AWS Account에 대해 몰랐던 것들

Organizations

1. Organization을 생성한 계정은 Management Account가 된다.
2. Consolidated Billing을 사용했을 경우 조직 차원에서 비용적으로 얻을 수 있는 이점은 조직 내 모든 계정의 사용량이 합산되므로 Reserved Instance, Savings Plan같은 예약 혜택 및 볼륨 할인이 조직 전체에 공유된다는 것.
   2-1. 조직 내의 한 계정에서 Reserved Instance를 샀는데 다 못 쓰면 조직 내 다른 계정이 이어서 사용할 수 있다.
3. OrganizationAccountAccessRole은 조직에서 새 계정에 접근하기 위한 IAM Role이다.
   3.1 조직에서 직접 계정을 생성하면 자동으로 생성되지만, 기존 계정을 초대해 합류시켰을 경우 수동으로 생성해야 한다.
   3.2 Management Account에서 멤버 계정으로 접근할 때 해당 Role을 Assume해서 들어간다.
4. SCP는 OU, 개별 계정, Root 컨테이너에 모두 붙일 수 있다.
5. 권한은 SCP 활성화시 기본적으로 implicit deny 되기 때문에 계정 내에서 무엇도 할 수 없다. 따라서 일단 전부 허용하는 FullAWSAccess 권한을 기본적으로 두고 막고싶은 권한을 추가로 deny하는 방식이 Deny List이다.
6. FullAWSAccess 권한을 제거하고 허용할 서비스만 명시하는 방식이 Allow List 방식. 더 보안적이지만 관리 부담이 크다.
   7.Management Account는 SCP의 영향을 절대 받지 않는다. 따라서 이 계정은 제어가 안 되므로 아무런 리소스도 올리지 않는 것을 권장
7. Root 컨테이너 > OU > Account

Terminology and concepts for AWS Organizations

이미지 요소	본문 개념
Organization root	Root 컨테이너 (최상위 그릇)
Management account	Organization을 생성한 계정
OU / Nested OU	Organizational Units, OU 안에 OU 중첩 가능
Member account	조직에 합류한 일반 계정
Policies (점선 화살표)	SCP — Root/OU/Account 레벨에 붙일 수 있음

9. SCPs inherit down through the organization tree - 하위 ou는 상위 ou를 상속한다.
10. organizations에서 SCP외에 Tag Policy, Backup Policy, AI Services Opt-out Policy도 사용할 수 있다.
11. Management Acc 대신 특정 Member Acc에게 조직 서비스 관리 권한을 Delegated Administrator 기능을 통해 위임할 수 있다.
12. CloudTrail, AWS Config, GuardDuty/SecurityHub는 조직 단위로 사용이 가능하다.
13. Resource Access Manager(RAM)는 Organizations와 연계해 subnet, tgw같은 리소스를 계정 간 공유할 수 있다.

Policies

1. AWS에 존재하는 policy는 6가지 종류가 있고, 아래와 같다.

타입	권한 부여 여부
Identity-based Policy	O
Resource-based Policy	O
Permission Boundary	X (최대 범위만 설정)
SCP	X (최대 범위만 설정)
ACL	O (cross-account만)
Session Policy	X (범위 제한만)

2. 우선순위는 다음과 같다: Explicit Deny > Allow > Implicit Deny
   2-1. Implicit Deny는 allow가 하나라도 있으면 무시된다.
3. SCP랑 Permission Boundary는 진짜 삼천년 동안 헷갈린다.

구분	SCP	Permission Boundary
적용 대상	계정 전체	개별 IAM User/Role
설정 주체	조직 관리자 (Management Account)	해당 계정의 관리자
목적	계정 단위 최대 권한 제한	사용자/역할 단위 최대 권한 제한

4. 일단 적용 대상이 크게 다르므로.. 조직 전체일 경우 scp, 대박 깨달았다. 왜 '계정'과 'iam user'를 혼용하고 있었는지 모를 일이다...
5. MFA 강제는 Permission Boundary보다는 IAM Policy의 Condition으로 구현한다고 한다.
6. Permission Boundary의 핵심 사용 사례는 자료에도 나온 Privilege Escalation 방지다. 어떤 유저에게 IAM 생성 권한을 줬을때 그 유저가 본인 혹은 다른 유저에게 AdministratorAccess를 부여하는 걸 막는 용도로 사용한다고 한다.
7. cross account 접근은 양쪽 모두의 허용이 필요하다.
   7-1. A는 resource-based policy로 B를 허용, B는 Identity-based policy에서 A가 접근하려고 하는 리소스 접근 허용
   7-2. 같은 계정 내에서는 identity-based policy만 있어도 접근할 수 있다.
8. 권한을 부여한다는 건 이 정책을 가지고 어떤 행동을 할 수 있게된다는 거고 권한을 부여하지 않는다는 건 이 정책 자체로 할 수 있는 건 없고 범위 제한의 효력만 가진다는 뜻
9. IAM은 계정 내, Organizations는 계정 자체
10. ACL은 resource-based policy와 비슷하다. 같은 계정 내에 대한 제한이 아니라 다른 계정에 대해서 정의
11. PowerUserAccess iam 관련 권한 빼고 다

Understanding IAM Policy Evaluation Logic and Permission Boundaries in AWS

cross account 접근일 경우 양쪽 계정에서 모두 이 평가 로직을 통과해야 한다.

12. Confused Deputy Problem: A 서비스가 B 서비스를 대신해서 C 리소스에 접근할 때, 권한을 악용당할 수 있는 문제
    12-1. 이걸 방지하기 위해 Condition에 aws:SourceArn 또는 aws:SourceAccount를 명시한다.
13. Assume Role 하면 임시 자격 증명을 받는다. 이게 만료 시간이 있는데(1~12h) assume할 때 session policy를 추가로 넘겨서 권한을 더 좁힐 수 있다고 한다.
14. 권한 상승 패턴
    IAM 생성 권한이 있는 유저가 자기 자신에게 Admin 권한 부여
    Lambda 생성 권한으로 Lambda를 통해 다른 Role을 Assume
    CloudFormation으로 높은 권한의 Role을 가진 스택 생성
    -> permissiono boundary로 막자
15. NotAction(이라는게 있다고 한다. reverse Action) 이거 뺴고 모두 allow/deny함
    15-1. deny + NotAction 하면 명시한 이거 빼고 다 거부

RAM

1. Resource Access Manager, 계정 간 리소스 공유할 수 있게 하는 서비스
2. RAM을 사용할 수 있는 전제 조건
   서비스가 RAM을 지원해야 한다.
   일부 서비스는 같은 Org 내부의 계정끼리만 공유 가능하다(subnet)
3. RAM 자체는 무료, 공유된 서비스 사용 비용만 발생
4. Owner Account:
   리소스 생성, 공유 설정
   공유 후에도 해당 리소스에 대한 모든 권한을 가짐
   누구와 공유할지를 결정. 공유 대상은 계정, ou, 전체 조직 중 설정
5. Participant(Principal):
   공유받은 리소스를 읽거나 참조
   공유받은 리소스 수정 및 삭제할 수 없음
   Shared vpc 기준으로 subnet에 ec2와 같은 리소스를 생성할 수는 있다.
6. 자동 수락되는 경우: 공유 대상이 같은 org 소속, RAM에서 조직 공유 활성화돼 있을 경우
7. 수동 수락해야 하는 경우: 공유 대상이 org 외부, 조직 공유 활성화 x
8. AZ ID가 있다고 함.. AWS는 AZ 이름을 계정별로 다르게 매핑
   이게 공유를 한다고 하면, 공유하는 두 계정에서 장애가 났을때 az가 다를 수 있음(같게 보여도)
   따라서 계정에 상관없이 동일한 az를 가리키는 az ID 제공
9. 각 계정에서 만든 리소스는 만든 계정에서만 보이지만 통신은 가능하다. (같은 네트워크 안에 있으니까)
10. 공유된 리소스는 natively 접근할 수 있다. -> 그냥 자기 리소스처럼 보이고 사용 가능
11. Subnet은 Network Account가 만들고, Prod Account는 그 Subnet을 빌려서 그 위에 자기 리소스만 올린다

Resource Access Manager (RAM)

Service Quotas

1. 리전 당 ec2 생성 몇 개, iam 유저 생성 계정 당 몇 개 등의 quota가 있음
2. 보통 서비스는 리전 별 쿼타, 글로벌 서비스는 계정별 쿼타가 있음
3. 요청해서 늘릴 수도 있다.

STS(Security Token Service)

1. STS에서 발급하는 임시 자격 증명에는 AccessKeyID, SecretAccessKey, SessionToken, Expiration이 포함된다.
2. 임시 자격증명은 수동으로 취소가 불가능하고 만료될 때까지 유효하다.
   2-1. 따라서 키가 유출되면 AWSRevokeOlderSessions 인라인 정책을 Role에 추가시켜서 기존 세션을 모두 무효화시킨다. 이 정책 추가 이후 새로 발급되는 세션은 영향을 받지 않는다.
   2-2. 해당 시점 이전에 생성된 토큰으로 생성되는 요청에 대해서는 다 deny하겠다
   2-3. 토큰 회수는 안 되지만 그 토큰으로 사용 자체를 할 수 없게 하겠다.
3. 임시 자격증명은 특정 Identity에 귀속되지 않는다. 따라서 유출됐을때 누가 사용하고 있는지 추적이 어렵기도 함

공부는 이어진다...