Securing the cloud is hard. But we can make it harder on ourselves than necessary. Each platform has an architecture. Trying to fit the architecture of one platform onto another will always be less optimal than architecting your solution to the target platform. This is why the common recommendation in cloud transformation is to avoid a 'lift-and-shift' approach of replicating a data center architecture directly in a public cloud environment.
Practical considerations may make a 'lift-and-shift' approach inevitable. But we must understand the cost and technical debt - operationally as well as financially - that incurs. Such an approach can make us lose sight of capabilities in the platform that would get better results faster, cheaper and easier to implement.
This also goes for cloud security.
Over decades, we have collectively developed best practices for data centers and IT infrastructure based around trusted networks. These are office or corporate networks connected via private (or at least encrypted) links to remote data centers, with defined ingress and egress points where traffic filtering and controls are implemented.
Remote workers complicated such an architecture, adding VPN to the landscape. Services were added directly accessible from the internet. Hybrid cloud landscapes added yet more complexity. A presentation of such a landscape is shown in this diagram. This is now the reality for almost everybody.
This development has led to concerns about the "death of the network perimeter" and the recommendation to implement Zero Trust Architectures. Getting there is difficult, especially in the middle of cloud transformation, and requires a lot of work in asset inventory and classification as well as new tooling. For larger organizations, getting the basics right necessary for Zero Trust to be effective can be a multi-year project. What do we do in the meantime?
We can look at the problem in a different way. The death of the perimeter and Zero Trust are still based on a network-centric view of the landscape. Public cloud architecture works differently, though. It is based around APIs.
Below is a diagram of how SAP operates public cloud landscapes. Most of SAP's cloud solutions are single-tenant, which means one customer - one cloud account. This provides tenant isolation through the public cloud provider infrastructure, which keeps each (AWS) cloud account, (Azure) subscription or (GCP) project isolated from each other.
Deployments are done through the cloud provider's API, instructing it to create, update or destroy cloud infrastructure through CI/CD pipeline Infrastructure-as-Code (IaC) automation scripts or, if absolutely needed, via the cloud provider's web admin console. This is essentially out-of-band administration. The cloud provider's internal processes manifest the infrastructure in the cloud account as instructed. Audit logs, telemetry and security scans are also collected via the cloud API.
The network, so central in the diagram above, is simply a carrier of encrypted API calls. Of course, it needs to be there, but it can hardly be considered central to the architecture. The death of the perimeter is irrelevant. We just need an internet connection.
Direct connections over SSH to the deployed landscape are generally discouraged, but if needed must go via administration jump hosts, and must come from defined CIDR ranges (such as a corporate network egress point). SAP centrally blocks admin ports from the public internet. If such SSH sessions can be avoided, there is no direct administration of the landscape over the network at all.
What admin users and service accounts can do with the APIs is governed by Identity and Access Management (IAM) and the assigned privileges and roles applied to those accounts. An alternative category name would be Cloud Infrastructure Entitlement Management (CIEM), which applies IAM specifically to public cloud landscapes, if we want to be even more precise. All activity and role assignment changes are recorded in cloud audit logs that can be centrally collected and analyzed.
Network security has a role to play at the internet ingress point for the application and exposed APIs, for instance in web application firewalls (WAF) to protect web applications and API endpoints. But unless further connected to any other networks via cloud network peering, the cloud account is otherwise an isolated island. Its blast radius, from a network perspective, doesn't extend beyond the resources deployed within it.
By looking at cloud security as an IAM problem rather than a networking problem, we reduce the problem space. Managing credentials and authorizations well is a big enough challenge as it is before we add network controls in the mix. Understanding the landscape as one of API calls helps us be smarter about where to focus our detections. Monitoring for network scans won't help us when the attacker is exploring the landscape, establishes persistence and moves laterally through cloud API calls. Cloud API audit logs are much better sources for that.
From this it may also be obvious that 'lifting-and-shifting' an existing security tooling stack to public cloud may prove to be difficult to deploy, expensive and less effective. A defensive approach based on networking access may even grow the attack surface and blast radius through requiring network paths that don't even need to exist.
Zero Trust Architectures are based around the intersection of IAM, detailed asset management and metadata, and network control policies based on those. All three are significant projects on their own to get right, let alone trying to do them all at the same time. At least in areas of public cloud - and aside from other common cloud security challenges like cloud infrastructure misconfigurations and known vulnerabilities - we can safely start with IAM for significant security impact.
Detailed asset management is challenging in any large and complex organization and will take significant time and coordination across teams. Every improvement made here, though, will benefit security functions across the board through better alert and incident attribution, a key component of security compliance reporting and SLA tracking, as well as effective security incident response. It will also help refine IAM. Finally, with reasonable maturity in both IAM and asset metadata in place, implementation of network controls for a Zero Trust Architecture become feasible and effective.
Therefore, look at your cloud environment with an API-centric view and secure your cloud cloud-natively. The more you do, the easier you make it on yourself.
In this day and age of tight security budgets and an uncertain economic climate, it is more important than ever to make maximum use of available resources. The larger your cloud landscape becomes, the more cloud-native approaches and tooling are critical to keep cost down while providing effective protection. We have learned the following principles from experience:
Practical considerations may make a 'lift-and-shift' approach inevitable. But we must understand the cost and technical debt - operationally as well as financially - that incurs. Such an approach can make us lose sight of capabilities in the platform that would get better results faster, cheaper and easier to implement.
This also goes for cloud security.
Network-Centric View of the Landscape
Over decades, we have collectively developed best practices for data centers and IT infrastructure based around trusted networks. These are office or corporate networks connected via private (or at least encrypted) links to remote data centers, with defined ingress and egress points where traffic filtering and controls are implemented.
Remote workers complicated such an architecture, adding VPN to the landscape. Services were added directly accessible from the internet. Hybrid cloud landscapes added yet more complexity. A presentation of such a landscape is shown in this diagram. This is now the reality for almost everybody.
Diagram showing the corporate network with remote workers and cloud connected directly into the corporate network
This development has led to concerns about the "death of the network perimeter" and the recommendation to implement Zero Trust Architectures. Getting there is difficult, especially in the middle of cloud transformation, and requires a lot of work in asset inventory and classification as well as new tooling. For larger organizations, getting the basics right necessary for Zero Trust to be effective can be a multi-year project. What do we do in the meantime?
API-Centric View of the Landscape
We can look at the problem in a different way. The death of the perimeter and Zero Trust are still based on a network-centric view of the landscape. Public cloud architecture works differently, though. It is based around APIs.
Below is a diagram of how SAP operates public cloud landscapes. Most of SAP's cloud solutions are single-tenant, which means one customer - one cloud account. This provides tenant isolation through the public cloud provider infrastructure, which keeps each (AWS) cloud account, (Azure) subscription or (GCP) project isolated from each other.
Deployments are done through the cloud provider's API, instructing it to create, update or destroy cloud infrastructure through CI/CD pipeline Infrastructure-as-Code (IaC) automation scripts or, if absolutely needed, via the cloud provider's web admin console. This is essentially out-of-band administration. The cloud provider's internal processes manifest the infrastructure in the cloud account as instructed. Audit logs, telemetry and security scans are also collected via the cloud API.
Diagram showing how cloud landscapes are managed through the cloud provider API, without being directly connected to corporate network or other cloud accounts at all
The network, so central in the diagram above, is simply a carrier of encrypted API calls. Of course, it needs to be there, but it can hardly be considered central to the architecture. The death of the perimeter is irrelevant. We just need an internet connection.
Direct connections over SSH to the deployed landscape are generally discouraged, but if needed must go via administration jump hosts, and must come from defined CIDR ranges (such as a corporate network egress point). SAP centrally blocks admin ports from the public internet. If such SSH sessions can be avoided, there is no direct administration of the landscape over the network at all.
What admin users and service accounts can do with the APIs is governed by Identity and Access Management (IAM) and the assigned privileges and roles applied to those accounts. An alternative category name would be Cloud Infrastructure Entitlement Management (CIEM), which applies IAM specifically to public cloud landscapes, if we want to be even more precise. All activity and role assignment changes are recorded in cloud audit logs that can be centrally collected and analyzed.
Network security has a role to play at the internet ingress point for the application and exposed APIs, for instance in web application firewalls (WAF) to protect web applications and API endpoints. But unless further connected to any other networks via cloud network peering, the cloud account is otherwise an isolated island. Its blast radius, from a network perspective, doesn't extend beyond the resources deployed within it.
Reducing the Problem Space
By looking at cloud security as an IAM problem rather than a networking problem, we reduce the problem space. Managing credentials and authorizations well is a big enough challenge as it is before we add network controls in the mix. Understanding the landscape as one of API calls helps us be smarter about where to focus our detections. Monitoring for network scans won't help us when the attacker is exploring the landscape, establishes persistence and moves laterally through cloud API calls. Cloud API audit logs are much better sources for that.
From this it may also be obvious that 'lifting-and-shifting' an existing security tooling stack to public cloud may prove to be difficult to deploy, expensive and less effective. A defensive approach based on networking access may even grow the attack surface and blast radius through requiring network paths that don't even need to exist.
Zero Trust Architectures are based around the intersection of IAM, detailed asset management and metadata, and network control policies based on those. All three are significant projects on their own to get right, let alone trying to do them all at the same time. At least in areas of public cloud - and aside from other common cloud security challenges like cloud infrastructure misconfigurations and known vulnerabilities - we can safely start with IAM for significant security impact.
Detailed asset management is challenging in any large and complex organization and will take significant time and coordination across teams. Every improvement made here, though, will benefit security functions across the board through better alert and incident attribution, a key component of security compliance reporting and SLA tracking, as well as effective security incident response. It will also help refine IAM. Finally, with reasonable maturity in both IAM and asset metadata in place, implementation of network controls for a Zero Trust Architecture become feasible and effective.
Therefore, look at your cloud environment with an API-centric view and secure your cloud cloud-natively. The more you do, the easier you make it on yourself.
Easier and More Cost-Effective Cloud Security
In this day and age of tight security budgets and an uncertain economic climate, it is more important than ever to make maximum use of available resources. The larger your cloud landscape becomes, the more cloud-native approaches and tooling are critical to keep cost down while providing effective protection. We have learned the following principles from experience:
- Take an API-centric view of cloud security, rather than a network-centric one
- Understand the value contained in cloud audit logs
- Carefully consider whether your cloud environment really needs a network connection to the corporate network or other cloud landscapes. If not, don't give it one
- If you have to provide direct SSH access, connect through an admin jump host that can only be reached from selected IP ranges
- Focus your Zero Trust Architecture deployment on IAM first, detailed asset metadata second (or run them in parallel) and network controls policies based on those last
- SAP Managed Tags:
