사전 AWS IAM
구현체

AWS IAM

gabury1고친 사람 github-actions[bot]

IAM 은 아마존 클라우드에서 누가 무엇을 해도 되는지를 미리 적어 두는 서비스입니다. 요청이 하나 올 때마다 적어 둔 내용을 확인해 통과시키거나 막습니다. 사람이 화면에서 누르는 것도, 서버에서 도는 프로그램이 부르는 것도 모두 이 확인을 거칩니다. 적어 둔 것이 없으면 아무것도 되지 않습니다.

쉽고 빠른 이해

클라우드 계정 안에서 「누가 · 무엇에 · 무엇을 해도 되는지」를 글로 적어 두는 곳입니다. 로그를 모으는 프로그램에는 「로그 보관소에 파일을 넣어도 된다」만 적어 둡니다. 그 프로그램은 파일을 지우지도, 다른 데이터를 읽지도 못합니다.

적어 두는 곳이 없으면 계정에 들어온 모두가 같은 권한을 갖습니다. 그러면 실수로 지운 파일 하나, 밖으로 새어 나간 비밀번호 하나가 계정 전체로 번집니다.

어떻게 도는가:

  1. 사람과 프로그램에 각각 신원을 만들어 줍니다
  2. 그 신원에 무엇을 해도 되는지를 문장으로 적어 붙입니다
  3. 요청이 올 때마다 그 문장을 읽어 통과시킬지 정합니다

대가가 있습니다. 어떤 일이 되게 하려면 무엇을 열어야 하는지 미리 알기 어렵습니다. 그래서 일단 넓게 열어 두고는 좁히지 못한 채 두게 됩니다.

상세

이 절은 클라우드 계정 안에서 허락이 어떤 모양으로 적히는지, 그리고 요청 하나가 어떤 판정을 거쳐 통과하는지를 봅니다. 로그를 모아 보관소에 넣는 프로그램 하나를 줄곧 예로 씁니다.

회사의 결재 규정집을 떠올리면 쉽습니다. 누가 얼마짜리 지출을 결재할 수 있는지가 규정집에 글로 적혀 있습니다. 결재가 올라올 때마다 담당자는 그 규정집을 펴서 맞는지 봅니다.

AWS(Amazon Web Services, 아마존 웹 서비스)에서 그 규정집을 두고 읽는 서비스가 IAM 입니다. IAM 은 Identity and Access Management 의 줄임말입니다. 어떤 신원에 어떤 권한을 줄지 적어 두는 일과, 요청마다 그것을 읽어 판정하는 일을 함께 맡습니다.

계정이라는 경계

AWS 에서 자원을 소유하고 요금을 무는 단위는 계정입니다. 서버도 저장소도 데이터베이스도 어느 계정 하나에 속합니다. IAM 이 말하는 「누가」와 「무엇에」도 그 계정 안에서 셉니다.

계정을 처음 만들면 루트 사용자 하나가 생깁니다. 이 신원은 계정 안의 모든 것을 할 수 있습니다. 이 하나로만 일하면 계정에 들어온 모두가 계정 전체를 다루게 되고, 비밀번호 하나가 새면 피해도 계정 전체가 됩니다.

그래서 사람과 프로그램마다 따로 신원을 만들고 각각에 필요한 만큼만 붙입니다. 그 신원을 만들고 붙이는 일을 IAM 이 맡습니다.

클라우드에는 저장소·큐·데이터베이스처럼 서로 다른 서비스가 수백 가지 있습니다. 서비스마다 허락을 다루는 방식이 따로 있으면 같은 규칙을 그 수만큼 다시 적어야 합니다. AWS 는 판정을 IAM 한 곳으로 모았고, 각 서비스는 요청을 받으면 그 판정을 물어봅니다.

사용자 · 그룹 · 역할

요청을 보낸 쪽을 프린시펄이라고 부릅니다. 사람일 수도 있고 서버에서 도는 프로그램일 수도 있습니다. IAM 은 이 프린시펄에 붙일 이름을 몇 가지 모양으로 내줍니다.

IAM 사용자는 사람 한 명이나 프로그램 하나에 고정으로 붙는 신원입니다. 화면에 로그인할 비밀번호를 갖거나, 프로그램이 요청에 붙일 액세스 키를 갖습니다. 한 번 만들면 지울 때까지 그대로 남습니다.

IAM 그룹은 사용자를 묶는 통입니다. 같은 일을 하는 사람들에게 같은 허락을 한 번에 붙이려고 씁니다. 그룹 자신은 로그인하지 못하고 사람을 대신하지도 않습니다.

역할은 특정한 누구의 것도 아닌 신원입니다. 미리 만들어 두면 사람이든 프로그램이든 필요할 때 그 역할을 맡습니다. 맡고 있는 동안만 거기 적힌 허락을 씁니다.

허락을 적는 문서, 정책

허락은 정책이라는 문서에 적습니다. 정책 한 덩이가 답하는 물음은 아래와 같습니다.

물음 적는 것
누가 이 허락을 받는 신원
무엇에 보관소·테이블처럼 손댈 자원
무엇을 읽기·쓰기·삭제 같은 동작
허용인가 거부인가 그 조합을 열지 막을지
어떤 때만 요청 시각이나 요청이 온 곳처럼 더 좁히는 조건

로그 프로그램의 정책은 이 칸들을 이렇게 채웁니다. 「로그 수집 역할」이 「로그 보관소」에 「파일 넣기」를 해도 된다고 적고, 나머지는 적지 않습니다.

정책은 사람이 읽고 쓰는 글입니다. 프로그램을 다시 배포하지 않고도 고칠 수 있습니다. 대신 글이 늘어나면 지금 이 요청을 열어 주는 문장이 어느 것인지 찾기 어려워집니다.

정책이 붙는 두 방향

같은 정책을 신원 쪽에 붙일 수도 있고 자원 쪽에 붙일 수도 있습니다. 어느 쪽에 붙이든 판정할 때 함께 읽힙니다.

신원 기반 정책은 사용자·그룹·역할에 붙습니다. 「이 역할은 저 보관소에 파일을 넣어도 된다」처럼 쓰는 쪽에 적어 두는 방식입니다.

자원 기반 정책은 보관소나 큐 같은 자원 자신에 붙습니다. 「저 계정의 저 역할은 여기에 파일을 넣어도 된다」처럼 받는 쪽에 적어 둡니다.

두 방향이 다 필요한 이유는 계정 경계에 있습니다. 남의 계정에 있는 신원에는 내가 정책을 붙일 수 없습니다. 그 신원에게 허락을 주려면 내 자원 쪽에 적는 수밖에 없습니다.

요청 하나가 받는 판정

요청이 오면 IAM 은 그 요청에 걸리는 정책을 모두 모아 읽습니다. 기본은 거부입니다. 어디에도 허용이 적혀 있지 않으면 요청은 묵시적 거부로 끝납니다.

허용이 하나라도 있으면 통과합니다. 다만 거부가 한 줄이라도 적혀 있으면 그 명시적 거부가 이깁니다. 허용을 아무리 여러 곳에 적어도 거부 한 줄을 넘지 못합니다.

flowchart TD
    A[요청] --> B{거부가 적혀 있나}
    B -->|있다| D[거부]
    B -->|없다| C{허용이 적혀 있나}
    C -->|있다| E[통과]
    C -->|없다| D

이 차례 덕분에 위에서 아래로 금지선을 그을 수 있습니다. 윗선에서 거부를 적어 두면 아래에서 누가 허용을 적어도 그 자원은 열리지 않습니다.

역할을 맡아 쓰는 임시 자격증명

서버에서 도는 프로그램에도 신원이 필요합니다. 사용자를 하나 만들어 액세스 키를 발급하고 서버에 적어 두는 방법이 먼저 떠오릅니다. 그런데 이 키는 만료가 없어서 새어 나가면 사람이 알아채고 지울 때까지 계속 쓰입니다.

IAM 은 역할을 맡는 쪽을 폅니다. 서버에 역할을 붙여 두면 프로그램은 요청을 보내기 전에 임시 자격증명을 받아 씁니다. 이 자격증명은 얼마 지나지 않아 저절로 만료되고, 만료되면 다시 받습니다. 서버 안에 오래 남는 비밀이 없어집니다.

sequenceDiagram
    participant 앱 as 서버의 프로그램
    participant IAM
    participant 보관소
    앱->>IAM: 이 역할을 맡겠다
    IAM-->>앱: 잠깐 쓸 임시 자격증명
    앱->>보관소: 자격증명을 붙여 파일을 넣는다
    보관소->>IAM: 이 요청을 받아도 되나
    IAM-->>보관소: 허용
    보관소-->>앱: 넣었다

밖에서 들어오는 사람도 같은 길을 지납니다. 회사 계정으로 로그인한 직원에게 IAM 사용자를 따로 만들어 주지 않고 역할을 맡깁니다. 누구인지 확인하는 인증은 회사 쪽에 두고, 클라우드 안에서 무엇을 해도 되는지는 IAM 이 집니다.

넓게 열린 허락을 좁히는 장치

어떤 일이 되게 하려면 무엇을 열어야 하는지는 해 보기 전에 잘 모릅니다. 그래서 넓게 열어 두고 동작을 확인한 다음 줄이는 순서로 일하게 됩니다. 줄이는 쪽은 미뤄지기 쉽습니다. 이미 도는 것을 건드려야 하기 때문입니다.

IAM 은 신원마다 어떤 서비스를 마지막으로 언제 썼는지 기록해 둡니다. 오래 안 쓴 허락이 무엇인지 보이면 그것부터 걷을 수 있습니다. 걷는 기준이 되는 원칙이 최소 권한입니다.

사람이 넓게 열어도 넘지 못할 선을 따로 긋는 방법도 있습니다. 권한 경계는 한 신원이 가질 수 있는 허락의 상한을 정합니다. AWS Organizations로 계정 여럿을 묶으면 서비스 제어 정책이 그 계정들 전부에 같은 상한을 씌웁니다.

관련 항목

AWS IAM 을 이루는 구성 요소

IAM 사용자 · IAM 그룹 · 역할 · 정책 · 프린시펄 · 루트 사용자 · 권한 경계 · 신뢰 정책

AWS IAM 이 판정할 때 읽는 정책의 종류

신원 기반 정책 · 자원 기반 정책 · 서비스 제어 정책 · 세션 정책 · 버킷 정책 · ACL

AWS IAM 이 클라우드에서 구현하는 접근 제어 개념

접근 제어 · 인가 · 인증 · 권한 · 최소 권한 · 역할 기반 접근 제어 · 속성 기반 접근 제어 · 명시적 거부 · 묵시적 거부

AWS IAM 이 신원을 증명받는 수단

액세스 키 · 자격증명 · 임시 자격증명 · 다중 인증 · 페더레이션 · OpenID Connect · SAML

AWS IAM 이 허락을 거는 대상 서비스

Amazon S3 · Amazon EC2 · AWS Lambda · Amazon RDS · Amazon SQS · CloudWatch

AWS IAM 이 속하는 상위 분류

AWS · 클라우드 컴퓨팅 · 관리형 서비스 · 클라우드 보안 · AWS Organizations

AWS IAM 에서 자주 나는 오류·사고

Access Denied · HTTP 403 · 과도한 권한 · 자격증명 유출 · 혼동된 대리인 · 권한 상승

AWS IAM 과 같은 일을 하는 다른 플랫폼의 권한 관리

Google Cloud IAM · Azure RBAC · Kubernetes RBAC · Active Directory · LDAP

다른 이름: IAM · Identity and Access Management