Skip to main content
All CollectionsConnectionsProvider
AWS (Amazon Web Services) Connection
AWS (Amazon Web Services) Connection

This article walks through the details of configuring AWS to connect to Drata.

Updated today

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

  1. Go to Drata.

  2. Select Connections on the side navigation menu.

  3. Select the Available connections tab and then search for and select 'AWS'.

  4. 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.

  1. Log in to the AWS Console with an account that has access to create a new role.

  2. Navigate to the IAM service, once there, select the Roles in the sidebar.

  3. Select the Create role button, then select the AWS account box.

  4. Click on the Another AWS account radio button.

  5. Copy and paste the Drata account ID: 269135526815 into the Account ID field.

Select trusted entity

  1. Select the Require external ID checkbox.

  2. Enter your Drata external ID into the External ID field (this is unique to your tenant, found in the AWS connection wizard in Drata).

  3. Leave the Require MFA checkbox un-checked.

Add connection permission

  1. Select the Next: Permissions button.

  2. In the Attach permissions policies section, search for the Read Only Access permission: SecurityAudit.

  3. 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

  1. 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

  1. Search for and select the role you just created. The role should be named DrataAutopilotRole.

  2. Copy the Role ARN from the role's summary page.

    • Paste this into Role ARN field on Drata connection wizard.

  3. 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:

  1. In the IAM Identity Center console, choose Settings in the left navigation pane.

  2. On the Settings page, choose the Identity source tab, and then choose Actions > Manage provisioning.

  3. On the Automatic provisioning page, under Access tokens, choose Generate token.

  4. In the Generate new access token dialog box, copy the new access token and save it in a safe place.

  5. 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:

  1. Within the Drata's AWS connection, select Specific regions in the Scoping set up section.

  2. 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:

  1. Navigate to the AWS Console.

  2. In the services menu, search for and select Organizations.

  3. In the Accounts section, find and select the account you are connecting to Drata.

  4. 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.

  5. Select each SCP to view its policy document and view the Condition element that specifies aws:RequestedRegion.

  6. 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:

  1. List the policies attached to the account:

    • aws organizations list-policies-for-target --target-id <account-id> --filter SERVICE_CONTROL_POLICY

  2. By using the PolicyId from the previous command, get the details of each policy.

    • aws organizations describe-policy --policy-id <policy-id>

  3. In the output, inspect the Condition elements for aws: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

backup:ListRecoveryPointsbyResource permission

Test 133: Failed Backup Alerts Being Sent

backup:ListBackupJobs permission

Test 134: Failed Backups Addressed in Timely Manner

backup:ListBackupJobs permission

Test 301: AWS DynamoDB Point-in-Time Recovery Enabled

backup:ListRecoveryPointsbyResource permission

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:

  1. Navigate to the DrataAutopilotRole in IAM Console.

  2. Add an inline policy to the role.

  3. 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 and backup: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": "*"
      }
      ]
      }
  4. 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 *

Did this answer your question?