Security is essential

When you run an application, it needs to be secure. There are many ways that attackers can attack your application and potentially get at your data or bring your app down. When you run your application in Azure, you get a lot of world-class protection out-of-the-box. However, you should still follow security best practices to make sure that your application and infrastructure in Azure is as secure as possible. In this post, we’ll explore some of the security best practices for Azure that can help you to make your application more secure.

#1. Encrypt data at rest and in-flight

Your data is often the most important asset of your business. This means that you need to protect it against attackers. There are many things that you can do, but in the worst-case scenario, it could be that an attacker gains access to your data, like data in your Azure SQL Database. Even if this happens, your data can be protected. Because by default, TDE (Transparent Data Encryption) is enabled in Azure SQL and Azure Synapse Analytics. And equivalent technology is enabled for Azure Database of PostgreSQL and Azure Database for MySQL. These technologies encrypt your data, so that it is not readable by anybody but the services that hold the encryption keys. Azure manages the encryption keys for encryption of data at rest. And if you need to, you can bring your own encryption keys to Azure SQL Database and Azure Synapse Analytics.

(Azure SQL Database TDE setting)

Azure Storage also encrypts data at rest by default. This encryption cannot be disabled, which is a good thing. By default, Azure manages the encryption keys for Azure Storage encryption. You can also bring your own encryption keys to encrypt and decrypt data in Azure Blob Storage and Azure Files.

Encrypting data at rest is very important, but it is also important to make sure that attackers can’t intercept data when it travels from service to service or to a web browser. This type of data is called in-flight data and you can encrypt it using TLS (also called SSL) encryption. TLS is enabled for all Azure services by default and for most services, it cannot be disabled. It encrypts the tunnel that data travels through. On top of using TLS, you can use the Azure Storage Client Library to encrypt data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client.

The best practices to take away are:

• Always encrypt data at rest
• Always encrypt in-flight data

#2. Restrict access to your databases

Your databases serve as the backbone of your applications. Your applications need to access them and sometimes administrators need to access them from workstations, to run queries or perform maintenance. How can you make sure that your databases can be accessed securely, without leaving vulnerabilities that attackers might use to gain access to your database?

In Azure SQL Databases, Azure Synapse Analytics, Azure Database for PostgreSQL and Azure Database for MySQL, you should make sure that firewalls are enabled. The firewall for these services is enabled by default and only let’s Azure services through and IP-addresses that you specify. This is a big restriction on who can access your database, which is a really good step towards securing your databases.

(Azure SQL Database Firewall)

Using the database firewall is a good idea, but is hard to manage in a production environment. In production, you ideally want the database to be completely shielded from the outside world, and be only accessible from the services that you want. You can do that by using Azure Private Link, which allows you to connect to various services in Azure via a private endpoint. A private endpoint is a private IP address within a specific VNet and Subnet. With Private Link, you could grant access to your web application and maybe to a Virtual Machine in the VNet, that you use to log into the database (using a tool like SQL Server Management Studio) and manage it.

The databases in Azure also support authentication through an Azure Active Directory (AAD) account. When you use an AAD account, instead of a database server specific account (like a SQL Server Authentication account), your database is more secure, because:

• An AAD account can authenticate identities on a database level, where a database server specific account grants access to the whole server and all its databases by default
• You can manage password policies and password rotation for an AAD account in a single place
• Authenticating with AAD accounts is secure by default. You can couple it to a Windows user you can enable Multi-Factor Authentication

The best practices to take away are:

• Enable database firewalls and maintain them strictly
• In production, shield databases from the outside world using Azure Private Link
• Use Azure Active Directory accounts for database access

#3. Restrict access to your VMS

If you are running applications in Azure Virtual Machines (VM), or if you use a VM for something else, like managing a database, you need to make sure that the VM is secure. Most people log into a VM using RDP or SSH, which requires you to open ports on the VM that expose it to attackers. What can you do to make your VMs more secure?

You should disable RDP/SSH Access to your VMs. When you create a VM in Azure, the RDP and SSH ports can be enabled in the creation wizard. Disable them as that minimizes the attack surface of your VM. Instead, you should deploy your VMs in a Virtual Network and use Azure Bastion to access them. Azure Bastion provides secure RDP and SSH connectivity to your VMS, without the need to open RDP or SSH ports on your VMS. When you use Azure Bastion, your VMs don’t need to have a public IP address, which means that attackers haven no chance of accessing the VM.

(Enable ports in the Azure VM creation wizard)

The best practices to take away are:

• Keep the RDP and SSH ports of your VMs disabled
• Use Azure Bastion to connect to your VMs

#4. Protect your application secrets

You applications store secrets, like API keys and connection keys, to connect to other services, like APIs and databases. It is not a good idea to store these secrets in application code, as the keys would be available for everybody who has access to the code. Instead, application secrets should be stored in a secure place, that is meant for storing secrets.

In Azure, you should store your application secrets, keys and certificates in Azure Key Vault. Azure Key Vault is a secure service that your applications can connect to, in order to retrieve secrets. In addition to storing your secrets safely, you can let your secrets be managed by the people that should manage them (not by developers). For instance, a DevOps engineer can manage a connection string to a database in Azure Key Vault. Only that engineer handles the secret and anybody else that works on the application or infrastructure doesn’t know the secret. This is a secure way of working.

If secrets are stored in Azure Key Vault and your applications retrieve these secrets, how do your applications connect to Azure Key Vault? Your applications run in services like Azure Web Apps, which support Managed Service Identities. These are identities that live in Azure Active Directory. Using these, your Web Apps can be granted access to Azure Key Vault without using connection strings or API keys.

(Azure Key Vault secret)

The best practices to take away are:

• Store application secrets in a central place, like Azure Key Vault
• Use a built-in mechanism, like Managed Service Identities, to connect to Azure Key Vault

#5. Use a separate Azure Subscription for production

You might have many different environment that you use to develop and test your applications. These environments might be separated into different Azure Resource Groups to make it clear which service belongs to which environment. You could use this mechanism to secure access to your services, as you can apply Role-based Access Control (RBAC) to Resource Groups. Using RBAC, you can grant rights to certain people, to be able to manage services in certain resource groups. This works well and is recommended for development and test environments.

For production environments, the best practice is to create a separate Azure subscription. This helps you keep your production data and other assets out of your dev/test environments. You can also easily apply two different sets of policies across the resources in the two subscriptions. If your setup is complicated and contains many services, possibly spread out over multiple geographic locations and serving different purposes, you might want to consider creating an Azure Management Group structure that can have multiple subscriptions and policies for the production environment.

The best practices to take away are:

• Always apply Role-based Access Control to control who can access which Azure resources
• Separate production resources from non-production resources

#6. Implement a Web Application Firewall (WAF)

When your applications are exposed to the internet, they will be attacked. Common attacks that you face are SQL injection attacks and cross site scripting attacks and there are many more.

You can protect your web applications from attacks by implementing a Web Application Firewall (WAF). In Azure, You can enable the WAF feature of Azure Front Door, which is a service that you put in front of your web applications and it acts as a gateway to your applications, allowing you to set routing rules and filter traffic. You can also enable the WAF feature of Azure Application Gateway, which is a similar service to Azure Front Door, but operates on a different network layer and has different features. The WAF protects you against all sorts of attacks, including those from the Open Web Application Security Project (OWASP) core rule sets.

You can customize the behavior of the WAF by selecting the attack that it needs to protect against and telling it what to do when you get attacked. You can block an attack, forward it to somewhere else, log it, and more. You can also add more rules and restrict IP addresses that are allowed to access your web applications or limit the amount of traffic from certain IP addresses.

(Azure WAF policies)

The best practices to take away are:

• Implement a gateway service, like Azure Application Gateway or Azure Front Door, in front of your web applications
• Enable the Web Application Firewall feature to protect you against attacks

#7. Use Azure Security Center to monitor and improve security and act on security events

If there is only one best practice that you adopt from this post, it should be this one. Use Azure Security Center. This is an Azure service that you can use for free, or in a paid tier, that tells you what your security state is, what you can improve and how to do that. You can use Azure Security Center to periodically check the security of your resources and to be alerted when something needs your attention. Security Center helps you to implement security best practices by telling you where they need to be implemented and allows you to directly implement them from the Security Center.

(Azure Security Center)

The best practice to take away is:

• Use Azure Security Center

#Conclusion

Security is a complex topic. There are many things that you should do to optimize your security and maintain it. Learn more about Azure security best practices here and make sure to use the Azure Security Center to implement the best practices in your Azure subscription. Stay safe!

-Source : AzureTipsAndTricks