Cloud Security Implementation | Award-Winning Project

Overview

Azure Cloud Security Implementation is a hands-on cloud security lab I completed as part of WGU's D485 Cloud Security Implementation course. The project focused on securing an organization that was migrating from on-premises infrastructure to Microsoft Azure while dealing with weak access controls, unverified backups, outdated security practices, and regulatory requirements.

I also received a WGU Excellence Award for exemplary work in Cloud Security, Task 1, recognizing the quality of the project and its supporting documentation.

View the Full Report →

Rather than only documenting recommended improvements, I configured several of the controls directly in Azure. The work focused on three practical areas: controlling who could access cloud resources, protecting sensitive keys and secrets, and establishing a consistent backup and recovery strategy for Azure virtual machines.

The environment used an Infrastructure as a Service (IaaS) model, which made the shared-responsibility boundary important. Azure manages the underlying infrastructure, while the organization remains responsible for areas such as operating-system security, application security, identities, permissions, data protection, and workload configuration.

Problem / Motivation

The scenario began with an Azure environment that had several security gaps. Departmental permissions were incorrectly scoped, users could potentially access resources outside their teams, backups had not been verified, and the organization's vulnerability-management posture had fallen behind.

The goal was to improve the cloud security posture while preserving the flexibility of Azure IaaS. I approached the environment by translating the scenario's security and recovery requirements into practical Azure controls.

The project also required considering regulatory expectations such as FISMA, NIST SP 800-53, and PCI DSS. Those frameworks helped guide decisions around access control, encryption, backup, monitoring, and recovery.

Core Features

Department-Scoped Access Control

I configured Azure role assignments around departmental resource groups so Marketing, Accounting, and IT resources could be managed within defined security boundaries.

The important part was not simply assigning a role. Permissions were scoped to the appropriate Azure resource group, reducing unnecessary cross-department access and reinforcing separation between teams.

Key Vault Access Segregation

I used Azure Key Vault access policies to separate access to departmental keys, secrets, and certificates.

This adds another security boundary beyond general resource-group permissions. Access to an Azure resource does not automatically mean a user should be able to retrieve or modify the sensitive cryptographic material associated with another department.

Backup and Recovery Configuration

I created a centralized Azure backup policy named SWBTL with a daily 7:00 PM Eastern schedule, three days of instant-recovery snapshot retention, and 45 days of daily recovery points.

I then enrolled the Accounting, IT, and Marketing virtual machines into that policy so the environment used a consistent recovery configuration instead of treating each system independently.

The captured VM status showed the machines enrolled with their initial backups still pending, so the project demonstrates backup-policy configuration and enrollment rather than a completed restore test.

Security and Compliance Analysis

The implementation was supported by a broader assessment of the cloud environment. I evaluated the IaaS shared-responsibility model, identified risks around operating-system security, data protection, and application security, and documented recommendations for vulnerability management and disaster-recovery testing.

The project also considered ransomware, insider threats, and DDoS attacks and mapped appropriate defensive controls to each scenario.

Resource-Scoped Azure RBAC

One of the central security problems in the scenario was excessive access between departments.

I addressed that by structuring permissions around Azure resource-group boundaries. Marketing and Accounting identities were associated with their respective resource scopes, while IT required broader administrative capability for infrastructure and backup responsibilities.

This demonstrates a practical difference between simply granting a role and designing the scope where that role applies. The resource boundary becomes part of the authorization model.

For a cloud environment, that separation matters because a permission that is appropriate inside one resource group can become significantly more powerful when assigned at a subscription-wide level.

Key Vault Recovery Protection

Access control protects a Key Vault from unauthorized use, but it does not fully address destructive actions performed by an authorized or compromised identity.

To strengthen recovery, I enabled Azure Key Vault soft delete and purge protection. Soft delete preserves deleted objects for a retention period, while purge protection prevents those objects from being permanently removed before that retention period expires.

This is useful in both accidental-deletion and malicious-administrator scenarios because the recovery window cannot simply be bypassed through an immediate purge.

Centralized VM Backup Policy

The scenario required more than simply turning backups on. Recovery behavior needed to be predictable and consistent.

I created a centralized Azure backup policy with a defined schedule and separate short-term and longer-term retention windows. The policy runs daily at 7:00 PM Eastern, retains instant-recovery snapshots for three days, and keeps daily recovery points for 45 days.

The Accounting, IT, and Marketing virtual machines were then associated with the same policy.

This configuration establishes the recovery policy, but it should not be confused with proof of a successful disaster-recovery exercise. The project separately recommends regular backup and restore testing as an additional control.

Technical Implementation

Azure Resource Groups provided the primary administrative boundaries between departments. Azure RBAC and IAM role assignments controlled which identities could manage resources within those boundaries.

Azure Key Vault was used for departmental key, secret, and certificate access, with soft-delete and purge-protection settings added to improve resilience against destructive actions.

Azure Backup provided the recovery layer. A shared backup policy defined schedule and retention behavior, and the virtual machines were associated with that policy through Azure Backup.

The project also documented the IaaS shared-responsibility model. Azure secures the underlying cloud infrastructure, while workload-level responsibilities such as operating-system hardening, application security, permissions, encryption configuration, and data protection remain with the organization.

The report recommends additional controls including customer-managed keys, TLS certificate management, continuous vulnerability management, endpoint protection, DDoS protection, and recurring disaster-recovery testing. Those recommendations were not presented as completed implementations unless configuration evidence was available.

Architecture / Tech Stack

Cloud Platform:
Microsoft Azure, Infrastructure as a Service (IaaS)

Identity & Authorization:
Azure RBAC, Azure IAM, Resource Groups

Key Management:
Azure Key Vault, access policies, soft delete, purge protection

Compute:
Azure Virtual Machines

Backup & Recovery:
Azure Backup, centralized backup policies, recovery-point retention

Security & Governance:
NIST SP 800-53, FISMA, PCI DSS, CIS Controls, Microsoft Cloud Security Benchmark concepts

Summary

• Used Azure resource scopes as part of the authorization design instead of treating role assignment and scope as separate concerns.
• Extended departmental isolation into Key Vault so access to cloud resources and access to sensitive cryptographic material could be controlled independently.
• Combined soft delete and purge protection to preserve a mandatory recovery window for deleted Key Vault resources.
• Standardized VM recovery behavior through one backup policy with explicit schedule and retention settings.
• Kept implemented controls separate from recommended future controls so the documented security posture reflects what was actually configured.