Security is probably one of the topics most often discussed with an organisation that is considering moving to the cloud.
In reality, it is reasonably likely that the physical security of the data centre is greater than your existing infrastructure. Your cloud provider has many protection measures for their underlying fabric, though there is one final piece of the puzzle - your solution.
Your solution is only as secure as you design it to be. I have worked with organisations that have the following mindset: "Ensuring that I have a Web Application Firewall and Virtual Machines stored in a locked down Virtual Network should mean I am secure".
The truth is, that is not the case. There are additional areas to consider. Now just to be clear, this is by no means a deep-dive into cloud security, but rather, a highlight of common pitfalls that I have seen.
Managing secrets is an age-old issue - You have a secret, for example, a database password. How do you ensure that you do not leak that information?
Firstly, ensure that you are not storing secrets in plain sight in your source. What happens if someone can decompile your application, or obtain your source code? Your data could be compromised, and depending on what that is - It could be damaging. Scott Hanselman wrote a blog post on managing this within ASP.NET, for example.
Secondly, control who has access to those secrets. Ideally, you would have a dedicated account per application to access your secret source. For example, in your database - you would have a database account for your application, which your end users cannot log into, and they would have separate user accounts. This approach would make things a bit cleaner from an auditability perspective.
You could also consider using something like Azure Key Vault to store those keys, backed by Azure Active Directory, so that only authorised users, or mechanisms allowed by you, can access the secret.
Remember that some secrets are accessible in the Azure Portal, so tight control of access to the portal is important. We will talk more about this a little further in "Effective Administration Management".
Rotation of Storage Account Keys
Storage Account Keys for storage accounts are synonymous to passwords for a user account; you do not want to lose it, as this could compromise the integrity of your data.
Consider regenerating your storage account keys regularly (in line with the policy that you would use to manage other secrets). Though, you may be thinking that this could have some significant manual overhead. There is an excellent article available on the Azure documentation page, which discusses How to Setup Key Vault with an end to end rotation and auditing approach.
I mentioned in the previous section that some secrets could be accessed in the Azure Portal - Storage Account Keys are an example of that.
Effective Administration Management
You should be aware that there are two deployment models, Classic Deployment (Azure Service Management) and Resource Deployment (Azure Resource Management), more details available here. Before I jump into some of the recommended practices, there is a reason that I bring the above point up. Within the ARM deployment model, there is the concept of Role-Based Access Control (RBAC). In the classic deployment model, no such concept exists. What does this mean? For any classic resources, co-admin access is a requirement for management.
Ensure that you keep the number of administrators on your account to a minimum. Consider that your admins hold "the keys to the kingdom" for your environment, so could easily bring things down if needed.
Ensure that, at a minimum; your admin accounts have Multi-Factor Authentication enabled. This approach adds an extra barrier to a potential compromise of those critical accounts.
Devolve access to your users by using Role Based Access Controls for all ARM (commonly known as v2) resources. There are a some existing roles available out of the box for you to use.
For those especially valuable resources, you can check to see who has access by selecting Access Control (IAM) in the resource blade. Further details are available here.
Controlling your Service Principals
Remember what we said about admins / co-admins of a subscription, and that they have the keys to the kingdom? Well, the same level of thought is needed for Service Principals.
A service principal has a defined level of access to a set of resources and used for some automation or deployment. Two examples of this include Deploying Resources via an Integration or Deployment Pipeline in Visual Studio Team Services and using Azure Automation to perform tasks on a scheduled basis.
A quick tip on the Azure Automation Run As accounts. When you create a Run As account, Azure creates a Service Principal in your Azure Active Directory to your v2 Resources and also creates a Classic Run as account to manage your v1 resources, using a management certificate approach.
Creating an Azure Run As account (non-classic) may fail if you do not have access to create applications in your Azure AD. If you are facing this scenario, then your organisation has disabled the setting "Users may add integrated applications".
Baseline of usual activity
Do you have a clear monitoring strategy, so that you can view an end-to-end story (from infrastructure up to your application)?
More importantly, do you know what normal usage looks like in your application? How about a given day or month? If you are a retailer, do you know what "normal" looks like for Black Friday, for example?
Once you have an idea on the above, you can then begin monitoring and alerting on significant trends within your logging. Additionally, you could take this a step further and build a Red vs. Blue team scenario, to Attempt/Detect an intrusion of your system.
Azure Security Centre is your friend
Azure Security Center is a recent addition to the Azure Portal. It helps you to detect, prevent and respond to threats in your environment, based on the resources within your subscription. This service should present some quick wins.
However, be mindful that recommendations provided by security center are actionable at the click of a button. If you take action, it performs the action without confirmation. As such, it is worth performing these changes in a UAT environment first, to prevent any potential impact on your production environments.
I hope that these points have been useful. They are an amalgamation of areas that I have seen while working with customers on their Azure Solutions. Do you have any more thoughts? Let me know on Twitter, @reddobowen