Which approach will allow for secure data sharing in scalable way?
Store the data in a single Amazon S3 bucket. Create an IAM role for every combination of job type and business unit that allows for appropriate read/write access based on object prefixes in the S3 bucket. The roles should have trust policies that allow the business unit’s AWS accounts to assume their roles. Use IAM in each business unit’s AWS account to prevent them from assuming roles for a different job type. Users get credentials to access the data by using AssumeRole from their business unit’s AWS account. Users can then use those credentials with an S3 client.
Store the data in a single Amazon S3 bucket. Write a bucket policy that uses conditions to grant read and write access where appropriate, based on each user’s business unit and job type. Determine the business unit with the AWS account accessing the bucket and the job type with a prefix in the IAM user’s name. Users can access data by using IAM credentials from their business unit’s AWS account with an S3 client.
Store the data in a series of Amazon S3 buckets. Create an application running in Amazon EC2 that is integrated with the company’s identity provider (IdP) that authenticates users and allows them to download or upload data through the application. The application uses the business unit and job type information in the IdP to control what users can upload and download through the application. The users can access the data through the application’s API.
Store the data in a series of Amazon S3 buckets. Create an AWS STS token vending machine that is integrated with the company’s identity provider (IdP). When a user logs in, have the token vending machine attach an IAM policy that assumes the role that limits the user’s access and/or upload only the data the user is authorized to access. Users can get credentials by authenticating to the token vending machine’s website or API and then use those credentials with an S3 client.
Explanations:
While storing data in a single S3 bucket with IAM roles for every job type and business unit allows for access control, it becomes unmanageable as the number of roles increases with more business units and job types. Additionally, managing trust policies across numerous accounts can complicate security and scalability. This approach could lead to errors in role assignments and increased complexity in role management.
Using a single S3 bucket with a bucket policy based on conditions for job type and business unit access is somewhat manageable, but it lacks the flexibility needed to adapt to frequent changes in business units and accounts. The reliance on IAM user prefixes for access control can introduce vulnerabilities and is less secure than other options that leverage more robust identity and access management strategies.
Although using an application running on EC2 to manage data access can centralize control and provide a user-friendly interface, it introduces a single point of failure and complexity in managing the application. Additionally, this option does not take full advantage of AWS native services for scalable access management and does not directly utilize S3 capabilities, which may complicate integration and increase latency for data access.
This approach effectively uses AWS STS for temporary credentials based on user identity, allowing for fine-grained access control according to job type and business unit. By integrating with an IdP, it can dynamically adapt to changes in user roles and business units. The use of temporary credentials enhances security and reduces the risk associated with long-term credentials, making this solution both scalable and secure for sharing proprietary data across a large number of AWS accounts.
I assess that the answer is:
Store the data in a series of Amazon S3 buckets. Create an AWS STS token vending machine that is integrated with the company’s identity provider (IdP). When a user logs in, have the token vending machine attach an IAM policy that assumes the role that limits the user’s access and/or upload only the data the user is authorized to access. Users can get credentials by authenticating to the token vending machine’s website or API and then use those credentials with an S3 client.