IT-4431: Activate IAM Access Analyzer on all accounts

[brucehoff]

This PR activates IAM Access Analyzer on all accounts, as required by Microsoft Defender:

AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity and identify unintended access to your resources and data.

There are three types of analyzers. This PR creates an External access analyzer which:

help[s] you identify potential risks of accessing resources by enabling you to identify any resource policies that grant access to an external principal.

[zaro0508]

I think this is the wrong approach. The recommended approach is to enable access analyzer from a delegated admin account.

here's the blog post: https://aws.amazon.com/blogs/aws/new-use-aws-iam-access-analyzer-in-aws-organizations/

Today I am pleased to announce that you can create an analyzer in the 
master account or a delegated member account with the entire organization as
the zone of trust.

[brucehoff]

@zaro0508 I read the links you shared, which seem to describe how to configure Access Analyzers that function at the organization level. In contrast, this PR create an access analyzer at the account level. Since MS Defender is examining the Synapse Prod account specifically, I believe the PR is correct.

[zaro0508]

Your PR description says.. activate access analyzer on all accounts. Are saying that you only want to enable access analyzer for Synapse Prod account?

[brucehoff]

@zaro0508 That's a good question: To satisfy MS Defender I think we would only have to active it on the Synapse Prod account, but my thought is to just activate it in all accounts so it's available if needed.

[zaro0508]

Isn't activating for all accounts is basically the same as enabling at the organziation level? if yes, then the latter is the recommended approach.

[brucehoff]

Isn't activating for all accounts is basically the same as enabling at the organziation level?

No, since each has a different "zone of trust" as mentioned in the blog you linked above:
https://aws.amazon.com/blogs/aws/new-use-aws-iam-access-analyzer-in-aws-organizations/

[zaro0508]

I believe the zone of trust is just a access analyzer configuration. You can create multiple analyzers with different zone of trust levels. So I guess the real question is what is your intention for the zone of trust? Is your intention to create an access analyzer in each AWS account with a zone of trust set to just that account? Just be aware that we do have use AWS services that accesses resources across accounts for example: identity center, security hub, guard duty, etc..

[brucehoff]

I believe the zone of trust is just a access analyzer configuration. You can create multiple analyzers with different zone of trust levels.

You can only create an analyzer with an organization level 'zone of trust' in the organization account (or perhaps in the delegated management account -- I haven't tried that.).

Is your intention to create an access analyzer in each AWS account with a zone of trust set to just that account?

Yes.

[brucehoff]

As promised I did the experiment of manually creating an access analyzer in the Synapse prod account. I can verify that:

• It satisfies MS Defender, which has now closed the issue: https://gitlab.com/sagebionetworks/sage-bionetworks/-/issues/228
• It is useful, generating a list of 57 findings (11 public access and 56 cross account access): https://us-east-1.console.aws.amazon.com/access-analyzer/home?region=us-east-1#/dashboard
• Since the findings are in a dedicated dashboard, it doesn't generate spam, clogging other notification mechanisms.

Can I please get an approval of this PR now?

[zaro0508]

As promised I did the experiment of manually creating an access analyzer in the Synapse prod account.

Your experiment is to enable access analyzer for Synapse only. This PR is to enable access analyzer for every account at the individual account level. Do we still want to enable for all accounts at the individual account level?

It satisfies MS Defender, which has now closed the issue: https://gitlab.com/sagebionetworks/sage-bionetworks/-/issues/228

I get 404 when trying to view that issue..

It is useful, generating a list of 57 findings (11 public access and 56 cross account access): https://us-east-1.console.aws.amazon.com/access-analyzer/home?region=us-east-1#/dashboard

How are they useful? Have you reviewed each cross account finding to determine whether they are actually useful? I'm guessing that a majority, if not all, of them are just cross account access from within our organization. I mean, how useful are cross account access findings for identity center, guardduty, macie, etc..?

Since the findings are in a dedicated dashboard, it doesn't generate spam, clogging other notification mechanisms.

The spam I was referring to is in the findings, if the result is that we essentially don't do anything with those findings then I would consider it spam.

[brucehoff]

I get 404 when trying to view that issue.
The link is valid. Did you log in to GitLab before clicking on the link?

How are they useful? Have you reviewed each cross account finding to determine whether they are actually useful? I'm guessing that a majority, if not all, of them are just cross account access from within our organization. I mean, how useful are cross account access findings for identity center, guardduty, macie, etc..?

They are useful because AA provides a concise list of cross account (and public) access, making it easy to look for unexpected access. I think your objection is that the list contains access that is not unwanted, but that does not make the list unuseful.

Your experiment is to enable access analyzer for Synapse only. This PR is to enable access analyzer for every account at the individual account level. Do we still want to enable for all accounts at the individual account level?

If I change the PR to deploy only to the Synapse Prod account, will you approve the PR?

[zaro0508]

The link is valid. Did you log in to GitLab before clicking on the link?

yes, i believe so. if i hadn't logged in shouldn't gitlab redirect me to login instead of giving me a 404? Also i just logged in to get lab again and that link is still giving me 404.

I think your objection is that the list contains access that is not unwanted, but that does not make the list unuseful.

yes, it would be nice to know what percentage of the findings we can ignore because they are appropriate. How useful is it if we ignored all the cross account findings?

If I change the PR to deploy only to the Synapse Prod account, will you approve the PR?

I think this approach might be reasonable if we were only enabling Access Analyzer in a single AWS account. However, it’s still not the most effective option. A better approach is to set up Access Analyzer in a delegated administrator account
(perhaps securitycentral) and create one or more analyzers there. Each analyzer can be configured to monitor either a single account or the entire organization. This centralized setup makes Access Analyzer easier to manage, since multiple analyzers can be created and maintained from a single AWS account.

[brucehoff]

Also i just logged in to get lab again and that link is still giving me 404.

I verified that the URL is valid. If you are not using the shared credentials (in LastPass) for the StackArmor engagement then you probably have to ask them to whitelist your GitLab account for the project.

This centralized setup makes Access Analyzer easier to manage, since multiple analyzers can be created and maintained from a single AWS account.

Why is it "easier"? We set up all our infra' using org' formation, in a single repo' (organizations-infra). Using org-formation we can easily create analyzers in one or multiple accounts with a small configuration change (in DefaultOrganizationBinding).

[zaro0508]

If you are not using the shared credentials

i have to login with a shared service account? didn't know that but alright. probably not a good practice to share an account for this purpose though.

Why is it "easier"?

What I’m really saying is that the delegated admin setup is the best practice. It provides stronger security isolation and allows us to monitor all findings from a single AWS account, which makes management much easier. While we only need one analyzer right now, there are clear scenarios where multiple analyzers could be useful—for example, one per account in each region or a custom analyzer for specific access violations. Managing all of these analyzers centrally in one account is far simpler than maintaining them separately across every account. That’s exactly how the service is designed to work, and it’s why AWS recommends using a delegated admin setup for organizations.

Using org-formation we can easily create analyzers in one or multiple accounts with a small configuration change (in DefaultOrganizationBinding).

Agreed. While AWS doesn’t support automating the delegated admin setup, it does support automating the creation and management of Access Analyzer itself. We should definitely use org-formation for that. The key difference in my suggestion is to set up analyzers in a delegated admin account (such as securitycentral) rather than creating them separately in every member account.

[brucehoff]

If I change the PR to set up the AA from a 'delegated admin account' will you approve it?

[zaro0508]

If I change the PR to set up the AA from a 'delegated admin account' will you approve it?

There would be a much higher probability of approval.