Data Protection and Security Flashcards
Azure SQL Transparent Data Encryption
Transparent Data Encryption (TDE) is a security feature that protects data at rest by encrypting the database files, backups, and logs. TDE ensures that unauthorized access to physical files does not compromise data confidentiality.
Configuration
Service Managed:
* Default encryption method for Azure SQL Database, Managed Instances, and Synapse Analytics.
* Azure automatically handles the encryption process without user intervention.
Customer Managed:
* Allows customers to manage their own encryption keys.
* Can be configured at the server or database level.
* Provides greater control over encryption and key lifecycle management.
Encryption Keys:
* Database Encryption Key (DEK): Uses AES-256 encryption standard to secure data.
* DEK Protector: RSA 2048/3072-bit wrapper used to protect the DEK. Can be managed by Azure (service-managed) or the customer (customer-managed) through Azure Key Vault.
Identity:
* A managed identity is required for the logical server to access Key Vault.
Azure SQL Always Encrypted
Always Encrypted is a data protection feature in Azure SQL Database and SQL Server that ensures sensitive data is encrypted in transit, at rest, and in use.
- Protects sensitive data such as credit card numbers or Social Security numbers from unauthorized access.
Configuration
Database:
* Supports SQL Server, Azure SQL Database, SQL Managed Instance.
Column:
* Encrypt one or more columns using deterministic or randomized encryption.
Encryption Key(s):
* CEK (Column Encryption Key): Used to encrypt/decrypt data in the columns.
* CMK (Column Master Key): Protects the CEK.
Store:
* The Column Master Key (CMK) must be stored in: Windows Certificate Store or Azure Key Vault.
Azure SQL Data Masking
Azure SQL Data Masking is a security feature designed to protect sensitive data from unauthorized access by hiding or masking it in real-time. This allows users to work with the data without exposing sensitive information, ensuring compliance with privacy regulations such as GDPR or HIPAA.
Configuration
Database:
* Supports Azure SQL Database, Managed Instance, and Synapse Analytics.
Column:
* Dynamic data masking is configured for one or more columns in a table to secure sensitive data.
Mask Function:
* Applies predefined or custom rules to mask data. Examples include masking credit card numbers or email addresses.
Query:
* The actual data within the database remains unaltered. Masking is applied only in the query results for unauthorized users.
Azure Storage Access Control
Access Keys
1. Storage Account: Access Keys are managed at the SA level
2. Access Keys provide full unrestricted access to the SA.
-2 Keys are created by default (Primary - Secondary), when you create the SA
-They provide full access via HTTP/S over the REST API to any data in your SA
-Can be used by all services for REST and even Azure File through SMB as well
3. Management: Keys can be rotated, or disabled entirely for a SA
-You can integrate Key Vault for the rotations
-You can disable the keys entirely
Azure AD Identities (RBAC)
1. Identity: A user, group, app, or managed identity to be provided data access
2. Scope: Supports standard RBAC hierarchy down to individual storage service
3. Role: Supports built-in and custom RBAC roles that target data operations
Shared Access Signatures (SAS)
-URLs with a token granting limited, time-bound access to specific resources.
-Fine-grained control over access without sharing keys.
- Service SAS: A token that can provide restricted access to an individual service
-Stored Access Policy: Facilitates server-side control over service shared access signatures - Account SAS: Provide access to one or more services, including service-level operations
We can create them, in two ways:
- By default, you are creating it by using the account key of the storage account
-If you rotate that access key, that would revoke any SAS that were created with it - User-Delegation SAS: SAS associated with an Azure AD identity that only supports blob storage
-Instead of using a key to sign the SAS token, it’s going to be created by an identity within Azure AD (much more secure)
Azure Storage Encryption
We do get encryption that can help us to protect traffic. For the storage, sitting at rest, we can use Azure Storage Service Encryption (SSE) (On by default)
-There’s also a feature called “Infrastructure Encryption” if you want to doubly encrypt, add another layer of encryption to you data as it’s processed through Microsoft’s infrastructure (Before the SA creation)
-For the encryption of the traffic flowing from our SA to our users, we can use SSL/TLS (can be enforced)
Configuration
- Service-Side Encryption: Encryption of the Azure Storage data in Microsoft infrastructure at rest
- Encryption Key (Key Vault) Two main ways where we can have encryption for our SA:
-PMK: Platform Managed Key (Encrypt)
-CMK (Optional): Customer Manager Key (use it to wrap the PMK)
–When you are setting up the SA, you get the option to say whether it’s just Blob and Files that is protected by your CMK (You can’t change this after creation)
–You have to configure an Identity: A managed identity is required for the SA to access Key Vault. This identity is granted permissions to access the KV. - Encryption Scopes: Optionally define blobs/containers to be encrypted with a CMK or PMK
Immutable Blob Storage
Inmutable Blob Storage Access Policy (Time-based Retention) helps us put the data into a special state, called “WORM state” (Write Once Read Many)
-It’s common when you’re working with compliance, industry requirements or maybe legal issues, you might need to have data not being modified
Must keep data for 2 years!
+Create and read blobs
-Delete/Modify blobs (less than 2 years old)
-If you create a policy for a container that is time-based, you can lock it and say, “no one can modify this data for two years”
Legal-Hold
+Create and read blobs
-Delete/Modify blobs (irrespective of age)
Implementation
- Storage Account: Supports General Purpose V2 and Premium Block Blob
- (Access) Policy
-Time: Retention period (can be locked) (Time and Locked or not)
-Legal: Switch on/off as needed (Requires a key) - Scope: Policies can be Container-level-scoped or Blob/Version-level-scoped
-For versioning, your SA must have the “Version Level Immutability” turned on
-If you want the “Version Level Immutability” feature at the SA scope, you must have to enable it BEFORE creating the SA