Cloud-native security architecture principles and controls
Building a sound cloud security framework is challenging, and it's even more so when implementing a cloud-native architecture. Here are steps you can take to make the job easier.
The past few years have found security teams struggling to define a sound cloud security architecture.
Simply put, a cloud security architecture is a security strategy that defines how an organization secures and protects data and applications in the cloud. The emergence of multi-cloud made things more difficult. Now, with cloud-native becoming increasingly popular, the task is further complicated.
Principles of a cloud-native security architecture
There are a few core principles organizations should keep in mind and include when building a cloud-native security architecture:
- Build in security at every layer. Defense in depth still applies in the cloud. A layered defense model still proves more effective than one where only minimal layers of security controls exist. In many ways, a cohesive security framework can also translate to implementing a blended combination of preventive, detective and response-based controls and capabilities.
- Exploit modular objects and elements. In a cloud-native control model, security and cloud engineering teams can build reusable policies and control definitions for network security, identity and access management (IAM), and workload configuration with images and package repositories.
- Design for failure and resilience. Because the cloud is a programmable and flexible software construct, any controls not properly implemented or that fail can be automatically remediated to ensure security and availability continuity.
- Design for elasticity. Cloud deployments are rarely static. Workloads and assets constantly change, which means security and engineering teams have to scale quickly as assets and utilization shift. Fortunately, autoscaling capabilities are readily available in all major PaaS and IaaS environments to prevent performance degradation and outages from occurring.
Cloud-native security controls
By putting the aforementioned principles into action, security teams can design a strong cloud-native security architecture that encompasses the following critical control areas:
- Network security. Network security in a cloud-native architecture includes core network access controls, such as firewall policies -- for example, security groups in AWS, network security groups in Azure and virtual private cloud firewall rules in Google Cloud Platform -- and network flow logs. Where available, network mirroring to send traffic to monitoring systems is suggested as well.
- IAM. In many ways, IAM policies are the most essential element of a core cloud security architecture. Every asset or service has some identity. IAM policies dictate what services and assets can talk to each other. User and service account access policies are also critical to define.
- Data security. Because cloud deployments include various types of storage -- among them databases, blob storage and data lakes -- defining and implementing an encryption and key management strategy for all cloud provider environments are critical. All major cloud providers include a native key management and secrets storage service, so this is a must-do for a cloud-native security architecture. Be sure to define key rotation cycles, permissions and logging for all updates. Most types of cloud storage include native encryption as well, making this easier to implement than ever. If cloud data discovery and monitoring are available, they should also be implemented.
- Workload security. Workload security typically consists of VM and/or container images, as well as approved package lists and definitions in repositories for use in containers and other cloud-native workloads. These are likely updated frequently, but all images and package definitions have identifiers in the cloud that can easily be tracked and controlled.
- Monitoring and intrusion detection. All major cloud environments have API request logging -- for example, AWS CloudTrail, Azure Monitor and Google Cloud's operations suite (formerly Stackdriver). These should be enabled to send logs and events for all API-based events to a central monitoring platform. Many providers also offer detection guardrail services, such as Amazon GuardDuty, Azure Security Center and Google Cloud Security Command Center. These tools often provide additional insights into suspicious and malicious activity in the cloud.
- Vulnerability management. If available, vulnerability management scanning and validation services should be enabled. These are likely to include workload scanning with tools such as Amazon Inspector and image scanning with container image scans in services such as Amazon Elastic Container Registry.
This is just the beginning…
It's impossible to describe an all-encompassing cloud-native security architecture in a short article, but these are the primary areas all teams should focus on.
To codify and maintain these controls, examine a tool such as the open source Terraform. It offers a way to implement a centralized and cloud-agnostic infrastructure as code (IaC) foundation. Security and cloud engineering teams should collaborate to first define security and control standards and then implement guardrails, IaC controls, and other mechanisms and monitor them continuously.
