- Encryption: Plaintext => Ciphertext, Decryption: Ciphertext => Plaintext
- Symmetric encryption
- Uses symmetric key to encrypt & decrypt
- The longer the key, the better it is
- Uses symmetric key to encrypt & decrypt
- Good encryption algorithm: been in use in several years + resisted all attacks.
- Encoding (encryption) of data when it is persisted (stored)
- Azure uses symmetric encryption
- For partitioned data, different keys may be used for each partition.
- Data encryption keys are often encrypted with asymmetric encryption.
- Flow: Resource providers <=> Data Encryption keys (DEKs) => Key encryption keys (KEKs) => Azure Key Vault (protected by Azure AD)
- Enabled by default, cannot be disabled using Storage Service Encryption (SSE)
- Does not affect the performance
- You can use
Encryption Blade
to use custom key.
- Some services support customer managed keys & client-side encryption
- Uses TDE (Transparent Data Encryption) on server level as default.
- Encrypts data + log files.
- Encryption happens in page level
- Encrypted before writing to disk
- Decrypted when read into memory
- Encryption happens in page level
- Encrypts also SQL server + Azure Synapse Analytics (older name: Azure SQL Data Warehouse)
- Does not increase the size of the encrypted database.
- Uses database encryption key (DEK)
- The key is stored in database boot record with a certificate for availability during recovery.
- It can be symmetric key in master DB server, or asymmetric key protected by EKM (Extensible Key Management)
- Database, media attachments, backups are encrypted by default.
- Primary database is generally stored in SSDs
- Media attachments & back-ups are stored in Blob storage (generally HDDs)
- In Azure SQL Database and SQL server.
- Data is never plaintext inside database.
- Encrypted at rest, during movement between client <=> server, in another words when data is in use.
- Clients decrypts data with a key unknown to DB.
- Separation between who own the data and who manage the data.
- Requires code changes, driver installed in server, change in connection string.
- Designed when data will never be in plaintext in cloud.
- Hardware vendors help it (e.g. Intel)
- Trusted Execution Environment
- No one can see the data.
- If code is changed, operations are denied & environment is disabled.
- No code changes required.
- Exposing
- Hardware: Intel CPU's with Intel SGX are available in VMs.
- Software: SGX SDK + 3rd party can be used in VM & compute.
- Services: Many Azure services including Azure SQL.
- Frameworks: Ex: Confidential Consortium Blockchain Framework by Microsoft Research Team.
- Trusted Execution Environment
- Security for communications over computer network.
- Secure Sockets Layer (SSL)
- Used by many Azure services.
- ❗ SSL (1.0, 2.0, 3.0) are vulnerable and prohibited by IETF.
- Transport Layer Security (TLS)
- ❗ TLS 1.0 is insecure because of block chippers (CBC & RC2 CBC) and stream cipher (RC4).
- 💡 Recommended: Higher than TLS 1.0.
- Supported by Azure Storage (default: TLS 1.2)
- Secrets store for e.g. password, DB credentials, API key, certificates.
- Each secret gets URL, vault name must be unique.
- Backed by hardware security modules (HSMs)
- Control & logs access to anything stored in them.
- Can handle requesting & renewing TLS certificates
- Streamlines key management process
- Dev, test keys and migration to production keys.
- Permissions to keys can be granted and revoked as needed.
- Usage
- Accessible on Azure Portal
- In .NET: You can use Azure SDK in C# with AzureServiceTokenProvider as authentication callback.
- In CLI:
az keyvault create
az secret set
az keyvault secret show
- Rest API:
- Create key:
POST {vaultBaseUrl}/keys/{key-name}/create?api-version=7.0
- Delete certificate:
DELETE {vaultBaseUrl}/certificates/{certificate-name}?api-version=7.0
- Get secret:
GET {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.0
- Update secret:
PATCH {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.0
- Create key: