ASD's Blueprint for Secure Cloud

Microsoft 365 is a publicly facing SaaS offering and firewall ports are required to be opened to enable communication between infrastructure and desktops and Microsoft 365. These ports configurations are updated frequently and are available online from Microsoft.

It is important to note the traffic between the clients and the Microsoft 365 offering is TLS 1.2 encrypted.

Configuration will occur on the proxy and external gateway of the organisation as required.

Mail flow and gateway

Mail flow is the path taken by an email from the sender to a receiver. A Mail Gateway acts as the central egress and ingress point for mail traffic into organisations.

For organisations implementing a PROTECTED environment, organisations are required to use a separate mail gateway to interface with GovLINK for the following functions:

• Encryption
• Message rules
• Header modification

This will achieve the closest alignment to whole-of-government policy for Secure Internet Gateways and with the guidance in ASD’s Information Security Manual and the Protective Security Policy Framework.

GovLINK enables secure communication between Commonwealth entities across public infrastructure and is required for PROTECTED mail to be securely transferred between government organisations.

A Transport Layer Security (TLS) solution for GovLINK is available enabling a direct interface between Microsoft 365 Exchange Online and GovLINK. In addition to Exchange Online, organisations wishing to deploy this solution will also require Microsoft Defender, Mail Transfer Agent-Strict Transport Security (MTA-STS), and TLS.

More information on GovLINK is available on the Department of Finance website.

Enquires on the GovLINK TLS solution can also be directed to govlinkenquiries@finance.gov.au or via the above website.

Optimisation

Microsoft 365 is a globally distributed service. The user experience with Microsoft 365 involves connectivity through highly distributed service connection points that are scaled over many Microsoft locations worldwide. This section outlines two sets of design decisions, representing advice to achieve the highest level of maturity and adherence to existing Whole of Government policies and advice to maximise optimisation outside and user experience. The below information is to inform organisations, including on how best to maximise optimisation and user experience, however consideration should be given for the risk implications of implementing in such a way. While this approach of optimisation represents the current best practice published by Microsoft it is inconsistent with the previously referenced guidance in ASD’s ISM and the PSPF relating to Secure Internet Gateways. We have provided configuration controls for both scenarios below.

To minimise latency, a customer network can route user requests to the closest Microsoft 365 service entry point, rather than connecting to Microsoft 365 through an egress point in a central location or region.

The following achieves optimal Microsoft 365 connectivity and performance:

• Local DNS resolution and Internet egress - Provision local DNS servers in each location and ensure that Microsoft 365 connections egress to the internet as close as possible to the user’s location. This configuration minimises latency and improves connectivity to the closest Microsoft 365 entry point.
• Add regional egress points - If the organisation’s network has multiple locations but only one egress point, add regional egress points to enable users to connect to the closest Microsoft 365 entry point. This configuration minimises latency and improves connectivity to the closest Microsoft 365 entry point.
• Bypass proxies and inspection devices - Configure browsers to send Microsoft 365 traffic directly to egress points and bypass proxies. Configure edge routers and firewalls to permit Microsoft 365 traffic without inspection. This configuration minimises latency and reduces the load on network devices.
• Enable split tunnelling connection for VPN users - If a VPN solution is required Always on VPN should be integrated into the organisation infrastructure. For VPN users, enable Microsoft 365 connections to connect directly from the user’s network rather than over the VPN tunnel by implementing split tunnelling. This configuration minimises latency and improves connectivity to the closest Microsoft 365 entry point.

Microsoft 365 Connectivity Optimisation Design Decisions for an increased security posture.

Microsoft 365 Connectivity Optimisation Design Decisions for an enhanced User Experience.

Exchange hybrid

This section is only relevant for organisations implementing a hybrid solution that leverages an on-premises Exchange Server(s).

Exchange Online can be used standalone (cloud only) or integrated with an on-premises Exchange Server(s) and Active Directory Domain Services, extending the organisation’s messaging farm in a hybrid configuration.

A Hybrid configuration provides administrators with added flexibility to transition users to the Cloud without isolating them from the on-premises resources. A Hybrid configuration can also assist with transport routing for compliance reasons (e.g. GovLINK) when “centralized mail transport” is enabled. The Edge Transport service may be deployed in scenarios where the organisation does not wish to expose Hybrid mail servers directly to Exchange Online Protection.

organisations wishing to synchronise their existing on-premises Active Directory Domain Services for identity (hybrid identity) must maintain an on-premises Exchange server for recipient management purposes, this is because most of the user attributes cannot be managed from Exchange online due to directory synchronisation rules, for more information see decommissioning on-premises Exchange servers.

Establishing hybrid deployments requires an Exchange hybrid server that is supported with existing on-premises Exchange Server. Microsoft recommends the deployment of the newest Exchange Hybrid server for the environment to ensure the best compatibility with Exchange Online.

Exchange 2010 has reached end of support, organisations that wish to use retain a Hybrid configuration after the Hybrid migration method should migrate those Exchange server roles to a supported version of Exchange. Microsoft also recommend that organisations still on Exchange 2010 that have not started or completed their Hybrid migration, upgrade from 2010 to 2016 before commencing the hybrid configuration.

Exchange Hybrid Server Supported Configurations.

The following table outlines the Exchange server roles required to be installed based on on-premises Exchange environment version. The roles mentioned for Exchange 2013 and 2010 can be installed separately or on one server, Microsoft strongly recommend installing all roles on one server.

Exchange Hybrid design considerations and decisions only apply to organisations leveraging a hybrid implementation.

Mail Exchange records

Mail Exchange (MX) records specify the mail server responsible for accepting mail on behalf of the domain.

The record is a resource in the Domain Name System (DNS), and it is possible for a single domain to have multiple MX records. Multiple records are largely configured for availability, redundancy, and load balancing reasons.

Cloud native deployments

Hybrid deployments

Mail connectors

Mail connectors use TLS to secure communication and can customise the way mail flows into and out of the organisation.

Generally mail connectors are required. An exception may be where organisations do not use a mail gateway and relies on Exchange Online Protection.

When the organisation intends to operate at the PROTECTED level, the Blueprint assumes that all organisations are implementing the configuration with a Mail Gateway and as such, provides detailed configurations on implementing mail connectors via the relevant gateway.

Mail Connector Configuration for all organisations and implementation types for environments intended to be used at the PROTECTED level

Autodiscover

Autodiscover is a mechanism for the configuration of a user’s email client with minimal user input. The required input from the user is their email address and password.

Autodiscover for a cloud environment varies from the process utilised when on-premises Exchange is leveraged. With a cloud environment, an Autodiscover Endpoint representing the domain is not available. Instead, DNS redirection and Hypertext Transfer Protocol Secure (HTTPS) redirection is leveraged to direct the Autodiscover client to a trusted Autodiscover Endpoint. The high-level process is:

• The Autodiscover endpoint looks for a host named autodiscover.{DomainName}.com
• DNS provides the Internet Protocol (IP) address of the host autodiscover.outlook.com
• The Autodiscover client attempts communication utilising HTTPS (This fails)
• The Autodiscover client requests redirection over Hypertext Transfer Protocol (HTTP) (This directs the client to autodiscover-s.outlook.com)
• The Autodiscover client attempts communication utilising HTTPS. The communication is successful. However, the new Autodiscover endpoint does not have a server certificate for the requested hostname. This communication is then redirected using HTTPS redirection to an additional Autodiscover endpoint which can provide the required Autodiscover information.
• The Autodiscover client completes the Autodiscover process with the new Autodiscover endpoint.

To ensure this process functions as described above, appropriate DNS records are required.

Cloud native deployments

Hybrid deployments

SPF, DMARC and DKIM

Sender Policy Framework (SPF), Domain Key Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC) are tools for email authentication. These tools can coexist to provide enhanced capabilities.

These tools can coexist to provide enhanced capabilities.

• SPF - SPF is a DNS entry which lists the servers which can send emails from a specific domain. It enables recipients to verify the identity of incoming mail.
• DKIM - DKIM, unlike SPF is a tool to verify whether the content of the message is trustworthy. This is completed using a public/private key signing process.
• DMARC - DMARC enables both SPF and DKIM using policy. A DMARC policy sets out how to handle messages which do not align to what the receiver knows about the sender. This can include rejecting the message; suggesting the message is quarantined; or allowing the message.

While DKIM within Microsoft 365 can sign messages, the organisation’s gateway may also be configured to do this which may cause issues with DMARC verification.

Note, organisations that enable DKIM signing within Microsoft 365 that also add additional business logic to email at the egress mail gateway, such as adding a default organisation email disclaimer, would fail DKIM authentication as the contents of the email had changed after the email had been sent from Exchange Online. In this scenario consider migrating the business logic from the mail gateway to native Exchange Online transport rules.

Accepted domains

Accepted Domains are SMTP namespaces configured within Exchange Online. Only emails addressed to users within the nominated domains are accepted.

Accepted Domains consist of the following types:

• Authoritative Domains - Authoritative Domains are domains where the Exchange Organisation accepts messages addressed to recipients and is responsible for generating non-delivery reports. On creation of an Exchange Online organisation the tenant domain Fully Qualified Domain Name (FQDN) and the <tenantname>.mail.onmicrosoft.com FQDN are automatically populated as an Authoritative Domains; and
• Relay Domains - Relay Domains are often called Non-Authoritative Domains. The Exchange Organisation will accept the messages addressed to the recipients; however, it is not responsible for generating non-delivery reports. Hybrid Exchange leverages Relay Domains and mail connectors to relay messages between both on-premises infrastructure and Exchange Online.

Hybrid deployments

Remote domains

Remote Domains enable administrators to control the type of replies and format of messages users send to the destination domain.

Administrators can configure Exchange to allow (or block) the following:

• Out of Office messages.
• Automatic replies and forwards.
• Read or delivery receipts.
• Non-delivery report to a specified domain.

The default remote domain will apply the same settings to all messages; however, administrators can configure specific settings for specific domains.

Configuration

Certificates for hybrid deployments

There are additional specific certificate requirements when configuring Exchange Hybrid that only apply to organisations implementing a hybrid configuration as Exchange Online encrypts all traffic to the on-premises environment. organisations implementing cloud only environments that do not leverage an on-premises Exchange Server do not need require these configurations.

The following certificates are associated with Exchange hybrid deployments:

• Azure Active Directory Connect (Entra Connect) with Active Directory Federation Services (AD FS) – a third party certificate from a Trusted Authority (CA) is required to establish a trust between web clients and federations server proxies used to sign and decrypt security tokens.
• Exchange Federation – a self-signed certificate is used to create a secure connection between the on-premises Exchange server and Azure Active Directory authentication
• Exchange Services – a third party certificated from a Trusted Authority (CA) is required to secure the TLS communication between Exchange servers and clients. These include Outlook on the web, Exchange ActiveSync, Outlook Anywhere and secure message transport
• Existing Exchange Servers – might use self-signed or certificates issued by a Trusted Authority (CA) depending on Exchange server certificates. These certificates may need updating for Exchange Hybrid

Suggested FQDNs for hybrid deployments:

Related information

Security & Governance

• None identified

Design

• None identified

Configuration

• None identified

References

• GovLink
• Secure Internet Gateways
• ASD’s Information Security Manual
• Protective Security Policy Framework