Not utilizing the built-in data security controls

Azure offers several essential security controls to protect data at rest and in transit. It is your responsibility to make sure these controls are enabled. Role-Based Access Control (RBAC) helps secure data by assigning authorized users and applications necessary privileges. Additionally, features like storage-side encryption and Azure Disk Encryption enhance data security. Since these features are not always enabled by default, they can be overlooked, particularly with older cloud resources.

Microsoft now defaults to enabling encryption on new cloud resources like storage accounts. However, it is necessary to verify that encryption is enabled, especially for older resources. Here are some guidelines to protect your data in Azure.

Make sure data is encrypted at rest:

Storage service encryption safeguards your data at rest by encrypting it as it’s written to Azure data centers and decrypting it when accessed. Follow the steps below to make sure Storage service encryption enabled.

Step 1. Go to Storage Accounts.
Step 2. For each storage account, go to Encryption under BLOB SERVICE.
Step 3. Ensure that Storage service encryption is set to Enabled.

Make sure data is encrypted in transit:

Enhance data security by allowing requests to storage accounts only over secure connections, rejecting any made over insecure transport. This applies to Azure File Services, and enabling this option will cause failures in scenarios using SMB 2.1, SMB 3.0 without encryption, and certain Linux SMB clients. Follow these steps to enforce encryption during data transit:

Step 1. Go to Storage Accounts.
Step 2. For each storage account, go to Configuration.
Step 3. Ensure that the Secure transfer required is set to Enabled.

Make sure SQL databases are encrypted:

Azure SQL Database Transparent Data Encryption (TDE) provides real-time encryption and decryption of databases, backups, and transaction logs at rest, protecting against malicious activities without requiring application changes. To ensure TDE is enabled, follow these steps.

Step 1. Go to SQL databases.
Step 2. For each DB instance, under Settings go to Transparent data encryption.
Step 3. Ensure that Data encryption is set to On.

Make sure “OS disks” and “data disks” are encrypted for VMs:

Encrypting the OS boot volume ensures its content is unreadable without a key, protecting against unauthorized access and safeguarding the machine’s configuration and stored credentials. To confirm the OS disk is encrypted, follow these steps.

Step 1. Go to Virtual machines.
Step 2. For each virtual machine, go to Settings.
Step 3. Click on Disks.
Step 4. Ensure that the OS disk has encryption set to Enabled.

Make sure storage blob containers are not public:

Azure Blob Storage can grant anonymous read-only access to data, but it’s recommended to avoid this unless necessary. Instead, use shared access signature tokens for controlled, timed access. To check if anonymous public access is enabled, follow these steps.

1. Go to Storage Accounts.
2. For each storage account, go to Containers under BLOB SERVICE.
3. For each container, click Access Policy.
4. Ensure that the Public access level is set to Private (no anonymous access).

Make sure storage keys are regenerated regularly:

Azure generates two storage access keys for authentication when creating a storage account. Regularly rotating these keys helps prevent unauthorized access. Follow these steps to check if keys have been rotated in the last 90 days.

1. Go to Storage Accounts.
2. For each storage account, go to the Activity log.
3. Under the Timespan drop-down, select Custom and choose Start time and End time, which ranges from 90 days.
4. Enter RegenerateKey is the Search text box.
5. Click Apply.

Make sure that Shared Access Signature (SAS) tokens expire on time:

A Shared Access Signature (SAS) is a URI that grants limited access to Azure Storage resources. It allows you to delegate access to certain resources without sharing your storage account keys, providing access to clients for a specific period. The SAS token’s validity period should be as short as possible, ideally within an hour, and it should only be allowed over HTTPS by enforcing it under Allowed protocols.