Skip to content

AWS Connector Overview

This connector enables you to use Data Access Security to access and analyze data stored in AWS S3 and do the following:

  • Analyze the structure of your stored data.
  • Verify user permissions on the resources, and compare them against requirements.
  • Identity collector – collect IAM users, groups and roles and the connections between them.

Installation Flow Overview

  1. Configure the prerequisites.
  2. Add a new AWS S3 application to Data Access Security.

Identity Collection

The AWS identities will be collected by the permission collector at the beginning of the task.

The following identities are collected:

  • AWS Accounts (root users)
  • IAM Users
  • IAM Groups
  • IAM Roles

The AWS predefined groups are represented as the following groups:

From each IAM Role, Data Access Security collects its trusted entities as members of the role. The AWS entities will be mapped to the following types:

  • IAM Users – will be saved as DAS “Local User” type.
  • IAM Groups – will be saved as DAS “Local Group” type.
  • IAM Roles – will be saved as DAS “Local Role” type.
  • AWS Account – will be saved as DAS “AWS Account” type.
  • AWS Service – will be saved as DAS “AWS Service” type.

All other types, including “Federated”, will be saved as DAS “AWS External Account” type.

Notes

  • IAM Role trusted Identity of type * is represented as "Anonymous" with type "Everyone, Authenticated Users, or contains it".

  • Principal: * in bucket policy is represented as “Anonymous” with type "Everyone, Authenticated Users, or contains it".

For each Collected identity, the primary ID will be their ARN and Alternative IDs will also be collected:

  • For AWS Accounts – ID, root user ARN ("arn:aws:iam::{iamRootUser.Id}:root") and canonical ID.
  • For other identities – ID.

Additional information that is collected:

  • Name
  • Display Name
  • Description
  • Domain – will be the AccountName(#AccountId)
  • Email (Only for AWS Account)
  • LastLogin (Only for IAM Users)

Cross-Account Access

To achieve cross-account access and allow an AWS IAM Identity from Account A to access AWS resources in Account B (S3 resource in our case), two conditions must be met:

  1. The IAM Identity owner account A should give permission X on the S3 resource in account B. In Data Access Security this permission will appear as X-ByTrustedCrossAccount
  2. The S3 resource owner account B should give permission X on the resource to the IAM Identity from account A. In Data Access Security this permission will appear as X-ByTrustingCrossAccount.

Permission X will be effective only if both permissions are granted to the user/group on the resource. Otherwise, the user/group will not be allowed to perform X on this resource.

In the above example, the user “DASAdminUser1” from account “FA-QA1” has both “GetBucketLocation-ByTrustingCrossAccount” and “GetBucketLocation-ByTrustedCrossAccount” permissions on bucket “bucket1-DAS-qa2-user1adminpriv” from account “DAS-QA2”.

Cross Account by Assume Roles

This scenario requires 4 conditions for user USER_A from Account A to have permission X on resource RESOURCE_B from Account B through role ASSUME_ROLE_B:

  1. ASSUME_ROLE_B is defined in account B.
  2. ASSUME_ROLE_B is attached to policy that gives permission X on RESOURCE_B.
  3. USER_A should be a member of ASSUME_ROLE - a trusted entity of the role.
  4. USER_A should have, in Account A, permission to assume ASSUME_ROLE_B in Account B.

In the above example, the role “DASConnectorRole” allows “GetBucketPolicy” on bucket “DAS-dev-public-bucket1”. The role and the bucket, both belong to account “DAS-Dev-Public”. The role has a member user (trusted entity) “AmirTestUser1” from account “DAS-Org”.

If, in account DAS-Org, “AmirTestUser1” has a policy that allows them to assume the role “DASConnectorRole” in account “DAS-Dev-Public", the permission will be active.

Block Public Access

The Amazon S3 Block Public Access feature provides settings for buckets and accounts to help manage public access to Amazon S3 resources. By default, new buckets and objects don't allow public access, however, users can modify bucket policies or object permissions to allow public access. S3 Block Public Access settings override these policies and permissions and enable to limit public access to these resources.

There are 4 settings both on the bucket level, and the account level, If the PublicAccessBlock settings are different between the bucket and the account, Amazon S3 uses the most restrictive combination of the bucket-level and account-level settings.

In Data Access Security these permissions appear with the suffix “Account-Disabled” for the account level settings and “Bucket-Disabled” for the bucket level settings. If one of these settings is turned off, the Permission Forensics view shows these permissions as “Allow”.

Go to Resources > Permissions > Simple View to view warnings.

Crawler

The crawler analyzes the structure of the organization and builds the hierarchy tree:

  • Organization Root container
  • Organization Units (OUs)
  • AWS Accounts
  • S3 Buckets
  • S3 Folders

Permission Collector

The Permission collection will retrieve and analyze the following permissions:

  • ACLs of buckets. If Analyze ACLs is checked, ACLs will be collected for the objects retrieved in the crawl.
  • Bucket policies for the buckets and their objects.
  • IAM policies which are relevant for the S3 buckets and Objects.
  • Account and bucket level PublicAccessBlock configurations.
  • Cross-account permissions

Permission Collection Limitations

Permission collection has the following limitations or unsupported features:

  • Permissions are analyzed for buckets and objects, not for folders since they are not an actual object in S3
  • Permissions Boundary
  • Policies Conditions
  • Policies Variables
  • Policies elements - NotPrincipal, NotAction, NotResource
  • Only S3-related permissions are analyzed
  • Access points and Jobs permissions are not analyzed

Analyze Permissions on Files

If checked, the crawler will also get the S3 Objects (files) under the buckets and the permission collector will analyze their permissions.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.