Thursday, October 22, 2015

A Playbook to Secure your Amazon AWS Server Infrastructure using Centrify and Active Directory

Background

Amazon AWS EC2 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.

Part I - The 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.
    Remember, there's always attestation needs. We need to be able to report who can perform which actions in the Amazon Console. 
    Also, remember, RBAC 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.

Part II - The proposed Solution

Amazon Article -the solution.jpg
Part III - See the Solution in Action



Series
Part 2 - Protecting the Root Account with Centrify Identity Service
Part 3 - Implementing Amazon IAM using Federation with Centrify Identity Service
Part 4 - Securing Linux and Windows EC2 Instances using Centrify Server Suite and AD
Part 5 - Securing Password and Sessions using Centrify Privilege Service

This article was originally published in the Centrify Community.

1 comment:

  1. Nice blog, very informative thanks for providing for more information on AWS get touch with AWS Online Course Bangalore Get Certified

    ReplyDelete