Sharepoint Data Security Risks


Introduction


Microsoft Office SharePoint Server 2007 (MOSS) and Windows SharePoint Services 3.0 (WSS) gives companies the opportunity to gather data from many sources and publish this on a central location for users to access. But what do the SharePoint administrators need to consider to make sure confidential information is not made available to everyone?


In this article we focus on the challenges of securing data on Microsoft SharePoint sites, lists, pages and the information made available through data-links to backend systems (through BDC and manually created data-links). The audience for this article is primarily the network-/server administrators and SharePoint designers / publishers.


Why do we need to consider securing information?


There are different inputs on what we need to consider when publishing content on SharePoint intranet sites. Sometimes it can be difficult to control the information available if the structure of content and the security access to this is not well planned from the beginning. As the intranet grows the designers and publishers learn how to use SharePoint for team collaboration, document management and dynamic reports. This content is made available for other employees and here is the key question: What information are they allowed to search for and read? SharePoint, being the place to centralize and structure information, really supports employees and teams work processes but can also be a data security breach if it is not secured correctly.


Let’s begin with an example scenario:


Toy Company A makes key performance indicators (KPI) available on their SharePoint site to show the executives how their department performs financially on a web page. The designer creates a data-connection to the financial database to extract the data. The executives have a blog on the same site where they comment on the KPI every week.



Figure 1: What is behind the nice web part?


In this example the designers have to secure the financial data connection so that only the required information is extracted from the database and to make sure that only the executives can access the data and the blog. The executives must know the importance of this security configuration to ensure and check that the policy is followed. In the worst case the designers use BDC with a full access account to the financial database and make it searchable – and do not limit access to the site for only the executives. In that case every user can search for financial data, read it and the blog comments on the intranet.


Making sure that the intranet is a secure place is a task that must be well planned. If every person from the architect to the end user is aware of this and understands why and how to secure the content (and follow the policies), the intranet is a safe place for your data.


How can users get away with company data?


When we are talking about data security risks the obvious question is: “how can we avoid people seeing or even getting a copy of our confidential information?” Well, today it is very hard to be one hundred percent sure that no one gets a copy and takes it outside the company. Oh yes, it can be done but how many companies have such restrictive security policies around the world? Not many.


The SharePoint infrastructure has a very good “feature” that I like: Users cannot see content that is restricted. YES, that is the way we want it! And with Information Rights Management (IRM) implemented we have great user control. But how can data get out of the SharePoint and be used elsewhere? Of course a SharePoint backup contains a lot of information, so keep these in a place with no user access. But if the users have read access to the content, they could use…


Internet browser



  • Copy-paste the data to any application.

  • Export the data to an XML-file via the URL protocol (owssvr.dll)

Office products



  • Connections and exports can be made to Office applications

  • The “Connect to Outlook” can make data available offline and be exported

Other programs 



  • Calls can be made to the SharePoint farm e.g. through Windows Powershell or other applications

Data copying could be an issue and the tools are right in front of the employees. We can hide links and pages from your users but we need to set correct permissions on the lists, items, document libraries, etc to avoid data copying/loss.


Pinpoint where to check or tighten the security


Okay, now we know why we need to address security on the intranet. Identifying where this can go wrong is the next challenge – and a big one too – and perhaps a bit more technical. Microsoft SharePoint is kind of a large chunk to swallow at the beginning. But working with the individual parts for some time solves the puzzle one bit at a time. As you can see in Figure 2 I have divided into separate sections the different data and how it is connected in the SharePoint structure and arrows of the communication. It simplifies some of the elements and features but gives you a picture of what to look for in your own environment. If you need more details please visit the Microsoft TechNet for full diagrams (see the link section below).


  
Figure 2


Notice the question marks? These places are where the security level must be considered. I will start explaining some considerations I thought of from the top of this diagram.



  • When a user accesses the SharePoint intranet:
                     What type of authentication must be used?
                     Should the traffic be encrypted with SSL?
  • SharePoint data is e. g. made by lists, pages and document libraries.
                     Should access to some/all of these be restricted in different levels?
                                          No Access
                                          Readers
                                          Publishers / Editors
                                          Administrators
                                          Are the administrators of the sites, SharePoint Service Providers (SSP) the correct ones?
  • Custom pages can contain manually configured data connections.
                     Ensure correct permissions is set on the pages/files.
                     See “External data sources” below if custom connections is used.

  • Custom solutions can contain code that access many areas.
                     Choose only to install custom solutions you trust.
                     Choose the correct security level when installing the solution (see link section).
                     See “External data sources” below if custom connections is used.
  • Search Crawls
                     The default content access account has full read access of all web applications in the farm.
                     Manually configure read access for the following:
                                      SharePoint sites outside the server farm
                                      Business Data Catalog applications
                                      Web sites
                                      File shares
                                      Microsoft Exchange Server public folders
                                      Lotus Notes
  • Access to Business Data Catalog (BDC) data 
                     Choose the correct security access level for users to ensure confidential information is not exposed 
                       to  everyone.
                     Choose the correct authentication method for your BDC connection (see link section).
                     If you configure search crawl consider the access to the crawled data.
  • Custom database connections can be made for the designers.
                     Make sure the connections is only available to the employees that needs the information.

  • External data sources
                     Do the data connections use other credentials?
                     Can the used credentials access more than needed?
                     Use Pass-through/Single Sign-On authentication if possible.  
                     If RevertToSelf is used, remember this option uses the Application Pool account to access the data 
                       source.

  • Service accounts
                    Only use least privilege rights for your service accounts (see link section).

  • WSS/MOSS Servers
                    Secure the server with Antivirus for the OS and SharePoint.
                    Patch the server with security patches when needed.
                    Use a firewall to limit the risk of attacks.
                    Secure the servers physically. 
                    Keep the central administration port a secret for non-administrators.

  • MOSS SQL database server (of not on the same server as WSS/MOSS)
                   Secure the server with Antivirus for the OS and SharePoint.
                   Patch the server with security patches when needed.
                   Use a firewall to limit the risk of attacks.
                   Secure the servers physically.
                   Use SQL alias and non-standard ports  for communication – especially if DMZ is used.

  • Network communication
                   Encrypt the communication between servers if possible.

Use the figure and list above to check how the health of your intranet is and discuss the decisions made for your SharePoint farm. This is not a complete checklist but see it as a guideline for a more secure farm. Small and medium sized companies tend to tighten security on the box in Figure 2 called “SharePoint Data” but of course this will vary from installation to installation.


Summary


In this article we covered why we should control the access to data and what scenario to avoid. We looked into how we could pin point security breaches and had a look into the security considerations on specific parts of a SharePoint intranet farm. 


Links


Microsoft MSDN: Business Data Catalog Authentication


Microsoft MSDN: URL Protocol


Microsoft TechNet: Plan for and design security (Office SharePoint Server)


Microsoft TechNet: Plan for administrative and service accounts


Microsoft Download center: MOSS Logical Architecture diagram


Combined Knowledge document: Code Access security for administrators

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top