Monday, March 14, 2016

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 3

Background
This is the third article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure the Amazon Root account.
In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 

About Amazon AWS Identity and Access Management (IAM)
For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 

Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:


AWS-IAM-BestPractice.png

Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 


This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.

Using Centrify CIS & Active Directory to Secure Amazon's IAM
In this post I describe a framework to leverage Centrify Identity Service  to meet and exceed the Identity Management requirements for Amazon AIM while maintaining the corporate directory (AD) as the single-source of truth. 

AWS-IAM-Concept.png
The example used in this blog post focuses on Active Directory, however, those who are familiar with Centrify know that the user sources can be or any other internal LDAP source, Google Directory, Federated Partner or even Social Identity providers.
The solution outlined below establishes a SAML federation agreement between Centrify Identity Service (CIS) acting as the Identity Provider (IdP) and Amazon AWS IAM acting as as the Service Provider (SP);  Since CIS will be using Active Directory principals as an identity source, AD continues to be the single-source of truth for the enterprise and AD group memberships, AWS IAM Roles and CIS roles can be used to manage entitlements.

Enhanced Objectives
  • Eliminate duplicated administration efforts and align Amazon IAM users with corporate policy
  • Leverage AD Group membership (or CIS Roles) for Amazon IAM provisioning (add/moves/changes/deletions)
  • Leverage AD Group membership (or CIS Roles) and IAM Groups for Entitlement Management
  • Provide SSO to Amazon AWS with minimal federation infrastructure required
  • Enforce Advanced Policies: Require Multi-factor Authentication or Enforce Access from the Corporate Network
  • Limit access to IAM credentials to those with business need-to-know
Planning
Stakeholders
  • Identity and Access lead:  Organizes and coordinates the effort.
  • Security SME: Outlines the security requirements based on policy or risk profile
  • Infrastructure SMEs: Execute the implementation of the tasks
Planning Discussions
Below are planning discussions that can be had around IAM:
  1. What are the services being used in AWS? Will there be a process defined when new services are used?
  2. Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
  3. Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
  4. Will contextual policy be needed?  E.g. restrict access to corporate sites, geo-fencing or time-fencing?
  5. What will be the attestation process for AWS users?  (e.g. AD Group Management or CIS Roles/Reports)
  6. Will Multi-factor authentication be required for IAM users?  What factors (Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
  7. Will approvals be required for IAM access?  (Request/Approval)
  8. Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
  9. Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration? 
  10. Will users be allowed to log in with their AWS password or just with SSO?
  11. How will users be uniquely identified in AWS? (should shortname, email, UPN or another field be used?)
 Our Example
  • The organization uses Amazon EC2 to hosts servers in the cloud
  • There are two types EC2 of users:  Users with Full Access and ReadOnly Users.
  • Users with full access will be managed via AD Security group Membership (AWS-EC2-FullAccess)
  • Users with read-ony access will be requested on-demand (must be approved) via a CIS Role;
  • Another group (AWS-IAM-Managers) can manage IAM in AWS and will approve requests.
  • All users must provide step-up authentication via Token, Email, SMS or Phone to access AWS
  • The implementation will use the Centrify-provided SAML template
  • The Centrify-Provided PKI Certificate will be used for the SAML Assertion
  • Users will be identified in AWS with their Shortname.
 Technical Requirements
  • Active Directory with security groups created and populated
  • Centrify Identity Service Tenant
  • A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
  • An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles

Implementation
This process implies a partial configuration in CIS, followed by the configuration in AWS, finishing-up in CIS again.

Initial Configuration in Centrify Identity Service
Add and Configure the Amazon Web Services (AWS) Console: SAML+Provisioning
  1. In Cloud Manager, navigate to Apps > Add Web App
  2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS Console SAML+Provisioning" template and click Add.
    AWS-IAM-apptemp.png
  3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
  4. In Application Settings:
    - Type your AWS Account ID (if you don't know it, go to "My Account" in AWS)
    - Click the "Download SAML provider metadata document"  link, this will save the XML file in your downloads folder

    AWS-IAM-temp-appsett.png
  5. In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
  6. Skip User Access and Policy (we'll revisit)
  7. In Account Mapping , use the "Use Account Mapping Script" option and type the following:
    LoginUser.Username = LoginUser.Shortname
    This option will send the user's shortname as the identifier.  If there are duplicates, you can switch to mail or UPN.
  8. Press Save, you'll have to return here for adjustments.
Configuration in AWS
Create the Centrify SAML IDP
  1. Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
  2. On the left pane, click Identity Providers and press the Create Provider button on the right
  3. Select SAML in provider type
  4. In provider name type a descriptive name like "Centrify" or "CentrifySAML"
  5. In Metadata Document, browse to the downloads location where the XML file from step 4 above was saved, press Next Step and press Create.
Configure the AWS IAM Roles for the Centrify SAML IdP
  1. On the Amazon AWS IAM Dashboard, Click Roles > Create New Role
    The names of the roles about to be created must match the role names in Centrify Identity Service.
  2. Example: EC2 Administrators - this role grants the ability to manage all aspects of EC2 instances, therefore a policy that matches that entitlement has to be tied to the role.
    Name: AmazonEC2Admins
    Role Type:  Role for Identity Provider Access > Grant Single Sign-On (WebSSO) access to SAML providers [Select]
    Establish Trust:  SAML Provider > Select Centrify > Press Next Step
    Verify RoleTrust: Press Next Step
    Attach Policy: type "AmazonEC2FullAccess" and Check the box
    This corresponds to the administrative role for EC2 instances
    Review:  Press Create Role
  3. Repeat the process for the rest of the roles.  Make Sure that you are writing down the names of the Roles.

Finishing the Configuration in Centrify Identity Service
Create and Populate the Centrify Identity Service Roles
  1. In Cloud Manager, navigate to Roles > Add New Role
  2. Name: AmazonEC2Admins  (must match the name of the corresponding role in AWS)
  3. Members: Populate based on your requirements.  For AmazonEC2Admins I'm leveraging AD membership
    AWS-IAM-temp-role.png
  4. Press Save.
    Repeat with any other roles created in AWS
Complete the User Access Section of the AWS Role-Based SSO App
  1. In Cloud Manager, navigate to Apps > Click your AWS SAML App
  2. Go to User Access and check the box on the roles you've created.
    AWS-IAM-useraccess.png
  3. Press Save, you are ready to verify.

Verification
At this point you can verify access.  If using Active Directory, simply add a user to any of the AD Security groups that grant access and the user will get the App automatically.  Upon clicking on it they'll be able pick the role (or roles, in case of multiple entitlements) and simply press sign-in.
AWS-IAM-verif-access.png

They should only be entitled to the activities allowed by the policies associated with the role.  For example, in the case above the user will only be able to manage EC2 instances and details, no more than that.


Adjustments
Adding Multifactor Authentication , Limiting Access from the Corporate Network and Workflow and Approvals
  • MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.  These include and are not limited to:  Centrify's Mobile Authenticator, Phone call, SMS, Security Question, Email or OATH Based OTP (Duo, Google Authenticator, Amazon Virtual OTP)
  • To limit access based on the corporate IP range, all you need to do is populate the NAT addresses for the organization and check the appropriate box.
  • To establish a workflow and approvals scheme, a role needs to be designated as the approver, see the video playlist below or the one included in part two to view the particulars.

Provisioning of IAM Users
There are instances in which it is desirable to have a provisioned user inside AWS IAM.  What needs to be reconciled is if users will know their IAM passwords, in that case they can go directly to the sign-in page and bypass the controls outlined above.  We can extend the SAML template to provide provisioning capabilities as well.

Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

Video Playlist

No comments:

Post a Comment