Cloud Security
Cloud Security Implementation
A hardened Azure IaaS landing pattern: scoped roles, protected keys, and backup posture that can be audited against the mapped frameworks.
- Azure IaaS
- RBAC
- Key Vault
- FISMA
- PCI-DSS
- NIST 800-53
Context
A shipping company was moving off on-premises infrastructure onto Azure IaaS. The risk in that kind of migration is that identity, key management, and backup controls quietly get weaker in transit — the lift-and-shift works, and the posture is worse than it was. The brief treated insider-threat scenarios as first-class, with the design mapped to FISMA, PCI-DSS, and NIST SP 800-53.
Approach
Access was scoped by department rather than granted broadly, so a compromised account stays inside one blast radius. Key Vault carried access policies with soft delete and purge protection enabled, which is what stops a deletion — accidental or malicious — from being final. Data was encrypted at rest and in transit, and backups were automated rather than left to a runbook step someone forgets. Each control was mapped back to an 800-53 family so the design could be read against the framework instead of taken on trust.
Outcome
The deliverable is a hardened Azure IaaS landing pattern: scoped roles, protected keys, encrypted data paths, and a backup posture that can be audited against the mapped frameworks. The repository holds the architecture, the RBAC model, and the Key Vault configuration notes.
Scope and caveats
- Client and subscription identifiers are omitted; the write-up covers method and control categories.
- Framework mappings reflect the academic brief, not a completed third-party audit.