Connecting Amazon Web Services (aka "AWS") to Drata allows for the automated, continuous monitoring and evidence collection of the dozens of infrastructure security controls required for compliance.
Prerequisites
AWS Account Access:
You must have sufficient permissions to create new roles in your company's AWS account. Typically, this requires admin access or appropriate IAM permissions to create and manage roles.
Service Control Policies (SCP) with region restrictions:
If the AWS account you are connecting to has a Service Control Policy (SCP) with region restrictions, be prepared to configure the allowed region details for the connection to avoid test errors.
Note: At this time, for organizations that manage identities through AWS IAM Identity Center (instead of AWS IAM) and select Connect AWS Identity Center, this functionality is only supported through SCIM linking, and does not read directly from the AWS IAM Identity Center identity store.
Access AWS connection within Drata
Go to Drata.
Select Connections on the side navigation menu.
Select the Available connections tab and then search for and select 'AWS'.
On the AWS connection drawer, follow the instructions to setup the connection, enter the Role ARN, and select the Allowed Regions options. To continue the setup process, move onto the next section.
Configure connection settings
In the first screen of the setup wizard, select the default connection settings.
The option to Use AWS connection for infrastructure functions is enabled by default.
If you have access to the User Access Review module, there is an additional option for you to enable syncs for that data from the AWS connection.
Organizations that manage identities through AWS IAM Identity Center (instead of AWS IAM) can select Connect AWS Identity Center.
Note: At this time, this function is only supported through SCIM linking, and does not yet read directly from the AWS IAM Identity Center identity store.
Create and link the AWS role ARN to Drata
In the following steps, learn how to create a role and attach a policy to that role with defined permissions. This role will enable Drata to perform read-only audits of your AWS infrastructure for compliance purposes.
Log in to the AWS Console with an account that has access to create a new role.
Navigate to the IAM service, once there, select the Roles in the sidebar.
Select the Create role button, then select the AWS account box.
Click on the Another AWS account radio button.
Copy and paste the
Drata account ID: 269135526815
into the Account ID field.
Select trusted entity
Select the Require external ID checkbox.
Enter your Drata external ID into the External ID field (this is unique to your tenant, found in the AWS connection wizard in Drata).
Leave the Require MFA checkbox un-checked.
Add connection permission
Select the Next: Permissions button.
In the Attach permissions policies section, search for the Read Only Access permission: SecurityAudit.
Scroll to the bottom of this list and select the SecurityAudit predefined role.
Note: Some additional permissions that is not covered by the SecurityAudit policy may be required in order to utilize additional tests that monitor AWS. Those tests and permissions are outlined in the Additional Permission Considerations section near the bottom of the article.
Create role
Copy and paste the fields below into the form, then click the Next button.
Note: Ensure that the value for Role Name is copied exactly as listed below.Role Name: DrataAutopilotRole
Role Description: Cross-account read-only access for Drata Autopilot
Link Amazon Resource Name
Search for and select the role you just created. The role should be named DrataAutopilotRole.
Copy the Role ARN from the role's summary page.
Scroll to the bottom of the connection form and click the ‘Next’ button to establish the link between AWS and Drata.
Set up Identity Center (Optional)
Note: Drata uses SCIM to read user data, such as usernames, emails, roles, and MFA status, with read-only access as configured in this setup. Although SCIM can enable write access under certain permissions, Drata only reads the data that is synced from the identity provider and does not modify or push changes to the source system. At this time, configurations using Identity Center Directory alone (without an external IdP) are not supported for SCIM provisioning.
Drata uses SCIM to connect to AWS IAM Identity Center. Enter a SCIM Endpoint and Token to enable an account data sync.
To have these fields available, you must have provisioned an external identity provider into IAM Identity Center using SCIM. To generate a new access token you can follow the following steps:
In the IAM Identity Center console, choose Settings in the left navigation pane.
On the Settings page, choose the Identity source tab, and then choose Actions > Manage provisioning.
On the Automatic provisioning page, under Access tokens, choose Generate token.
In the Generate new access token dialog box, copy the new access token and save it in a safe place.
Choose Close.
Scope available regions for the connection
If the AWS account you are connecting to has a Service Control Policy (SCP) with region restrictions:
Within the Drata's AWS connection, select Specific regions in the Scoping set up section.
Then, choose the appropriate regions.
If it does not have restrictions, you can select the All regions option.
Verify SCP Region Restrictions for the Account
You can verify the appropriate regions through the AWS console:
Navigate to the AWS Console.
In the services menu, search for and select Organizations.
In the Accounts section, find and select the account you are connecting to Drata.
Under the account details, go to the Policies tab and search for the Service Control Policies (SCPs) section to view all policies attached to the account.
Select each SCP to view its policy document and view the Condition element that specifies
aws:RequestedRegion
.In the array, you will find a list of all the allowed regions. Select those regions in the AWS connection drawer in Drata.
Alternatively, you can use the AWS CLI to find these details:
List the policies attached to the account:
aws organizations list-policies-for-target --target-id <account-id> --filter SERVICE_CONTROL_POLICY
By using the PolicyId from the previous command, get the details of each policy.
aws organizations describe-policy --policy-id <policy-id>
In the output, inspect the
Condition
elements foraws:RequestedRegion
to find a list of the allowed regions.
🎉 You have just successfully setup proper read-only access for Drata 🎉
Additional Permission Considerations
The following tests require additional permissions not covered by the SecurityAudit Policy:
Test Name | Additional permission required |
Test 132: Daily Backup Job Status Monitored |
|
Test 133: Failed Backup Alerts Being Sent |
|
Test 134: Failed Backups Addressed in Timely Manner |
|
Test 301: AWS DynamoDB Point-in-Time Recovery Enabled |
|
Running these tests before your connected AWS account has these proper permissions may result in an error. To add these permissions to the DrataAutopilotRole through a single inline policy:
Navigate to the DrataAutopilotRole in IAM Console.
Add an inline policy to the role.
In the policy editor, select the JSON tab to manually add these permissions by pasting the following JSON into the editor to include the require permissions for these tests.
The Action field specifies the permissions being added.
In the JSON below, the permissions being added are:
backup:ListBackupJobs
andbackup:ListRecoveryPointsbyResource
permissions. If you only need one of these permissions, you remove the unnecessary permission from the “Action” list.{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"backup:ListRecoveryPointsByResource",
“backup:ListBackupJobs”
],
"Resource": "*"
}
]
}
Give this inline policy a name and add it to the DrataAutopilotRole
Monitoring tests covered by AWS
Note: Test with an * at the end require additional permissions.
Test 4: SSL/TLS on Admin Page of Infrastructure Console
Test 30: Availability Zones Used
Test 68: Customer Data is Encrypted at Rest
Test 69: Customer Data in Cloud Storage is Encrypted at Rest
Test 88: MFA on Infrastructure Console
Test 95: Infrastructure Accounts Properly Removed
Test 98: Employees have Unique Infrastructure Accounts
Test 102: Public SSH Denied
Test 104: Cloud Data Storage Exposure
Test 105: AWS Guard Duty
Test 107: Daily Database Backups
Test 108: Storage Data Versioned or Retained
Test 112: Database CPU Monitored
Test 113: Database Free Storage Space Monitored
Test 114: Database Read I/O Monitored
Test 115: Messaging Queue Message Age Monitored
Test 117: NoSQL Cluster Storage Utilization Monitored
Test 118: Infrastructure Instance CPU Monitored
Test 119: Firewall Default Disallows Traffic
Test 122: Web Application Firewall in Place
Test 124: Root Infrastructure Account Unused
Test 130: Load Balancer Used
Test 132: Daily backup job status monitored *
Test 133: Failed Backup Alerts Being Sent *
Test 134: Failed Backups Addressed in Timely Manner *
Test 205: CloudTrail log file integrity validation enabled
Test 206: SQL freeable memory monitored
Test 214: MFA for AWS Root Account
Test 215: AWS IAM Password Minimum Length
Test 216: AWS IAM Password Reuse
Test 217: AWS IAM Group-Based Access Control
Test 218: AWS EBS Volume Encryption
Test 219: AWS RDS Auto Minor Version Upgrade
Test 220: AWS RDS Public Access Restricted
Test 221: AWS S3 Bucket Access Logging
Test 222: AWS CloudTrail Logs Encrypted
Test 223: AWS CMK Rotation *
Test 224: AWS VPC Flow Logging
Test 225: Hardware MFA for AWS Root Account
Test 226: AWS S3 Object-Level Logging for Read & Write Events
Test 227: AWS Network ACLs Public Remote Server Administration Access Restricted
Test 228: AWS Security Groups Restrict Public RDP Access
Test 229: AWS IAM Unused Credentials
Test 230: AWS IAM Principle of Least Privilege
Test 231: AWS EFS Encrypted at Rest
Test 232: AWS IAM Access Key Rotation
Test 233: AWS VPC Default Security Groups Restrict All Traffic
Test 234: AWS S3 HTTP Request Denied
Test 290: AWS Database Writes I/O Monitored
Test 291: AWS Security Groups HTTP Access Restricted
Test 292: AWS EC2 Instances IMDSv1 Disabled
Test 293: AWS Classic Load Balancer Latency Monitored
Test 294: AWS Application Load Balancer Target Response Time Monitored
Test 295: AWS Classic Load Balancer Server Errors Monitored
Test 296: AWS Application Load Balancer Server Errors Monitored
Test 297: AWS Classic Load Balancer Unhealthy Hosts Monitored
Test 298: AWS Application Load Balancer Unhealthy Hosts Monitored
Test 299: AWS Application Load Balancer Redirects HTTP to HTTPS
Test 300: AWS Lambda Error Rate Monitored
Test 301: AWS DynamoDB Point-in-Time Recovery Enabled *