New Webinar: Leaky S3 Buckets- How to Simplify Access and Stop the Spill·Watch now
Blog

Secure Access Management for Your Cloud-Native Resources

Organizations are quickly turning to cloud-native as the new model for application development and for provisioning and managing underlying cloud infrastructure services. One common approach is to design applications as loosely coupled microservices, run them in containers, and use services like Helm, Kubernetes, ECS, or Fargate to orchestrate them. Infrastructure is then managed and configured through text files in a human and machine-readable format.

With the advent of this new model, organizations need to adopt fresh strategies to keep their applications, workloads and data secure. While most IT and security teams understand these concepts at a high level, it is crucial for engineering teams to embrace them as well, since they are the ones actually responsible for delivering applications and infrastructure securely. 

In this blog post, we outline a design pattern that engineering teams can use to help make sure that only the right people have access to the right resources. We also outline a reference implementation.

Identity as the Cornerstone of Cloud Security

Adoption of the cloud has forced organizations to throw away large parts of their existing security models. With cloud workloads in the picture, the old perimeter of the on-prem data center has become obsolete, replaced by a more complex environment where it’s difficult to enforce IP address-based access rules, and where barriers at known ingress/egress points have become almost meaningless. 

This complexity is unavoidable due to the ephemeral nature of modern services. Multi-tiered architectures have been replaced with microservice-based architectures. Long-lived virtual instances have been replaced with ephemeral containers. Changes that used to be executed through helpdesk tickets are now automated as part of continuous delivery automation. Web workers are dynamically created during times of high load, and automatically spun down afterwards. A database reporting service spins up once a day to ingest data, and disappears when finished.

Impact on Security

Implementing conventional cloud security models became difficult as a result of this more dynamic services environment. Previously, it was possible to restrict access based on IP addresses, ports, and similar strategies like restricting network CIDR ranges. Now it became much more difficult to reason about an architecture that was much more ephemeral, microservice-based, and complex. 

Architectures that are difficult to reason about are difficult to secure. To counter that complexity and fill the gap left by the loss of perimeter-based security models, the notion of identity as the new perimeter grew. Identity-centric security models such as Zero Trust, continuous adaptive risk and trust assessment (CARTA), and Secure Access Service Edge (SASE) became popular.

As the foundation for this new perimeter, Identity and Access Management (IAM) has become a major area of investment in security, with all major cloud platforms providing sophisticated, native IAM solutions for their own services.

Adding this identity-based security layer also countered the complexity of the modern services environment, by giving an easy-to-understand barrier that always intermediates between users, services, and their data. Also, defense in depth grew in popularity, because in a system that has multiple points of failure, it’s also useful to have multiple points of security.

Securely Accessing Your Cloud-Native Resources

For organizations to protect their underlying resources and data from malicious access they need to ensure:

  1. All services accessing a resource must be authenticated, authorized and audited.
  2. Any secrets should never be kept with the service and must be easy to rotate.
  3. All policies should be centralized and allow dynamic updates.
  4. Escalated privileges should be granted on-demand and for a specified time.
  5. All of the above should be managed as code and every action should be auditable.

To make the discussion less abstract, we illustrate below how organizations can use various publicly available services to implement the above model. This architecture shows the families of applications that can be used for each important function, and it lists popular services and frameworks in each. 

Now that we have a concrete, visual idea of our potential architecture, let’s talk through how each goal can be achieved by engineering teams.

  1. All services accessing a resource must be authenticated, authorized and audited.

To achieve this, we must authenticate services using their identity. Identity can be delivered cryptographically through AWS IAM, and verified through AWS STS. (The equivalent can be achieved on other cloud platforms, such as GCP.) Users logging in directly into various services may have their identity retrieved from corporate directory services like Okta.

Then, services must be authorized. In this example, Cyral can provide fine-grained control over what may be accessed within a database, how much, when, and for how long. AWS IAM roles may also be used in concert with Cyral and Vault to describe what type of user an entity is, and therefore what they should be allowed to access.

Then, services must be audited. Cyral provides audit logs and traces that attribute all database queries to specific users and service instances. Boundary provides more generic session recording for SSH, Kube and RDP access.

  1. Any secrets should never be kept with the service and must be easy to rotate.

Most modern logging frameworks make logs nearly instantly available. Many ephemeral applications accidentally log their own credentials as part of logging their configuration. Many companies share logs across departments to help customer success and engineers debug issues. Because of that, passwords must be shrouded, rotated frequently in case they’re leaked, or both. 

To achieve that, end user passwords may be shrouded by using Single Sign-On (SSO) to gain access to applications. This reduces the number of points where user credentials may be leaked. Vault may be used to grant usernames and passwords that are short-lived, but Vault cannot end a session that has already been started. Access management services like Cyral and Boundary can broker the session to underlying resources.

  1. All policies should be centralized and allow dynamic updates.

Centralizing policies into Github adds a level of safety and process to security policy changes. It also enforces that policies are living protocols, rather than arbitrary words written on paper and given to a security auditor. Security policies can be dynamically enforced through the access management layer, eliminating the need to restart infrastructure. 

Open Policy Agent (OPA) is an open-sourced policy engine that enables unified, context-aware policy enforcement across an entire stack. It’s a tool well-suited to both documenting and enforcing security requirements. Through Cyral’s Github integration, these policies can be collaboratively written, versioned, and immediately applied either manually or through a continuous integration tool.

This whitepaper discusses in detail the benefits and process of managing policies as code when determining privileges and permissions for various users accessing different services inside a company.

  1. Escalated privileges should be granted on-demand and for a specified time.

In companies that don’t grant ephemeral privileges, user permission levels tend to rise. An analyst requests access to a database, and is granted it forever. An engineer has pager duty and needs to be able to restart services, and then can restart services even when they’re on vacation.

In contrast, companies that do grant ephemeral access tend to have more stable permission levels. An analyst is granted access to a database for a month, until their project is over. An engineer can restart services for a week while they’re on pager duty.

Services like Cyral and Boundary can grant ephemeral access to resources. Boundary takes a more generic approach and can be used for SSH, RDP and Kube. Cyral covers database queries extensively, with fine-grained control (and alerts) around permissions and activity.

  1. All of the above should be managed as code and every action should be auditable.

Starting in the world of software development, the use of version control systems, coupled with automation, has enabled organizations to automate more of the work they do every day. With automation, actions that once had to be done by hand are now carried out based on a procedure or policy that’s written down as code — infrastructure as code, or policy as code. Version control is a key enabling technology here because it preserves the audit trail of every change in procedure or policy, and because it allows the rollback of changes that turned out to be unwanted.

In the world of services deployment, frameworks like CloudFormation and Terraform support infrastructure as code (IaC). Version control platforms like Github house the “code” (the procedures and policies) and provide an audit log that captures every policy change. Based on this foundation of IaC and version control, Cyral (fully) and Vault (limitedly) support security policy as code

Finally, it’s important to invest in real-time logging and monitoring to detect and alert on any drifts from normal usage and any configuration changes.

Conclusion

Although becoming a cloud-native company tears down many traditional approaches to software security, it also challenges us to evolve to a more holistic approach. Moving to microservices, containers, and continuous integration can be executed safely when an appropriate architecture is selected. 

Consider the following questions in designing or evaluating your organization’s security architecture:

  • Who is our identity provider?
  • Is that identity provider used at all steps?
  • Are access grants to sensitive resources short-lived?
  • When secrets such as credentials are given, are they rotated automatically afterwards?
  • What access manager do we use?
  • What percentage of our resources are protected by these?
  • Do we leverage infrastructure as code?
  • Do we leverage security policy as code?
  • Do our audit logs always include the identity of the person or service instance accessing sensitive data?

These questions can guide a sound security approach.

To learn more about how Cyral can help you with secure access management for your cloud-native resources, you can learn more here.

Identity as the Cornerstone of Cloud Security
Subscribe to our Blog

Get stories about data security delivered directly to your inbox

Try Cyral

Get Started in Minutes with our Free Trial