Identity and Access Management (IAM) has evolved from a back-office IT function to the critical perimeter of modern cloud security. With more than 70% of cloud attacks originating from identity vulnerabilities, mastering IAM is no longer optional—it’s survival.
We sat down with Sneha Malshetti, a Senior Security Engineer at Ethos with over a decade of experience at major enterprises like Credit Karma. Sneha shared her deep expertise on the nuances of multi-cloud IAM, the necessity of automation in scaling access control, and the double-edged sword of AI in security.
You can read the complete transcript of the epiosde here >
What are the key architectural differences between AWS and GCP IAM?
While the core concepts of principles and authorization remain similar, AWS and GCP approach IAM from fundamentally different philosophies.
- Identity-Centric vs. Resource-Centric: AWS is primarily identity-centric, where policies are attached to users, groups, or roles. In contrast, GCP is resource-centric, where permissions (bindings) are often applied directly to the resource (e.g., a storage bucket or project) rather than the identity itself.
- Hierarchy: This is a major differentiator. AWS does not have a strict native IAM hierarchy within the account structure in the same way GCP does. In GCP, if you grant permissions at the root or parent level (Organization or Folder), those permissions automatically trickle down to all child projects. This inheritance can lead to over-privileged access if not carefully managed.
- Customization: AWS relies heavily on creating custom policies JSON documents. GCP provides a robust set of pre-defined roles (like Viewer, Owner, Editor) which are easy to use but often over-privileged.
How do you manage identity federation in a multi-cloud environment?
Managing identities across multiple clouds requires a centralized strategy to avoid silos.
- Role-Based Access Control (RBAC): The foundation is mapping your organizational roles to specific permissions in each cloud.
- Groups over Users: A golden rule for federation is to never assign permissions directly to users. Always assign permissions to groups. If a user moves roles (e.g., from a recruiter to a data scientist), you simply move them from one group to another, ensuring their previous access is revoked automatically.
- Production Access: In GCP specifically, avoid giving anyone direct “Owner” access in production. Use groups to strictly control and review who has this level of privilege.
How can organizations scale RBAC without creating “role explosion”?
Scaling RBAC for a 10,000-person company is vastly different from a 50-person startup. To manage this scale:
- Delegated Permissioning: You cannot manage everything centrally. Delegate approval authority down to managers who understand the context of the access request.
- Dual Approval: For sensitive access (like S3 administrative rights), implement a dual approval system. This requires approval from both the user’s manager (who knows why they need it) and the data owner (who knows if they should have it).
What tools and techniques work best for auditing IAM at scale?
Manual auditing is impossible in large environments. Automation and native tools are essential.
- Access Analyzer: Use tools like AWS IAM Access Analyzer to detect unused permissions. A common threshold is to flag any role where more than 60% of permissions have been unused for 90 days.
- Automation: For lean teams managing hundreds of accounts, build automation that hits cloud provider APIs (like the GCP Recommender API) to pull access data centrally.
- Cost Management: Be mindful of API rate limits and costs associated with high-volume log ingestion and analysis.
How do you handle “Just-in-Time” (JIT) access and prevent privilege escalation?
Static, long-lived permissions are a security risk. JIT access minimizes this window of exposure.
- Role Expiry: Roles should not be permanent residue. Assign expiry dates to permissions, especially for production access.
- Time Limits: A general best practice is a 4-hour limit for privileged access in production and perhaps 8 hours for development environments.
- Automated Break-Glass: To avoid blocking urgent work (e.g., a deployment failure on a weekend), automate break-glass access. If a valid Jira ticket exists for an incident and the requestor is on-call, the system can automatically provision temporary elevated access.
What role do Service Control Policies (SCPs) and boundaries play?
Defense in depth requires strong perimeters to prevent lateral movement and accidental exposure.
- Permission Boundaries: Ensure that no user can create an IAM role with more privileges than they currently possess.
- Region Restriction: Use SCPs to restrict deployments to only the specific regions your business operates in.
- Resource Whitelisting: Use SCPs to whitelist only the specific AWS resources your company uses, preventing developers from spinning up expensive or unapproved services.
- Hard Limits: Be aware of the hard limit of 5 SCPs per account, which requires careful planning of your policy structure.
How is AI reshaping the security landscape?
AI is a double-edged sword, serving as both a powerful tool for security engineers and a potential vector for data leakage.
- Empowerment: AI tools now allow any engineer to understand and remediate security logs by providing step-by-step consolidation and explanation of issues.
- Anomaly Detection: AI is crucial for parsing millions of log records to find anomalies that human analysts would miss.
- The Trust Gap: Despite its power, AI should not be trusted for automated remediation in production. Human verification is still required before applying fixes.
- Data Privacy: A major risk is sensitive data (PII, PCI) leaking into public LLMs. Organizations must set strict guardrails, such as using enterprise versions of tools where data is not used for training, and educating teams on what data is off-limits.
Conclusion
The conversation with Sneha Malsetti highlights that effective identity security is not just about tools, but about architecture and process. Whether navigating the structural differences between AWS and GCP, implementing Just-in-Time access to reduce blast radius, or leveraging AI for log analysis, the goal remains the same: granting the right access, to the right person, for the right time. As cloud environments grow in complexity, the organizations that treat identity as their primary security perimeter will be the ones that succeed.
