Unit 4: Manage Security Operation

I. Security Operations in Azure — Governing Principles

Security operations are the continuous activities used to establish governance, protect identities and cryptographic assets, monitor deployed resources, and restore workloads after disruption. In Microsoft Azure, these activities follow the shared-responsibility model: Microsoft secures the physical cloud platform, while customers secure identities, data, configurations, applications, and access according to the service model.

• Confidentiality: Prevent unauthorized disclosure through encryption, Azure Key Vault, access controls, private endpoints, and certificate-based authentication.
• Integrity: Protect resources and data from unauthorized modification using Azure Policy, RBAC, activity logs, resource locks, and cryptographic signatures.
• Availability: Maintain services through redundancy, Azure Backup, recovery vaults, availability zones, and tested restoration procedures.
• Least privilege: Grant only the permissions required for a task, at the narrowest practical Azure scope.
• Defense in depth: Apply controls across identity, network, compute, application, data, monitoring, and physical layers.
• Zero Trust: Verify explicitly, use least-privileged access, and assume breach rather than trusting a request solely because it originates inside a network.
• Continuous governance: Detect and correct configuration drift through policies, compliance assessments, security monitoring, and automated remediation.
• Operational resilience: Define recovery objectives, protect backups from deletion, and regularly verify that workloads can be restored.

II. Security Policies — Enforcing Organizational Requirements

A. Security policies

Security policies define mandatory rules for protecting information systems and translate organizational risk decisions into technical and administrative controls.

• Policy scope: A policy may apply to a tenant, management group, subscription, resource group, workload, or data classification.
• Core policy areas:
  • Identity: Require multifactor authentication, privileged access workflows, and periodic access reviews.
  • Network: Restrict public endpoints, define firewall rules, and require network segmentation.
  • Data: Specify encryption, retention, classification, backup, and approved storage regions.
  • Operations: Establish logging, incident response, patching, vulnerability management, and recovery requirements.
• Azure Policy: Evaluates Azure resources against rule definitions and reports or changes their compliance state.
• Policy effects:
  • Audit records non-compliance without blocking deployment.
  • Deny prevents a non-compliant resource operation.
  • Modify adds, removes, or changes supported properties.
  • DeployIfNotExists deploys a required related configuration.
  • AuditIfNotExists checks whether a related resource exists.
• Initiative definition: Groups multiple policy definitions, such as encryption, logging, and endpoint restrictions, into one compliance assignment.
• Exemptions: Permit controlled exceptions with documented scope, justification, category, and expiration date.

B. Applications and limitations

Security policy is effective only when requirements are measurable, enforceable, and regularly reviewed.

• Concrete application: A Deny policy can prevent creation of storage accounts that allow insecure transport.
• Compliance evidence: Azure Policy compliance results identify compliant, non-compliant, exempt, and unknown resources.
• Limitation: Policy compliance does not prove that a workload is secure; application flaws, stolen credentials, and unmonitored data flows may remain.
• Operational caution: Test restrictive policies in Audit mode before changing them to Deny, especially for production subscriptions.

III. Azure Blueprint-Based Governance — Repeatable Environments

A. Security settings using Azure Blueprint

Security settings using Azure Blueprint package governance artifacts so that controlled Azure environments can be deployed repeatedly and consistently.

• Blueprint artifacts:
  • Policy assignments: Enforce requirements such as allowed locations or mandatory diagnostic settings.
  • Role assignments: Grant predefined Azure roles at deployment scope.
  • ARM templates: Deploy resources such as Log Analytics workspaces or network infrastructure.
  • Resource groups: Establish a standard resource organization.
• Lifecycle: A blueprint is drafted, published as a version, assigned to a subscription, and tracked through deployment.
• Parameters: Blueprint and artifact parameters allow values such as region, resource names, and principal identifiers to vary between assignments.
• Resource locking: Blueprint-managed resources can be protected against modification or deletion, depending on the assignment’s locking configuration.
• Governance relationship: Azure Blueprints orchestrates artifacts, whereas Azure Policy continuously evaluates individual resource compliance.
• Service direction: Azure Blueprints remains associated with legacy governance implementations; modern designs should evaluate Azure Deployment Stacks, Template Specs, and Azure Policy because Blueprints is scheduled for deprecation.

B. Applications and limitations

Blueprint-style governance supports regulated landing zones but requires lifecycle and migration planning.

• Application: A financial-services subscription can receive mandatory logging, restricted deployment regions, standard RBAC assignments, and protected resource groups in one assignment.
• Version control: Published versions create stable deployment baselines; changes should be released as a new version.
• Limitation: Existing resources may need remediation if they predate the assignment.
• Migration concern: Organizations should inventory blueprint definitions and reproduce needed behavior with supported infrastructure-as-code and governance services.

IV. Operational Security Architecture — Protecting Deployed Resources

A. Deployed security infrastructure

Deployed security infrastructure consists of the preventive, detective, and responsive controls operating around Azure workloads.

• Identity layer: Microsoft Entra ID provides authentication, Conditional Access, managed identities, Privileged Identity Management, and identity-risk detection.
• Network layer: Network Security Groups filter traffic by protocol, port, source, and destination; Azure Firewall provides centralized filtering and logging.
• Perimeter protection: Azure Web Application Firewall protects HTTP applications, while Azure DDoS Protection addresses volumetric and protocol attacks.
• Workload protection: Microsoft Defender for Cloud supplies security recommendations, posture assessment, regulatory dashboards, and workload threat protection.
• Monitoring layer: Azure Monitor, Log Analytics, activity logs, and Microsoft Sentinel collect and correlate operational and security events.
• Private connectivity: Private Link and private endpoints expose platform services through private virtual-network addresses rather than public endpoints.
• Deployment validation: Confirm secure images, patch levels, endpoint protection, disk encryption, diagnostic settings, and approved network paths before production release.

B. Applications and limitations

Security infrastructure must be monitored and maintained rather than treated as a one-time deployment.

• Control mapping: Preventive controls include firewalls and RBAC; detective controls include alerts and logs; corrective controls include automation runbooks and recovery.
• Configuration drift: Manual changes may weaken approved baselines, so infrastructure-as-code and policy evaluation should detect deviations.
• Telemetry requirement: A firewall without diagnostic logs can block traffic but provides limited evidence for investigation.
• Limitation: Excessive alerts create fatigue; severity, ownership, escalation, and response times must be defined.

V. Azure Key Management — Centralized Secret Protection

A. Azure Key Vaults (AKV)

Azure Key Vaults (AKV) securely store and control access to application secrets, cryptographic keys, and certificates.

• Supported objects:
  • Secrets: Passwords, tokens, connection strings, and API keys.
  • Keys: RSA or elliptic-curve keys used for encryption, decryption, signing, and verification.
  • Certificates: X.509 certificates and their associated private keys and lifecycle metadata.
• Authentication: Applications should use Microsoft Entra identities, preferably managed identities, instead of embedding credentials in source code.
• Authorization: Access can be controlled through Azure RBAC; older vaults may use vault access policies.
• Network security: Firewalls, virtual-network rules, private endpoints, and disabled public access reduce exposure.
• Protection features: Soft delete retains deleted objects for recovery, while purge protection prevents permanent deletion until the retention period expires.
• Monitoring: Diagnostic settings can send vault audit events to Log Analytics, Storage, or Event Hubs.
• Separation of duties: A resource administrator should not automatically receive permission to read secret values.

B. Applications and limitations

Key Vault reduces credential exposure but does not correct insecure application handling after retrieval.

• Application: A virtual machine’s managed identity can retrieve a database secret without storing an Azure password on disk.
• Rotation: Applications should tolerate new secret or key versions and avoid permanently binding to an obsolete version.
• Availability: Workloads should handle throttling and temporary access failures with controlled retry and caching strategies.
• Limitation: A compromised application identity may retrieve every object permitted to that identity; permissions must therefore remain narrow.

VI. Hardware-Protected Cryptography — Strong Key Isolation

A. Hardware Security Module

A Hardware Security Module is a tamper-resistant cryptographic device that generates, stores, and processes keys without exposing private key material in plaintext.

• Security boundary: Cryptographic operations occur inside the HSM, reducing the risk of keys being extracted from application memory or storage.
• Azure options:
  • Key Vault premium tier: Supports HSM-protected keys in a multi-tenant managed service.
  • Azure Managed HSM: Provides a single-tenant, highly available HSM service for cryptographic keys.
  • Azure Dedicated HSM: Provides dedicated physical appliances for specialized control requirements.
• Standards anchor: Azure HSM offerings use validated hardware, commonly assessed against FIPS 140 security requirements.
• Key operations: Typical operations include key generation, wrapping, unwrapping, signing, verification, encryption, and decryption.
• Administrative control: Managed HSM uses separate data-plane roles, supporting division between security administrators and cryptographic users.
• Use cases: Payment processing, certificate-authority keys, database encryption, code signing, and regulated key custody benefit from hardware protection.

B. Applications and limitations

HSMs offer stronger key assurance at the cost of added administration, service constraints, and expense.

• Non-exportability: HSM-generated private keys are normally designed to remain inside the hardware security boundary.
• Resilience: Backup, quorum, region, and disaster-recovery arrangements must be designed before critical keys are created.
• Performance: Cryptographic throughput and supported algorithms should be checked against application requirements.
• Limitation: An HSM protects keys, not authorized misuse; a compromised principal with signing permission may still request valid signatures.

VII. Authorization Management — Controlling Azure Actions

A. Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) determines who can perform which actions on Azure resources and at what scope.

• Role assignment components:
  • Security principal: User, group, service principal, or managed identity.
  • Role definition: Collection of allowed and excluded operations.
  • Scope: Management group, subscription, resource group, or individual resource.
• Inheritance: A role assigned at subscription scope generally applies to contained resource groups and resources.
• Built-in roles: Owner manages resources and access, Contributor manages resources but not role assignments, and Reader views resources.
• Data-plane distinction: Roles such as Storage Blob Data Reader grant access to stored data, unlike management roles that control the storage account resource.
• Custom roles: Define required Actions, NotActions, DataActions, and assignable scopes when built-in roles are too broad.
• Privileged access: Microsoft Entra Privileged Identity Management can make high-impact assignments eligible, time-limited, approval-based, and audited.

az role assignment create \
  --assignee <principal-id> \
  --role "Reader" \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>

B. Applications and limitations

RBAC should be assigned to groups or managed identities and reviewed for unnecessary privilege.

• Least-privilege example: Grant a backup operator a backup-specific role rather than Owner.
• Deny assignments: Certain Azure-managed services use deny assignments that take precedence over granted permissions.
• Propagation: New role assignments may require several minutes to become effective.
• Limitation: RBAC controls Azure authorization but does not replace operating-system permissions or application-level authorization.

VIII. Certificate Lifecycle Management — Maintaining Digital Trust

A. Manage certificates

Manage certificates means securely issuing, storing, deploying, renewing, revoking, and monitoring X.509 certificates throughout their lifecycle.

• Certificate contents: A certificate binds a public key to a subject identity and includes an issuer, serial number, validity period, and digital signature.
• Private-key protection: Private keys should be non-exportable where possible and stored in Key Vault or an HSM-backed service.
• Lifecycle stages: Generate a key pair and certificate signing request, obtain issuance, validate deployment, renew before expiry, and revoke if compromised.
• Key Vault integration: Key Vault can create or import certificates, maintain versions, and integrate with supported certificate issuers.
• Deployment targets: Certificates commonly secure Application Gateway, App Service, API endpoints, VPN authentication, and service-to-service TLS.
• Expiry monitoring: Alerts should be generated well before the NotAfter date to allow validation and controlled replacement.
• Trust chain: Clients must trust the issuing root and required intermediate certification authorities.

B. Applications and limitations

Certificate automation prevents outages and reduces errors caused by manual renewal.

• Rotation principle: Deploy the renewed certificate, verify TLS operation, and only then retire the old version.
• Revocation: Certificate revocation lists and Online Certificate Status Protocol can indicate that a certificate is no longer trusted.
• Hostname validation: The requested DNS name must appear in the certificate’s Subject Alternative Name extension.
• Limitation: A valid certificate proves possession of a private key and certified identity attributes; it does not prove that the application itself is secure.

IX. Azure Data Protection — Backup and Disaster Recovery

A. Backup and recovery solutions in Azure

Backup and recovery solutions in Azure protect data against deletion, corruption, ransomware, infrastructure failure, and regional disruption.

• Azure Backup: Provides managed backup for Azure virtual machines, files, disks, and supported workloads through vault-based protection.
• Recovery Services vault: Stores backup metadata and recovery points for supported services, including Azure VM backup.
• Backup vault: Supports newer Azure Data Protection workloads and should not be confused with a Recovery Services vault.
• Azure Site Recovery: Replicates machines and orchestrates failover; it provides disaster recovery rather than historical backup.
• Recovery objectives:
  • Recovery Point Objective: Maximum acceptable amount of lost data, measured as time.
  • Recovery Time Objective: Maximum acceptable duration for restoring service.
• Retention: Policies can retain daily, weekly, monthly, and yearly recovery points according to business and regulatory requirements.
• Security controls: Soft delete, immutability, multifactor authorization, encryption, monitoring, and restricted vault permissions protect backup data.

B. Applications and limitations

A complete recovery strategy combines backup, replication, documented procedures, and restoration testing.

• Backup versus replication: Backup preserves historical recovery points; replication maintains a current secondary copy for faster failover.
• Restore testing: Recovery success must be verified by restoring data or machines into an isolated network.
• Cost factors: Protected-instance charges, backup storage, retention duration, and cross-region restore affect cost.
• Limitation: A successful backup job does not guarantee application consistency unless the workload and backup method support it.

X. Virtual Machine Protection — Recovery Services Vault Procedure

A. Configure backup of a virtual machine using Recovery Services vault

Configure backup of a virtual machine using Recovery Services vault by creating a compatible vault, selecting a backup policy, enabling protection, and verifying recovery points.

• Prerequisites: The operator requires backup permissions, and the vault must be compatible with the virtual machine’s subscription and region.
• Create the vault: In the Azure portal, create a Recovery Services vault, selecting the subscription, resource group, vault name, and region.
• Configure resilience: Choose locally redundant, zone-redundant where supported, or geo-redundant backup storage before protection becomes established.
• Open backup configuration: Select Backup, choose Azure as the workload location, and select Virtual machine as the workload type.
• Select a policy: Define backup frequency, execution time, instant-restore retention, and long-term recovery-point retention.
• Enable protection: Select one or more eligible virtual machines and choose Enable backup.
• Run initial backup: Use Backup now to create an on-demand recovery point rather than waiting for the scheduled job.
• Verify operation: Check Backup Jobs, Backup Instances, and the VM’s recovery-point list for successful completion.
• Restore options: Recovery may create a new VM, restore disks, replace existing disks where supported, or recover individual files.

B. Operational validation and limitations

VM backup configuration is complete only after a recovery point has been tested through a controlled restore.

• Application consistency: Azure Backup coordinates with supported operating-system mechanisms to create application-consistent recovery points; otherwise, crash-consistent recovery may be used.
• Encryption awareness: Encrypted VMs require appropriate permissions and continued access to relevant keys or encryption resources.
• Network isolation: Test restores should use an isolated virtual network to prevent duplicate hostnames, addresses, or application transactions.
• Deletion protection: Enable soft delete and consider immutability and multifactor authorization to resist accidental or malicious backup removal.
• Monitoring: Configure Azure Monitor alerts for failed jobs, unhealthy backup instances, and protection gaps.
• Limitation: Restoring a VM does not automatically validate external dependencies such as DNS, databases, certificates, identity permissions, or network routes.