AWS’ Security Model and MS AD support
Migration of a mission-critical application infrastructure should be architected from a global enterprise perspective. If ad hoc “forklift” migrations are done in an isolated “silo by silo” approach then the result will be inevitable: A costly, disjointed, inefficient, inflexible, fragile, and wasteful architecture.
AWS describes in great detail recommended migration strategies and “best practices”.
Before considering AD in relation to AWS, it would be useful to review AWS security basics.
AWS approach can be summarized as follows:
While AWS manages security of the cloud, security in the cloud is the responsibility of the customer.
AWS’ basic IAAS EC2 service provides a good example of the shared responsibility model:
...AWS manages the security of the following assets:
... you the customer... are responsible for the security of the following assets:
This section briefly reviews AWS’ basic security model. The next section looks at security function implemented for specific AWS service offerings.
Each AWS account has a root user account. This account has full power to provision the rest of AWS security including the IAM RBAC.
Root accounts as well as IAM accounts are authenticated with reusable passwords plus optional 2FA.
Access to the rich set of AWS APIs uses an HMAC signature based on a user secret key / access ID. AWS S3 SOAP requests are an exception. They use X.509 certificates.
IAM is the fundamental RBAC AuthN / AuthZ application:
AWS IAM allows you to create multiple users and manage the permissions for each of these users within your AWS Account. A user is an identity (within an AWS Account) with unique security credentials that can be used to access AWS Services. AWS IAM eliminates the need to share passwords or keys, and makes it easy to enable or disable a user’s access as appropriate.
AWS IAM is tightly integrated into all AWS service offerings.
Roles (sets of permissions) are defined in IAM. The permissions define highly granular user AuthZ across the Amazon applications, including access to specific API function.
Roles are used to generate temporary security credentials.
An IAM role uses temporary security credentials to allow you to delegate access to users or services that normally don't have access to your AWS resources. A role is a set of permissions to access specific AWS resources, but these permissions are not tied to a specific IAM user or group. An authorized entity (e.g., mobile user, EC2 instance) assumes a role and receives temporary security credentials provide enhanced security due to their short life-span (the default expiration is 12 hours) and the fact that they cannot be reused after they expire. This can be particularly useful in providing limited, controlled access in certain situations:
The following describes how IAM facilitates use of temporary credentials for access to AWS resources by applications running on EC2 instances:
Beside cloud-based infrastructures services, AWS also offers “managed applications”. These are cloud-based functional platforms abstracting underlying infrastructure.
The following is a typical example of IAM integration in a managed application:
Amazon SNS access is granted based on an AWS Account or a user created with AWS IAM. Once authenticated, the AWS Account has full access to all user operations. An AWS IAM user, however, only has access to the operations and topics for which they have been granted access via policy. By default, access to each individual topic is restricted to the AWS Account that created it. However, you can allow other access to SNS, using either an SNS-generated policy or a policy you write.
The previous section briefly reviewed AWS’ basic security model. This section looks at security functions implemented for specific AWS service offerings.
Amazon offers 3 kinds of services. These are summarized in the following table:
“Compute” services and related “Infrastructure” services
Elastic Block Store (EBS)
Virtual Private Cloud (VPC).
Managed service application “containers”
Relational Database Services (RDS)
Elastic Map Reduce (EMR)
AWS Elastic Beanstalk
High-level storage, database, and messaging services
Abstracted platform / management layer
Access via endpoint APIs
Simple Storage Service ( S3)
Simple Queuing Service ( SQS)
Simple Email Service ( SES)
Customer responsibilities for security vary depending on the kind of service:
Examples of Customer responsibilities
control the operating system, and you configure and operate any identity management system that provides access to the user layer of the virtualization stack
setting up and managing network controls, such as firewall rules, and for managing platform-level identity and access management separately from IAM
The following diagrams illustrate the shared responsibility in a visual manner for each of the 3 types of AWS service:
EC2 is Amazon’s fundamental IAAS offering. As such EC2 security function is tightly integrated with AWS’ basic security model.
SSH login to EC2 instances is protected by 1024-bit SSH-2 RSA keys. Each instance has its own key pair.
Although the basic key pair approach offers robust security, it is not manageable at scale. AWS’ solution is to leverage IAM roles for generation of temporary credentials:
However, getting credentials out to new EC2 instances launched with AutoScaling can be challenging for large or elastically scaling fleets. To simplify this process, you can use roles within IAM, so that any new instances launched with a role will be given credentials automatically. When you launch an EC2 instance with an IAM role, temporary AWS security credentials with permissions specified by the role will be securely provisioned to the instance and will be made available to your application via the Amazon EC2 Instance Metadata Service. The Metadata Service will make new temporary security credentials available prior to the expiration of the current active credentials, so that valid credentials are always available on the instance. In addition, the temporary security credentials are automatically rotated multiple times per day, providing enhanced security.
S3 is the Amazon “bulk cloud storage”. Data objects are stored in “buckets”.
Access control is provided at several levels:
Audit trail logs can be configured to track S3 bucket access. 
CloudTrail is the AWS “audit trail”:
CloudTrail captures information about every API call to every AWS resource you use, including sign-in events.
CloudTrail security logs across different regions can be consolidated in a single AWS S3 bucket for easy access by log management / analysis.
In addition to CloudTrail’s user activity logs, you can use the Amazon CloudWatch Logs feature to collect and monitor system, application, and custom log files from your EC2 instances and other sources in near-real time.
Patching in the cloud can be automated. The basic approach is to relaunch a newly patched instance.
AWS provides automatic software patching for managed DBs. The user defines a maintenance window to take a given instance offline for either patching or to scale up/down.
Patching provided by Amazon includes all base AWS OS AMI images as well as managed DB software.
To control who can use the DynamoDB resources and API, you set up permissions in AWS IAM. In addition to controlling access at the resource-level with IAM, you can also control access at the database level—you can create database-level permissions that allow or deny access to items (rows) and attributes (columns) based on the needs of your application. These database-level permissions are called fine-grained access controls, and you create them using an IAM policy that specifies under what circumstances a user or application can access a DynamoDB table. The IAM policy can restrict access to individual items in a table, access to the attributes in those items, or both at the same time.
In addition to requiring database and user permissions, each request to the DynamoDB service must contain a valid HMAC-SHA256 signature, or the request is rejected.
When you first create a DB Instance within Amazon RDS, you will create a master user account, which is used only within the context of Amazon RDS to control access to your DB Instance(s). The master user account is a native database user account that allows you to log on to your DB Instance with all database privileges.
You can control Amazon RDS DB Instance access via DB Security Groups, which are similar to Amazon EC2 Security Groups but not interchangeable. DB Security Groups act like a firewall controlling network access to your DB Instance. … authorizing a network IP range or authorizing an existing Amazon EC2 Security Group
AWS also provides the possibility of encrypted connections, and transparent data encryption.
The memory-based cache application includes a “Cache Security group” to limit network access to caching servers.
The previous sections looked at the Amazon Security Model as well as security function provided for specific AWS services.
The following sections look at MS AD in the AWS cloud.
Amazon is first and foremost a Linux-centric shop. Historically this was reflected in Amazon’s attitude to all things “Microsoft”. As late as 2013, Amazon authors wrote concerning AWS “Security Best Practices”:
Make sure the AMI is not a part of a Windows domain.
Do not enable any file sharing, print spooler, RPC, and other Windows services that are not essential but are enabled by default.
In 2014-2015 Amazon completely reversed its former position concerning MS, especially MS AD.
AWS is now providing detailed guides and blog articles for integration of a corporate on-premises AD with an AWS cloud-based deployment. Amazon is offering comprehensive new services for MS AD integration and support.
Probably the main driving force in this about-face was Amazon’s push into new end-user oriented services e.g. Amazon’s Workspaces (user virtual desktop), Workdocs (user file sharing), and Workmail (user email). To be attractive, these services have to leverage corporate AD integration for function such as SSO.
The following sections start with a brief description of reference AD architectures on the AWS cloud. A discussion of remote management access is included. Finally there is an overview of the various AWS AD service offerings.
The reference architecture for a cloud-based RYO MS AD DS / Dns deployment follows. A separate AD sites is configured for each Availability Zone. Each Availability Zone has autonomous function including GC and Dns.
The salient features described below.
Individual host instances:
Network traffic ACLs:
Amazon recommends using MS Remote Desktop GW for remote access to MS EC2 instances. The reference architecture follows:
A TLS encrypted RDP connection is proxied through the RD GW on Tcp 443 to backend Windows instances in private subnets on cleartext Tcp 3389.
To lock down and automate access:
Amazon provides configurable CloudFormation templates to automate deployment of the above reference RD GW architecture.
The following diagram shows the reference architecture for extending on-premises AD to the cloud:
The AD architecture specifics:
AWS Directory Service offers 3 different ways to use MS AD on the AWS cloud:
The following sections consider each of the above services in turn.
This is a Samba 4 implementation to provide the following basic AD-like services:
The following is not supported:
This is a full-blown AWS multi-tenant managed AD in the AWS cloud.
This is essentially an Ldap proxy to connect on-premises MS AD to the AWS cloud. Cleartext Ldap is used to authenticate to the corporate AD. Then temporary security credentials are provided by AWS for that user to sign-on to AWS services (e.g. AWS management console).
The following integration is provided for AWS base services:
“Cloud” brings with it a whole new set of function to be configured and monitored. Along with this new context comes the need to determine and mitigate the associated Security Risks.
Mature cloud offerings provide such as SFDC and AWS provide robust, highly integrated (albeit complex) security function to manage the new cloud-related Security Risks.
Operational or architectural “shortcuts” concerning cloud implementation can result in High Risk: 
Regardless of the type of migration, the security architecture should be adapted to cloud-based realities.
This applies even for a “forklift” migration that moves on-premises servers / applications “as is” into the cloud.
Amazon documentation contains detailed guidance on how to best accomplish this.
The following sections contain some quick suggestions.
In the cloud, the legacy concept of “security zone” == “network segmentation” is passé.
A network segment simply isolates one network from another, where a security zone creates a group of system components with similar security levels with common controls.
Traditional environments require separate network segments representing separate broadcast entities to route traffic via a central security enforcement system such as a firewall. The concept of security groups in the AWS cloud makes this requirement obsolete. Security groups are a logical grouping of instances, and they also allow the enforcement of inbound and outbound traffic rules on these instances regardless of the subnet where these instances reside.
AWS provides flexible security zoning options. Security engineers and architects can leverage the following AWS features to build isolated security zones/segments on AWS per Amazon VPC access control:
AWS root accounts need to be tightly controlled. Passwords should be regularly rotated.
IAM – even if decentralized – needs to be integrated with on-premises AD using federation.
Global 2FA also needs to be layered on as the “default” approach.
Architect and implement centralized security management with multiple autonomous independent projects:
Delegate AuthN / AuthZ:
It would be a serious strategic error to try to manage the “cloud” as if it were an extension of legacy “on-premises”. In fact it would be better to ask:
How can the current legacy on-premises security function be evolved to harness the power of the cloud (e.g. auto-scaling, self-healing, containerization)?
Super introduction to enterprise architecture cloud migration
Introduction to the (very complete) AWS Cloud Adoption Framework Series
50000’ overview of cloud migration. Too simplistic.
All Amazon whitepapers
General AWS security-related documentation
Overview of AWS services security-related function. Super read
Comprehensive list of cloud-related security controls
Detailed guide on implementing a full-blown ISO 27001 ISMS at Amazon. Many detailed suggestions on how to adapt legacy security to cloud realities.
Outlines major CloudTrail function / controls. Maps these to major compliance frameworks like PCI.
Maps AWS Service features to Governance req’t. Includes useful summary of main features by service (pg 15).
Recent, detailed step-by-step guide for common MS AD cloud deployments. Good read.
Same author as previous whitepaper. Considers RDGW specifics.
Official AWS documentation for the AWS Directory Service
Official AWS documentation for the AWS SSM used to automate bootstrapping of EC2 instances
Good blog article describing AD Connector
Talks about AD Connector and Simple AD only. Article is somewhat simplistic.
Older TN article describing how a WMI filter can be used to limit the scope of a GPO
Really old whitepaper: 2010. ADFS 1.1 + 2.0 only. Out-of-date but demonstrates complexity of legacy ADFS federation
Here then are some of the acronyms and “buzz words”:
In an organization, a group that is isolated from others and lives by itself, for itself
Microsoft’s Active Directory
Amazon Web Services, used here as meaning “all of Amazon’s cloud offerings”
Infrastructure as a service
Platform as a Service e.g. SFDC’s offerings
Software as a Service
AWS’s basic IAAS offering
Amazon Machine Image
AWS Identity Management application
Hash-based message authentication code
Multi-factor authentication as opposed to “reusable password” authentication
Protocol specification cf https://en.wikipedia.org/wiki/SOAP
Role-based access control
Application Programming Interface
Protocol / application cf https://en.wikipedia.org/wiki/SSH
Access control list
RO / RW
Read-Only / Read-Write
“Roll Your Own” refers to in-house development
Active Directory Data Services
Domain Name System. Protocol. See https://en.wikipedia.org/wiki/Domain_Name_System
AWS Virtual Private Cloud
Network Address Translation
DC / RODC
Domain Controller / Read-Only Domain Controller
Remote Desktop Gateway. See https://en.wikipedia.org/wiki/Remote_Desktop_Protocol
Transport Layer Security, cf https://en.wikipedia.org/wiki/Transport_Layer_Security
Dynamic host configuration protocol cf https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
Cross-platform implementation of MS CIFS/SMB protocols cf https://en.wikipedia.org/wiki/Samba_(software)
AuthN protocol used by MS AD
Group Policy Object, used by MS AD
Function of MS AD cf https://en.wikipedia.org/wiki/Flexible_single_master_operation
MS scripting language
AuthN / AuthZ protocol for federated organization access cf https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
Salesforce.com, a major PAAS / SAAS provider
See also the AWS “Cloud Adoption Framework” series starting with: https://d0.awsstatic.com/whitepapers/aws_cloud_adoption_framework.pdf
 See the following section for the details.
 Op cit pg 37
 Op cit
 Op cit pg 20
 Op cit pg 42
 Op cit pg 43
 Op cit pg 49
 There are a lot of ports to specify for DC traffic.
 This section relies heavily on the AWS documentation for AWS Directory Services.
 This section also relies on the AWS Security Blog article concerning AD connector.
 Especially end-user services such as Amazon WorkSpaces, WorkDocs, WorkMail
 For a list of cloud-related security controls for auditors, see http://d0.awsstatic.com/whitepapers/compliance/AWS_Auditing_Security_Checklist.pdf
This can be viewed as a comprehensive list of “what can go wrong” in a bungled cloud implementation.
 Much of the following is adapted from http://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf
 Cf http://d0.awsstatic.com/whitepapers/compliance/AWS_Auditing_Security_Checklist.pdf, App C API Calls, pg 27
 http://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf, Strategies for Multiple AWS Accounts, pg 15
 Op cit, pg 17