Secure Data and Applications (part 1)

By Ashwin Venugopal -

 



To read part 2 please click here

Azure Key Vault

Azure Key Vault helps you to safeguard cryptographic keys as well as secrets that cloud applications and services use while using it to create multiple secure containers called vaults that help reduce the chances of accidental loss of security information by centralizing application secrets storage.Key vaults also control and log the access to anything stored in them. Azure Key Vault helps address the following issues:
  • Secrets management- You can use Azure Key Vault to securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets.
  • Key management- You can use Azure Key Vault as a key management solution, making it easier to create and control the encryption keys used to encrypt your data.
  • Certificate management- Azure Key Vault is also a service that lets you easily provision, manage, and deploy public as well as private SSL/TLS certificates for use with Azure and internal connected resources.
  • Store secrets backed by Hardware Security Modules (HSMs)- The secrets and keys can be protected either by software, or FIPS 140-2 Level 2 validates HSMs.  
Azure Key Vault is designed to support application keys and secrets. Key Vault is not intended as storage for user passwords.

Key Vault Access

Access to a key vault is controlled through two interfaces- the management plane, and the data plane. The management plane is where you can manage key vault itself and the operations in this plane includes creating and deleting key vaults, retrieving key vault properties, and updating access policies. Whereas, the data plane is where you work with the data stored in a key vault. You can add, delete, and modify keys, secrets, and certificates from here.
Both the planes uses Azure AD for authentication, but for authorization management plane uses RBAC, while the data planes uses a key vault access policy.

Active Directory Authentication

All callers in both the planes (management as well as data plane) must register in this tenant and authenticate to access the key vault. In both cases, applications can access Key Vault in two ways:

  • User plus application access- The application accesses Key Vault on behalf of a signed-in user. For example in Azure PowerShell and Azure portal, user access is granted in two ways- they can either access Key Vault from any application, or they must be specific application.

  • Application-only access- The application runs as a daemon service or background job and the application identity is granted access to the key vault.   

For both types of access, the application authenticates with Azure AD and uses any supported authentication method based on the application type. 

Benefits

The model of a single mechanism for authentication to both planes has several benefits:
  • Organizations can centrally control access to all key vaults in their organization.
  • If a user leaves, they instantly lose access to all key vaults in the organization.
  • Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security.

Key Vault Certificates

Key Vault certificate support provides for management of your x509 certificates and enables:
  • A certificate owner to create a certificate through a Key Vault creation process or through the import of an existing certificate. Includes both self-signed and CA-generated certificates.
  • A Key Vault certificate owner to implement secure storage and management of x509 certificates without interaction with private key material.
  • A certificate owner to create a policy that directs Key Vault to manage the life-cycle of a certificate. 
  • Certificate Owners to provide contact information for notification about life-cycle events of expiration and renewal of certificate.
  • Automatic renewal with selected issuers- Key Vault partner x509 certificate providers and CAs.  
When a Key Vault certificate is created, an addressable key and secret are also created with the same name. If a Key Vault certificate expires, it's addressable key and secret both become inoperable. 

Certificate Policy

A certificate policy contains the information on how to create and manage the Key Vault certificate life-cycle and when a Key Vault certificate is created from scratch, a policy needs to be supplied that can specify how to create the Key Vault certificate version, or the next Key Vault certificate version. There's only one instance of a policy for all the versions of a Key Vault certificate. At a high level, a certificate policy contains the following information:
  • x509 certificate properties which contains subject name, subject alternate names, and other properties used to create an x509 certificate request.
  • Key properties that contains key type, key length, exportable, and reuse key fields. These fields instructs Key Vault on how to generate a key.
  • Contains secret properties such as content type of addressable secret to generate the secret value, for retrieving certificate as a secret.
  • Contains lifetime actions for Key Vault certificate and each lifetime action contains- Trigger, which specifies via days before expiry or lifetime span percentage; and Action, which specifies the action type i.e. emailContacts, or autoRenew.
  • Contains the parameters about the certificate issuer to use to issue x509 certificates.
  • Contains the attributes associated with the policy.      

Certificate Issuer

Before you can create a certificate issuer in a Key Vault, the following two prerequisite steps must be completed successfully:
  1. Onboard to CA providers- An organization administrator must onboard their company with at least one CA provider.
  2. Admin creates requester credentials for Key Vault to enroll (and renew) SSL certificates- It provides the configuration to be used to create an issuer object of the provider in the Key Vault. 

Certificate Contacts

Certificate contacts contains contact information to send notifications triggered by the certificate lifetime events but if a certificate's policy is set to auto-renewal, then a notification is sent for the following events:
  • Before certificate renewal.
  • After certificate renewal, and stating if the certificate was successfully renewed, or if there was an error requiring manual renewal of the certificate
  • When its time to renew a certificate for a certificate policy that is set to manually renew (email only).

Certificate Access Control

The Key Vault that contains certificates manages access control for those same certificates and the following permissions closely mirror the operations allowed on a secret object, and can be used on a per-principle basis in the secrets access control entry on a Key Vault:

         Permissions for certificate management operations:
  • get: Get the current certificate version, or any version of a certificate.
  • list: List the current certificates, or versions of a certificate.
  • update: Update a certificate.
  • create: Create a Key Vault certificate.
  • import: Import certificate material into a Key Vault certificate.
  • delete: Delete a certificate, its policy, and all its versions.
  • recover: Recover a deleted certificate.
  • backup: Back up a certificate in a Key Vault.
  • restore: Restore a backed-up certificate to a Key Vault.
  • managecontacts: Manage Key Vault certificate contacts.
  • manageissuers: Manage Key Vault certificate authorities/issuers.
  • getissuers: Get a certificate's authorities/issuers.
  • listissuers: List a certificate's authorities/issuers.
  • setissuers: Create or update a Key Vault certificate's authorities/issuers.
  • deleteissuers: Delete a Key Vault certificate's authorities/issuers.
         Permissions for privileged operations:
  • purge: Purge (permanently delete) a deleted certificate.


To read part 2 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...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
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...
Read more