Principle of Least Privilege with AWS IAM Identity Center in a Multi-Account setup

A talk from the AWS user group in Berlin, Germany. A short overview of how to achieve the principle of least privilege with AWS IAM Identity Center in a Multi-Account setup.

Transcript

1. Nico Schilling Client Technology Lead – Automotive https://www.linkedin.com/in/nicoschilling/ Welcome AWS Usergroup Berlin! Great to have you with us!
2. SKILLS AND EXPERIENCE GLOBAL SCALE SOFTWARE-ENABLED DELIVERY FANATICAL EXPERIENCETM Americas EMEA APJ 4,600+ Employees 1,100+ Employees 1,200+ Employees 120 Countries 40 Data centers 168 PB Storage managed 6,900+ employees with 11,000+ technical certifications Certifications Talent Awards 53 NPS 120k+ clients 12M+ Hours of development to date $1B+ In investments 8 Years developing unique IP Solution automation Self-healing deployed to customers AI automation AI-driven management for multi-tenants Intelligent automation Highly efficient customer support Top Asia-Pacific Managed Cloud Services Provider Leader, Magic Quadrant for Public Cloud Infrastructure Professional and Managed Services, Worldwide 2018 2 Rackspace Technology at a glance
3. TOP TALENT BACKED BY RECOGNIZED EXPERTISE Delivered with expertise enabled by automation 3 2,000+ Cloud Professionals 2700+ AWS Certifications 20+ Years of Hosting Experience 14 AWS Competencies Cloud Migration – Data & Analytics -DevOps – Machine Learning - IoT Leader Magic Quadrant for Public Cloud Infrastructure Professional and Managed Services, Worldwide All-in APN Consulting Partner Migration Partner of the year (2021) Infrastructure (2019) Migration (2018) Rackspace IP • AWS Enhanced Architecture Review • ITSM automation with Rackspace Fabric • Landing Zone Automation • AWS Data Discovery and Data Platform Foundations AWS Cloud Expertise • Cloud Transformation approach that builds on AWS Cloud Adoption Framework • Application and Infrastructure Modernization based on AWS MAP • AWS reference implementations based on AWS Well Architected Framework • Cloud Data Architecture and migrations for OLAP & OLTP workloads • Cloud Native Application Development and IoT
4. 4 Advise Transform Manage and Optimize MANAGED SERVICES AND ELASTIC ENGINEERING PROFESSIONAL SERVICES Application Modernization Roadmap Application Migration Analytics & Applied AI Cloud Strategy Architecture Roadmap Cloud Security Advisory & Assurance Cloud Native Application Development Cloud Data Migrations Platform Migrations Cloud Platform Architecture & Engineering Identity & Access Management Zero Trust & Next Gen Networking IoT Platform Design & Development Data & AI Strategy & Roadmap Application Security & DevSecOps Cloud Data Platform SERVICE LINES Cloud data Cloud platform Cloud security Cloud apps Multicloud Engineering & Optimization Modern Operations Detection & Response Rackspace Public Cloud Solutions
5. Principle of Least Privilege with AWS IAM Identity Center in a Multi-Account setup
6. "The principle means giving a user account […] only those privileges which are essential to perform its intended function. For example, a user account for the sole purpose of creating backups does not need to install software: hence, it has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked. […] The principle of least privilege is widely recognized as an important design consideration in enhancing the protection of data and functionality from faults (fault tolerance) and malicious behavior.“ The Principle of Least Privilege 6
7. AWS knows roughly four ways to define access via identity-based policies: •Actions -> What you can do or not (individually, in a group or per service) •Resource -> On what you can do something or not •Effect -> If actions are allow or deny •Condition -> Additional context based conditions The Principle of Least Privilege on AWS 7
8. In reality it can look something like this: The Principle of Least Privilege on AWS 8
9. „You can think of AWS accounts as isolated resource containers: they offer workload categorization, as well as blast radius reduction when things go wrong.“ •250 Business Projects => 500 AWS Accounts •All users are handled in a central IDP •No common baseline in terms of AWS service usage, project structure or operating style (e.g., DevOps vs central operations) •The cloud platform within the customer only provides as little as possible •Security want to apply the principle of least privilege at least on service level •Everything must be a self-service to ensure speed and agility of business projects AWS Multi-Account Setup 9
10. User Access in a Multi-Account Setup 10 Project A - DEV Project A - Production Project B - DEV Project B - Production Central User Account Usergroup PowerUser Administrator PowerUser PowerUser PowerUser Administrator Microsoft AzureAD What they have in common? => Role definition in the AWS account but mostly centrally controlled
11. AWS IAM Identity Center 11 „AWS IAM Identity Center helps you securely create or connect your workforce identities and manage their access centrally across AWS accounts and applications. IAM Identity Center is the recommended approach for workforce authentication and authorization on AWS for organizations of any size and type.“ Based on IDP Group Memberships
12. Let‘s look into the details…
13. The AWS IAM Identity Center has one central configuration object: the permission set. It connects: •The IDP group •The actual policy with permissions •The AWS member account The policy must be in the IAM IC account and is the same for all member accounts. AWS IAM Identity Center – Technical View 13 AWS IAM Identity Center Account (delegated administration) ViewOnly PowerUser Administrator
14. AWS IAM Identity Center – Technical View 14 AWS IAM Identity Center Account Project A - DEV PowerUser Administrator Nico • „Project A – Dev“ - Administrator Permission Set: Administrator IAM Policy: Administrator The central definition of permissions leds to the same permissions for everyone / no polp.
15. AWS IAM Identity Center – Technical View 15 AWS IAM Identity Center Account Project A - DEV PowerUser Administrator Project B - DEV PowerUser Nico • Project A – Dev • Project B – Dev Alex • Project B – Dev ViewOnly Alex Group memberships: • Project B – Dev - ViewOnly Nico Group memberships: • Project A – Dev – PowerUser • Project A – Dev – Administrator • Project B – Dev - Administrator Microsoft AzureAD Regular Sync ViewOnly PowerUser Administrator SAML
16. AWS IAM Identity Center customer managed policies (CMPs) 16 AWS IAM Identity Center Account Project A - DEV Permission Set: DevOps IAM Policy: DevOps Project B - DEV IAM Policy: DevOps The permission set links to a member account IAM policy that can be edited by the member accounts and can be different. Project IAM-Admin Project IAM-Admin
17. The Technical Workflow to Define a Custom Role 17 AWS IAM Identity Center Account Project A - DEV Microsoft AzureAD 1. Create new IDP Group: AWS-projecta-dev-devop s 2. Create a new IAM policy: awsiamic-devops AWS IAM Identity Center IAM Policy 3. Create a permission set and link IDP Group, AWS Account and IAM Policy in it: devops
18. The Technical Workflow to Define a Custom Role 18 Project A - DEV Microsoft AzureAD 5. Add users to new IDP group AWS-projecta-dev-devops 4. Projects IAM-Admin adds permissions to predefined IAM policy awsiamic-devops IAM Policy
19. The AWS blog provides a very useful guide for a first example implementation and some more technical details: https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanc ed-use-cases/ AWS Useful documentation 19
20. The Security Side of Things
21. AWS brings some helpful services on member-account level to be used by projects to check on themselfs: Access Administrator and Access Analyzer Security View – How to Ensure the Principle of Least Privilege 21
22. AWS IAM Access Analyzer or 3rd party solutions can help with an organization-wide view. They can help with: •Get a more comprehensive view of the whole organization to understand how projects are using IAM •After how many days are permissions „outdated“ •Define “no-gos“: •General wildcards •Access outside of the own organization •Cross-account access •Giving more precise guidance on boundaries from security side •Remediation in any form and shape Security View – How to Ensure the Principle of Least Privilege 22
23. What are some key considerations while using AWS IAM Identity Center with custom policies / custom permission set? What worked good for us? •Projects can now define the permission for each project role (e.g. application developer, operations, 3rd-party) •Security can now govern if access to member accounts is overprivileged What are good next steps for the product? •Enable the usage of AWS Managed policies (custom roles insteadt of custom policies?) •Eliminate the „permisson set“ object for member-account driven permissions/ custom policies (CMPs) •Eliminate the sync with the IDP – use JIT and SAML attributes to create user and get group memberships Learnings 23
24. Rackspace Technology Rackspace Germany GmbH Neuer Wall 71 D-20354 Hamburg Sales: 0800 7238749 Support: 0800 7238750 www.rackspace.com/de Copyright © 2021 Rackspace | Rackspace® Fanatical Support® and other Rackspace marks are either registered service marks or service marks of Rackspace US, Inc. in the United States and other countries. Features, benefits and pricing presented depend on system configuration and are subject to change without notice. Rackspace disclaims any representation, warranty or other legal commitment regarding its services except for those expressly stated in a Rackspace services agreement. All other trademarks, service marks, images, products and brands remain the sole property of their respective holders and do not imply endorsement or sponsorship. Thank you