Implement Azure security practice questions

The user's display name is present

Why wrong: While a user's display name might be present in claims like `name` or `preferred_username`, its existence or specific value is not a security validation control for the token itself. The API's primary security concern is the token's cryptographic validity and authorization claims, not the presence of user-friendly attributes. An API should not reject a token solely because a display name is missing, nor trust it solely because one is present.

The token was sent in a query string

Why wrong: Transmitting sensitive JWT access tokens in a URL query string is a significant security vulnerability and should never be accepted. Query string parameters are often logged by web servers, proxies, and browser histories, making the token highly susceptible to exposure and interception. Bearer tokens must always be sent securely within the `Authorization` header using the `Bearer` scheme to prevent such leakage.

Managed Identity: A secret key used to authenticate to Azure SQL Database

Why wrong: This statement is incorrect because a Managed Identity is not a secret key; rather, it is an identity in Azure Active Directory that *eliminates* the need for managing secret keys. While a Managed Identity can be used to authenticate to Azure SQL Database, it does so by leveraging Azure AD authentication, where Azure SQL Database trusts Azure AD for identity verification. The concept of a 'secret key' for authentication typically refers to connection strings or manually managed application secrets, which Managed Identities are designed to replace.

Service Principal: A user account in Azure AD for human users

Why wrong: This statement is incorrect because a Service Principal is specifically designed as an identity for applications, services, or automated tools, not for human users. Human users in Azure Active Directory are represented by 'user accounts,' which have distinct properties and are managed differently, often involving multi-factor authentication and password policies. Service Principals enable programmatic, non-interactive access to Azure resources, distinguishing them fundamentally from human-centric user accounts.

Kubernetes Secrets with a CronJob to update them

Why wrong: Kubernetes Secrets, by default, are only base64 encoded, not encrypted at rest in etcd, making them inherently less secure for highly sensitive data. Implementing secret rotation using a custom CronJob introduces significant operational complexity, potential security vulnerabilities, and a high risk of misconfiguration or service disruption. This approach also places the burden of secret lifecycle management directly on the application team, deviating from best practices for centralized secret management.

Azure Managed Identity for the pod

Why wrong: Azure Managed Identity for the pod provides an identity for applications to authenticate to Azure AD-protected resources without requiring developers to manage credentials. While essential for enabling secure access to services like Azure Key Vault, Managed Identity itself does not store, manage, or rotate secrets. It serves as the secure authentication mechanism that allows a pod to access a secret store, rather than being a secret storage or rotation solution in its own right.

Azure App Configuration with a managed identity

Why wrong: Azure App Configuration is primarily designed for centralized management of application settings, feature flags, and dynamic configuration values. Although it can store configuration data that might include non-sensitive connection strings, it lacks the dedicated security features, robust auditing capabilities, and built-in automatic rotation mechanisms specifically engineered for highly sensitive secrets. Using App Configuration for secret rotation would be an anti-pattern, as it's not its intended secure secret management purpose.

Configure a service hook to validate signatures using Azure Functions

Why wrong: Service hooks in Azure DevOps are designed to integrate with external services by sending notifications or triggering workflows *after* specific events occur, such as a pull request completion. While an Azure Function could be invoked to validate signatures, a service hook cannot inherently *block* a merge operation based on the validation outcome. It lacks the direct enforcement capability within the pull request merge process to prevent an unsigned commit from being integrated into the target branch.

Use Azure Policy to require code signing on the repository

Why wrong: Azure Policy is a governance tool primarily focused on enforcing standards and assessing compliance for Azure resources, such as virtual machines, storage accounts, and networking components. It operates at the management group, subscription, or resource group scope and is not designed to interact with or enforce policies within the internal operations of an Azure DevOps Git repository. Therefore, it cannot be used to directly mandate or validate commit signing requirements for source code.

Add a build validation step in the PR pipeline that checks signatures

Why wrong: Adding a build validation step to a pull request pipeline allows for automated checks, like compiling code or running tests, before a merge is permitted. While a custom script within this pipeline could theoretically check for commit signatures, this validation runs *prior* to the final merge decision and does not inherently enforce the signature requirement at the point of merge. If the branch policy itself doesn't mandate signed commits, an unsigned commit could still be merged once the build validation passes, or if the policy is bypassed.

Enable HTTPS on the web front end

Why wrong: Enabling HTTPS on the web front end primarily secures the communication channel between external clients and the public-facing web application. While crucial for protecting user data in transit from the internet, it does not inherently provide encryption or security for the internal service-to-service communication paths between the web layer, API layer, and database layer within the Azure virtual network. Therefore, it fails to address the security of data moving between internal application tiers.

Enable Azure Storage encryption at rest

Why wrong: Azure Storage encryption at rest, such as Server-Side Encryption for Blob storage or Azure Disk Encryption for virtual machine disks, protects data when it is persisted on storage devices. This measure is fundamental for data confidentiality when data is inactive or stored. However, it does not provide encryption for data as it actively travels across the network between different application tiers, which is the specific concern of securing data in transit.

Use managed identities to authenticate between tiers

Why wrong: Managed identities provide an Azure Active Directory (AAD) identity for Azure resources, enabling them to authenticate securely to other AAD-protected services without requiring developers to manage credentials. While essential for secure *authentication* and authorization between application tiers, managed identities do not inherently encrypt the *data payload* as it traverses the network. They establish *who* is communicating, but do not protect the content of the communication itself from interception.

Microsoft.Storage/storageAccounts/read

Why wrong: This is a management action for reading storage account properties, not blob data.

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Why wrong: This permission is already included in the role; it allows reading blob content but not listing blobs.

Microsoft.Storage/storageAccounts/blobServices/containers/read

Why wrong: This is an ARM action for listing containers, not for listing blobs.

Azure App Configuration

Why wrong: Azure App Configuration is primarily designed for centralized management of application settings and feature flags, offering dynamic configuration updates without redeploying applications. While it can store configuration values, its capability to manage secrets typically involves storing references to secrets held within Azure Key Vault. This integration allows applications to retrieve both configuration and sensitive data securely from a single endpoint, promoting separation of concerns and enhancing operational efficiency.

Azure Active Directory Certificate Services

Why wrong: Azure Active Directory Certificate Services (AD CS) refers to the on-premises Public Key Infrastructure (PKI) role that issues and manages digital certificates within an enterprise. While certificates are a type of secret, this service's primary function is to establish trust and secure communication through certificate issuance and revocation for identity verification. It does not provide a centralized repository for general application secrets like API keys or database connection strings, which is the domain of services like Azure Key Vault.

Azure Policy

Why wrong: Azure Policy is a governance tool used to enforce organizational standards and assess compliance across Azure resources. It defines rules and effects to ensure resources adhere to specific configurations, such as requiring Key Vault for secret storage or auditing non-compliant settings. Azure Policy's role is to control and audit resource configurations, not to store or manage secrets or certificates itself.

Improved application performance by caching secrets.

Why wrong: Azure Key Vault itself does not inherently provide a caching mechanism for secrets to improve application performance. While applications might implement their own client-side caching of retrieved secrets to reduce latency and the number of Key Vault calls, this is an application-level optimization, not a direct feature or benefit provided by the Azure Key Vault service. Key Vault's primary role is secure storage and access control, not performance enhancement through built-in caching.

Integration with Azure DevOps for automatic secret rotation in pipelines.

Why wrong: While Azure Key Vault can be integrated with Azure DevOps pipelines (e.g., using the Azure Key Vault task to fetch secrets) and supports secret rotation capabilities, the automatic rotation specifically within pipelines is not an inherent benefit of Key Vault itself. Key Vault provides the secure storage and APIs for rotation, but the orchestration of *automatic rotation within a DevOps pipeline* requires additional scripting, external automation, or specific tooling configured within the pipeline, rather than being a direct, built-in feature of Key Vault.

Automatic encryption of secrets at rest and in transit.

Why wrong: Azure Key Vault indeed automatically encrypts secrets at rest using FIPS 140-2 validated hardware security modules (HSMs) or software, and data in transit is protected by TLS. However, while crucial for security, this is a fundamental security feature expected of any secure secret management service, rather than a distinct benefit that differentiates it or is its sole purpose. The question asks for *benefits* of *using* Key Vault, implying advantages beyond basic security hygiene that are common to secure storage solutions.

Azure Monitor Log Analytics workspaces.

Why wrong: Azure Monitor Log Analytics workspaces are primarily designed for collecting, analyzing, and querying operational logs and metrics for monitoring, diagnostics, and troubleshooting purposes. While they offer robust querying capabilities, logs stored within Log Analytics are not inherently immutable by default and can be modified or deleted by users with appropriate permissions, making them unsuitable for strict tamper-proof audit requirements where data integrity and non-repudiation are critical for compliance.

Microsoft Sentinel.

Why wrong: Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution. Its core purpose is to provide intelligent security analytics across an enterprise, detecting threats, investigating incidents, and automating responses. While Sentinel ingests vast amounts of log data, its primary function is not to provide tamper-proof, long-term audit log retention for compliance, but rather to identify and act on security events.

Microsoft Purview Audit (Premium).

Why wrong: Microsoft Purview Audit (Premium) is specifically engineered to provide comprehensive, tamper-proof audit logging across Microsoft 365 services, including integrated Azure activities, to meet stringent regulatory and compliance requirements. It offers advanced auditing capabilities such as high-value event logging, long-term retention of audit records (up to 10 years), and forensic investigation tools, ensuring the integrity and immutability of audit trails crucial for legal hold and compliance mandates.

Enforce TLS 1.2 for all client connections.

Why wrong: Enforcing TLS 1.2 for all client connections is a vital security practice, but it specifically protects data in transit between the client application and the Azure Cosmos DB service. TLS (Transport Layer Security) encrypts network communications, preventing eavesdropping and tampering during data transmission over the internet or private networks. However, once the data reaches the Cosmos DB storage and is persisted, TLS no longer applies; it does not provide protection for data at rest on the storage media itself.

Deploy Azure Firewall in front of the Cosmos DB account.

Why wrong: Deploying Azure Firewall in front of an Azure Cosmos DB account is a network security measure designed to filter and control inbound and outbound network traffic to and from the Cosmos DB endpoint. While a firewall enhances overall security by restricting network access to authorized sources and preventing network-based attacks, it operates at the network perimeter. It does not directly encrypt or protect the data once it has been successfully written and stored within the Cosmos DB service; thus, it does not safeguard data at rest.

Rotate storage account keys every 24 hours

Why wrong: Rotating storage account keys every 24 hours is an excessively frequent practice that introduces significant operational overhead and potential for service disruption. While key rotation is crucial for security, best practices typically recommend rotation intervals of 90 to 180 days, allowing sufficient time for key updates across dependent applications without constant, high-risk changes.

Use SAS tokens with long expiry dates

Why wrong: Using Shared Access Signatures (SAS) tokens with long expiry dates is a significant security anti-pattern that drastically increases the risk of unauthorized access. If a long-lived SAS token is compromised, an attacker gains extended, unauthenticated access to the specified storage resources, making it challenging to revoke promptly. Best practice dictates using SAS tokens with the shortest possible expiry and least privilege necessary for the task.

Enable anonymous public access for all containers

Why wrong: Enabling anonymous public access for all containers is a critical security vulnerability that allows anyone on the internet to read data without any authentication. This setting bypasses all access control mechanisms, exposing potentially sensitive information to the public. For most enterprise scenarios, public access should be disabled by default and only selectively granted for specific, non-sensitive content like static website assets, under strict control.

The key can only be used for encryption

Why wrong: The statement is incorrect because the `keyOps` property in Azure Key Vault explicitly defines the cryptographic operations permitted for a key. If the key's `keyOps` array includes both "encrypt" and "decrypt" operations, it signifies that the key is authorized for both actions, not exclusively for encryption. Therefore, the key is not restricted to only encryption.

The key size is 4096 bits

Why wrong: This statement is incorrect as the `keySize` property of an Azure Key Vault key specifies its exact length in bits. If the configuration explicitly states a `keySize` of 2048 bits, then asserting that the key size is 4096 bits directly contradicts the defined attribute. The key's actual cryptographic strength is determined by its configured size, which in this case is 2048 bits.

The key will be rotated 90 days before expiration

Why wrong: This statement is incorrect because key rotation policies in Azure Key Vault differentiate between triggers based on creation time versus expiration time. The policy parameter `timeAfterCreate: P90D` dictates that the key will be rotated 90 days after its initial creation date, not 90 days prior to its expiration. Rotation before expiration would be configured using `timeBeforeExpiry`.

Assign the same role to other users

Why wrong: Assigning roles requires Microsoft.Authorization/roleAssignments/write.

Delete secrets from Key Vaults in the resource group

Why wrong: Delete requires Microsoft.KeyVault/vaults/secrets/delete.

Create new Key Vaults in the resource group

Why wrong: Create requires write permission (Microsoft.KeyVault/vaults/write).

Configure CORS on the storage account

Why wrong: Configuring Cross-Origin Resource Sharing (CORS) on an Azure Storage account is primarily a browser-security feature designed to allow web applications running in a browser at one domain to access resources from another domain. Azure Functions, when executing server-side code, do not operate within a browser's security context. Therefore, CORS settings are irrelevant for enabling a Function App to access storage using its managed identity, as this interaction is server-to-server and relies on Azure Active Directory authentication.

Assign the Storage Blob Data Reader role to the managed identity at the storage account scope

Why wrong: Assigning the 'Storage Blob Data Reader' role to the Function App's managed identity at the storage account scope is the correct and complete solution. This action leverages Azure Role-Based Access Control (RBAC) to explicitly grant the Function App's identity the necessary permissions to read blob data within that specific storage account. This combination of an enabled managed identity and a targeted RBAC role assignment provides secure, identity-based access without requiring any secrets or connection strings.

Generate a SAS token for the blob

Why wrong: Generating a Shared Access Signature (SAS) token for a blob provides delegated access to storage resources with specific permissions and a limited validity period. While SAS tokens are a valid method for granting access, they are typically used for scenarios where a managed identity or Azure AD authentication is not feasible, such as providing time-limited access to external clients. When using managed identities, the primary goal is to eliminate the need for managing secrets like SAS tokens, making this approach redundant and less secure for internal Azure service-to-service communication.

Use the UseAuthentication middleware to validate tokens

Why wrong: The UseAuthentication middleware is responsible for validating the incoming JSON Web Token (JWT) from Azure AD, ensuring its signature, expiry, and issuer are valid. It then constructs the `HttpContext.User` principal based on the token's contents, including all claims. While essential for establishing identity, `UseAuthentication` does not perform any authorization checks against specific claims; its role is purely authentication.

Use the [Authorize] attribute with a policy that requires a specific claim

Why wrong: This is the correct and recommended approach in ASP.NET Core for claim-based authorization. By applying the `[Authorize]` attribute with a named policy, you instruct the authorization middleware to evaluate specific requirements defined within that policy. The policy is configured to demand the presence and/or a specific value of a particular claim, ensuring that only authenticated users possessing the required claim can successfully access the protected resource.

Manually parse the JWT in a custom middleware

Why wrong: Manually parsing the JWT in custom middleware bypasses the built-in policy-based authorisation pipeline that integrates with Microsoft Entra ID, meaning claims are checked outside the framework’s `[Authorize]` attribute and `IAuthorizationHandler` system, which is the intended mechanism for claim-based access control. This approach is tempting because it gives full control over token inspection and would be correct if the requirement were to validate a custom token format or perform non-standard cryptographic checks that the default middleware cannot handle.

Assign the managed identity directly to the Azure SQL Database logical server.

Why wrong: This statement is incorrect because managed identities are designed to be assigned to Azure services (like Function Apps, VMs, App Services) that need to access other resources. An Azure SQL Database logical server is a target resource that other services authenticate to, not a resource that itself uses a managed identity to authenticate to something else in this context. Therefore, you cannot directly assign a managed identity to the SQL server itself.

Create a service principal and assign it to the function app.

Why wrong: While a service principal can be used for authentication, creating one and assigning it to a Function App is not a 'managed identity' approach and introduces credential management overhead. A service principal requires manual creation of client secrets or certificates, which must be securely stored (e.g., in Key Vault) and rotated. Managed identities automate this process entirely, making them the preferred, more secure, and simpler solution for Azure resource authentication without secrets.

Inject secrets as environment variables from ConfigMaps.

Why wrong: Injecting secrets as environment variables from ConfigMaps is a significant security vulnerability. ConfigMaps are designed for non-confidential configuration data and store information unencrypted in etcd, making it easily accessible to anyone with cluster access. Exposing sensitive data like API keys or database credentials directly in pod environment variables allows simple inspection and retrieval, completely undermining security best practices for secret management.

Use Kubernetes Secrets with a scheduled CronJob to rotate them.

Why wrong: Using Kubernetes Secrets with a scheduled CronJob for rotation is an insecure and operationally complex approach. Kubernetes Secrets are merely base64-encoded, not encrypted at rest by default within etcd, meaning they are vulnerable if the underlying storage is compromised. While a CronJob could attempt rotation, this requires a custom, error-prone implementation that lacks the robust security features, auditing, and lifecycle management provided by a dedicated secret management solution.

Enable 'App Service Authentication' and set the action to 'Allow anonymous requests'.

Why wrong: Enabling App Service Authentication is a correct first step, but setting the action to 'Allow anonymous requests' fundamentally defeats the purpose of securing sensitive data. This configuration permits unauthenticated access to the function app, meaning any client can invoke the function without proving its identity. For processing sensitive customer data, this approach introduces a critical security vulnerability, as it provides no mechanism to restrict access to authorized users or services.

Use Service Bus managed identity with access keys for authentication.

Why wrong: While managed identities are a secure way for Azure services to authenticate to other Azure services (like a Function App accessing Service Bus), this option incorrectly suggests using Service Bus managed identity *with access keys* for *function app authentication*. Access keys are static credentials that are difficult to manage securely and do not leverage Microsoft Entra ID for client authentication to the function app itself. This approach introduces security risks by relying on shared secrets instead of robust identity-based authentication for incoming requests to the function.

Set the function app's 'HTTP version' to 'HTTP/2' to improve encryption.

Why wrong: Setting the function app's 'HTTP version' to 'HTTP/2' primarily improves performance through features like multiplexing and header compression, but it does not inherently improve or enforce encryption. Encryption is provided by the underlying TLS/SSL protocol, which is enabled by HTTPS. Relying on HTTP/2 alone without enforcing HTTPS would still leave sensitive data vulnerable to interception and exposure, as HTTP/2 can operate over both secure (HTTPS) and insecure (HTTP) connections.

Configure a customer-managed key in Azure Key Vault and associate it with the storage account.

Why wrong: Configuring a customer-managed key (CMK) in Azure Key Vault for a storage account primarily enhances data encryption at rest. While CMK provides greater control over the encryption keys used by Azure Storage to encrypt your data, it does not address network access control or secure data in transit. This feature is designed to meet specific compliance requirements for data residency and key management, not to restrict which network entities can connect to the storage account or to enforce secure communication protocols.

Enable VNet integration on the function app to route traffic through a virtual network.

Why wrong: Enabling VNet integration on the function app allows the function to send outbound traffic into a specified virtual network, enabling it to access resources within that VNet or peered VNets. However, VNet integration itself does not automatically restrict inbound access to the storage account from other networks or the public internet. To secure the storage account, you must explicitly configure its firewall rules to only permit traffic originating from the VNet where the function is integrated, thereby controlling who can connect to the storage account.

Have each microservice read secrets directly from Key Vault using the SDK.

Why wrong: This approach creates a direct, synchronous dependency on Azure Key Vault for every secret access. Without any caching mechanism, each microservice call to retrieve a secret incurs network latency and consumes Key Vault API quotas. More critically, if Azure Key Vault experiences an outage or network connectivity issues, the microservices will be unable to retrieve necessary secrets, leading to application failures and significant downtime. This design lacks resilience and introduces a single point of failure.

Assign a managed identity to each pod and use it to authenticate to Key Vault.

Why wrong: While assigning a managed identity to each pod is an excellent practice for secure, passwordless authentication to Azure Key Vault, it only addresses the authentication aspect. This method still requires each pod to make direct, real-time calls to Key Vault to retrieve secrets. It does not provide any caching or local storage of secrets, meaning that if Key Vault is unavailable or experiences high latency, the pods will fail to retrieve secrets, impacting application functionality and performance.

Store secrets as plain text in Kubernetes secrets.

Why wrong: Storing secrets as plain text in Kubernetes secrets is a severe security vulnerability and fundamentally violates best practices for sensitive data handling. While Kubernetes secrets are base64 encoded, this is not encryption and offers no protection against unauthorized access to the cluster's etcd database or compromised nodes. This approach exposes sensitive information directly, making it easily readable by anyone with sufficient access to the cluster, leading to potential data breaches and compliance failures.