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:
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.
- 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).
- 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.
- 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
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.