IAM

AWS Identity and Access Management(IAM)는 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스다. IAM을 사용하여 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어한다.

Root account는 기본적으로 생성된다.
AWS 계정을 처음 만들었을 때 만든 루트 계정(email)이랑 완전 다르다는 점을 알아야 한다. 왜냐하면 루트 계정은 모든 권한을 갖고 있고, IAM 사용자는 단지 루트 계정에 의해 만들어졌을 뿐이다.
AWS에서는 루트 계정을 직접 사용하지 말고, 어드민 권한(AdministratorAccess)을 부여한 IAM 사용자를 따로 만들어서 사용하는 것을 권장하고 있다.

User

• root account가 아닌 iam user로 로그인할 수 있도록 한다.
• 유저에게 개별적으로 permission을 할당할 수 있다. 하지만 그룹 단위로 관리하는게 좋다.

Group

• group안에는 user만 있어야 한다. group안에 group x
• 한 유저는 여러 그룹에 속할 수 있다

Role

role은 user, 일반적으로 AWS 리소스에 액세스할 수 없는 사용자, 애플리케이션 또는 서비스에 액세스 권한을 위임할 수 있다.
=> Role은 Policy를 갖는다는 점에서 IAM 사용자 비슷하다.하지만 IAM 사용자는 딱 그 사용자에게만 권한이 적용되지만, IAM 역할은 그 권한이 필요한 사용자라면 얼마든지 획득할 수 있다.

그룹에다가 권한을 바로 주는 대신에 권한의 논리적 집합으로서 역할을 만들고 역할을 그룹이나 사용자에 연결합니다.
즉 Group은 UserGroup으로 주로 사용하고, Role은 권한의 Group으로 사용하는 것입니다. (간접 계층 추가)

group만으로 권한을 관리하게 되면 여러 그룹이 생기고, 관리가 어려워진다.
그래서 대신 Role 개념을 추가해서 권한 관계를 신경쓰고, Group은 Group 답게 User와의 관계만 신경쓰도록 하게 되었습니다.

그룹

• 관리자 그룹
• 사용자 그룹
• 게스트 그룹
  역할
• a할 수 있는 역할
• b할 수 있는 역할

permission(권한)

aws서비스나 자원에 어떤 작업을 할 수 있는지 명시해두는 규칙

Policy(정책)

• 권한들의 모음. 정책은 권한을 부여하는 방법이다. user나 group에 permission을 직접 사용할 수 없고 permission으로 만든 policy를 적용해야 한다.

Statement*
sid: statement의 identifier (optional)
effect: Allow / Deny
principal: 이 policy가 적용될 account/user/role을 기술
action: 이 policy가 allow/deny할 액션들
resource: action이 적용될 리소스
condition: policy가 적용되는 조건 기술 (optional)

policy 종류

• 연결 대상이 어디인가에 따라
  • 자격 증명 주체(User, Group, Role)
    • 자격증명-기반 정책(Id-Based Policy)
      대개 principal이 없다. 해당 정책에 연결된 보안 주체(aws계정, iam사용자, 그룹)가 principal이 된다
  • 리소스에
    • 리소스-기반 정책(Resource-Based Policy)
• Role의 신뢰 관계
  • 신뢰 정책 (사실 Role을 리소스로 본다면, 특별한 의미의 리소스-기반 정책이라고 할 수 있음)

MFA(Multi Factor Authentication)

• MFA = password + security device
• 비밀번호가 탈취되어도, 토큰 인증할 장비가 없으면 접속이불가능하기때문에 더 안전하다

STS

---

https://jonnung.dev/posts/2021-01-28-aws-iam-role/
https://musma.github.io/2019/11/05/about-aws-iam-policy.html