When developing, deploying, or migrating IT assets into the cloud, what responsibilities fall on the cloud provider and what are yours to consider? Popular cloud providers like Amazon Web Services (AWS) and Microsoft Azure (Azure) provide security features within their services but often time their default configuration settings should be customized to your environment. It’s ultimately the responsibility of the business, not the cloud provider, to develop measures to secure the data, devices, accounts, and identities of its users.
To ensure the highest standard of security in the cloud, we recommend having technical domain experts properly establish a strong security strategy for how digital data is stored, processed and transmitted in your cloud environment. At Adelear, we possess industry-leading expertise in architecting secure AWS, Azure, and GCP environments that will allow your business to leverage secure and scalable platforms.
Azure
Microsoft Azure’s cloud services offer new standards with a secure development lifecycle at the center of its design. As a company, Microsoft recently became recognized as the first and only cloud platform to meet EU data protection authorities requirements for personal data protection. In this article, we’ll cover common default configuration settings in Azure, that if left alone, can lead to data loss, leakage, and other security incidents that can put your organization and its users’ data at risk.
1. Enable Multi-factor Authentication (MFA)
Multi-factor authentication (MFA) should be required for all privileged users who possess administrative, management, or write access to Azure resources. Additionally, when an unfamiliar device is accessed by a given user, MFA should be required prior to the device being added to Active Directory. This will ensure that bad actors cannot use compromised accounts to make lateral movements within an environment to access resources or make critical changes.
2. Secure Storage Accounts
Every object stored in Azure has an address with a unique account name for that data. It’s important to note that Azure’s default setting for storage accounts allows access from anywhere, including the internet which can expose data to the public. At Adelear, we recommend using least privilege to restrict access to each storage account only from the selected IP address, network range or Azure’s virtual network subnet.
3. Configure Encryption for Disks
Encryption at rest for operating system disks, data disks, and unconnected disks should be configured in every production environment, workstation, server, and cloud environment. Azure supports disk encryption for Windows using BitLocker and with Linux using DM-crypt.
4. Enhance DDoS protection for virtual networks
Compared with the basic version of Distributed Denial of Service (DDoS) protection, enhanced or “standard” DDoS protection protects against network based DDoS attacks. We recommend upgrading to Standard DDoS defense services for all VNets in each production environment.
5. Customize Alerting in Azure Monitor
We recommend customizing alerts based on the environment as well as the needs of the services deployed. Consider setting parameters for: Index value, Record search query, Activity log events, The operating status of the basic Azure platform, and Test website usability.
6. Network Security Group
A network security group contains security rules surrounding network traffic rights for several Azure resources. For each rule, you can specify source and destination, port, and protocol. When defining firewall rules, we recommend specifying as many parameters as possible in the rules and changing the protocol source from “any” to specific addresses and a defined source.
7. Public IP Address Configuration
We recommend configuring the public IP address as a standard SKU as opposed to a basic SKU, because of a variety of features including:
Regional Redundancy and Zoning – which replicates your applications and data across various Availability Zones. Availability Zones protect against single points of failure, offering maximal virtual machine uptime service level agreements. Uptime SLA guarantees 99.95% availability of the Kubernetes API server endpoint for clusters that use Availability Zones and 99.9% of availability for clusters that don’t use Availability Zones
Static IP is a unique online ID for secure, remote system access. A static IP address is an IP address that was manually configured for a device instead of one that was assigned by a DHCP server. It’s called static because it doesn’t change whereas a dynamic IP address, which does change.
For the basic SKU, the main security issue is overall openness. Unless specially protected by a firewall, by default, the system assigned the public IP address of the base SKU will be completely exposed to the outside world.
Needless to say, this is a taboo in any production environment. In a production environment, all public IP addresses should be configured as Standard SKUs, and their network traffic should be fully understood.
Please note that once the IP address is configured in either way, this setting cannot be changed. Therefore, solving this problem may require planning for downtime and migration time.
8. Dynamic IP address for public-facing services
This in itself is not a real security hole, but for any public-facing system, it is a serious misconfiguration.
If the IP address is dynamic, it means that it can be changed at any time, such as after a reboot or DHCP lease renewal. Moreover, when it appears on a publicly available system, it can destroy many things, such as:
This may cause unnecessary availability issues (such as DoS). Therefore, it is always strongly recommended to use static IP addresses for any public-facing services.
9. Blob storage with anonymous read access
Azure Blob storage is Microsoft’s object storage solution for the cloud. Blob storage is optimized for storing massive amounts of unstructured data and supports the following 3 access control options:
At Adelear we recommend setting the production environment to private to avoid data leakage.
10. Insecure guest user settings in Azure AD
Guest users in Azure Active Directory (AD) are designed as accounts created for vendors, contractors, partners, customers, and other temporary roles but can be granted the same access as typical user accounts. We recommend limiting the number of these temporary accounts, limit the privilege level, and delete the account once irrelevant. This will help prevent any network vulnerabilities being accessed or exposed via the guest account.
11. Unrestricted access to Azure AD management portal
The Azure AD management portal contains a lot of sensitive information. By default, any user under Azure AD can access it. This means that even standard users will have at least read only access, allowing them to view almost all settings, including but not limited to details of other users, group memberships, applications, etc. This is a major security risk and should therefore be restricted in line with least privilege policies.
12. Azure Identity Protection feature is disabled
Azure Identity Protection adds an extra layer of protection to user accounts in Active Directory. Intelligent behaviour and pattern analysis detects any anomalous user activity. It has the ability to prevent user account leakage, password injection attempts, and can identify and block anonymous or suspicious IP addresses.
13. Azure Network Watcher is disabled
Azure Network Watcher provides vital diagnostic and visualization tools for understanding and solving any network problems in your Azure infrastructure. This service also provides network flow analysis capabilities, allowing you to gain an in-depth insight, down to packet level, into your Network Security Group Azure firewalls.
This feature is disabled by default, and we recommended enabling this feature for all areas.
14. HTTPS is not enforced for all web application traffic
HTTPS is used for secure communication over a network. With HTTPS the communication protocol is encrypted using Transport Layer Security (TLS), and therefore protects against attackers attempting to monitor traffic, or tamper with the payload. For this reason, all internal and external (public) web applications hosted on Azure should require HTTPS connections.
TLS, formerly known as Secure Sockets Layer (SSL) is not just important for website communication, it should also be applied to any and all Azure services which offer the “Force SSL connection”, for example MySQL and Postgres servers.
When presented with a choice of which encryption standard to apply, the The National Institute of Standards and Technology (NIST) and and Payment Card Industry (PCI) compliance standards for cybersecurity recommend using TLS version 1.2
15. Monitoring strategy in Azure Security Center
The CIS benchmark recommends enabling the following monitoring strategies in Azure Security Center:
Calculations and applications
The internet
Data
All these policies should be enabled in every production environment. These strategies provide basic security monitoring of Azure cloud components. When enabling these policies, be sure to enable the setting for “Automatically set monitoring agents” to ensure that the monitoring agent is configured for all existing virtual machines and any new machines added in the future.
Conclusion
Like any other cloud provider, Microsoft Azure is no simple service. To set it up securely requires a huge effort, requires knowledge of multiple technical areas, and requires knowledge of the Azure ecosystem. At Adelear, we help organizations leverage the cloud through pre-configured solutions designed with enterprise-level security, performance, and resiliency. Our process enables organizations to leverage the scale and flexibility of public cloud providers, while also enjoying lower costs. Our comprehensive solutions help solve your cloud migration and development challenges while meeting the unique constraints of your mission. To learn more on our approach, contact us to set up a free strategy session/consultation at support@adelear.com.