Microsoft Exchange - Additional Design Considerations Around Security and Availability

I was recently asked how we had configured our Exchange servers in our secure environment. I wasn't going to go into detail on how to design and configure a Microsoft Exchange installation because there are many blogs and white papers covering the topic - where I thought I could add value was highlighting some of the additional design considerations sometimes not included in the configuration guides.

When we look at designing any solution including Exchange we will look at a solution that covers Confidentiality, Availability and Integrity of the entire solution throughout. We will not only look at the Exchange implementation but will also assess any related infrastructure components to ensure the whole end to end solution is as secure and highly available as possible. We will follow the security principles of “least privilege” and “defence in depth” where possible and implement fully resilient network and infrastructure components to support high availability.

Before moving on here are some best practice design guides for Microsoft Exchange and Exchange Security:

Microsoft Exchange 2010 Design: http://technet.microsoft.com/en-us/library/cc196387.aspx

Microsoft Exchange 2010 Security Design: http://technet.microsoft.com/en-us/library/bb691338(v=exchg.141).aspx

Base Network & Infrastructure Design Considerations:

Plan your end to end design and installation carefully. Document your design and verify it to ensure it is supported.

All supporting network devices should be configured for high availability including resilient routing and resilient links.

Networks will be segmented through the use of VLANS and multiple dual vendor firewalls. Only the ports needed between clients (users) and servers will be allowed.

For added security host based firewalls should be used to limit communications between servers in same VLANS.

Admin or privileged users computers should be located on a privileged VLAN that has less restrictive access to the exchange servers for admin purposes (management ports will be opened form this VLAN).

If running a virtualised environment - the supporting hyper-visor must be configured according to design and security best practices. Major vendors will have published papers supporting these configurations - Just ask Google!

Virtual datacenters will run on highly available hyper-visor clusters.

Implement an internal PKI - this can be quite specialist but you can learn how to implement it as there is a wealth of information out then on the internet.

Microsoft Exchange Design Considerations:

Make sure that your design is supported by Microsoft - you don't want to find that when you have an issue Microsoft refuses to support you because your solution is not supported.

Have your Microsoft Exchange solution designed in a cluster configuration for high availability as follows:

2 or more servers making up your CAS array (HUB & CAS roles)

2 or more servers making up your Database cluster (Mailbox role)

All our Exchange roles (servers) can reside in the same VLAN – you can split the roles out, such as placing edge servers in the DMZ - check with the configuration document to check what configurations are supported.

You can use basic NLB for load balancing of traffic to your CAS array but you also have the option of using other more advanced load balancing technologies available from Citrix, F5 or a cheaper alternative from KEMP.

Use trusted certificate providers for public facing portals such as Outlook Web Access (OWA) certificates – only allow HTTPS connections.

For highly secure implementation you can also encrypt communication between Exchange server components and/or client to Exchange server connections.

Exchange servers and data should be backed up daily using our backup software – journaling can also be enabled on the exchange server for archiving or if required a third party archiving tool can be used - such as Commvault or Symantec Enterprise Vault

Outlook clients will only be able to connect to specific exchange hosts (CAS servers) through specific ports from their VLANS.

Secure OWA (Outlook Web Access) traffic should be reverse proxied to your CAS servers from your perimeter network.

Ensure you have an excellent SMTP proxy and virus scanning solution, this usually sits on your perimeter network and will handle scanning of messages and rules applying to your SMTP traffic. 

All your Exchange servers can be virtualised for added resiliency through hyper-visor clustering (such as HA and DRS for VMware installations). Each of the clustered servers should be pinned to a separate physical host to prevent failure of a single hyper-visor host causing downtime.

There are various best practices for configuring Exchange 2010 or above with a given storage array so best to check with their configuration as Exchange 2010 users different technology to optimise SAN read/writes for Exchange 2010.

If you are handling sensitive data such as personal detail, secret information or credit card numbers then it would be wise to implement a policy based gateway encryption solution that compliments a wider Data Loss Prevention (DLP) solution.

If there is a requirement for high availability I would also look at DR and recovery of exchange services across sites, there are several options to look at here such as having a dedicated exchange node at another datacentre or recovering an Exchange cluster using something like VMware SRM if VMware virtualised.

There are also some advanced configurations of MX records that you can use for high availability configurations.

Only selected admin users will have access to the Microsoft Exchange servers and Exchange application. Auditing should be enabled and events logged to a central logging system if you have this capability in place.

Microsoft Exchange RBAC (Role Based Access Controls) should be used. These are usually predefined so it’s just a matter of adding the correct users to the correct groups. The groups are automatically created in Active Directory when you install Exchange.

Some financial regulations require compliance check or “Code of connections” and these may stipulate mandatory security controls for your implementations that go above and beyond any standard security recommendations. Additional security controls within the outlook client may also be included such as scanning of emails locally on the client as well as the gateway using different vendors, encrypted connections and/or only allowing plain text emails.

Need more detail – feel free to drop me a line….