In a recent episode of the ScaleToZero podcast, we sat down with Rowan Udell, an AWS specialist with over a decade of hands-on experience and author of the “Practical AWS IAM Guide.” Rowan, an AWS Community Builder, shared invaluable insights into navigating the complex cloud security landscape, particularly focusing on AWS Identity and Access Management (IAM). This article summarizes our engaging conversation, highlighting key takeaways for organizations aiming to enhance their cloud security posture without compromising developer productivity.
You can read the complete transcript of the epiosde here >
The Evolution of Cloud Security: From “Should We?” to “How Securely?”
Rowan began by reflecting on his journey in the cloud, noting that he started over a decade ago, which offered the unique advantage of learning as the cloud evolved. In the early days, discussions often revolved around whether to adopt the public cloud. Thankfully, these fundamental conversations have shifted. Today, the focus is on how to effectively utilize cloud services, especially in a secure manner. As Rowan highlighted, the cloud has become a de facto standard for building solutions, with its immense benefits for on-demand workloads and scalability.
The Golden Rule of IAM: No Human Access to Production Accounts?
A central theme of our discussion was the principle, championed by AWS’s Chad Lawrence, that “humans do not need access to production cloud accounts.” While this is an aspirational “golden rule” for organizations, Rowan emphasized the nuance required in practice. For many, achieving this state isn’t an overnight switch; it’s a journey that depends on an organization’s maturity level. Business needs often take precedence, and abruptly cutting off production access can hinder operations, deployments, and bug fixes.
The crucial first step is gaining visibility into why humans are accessing production environments. AWS Identity Center is a powerful tool for centralizing identities across an organization, providing a clear audit trail of who did what, where, and when. This visibility allows organizations to identify underlying issues, such as a reliance on manual changes for deployments, and then implement solutions like infrastructure as code or increased automation.
Rowan also highlighted the importance of moving from long-term to short-term access keys to reduce the window of potential issues. This gradual approach ensures value delivery throughout the security maturity journey.
Beyond Identity Center: Leveraging AWS Organizations, SCPs, and RCPs
Beyond Identity Center, Rowan strongly recommended leveraging AWS Organizations. While it used to be challenging to manage AWS accounts and their connections, AWS Organizations, along with Service Control Policies (SCPs) and the more recent Resource Control Policies (RCPs), provide powerful tools for defining guardrails and managing access at an organizational level.
AWS accounts act as ownership groups, providing a “blast radius” for permissions. If an administrator has access to one account, their actions are confined to that account, minimizing impact on other environments like production. Many older AWS customers, pre-Organizations, suffer from having too many resources and teams in a single account, leading to complexity and security challenges. SCPs and RCPs are critical as they override individual account settings, allowing for robust controls like disabling root accounts or preventing backup deletions, even for administrators. These features are vital for maintaining a strong security posture.
Measuring ROI in Security and the “Least Privilege, Maximum Effort” Principle
A common challenge for security teams is quantifying the return on investment (ROI) for security initiatives, as security is often a non-functional requirement. The cost of an outage can be significant, impacting customer trust and service level agreements (SLAs), but translating this into a precise monetary value is highly context-dependent.
From an IAM perspective, Rowan suggested focusing on measurable metrics like reducing the number of IAM users with excessive permissions. While challenging to quantify ROI in the absence of existing problems, it becomes clearer when security measures solve recurring issues, such as one team inadvertently breaking another’s roles.
Rowan also discussed the statement by Joseph South, a principal cloud security engineer, who noted that the ability to create users and roles at will is both an advantage and a downfall of cloud IAM. Rowan likened IAM to a powerful tool: it can be used for building or destroying, depending on how deliberately it’s wielded. He admitted to his own early oversight in not paying enough attention to the permissions granted to serverless functions, often giving them overly broad access.
This led to the critical concept that “identity is the new perimeter.” Historically, networks were the primary focus of security. In the cloud, the right identity can manipulate the network or perform virtually any action. This underscores the importance of permissions boundaries, which act as a second layer of defense, restricting the maximum permissions a role can have, even if created by a developer. While challenging, a simpler approach can be to give developers their own AWS accounts, allowing them to manage their own messes within a contained environment.
The discussion culminated with a powerful quote, attributed to Eric Brandwine: “Least privilege equals maximum effort.” Achieving least privilege in AWS is incredibly challenging and requires a deep understanding of necessary permissions. Moreover, it’s not a one-time task; as businesses evolve and the cloud itself changes, permissions must be continuously monitored, optimized, and revised.
Just-in-Time Access: An Advanced Security Strategy
The podcast also delved into “just-in-time” (JIT) access, a highly advanced strategy that minimizes standing access to environments like production. JIT access relies on a high level of automation, where individuals request access only when needed, for a predefined window, creating a clear audit trail. This significantly reduces the risk of accidental deletions or unauthorized access, which are unfortunately common causes of incidents. While not suitable for early-stage startups due to the associated cost and effort, JIT access is an excellent long-term goal for maturing organizations.
Understand What is Just-In-Time Access >>
Securing Sensitive Data: A Healthcare Startup’s Challenge
Addressing a question from a security leader at a remote-first healthcare startup, Rowan emphasized the paramount importance of knowing exactly where all sensitive data resides. Without this precise knowledge, effectively securing it becomes impossible, as different data locations require different protection strategies. He cited AWS database encryption libraries as an example of readily available solutions that encrypt data client-side, ensuring that even administrators in the AWS console only see masked values. This highlights that many data security challenges have existing, well-tested solutions, eliminating the need to “reinvent the wheel.”
