Here are some tips that might help you building and hosting secure applications in Azure.
Application Architecture: Clients and APIs
Make sure to make a clear segregation between clients and APIs. I’m not a great fan of MVC where the C part is often used as an API layer by developers. I advocate for a clear separation between the client part (could be a mobile APP, a SPA, etc.) and the API layer. The clients and APIs should be hosted in different App Services.
Do not trust client devices
Whether your client is a browser, a mobile app or any other native client application, as a rule of thumb, never store any sensitive information that is beyond the scope of the current device/user. So for instance, never use a Storage Account key right from a client device. Do not assume that mobile apps’s code is not accessible. So for instance, if you write a Xamarin mobile app, it will be packaged and delivered as an IPA file which can easily be retrieved via iTunes. Extracting code from the archive is a piece of cake and using reflectoring tools to reverse engineer the code is not more complicated.
Moreover, it is damn easy to proxy a mobile device with Fiddler (or other tools) so as to capture and analyze HTTP/HTTPS traffic. Same goes for browsers of course, although it is even easier to explore the browser storage & network activity.
Make sure to ensure API isolation (network isolation) and/or secure them through AAD or any other authentication/authorization mechanism. In Azure, there are multiple ways to ensure network isolation/protection such as using App Service Environments or IP filtering at App Service level.
Use an APIM layer between your consumers and your APIs. Of course, in the Azure story, Azure API Management is a first class citizen. Define proper APIM policies to ensure only eligible requests are sent to the backend APIs. Leverage the built-in JWT token validation and other techniques such as Client Certificates to secure the communication between API consumers and APIs. On top of the security bits, APIM will help you defining throttling policies which are an extra protection against DOS attacks.
Use Azure’s network plumbing (NSG, ASG, subnets, vnets, peering, etc.) to control network flows between Azure to Azure resources and Azure to on-premises. Azure makes it easy now to setup & control secure connections.
Host SPAs behind an Azure Application Gateway with WAF enabled to protect against most of the OWASP vulnerabilities and more particularly the attacks targeting browsers.
Whether you need to use certificates, encryption keys or secrets, do not reinvent the wheel and just use Vault together with its SDK. Azure Key Vault is a FIPS 140-2 level 2 HSM, in other words, some piece of hardware many organizations can’t even afford.
Keys, Secrets & Certificates rotation
Make sure you rotate sensitive information on a regular basis. Vault may help achieving this as explained in this article https://docs.microsoft.com/en-us/azure/key-vault/key-vault-key-rotation-log-monitoring
Organizations are used to deal with PKI but should not only focus on this. I’m more particularly referring to Azure Active Directory Applications that are a new (few years old already) kid in town and for which I often see never-expiring application secrets. In comparison, I very rarely see never expiring certificates. Why is that? Simply because AAD Apps are not yet integrated in the existing enterprise processes. But whatever the reason, that is pretty bad, especially if some of your components do leverage the Client Credentials Flow (app-only). Therefore, I’d recommend using short-lived AAD Apps secrets. The Graph API helps identifying secrets that are about to expire so it is not hard to have scheduled Azure Automation runbooks rotating these secrets automatically and seamlessly for your business applications.
Keep credentials out of code
Explore (still in preview) Azure MSI if your APIs need to access other resources.
CI/CD pipeline, quality gates & security scanners
Nowadays, security also happens here. With Agile Development and very frequent releases, it is no more possible to rely only on penetration tests since they are very expensive and hardly affordable every 2 weeks. So, unless you have Blue & Red teams in your organization, you’d better invest in tools that will analyze both the code quality & security of your code base. To me, the code should be agnostic to its final hosting location and should be robust by design. Layer 7 vulnerabilities are often due to unvalidated untrusted data and this, can be avoided right from the code itself, independenly of a WAF.
Monitor, monitor, monitor!
Admittedly, monitoring what’s going on in Azure isn’t an easy piece because there is a plethora of tools, but when it comes to security, I’d definitely recommend using the Azure Security Center and Traffic Analytics (preview) together with NSG Flow Logs.