Exam Ref AZ-500 Microsoft Azure Security Technologies - Yuri Diogenes & Orin Thomas - 2021 - Microsoft Press - Copy-501-600

Updating Encryption Keys for Storage Accounts

• To update the encryption key for a storage account:
  1. Select the More button next to the encryption scope you want to update.
  2. On the Edit Encryption Scope page, change the Encryption Type.
  3. Click Save.

Advanced Threat Protection (ATP) for Azure Storage

• Purpose: Detects unusual and malicious attempts to interact with Azure Storage accounts.
• Functionality:
  • Enables security alerts when anomalous storage account activity is detected.
  • Detections are based on recognized patterns of malicious activity identified by Microsoft security researchers.
  • Alerts are integrated with Azure Security Center.
  • Alerts can be forwarded by email to subscription administrators.
• Alert Information:
  • Nature of the anomaly
  • Storage account name
  • Event time
  • Storage type
  • Probable causes
  • Investigation steps
  • Remediation steps
• Availability:
  • Available for Blob Storage, Azure Files, and Azure Data Lake Storage Gen2.
  • Supported by General-Purpose V2, block blob, and Blob Storage accounts.

Account or User Delegation SAS

• Always an ad-hoc SAS.
• Cannot use stored access policies for the account or user delegation SAS types.

Securing Azure SQL Database Instances

Database Authentication

• When creating an Azure SQL database server instance:
  • Create an administrator login.
  • Create a password associated with that login.
  • The administrative account is granted full administrative permissions on all databases hosted off the Azure SQL instance as a server-level principal.
• The administrator login:
  • Has all possible permissions on the Azure SQL instance.
  • Cannot be limited.
• A separate user account called dbo is created for the administrator login for each user database.
  • The dbo user has all database permissions.
  • Mapped to the db_owner database role.
• Determine the identity of the administrator account:
  • On the Properties page of the database in the Azure portal.
• The admin login identifier cannot be changed once the database is created.
• Reset the password of the admin account:
  • Select the Azure SQL server in the Azure portal.
  • Select Reset Password from the Overview page.
• Adding Administrative Users:
  • Create an Azure Active Directory Administrator account.
    • Enable Azure Active Directory authentication.
    • Configure a user or group account in Azure AD with administrative permissions.
    • Select the Active Directory Admin section under the Azure SQL Instances setting.
    • Configure an admin account by clicking the Set Admin button.
  • Create an additional SQL login in the master database:
    • Create a user account associated with this login in the master database.
    • Add this user account to the dbmanager role, the loginmanager role, or both roles in the master database using the ALTER ROLE statement.
  • Creating Additional Accounts for Nonadministrative Users:
    • Create SQL logins in the master database.
    • Create user accounts in each database to which the user requires access.
    • Associate that user account with the SQL login.

Database Auditing

• Allows you to track database events, such as tables being added or dropped.
• Audit logs for Azure SQL databases can be stored in:
  • An Azure Storage account
  • A Log Analytics workspace
  • Event Hubs
• Auditing for Azure SQL can be defined at both the server level and the database level.
  • Server Policy: Applies to all existing and newly created databases on the Azure SQL server instance.
  • Enabling auditing on an individual Azure SQL database will not override any server auditing settings, with both audits existing in parallel.
  • Microsoft recommends against enabling both server auditing and database blob auditing unless you:
    • Want to use a different storage account, retention period, or Log Analytics Workspace for a specific database.
    • Want to audit a separate set of event types of categories for a specific database.
• Steps to enable auditing for an SQL instance:
  1. In the Azure portal, open the Azure SQL instance on which you want to configure auditing.
  2. Under the Security node, select Auditing.
  3. Set the Auditing slider to On.
  4. Specify the audit log destination choosing from Storage, Log Analytics, or Event Hub.
  5. Click Save.
• Destinations for Audit Logs:
  • Azure Storage accounts
  • Event Hubs
  • Log Analytics workspaces (consumed by Azure Monitor logs)
  • Data can be written to multiple locations.
• Retention Period:
  • When auditing to a storage destination, the retention period is unlimited.
  • Retention settings can be modified to keep audit logs for a shorter amount of time.
• Viewing Audit Logs:
  • Click on the View Audit Logs item from the Auditing page of the Azure SQL server’s instance.
  • View audit information from the server or database level.
  • Click Log Analytics to view the logs in the Log Analytics workspace.
  • Click View Dashboard to view an auditing dashboard that will include access to sensitive data and security insight information.

Azure SQL Database Advanced Threat Protection

• Detects unusual activity that indicates that a third party might be trying to attack your organization’s Azure SQL databases.
• Notifications:
  • Unusual database activity
  • Potential database vulnerabilities given the current configuration
  • SQL injection attacks.
• Integrates with Azure Security Center.
• Provides recommendations on how to further investigate and remediate suspicious activity and threats.
• Steps to configure Azure SQL Database Advanced Threat Protection:
  1. In the Azure portal, open the Azure SQL Server instance for which you want to configure ATP.
  2. Under the Security node, click Advanced Data Security
  3. On the Advanced Data Security page, configure the following settings:
     • Advanced Data Security: Functionality includes Data Discovery, Classification, Vulnerability Assessment, and Advanced Threat Protection and has a per-month cost.
     • Subscription: Determines which subscription the vulnerability assessment settings will be billed against.
     • Storage Account: Where data from assessments will be logged.
     • Periodic Recurring Scans: Determines whether periodic vulnerability assessment scans are run against the Azure SQL instance.
     • Email address to which scan reports will be sent.
     • Advanced Threat Protection Settings: Configure where advanced threat protection information will be forwarded.
  4. On the Advanced Threat Protection Types page, choose which alerts you want to be notified about:
     • SQL Injection
     • SQL Injection Vulnerability
     • Data Exfiltration
     • Unsafe Action
     • Brute Force
     • Anomalous Client Login

Database Encryption

Transparent Data Encryption (TDE)

• Protects Azure SQL databases by encrypting data at rest.
• Databases, associated backups, and transaction log files are automatically encrypted and decrypted.
• Enabled by default for all new Azure SQL Databases.
• Configured at the server level and is inherited by all databases hosted on the Azure SQL Server instance.
• Has a database encryption key (DEK) protected by a built-in server certificate that is unique to each Azure SQL instance and leverages the AES 256 encryption algorithm.
• Microsoft automatically rotates these security certificates.
• Customer-Managed TDE (“Bring Your Own Key” or BYOK):
  • The TDE protection key is stored within Azure Key Vault.
  • Configure an Azure Key Vault with permissions so that the Azure SQL instance can interact with the Key Vault to retrieve the key.
  • If the Key Vault is removed or the Azure SQL instance loses permissions to the Key Vault in a BYOK scenario, the database will be inaccessible.
• Verifying TDE is enabled:
  • Select the Transparent Data Encryption section of a database server instance’s properties page in the Azure portal.
• Switching to customer-managed key:
  1. Create and configure an Azure Key Vault in the same region as the Azure SQL instance.
  2. Use the portal to create a key in the Key Vault and configure the Azure SQL instance with the appropriate permissions.
  3. On the Transparent Data Encryption page of the Azure SQL database instance, select Customer Managed Key
  4. The Key Selection Method offers two choices:
     • Enter a Key Identifier
     • Select A Key
  5. On the Select Key From Azure Key Vault page, select the subscription and the Key Vault that will host the key.
  6. If no suitable key is present in the Key Vault, you can click Create New.
  7. On the Select Key From Azure Key Vault page, select the version of the key.
  8. Click Save to configure Azure SQL to use your customer key.

Always Encrypted

• Protects specific types of sensitive data that has a known recognizable pattern (e.g., passport numbers, tax file identification numbers, and credit card numbers).
• Clients interacting with the database server encrypt the sensitive data inside the client applications and do not forward the encryption keys used to decrypt that data to the database server that will store that data.
• Ensures that administrators who manage Azure SQL servers cannot view sensitive data protected by Always Encrypted.

Deterministic Encryption:

• The same encrypted value will always be generated for the same plain text value, though this value will be unique to each database.
• Implementing deterministic encryption will allow you to perform point lookups, equality joins, grouping and indexing on encrypted columns.
• May allow unauthorized users to guess information about encrypted values by looking for patterns in encrypted columns, especially if there are a small set of possible values.
• Deterministic encryption requires that the column collation is configured with a binary2 sort order for character columns.

Randomized encryption

• Data is encrypted in a less predictable manner.
• More secure than deterministic encryption.
• Prevents searching, grouping, indexing, and performing joins on encrypted columns.
• Use deterministic encryption if columns will be used for searchers or where you will be grouping parameters.
• Use randomized encryption if your database has information that isn’t grouped with other records and which isn’t used to join tables, such as medical notes.

Configuring Always Encrypted

• Requires use of client-side tools.
• Cannot use Transact SQL statements to configure Always Encrypted.
• Instead, must configure Always Encrypted using SQL Server Management Studio or PowerShell.
• Requires performing the following tasks:
  • Provisioning column master keys, column encryption keys, and encrypted column encryption keys with corresponding column master keys.
  • Creating key metadata in the database
  • Creating new tables with encrypted columns
  • Encrypting existing data in selected database columns

Always Encrypted is not supported for columns that have the following characteristics:

• Columns with xml, timestamp/rowversion, image, ntext, text, sql_variant, hierarchyid, geography, geometry, alias types or user-defined types
• FILESTREAM columns
• Columns with the IDENTITY property
• Columns with ROWGUIDCOL property
• String columns with non-bin2 collections.
• Columns that are keys for clustered and nonclustered indexes (if you are using randomized encryption)
• Columns that are keys for full-text indexes (if you are using randomized encryption)
• Computed columns
• Columns referenced by computed columns
• Sparse column set.
• Columns referenced by statistics (if you are using randomized encryption)
• Columns using alias types
• Partitioning columns
• Columns with default constraints
• Columns referenced by unique constraints (if you are using randomized encryption)
• Primary key columns (if you are using randomized encryption)
• Referencing columns in foreign key constraints
• Columns referenced by check constraints
• Columns tracked using change data capture
• Primary key columns on tables that have change tracking enabled
• Columns masked using Dynamic Data Masking
• Columns in Stretch Database Tables

Configuring Always Encrypted on an Azure SQL database using SQL Server Management Studio:

1. Connect to the database that hosts the tables with columns you want to encrypt using Object Explorer in SQL Server Management Studio.

   • If the database does not already exist, you can create the database and then create the tables that you will configure to use Always Encrypted.

2. Right-click the database, select Tasks > Encrypt Columns. This will open the Always Encrypted Wizard. Click Next.

3. On the Column Selection page, expand the databases tables, and then select the columns that you want to encrypt.

4. For each column selected, you will need to set the Encryption Type attribute to Deterministic or Randomized.

5. For each column selected, you will need to choose an Encryption Key. If you do not already have an encryption key, you can have one automatically generated.

6. On the Master Key Configuration page, choose a location to store the key. You will then need to select a master key source.

7. On the Validation page, select whether you want to run the script immediately or use a PowerShell script later.

8. On the Summary page, review the selected option and click Finish.

Azure Key Vault

• Acts as a cloud hardware security module (HSM).
• Securely stores encryption keys and secrets, including certificates, database connection strings, and virtual machine passwords.
• Ensures that the items stored in Azure Key Vault are only accessible to authorized applications and users.
• Manage access to Key Vault, including how to configure permissions to secrets, certificates, and keys.
• Configure RBAC for managing Key Vault.
• Manage the items within Key Vault,
  • Rotate keys
  • Perform backup and recovery on secure Key Vault items.

Key Vault Access Control

• Limits access to sensitive information such as secrets, certificates, and keys.
• Managed at the management plane and at the data plane.
  • Management Plane: Tools to manage Key Vault (Azure portal, Azure CLI, and Cloud Shell).
  • Data Plane: Items stored within Key Vault (certificates, secrets, and keys).
  • Access permissions allow the ability to add, delete and modify certificates, secrets, and keys.
• Access to the Key Vault at both the management plane and the data planes should be as restricted as possible.
• If a user or application doesn’t need access to the Key Vault, they shouldn’t have access to the Key Vault.
• Microsoft recommends that: You use separate Key Vaults for development, preproduction, and production environments.
• Each Key Vault is associated with the Azure AD tenancy that is linked to the subscription that hosts the Key Vault.
• All attempts to manage or retrieve Key Vault content require Azure AD authentication.
• An advantage of requiring Azure AD authentication is that it allows you to determine which security principal is attempting access.
• Access to Key Vault cannot be granted based on having access to a secret or key and requires some form of Azure AD identity.

Key Vault Firewalls and Virtual Networks

• The Networking page of a Key Vault allows you to configure the network locations from which a specific Key Vault can be accessed.
• You can configure the Key Vault to be accessible from:
  • All networks
  • Specific virtual networks
  • Sets of IPv4 address ranges.
• When configuring network access rules for Azure Key Vault, keep the following in mind:
  • Each Key Vault can be configured with a maximum of 127 virtual network rules and 127 IPv4 rules.
  • /31 and /32 CIDR subnet masks are not supported.
  • Instead of individual IP addresses, rules should be allowed when allowing access from these subnets.
  • IP network rules can only be configured for public IP address ranges.
  • You should use virtual network rules for private IP address ranges.
  • IPv6 addresses are not presently supported by Azure Key Vault firewall rules.
• Steps to configure Key Vault firewalls and virtual networks in the Azure portal:
  1. In the Azure portal, open the Key Vault that you want to configure.
  2. Under Settings, select Networking. On the Networking page, select Firewalls And Virtual Networks
  3. By default, the Key Vault will be accessible from all networks. Select the Private Endpoint And Selected Networks option. When you enable this option, trusted Microsoft services can bypass the firewall. You can disable access from trusted Microsoft services if you choose.
  4. To add an existing virtual network or a new virtual network, click the Add Existing Virtual Networks or Add New Virtual Networks items.
  5. When you add a virtual network, you must select the subscription, virtual network, and subnets that you want to grant access to the Key Vault. If a service endpoint isn’t present on the virtual network subnet, you can enable one.
  6. To add an IPv4 address range, enter the IPv4 address or CIDR range.
  7. Click Save to save the Firewall And Virtual Networks configuration.
• You can use the Private Endpoint Connections tab to add private endpoint access to a specific Key Vault.
  • An Azure Private Endpoint is a network interface that allows a private and secure connection to a service using an Azure Private Link.
  • Azure Private Link allows access to Azure PaaS Services, such as Azure Key Vault over a private connection on the Microsoft network backbone.
  • No traffic that traverses a private link passes across the public Internet.

Permissions to Secrets, Certificates, and Keys

• Use Key Vault access control policies to manage permissions to secrets, certificates, and keys at the data plane level.




• Each Key Vault access control policy includes entries specifying what access the designated security principal has to keys, secrets, and certificates.




• Each Key Vault supports a maximum of 1,024 access policy entries.




• An access policy entry grants a distinct set of permissions to a security principal.




• A security principal can be a user, service principal, managed identity, or group.




• Microsoft recommends assigning permissions to groups and then adding and removing users, service principals, and managed identities to and from those groups as a way of granting or revoking permissions.
  
  Table 4-3 Key vault permissions
  

  Certificate permissions	Key permissions	Secrets permissions
  GetView the current certificate version in the Key Vault.	DecryptPerform a key decryption operation with the key.	GetRead a secret.
  ListList current certificates and certificate versions in the Key Vault.	EncryptPerform an encryption operation with the key.	ListList secrets or secret versions.
  DeleteDelete a certificate from the Key Vault.	UnwrapKeyUse the key for key decryption.	SetCreate a secret.
  CreateCreate a Key Vault certificate.	WrapKeyUse the key for key encryption.	DeleteDelete a secret.
  ImportImport certificate material into a Key Vault certificate.	VerifyUse the key to verify a signature.	BackupBack up secret in a Key Vault.
  UpdateUpdate a certificate in Key Vault.	SignUse the key for signing operation.	RestoreRestore a backed-up secret to a Key Vault.
  ManagecontactsManage Key Vault certificate contacts.	GetRead the public parts of a key.	RecoverRecover a deleted secret.
  GetissuersView the certificate’s issuing authority	ListList all keys in the vault.	PurgePermanently delete a deleted secret.	;
  ListissuersList a certificate’s issuing authority information.	UpdateModify the key’s attributes/metadata.
  SetissuersUpdate a Key Vault certificate authority or issuers.	CreateCreate a key in a Key Vault.
  DeleteissuersRemove information about a Key Vault’s certificate authorities or issuers.	Import Import an existing key into a Key Vault.
  ManageissuersManage a Key Vault’s list of certificate authorities/issuers.	DeleteRemove a key from a Key Vault.
  RecoverRecover a certificate that has been deleted from a Key Vault.	BackupExport a key in protected form.
  BackupBack up a certificate stored in Key Vault.	RestoreImport a previously backed up key.
  RestoreRestore a backed-up Key Vault certificate.	RecoverRecover a deleted key.
  PurgePermanently delete a deleted certificate.	PurgePermanently delete a deleted key.

$Set-AzKeyVaultAccessPolicy -VaultName <your-key-vault-name> - PermissionsToKeys <permissions-to-keys> -PermissionsToSecrets <permissions-to- secrets> -PermissionsToCertificates <permissions-to-certificates> - ObjectId <Id>$

$az keyvault set-policy -n <your-unique-keyvault-name> --spn <ApplicationID-of-your- service-principal> --secret-permissions <secret-permissions> -- key-permissions <key- permissions> --certificate-permissions <certificate- permissions>$

RBAC Usage in Azure Key Vault

• RBAC allows you to secure Azure Key Vault at the management plane.
• Microsoft introduced a new set of RBAC roles that provide a simplified way of assigning permissions to the contents of Key Vaults.
• Going forward, you should only configure access policies when you need to configure complex permissions that are not covered by the new RBAC roles.
• Assign Key Vault RBAC roles on the Access Control (IAM) page of a Key Vault’s properties.
• While you can also assign Key Vault RBAC roles at the resource group, subscription, and management group level, security best practice is to assign roles with the narrowest-possible scope.
• The RBAC roles for Azure Key Vault are as follows:
  • Key Vault Administrator: Can perform any action on secrets, certificates, and keys in a Key Vault, except managing permissions.
  • Key Vault Certificates Officer: Can perform any actions on Key Vault certificates, except managing permissions.
  • Key Vault Contributor: Allows for the management of Key Vault but does not allow access to the items within a Key Vault
  • Key Vault Crypto Officer: Can perform any actions on Key Vault keys, except managing permissions
  • Key Vault Crypto Service Encryption: Has read access to key metadata and can perform wrap and unwrap operations
  • Key Vault Crypto User: Can perform cryptographic operations on keys and certificates
  • Key Vault Reader: Can read Key Vault item metadata but not Key Vault item contents
  • Key Vault Secrets Officer: Can perform all actions on Key Vault secrets except managing permissions
  • Key Vault Secrets User: Can read the contents of secrets.

Certificate Management

• Azure Key Vault supports the following management actions for x509 certificates:
  • Allows for the creation of an x509 certificate or for the import of an x509 certificate
  • Supports Certificate Authority–generated certificates and self-signed certificates
  • Allows a Key Vault certificate owner to store that certificate securely without requiring access to the private key
  • Allows a certificate owner to configure policies that allow Key Vaults to manage certificate life cycles
  • Allows certificate owners to provide contact information so that they can be notified about life cycle events, including certificate expiration and renewal
  • Can be configured to support automatic certificate renewal with specific Key Vault partner x509 certificate authorities

Certificate Policies

• Provide information to the Key Vault on how to create and manage the life cycle of a certificate stored within the Key Vault.
• This includes information on whether the certificate’s private key is exportable.
• When you create a certificate in a Key Vault for the first time, a policy must be supplied.
• Once this policy is established, you won’t need the policy for subsequent certificate creation operations.

Certificate policies contain the following elements:

• X509 certificate properties
  • Includes subject name, subject alternate names, and other properties used during the creation of an x509 certificate.
• Key properties
  • Specifies the key type, key length, whether the key is exportable, and how the key should be treated in renewal fields.
  • These properties provide instruction on how a Key Vault generates a certificate key.
• Secret properties
  • Specifies secret properties, including the type of content used to generate the secret value, when retrieving a certificate as a Key Vault secret.
• Lifetime actions
  • Specifies lifetime settings for the Azure Key Vault certificate.
  • This includes the number of days before expiry and an action option, which either emails specified contacts or triggers autorenewal of the certificate.
• Issuer
  • Includes information about the x509 certificate issuer.
• Policy attributes
  • Lists attributes associated with the policy.
• Azure Key Vault presently can work with two certificate-issuance providers for TLS/SSL certificates: DigiCert and GlobalSign.
• When you onboard a certificate authority provider, you gain the ability to create TLS/SSL certificates that include the certificate authority provider as the apex of the certificate trust list.
• This ensures that certificates created through the Azure Key Vault will be trusted by third parties who trust the certificate authority provider.
• Certificate contacts information includes the addresses where notifications are sent when specific certificate life cycle events occur. Certificate contact information is shared across all certificates generated by a Key Vault.
• If you have configured a certificate’s policy so that auto- renewal occurs, notifications will be sent:
  • Prior to certificate renewal.
  • After successful certificate auto-renewal.
  • If an error occurs during auto-renewal.
  • If manual renewal is configured, you are provided with a warning that you should renew the certificate.

Creating and Importing Certificates

• You can add certificates to Key Vault by importing them or generating them using the Key Vault.

• When generating certificates, you can have the certificate self-signed or have it be generated as part of a trust chain from a trusted CA provider.

• Steps to create a self-signed certificate using the Azure portal:

  1. In the Azure portal, open the Key Vault properties page and click Certificates
  2. Select Generate/Import. On the Create A Certificate page, set the Method Of Certificate Creation as Generate. You can also set this to Import An Existing Certificate, which you will learn about later in this chapter. Ensure that Type Of Certificate Authority (CA) is set to Self-Signed Certificate. Provide a Certificate Name, a Subject, and any DNS Names, and then click Create.

• You can use Azure Key Vault to create TLS/SSL certificates that leverage a trust chain from a trusted CA provider after you have performed the following steps to create an issuer object:

  1. Performed the onboarding process with your chosen Certificate Authority (CA) provider. At present, DigiCert and GlobalSign are partnered with Microsoft to support TLS/SSL certificate generation. Certificates generated in this manner will be trusted by third-party clients.
  2. The chosen CA provider will provide credentials that can be used by Key Vault to enroll, renew, and implement TLS/SSL certificates. You can enter these credentials on the Create A Certificate Authority page in the Azure portal.
  3. Add the certificate issuer resource to the Key Vault.
  4. Configure Certificate Contacts for notifications. This step isn’t required, but it is recommended.

• Once you have configured the relationship with the issuing CA, you will be able to create TLS/SSL certificates using the portal or by creating a request using JSON code similar to the following. (This requires the CertificateIssuer resource created earlier, and this example assumes a partnership with DigiCert.)

{
 "policy": {
  "x509\_props": {
  "subject": "CN=TailwindCertSubject1"
  },
  "issuer": {
  "name": "mydigicert",
  "cty": "OV-SSL",
  }
 }
}

• The POST method to send this request URI is similar to the following, with your Key Vault’s address substituted where appropriate:

  $https://mykeyvault.vault.azure.net/certificates/mycert1/create?api-version= {api-version}$

• To create a Key Vault certificate manually instead of relying on the partner certificate authority provider, use the same method as outlined earlier, but don’t include the issuer field.

• As an alternative, you can create a self-signed certificate by setting the issuer name to Self in the certificate policy, as shown here:

"issuer": {
 "name": "Self"
 }

• You can import an X509 certificate into Key Vault that has been issued by another provider, as long as you have the certificate in PEM or PFX format and you have the certificate’s private key.
• You can perform an import through the Azure portal, by using the az certificate import Azure CLI command or by using the Import- AzKeyVaultCertificate PowerShell cmdlet.
• PowerShell cmdlets for managing Azure Key Vault certifications

• Azure CLI commands for managing Azure Key Vault certifications