× Welcome to the Centrify Community! We are rolling out product name changes — click here to learn more.

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

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

By Centrify Guru I ‎10-04-2015 08:37 AM

Background

Amazon AWS is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.  

 

It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.

 

This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.

 

Requirements and Challenges

 

Identity and Access Management Requirements

 

  1. Secure Access to the Amazon Root Account
    The experts at amazon will be the first to tell you.
    Amazon Article - az checklist root account.jpg
    Don't use your Amazon root account as the means for regular administration. Don't share it. Look at this account only for break-glass scenarios

  2. Use Role-Based Access Control
    This is another best practice documented by our friends at Amazon.
    Amazon Article - az rbac.jpg
    However, what's not very obvious is that you may want to do this from a common identity source. We don't want AWS to become an additional identity silo, this promotes duplication of effort and increases the likelyhood of exposure.
    Organizational policy and risk assessment will require that policy is enforced centrally and depending on data clasification, there will be attestation needs. We need to be able to report who can perform which actions in the Amazon Console. 
    The role-based access control model needs not only apply to the Amazon console, but to the systems that are running in the IaaS cloud;  you must be able to enforce the least access, least privilege, separation of duties and be able to attest or report which users has access to each system, what can they do with privilege and how they got granted the access.

  3. Use Multifactor Authentication
    Amazon Article - az checklist MFA.jpg
    Amazon recommends strong controls for the root account; however, We argue that we have to apply stronger controls like being able to access the console only from on-premises in some cases (or example, when using the amazon root account) and apply MFA across the board in cases where the user is accessing externally.

    The challenge for many organizations is that Multi-factor Authentication is also a fragmented capability, because most IAM vendors until recently have not considered it a must have.
    There’s also the issue of modern use cases. Physical OTP tokens are expensive and don’t provide enough information for the modern enterprise. We need more significant information and workflow-like capabilities and to be able to use that same scheme in other use cases, like when elevating to use your privileges.
    Since all roads point to the mobile device in your pocket, this means strong Enterprise Mobile capabilities to secure that device as well.

    Finally, wouldn't it be better to go beyond MFA and be able to apply stronger policies?  Perhaps only allow access to the AWS console only from your on-premises infrastructure?  Provide authentication policies that request MFA before the user's password?

  4. Apply a Security Policy
    This is another item in the Amazon checklist, they specificaly talk about passwords.
    Amazon Article - az checklist policy.jpg
    However, organizations with mature security practices understand that using a common identity store (like Active Directory, used in 90%+ organizations) also allows for consolidating policy definition and enforcement.
    Amazon systems can be integrated to the common directory for the purposes of Access Control.
    This step requires the extension of your corporate IT directory to the IaaS infrastructure. This can be accomplished several ways (in the case of AD). A resource domain with a 1-way trust and a site-to-site VPN, an RODC, etc.

    The benefits of this approach include less IT fragmentation and complexity, and consolidation of processes and tools, however, the solution should be ready for automation and orchestration; one of the principles of public/private clouds is elasticity, this means that if machines are spun up or down, the tools should have simple ways to satisfy these needs.

  5. Session Management
    Systems in the Amazon cloud should be accessed in a way that allows for accountability, centralization of access and enforcement of strong policies. Although it's possible to access directly via Amazon, this tends to open itself to challenges with sessions and key management.

  6. Password Management
    Finally, we need to eliminate the human challenge of shared credentials. Accounts like root, Administrator and any others should be brokered with a repeatable process: request/approve-check-out-check-in-rotate.

 

The Proposed Solution

Amazon Article -the solution.jpg

Part III - See the Solution in Action

 

 

Articles

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

 

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel