Opening up an internal SharePoint farm to the Internet in order to share resources with external parties might seem a good idea, because it helps avoiding expensive infrastructure changes. However, in terms of security, this is not recommended because it does not sufficiently protect internal resources from external threats.

The protection of internal resources hinges on the security-level of the Windows Server operating system, the SharePoint product and the deployed 3rd party code. In other words, if security patches are not applied regularly or in case of 0-day vulnerabilities, there may be little to prevent an attacker from gaining access to confidential internal information. The lack of a physical separation of the internal and external collaboration platform violates the important defense-in-depth principle.

Furthermore, an attacker can attack other servers (or even clients?) within the Intranet without bypassing the internal Firewall first.

To be more specific, a remote code execution vulnerability in one of the web server or its software components would allow an adversary in the Internet to execute its own code on the internal SharePoint server and therefore:

  • directly attack the internal SharePoint Web Application and its critical assets
  • directly attack other servers in the same internal network
  • directly attack the internal Active Directory Domain Controller

Note: A Web Application Firewall needs to be seen as a second layer of defense and cannot replace a secure SharePoint architecture.

Ideal Solution

The following architecture designs are proposed by Microsoft and recommended by Compass Security.

Back-to-back perimeter

Split back-to-back

Alternative Solutions

If implementing a dedicated AD in the DMZ is not an option. There are still ways to open up SharePoint for external parties, but still reduce the exposure of the internal Windows network.

As a first step, the internal SharePoint farm should be physically separated from the external one. This at least isolates an attacker on separate Windows Servers. However, the following threats still exist:

  • directly attack other servers in the same internal network
  • directly attack the internal Active Directory Domain Controller

Therefore, the external Web Application should be hosted on a SharePoint farm in a separate perimeter network (DMZ). If the new farm is still joined to the internal Active Directory domain, the following threat remains:

  • directly attack the internal Active Directory Domain Controller

Read-Only Domain Controllers (RODC) might seem to be a great, lightweight solution to shield the internal DC from external attackers, but Compass has not heard of any success story involving RODCs. This concept has been introduced to protect ADs in less secure office sites, but not to introduce ADs in DMZs. The configuration can be very difficult and error prone. Furthermore, not all SharePoint features are supported.

Long-story short, DMZ systems should not be joined to the internal Active Directory domain. The only way to properly segregate the internal and external environments is to introduce a dedicated AD forest in the DMZ for the technical accounts of the external SharePoint farm and the authentication of the external users. On the other hand, this means that a new solution needs to be found for authenticating the internal users on the external farm (for collaboration and sharing with external parties). If the solutions proposed by Microsoft, a one-way trust relationship between the internal and the external AD forest, is not an option, another more light-weight solution could be implemented using the Microsoft SAML implementation AD FS.

References