© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021
K. OtsAzure Security Handbookhttps://doi.org/10.1007/978-1-4842-7292-3_5

5. Workload Protection – Data

Karl Ots1  
(1)
Zürich, Zürich, Switzerland
 

In this chapter, we discuss hardening of data workloads. After reading this chapter, you will be able select and implement appropriate controls for securing data workloads as part of your organization’s security policy framework.

I have selected Azure Key Vault, Azure Blob storage, and Azure SQL database as the services covered in this chapter. There are, of course, a plethora of other Azure services that support your data workloads available, such as Azure CosmosDB, Databricks, and HDInsights. Based on my experience working with enterprise organizations, the services I have selected are relevant to the broadest set of Azure users. If the data service you are looking for is not covered, you should be able to apply the core monitoring, networking, and access controls presented in this chapter for your needs.

Azure Key Vault

Azure Key Vault is an Azure-native service for storing and managing secrets, certificates, and cryptographic keys. Logically, Azure Key Vault is natively linked to the Azure Active Directory of your Azure subscription. Physically, Azure Key Vault instances are deployed to shared pools of hardware security modules (HSM) in Azure regions. For additional compliance needs, you may also use managed HSM and dedicated HSM offering of Azure Key Vault, which provides the same set of core functionality and controls, while providing you with additional isolation.

Several Azure resources integrate natively with Azure Key Vault using managed identities for Azure resources for authentication. For example, Azure App Service can consume certificate data from Azure Key Vault. Data services that support Bring Your Own Key (BYOK) encryption use Azure Key Vault to hold the cryptographic keys by default.

Access Control

Access to Azure Key Vault is authenticated using Azure Active Directory. This limits the potential access to users and security principles which are either native to your Azure Active Directory or invited as Azure Active Directory Guests. Effectively, Azure Key Vault is as secure as your Azure Active Directory.

Azure Key Vault authorization is performed using two alternative permission models: access policies (classic) or Azure data-plane role-based access control (modern). The permission models are not cross-compatible, meaning that your Azure Key Vault can only use one of the permission models. For any new Azure Key Vaults, you should use the data-plane role-based access control model.

In both permission models, management-plane access is granted using Azure role-based access control. A Contributor for an Azure Key Vault resource can switch between the permission models by editing the properties.enableRbacAuthorization property. Once in access policy mode, a Contributor can create, read, update, and delete access policies.

Note

Contributor can switch between permission models and, by extension, manage access to the data stored in Azure Key Vault.

In the access policy permission model, the access scope is the entire Key Vault resource. An access policy is simply a combination of allowed operations, combined with the Azure Active Directory principal. There are 40 Key Vault operations configurable in access policies: 16 key permissions, 8 secret permissions, and 16 certificate permissions. There are also access policy templates available, which you can use to standardize authorization. As the scope of the access policy is the entire Key Vault resource, you cannot grant granular access two individual secrets, keys, or certificates. As such, it is not considered a best practice to share Key Vault resources across applications.

In the Azure data-plane role-based access control, you can grant access within a more granular scope. Specifically, keys, secrets, and certificates are considered sub-resources and can be used as a scope for role-based access control assignments. There are built-in roles available, which you can assign either to the Key Vault resource or any of its sub-resource scope:
  • Key Vault Administrator: Perform all data-plane operations on a key vault and all objects in it, including certificates, keys, and secrets. Cannot manage Key Vault resources or manage role assignments.

  • Key Vault Reader: Read metadata of Key Vaults and its certificates, keys, and secrets. Cannot read sensitive values such as secret contents or key material.

  • Key Vault Contributor: Management-plane operations only. It does not allow access to keys, secrets, or certificates.

  • Key Vault Secrets Officer: Perform any action on the secrets of a key vault, except manage permissions.

  • Key Vault Secrets User: Read secret contents.

  • Key Vault Certificates Officer: Perform any action on the certificates of a key vault, except manage permissions.

  • Key Vault Crypto Officer: Perform any action on the keys of a key vault, except managing permissions.

  • Key Vault Crypto User: Perform cryptographic operations using keys.

Network

Network access to the data plane of Azure Key Vault is by default unrestricted: authorized applications and users can access the Key Vault resource from any network location allowed within your Azure Active Directory Conditional Access. To set up network controls, you need to enable the Key Vault Firewall.

The least restrictive mode for the Key Vault Firewall is the Allow Trusted Microsoft Services to bypass this firewall option. This denies public network access and allows it from most multitenant Microsoft services. The list of trusted services includes, but is not limited to, Azure App Service, Azure SQL database, and Azure storage. To verify whether your target service is included, consult the documentation.1 If the multitenant Azure service you are using is not included in the list, such as Azure DevOps agent pools, you need to configure the Key Vault Firewall with network allow lists.

Azure Key Vault Firewall’s network allow lists support both public IPv4 address ranges and Azure virtual networks. Additionally, you can control access to your Key Vault using private endpoints.

Note

Azure Key Vault Firewall rules apply to any data-plane operations, including access from the Azure Portal.

Logging

Azure Key Vault provides security logs for management and data planes. Management-plane, or platform, logs are created within Azure activity log. These logs include
  • Firewall configuration changes (properties.networkAcls)

  • Permission model changes (properties.enableRbacAuthorization)

  • Role-based access control changes (roleAssignments/write)

  • Access policy changes (properties.accessPolicies)

Azure Key Vault does not keep data-plane logs by default. To enable data-plane logging, you need to configure AuditEvent resource logs (under diagnostic settings) to be sent to your centralized log store. These logs include create, read, update, and delete (CRUD) operations to the Key Vault data plane. These logs include
  • Operation name

  • Caller IP address

  • Caller identity

Additionally, Azure Defender for Key Vault analyzes data-plane logs and creates Security Center alerts for anomalies. These alerts include
  • Unusual application accessed a key vault.

  • Suspicious policy change and secret query in a key vault.

  • Unusual operation pattern in a key vault.

Best Practices

To enforce proper operational best practices, you should ensure that keys, secrets, and certificates stored in Azure Key Vault are properly rotated. You can do this natively by configuring versions and expirations or any content you store in the Key Vault. You can also create custom workflows for advanced scenarios by subscribing to Azure Event Grid events from Azure Key Vault.2

To mitigate the risk of lost keys and user error, you can enable the soft delete and purge protection features. This keeps your deleted data recoverable for up to 90 days.

Azure Blob Storage

Azure Blob storage is an object storage service, built for storing unstructured data such as binary files. As one of the first platform-as-a-service components released in Microsoft Azure, Blob storage is a core component for most applications built natively for the cloud.

A variant of Azure Blob storage, Azure Data Lake Storage Gen 2, supports a hierarchical namespace filesystem. This makes Azure Data Lake Storage Gen 2 optimal for analytics workloads. Azure Data Lake Storage Gen 2 supports most of the security features of Azure Blob storage.3

Access Control

Access to Azure Blob storage is controlled using Azure Active Directory or shared keys (sometimes called Storage Account keys). Whenever possible, you should use Azure Active Directory-based authentication. If you are dealing with legacy workloads or third-party solutions, you might need to revert to using shared keys.

Public read-only access is often required for workloads serving web application content in Blob storage. Users with sufficient privileges (or using shared keys) can enable public access per blob item or container level.

Data-Plane Role-Based Access Control

You should manage access to the data plane of Azure storage account using data-plane role-based access control roles. The available built-in roles are available for you to assign in an account or container scope:
  • Storage Blob Data Owner: Used to manage POSIX access control for Azure Data Lake Storage Gen 2

  • Storage Blob Data Contributor: Used to grant read/write/delete permissions to Blob storage resources

  • Storage Blob Data Reader: Used to grant read-only permissions to Blob storage resources

  • Storage Blob Delegator: Used to create a shared access signature that is signed with Azure AD credentials for a container or blob

Shared Key Access

Shared keys, sometimes referenced to as account keys, are the oldest way of authorizing access to Azure Blob storage. With shared keys, a user gets full control to the storage account. This access allows for create, read, update, and delete operations for any data stored within the Blob storage account. Additionally, shared case also allows to change any access control settings, such as setting a blob as publicly available. It only takes the name of the storage account and the shared key to gain full access to the storage account.

Any user that has access to the Microsoft.Storage/storageAccounts/listkeys/action operation in your storage account can use the shared key. The built-in Contributor role is an example of a typical role that has this access.

Note

Contributor role has access to read and regenerate shared keys. By extension, Contributor can manage access to the data stored in Azure Blob storage.

You should avoid using shared key authorization whenever possible. If you are sure you are not using shared key authorization, you can configure the AllowSharedKeyAccess property in your storage account resource to prevent its usage altogether. This property forces Azure Active Directory authorization for the storage account. Crucially, this property is something a Contributor can change!

If you need to use shared keys, you should rotate the keys periodically. You can set your own key rotation policies by using the Storage Account Key Operator Service Role or automate the key rotation using the az keyvault storage command.4

Delegated Access

Some scenarios require you to share the content of your Blob storage to external users while still applying granular access control. For example, a media bank application could allow public access for sample content but would require additional controls for paid content. This is where user delegation shared access signature (SAS) comes in.5

In this model, you control access via a shared access signature token, which is a key that provides restricted access to data in your storage account. Together with a URI to a file in your Blob storage, anyone using the SAS can access your data.

Azure Active Directory identity is used to sign the SAS, effectively delegating the identity’s permissions to the holder of the SAS key. You can limit the effective permissions even further by setting granular permissions to storage account, container, or blob level using SAS parameters. Table 5-1 describes the available options for limiting the permissions using SAS parameters. Notably, access can be limited for a certain time period and even with network controls.

Prior to the introduction of the user delegation model, SAS keys were created and signed using shared keys. This is still possible for backward compatibility purposes. However, its usage should be avoided. The delegated permissions used for creating SAS keys with shared keys would effectively be the root access, potentially exposing your storage accounts.

Anonymous Access

You might have business requirements to expose data in your Blob storage account to anonymous users. By default, containers and blobs can be set publicly accessible by an administrator (or the holder of a shared key). The available public access levels per container are
  • No public read access for container or blobs (default setting)

  • Public read access for blobs only

  • Public read access for container and its blobs

You can prevent this by enforcing the AllowBlobPublicAccess property. When the property is set to false, anonymous access is not allowed, regardless of the public access level.

Note

You can prevent public anonymous access by setting the AllowBlobPublicAccess property to false!

Table 5-1.

SAS permissions

Permission

Allowed operations

Read

Read the content, block list, properties, and metadata of any blob in the container or directory

Create

Write a new blob, snapshot a blob, or copy a blob to a new blob

Write

Create or write content, properties, metadata, or block list. Snapshot or lease the blob

Delete

Delete a blob

List

List blobs

Move

Move a blob or a directory and its contents to a new location

signedIp

Specifies an IP address or a range of IP addresses from which to accept requests

signedProtocol

The protocol permitted for a request made with the SAS. Possible values are HTTPS+HTTP (default) or HTTPS

signedKeyStartTime

The start of the lifetime of the user delegation key

signedKeyExpiryTime

The end of the lifetime of the user delegation key

Network

Network access to Azure Blob storage is notoriously unprotected by default. To protect your Blob storage, you can set multiple controls in place.

First, you can limit public anonymous access by configuring the AllowBlobPublicAccess property. We discussed anonymous access in the previous section. To continue sharing access to blobs after enabling the property, you can use SAS tokens, which you can further control by configuring allowed IP addresses in the signedIp field.

Next, you can enforce your connections are always encrypted in transit, by setting the supportsHttpsTrafficOnly to true and minimumTlsVersion to the newest TLS version.

And finally, you can enable the Azure Blob storage firewall. This changes the value of default action within network rule set from allow to deny. After enabling the firewall, you need to specify allowed network locations with network allow lists. The network allow lists support both public IPv4 address ranges and Azure virtual networks. Additionally, you can control access to your Blob storage using private endpoints. This eliminates exposure to public networks and helps you prevent data exfiltration.

Logging

Azure Blob storage provides security logs for management and data planes. Management-plane, or platform, logs are created within Azure activity log. These logs include
  • Network control configuration changes (networkAcls, supportsHttpsTrafficOnly and allowBlobPublicAccess)

  • Role-based access control changes (roleAssignments/write)

  • Shared key usage (listKeys operation used to get the shared keys)

Azure Blob storage does not keep data-plane logs by default. To enable data-plane logging, you need to configure StorageRead, StorageWrite, and StorageDelete categories of resource logs (under diagnostic settings) to be sent to your centralized log store. The log schema includes
  • REST operation and HTTP status.

  • Caller IP address and port.

  • Caller identity: OAuth, Kerberos, SAS Key, Account Key, or Anonymous. In case of OAuth or Kerberos, further details of the requestor identity are stored.6

Additionally, you can use Azure Defender to analyze data-plane logs and create Security Center alerts in case of anomalies. For Azure Blob storage, these alerts include7
  • Access from a suspicious IP address.

  • Anonymous scan of public storage containers.

  • Potential malware uploaded to a storage account. This alert is based on hash reputation analysis.

Backup and Disaster Recovery

Azure Blob storage helps you protect the availability of your data in two ways. First, you control data availability by selecting a redundancy type for your storage account, as listed in Table 5-2.
Table 5-2.

Storage redundancy options

Tier

Number of copies

Durability

LRS: locally redundant storage

3 copies on separate nodes within a region

99.999999999% (11 9’s)

ZRS: zone-redundant storage

3 copies across separate availability zones within a region

99.9999999999% (12 9’s)

GRS: geo-redundant storage

6 copies: 3 in the primary region and 3 in the secondary region

99.99999999999999% (16 9’s)

GZRS: geo-zone-redundant storage

6 copies, 3 across separate availability zones in the primary region and 3 locally redundant copies in the secondary region

99.99999999999999% (16 9’s)

And second, you can enable soft delete and point-in-time restore to protect the data in your Blob storage against accidental deletion, corruption, or ransomware attacks.

Note

Selecting a redundancy tier is not a substitute for backups. You are always responsible for adding sufficient backup and disaster recovery controls for your application needs.

Best Practices

While the data stored in Blob storage is always encrypted with Microsoft-managed keys (MMK) using AES 256-bit encryption, your organization might have requirements to control the key length, operations, or storage. To do that, you need to specify the storage account encryption type as customer-managed keys (CMK). Customer-managed keys can be stored either in Azure Key Vault or Azure Key Vault managed hardware security module (HSM). Using customer-managed keys, Azure Storage supports RSA and RSA-HSM encryption keys of sizes 2048, 3072, and 4096.8

To support multitenancy or isolation requirements, you can encrypt different encryption scopes in your storage account using multiple keys. For example, you can use Microsoft-managed keys to encrypt most of the storage account, but encrypt an individual container or blob using your own encryption key. Azure supports up to 10 000 of these encryption scopes per storage account.9

As an operational-based practice, you should limit access to the list storage account keys operation to a minimum. If you are not able to prevent it altogether, you should closely monitor usage of this operation with custom activity log alerts.

While Azure Defender alerts you for malware based on hash comparison, Azure does not have built-in support for anti-malware scanning of Blob storage files. To implement your own logic for scanning uploaded files, you can look at Azure Event Grid. Your scanning workflow should start when Microsoft.Storage.BlobCreated event is triggered.

Exercise

Your organization is about to launch the next-generation product. As part of the launch campaign, you are asked to secure the storage account that stores the marketing images for the campaign website and product datasheets, available for interested customers after signing up. How would you configure the network and access controls of the storage account?

Bonus Exercise

A week before the public launch, you receive a new requirement. You would need to provide early access to product data sheets to an internal test group. What would you need to change in the storage account configuration to grant the access securely?

Azure SQL Database

Azure SQL database is another key data service in Microsoft Azure. Azure SQL database is a managed relational database as a service, based on Microsoft SQL Server engine. Like Blob storage, Azure SQL database has been available from the very beginning. This means that the service is mature and supports most of the Azure security controls. However, given its history, you might find that some of the controls are implemented differently than in newer services, such as Azure Key Vault.

There are variants of Azure SQL database in terms of database technology and tenancy. In this book, we are focusing on the multitenant SQL database and leaving Azure SQL Managed Instance out of the conversation. Similarly, we will not be discussing security controls for Azure database for MySQL, PostgreSQL, or MariaDB. Finally, some key controls such as Azure Active Directory authentication are also available in Azure Synapse Analytics (formerly known as Azure SQL DataWarehouse). Microsoft documentation pages usually clearly indicate any differences between Azure Database versions.

Access Control

Authentication to Azure SQL database is controlled by either of the two authentication methods: Azure Active Directory authentication or SQL authentication. Whenever possible, you should use Azure Active Directory authentication.

SQL Authentication

As a best practice, avoid using SQL authentication whenever possible and use Azure AD as a centrally managed identity provider instead. Similar to Blob storage shared keys, a Contributor can reset the logical server admin login credentials.

You can prevent the usage of SQL authentication by setting the logical server’s azureADOnlyAuthentications property to true. This property enables Azure AD authentication only mode and disables SQL authentication in the server level. Effectively, no SQL login can connect to your Azure SQL database after setting the Azure AD only mode.

Azure AD Authentication

You should use Azure Active Directory authentication to manage identities of your database users in a central location. This reduces the operational responsibilities of your application team: they do not need to worry about password rotation policies or storing passwords themselves. When using Azure Active Directory authentication, your users also benefit from all that security trades of your Azure Active Directory, such as conditional access and multifactor authentication.

Azure Active Directory authentication is configured in the logical server as an Azure AD group assignment. There is a lower and upper limit of one assignment for the logical server Administrator role. Further role assignments should be granted in the data plane: in the database using Transact-SQL statements. Listing 5-1 illustrates how the database users can be created from the native Azure Active Directory.
CREATE USER [alice@contoso.com] FROM EXTERNAL PROVIDER;
CREATE USER [FINANCE-ADMINS] FROM EXTERNAL PROVIDER;
CREATE USER [financewebappmsi] FROM EXTERNAL PROVIDER;
Listing 5-1.

Assignments of an AAD user, an AAD group, and a managed identity to the database.

Authorization

Once your users are successfully authenticated using Azure AD, authorization to data and operations within Azure SQL database should be done using standard database roles with principle of least privilege in mind. You can further limit access with role-level security.10 As of the writing of this book, there are no data-plane role-based access control roles available that would map Azure RBAC assignments to database authorization.

Control-Plane Role-Based Access Control Roles

While there are no data-plane RBAC roles available for Azure SQL database, there are some management-plane RBAC roles which can be useful for you. The built-in roles for Azure SQL database are
  • SQL DB contributor: Used to manage SQL databases, but not access to them. Excludes configuration of security-related policies

  • SQL server contributor: Used to manage SQL logical servers and databases, but not access to them. Excludes configuration of security-related policies

  • SQL security manager: Used to manage the security-related policies of SQL servers and databases, but not access to them

Network

To protect network access to your SQL database, you can set multiple controls in place.

First, you can enforce your connections are always encrypted in transit, by setting the minimalTlsVersion to the newest TLS version.

Next, you can enable the logical server firewall. This changes publicNetworkAccess allow to deny. After enabling the firewall, you need to specify allowed network locations with firewallRules and virtualNetworkRules. Additionally, you can control access to your Azure SQL database logical server using private endpoints. This eliminates exposure to public networks and helps you prevent data exfiltration.

Finally, you can create IP firewall rules in the database level. This is done in the data plane, using Transact-SQL statements. If there are conflicts between the logical server and database firewall rules, the database firewall rules prevail. As a best practice, you should always use database-level firewall rules when you have more than one database in a logical server.

Figure 5-1 illustrates how firewall conflicts are handled. If an incoming request originates from an IP address that is part of the allowed database-level addresses, the request is accepted, regardless of the firewall settings of the logical server.
../images/508755_1_En_5_Chapter/508755_1_En_5_Fig1_HTML.jpg
Figure 5-1.

Azure SQL database’s firewall hierarchy

Logging

Azure SQL database does not keep data-plane audit logs by default. To enable audit logging, you need to configure the auditingSettings property to store the logs to your centralized log store. Azure SQL database auditing tracks database events and writes them into an audit log. As a best practice, you should set this only in the server level. If you need additional logs to be created with different settings per database, you can enable these per database, too. The audit log fields include11
  • Name of the action, such as INSERT

  • Source IP of the client application and service principal information of the login

  • T-SQL statement that was executed

  • Information type and sensitivity label of the data queried

Note

When you use Azure AD authentication, failed login records will not appear in the SQL audit log, but rather in the Azure AD sign-in logs!

Additionally, you can use Azure Defender to analyze data-plane logs and create Security Center alerts. For Azure SQL database, these alerts include12
  • Login from a suspicious IP

  • A possible vulnerability to SQL injection due to a faulty SQL statement in your database

  • Potential SQL injection

  • Potential SQL brute-force attempt

Finally, Azure Defender includes recurring scanning against SQL vulnerability assessment rules,13 based on Microsoft best practices.

Backup and Disaster Recovery

As a managed PaaS service, Microsoft is responsible for most of the high availability implementation of Azure SQL database. Microsoft offers 99.99% availability service-level agreement (SLA) for Azure SQL database out of the box. If you choose business critical tier with zone-redundant deployments, you get availability SLA of 99.995%, recovery point objective of 5 seconds and recovery time objective of 30 seconds.

By default, Azure SQL database comes with a point-in-time restore feature, allowing you to restore the content of your entire database to its earlier state. The point-in-time restore timeframe is set to 7 days by default, so it is a good idea to change it to the maximum allowed 35 days. Your application team can restore the content in a self-service manner by replacing the current database or restoring the content to a new database – even in another geographic region.

To fulfill backup requirements that are over 35 days and up to 10 years, you need to configure the long-term backup retention feature, which leverages the full database backups that are created for the point-in-time restore (PITR) feature. The LTR policy for each database in SQL database can also specify how frequently the LTR backups are created (weekly, monthly, yearly).

Note

The BACKUP Transact-SQL statement is not available in Azure SQL database.

To protect your application from regional datacenter downtime, you can configure auto-failover groups, which configure the active geo-replication and failover logic for Azure SQL database. You can initiate failover to another region manually or you can automate it based on a policy you define (failoverWithDataLossGracePeriodMinutes).

Best Practices

While the data stored in Azure SQL database is always encrypted with Microsoft-managed keys (MMK) using AES 256-bit encryption, your organization might have requirements to control the key length, operations, or storage. To do that, you need to specify the storage account encryption type as customer-managed keys (CMK). Using customer-managed keys, Azure SQL database supports RSA encryption keys of sizes of up to 4096 bits.

Azure SQL database supports some data governance features, such as automatic data discovery and classification. If you are not already using a similar solution, you should evaluate the usage of these features.

Finally, Azure SQL database provides server-side data protection for sensitive data. This feature – dynamic data masking – obfuscates the query result data before sending it to the clients. You can customize it to recognize your existing sensitivity labels or configure the masking manually per column.

Summary

In this chapter, we looked at the controls available to you for protecting Azure data services. As we learned, they share many basic controls, such as Azure AD authentication support and the concept of an IP address and virtual network firewall. However, details such as data-plane RBAC support or the options for enforcing Azure AD authentication differ from service to service.

For all the data services we covered in this chapter, the built-in control-plane RBAC role Contributor should be considered as a privileged role.

Finally, even though available logging options differ vastly in each service, the support for tracking core control-plane actions in the activity log and support for Azure Defender alerts for the data-plane actions provide a consistent set of controls that you can enforce at scale.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset