Secure Data and Applications (part 2)

By Ashwin Venugopal -

 


To read part 1 please click here

Key Vault Keys

Cryptographic keys in Key Vault are represented as JSON Web Key (JWK) objects. There are two types of keys, depending on how they were created:
  • Soft Keys- They are the keys processed in software by Key Vault, but is encrypted at rest using a system key that is in a Hardware Security Module (HSM). 
  • Hard Keys- They are the keys processed in HSM and are protected in one of the Key Vault HSM Security Worlds (there's one security world per geography to maintain isolation).

Key Operations

Key Vault supports many operations on key objects, they are:
  • Create- It allows a client to create a key in Key Vault. The value of the key is generated by Key Vault and stored, not released to the client. Asymmetric keys can also be created in the Key Vault.

  • Import- It allows a client to import an existing key to the Key Vault. Asymmetric keys can also be imported to the Key Vault by using a number of different packaging methods within a JWK construct.

  • Update- It allows a client with sufficient permissions to modify the metadata (key attributes) associated with a key previously stored within the Key Vault.

  • Delete- It allows a client with sufficient permissions to delete a key from the Key Vault.

Cryptographic Operations

Once a key has been created in the Key Vault, the following cryptographic operations can be performed using the key:

  • Sign and Verify- This operation is strictly "sign hash" or "verify hash", as Key Vault doesn't support hashing of content as a part of signature creation. Verification of the signed hashes is supported as a convenience operation for the applications that may not have access to [public] key material.

  • Key Encryption/Wrapping- A key stored in the Key Vault may be used to protect another key, typically a symmetric Content Encryption Key (CEK). When the key in the Key Vault is symmetric, key wrapping is used but when it is asymmetric, key encryption is used.

  • Encrypt and Decrypt- A key stored in the Key Vault may be used to encrypt or decrypt a single block of data. The encrypt operation is provided for convenience, particularly for the applications that may not have access to [public] key material. 

Application Services Plan

Azure Key Vault provides the secrets management policies adopted by the various organizations (to store secrets centrally with expectations around expiration and access control), to your applications in Azure. But some applications can't easily take on code changes to start integrating with it, hence the Key Vault references are a way to introduce secrets management into your app without any code changes.

The app's system-assigned identity is used to securely fetch the secret and make it available to the app as an environment variable, which means that the teams can just easily replace the existing secrets stored in app settings with references to the same secret in the Key Vault, while the app will continue to operate normally.

Configure a Hardware Security Module (HSM) Key-generation Solution

For added assurance, whenever you use Azure Key Vault, you can always import or generate keys in HSMs that can never leave the HSM boundary, which is often referred to as Bring Your Own Key (BYOK). Azure Key Vault uses Thales nShield family of HSMs to protect your keys. (This functionality is not available for Azure China).

Generating and transferring an HSM-protected key over the Internet:  

  1. You generate the key from an offline workstation, which reduces the attack surface.
  2. The key is encrypted with a Key Exchange Key (KEK), which stays encrypted until it is transferred to the Azure Key Vault HSMs. Only the encrypted version of your key leaves the original workstation.
  3. The toolset sets the properties of your tenant key that binds your key to the Azure key Vault security world. This binding is enforced by the Thales HSMs.
  4. The KEK that encrypts your key is generated inside the Azure key Vault HSMs, and is not exportable. In addition, the toolset includes attestation from Thales that the KEK is not exportable and was generated inside a genuine HSM that was manufactured by Thales.
  5. The toolset also includes attestation that the Azure Key Vault security world was also generated on a genuine HSM manufactired by Thales.
  6. Microsoft uses separate KEKs and security worlds in each geographical region. This separation ensures that your key can be used only in data centers in the region in which you encrypted it.

 Customer Managed Keys

Once you have created your Key Vault and have populated it with keys and secrets, the next step is to set up a rotation strategy for the values you store as the Key Vault secrets. Secrets can be rotated in several ways:
  • As a part of manual process
  • Programmatically by using REST API calls
  • Through an Azure Automation script

Key Vault secrets

Key Vault offers a secure storage of secrets, such as passwords and database connection strings and its service doesn't provide semantics for secrets, it merely accepts the data, encrypts it, stores it, and returns a secret identifier ("id") that can be used to retrieve the secret at the later time.

It also supports the contentType field for secrets. Cients may specify the content type of a secret to assist in interpreting the secret data when it is retrieved. For instance, an implementation may store both the passwords and certificates as secrets, then use this field to differentiate. There are no predefined values. 


 

As shown above, the values for Key Vault Secrets are:
  • Name-value pair- Name must be unique in the Vault
  • Value can be any UTF-8 string- max of 25 KB in size
  • Manual or certificate creation
  • Activation date
  • Expiration date

 Azure Storage Account Key Management

Key Vault can manage Azure storage account keys:
  • Internally, Key Vault can list (sync) keys with an Azure storage account.
  • Key Vault regenerates (rotates) the keys periodically.
  • Key values are never returned in response to caller.
  • Key Vault manages the keys of both the storage accounts and classic storage accounts. 

Storage Account Access Control 

The following permissions can be used when authorizing a user or application principle to perform operations on a managed storage account:
Permissions for managed storage account and SaS-definition operations: 
  • get- Gets information about the storage account
  • list- List storage accounts managed by a Key Vault
  • update- Update a storage account
  • delete- Delete a storage account
  • recover- Recover a deleted storage account
  • backup- Backs up a storage account
  • restore- Restore a backed-up storage account to a Key Vault
  • set- Create or update a storage account
  • regeneratekey- Regenerate a specified key value for a storage account
  • getsas- Get information about a SaS definition for a storage account
  • listsas- List storage SaS definitions for a storage account
  • deletesas- Delete a SaS definition from a storage account
  •  setsas- Create or update a new SaS definition/attributes for a storage account
Permissions for privileged operations:
  • purge- Purge (permanently delete) a managed storage account

Key and Secret Rotation

Once you have keys and secrets stored in the Key Vault, it is very important to think about a rotation strategy. There are several ways to rotate the values:
  • As part of a manual process
  • Programmatically by using API calls
  • Through an Azure Automation script
The following diagram shows that how Event Grid and Logic Apps can be used to automate the process- 

  1. 30 days before expiration date of a secret, Key Vault publishes the "near expiry" event to Event Grid.
  2. Event Grid then checks the event subscriptions and uses HTTP POST to call the function app endpoint subscribed to the event.
  3. The function app receives secret information, and generates a new random password, as well as creates a new version for the secret with the new password in the Key Vault.
  4. Lastly, the function app updates SQL Server with the new password. 
Hence, you can easily rotate the values without any problem and ensure better security.


To read part 1 please click here






Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more