The following is from Azure Developer Training lab for AZ-203

Encryption

Encryption is the process of translating plain text data (plaintext) into something that appears to be random and meaningless (ciphertext). Decryption is the process of converting ciphertext back to plaintext. To encrypt more than a small amount of data,symmetric encryption is used. A symmetric key is used during both the encryption and the decryption process. To decrypt a particular piece of ciphertext, the key that was used to encrypt the data must be used.

The goal of every encryption algorithm is to make it as difficult as possible to decrypt the generated ciphertext without using the key. If a really good encryption algorithm is used, there is no technique significantly better than methodically trying every possible key. For such an algorithm, the longer the key, the more difficult it is to decrypt a piece of ciphertext without possessing the key. It is difficult to determine the quality of an encryption algorithm. Algorithms that look promising sometimes turn out to be very easy to break, given the proper attack. When selecting an encryption algorithm, it is a good idea to choose one that has been in use for several years and has successfully resisted all attacks.

Encryption at rest

Encryption at rest is the encoding (encryption) of data when it is persisted. It is a common security requirement that data that is persisted on disk be encrypted with a secret encryption key. Encryption at rest helps provide data protection for stored data (at rest).Attacks against data at rest include attempts to obtain physical access to the hardware on which the data is stored and to then compromise the contained data. In such an attack, a server’s hard drive may have been mishandled during maintenance, allowing an attacker to remove the hard drive. Later, the attacker puts the hard drive into a computer under their control to attempt to access the data.

Encryption at rest is designed to prevent the attacker from accessing the unencrypted data by ensuring that the data is encrypted when on disk. If an attacker were to obtain a hard drive with such encrypted data but no access to the encryption keys, the attacker would not compromise the data without great difficulty. In such a scenario, an attacker would have to attempt attacks against encrypted data, which are much more complex and resource consuming than accessing unencrypted data on a hard drive. For this reason, encryption at rest is highly recommended and is a high-priority requirement for many organizations.

Encryption at rest may also be required by an organization’s need for data governance and compliance efforts. Industry and government regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), PCI DSS, and Federal Risk andAuthorization Management Program (FedRAMP), lay out specific safeguards regarding data protection and encryption requirements. Encryption at rest is a mandatory measure required for compliance with some of those regulations. In addition to meeting compliance and regulatory requirements, encryption at rest should be perceived as a defense-in-depth platform capability.

In Microsoft Azure, organizations can achieve encryption at rest without having the cost of implementation and management and the risk of a custom key management solution. While Microsoft provides a compliant platform for services, applications, data, comprehensive facility and physical security enhancement, data access control, and auditing, it is important to provide additional, overlapping security measures in case one of the other security measures fails. Encryption at rest provides such an additional defense mechanism.

The encryption at rest designs in Azure use symmetric encryption to encrypt and decrypt large amounts of data quickly according to a simple conceptual model:

• A symmetric encryption key is used to encrypt data as it is written to storage.
• The same encryption key is used to decrypt that data as it is readied for use in memory.
• Data may be partitioned, and different keys may be used for each partition.
• Keys must be stored in a security-enhanced location with access control policies limiting access to certain identities and logging key usage. Data encryption keys are often encrypted with asymmetric encryption to further limit access.

Azure Storage encryption

All Azure Storage services (Blob storage, Queue storage, Table storage, and Azure Files) support server-side encryption at rest, with some services supporting customer-managed keys and client-side encryption. All Azure Storage services enable server-side encryption by default using service-managed keys, which is transparent to the application.

Storage Service Encryption is enabled for all new and existing storage accounts and cannot be disabled. Because your data is security enhanced by default, you don’t need to modify your code or applications to take advantage of Storage Service Encryption.

Azure SQL Database encryption

Azure SQL Database supports encryption at rest for Microsoft-managed server-side and client-side encryption scenarios. Support for server encryption is currently provided through the unified SQL feature called Transparent Data Encryption (TDE). Once anAzure SQL Database customer enables TDE, keys are automatically created and managed for them. Encryption at rest can be enabled at the database and server levels. TDE is enabled by default on newly created databases. Azure SQL Database also supportsRSA 2048-bit customer-managed keys in Azure Key Vault.

Azure Cosmos DB encryption

Cosmos DB stores its primary databases on solid-state drives (SSDs). Its media attachments and backups are stored in Azure Blob storage, which is generally backed up by hard disk drives (HDDs). Cosmos DB automatically encrypts all databases, media attachments and backups.

Encrypt data with Transparent Data Encryption (TDE)

You can take several precautions to help secure the database, such as designing a security-enhanced system, encrypting confidential assets, and building a firewall around the database servers. However, in a scenario where the physical media (such as drives or backup tapes) are stolen, a malicious party can just restore or attach the database and browse the data. One solution is to encrypt the sensitive data in the database and help to protect the keys that are used to encrypt the data with a certificate. This helps prevent anyone without the keys from using the data, but this kind of protection must be planned in advance.

TDE encrypts SQL Server, Azure SQL Database, and Azure SQL Data Warehouse data files. TDE performs real-time I/O encryption and decryption of the data and log files. The encryption of the database file is performed at the page level. The pages in an encrypted database are encrypted before they are written to disk and decrypted when read into memory. TDE does not increase the size of the encrypted database.

The encryption uses a database encryption key (DEK), which is stored in the database boot record for availability during recovery. The DEK is either a symmetric key secured by using a certificate stored in the master database of the server or an asymmetric key protected by an Extensible Key Management (EKM) module. TDE protects data at rest, meaning the data and log files. It provides the ability to comply with many laws, regulations, and guidelines established in various industries. This enables software developers to encrypt data by using the AES and 3DES encryption algorithms without changing existing applications.

Encrypt data with Always Encrypted

Always Encrypted is a new data encryption technology in Azure SQL Database and SQL Server that helps protect sensitive data at rest on the server, during movement between client and server, and while the data is in use, helping to ensure that sensitive data never appears as plaintext inside the database system.

Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (for example, United States social security numbers), stored in Azure SQL Database or SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the database engine ( SQL Database or SQL Server). As a result, Always Encrypted provides a separation between those who own the data (and can view it)and those who manage the data (but should have no access). After you encrypt the data, only client applications or app servers that have access to the keys can access the plaintext data.

By helping ensure that on-premises database administrators, cloud database operators, or other highly privileged but unauthorized users cannot access the encrypted data, Always Encrypted allows organizations to encrypt data at rest and in use for storage inAzure, to enable the delegation of on-premises database administration to third parties, or to reduce security clearance requirements for database administrators.

Note: Always Encrypted requires a specialized driver installed on the client computer to automatically encrypt and decrypt sensitive data in the client application. For many applications, this does require some code changes. This is in contrast to TDE, which only requires a change to the application’s connection string.

Azure confidential computing

Azure confidential computing refers to features available in many Azure services that encrypt data in use. Confidential computing is designed for scenarios where data needs to be processed in the cloud while still maintaining a level of encryption that helps protect the data from being viewed in a plaintext manner. Confidential computing is a collaborative project between hardware vendors like Intel and software vendors like Microsoft.

Confidential computing helps to ensure that when data is “in the clear,” which is required for efficient processing, the data is protected inside a Trusted Execution Environment (TEE). TEEs help to ensure that there is no way to view data or operations inside from the outside, even with a debugger. They also help to ensure that only authorized code is permitted to access data. If the code is altered or tampered with, the operations are denied and the environment disabled. The TEE enforces these protections throughout the execution of the code within it.

Note: In some online articles, TEEs are commonly referred to as enclaves.

The goal of confidential computing is to build a platform where developers can take advantage of both hardware and software TEEs without being required to change their code. TEEs are exposed in multiple ways:

• Hardware – Intel Xeon processors with Intel SGX technology are available for Azure Virtual Machines.
• Software – The Intel SGX software development kit (SDK) and third-party enclave APIs can be used with compute instances and Virtual Machines in Azure.
• Services – Many Azure services, such as Azure SQL Database, already execute code in TEEs.
• Frameworks – The Microsoft Research team has developer frameworks, such as the Confidential Consortium Blockchain Framework, to help jumpstart new projects that need to run in TEEs.

Azure Key Vault

You have passwords, connection strings, and other pieces of information that are needed to keep your applications working. You want to make sure that this information is available but that it is security enhanced. Azure Key Vault is a cloud service that works as asecurity-enhanced secrets store.

Key Vault allows you to create multiple security-enhanced containers, called vaults. These vaults are backed by hardware security modules (HSMs). Vaults help to reduce the chance of accidentally losing security information by centralizing the storage of application secrets. Vaults also control and log the access to anything stored in them. Azure Key Vault is designed to support any type of secret, such as a password, database credential, API key, or certificate. Software or HSMs can help to protect these secrets.Azure Key Vault can handle requesting and renewing TLS certificates, providing the features required for a robust certificate lifecycle management solution.

Key Vault streamlines the key management process and enables you to maintain control of keys that access and encrypt your data. Developers can create keys for development and testing in minutes and then seamlessly migrate them to production keys. Security administrators can grant (and revoke) permission to keys as needed.

Accessing Key Vault in Azure CLI

To create a vault using the Azure Command-Line Interface, you need to provide some information:

• A unique name. For this example, we will use contoso vault.
• A resource group. Here, we are using SecurityGroup.
• A location. We will use West US.

  az keyvault create --name contosovault --resource-group SecurityGroup --location westus

The output of this cmdlet shows properties of the newly created vault. Take note of the two properties listed below:

• Vault Name: In the example, this is contoso vault. You will use this name for other Key Vault commands.
• Vault URI: In the example, this is https://contosovault.vault.azure.net/. Applications that use your vault through its REST API must use this URI.

At this point, your Azure account is the only one authorized to perform any operations on this new vault.

To add a secret to the vault, you just need to take a couple of additional steps. This password could be used by an application. The password will be called DatabasePassword and will store the value of Pa5w.rd in it:

az keyvault secret set --vault-name contosovault --name DatabasePassword --value 'Pa5w.rd'

To view the value contained in the secret as plain text:

az keyvault secret show --vault-name contosovault --name DatabasePassword