The key to creating a cloud security architecture strategy, is to obtain and integrate tangible business requirements including security policies, legal and regulatory requirements into the overall strategy and map them end to end with every artefact. Of equal importance is the integration with the organisations current processes, including for example, the classification policies and risk management methodology.
Pulling all this together can be done quickly and tangibly utilising the Toolkit, which will enable you in creating a useful listing of all your key stakeholders and locations of key processes and policies and standards, bringing everything closer to your fingertips rapidly.

If the organisation has not already selected the CSP(s) or model(s), then you need to support them based on the business requirements and enterprise architecture planning.

Key Security Architecture Strategy Artefacts:

  • Creation of a security architecture blueprint/HLD encompassing all security controls necessary to protect the organisations and customers assets.
  • Creation and implementation of cloud security principles, standards and patterns.
  • Provision of security governance through TDA and technical security evaluations/risk assessments.
  • Detailed or low level designs to enable the deployment of security controls as part of an overarching security program of work, reusing or augmenting where feasible artefacts already deployed, and introducing new technology and processes where necessary.

Example of HIGH LEVEL Cloud Security Architecture View:

Cloud service models:

Key Security Architecture Artefacts:

  • Perimeter security; CASB, Anti-DDoS, WAF, DLP, API Security
  • PKI management and automation (encryption of ALL data at rest and in transit)
  • Secrets management on premise (PAM) and in cloud
  • Security log management (SIEM)
  • Compute, Storage and Database security; endpoint protection (AV, IPS, Hardening)
  • Centralised identity and access management (internal and external)
  • DevSecOps and security operations integration and operability.

If you’re not already using ACM PCA, then you should be.

AWS has some of the best thought out and implemented cryptographic controls available. Leveraging ACM PCA will enable you to provision end to end TLS channels beyond the ELB (ALB and NLB). This is a managed service from AWS which works excellently, no more self management of certificates (think key management lifecycle processes, including rotation….), once it’s enabled the API’s provision the functionality to enable automation.

If your stuck deciding on whether to integrate it with your current PKI, stop thinking and break away from this! AWS is fully certified to FIPS 140-2 standards (and plenty of others) therefore you should be looking to leveraging it as the authoritative CA for everything you deploy into AWS in addition to KMS and ACM. Don’t confuse this with externally facing services such as web-services – use ACM for those public certificates or your preferred 3rd party CA (if you think your still stuck in legacy dinosaur land).

Ultimately the crypto in AWS is fully integrated with the rest of the AWS technology stacks which starts to obsolete the notion of running your own expensive PKI and management teams.

Keys are protected in an HSM’s owned and managed by Amazon. Here’s the actual device and specifications: https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3009.pdf , NIST FIPS140-3 Validation:https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/3139 and certificate https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/certificates/FIPSConsolidatedCertFeb2018.pdf (3139 – AWS KMS HSM, the same device for ACM/PCA)