compliance controls are associated with this Policy definition 'SQL managed instances should use customer-managed keys to encrypt data at rest' (ac01ad65-10e5-46df-bdd9-6b0cad13e1d2)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| Azure_Security_Benchmark_v1.0 |
4.8 |
Azure_Security_Benchmark_v1.0_4.8 |
Azure Security Benchmark 4.8 |
Data Protection |
Encrypt sensitive information at rest |
Customer |
Use encryption at rest on all Azure resources. Microsoft recommends allowing Azure to manage your encryption keys, however there is the option for you to manage your own keys in some instances.
Understand encryption at rest in Azure:
https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest
How to configure customer managed encryption keys:
https://docs.microsoft.com/azure/storage/common/storage-encryption-keys-portal |
n/a |
link |
7 |
| Azure_Security_Benchmark_v2.0 |
DP-5 |
Azure_Security_Benchmark_v2.0_DP-5 |
Azure Security Benchmark DP-5 |
Data Protection |
Encrypt sensitive data at rest |
Shared |
To complement access controls, data at rest should be protected against ‘out of band’ attacks (such as accessing underlying storage) using encryption. This helps ensure that attackers cannot easily read or modify the data.
Azure provides encryption for data at rest by default. For highly sensitive data, you have options to implement additional encryption at rest on all Azure resources where available. Azure manages your encryption keys by default, but Azure provides options to manage your own keys (customer managed keys) for certain Azure services.
Understand encryption at rest in Azure: https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#encryption-at-rest-in-microsoft-cloud-services
How to configure customer managed encryption keys: https://docs.microsoft.com/azure/storage/common/storage-encryption-keys-portal
Encryption model and key management table: https://docs.microsoft.com/azure/security/fundamentals/encryption-models
Data at rest double encryption in Azure: https://docs.microsoft.com/azure/security/fundamentals/double-encryption#data-at-rest |
n/a |
link |
13 |
| Azure_Security_Benchmark_v3.0 |
DP-5 |
Azure_Security_Benchmark_v3.0_DP-5 |
Microsoft cloud security benchmark DP-5 |
Data Protection |
Use customer-managed key option in data at rest encryption when required |
Shared |
**Security Principle:**
If required for regulatory compliance, define the use case and service scope where customer-managed key option is needed. Enable and implement data at rest encryption using customer-managed key in services.
**Azure Guidance:**
Azure also provides encryption option using keys managed by yourself (customer-managed keys) for certain services. However, using customer-managed key option requires additional operational efforts to manage the key lifecycle. This may include encryption key generation, rotation, revoke and access control, etc.
**Implementation and additional context:**
Encryption model and key management table:
https://docs.microsoft.com/azure/security/fundamentals/encryption-models
Services that support encryption using customer-managed key: https://docs.microsoft.com/azure/security/fundamentals/encryption-models#supporting-services
How to configure customer managed encryption keys in Azure Storage: https://docs.microsoft.com/azure/storage/common/storage-encryption-keys-portal |
n/a |
link |
10 |
| CIS_Azure_1.1.0 |
4.10 |
CIS_Azure_1.1.0_4.10 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.10 |
4 Database Services |
Ensure SQL server's TDE protector is encrypted with BYOK (Use your own key) |
Shared |
The customer is responsible for implementing this recommendation. |
TDE with BYOK support provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties.
With TDE, data is encrypted at rest with a symmetric key (called the database encryption key) stored in the database or data warehouse distribution. To protect this data encryption key (DEK) in the past, only a certificate that the Azure SQL Service managed could be used. Now, with BYOK support for TDE, the DEK can be protected with an asymmetric key that is stored in the Key Vault. Key Vault is a highly available and scalable cloud-based key store which offers central key management, leverages FIPS 140-2 Level 2 validated hardware security modules (HSMs), and allows separation of management of keys and data, for additional security.
Based on business needs or criticality of data/databases hosted a SQL server, it is recommended that the TDE protector is encrypted by a key that is managed by the data owner (BYOK). |
link |
6 |
| CIS_Azure_1.3.0 |
4.5 |
CIS_Azure_1.3.0_4.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.5 |
4 Database Services |
Ensure SQL server's TDE protector is encrypted with Customer-managed key |
Shared |
The customer is responsible for implementing this recommendation. |
TDE with Customer-managed key support provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties.
With TDE, data is encrypted at rest with a symmetric key (called the database encryption key) stored in the database or data warehouse distribution. To protect this data encryption key (DEK) in the past, only a certificate that the Azure SQL Service managed could be used. Now, with Customer-managed key support for TDE, the DEK can be protected with an asymmetric key that is stored in the Key Vault. Key Vault is a highly available and scalable cloud-based key store which offers central key management, leverages FIPS 140-2 Level 2 validated hardware security modules (HSMs), and allows separation of management of keys and data, for additional security.
Based on business needs or criticality of data/databases hosted a SQL server, it is recommended that the TDE protector is encrypted by a key that is managed by the data owner (Customer-managed key). |
link |
6 |
| CIS_Azure_1.4.0 |
4.6 |
CIS_Azure_1.4.0_4.6 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.6 |
4 Database Services |
Ensure SQL server's TDE protector is encrypted with Customer-managed key |
Shared |
The customer is responsible for implementing this recommendation. |
TDE with Customer-managed key support provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties.
With TDE, data is encrypted at rest with a symmetric key (called the database encryption key) stored in the database or data warehouse distribution. To protect this data encryption key (DEK) in the past, only a certificate that the Azure SQL Service managed could be used. Now, with Customer-managed key support for TDE, the DEK can be protected with an asymmetric key that is stored in the Key Vault. Key Vault is a highly available and scalable cloud-based key store which offers central key management, leverages FIPS 140-2 Level 2 validated hardware security modules (HSMs), and allows separation of management of keys and data, for additional security.
Based on business needs or criticality of data/databases hosted a SQL server, it is recommended that the TDE protector is encrypted by a key that is managed by the data owner (Customer-managed key). |
link |
6 |
| CIS_Azure_2.0.0 |
4.1.3 |
CIS_Azure_2.0.0_4.1.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.1.3 |
4.1 |
Ensure SQL server's Transparent Data Encryption (TDE) protector is encrypted with Customer-managed key |
Shared |
Once TDE protector is encrypted with a Customer-managed key, it transfers entire responsibility of respective key management on to you, and hence you should be more careful about doing any operations on the particular key in order to keep data from corresponding SQL server and Databases hosted accessible.
When deploying Customer Managed Keys, it is prudent to ensure that you also deploy an automated toolset for managing these keys (this should include discovery and key rotation), and Keys should be stored in an HSM or hardware backed keystore, such as Azure Key Vault.
As far as toolsets go, check with your cryptographic key provider, as they may well provide one as an add-on to their service. |
Transparent Data Encryption (TDE) with Customer-managed key support provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties.
With TDE, data is encrypted at rest with a symmetric key (called the database encryption key) stored in the database or data warehouse distribution. To protect this data encryption key (DEK) in the past, only a certificate that the Azure SQL Service managed could be used. Now, with Customer-managed key support for TDE, the DEK can be protected with an asymmetric key that is stored in the Azure Key Vault. The Azure Key Vault is a highly available and scalable cloud-based key store which offers central key management, leverages FIPS 140-2 Level 2 validated hardware security modules (HSMs), and allows separation of management of keys and data for additional security.
Based on business needs or criticality of data/databases hosted on a SQL server, it is recommended that the TDE protector is encrypted by a key that is managed by the data owner (Customer-managed key).
Customer-managed key support for Transparent Data Encryption (TDE) allows user control of TDE encryption keys and restricts who can access them and when. Azure Key Vault, Azure’s cloud-based external key management system, is the first key management service where TDE has integrated support for Customer-managed keys. With Customer-managed key support, the database encryption key is protected by an asymmetric key stored in the Key Vault. The asymmetric key is set at the server level and inherited by all databases under that server. |
link |
6 |
| CMMC_2.0_L2 |
SC.L2-3.13.10 |
CMMC_2.0_L2_SC.L2-3.13.10 |
404 not found |
|
|
|
n/a |
n/a |
|
37 |
| CMMC_L3 |
SC.3.177 |
CMMC_L3_SC.3.177 |
CMMC L3 SC.3.177 |
System and Communications Protection |
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Cryptography can be employed to support many security solutions including the protection of controlled unclassified information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Cryptographic standards include FIPSvalidated cryptography and/or NSA-approved cryptography. |
link |
25 |
| FedRAMP_High_R4 |
SC-12 |
FedRAMP_High_R4_SC-12 |
FedRAMP High SC-12 |
System And Communications Protection |
Cryptographic Key Establishment And Management |
Shared |
n/a |
The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].
Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17.
References: NIST Special Publications 800-56, 800-57. |
link |
40 |
| FedRAMP_Moderate_R4 |
SC-12 |
FedRAMP_Moderate_R4_SC-12 |
FedRAMP Moderate SC-12 |
System And Communications Protection |
Cryptographic Key Establishment And Management |
Shared |
n/a |
The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].
Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17.
References: NIST Special Publications 800-56, 800-57. |
link |
40 |
| hipaa |
0304.09o3Organizational.1-09.o |
hipaa-0304.09o3Organizational.1-09.o |
0304.09o3Organizational.1-09.o |
03 Portable Media Security |
0304.09o3Organizational.1-09.o 09.07 Media Handling |
Shared |
n/a |
The organization restricts the use of writable removable media and personally-owned removable media in organizational systems. |
|
8 |
| New_Zealand_ISM |
23.4.9.C.01 |
New_Zealand_ISM_23.4.9.C.01 |
New_Zealand_ISM_23.4.9.C.01 |
23. Public Cloud Security |
23.4.9.C.01 Data protection mechanisms |
|
n/a |
For each cloud service, agencies MUST ensure that the mechanisms used to protect data meet agency requirements. |
|
17 |
| NIST_SP_800-171_R2_3 |
.13.10 |
NIST_SP_800-171_R2_3.13.10 |
NIST SP 800-171 R2 3.13.10 |
System and Communications Protection |
Establish and manage cryptographic keys for cryptography employed in organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Cryptographic key management and establishment can be performed using manual procedures or mechanisms supported by manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards specifying appropriate options, levels, and parameters. [SP 800-56A] and [SP 800-57-1] provide guidance on cryptographic key management and key establishment. |
link |
40 |
| NIST_SP_800-53_R4 |
SC-12 |
NIST_SP_800-53_R4_SC-12 |
NIST SP 800-53 Rev. 4 SC-12 |
System And Communications Protection |
Cryptographic Key Establishment And Management |
Shared |
n/a |
The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].
Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17.
References: NIST Special Publications 800-56, 800-57. |
link |
40 |
| NIST_SP_800-53_R5 |
SC-12 |
NIST_SP_800-53_R5_SC-12 |
NIST SP 800-53 Rev. 5 SC-12 |
System and Communications Protection |
Cryptographic Key Establishment and Management |
Shared |
n/a |
Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]. |
link |
40 |
| NL_BIO_Cloud_Theme |
U.05.2(2) |
NL_BIO_Cloud_Theme_U.05.2(2) |
NL_BIO_Cloud_Theme_U.05.2(2) |
U.05 Data protection |
Cryptographic measures |
|
n/a |
Data stored in the cloud service shall be protected to the latest state of the art with encryption and with a key length sufficient at least for the purpose, whereby the key management is not purchased as a cloud service if possible and is carried out by the CSC itself. |
|
52 |
| NL_BIO_Cloud_Theme |
U.11.3(2) |
NL_BIO_Cloud_Theme_U.11.3(2) |
NL_BIO_Cloud_Theme_U.11.3(2) |
U.11 Cryptoservices |
Encrypted |
|
n/a |
Sensitive data (on transport and at rest) is always encrypted, with private keys managed by the CSC. The use of a private key by the CSP is based on a controlled procedure and must be jointly agreed with the CSC organisation. |
|
52 |
| NZ_ISM_v3.5 |
CR-3 |
NZ_ISM_v3.5_CR-3 |
NZISM Security Benchmark CR-3 |
Cryptography |
17.1.53 Reducing storage and physical transfer requirements |
Customer |
n/a |
When encryption is applied to media or media residing within IT equipment it provides an additional layer of defence. Whilst such measures do not reduce or alter the classification of the information itself, physical storage, handling and transfer requirements may be reduced to those of a lesser classification for the media or equipment (but not the data itself). |
link |
12 |
| NZISM_Security_Benchmark_v1.1 |
CR-3 |
NZISM_Security_Benchmark_v1.1_CR-3 |
NZISM Security Benchmark CR-3 |
Cryptography |
17.1.46 Reducing storage and physical transfer requirements |
Customer |
If an agency wishes to use encryption to reduce the storage or physical transfer requirements for IT equipment or media that contains classified information, they SHOULD use:
full disk encryption; or
partial disk encryption where the access control will only allow writing to the encrypted partition holding the classified information. |
When encryption is applied to media or media residing within IT equipment it provides an additional layer of defence. Whilst such measures do not reduce or alter the classification of the information itself, physical storage, handling and transfer requirements may be reduced to those of a lesser classification for the media or equipment (but not the data itself). |
link |
11 |
| RBI_CSF_Banks_v2016 |
13.4 |
RBI_CSF_Banks_v2016_13.4 |
|
Advanced Real-Timethreat Defenceand Management |
Advanced Real-Timethreat Defenceand Management-13.4 |
|
n/a |
Consider implementingsecure web gateways with capability to deep scan network packets including secure (HTTPS, etc.) traffic passing through the web/internet gateway |
|
41 |
| RBI_CSF_Banks_v2016 |
21.1 |
RBI_CSF_Banks_v2016_21.1 |
|
Metrics |
Metrics-21.1 |
|
n/a |
Develop a comprehensive set of metrics that provide for prospective and
retrospective measures, like key performance indicators and key risk indicators |
|
15 |
| RMiT_v1.0 |
10.16 |
RMiT_v1.0_10.16 |
RMiT 10.16 |
Cryptography |
Cryptography - 10.16 |
Shared |
n/a |
A financial institution must establish a robust and resilient cryptography policy to promote the adoption of strong cryptographic controls for protection of important data and information. This policy, at a minimum, shall address requirements for:
(a) the adoption of industry standards for encryption algorithms, message authentication, hash functions, digital signatures and random number generation;
(b) the adoption of robust and secure processes in managing cryptographic key lifecycles which include generation, distribution, renewal, usage, storage, recovery, revocation and destruction;
(c) the periodic review, at least every three years, of existing cryptographic standards and algorithms in critical systems, external linked or transactional customer-facing applications to prevent exploitation of weakened algorithms or protocols; and
(d) the development and testing of compromise-recovery plans in the event of a cryptographic key compromise. This must set out the escalation process, procedures for keys regeneration, interim measures, changes to business-as-usual protocols and containment strategies or options to minimise the impact of a compromise. |
link |
10 |
| RMiT_v1.0 |
11.15 |
RMiT_v1.0_11.15 |
RMiT 11.15 |
Data Loss Prevention (DLP) |
Data Loss Prevention (DLP) - 11.15 |
Shared |
n/a |
A financial institution must design internal control procedures and implement appropriate technology in all applications and access points to enforce DLP policies and trigger any policy violations. The technology deployed must cover the following:
(a) data in-use - data being processed by IT resources;
(b) data in-motion - data being transmitted on the network; and
(c) data at-rest - data stored in storage mediums such as servers, backup media and databases. |
link |
14 |
| SO |
.3 - Customer-Managed Keys |
SO.3 - Customer-Managed Keys |
404 not found |
|
|
|
n/a |
n/a |
|
12 |
| SOC_2 |
CC6.1 |
SOC_2_CC6.1 |
SOC 2 Type 2 CC6.1 |
Logical and Physical Access Controls |
Logical access security software, infrastructure, and architectures |
Shared |
The customer is responsible for implementing this recommendation. |
The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion:
• Identifies and Manages the Inventory of Information Assets — The entity identifies,
Page 29
TSP
Ref. #
TRUST SERVICES CRITERIA AND POINTS OF FOCUS
inventories, classifies, and manages information assets.
• Restricts Logical Access — Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative
authorities, mobile devices, output, and offline system components is restricted
through the use of access control software and rule sets.
• Identifies and Authenticates Users — Persons, infrastructure, and software are
identified and authenticated prior to accessing information assets, whether locally
or remotely.
• Considers Network Segmentation — Network segmentation permits unrelated portions of the entity's information system to be isolated from each other.
• Manages Points of Access — Points of access by outside entities and the types of
data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified,
documented, and managed.
• Restricts Access to Information Assets — Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets.
• Manages Identification and Authentication — Identification and authentication requirements are established, documented, and managed for individuals and systems
accessing entity information, infrastructure, and software.
• Manages Credentials for Infrastructure and Software — New internal and external
infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point.
Credentials are removed and access is disabled when access is no longer required
or the infrastructure and software are no longer in use.
• Uses Encryption to Protect Data — The entity uses encryption to supplement other
measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk.
• Protects Encryption Keys — Processes are in place to protect encryption keys during generation, storage, use, and destruction |
|
78 |
|
U.05.2 - Cryptographic measures |
U.05.2 - Cryptographic measures |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
|
U.11.3 - Encrypted |
U.11.3 - Encrypted |
404 not found |
|
|
|
n/a |
n/a |
|
51 |