Background

In a previous entry, I wrote an article titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" and I described the use of Centrify Identity Platform and Active Directory  to implement enhanced security controls to protect AWS deployments.

In this first part, we'll address how to secure the AWS Root Account.  Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.

Enhanced Objectives

• Eliminate sharing of the Amazon AWS root account
• Protect the password by not exposing it to any users
• Limit access only from the corporate network
• Limit access to the AWS account to those with business need-to-know
• Activate MFA with Centrify Step-Up Methods (Mobile Authenticator, Phone factor, SMS, Email, Security Question)
• Activate MFA with Amazon's OATH-based virtual MFA

The Value of Centrify Identity Service

Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.

As customary, we'll use the Plan-Do-Check-Adjust methodology.

Planning

Role-Based Access Control

- Should the application always be accessible by a limited group of users?

   - Should application access be governed by AD group membership or Centrify Role?

Should the application be accessible to nobody and only requested on demand?

   - Who will approve the application access request?

Additional Controls

• Should the application be accessible only from the corporate network?
• Should the application be accessible at certain times?
• Should the application require step-up authentication.
• What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP,  etc)

An example

Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.

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

Access Control Building-Blocks

Create the AD Groups

1. In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
2. Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.

- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)

Create the AWS Root Role

Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Create the AWS Root Approvers Role

Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root Approvers
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Configuration in Identity Service

Add and Configure the AWS User/Password App

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 User/Password" template and click Add.
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. Description - in this step you will change the name to something descriptive to your environment.
   
5. User Access - check the box next to the role you created for this purpose (in our example AWS Root)
6. Policy - we'll revisit this in the "Adjustments" section.
7. Account Mapping - This is where you'll securely store the AWS credentials. Select
   a) Select "Everybody shares a single username"
   b) Populate the username with the AWS root account email address and the password with the current password.
8. Press Save, you're ready for initial testing.

Verification

At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

1. Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
2. You should see the AWS As Root App.  Click on it.
3. This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.
4. You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app. 

Adjustments

Limiting Access only from the Corporate Network

This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets or IP addresses that are translated via NAT for outbound internet connectivity to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.

Adding Multifactor Authentication or Other Controls

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.

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

Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service