Tuesday, September 13, 2011

Options to block or exclude a security group to access some selected Sharepoint site collections - Part II

You might see the issues we are facing from Part I to restrict the users belong to some security groups to access selected site collections with sensitive information even these users have been granted the permission through individual account, any AD groups, or email list groups.

After discussion with several consultant companies, Microsoft SharePoint architecture teams,  and Microsoft SharePoint product teams, there is not a simple solution to achieve this access control without leaving any security holes. In this blog, we will continue to explore the challenges and some other thoughts beyond part I.

1. The first challenge is to identify the sensitive site collections need to be controlled or blocked on access. By discussion the business process with business departments and security teams, we have come up a fairly clear rule to identify those sensitive site collections.  Here is the approach for us.
  • We identify the departments that are involved in sensitive projects or information. 
  • The list of the department number we called "Controlled Department list" then will be provided to the SharePoint team.
  • Any site collection with any owner who belongs to the "Controlled Department list" will be the ones we need to restrict access. These site collections will be called "Controlled Site Collections"

    2. Second challenge is to identify the group of users who should be blocked to the controlled site collections. Here is the approach for us.

    • Identify the users from the geography location and department
    • Create a AD group that will sync all those users to the group. This group will have ALL users that should be restricted to the "Controlled Site Collections". This group we call "Black List".

      3. Third challenge is back to our original question the best option to restrict the users belong to some security groups to access selected site collection. 

      Originally we were hoping there is a way we could extend "Deny-All" functionality form webapp to Site Collection. However, after discussing with Microsoft,  "Deny-All" functionality for site collection is not possible due to the following reason provided by Microsoft product team.

      • Implementation of SharePoint Authorization Process is closed
      • The only deny rule is at WebApp level to override ACL
      • SharePoint Authorization API is not open for extending
      • There are no alternate SharePoint APIs that can manage similar functionality
      • Authorization functions are not open for extension in the future releases at this time from product team and Sr. escalation engineers

        4. The forth challenge is to keep SharePoint security integrity across all SharePoint functions. Any security restriction we implemented should be applied to the following functions to keep security integrity.
        • Search - if you cannot access the content, you should not be able to search the content
        • Direct link to items - if you could not access the site collection from UI and whole collection should be restricted. You should not be able to access the content such as file directly through link to the file
        • Users added to AD group after the AD group granted the access - if "clean" AD groups has been grant access to site collections and people add additional users to the AD group, there is potential risk that "Black list" users could be added. No of the current tools could resolve this case.
        • Excel services - User should not access to any restricted content through any services besides UI
        • SharePoint API - If user could not access any content through UI, s/he should not be able to access through API. Most tolls and options failed on this also.
        • SharePoint Web service - same as above
        • Outlook integration - Any integration should be same security access
        • UNC and WebDev integrations - same as above

        We have looked at many third party tolls such as ControlPoint, Quest SharePoint Adminstration tool, DeliverPopint, UAG. None of them could be implemented quickly with all the functionality we are looking for.

        Since at this point, we have identified the top challenges and we have the site collection URLs need to be secured and the AD group with black users, we are looking to have other tools that could apply policy such as URL restrictions. Here are three options we are evaluating.

        • Forefront Threat Management Gateway 2010 Server (TMG) 
        • TITUS Document Policy Manager
        • NextLabs for SharePoint Secure Deployment
        • Cryptzone SharePoint security control
        • Imperva SecureSphare Data Security for SharePoint
        • Aveksa SharePoint Governance
        • HiSoftware for SharePoint
        • Customized authentication provider that is similar to http interceptor 

        At last, even if we have the solution to restrict "Deny all" access to certain site collections, there are still some problems. One of the problems is that if the content copied from "Controlled Site Collections" to non-controlled site collections, how we could deal with this? Should we notify the security group? Should the content be protected? There will be more test cases need to be evaluated

        We will work with Microsoft in the next two week to identify whether any of the remaining options could satisfy our requirement.


        1. Great discussion referencing properly securing content even for properly authenticated user objects.

          I think speaking to the many ways to secure SharePoint is a great start. If fact you spoke to the protection of content briefly which overlook the fact that is the more important aspect to SharePoint core capability as a content repository.