This article explains the security controls that can be changed in Azure Stack Hub and highlights the tradeoffs where applicable.
Azure Stack Hub architecture is built on two security principle pillars: assume breach and hardened by default. For more information on Azure Stack Hub security, see Azure Stack Hub infrastructure security posture. While the default security posture of Azure Stack Hub is production-ready, there are some deployment scenarios that require additional hardening.
TLS version policy
The Transport Layer Security (TLS) protocol is a widely adopted cryptographic protocol to establish encrypted communication over the network. TLS has evolved over time and multiple versions have been released. Azure Stack Hub infrastructure exclusively uses TLS 1.2 for all its communications. For external interfaces, Azure Stack Hub currently defaults to use TLS 1.2. However, for backwards compatibility, it also supports negotiating down to TLS 1.1. and 1.0. When a TLS client requests to communicate over TLS 1.1 or TLS 1.0, Azure Stack Hub honors the request by negotiating to a lower TLS version. If the client requests TLS 1.2, Azure Stack Hub will establish a TLS connection using TLS 1.2.
Since TLS 1.0 and 1.1 are incrementally being deprecated or banned by organizations and compliance standards you can now configure the TLS policy in Azure Stack Hub. You can enforce a TLS 1.2 only policy where any attempt of establishing a TLS session with a version lower than 1.2 isn't permitted and is rejected.
Important
Microsoft recommends using TLS 1.2 only policy for Azure Stack Hub production environments.
Demonstrate the skills needed to implement security controls, maintain an organization’s security posture, and identify and remediate security vulnerabilities.