SharePoint is not a secure application. But neither are any other applications out there. Their are some mechanisms in SharePoint that allow overriding the access permissions to SharePoint sites. These mechanisms can allow access to resources without the content owners knowing about it. There are however ways to learn of these individuals access via Auditing. The problem with auditing is that you can clear the audit log. Let's take a look at how this all works:
Basic site permissions:
Open SharePoint 2010 Central Administration
Create a new web application on port 100
Create a new site collection with a team site template
For the site collection owner assign as user, in my example I'm using ContosoSP_Admin
You should now be able to open the site using the browser (http://servername:100) as the SP_Admin user:
Create a new document in the "Shared Documents" library
Try to login using a different account (in my example "Dan Jump"), you will get access denied:
Advanced Web Application Permissions:
Switch back to Central Administration
Click "Manage web applications"
Select the port 100 web application
In the ribbon, click "user policy"
Click "Add Users"
Select "all zone", click "next":
Type a user, in my example I use "Dan Jump"
Click the "Full Control" checkbox:
Click "Finish"
Switch to the browser, try to access the site using "Dan Jump"
You will be allowed access!:
Click "Site Actions->Site Permission", notice the permissons on the site, it does not show "Dan Jump" having access
Notice that Dan can see the document even though no visible permissions are present
Delete the document in the document library and from the recycle bin.
It lets you do it! Poor SP_Admin won't know where his document went!
This scenerio presents some challenges around accountability. SharePoint administrators can at will assign permissions to sites, that by default are not tracked!
Site Collection Auditing:
Login to the team site as SP_Admin
In the Team site, click Site Actions->Site Settings
Under Site Collection administration, click "site collection audit settings":
In the documents and items section, check all the checkboxes
In the list, libraries and sites section, check all the checkboxes
Click "Save"
Add a new document to the document library
Login to the team site as "Dan Jump"
Delete the document
Now where to find reports? In some cases, you have to enable the site collection feature called "SharePoint Server Standard site collection features" first to get this link:
Click "Audit log reports"
Click "Deletion"
Click "Browse"
Select the "Shared Documents" library
Open the library, click "You should see the information that "Dan Jump" did in fact delete the document:
Sweet right!?! The audit log will record everything that happens on the site (as long as you tell it to anyway), even permission changes. But what if "Dan Jump" is an admin up to no good? "Dan Jump" could simply clear that audit log using a couple of methods.
Clear the Audit log:
You can clear the audit log by using the Object Model, PowerShell, or simply running this command:
SQL:
truncate table auditdata
PowerShell:
$spsite = get-spsite "http://servername:100"
$spsite.audit.deleteentries([System.DateTime]::Now.ToLocalTime().AddDays(1))
$spsite.audit.update()
Trying to rerun the report will result in an error, which is a bug in SharePoint by the way (a null/empty report is being returned and it can't handle it):
If "Dan Jump" wants access to the data without any auditing, he can also do that by accessing the database directly. See this post on how to dump the contents of the content database:
And with this guidance, black hat paradise awaits you…this post is designed to bring focus to security and governance. If you haven't thought about it yet, well….all you should be focused on
is Governance, Governance, Governance BEFORE you deploy SharePoint 2010.
Chris
For other security holes that you may not know about, check out this older blog post:
NOTE: The only way to ensure full compliance of auditing is to turn C2 Auditing on and let the SQL Server storage explosion begin!
