SaaS Application Access to Amazon EC2 Resources on AWS Cloud - Best Practices for Least Privilege

Best Practices for Least Privilege Access to Amazon EC2 Resources for SaaS Applications

Question

An enterprise wants to use a third-party SaaS application running on AWS Cloud.

The SaaS application needs to have access to issue several API commands to discover Amazon EC2 resources running within the enterprise's account.

The enterprise has internal security policies that require any outside access to their environment must conform to the principles of least privilege.

There must be controls in place to ensure that the credentials used by the SaaS vendor cannot be used by any other third party.

Which of the following would meet all of these conditions?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Answer - C.

The below diagram from an AWS blog shows how access is given to other accounts for the services in your own account.

When third parties require access to your organization's AWS resources, you can use roles to delegate access to them.

For example, a third party might provide a service for managing your AWS resources.

With IAM roles, you can grant these third parties access to your AWS resources without sharing your AWS security credentials.

Instead, the third party can access your AWS resources by assuming a role that you create in your AWS account.

Third parties must provide you with the following information for you to create a role that they can assume:

The third party's AWS account ID.

You specify their AWS account ID as the principal when you define the trust policy for the role.

An external ID to uniquely associate with the role.

The external ID can be any secret identifier that is known by you and the third party.

The third-party must provide this ID when they assume the role.

The permissions that the third party requires to work with your AWS resources are specified in the role's permission policy.

After creating the IAM role for cross-account access, you must provide the role's Amazon Resource Name (ARN) to the third party.

They require your role's ARN to assume the role.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html
AWS MP

©

SD

temporary
security
credential

v
x

Marketplace Marketplace

Metering Metering
role permissions

Assume Role Instance role
Permissions

Production Account: 111111111111

Seller Account: 222222222222

The correct answer for this scenario is option C: Create an IAM role for cross-account access that allows the SaaS provider's account to assume the role and assign it a policy that allows only the actions required by the SaaS application.

Explanation:

Option A is not a recommended solution because it would give the SaaS vendor full access to the AWS environment, which is not in compliance with the principle of least privilege. Moreover, it would also be difficult to revoke access to the SaaS vendor in case of termination of contract, as there is no centralized control over the access keys.

Option B is better than option A, but it still requires the creation of an IAM user with access keys, which is not the recommended approach. IAM users are meant for human users and are not suitable for automated access such as that required by a SaaS application.

Option D is not recommended either, because it involves creating an IAM role specifically for EC2 instances, which would not work if the SaaS application needs to access other resources in the enterprise account.

Option C is the most appropriate solution, as it involves creating an IAM role for cross-account access. This role allows the SaaS vendor to assume the role temporarily and access the resources required by the application, while at the same time enforcing the principle of least privilege by restricting the actions that can be performed. The SaaS vendor does not need to have permanent access keys, which enhances security and simplifies key management. The IAM role can also be easily revoked if the contract is terminated, which makes it a more flexible and secure solution.