• Triple A 에 대한 관리
    1. Authentication
    2. Authorization
    3. Auditing

IAM 소개

  1. 사용자
  2. 그룹
  3. 역할
  4. 정책

IAM_intro

인증 (내가 누구인지 Authorization)

  1. 사용자 (USER)
    • username / password
    • AccessKey

    → 로그인 하는 방법에 따라서 필요한 정보가 다를 뿐. 사용자는 로그인을 통해 인증.

    → AccessKey공유하지 말것! CloudTrail에 한 기록이 모두 그 사람의 AccessKey로 남음

    • 권한 부여를 받는 대상으로 만약 정책이 없다면 권한이 없다고 생각하면된다.
  2. 그룹 ( Group)
    • 그룹의 정책은 유저에게 상속된다.
  3. 역할 (Role)
    • Role에 정의된 권한만 실행할 수 있다. 기존의 롤을 덮어쓰기를 한다고 보면됨.
    • 임시로 권한을 잠깐 부여받기 위해 사용함. AWS IAM은 최소 권한의 원칙!
    • 롤의 중복 할당 안됨.
    • 리소스에 대해서도 할당이 가능하다.
      • EC2에서 코드 실행 → AWS 리소스 호출하는 액션 → 액세스키가
        1. 액세스키 하드코딩
        2. OS 환경변수
        3. aws/credentials
        4. 1,2,3이 없으면 리소스의 역할을 확인한다. 1,2,3의 우선순위는 3이 가장 높다.

인가 (내가 무엇을 할 수 있지 Authenticate)

4. 정책 (Policy)

  • Json파일
  • permission에 대한 ALLOW, DENY 내용을 담은 문서
  • 중복할당 가능

IAM_deny_allow

Account와 user는 구분이 되어야 한다.

  • Account는 IAM의 가장 큰 단위
  • USER가 무엇을 하던지, Account를 기준으로 비용처리가 된다.

  • Account가 루트 계정인데 이 루트 계정으로는 Access/Secret key를 발급하지 말라고 한다. 루트 계정의 권한을 막을 방법이 없기 때문에 유출 시 위험하다. 내가 루트 계정으로 AWS 계정을 만들었어도, admin 유저를 만들어서 admin 유저를 사용하도록 하자.

    IAM_policy

    • ARN : AWS Resource Name
      • 리소스의 식별자
      • arn.aws:[서비스]:[리전]:[account]:[리소스아이디]
        • s3는 리전,account는 생략이 가능하다. 생략 가능한 이유는 버킷 이름을 기준으로 url이 만들어지기 때문에 전 세계에서 같은 이름으로 생성할 수가 없다.
      • identity-based policies (=관리형 정책: AWS 관리형 정책 혹은 고객 관리형 정책으로 나뉨)
      • resource-based policies (= 인라인 정책)
        • 둘중에 충돌이 나는경우 역시 거부 우선

    AWS 접근하려고 하면 (API호출을 하면) 방화벽처럼 해당 유저가 권한있는지 물어보는게 IAM!!