AWS Issue - Fragmented View of Services Due To Acct/Role

Hello,

Firstly, I would like to dive into the functionality of IAM entities - IAM Roles/Users/Groups etc. So the AWS IAM service exists to provide the secure control of individual or group access to the AWS resources.

What is a IAM User? A user is a unique identity recognized by AWS services and applications. Similar to a login user in an operating system like Windows or UNIX, a user has a unique name and can identify itself using familiar security credentials such as a password or access key.

What is an IAM Role? An IAM role is an IAM entity that defines a set of permissions for making AWS service requests. IAM roles are not associated with a specific user or group. Instead, trusted entities assume roles, such as IAM users, applications, or AWS services such as EC2.

https://aws.amazon.com/iam/faqs/

For example -

An IAM Role/User can have complete access to EC2 actions with an IAM Policy like below -

{ "Version": "2012-10-17", "Statement": [ { "Action": "ec2:", "Resource": "", "Effect": "Allow", } ] }

Also, you can restrict the same IAM Role/User to be only able to access EC2 resources in a specific region by using condition keys. Basically the below example shows how you might create an IAM policy that allows full EC2 access within a specific Region.

{ "Version": "2012-10-17", "Statement": [ { "Action": "ec2:", "Resource": "", "Effect": "Allow", "Condition": { "StringEquals": { "ec2:Region": "us-east-2" } } } ] }

So as you can see the IAM Policies are the JSON structures which define what an IAM entity is authorized to perform or vice versa what specific actions are denied implicitly or explicitly.

Please note that when a principal tries to use the AWS Management Console, the AWS API, or the AWS CLI, that principal sends a request to AWS. When an AWS service receives the request, AWS completes several steps to determine whether to allow or deny the request.

Please feel free to refer to our AWS Documentation on how AWS Policy's logic is evaluated here - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

So as you can understand the limited view according to the permissions provided to an IAM entity is a service design capability that has been provided as a security mechanism feature. For example, you wouldn't want a sales member entity to be able to access dev/admin information that they shouldn't be able to access otherwise. Hence, you only provide them with the least privilege access which is one of the security best practices recommended by AWS.

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

"When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks."

Also in regards to best practices, I do want to mention that the access key for your AWS account's root user gives full access to all your resources for all AWS services, and you cannot reduce the permissions associated with your AWS account root user access key.

Therefore it is another security best practice recommendation that you do not use the root user for your everyday tasks, even the administrative ones. Instead, use your root user credentials only to create your IAM admin user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials

Furthermore, to shed some more light on the difference between the access of root user and an IAM Admin User, you can only perform the tasks listed in the AWS Doc below only when you sign in as the root user of an account. For example tasks such as changing account settings, closing account etc.

https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html

To summarize - There are two different types of users in AWS. You are either the account owner (root user) or you are an AWS Identity and Access Management (IAM) user. Root user credentials -> The credentials of the account owner allow full access to all resources in the account. IAM credentials -> For example, if you require administrator-level permissions, you can create an IAM user, grant that user full access, and then use those credentials to interact with AWS.

https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "", "Resource": "" } }

Important Note - When you give a user full access, you are effectively giving them full access to all resources in your AWS account. This includes access to delete all resources. You should grant these permissions to only trusted administrators, and you should enforce multi-factor authentication (MFA) for these administrators.

In case if you still have any questions on the service design in regards to IAM permission please feel free to open up a case with premium support team for further discussion if need be.

Secondly, please feel free to refer to our AWS documentation which provides information on usage of IAM in cross account access and its practices -

https://aws.amazon.com/blogs/apn/securely-accessing-customer-aws-accounts-with-cross-account-iam-roles/ https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html

Basically, you can allow a principal in one account to access resources in a second account. This is called cross-account access. When you allow cross-account access, the account where the principal exists is called the trusted account. The account where the resource exists is the trusting account. To allow cross-account access, you attach a resource-based policy to the resource that you want to share. You must also attach an identity-based policy to the identity that acts as the principal in the request. The principal's identity-based policy must allow the requested access to the resource in the trusting service.

Now, in case if you are looking for an aggregation of data from multiple account, several AWS services have integration with AWS Organization service to help one achieve such a use case to have a broader view per say. For example Config, Inspector, GuardDuty, Security Hub etc.

https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-inspector2.html https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html

Thirdly, in regards to your front end issue with your application, we also have the dedicated AWS Solutions Architect team which addresses the architecture and design level queries for custom/development/architectural solutions. I would suggest you reach out directly to our Sales team as they can help you to get in touch with our Solutions Architect (SA) team.

You can request for a member of the sales (Business Development) team to contact you using any of the following methods:

> Via form:    	http://aws.amazon.com/contact-us/aws-sales/
> Via Live Chat:   https://pages.awscloud.com/live-chat-contact-us.html
> Phone support:   +1 (833) 662-9873 - 6:30am - 4:00pm (Pacific) Monday - Friday.

Fourthly, in regards to the inspector service. You can leverage the AWS Organization integration which will allow you to aggregate all finding data. Using Amazon Inspector you can manage multiple accounts that are associated through AWS Organizations by simply delegating an administrator account for Amazon Inspector. The delegated administrator manages Amazon Inspector for the organization and is granted special permissions to perform tasks on behalf of your organization such as:

- Enable or disable scans for member accounts

- View aggregated finding data from the entire organization

- Create and manage suppression rules

https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-inspector2.html

In case if you are facing issues during implementation or are running into any errors, please feel free to open a support case with our team so that we can assess your environment and the issues at hand to better assist you.

Thanks for the response Yash - a question: if I wanted a user to be granted read access so that they could view/print/export any report from any service... what would the order of config of Organizations, Cross-Account Access, individual service configs & testing access/aggregation be?

There are a finite group of IAM users who would require this. One one hand there are INFR admins who'd like to have ability to view/export reports on EC2's - a common request is asset list & performance metrics (CPU, RAM, HD space util). Another are SECURITY folks - looking for same view into various services (Inspector, SecHub, GuardDuty, etc).

And is there a list of services where this process applies? In a perfect world we would use the same template - Organizations/Cross-Account so a "global/top-down" view of a service running across multiple Accounts/Roles - would be possible.