Data Security: Encryption, Keys, and RBAC | Guided by A Guide to Cloud

Data security layers

Simple explanation

Think of data security in layers, like a bank vault. Encryption at rest is the vault walls — data is scrambled when stored. Keys are the combinations to the vault — you need one to get in. RBAC is the security guard checking your badge — different people get different levels of access. Always Encrypted is a locked briefcase inside the vault — even the bank staff can’t read what’s inside.

Marcus’s security checklist

⚙️ Marcus at FinSecure has SOC 2 requirements for data security:

All data encrypted at rest with customer-controlled keys
No shared master keys in application code
Least-privilege access for each microservice
PII fields (SSN, account numbers) encrypted client-side

Encryption at rest

Cosmos DB always encrypts data at rest — you cannot disable it.

Aspect	Service-Managed Keys (default)	Customer-Managed Keys (CMK)
Key management	Microsoft manages keys	You manage keys in Azure Key Vault
Key rotation	Automatic by Microsoft	You control rotation schedule
Compliance	Meets most requirements	Required for some regulatory frameworks
Setup	Automatic — no configuration	Requires Key Vault + managed identity
Cost	Included	Key Vault charges apply
Revocation	Not possible	Revoke access by removing key permissions

# Configure CMK with Azure Key Vault
az cosmosdb update --name finsecure-cosmos \
  --resource-group rg-finsecure \
  --key-uri "https://finsecure-vault.vault.azure.net/keys/cosmos-key/abc123"

Exam tip: CMK revocation

If you revoke the Key Vault permissions for a CMK-enabled Cosmos DB account, the account becomes inaccessible — all reads and writes fail. This is a powerful security control (you can lock out a compromised account) but also a risk (misconfigured Key Vault access can cause an outage).

The exam tests this: “What happens if the CMK is deleted from Key Vault?” → the account becomes inaccessible.

Authentication methods

1. Account keys (master keys)

// Full access — read, write, delete anything
CosmosClient client = new CosmosClient(endpoint, accountKey);

Two keys: Primary and secondary (for rotation without downtime)
Full access: Master keys grant complete control — never embed in client apps
Rotation: Rotate using az cosmosdb keys regenerate; switch apps to the secondary key first

2. Resource tokens (scoped access)

// Create a permission that grants read access to a specific partition
Permission permission = await user.CreatePermissionAsync(
    new PermissionProperties(
        id: "readOrders",
        permissionMode: PermissionMode.Read,
        container: ordersContainer,
        resourcePartitionKey: new PartitionKey("customer-123")
    ),
    tokenExpiry: 3600  // 1 hour
);

string resourceToken = permission.Resource.Token;
// Give this token to the client — they can only read customer-123's orders
CosmosClient scopedClient = new CosmosClient(endpoint, resourceToken);

Scoped: Limit access to specific containers, partitions, or documents
Temporary: Tokens expire (1-24 hours, default 1 hour)
Per-user: Created via the Users and Permissions system

3. Microsoft Entra ID (RBAC)

The recommended approach — no keys or tokens to manage:

# Assign the built-in "Cosmos DB Built-in Data Reader" role
az cosmosdb sql role assignment create \
  --account-name finsecure-cosmos \
  --resource-group rg-finsecure \
  --role-definition-name "Cosmos DB Built-in Data Reader" \
  --principal-id "00000000-0000-0000-0000-000000000000" \
  --scope "/dbs/orders/colls/transactions"

RBAC: data plane vs management plane

Aspect	Data Plane RBAC	Management Plane RBAC
What it controls	Read/write/query operations on data	Account config, databases, containers
Roles	Cosmos DB Built-in Data Reader, Data Contributor	Azure built-in roles (Contributor, Reader)
Scope	Account, database, container, or partition	Subscription, resource group, or account
Authentication	Microsoft Entra ID tokens	Microsoft Entra ID tokens
Key operations	CRUD on items, run queries	Create/delete DBs, change throughput

Built-in Data Plane Role	Permissions
Cosmos DB Built-in Data Reader	Read items, execute queries
Cosmos DB Built-in Data Contributor	Read + write items, execute queries

Exam tip: RBAC vs master keys

RBAC with Microsoft Entra ID is the recommended authentication method for production. Master keys should only be used for initial setup or legacy applications. Key advantages of RBAC:

No secrets to rotate or leak
Least-privilege access (specific roles, scoped to containers)
Integration with Entra ID Conditional Access policies
Audit trail in Entra ID logs

The exam often presents “a developer has the master key in their code” as a security anti-pattern, with RBAC as the correct alternative.

Always Encrypted (client-side)

For the most sensitive data, Always Encrypted provides client-side encryption:

Data is encrypted before it leaves the application
Cosmos DB stores and indexes ciphertext — it never sees plaintext
Only the application with the encryption key can decrypt
Supports deterministic encryption (allows equality queries on encrypted fields) and randomised encryption (no queries, maximum security)

// Always Encrypted configuration
ClientEncryptionPolicy encryptionPolicy = new ClientEncryptionPolicy(
    new List<ClientEncryptionIncludedPath>
    {
        new ClientEncryptionIncludedPath
        {
            Path = "/ssn",
            ClientEncryptionKeyId = "customer-dek",
            EncryptionType = EncryptionType.Deterministic.ToString(),
            EncryptionAlgorithm = "AEAD_AES_256_CBC_HMAC_SHA256"
        }
    }
);

Diana’s tip: 🔍 Diana requires Always Encrypted for SSN and account number fields — even FinSecure’s DBAs cannot see plaintext values.

🎬 Video walkthrough

🎬 Video coming soon

Data Security — DP-420 Module 25

~16 min