문제

A media company hosts its entire infrastructure on the AWS cloud. There is a requirement to copy information to or from the shared resources from another AWS account. The solutions architect has to provide the other account access to several AWS resources such as Amazon S3, AWS KMS, and Amazon ES in the form of a list of AWS account ID numbers. In addition, the user in the other account should still work in the trusted account and there is no need to give up his or her user permissions in place of the role permissions. The solutions architect must also set up a solution that continuously assesses, audits, and monitors the policy configurations. Which of the following is the MOST suitable type of policy that you should use in this scenario?

A)Set up cross-account access with a resource-based Policy. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.

B)Set up a service-linked role with a service control policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.

C)Set up cross-account access with a user-based policy configuration. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.

D)Set up a service-linked role with an identity-based policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.

풀이 및 공부

공부

resource-based Policy 에 대해 알고 있니? 를 물어보는 문제

내가 여태까지 사용했던 것은 대부분 Identity-based policy였던 것 같다. EC2에서 S3 읽기 권한이 필요하면, EC2에 S3 read permission을 가진 role을 할당해주었다.

resource-based Policy는 그와 반대이다. S3 입장에서 누구에게 어떤 권한을 허용해줄 것인지? 를 정할 수 있다.

Identity-based Policy

Resource-Based Policy

예시

role에 붙이는것과 아닌걸로 구분하면 이해가 빨리 된다.

위 사진은 s3 에 있는 policy 인데 Role에 붙어있는 것이 아니므로 Resource-Based Policy 라고 이해하면 된다.

When to use IAM policies vs Resource-Based Policies(S3) ?

부연 설명

AWS Config

AWS 내에서 configuration change 를 모니터링 할 수 있는 서비스이다.

만드는 방법은 아래와 같다

방금 문제의 service-linked role이 또 나오는데, service-linked role이 무엇인지 이해하고 나니까 왜 Config 가 service-linked role을 필요로하는지 알 것 같다.

aws config로 security-group을 보면 timeline으로 변경사항도 볼 수 있다.

이런식으로 rule을 붙일수도 있다.

Rule을 만들면 어떤 sg가 조건을 만족하는지 안하는지 알 수 있다.

문제 풀이

또한 다른 account의 user는 여전히 trusted account에서 작동해야 하며 role 권한 대신 자신의 user permission을 포기할 필요는 없습니다

문제의 위 내용은 아래 설명 참고

resource-based policy를 통해 cross account 접근을 하면 본인 계정의 permission 들은 다 남아있는 상태로 사용할 수 있다.

AWS Account ID 번호의 리스트 형식으로 제공

문제의 위 내용은 아래 설명 참고

policy에서 principal

Identity-based policies and resource-based policies

A번

D번

추가 정보

참고

https://www.youtube.com/watch?v=iaMDr6dsB7s

https://www.youtube.com/watch?v=qHdFoYSrUvk