Securing the Microsoft Azure subscription

This blog post is part of a series of posts on Security Best Practices for Microsoft Azure Applications. You can visit the landing page here.

Subscriptions help you organize access to cloud service resources. Compromise of a subscription can compromise all data and applications hosted in it. Threats and countermeasures for securing a subscription are listed below.

	Threats	Countermeasures
1	Spoofing of an account administrator, service administrator or co-administrator account to access the subscription. This could happen if the administrator's password is compromised may be by social engineering or brute-forcing or by compromising the administrator's local machine that is used to login to the Azure management portal. An employee who had access to a subscription using a Microsoft Account (Windows Live ID) leaves the organization, but can still access the subscription. Article related to this threat:- AWS console breach leads to demise of service with "proven" backup plan	Use organizational accounts or on-premise corporate identities instead of Microsoft accounts (Windows Live ID) to provision access to subscriptions. Set a strong password policy and require passwords to be changed periodically. Use Multi Factor Authentication to access the Azure Management portal. You can add Multi Factor Authentication to Azure Active Directory or enable Multi Factor Authentication on your on-premise STS (e.g. ADFS server). Limit the number of co-administrators to a minimum. To do so, use separate subscriptions for test and production environments, so that developers and testers do not need to be given access to production subscription and/ or use Role Based Access Control on the Azure preview portal to grant (owner/ contributor/ reader) access to subscription or to specific resources or resource groups. Periodically review the list of people who have access to a subscription, resource groups or resources. Administrators should ensure that the machines they are using to connect to the Azure portal have a secure configuration, e.g. should be patched and have anti-virus running. Monitor the subscription operation logs
2	A management certificate or a publishsettings file is compromised and is used to access the subscription. Or an administrator who had access to a management certificate leaves the company and may still have the certificate and be able to access the subscription. Articles related to this threat:- Old AWS API key led to search provider's cloud security breach Developers, Check Your Amazon Bills For Bitcoin Miners	Limit the number of management certificates being used in the subscription. When using PowerShell, prefer to use Add-AzureAccount to login using individual administrator organizational accounts instead of using management certificates. Periodically review the list of management certificates in the subscription. Ensure there is a valid reason for each. Change management certificates periodically and whenever someone who had access to the management certificate leaves the company. Do not store .publishsettings files, even for test subscriptions in your code repository or folder shares.
3	Someone takes an action on the subscription and it is not possible to tell who took the action and when.	Ensure that administrators are not using shared accounts to login to the Management Portal. They must use their individual organizational accounts or accounts that can be tied back to an individual. Limit use of management certificates to background jobs or scripts that need to run automatically. All other access should be done using organizational accounts either through the portal or using Power Shell. Subscription operation logs are available for the last 90 days. If you may need to know about actions taken earlier than that, archive the subscription operation logs.