Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.

 

The Challenge:  Extend Existing Enterprise Identity and Access Management in Public Clouds

In a previous entry of this series, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based controls.  However, organizations may already have capabilities for Centralized Identity which is at the heart of strong access controls.  This may mean that organizations need to find ways to extend this infrastructure out to public clouds like Amazon.  This may imply:

  • Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
  • Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
  • Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

 

Centrify Privilege Service

cps-snap.PNG

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

  • Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
  • Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
  • Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
  • Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

 

New Linux Agent

The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

 

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

ibconcept.png

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

  • No need to deploy "jumpboxes" to the private clouds (limits exposure)
  • Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
  • Access Request provides the assurance of "documented approvals" to sensitive systems
  • Deploy MFA or access only from the OnPrem network as additional controls.

This topic was covered in this post.

 

Agent Architecture

The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

 

Supported Platforms

agent-platforms.PNG 

UNIX Identity

Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.

Login - user's short name (must use the fully-qualified name the first time)

UID - auto-generated based on the GUID

Primary group - auto-private (same as UID)

GECOS - the display name in Centrify Identity Service

Home/Shell - configurable in the Settings tab.

ibgecosshell.png

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

 

Automation

There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

ib-enroll.PNG

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

 

Identity Broker

Privilege Service can accomodate several identities, including:

ib-sources.PNG

Note that it can accommodate identities from Active Directories without any trust relationships.

These identities can be aggregated using Identity Service Roles:

ib-role.PNG

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

IB-aws resource.png

As you can see the model works like this:

Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

 

Basic Commands

Agent Operation

  • cinfo – obtain information about the agent
  • cenroll – enroll the identity platform and enable features
  • cunenroll – leave the platform and optionally delete resource and any managed accounts
  • cflush – flush the local cache

IB login.PNG

 

AAPM

  • csetaccount – add a managed account for the resource
  • cgetaccount – obtain a managed account’s password
  • cdelaccount - delete a managed account's password

 

To test-drive the new Linux agent and to see how it can secure your public-cloud Linux instances, request a CPS trial today:  https://www.centrify.com/free-trial/privilege-service-form/

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

This article discusses how you can use Centrify Privilege Service to meet or exceed the requirements to secure shared database accounts in Amazon RDS.

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS services like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 

How are Amazon RDS instances secured?

 

The WS Security Best Practices document specifies the following information:

aws-rds.png

 

Amazon best practices provide information about data security and encryption and additional controls in each database, however, it's up to you to secure other areas like shared database accounts.  This is where Centrify Privilege Service can help you meet or exceed your goals for shared responsibility.

 

Note that it still possible for you to add your instance to an infrastructure like Active Directory; however, you can control the account, and use least privilege with other users.

 

The Database Shared Account issue

The problem is straightforward.  When you provision an Amazon RDS instance, you are provided with an administrative account that is typically shared amongst administrators.  

sql-shared.png

 

In an enterprise environment, depending on the data classification, risk profile, regulation or policy, you have to be able to control the shared account lifecycle:

  • Governance/Business Process:  Request/Approve
  • Password operations:  Check out-Check-in, Rotate/Update, Maintain History.
  • Policy:  length, complexity, expiration, rotation requirements, etc.
  • Operations:  Provide input for security operations (monitoring, remediation) and compliance

Controlling the Governance Lifecycle

Centrify Privilege Service provides the ability to take control over this process and enhance your capabilities, it can implement an Access Request model (native or with ServiceNow) to control requests and approval flow.

 

sn-aws.png

 

Controlling Password Operations Everywhere

The SAPM process is enhanced by Centrify by providing the ability to control both on-premises or public cloud database deployments.  The Connector infrastructure facilitates the deployment.

agent.png

 

 

Identity Flexibility

Leverage your Enterprise Directory (AD or LDAP) and have the flexibility to use federated identity, Google for Work or the built-in Centrify Directory for added flexibility.

 

dir-svc.png

 

RBAC, Policy Engine and Multi-factor Authentication (MFA)

Role-based access controls starts with a great grasp on identity.  With CPS, roles can be constructed leveraging any identity source visible to the platform.

 

Establish controls like accessibility only from inside the network, geo-location, plus using modern Multi-factor (Smart Card, Yubikey, OATH, Authenticator), step-up methods (e-mail, phone factor, SMS) or your own legacy (SecurID, Vasco, Symantec) infrastructure.

 polic.pngap.png

 

Enhance Security Operations

Provide flexible mechanisms to export event information (REST, SQL) to integrate with your existing monitoring infrastructure, or leverage the provided dashboards and activity feeds.

secov.png

 

activity.png

 

Demo:  Setting-up Centrify Privilege Service to Manage a SQL Server-based Amazon RDS Instance

 

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

I was recently reading an article about AWS security blunders.  The article takes a very common-sense approach to what can be applied on any Public or Private Cloud.   

 

My personal observation is that many of the challenges on any public cloud relate to the complexities of extending enterprise capability out to a public cloud and Identity and Access Management is as the heart of it. Starting with the Amazon Account and IAM, these could potentially be managed in parallel from the current IT infrastructure; this slowly becomes a management nightmare while increasing security exposure.  

 

The good news is that at Centrify we provide products and capabilities to meet and exceed the Access Control requirements for AWS around IaaS and our platform is uniquely positioned to help you today.

 

plaform.png

 

Leverage your Identity and Access Management to secure your AWS IaaS

In the article, blunders like “not knowing who is in charge of security” typically happen due to infrastructure duplication and fragmentation.  Since everything starts with Identity, at Centrify we allow you to integrate Amazon’s Identity and Access Management (IAM) with your existing directory (Active Directory or LDAP) leveraging SAML or the Native APIs.

aws.png 

To address the issue of “giving away too many privileges” & “not taking root seriously”  securing the Amazon Account and Implementing Amazon IAM are key areas and quick wins that can be accomplished with minimal effort using Centrify’s Identity Platform. 

Here are a few Tech Blogs that cover this topic:

 gears.png

 

The article also mentions challenges with Passwords and Keys (“relying too much on passwords” & “exposed secrets and keys”).  Passwords exist in web apps, Linux and Windows servers and even within scripts (a very insecure habit).  A big benefit of the Centrify Identity Platform is that you can implement Shared Password capabilities for web apps (password walleting), and vaulting of Windows, Linux and other systems.

 

See a technical showcase on CPS here:  http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

AWS and the Identity Challenge

A common strategy is to implement or extend Active Directory to AWS.  This will eliminate the need to rely on keys.  With products with our Centrify Server Suite, an access control and privilege management model can be implemented quickly and it provides a single-pane of glass that can provide security and visibility across Windows and Linux systems in AWS.  Learn more here:

http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

However, this does require either the implementation of AD in the cloud (new forest) or the extension by implementing a site-to-site VPN and using either a 1-way trust or an RODC setup.  Although these are great best practices for the enterprise, they come with cost and complexity when working with public clouds.

 

Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

With our November release of the Identity Platform, we are providing two exciting capabilities:

 

a) Centrify Agent for Windows:  Extends our award-wining Windows PIM capabilities to Identity Service or Privilege Service customers looking to secure Windows systems on console login, RDP or screen unlock.

methods.PNG

The back-end services supported are MFA methods like Mobile Authenticator, Yubikey, OATH Token or even your legacy tokens via RADIUS (e.g. SecurID, Vasco, Symantec), plus step-up methods like Phone Factor, SMS, or E-mail.

To see an article that covers this new capability, click here:  http://community.centrify.com/t5/Community-Tech-Blog/AWS-Shared-Responsibility-Login-MFA-for-Windows...

 

This new capability provides security mechanisms for organizations using Windows systems as AWS jumpboxes or that simply it is required based on the system's risk profile.

 

b) New Platform Agent for Linux -  an alternative way to provide Authentication and AAPM services for Linux systems in private or public clouds like AWS.  It’s a brand-new, “lightweight” Centrify agent.

This client works with the identity platform.  Linux systems are “enrolled” to our service and we act as an Identity Broker for your enterprise AD or LDAP-based identities.

 

The convenience of the new agent lies in its simplicity and low overhead.  Since newer workloads don’t require legacy support for NIS-like services this makes the footprint very small and the infrastructure requirements minimal in comparison of deploying a full AD forest or LDAP tree, and simpler than alternatives like one-way trusts or RODCs.   Simply drop a Centrify connector in your AWS (or other) cloud and that’s it.  Connector to cloud and agent to connector (or cloud) only requires HTTPS connectivity.  Enrollment can be fully automated using codes.

 

Here's a quick demo

 

 

The architecture of Centrify Privilege Service for AWS (or any public loud) is quite simple.  The Centrify connector talks to our service over HTTPS and extends cross-platform services like federation, policy, MFA, shared account password management, privilege session brokering, application-to-application password management and more.

 

The huge benefit is the service's identity flexibility.  Regardless of your identity source (traditional LDAP or AD), modern (Google Directory, Federated Identity, Centrify Cloud Directory) you can extend application access and PIM services.  All you need is the Centrify connector where you want those services available. 

 

 agent.png

 

In conclusion, regardless of your Public cloud, you will find that with Centrify you can meet or exceed your security requirements PLUS you can balance value and functionality, keeping capability fragmentation at bay.

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.

 

How is access to Amazon Windows AMIs secured today?

 

The AWS Security Best Practices document specifies the following information:

aws-sec-windows.PNG

At a basic level, this just means that beyond providing the ability to decrypt the administrator password based on your private key, it's up to the customer to deploy additional controls (including x.509 authentication, Active Directory or local accounts).

 

For large organizations, both x.509 or local accounts may create an additional identity silo; this means that Active Directory (either an extension of the on-prem directory or an instance running in AWS is the main option).

 

Centrify Privilege Service and Centrify Server Suite provide the flexibility to implement these controls and we'll cover more in subsequent posts, now let's explore the benefits of combining Privilege Service with the Centrify Agent for Windows for Centralized Sessions and Windows MFA

 

Privilege Session Brokering facilitated by CPS provides these benefits:

  • Centralized Identity Source:  You can leverage your existing on-premises Active Directory to authenticate users accessing EC2 Windows AMIs.
    dirsvc.png
  • Centralized Session Initiation:  This control centralizes all RDP sessions from a central management perspective.  With CPS, this capability is enhanced by providing watch and terminate options  (session proctoring) and session recording (capture and replay).
    watch-terminate.png
  • Limited Exposure:  by not using public IP addresses for your Windows systems, you are limiting exposure to attacks.
  • Additional controls:  CPS's ability to implement RBAC, Geo/time fencing can meet or exceed policy requirements.
  • Password Services:  Shared account password management for local Windows and UNIX accounts;  AD accounts, Oracle and SQL databases, Windows services and scheduled tasks.

Multi-Factor Authentication with the Centrify Agent for Windows provides these benefits:

  • You can enforce MFA using different factors like:  Mobile Authenticator, OATH OTP, Legacy (e.g. SecurID), Phone factor, SMS, e-mail or security question.
    methods.PNG
  • Contexts:  You can limit this to login or privilege elevation (if you're using Centrify Server Suite zones technology - will be covered later).
  • Enhanced controls:  If you're allowing direct connectivity, users must provide MFA and authenticate with their AD credentials.
  • Offline Access and Rescue Rights:  Leverate OATH OTP codes for MFA in case there's no access to Centrify services
    offline.png

 

Conclusion

With Centrify Privilege Service + the Windows MFA capabilities enabled by the Centrify Agent for Windows we can secure Windows AMIs by providing ways to leverage your existing AD infrastructure to centralize sessions, provide SAPM services and provide MFA enforced at the local level. 

 

Demo Video

In this demo we show how we can centralize session origination using Centrify Privilege Service, how we can use a shared account or log in manually.   We'll configure Windows MFA for a demo user and we'll demonstrate how the control is enforced via the jumpbox or if the user chooses to connect to the Windows AMI directly.

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS services like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Identity Service (or Privilege Service) to secure the Amazon Account.

 

What's the Amazon account?

The amazon account (or Amazon root account) holds the keys to the AWS Kingdom.  This is the first account set up, most likely used to set up billing, IAM roles and groups, keys, etc.

 

What constitutes a bad practice?

If your organization is sharing the Amazon account with several members of your IT staff and you're not adding additional controls around it, you are going against several security best practices.  

 

What is Amazon's guideline?

Amazon's guidelines are simple:

  • Limit access and usage of the Amazon account
  • Add multi-factor authentication
  • Implement Amazon's Identity and Access Management groups

The basic guideline is to implement a model of least privilege access.   At Centrify that's what we have traditionally preached in the context of Operating Systems and Apps.   Additional complexity is added depending on your AWS deployment model.  This is an except from the AWS Security Best Practices document (August 2016, Pg 16).

 

amazon-root.PNG

 

How can Centrify help?

Centrify Identity Service (and Privilege Serivce) provide a simple-to-use federation engine that allows the implementation of Amazon IAM without the overhead of federation services.  In addition, it provides a powerful policy and multi-factor authentication engine that allows the deployment of controls to secure the account.

 

Enhancements since the previous entry

Last year when I wrote the original post, I outlined how to implement MFA to secure the root account.  The Amazon AWS (User/Password) app is deployed leveraging the password wallet built-in to the platform.  Since the password is securely replayed, users just click on the app link, they don't rely on shared credentials.

 

A big benefit of our approach was flexibility.  In addition to Smart Card or Yubikey for pre-authentication, you could use the Centrify Mobile Authenticator and individual OATH codes for each user, you could use Phone factor, e-mail, SMS and security question as step-up authentication when the application is lauched.  

 

Enhancements since last year

  • Radius Client as MFA - this means that you can use your legacy (or modern) tokens (RSA SecurID, Vasco, Symatntec, DUO, Microsoft) via our platform
  • Workflow and approvals - this means that you can use our existing access request or external worklow like our ServiceNow App Access app for governance and documented approvals
    sn-amazon.PNG
  • Policy at the application level - this was just released, and as announced by @Friedsam this weekend, 16.10 provides application granularity.
    add-policy.png

Example

With Centrify assets, you can deploy controls that limit access to users that have been explicity approved access to the application, and to use the Amazon account they must use multi-factor authentication, only from inside the corporate network and during business hours.  You can have different combinations of controls on different environments (accounts).

 

Conclusion

With Centrify Identity Platform (Identity Service and Privilege Service) not only you can meet, but exceed the Shared Responsibility of securing your  Amazon account. 

 

Demo

In this demo, we implement three controls:

- Documented Approvals (with ServiceNow)

- Secure the shared password (not available/visible)

- Multi-factor Authentication

 

 

 

Related Articles

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

 

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:

 

 

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.

Read more...

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

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.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel