Certificate Management in Azure: Do's and Don'ts
This post comes from Avi Ben-Menahem, a Principal Security Program Manager in the Azure Security engineering team.
There are multiple services that require credentials for secure access or data protection as part of service development and operations in Azure. Some of the most immediate examples include SSL (ok, actually TLS, but we’ll refer to it as SSL in this article) for client and server authentication or communication encryption, storage account keys and more. As cloud services evolve, we see the number of credentials used across the different services grow significantly, and with it comes the complexity of proper credential management which includes acquisition, credential lifecycle and secure credential storage.
Internally in Azure we are investing heavily in ensuring we have a robust set of tools, operating procedures and standards to ensure we are providing a secure platform for our customers which is robust and compliant (more on compliance another time). In this blog I want to share some of the best practices and recommendation we use internally for credential management, with a focus on X.509 certificates.
Acquisition
Certificate management in Azure requires a few steps to implement and get right. Once you setup your web site or web role follow the steps here to acquire and configure the certificate: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/.
There are a few best practices and recommendations you should pay close attention to:
You should not acquire certificates for the cloudapp.net and azurewebsites.net domains or any of their sub domains such as mysite.cloudapp.net. These are Azure-reserved domains and any of the sub-domains created during the web site or web role creation already have HTTPS enabled through the default Microsoft multi-domain cert. Before enrolling for a public facing SSL certificate you should acquire and register a domain name and only then enroll for the appropriate SSL certificate per the article above against that domain.
Cryptographic recommendations:
Don't use wildcard certificates (e.g. *.mydomain.com) unless absolutely required - wildcard certificates which are widely deployed on multiple service instances reduce the isolation boundaries of your service. If one of the instances is compromised, the compromised certificate will affect all services under your existing domain name, which makes revocation and recovery extremely difficult.
Ensure proper EKU (Extended Key Usage) extensions in your certificates - makes sure you include EKU only for the usage of your application. For example, include only "Client Auth" and "Server Auth" OIDs for SSL certificates. OIDs support the naming of almost every object type in X.509 certificates, such as components of Distinguished Names, CPSs, and others. Misconfigured certificates can lead to a more significant compromise if not done right.
Ensure proper algorithm and key length:
RSA >= 2048. Note: All public SSL CA's will issue RSA 2048 based certificates.
Diffie-Hellman (>= 2048bit),
ECC (>= 256bit), Elliptic Curve Cryptography P-256 or greater
Use SHA-2 only (SHA-256, SHA-384, SHA-512). Note that starting in the year 2017, all certificates which use SHA-1 will not be trusted by most browsers.
Credential Lifecycle
Another key focus area is the rotation period for different key types. We highly recommend that you rotate credentials on a regular basis. In some cases, ensuring proper key rotation can be a cumbersome task - it is recommended you plan and budget for it as part of your application's ongoing maintenance and development cycle. Below you can find a table that includes the different credential types and the recommended rotation period for each:
|
Secure Storage
One of the most important aspects of credential management is secure storage. None of the above recommendations and best practices matter if credentials are not properly secured. We strongly recommend that you establish a proper secure store and enforce its use early in the development cycle, no ifs, no ands, no buts! We have seen cases where credentials were left in config files, source code or as plain unprotected text files. Don't be that gal or guy!
In addition, we have recently announced the public availability of the Azure Key Vault. Key Vault enables developers and operators to store and control cryptographic keys and other secrets used by cloud applications in a secure storage which can be HSM backed. Get started on Key Vault here.
Avi Ben-Menahem
Azure Security
@Avibm