11 April,19 at 11:50 AM
Background
This is the fourth 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 Amazon Identity and Access Management (IAM) by leveraging Centrify Identity Service and your on-premises Active Directory.
In this article we'll discuss how to use Centrify Server Suite to secure your AWS Server instances by leveraging Active Directory (in AWS, on-premises or a mixed environment). The drivers behind this are:
Active Directory and AWS
The prescriptions outlined on this article depend on how your Active Directory AWS strategy is designed. It's even possible that there's no AD in your AWS deployment today, in that case you'd benefit from looking at the next entry in the series (that focuses on session brokering and password management). Assuming you are using AD in AWS, here are some of the models we've seen with our customers:
The Connected Model
This model implements some degree of permanent connectivity between AWS and your on-premises infrastructure (e.g. Amazon DirectConnnect, Firewall ACLs, VPNs/Tunneling, etc); the end result in the Active Directory layer is that the following models can be implemented:
The connected model allows for organizations to extend their AD and Centrify deployments and treat AWS as another site. As far as Centrify goes, it's like adding another branch or site.
The implications of this model are permanent connectivity (and costs), plus the need to implement the network and security components prior to the AWS deployment. Once it is in place, the administration is simplified.
The Disconnected Model
This model uses the opposite approach. It treats AWS as a disconnected entity. Users connect to AWS through the Internet. Directory services are separated.
In this scenario, independent AD forests exist on premise and in AWS. The benefits of this model are:
The obvious drawback of this model is dual administration.
Commonalities and Customer Inquiries
When communicating with prospects and customers on the field, these are the commonalities that I have observed:
Fortunately the building-blocks for all the questions asked above are scattered in the Tech Blogs and the Centrify Knowledgebase. Instead of using the Plan-Do-Check-Adjust model in this article (because of the combination of scenarios), I will speak about each bullet-point individually.
Extending Centrify Server Suite to Amazon Web Services
This one is straightforward. CSS requires Active Directory and there are several avenues that you can use. This all depends on the access and privilege model to be implemented.
EC2 Instance Lifecycle
The EC2 lifecycle (Launch, Stop, Terminate) has implications depending on the use cases. In permanent environments, systems are expected to be there for a long time; in elastic environments systems may be alive for a few weeks while an app is tested, or may be scaled-up or down depending on load or business seasonality.
Aspect that require planning include naming conventions, properly deprovisioning systems and using the analyze wizard to make sure things are tidy. Some resources:
Deploying the Centrify Software and Joining (or leaving) AD automatically
Deployment depends on the approach. I've seen customers that bake the software into their private AMIs (this allows for them to test and validate any corporate software) or I've seen the use of repositories and configuration management software. The guidance here is consistent: If you want the system to participate in your AD, you must align your hostname with your naming convention, specify the domain name, and automate the AD join (using a krb5.conf file and a service account keytab).
Baking the software and utilities to an image makes things more predictable; however using a DevOps framework is the way of the future (given the testing orientation).
This article shows how to create these building blocks:
DevOps Frameworks
Amazon AWS provides a great set of tools based on Chef (OpsWorks). If you choose to use this framework, you need to have your recipes and underlying infrastructure in place (e.g. an APT/YUM repo, or Chef infrastructure) to host the dependencies. If you are looking at the DirectControl, DirectAudit or CLI toolkit as an app, you have to sequence the triggering of the script based on your design (e.g. user-data, setup/configure/deploy/undeploy/shutdown).
Here are some avenues:
User Data field:
OpsWorks:
These articles show the same sequence using Chef or Puppet:
AutoScaling, OpsWorks and Automation Resources
Automating Access and Privilege Operations with PowerShell
Amazon AWS provides a powerful toolset that has been implemented in PowerShell. This is very aligned with Centrify's efforts (both Centrify Suite Standard and Enterprise edition provide PowerShell management tools).
The subject of PowerShell is very broad, here are a few resources:
Securing Windows Servers in AWS
Some of you are also using Windows servers in AWS and ask us how we can help. The windows security model has been challenged by modern threats like PtH and the dependency on high-privileged accounts (like Administrator) and groups (like Administrators and Domain Administrators). Centrify DirectAuthorize provides a powerful mechanism to control access and privilege elevation.
This article goes to length to explain the process for Windows: http://community.centrify.com/t5/Community-Tech-Blog/HOWTO-Eliminate-the-use-the-shared-Root-UNIX-Linux-and/ba-p/19470
Automation: In Suite 2016, Centrify added the ability to join zones automatically with the dzjoin command. This can be combined with the EC2Config tasks for your Windows based AWS systems. The User's Guide for Windows describes dzjoin in detail.
Advanced Controls and Reporting
Depending on the data classification or risk profile of the systems hosted in AWS, organizations may want to deploy additional controls to provide the assurance that only authorized users are accessing these systems, in addition, these systems may be subject to attestation requirements just like on-premise systems. We will explore other controls in part 5, however Centrify Standard Edition provides multi-factor authentication for access and privilege elevation as well as several mechanisms to obtain access data.
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