Unit 4: Manage Security Operation - Subjective Questions

A cloud security policy is a formal set of rules, responsibilities, and controls used to protect cloud resources, identities, applications, and data.

Major elements include:

• Purpose and scope: Identifies the subscriptions, users, applications, and resources covered by the policy.
• Identity and access management: Defines authentication, authorization, multifactor authentication, privileged access, and least-privilege requirements.
• Data protection: Specifies encryption, data classification, retention, and secure deletion requirements.
• Network security: Defines firewall rules, network segmentation, private connectivity, and permitted traffic.
• Resource configuration: Establishes approved regions, virtual machine sizes, resource types, and mandatory security settings.
• Logging and monitoring: Specifies audit log collection, alerting, and security incident monitoring.
• Backup and recovery: Defines backup frequency, retention period, recovery objectives, and restoration procedures.
• Incident response and compliance: Describes reporting, investigation, remediation, and regulatory requirements.

In Azure, many of these requirements can be enforced using Azure Policy, management groups, RBAC, Microsoft Defender for Cloud, and infrastructure deployment templates.

The security policy lifecycle consists of the following stages:

1. Requirement identification: Determine business, technical, legal, and regulatory requirements.
2. Risk assessment: Identify assets, threats, vulnerabilities, and the possible impact of security incidents.
3. Policy development: Define rules for identity, network access, encryption, logging, backup, and incident response.
4. Approval and communication: Obtain management approval and communicate the policy to administrators and users.
5. Implementation: Apply controls using Azure Policy, RBAC, network security groups, Key Vault, Defender for Cloud, and backup services.
6. Monitoring: Use Azure Monitor, activity logs, policy compliance reports, and security alerts to verify compliance.
7. Remediation: Correct non-compliant configurations through manual or automated remediation tasks.
8. Periodic review: Update policies when services, threats, regulations, or organizational requirements change.

This lifecycle ensures that security policies remain effective, measurable, enforceable, and aligned with business objectives.

Azure Policy and Azure Blueprints both support governance, but they serve different purposes.

• Azure Policy:

  • Evaluates resources against organizational rules.
  • Can deny, audit, modify, append, or automatically deploy required settings.
  • Uses policy definitions, initiatives, assignments, exemptions, and remediation tasks.
  • Continuously evaluates resource compliance.

• Azure Blueprints:

  • Packages multiple governance and deployment artifacts into a reusable environment definition.
  • Can include policy assignments, RBAC role assignments, resource groups, and Azure Resource Manager templates.
  • Supports versioning, assignment to subscriptions, and resource locking.
  • Is useful for creating repeatable environments that follow organizational standards.

Thus, Azure Policy focuses mainly on continuous rule enforcement, whereas Azure Blueprints historically provided repeatable deployment and governance packaging. In modern implementations, organizations may also use deployment stacks, template specifications, and infrastructure-as-code tools for repeatable governed deployments.

An Azure Blueprint can contain the following artifacts:

• Policy assignments: Apply individual Azure Policy definitions or policy initiatives to enforce security and compliance requirements.
• Role assignments: Assign built-in or custom RBAC roles to users, groups, service principals, or managed identities.
• Resource groups: Create resource groups with predefined names, locations, and organizational structures.
• Azure Resource Manager templates: Deploy resources such as virtual networks, storage accounts, Key Vaults, virtual machines, and monitoring components.

A blueprint definition can be published as a version and assigned to one or more subscriptions. During assignment, parameters such as locations, resource names, and identity information can be supplied. Blueprint locks may protect deployed resources from unauthorized modification or deletion.

Together, these artifacts enable consistent deployment of a governed and security-compliant Azure environment.

An organization can use Azure Blueprints through the following process:

1. Define governance requirements: Identify mandatory controls such as allowed regions, encryption, logging, tagging, and network restrictions.
2. Create the blueprint definition: Create the blueprint at a management group or subscription scope.
3. Add policy artifacts: Add policies that deny public storage, require secure transfer, restrict locations, and deploy diagnostic settings.
4. Add RBAC artifacts: Assign appropriate roles to security, operations, networking, and application teams.
5. Add deployment artifacts: Use Azure Resource Manager templates to deploy virtual networks, Key Vaults, Log Analytics workspaces, and other shared infrastructure.
6. Publish a version: Publish a controlled version so that it can be assigned consistently.
7. Assign the blueprint: Select the target subscription, provide parameter values, and configure the managed identity required for deployment.
8. Apply resource locks: Use blueprint locks where protection from modification or deletion is required.
9. Validate deployment: Confirm that all artifacts and resources were deployed successfully.
10. Monitor compliance: Review Azure Policy compliance, activity logs, security recommendations, and alerts.
11. Update and remediate: Publish new versions and remediate non-compliant resources when requirements change.

This approach provides standardization, repeatability, traceability, and centralized governance across multiple Azure subscriptions.

Deployed security infrastructure refers to the Azure resources and services implemented to prevent, detect, investigate, and recover from security incidents.

Important components include:

• Microsoft Entra ID: Provides identity management, authentication, conditional access, and multifactor authentication.
• RBAC: Controls who can perform actions on Azure resources.
• Network security groups: Filter inbound and outbound traffic at subnet or network-interface level.
• Azure Firewall and Web Application Firewall: Provide centralized traffic filtering and application-layer protection.
• Azure Key Vault: Protects keys, secrets, and certificates.
• Microsoft Defender for Cloud: Provides security posture management, recommendations, and workload protection.
• Azure Monitor and Log Analytics: Collect metrics and logs for visibility, diagnostics, and alerting.
• Microsoft Sentinel: Supports security information and event management and automated response.
• Recovery Services vault: Manages backups and recovery points for supported workloads.
• Private endpoints and network segmentation: Reduce exposure to public networks.

These components should be deployed using a defense-in-depth model rather than relying on a single security control.

Defense in depth uses multiple independent security layers so that the failure of one control does not expose the entire environment.

The layers can be applied in Azure as follows:

1. Physical security: Microsoft protects Azure datacenters, hardware, and physical access.
2. Identity layer: Use Microsoft Entra ID, multifactor authentication, conditional access, privileged identity management, and managed identities.
3. Perimeter layer: Use distributed denial-of-service protection, Azure Firewall, application gateways, and Web Application Firewall.
4. Network layer: Segment workloads using virtual networks and subnets, and control traffic with network security groups and private endpoints.
5. Compute layer: Patch operating systems, use endpoint protection, remove unnecessary services, and apply secure configuration baselines.
6. Application layer: Use secure coding, API protection, vulnerability testing, and controlled secret access.
7. Data layer: Encrypt data at rest and in transit, store keys in Key Vault or managed HSM, and classify sensitive data.
8. Monitoring layer: Collect logs with Azure Monitor, detect threats with Defender for Cloud, and correlate incidents using Microsoft Sentinel.
9. Recovery layer: Maintain protected backups and regularly test restoration procedures.

A successful design also applies least privilege, zero-trust verification, continuous monitoring, and automated compliance checks across all layers.

Azure Key Vault is a managed Azure service used to securely store and control access to sensitive information.

It manages:

• Keys: Cryptographic keys used for encryption, decryption, signing, and verification.
• Secrets: Sensitive values such as passwords, connection strings, tokens, and API keys.
• Certificates: Public-key certificates and their associated private keys and lifecycle information.

Key Vault protects these objects through:

• Encryption of stored data.
• Microsoft Entra ID authentication.
• Authorization through Azure RBAC or vault access policies.
• Hardware-protected key options.
• Logging and auditing through Azure Monitor diagnostic settings.
• Network restrictions, firewalls, private endpoints, and public network access controls.
• Soft delete and purge protection to reduce accidental or malicious permanent deletion.
• Key and secret versioning to support rotation and recovery.

Applications should use managed identities to access Key Vault instead of embedding credentials in source code or configuration files.

Azure Key Vault and Azure Key Vault Managed HSM both protect cryptographic material, but they have different capabilities.

• Azure Key Vault:

  • Stores keys, secrets, and certificates.
  • Supports software-protected and hardware-protected keys, depending on configuration and service tier.
  • Is suitable for application secrets, TLS certificates, encryption keys, and general cloud workloads.
  • Provides integrated certificate and secret management.

• Managed HSM:

  • Is a fully managed, highly available, single-tenant hardware security module service.
  • Primarily manages hardware-protected cryptographic keys.
  • Provides stronger administrative separation and a dedicated security domain.
  • Is designed for regulated or high-assurance workloads requiring strict key custody and hardware isolation.
  • Does not serve as a general-purpose secret and certificate store in the same manner as a Key Vault.

Therefore, an organization should use Key Vault for broad secret, key, and certificate management, and Managed HSM when dedicated hardware isolation and stronger cryptographic control are required.

A Hardware Security Module, or HSM, is a tamper-resistant hardware device designed to generate, store, and use cryptographic keys securely.

Security benefits include:

• Cryptographic keys are protected within a hardened hardware boundary.
• Key operations such as signing and decryption can be performed without exposing private key material.
• Tamper detection and resistance reduce the risk of physical and logical attacks.
• Strong administrative controls support separation of duties.
• HSM-based services can help meet regulatory and industry compliance requirements.

Common Azure use cases include:

• Protecting customer-managed encryption keys.
• Signing software, documents, and transactions.
• Protecting certificate authority private keys.
• Supporting database and storage encryption.
• Securing payment, financial, government, and healthcare workloads.
• Managing high-value keys through Azure Key Vault Premium or Managed HSM.

An HSM improves key protection, but administrators must still implement RBAC, monitoring, backup, rotation, and recovery procedures.

Azure Role-Based Access Control, or Azure RBAC, is an authorization system used to control who can access Azure resources, what actions they can perform, and where the permissions apply.

Its major components are:

• Security principal: A user, group, service principal, or managed identity requesting access.
• Role definition: A collection of allowed and excluded operations. Examples include Owner, Contributor, Reader, and Key Vault Secrets User.
• Scope: The level at which access applies, such as management group, subscription, resource group, or individual resource.
• Role assignment: The association of a security principal, a role definition, and a scope.
• Deny assignment: An explicit restriction that blocks specific actions even when a role would otherwise allow them.

Azure RBAC supports the principle of least privilege. Administrators should assign the smallest suitable role at the narrowest practical scope and prefer group-based assignments over repeated assignments to individual users.

Azure Key Vault supports two authorization approaches:

• Azure RBAC permission model:

  • Uses Azure role assignments.
  • Supports management group, subscription, resource group, and vault-level scopes, with supported data-plane scopes.
  • Provides centralized access management and integration with privileged identity management.
  • Includes roles such as Key Vault Administrator, Key Vault Secrets User, and Key Vault Crypto Officer.
  • Is generally preferred for consistent enterprise governance.

• Key Vault access policy model:

  • Stores permissions directly in the vault configuration.
  • Grants separate permissions for keys, secrets, and certificates.
  • Is managed independently for each vault.
  • Can increase administrative complexity in large environments.
  • Must be carefully protected because users with broad vault configuration permissions may be able to modify access policies.

Both models use Microsoft Entra ID for authentication. An organization should choose one authorization model per vault and carefully plan migration before changing models to avoid interrupting application access.

A suitable RBAC strategy should apply least privilege, separation of duties, controlled elevation, and narrow scope.

• Security administrators: Assign security-focused roles at the management group or subscription level. Avoid assigning Owner unless resource access delegation is necessary.
• Backup operators: Assign Backup Operator or an appropriate backup-specific custom role at the Recovery Services vault or resource-group scope.
• Application developers: Grant Contributor only on application resource groups. Use narrower service-specific roles where possible and prevent unnecessary access to production secrets.
• Auditors: Assign Reader, Security Reader, and monitoring-related read roles so they can inspect configurations and reports without changing resources.
• Automated applications: Use managed identities and grant only the required data-plane role, such as Key Vault Secrets User, on the required vault.

Additional controls should include:

1. Assign roles to groups rather than individual users.
2. Use privileged identity management for time-bound administrative access.
3. Require approval and multifactor authentication for privileged activation.
4. Keep production, development, and testing scopes separate.
5. Use custom roles only when built-in roles are too broad.
6. Review role assignments and inactive accounts periodically.
7. Monitor privileged operations through activity logs and alerts.
8. Avoid excessive Owner and User Access Administrator assignments.

This design limits attack impact while allowing each team to perform its required duties.

The certificate lifecycle includes the following stages:

1. Planning: Select the certificate type, subject name, key algorithm, validity period, and trusted certificate authority.
2. Key generation: Generate the private and public key pair securely, preferably using Key Vault or an HSM for sensitive workloads.
3. Certificate request: Create and submit a certificate signing request to the certificate authority.
4. Issuance: The certificate authority validates the request and issues the certificate.
5. Deployment: Install or reference the certificate in services such as application gateways, web applications, API services, or virtual machines.
6. Monitoring: Track expiration dates, failed renewals, incorrect bindings, and unauthorized access.
7. Renewal and rotation: Renew certificates before expiration and update dependent services with the new version.
8. Revocation: Revoke a certificate if its private key is compromised or its owner is no longer trusted.
9. Retirement: Remove unused certificates, bindings, and access permissions securely.

Private keys must be protected throughout the lifecycle using restricted access, encryption, auditing, backup, and secure rotation procedures.

Azure Key Vault provides centralized certificate lifecycle management.

• Creation: An administrator can create a certificate policy that defines the subject, validity period, key type, key size, renewal action, and issuer.
• Import: Existing certificates can be imported in supported formats. If a certificate contains a private key, the import package must be protected and handled securely.
• Storage: Key Vault stores the certificate and its related key and secret representations with versioning.
• Access: Applications can retrieve certificates using Microsoft Entra authentication and Azure RBAC. Managed identities are preferred.
• Renewal: Certificates may be renewed automatically with supported integrated issuers or renewed manually with external certificate authorities.
• Monitoring: Administrators can configure expiration notifications, Azure Event Grid events, diagnostic logs, and alerts.
• Rotation: A new certificate version can be created and dependent services can be updated to use it.
• Recovery: Soft delete and purge protection help recover accidentally deleted certificate objects.

Administrators should regularly test renewal automation because a stored certificate is not useful if dependent services fail to load its latest version.

Azure Backup is a managed service that protects Azure and supported on-premises workloads by creating recoverable copies of data.

Important concepts include:

• Recovery Services vault: A management entity that stores backup configuration, recovery points, and backup-related metadata for supported workloads.
• Backup vault: A newer vault type used for certain modern Azure Backup workloads.
• Backup policy: Defines backup frequency, schedule, instant restore settings where applicable, and retention periods.
• Protected item: A virtual machine, database, file share, or other workload registered for backup.
• Recovery point: A restorable version of the protected workload created at a specific time.
• Snapshot tier: Supports faster operational recovery for supported workloads.
• Vault tier: Retains recovery points in Azure Backup storage for longer-term protection.
• Redundancy: Backup storage may use locally redundant, zone-redundant, or geo-redundant storage, depending on service and regional support.
• Soft delete and immutability: Help protect backups from accidental or malicious deletion.
• Monitoring: Backup Center, Azure Monitor, alerts, reports, and jobs are used to track backup health.

Azure Backup reduces infrastructure management while providing centralized policies, security controls, and restoration capabilities.

Azure provides several complementary backup and recovery solutions:

• Azure Backup: Creates recovery points for virtual machines, files, databases, and other supported workloads. It is used to recover from deletion, corruption, ransomware, or operational errors.
• Azure Site Recovery: Replicates machines to another region or recovery location and orchestrates failover. It is mainly used for business continuity and disaster recovery.
• Azure Storage redundancy: Maintains additional copies of storage data within or across regions. It improves durability but is not a replacement for backup because accidental deletion or corruption may be replicated.
• Azure Files snapshots and backup: Provide point-in-time recovery for file shares, depending on the configured protection method.
• Database-native services: Azure SQL Database and other managed databases provide automated backups and point-in-time restoration features.
• Application-consistent backup: Coordinates with applications to improve transactional consistency during recovery.

The solutions differ as follows:

• Use Azure Backup for long-term retention and item or workload restoration.
• Use Site Recovery when rapid service restoration and regional failover are required.
• Use storage redundancy for infrastructure-level durability.
• Use database-native recovery for transaction-aware database restoration.

A complete strategy should define:

• Recovery Point Objective: The acceptable amount of data loss measured in time.
• Recovery Time Objective: The acceptable time required to restore service.
• Retention, regulatory, encryption, immutability, and geographic requirements.

For critical systems, backup and disaster recovery should be combined rather than treated as interchangeable solutions.

The procedure for configuring virtual machine backup is:

1. Review prerequisites: Confirm the virtual machine region, subscription, supported configuration, permissions, and backup requirements.
2. Create a Recovery Services vault: Specify the subscription, resource group, vault name, and region. The vault should normally be in the same region as the protected virtual machine.
3. Configure storage redundancy: Choose the supported redundancy option before protection is enabled, according to business requirements.
4. Review vault security: Configure soft delete, immutability where required, multifactor authorization or Resource Guard for critical operations, network controls, and encryption settings.
5. Create or select a backup policy: Define backup frequency, schedule, instant restore retention where applicable, and daily, weekly, monthly, or yearly retention.
6. Discover and select the virtual machine: Open the vault backup configuration, choose Azure Virtual Machine as the workload, and select the required VM.
7. Enable backup: Associate the VM with the selected policy. Azure installs or updates the VM backup extension when required.
8. Run an on-demand backup: Use Backup now to create an initial recovery point and specify its retention date.
9. Monitor the job: Verify the backup job status in the vault, Backup Center, or Azure Monitor.
10. Validate recovery points: Confirm that recovery points are available and review their consistency type.
11. Test restoration: Perform a controlled restore test to verify that the VM, disks, network settings, and application data can be recovered.
12. Configure alerts and reports: Enable notifications for failed backups, missed backups, deletion attempts, and other critical events.

Backup is complete only when recovery points are successfully created and restoration has been tested.

Azure Backup provides multiple restoration approaches for protected virtual machines:

• Create a new virtual machine: Creates a new VM from a selected recovery point. It is useful when the original VM is unavailable or when an isolated recovery copy is required.
• Restore disks: Restores managed disks and provides deployment information. Administrators can inspect the disks, customize the VM configuration, or create a VM manually.
• Replace existing disks: Replaces the disks of the original VM using a recovery point. It is useful when the VM configuration should be preserved but its disks must be rolled back.
• File recovery: Mounts or exposes a recovery point so that individual files and folders can be copied without restoring the complete VM.
• Cross-region restore: When supported and properly configured, restores data in a secondary Azure region. It is useful during regional failures or recovery testing.

Before restoration, administrators should select the correct recovery point, verify application consistency, plan network settings, check encryption requirements, and ensure sufficient permissions. After restoration, they should validate boot status, applications, connectivity, security settings, and data integrity.

A secure Azure virtual machine backup operations plan should include the following controls:

1. Governance and access

• Assign backup permissions through narrowly scoped RBAC roles.
• Separate backup administration from subscription ownership and workload administration.
• Use privileged identity management for temporary privileged access.
• Enable multifactor authentication and approval for critical operations.

2. Backup configuration

• Create policies that satisfy business retention requirements.
• Define Recovery Point Objective and Recovery Time Objective for each workload.
• Choose appropriate vault storage redundancy.
• Use application-consistent backups where transactional consistency is required.

3. Ransomware and deletion protection

• Enable soft delete and enhanced soft delete where supported.
• Enable vault immutability when backup data must not be altered or deleted before retention expires.
• Use Resource Guard or multifactor authorization for critical vault operations.
• Restrict public network access and use private connectivity where appropriate.
• Monitor attempts to stop protection, delete backup data, or modify security settings.

4. Monitoring and reporting

• Use Backup Center and the Recovery Services vault dashboard.
• Configure Azure Monitor alerts for failed, delayed, or missed backups.
• Send diagnostic logs to a Log Analytics workspace.
• Review policy compliance, backup jobs, and protected-item health regularly.

5. Recovery testing

• Schedule periodic file-level and full-VM restore tests.
• Restore into an isolated network to prevent production conflicts.
• Measure actual recovery time and compare it with the required objective.
• Verify operating system startup, application functionality, access controls, and data integrity.
• Document and correct all recovery test failures.

6. Troubleshooting

• Check the backup job error code and recommended action.
• Verify VM agent and backup extension health.
• Confirm network connectivity to required Azure service endpoints.
• Review disk, encryption, snapshot, and application-writer issues.
• Validate permissions, policy assignment, vault configuration, and resource locks.
• Retry the job only after correcting the underlying problem.

A backup strategy is reliable only when it combines protected recovery points, restricted administration, continuous monitoring, and regularly tested restoration procedures.