Cloud transformation often occurs simultaneously across siloed organizational units and groups, each potentially using a different cloud for their applications and workloads. However, taking inventory of all their cloud resources and building a compliant, secure, simple, and unified strategy has become a common challenge.
It wouldn’t be surprising to see an organization with most of its workloads in AWS using Microsoft 365 and Azure Active Directory while also heavily using Google Cloud GKE and Big Query. On top of that, Oracle Cloud may also be in the mix with some autonomous database offerings. As cloud adoption matures in an organization, and as smaller cloud providers gain traction, the mix of services and cloud platforms becomes incredibly diverse and complex. In light of these challenges, organizations must still find ways to govern and secure their entire cloud infrastructure.
The answer? A framework that works across all clouds to unify detection, prioritization, and remediation of the most impactful risks facing the organization.
Identities and Authentication Keys
Diving into a use case around cloud identity authentication keys for access, let’s see how you can protect your organization’s crown jewels in your multicloud environment. In the cloud world, identity is perhaps the most critical cloud object to govern, monitor, detect, and remediate. Compromising a cloud identity has the largest blast radius since, frankly, the public cloud is just a bunch of public APIs that respond to authenticated requests.
Authentication keys are cryptographic entities attached to an identity that allow you to issue authenticated API requests from the Internet. Hence, these keys call for the undivided attention of any governance and security strategy. However, each cloud provider defines identity in a different way, with a completely new set of capabilities and risks.
The idea here is to think of an organization that wants to enforce the following policy: “Authentication keys should be rotated every 90 days, and every 30 days if they enable personally identifying information access.” This seemingly simple policy would need to take four different implementations, depending on which cloud it’s using. Additionally, the security admin would need to tailor specific policies, such as limiting the number of concurrent keys (not relevant to AWS) or enforcing expiration dates upon key creation (not relevant for secrets).
The same concept applies when an organization tries to enforce “do not allow public access to storage objects” or “only build workloads from images that are up to date.”
Building, Securing, and Governing the Cloud
While each cloud is unique, foundationally, they are not so different. They all have a concept of a computer instance, object and file storage, and both human and nonhuman identities, each of which can be assigned permissions. As a result, the multicloud infrastructure calls for unification between building, securing, and governing the cloud.
When building cloud deployments, organizations rely on infrastructure as code (IaC) languages like HashiCorp’s Terraform to create a unified approach to address cloud objects. Think of IaC as a higher-level language over the lower-level cloud-specific API calls.
The parallel higher-level language for securing and governing the cloud is the cloud-native application protection platform (CNAPP). CNAPP converges tools like cloud security posture management, cloud infrastructure entitlement management, cloud workload protection platform, configuration management database, and others, providing complete security for your cloud, spanning the cloud development lifecycle from build time to run time. CNAPP provides a single pane of glass for all your cloud environments.
These solutions provide a complete inventory of your cloud assets, as well as visibility into potential security gaps and risks, correlating across a broad range of signals including misconfigurations, vulnerabilities, Internet exposure, excessive permissions, and more.
Through a CNAPP, teams can enable unified detection, investigation, and enforcement of common cloud objects, as well as pitfalls such as exposed storage, unpatched compute instances, and more. Ideally, a single UI workflow allows you to enforce multicloud organization policies such as “block public access for cloud storage” or “isolate compute instances that accept traffic from the Internet and expose a service with critical vulnerabilities.”
Here are additional best practices and recommendations for securing your cloud footprint:
- Decide whether to measure against a security framework like NIST or CIS, or your own internally developed policies. Implement these policies across the development lifecycle, with explicit definition of where to enforce action-blocking guardrails. A CNAPP can help you accomplish this.
- Ensure your security team is diversified in terms of multicloud knowledge, e.g., AWS, Azure, and GCP.
- Implement identity best practices, such as single sign-on and multifactor authentication, via your organization’s existing IAM provider, whenever possible. Avoid the use of cloud-specific local identities to access the cloud from the Internet.
- Define the unified view as a prerequisite for procurement of cloud security tools. Ideally, choose tools that enable a unified approach of enforcing organizational policies across clouds.
Cloud transformation has become a vital initiative for many organizations. As you go through the cloud transformation journey, remember that your approach to security (and the tools you use) must transform as well. Whether you’re unifying siloed tools, security and DevOps teams, different cloud vendors, management, or policies and languages, bringing tools together and enforcing commonalities will benefit your organization in the long run.
Read more Partner Perspectives from Zscaler.
Source: www.darkreading.com