IAM으로 AWS 보안 및 권한 체계 구축

AWS 클라우드 환경에서 보안의 핵심인 IAM(Identity and Access Management)을 처음부터 끝까지 배웁니다. 사용자, 그룹, 역할, 정책의 개념부터 실무에서 바로 적용할 수 있는 보안 설정까지, 초급 개발자도 쉽게 따라할 수 있도록 설명합니다.

---

목차

1. IAM의_핵심_개념
2. 루트_사용자_보호와_MFA_설정
3. Admin_사용자_및_그룹_생성
4. 정책_문서_작성
5. 역할을_통한_서비스_간_권한_부여
6. 계정_간_역할_전환

---

1. IAM의 핵심 개념

어느 날 김개발 씨가 회사에서 처음으로 AWS 콘솔에 접속했습니다. 선배가 건네준 계정으로 로그인했는데, 화면에 보이는 서비스가 몇 개 없습니다.

"어, 저는 왜 EC2만 보이고 S3는 안 보이는 거죠?" 선배 박시니어 씨가 웃으며 대답합니다. "그게 바로 IAM이야.

네가 할 수 있는 일을 정해놓은 거지."

**IAM(Identity and Access Management)**은 한마디로 AWS에서 누가 무엇을 할 수 있는지를 관리하는 서비스입니다. 마치 회사 건물의 출입 카드 시스템과 같습니다.

어떤 사람은 모든 층에 출입할 수 있고, 어떤 사람은 자기 사무실만 들어갈 수 있듯이, IAM은 AWS 리소스에 대한 접근 권한을 세밀하게 제어합니다.

다음 코드를 살펴봅시다.

// IAM의 4가지 핵심 구성요소
const iamComponents = {
  // 1. 사용자(User): AWS에 접근하는 개별 계정
  user: "kim-developer",

  // 2. 그룹(Group): 사용자들의 모음, 권한 일괄 적용
  group: "developers",

  // 3. 역할(Role): 임시로 부여받는 권한 세트
  role: "EC2-S3-Access-Role",

  // 4. 정책(Policy): 실제 권한을 정의한 JSON 문서
  policy: {
    Effect: "Allow",
    Action: "s3:GetObject",
    Resource: "arn:aws:s3:::my-bucket/*"
  }
};

김개발 씨는 입사 첫 주에 AWS 계정을 받았습니다. 그런데 이상합니다.

분명 AWS에는 수백 개의 서비스가 있다고 들었는데, 자신의 화면에는 EC2와 CloudWatch만 보입니다. 옆자리 동료에게 물어보니 그 동료는 S3와 Lambda가 보인다고 합니다.

박시니어 씨가 다가와 설명해줍니다. "AWS에서는 모든 사람에게 모든 권한을 주지 않아.

그게 바로 보안의 기본이거든." 그렇다면 IAM이란 정확히 무엇일까요? 쉽게 비유하자면, IAM은 마치 대형 쇼핑몰의 보안 시스템과 같습니다.

쇼핑몰에는 고객, 직원, 관리자가 있습니다. 고객은 매장에만 들어갈 수 있고, 직원은 창고에도 접근할 수 있으며, 관리자는 사무실까지 출입할 수 있습니다.

IAM도 마찬가지로 누가 어디에 접근할 수 있는지를 정밀하게 관리합니다. IAM의 첫 번째 구성요소는 **사용자(User)**입니다.

AWS에 접속하는 개별 계정을 의미합니다. 김개발 씨가 받은 계정이 바로 IAM 사용자입니다.

각 사용자는 고유한 자격 증명을 가지며, 콘솔 로그인이나 API 호출에 사용됩니다. 두 번째는 **그룹(Group)**입니다.

사용자들을 묶어놓은 것입니다. 개발팀 그룹, 운영팀 그룹처럼 역할별로 사용자를 모아두면 권한 관리가 훨씬 쉬워집니다.

새 개발자가 입사하면 개발팀 그룹에 추가하기만 하면 됩니다. 세 번째는 **역할(Role)**입니다.

이것은 조금 특별합니다. 사용자에게 고정된 권한이 아니라, 필요할 때 임시로 부여받는 권한 세트입니다.

마치 영화관에서 3D 안경을 빌려 쓰는 것처럼, 역할은 필요한 순간에만 사용하고 반납합니다. 네 번째는 **정책(Policy)**입니다.

이것이 실제 권한의 본체입니다. JSON 형식으로 작성된 문서로, 어떤 행동을 허용하거나 거부할지 명시합니다.

정책은 사용자, 그룹, 역할에 연결되어 실제 권한을 부여합니다. 실무에서 이 네 가지는 어떻게 조합될까요?

예를 들어 스타트업에서 5명의 개발자가 있다고 가정합시다. 각 개발자마다 일일이 권한을 설정하면 관리가 복잡해집니다.

대신 "developers"라는 그룹을 만들고, 이 그룹에 필요한 정책들을 연결합니다. 그리고 5명의 개발자를 이 그룹에 추가하면 끝입니다.

하지만 주의할 점이 있습니다. 권한은 항상 최소한으로 부여해야 합니다.

이를 **최소 권한 원칙(Principle of Least Privilege)**이라고 합니다. 처음부터 모든 권한을 주면 편하겠지만, 보안 사고가 발생했을 때 피해가 커집니다.

다시 김개발 씨 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 저한테는 필요한 권한만 주어진 거군요!" 이제 IAM이 왜 중요한지 이해했습니다.

실전 팁

💡 - 사용자 개별 권한보다 그룹을 통한 권한 관리가 실수를 줄입니다

• 정책은 가능한 구체적으로 작성하고, 와일드카드(*)는 신중하게 사용하세요

---

2. 루트 사용자 보호와 MFA 설정

김개발 씨가 퇴근 후 뉴스를 보다가 깜짝 놀랐습니다. "A 스타트업, AWS 해킹으로 수천만 원 과금 피해." 기사를 읽어보니 루트 계정이 탈취당했다고 합니다.

다음 날 출근해서 박시니어 씨에게 물었습니다. "저희 회사 루트 계정은 괜찮은 거죠?" 박시니어 씨의 표정이 심각해집니다.

"루트 계정 보호가 얼마나 중요한지 제대로 알려줄게."

**루트 사용자(Root User)**는 AWS 계정을 처음 만들 때 사용한 이메일로 로그인하는 계정입니다. 마치 건물의 마스터키와 같아서 모든 것을 할 수 있습니다.

그래서 반드시 **MFA(Multi-Factor Authentication)**를 설정하고, 일상적인 작업에는 절대 사용하지 않아야 합니다.

다음 코드를 살펴봅시다.

// AWS CLI로 MFA 디바이스 활성화 상태 확인
// 루트 계정과 IAM 사용자 모두 확인해야 합니다

// 1. 현재 계정의 MFA 디바이스 목록 조회
aws iam list-mfa-devices --user-name kim-developer

// 2. 가상 MFA 디바이스 생성 (IAM 사용자용)
aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name kim-developer-mfa \
  --outfile /tmp/QRCode.png \
  --bootstrap-method QRCodePNG

// 3. MFA 디바이스 활성화 (인증 앱의 코드 2개 필요)
aws iam enable-mfa-device \
  --user-name kim-developer \
  --serial-number arn:aws:iam::123456789012:mfa/kim-developer-mfa \
  --authentication-code1 123456 \
  --authentication-code2 789012

그날 밤, 김개발 씨는 잠이 오지 않았습니다. 뉴스에서 본 스타트업 해킹 사건이 자꾸 떠올랐습니다.

그 회사는 루트 계정 비밀번호가 유출되어 해커가 수백 대의 EC2 인스턴스를 가동했고, 하루 만에 수천만 원의 요금이 청구되었습니다. 다음 날, 박시니어 씨가 회의실로 김개발 씨를 불렀습니다.

"AWS 보안의 첫 번째 원칙을 알려줄게. 루트 계정은 금고 속에 넣어둬." 루트 사용자란 무엇일까요?

AWS 계정을 처음 만들 때 사용한 이메일 주소와 비밀번호로 로그인하는 계정입니다. 이 계정은 AWS에서 할 수 있는 모든 것을 할 수 있습니다.

계정 삭제, 결제 정보 변경, 모든 리소스 삭제가 가능합니다. 말 그대로 신과 같은 권한입니다.

문제는 여기서 시작됩니다. 루트 계정이 탈취되면 어떤 일이 벌어질까요?

해커는 당신의 모든 데이터를 삭제할 수 있습니다. 새로운 리소스를 무제한으로 생성할 수 있습니다.

결제 정보를 변경하여 환불금을 가로챌 수도 있습니다. 심지어 계정 이메일을 바꿔버리면 당신은 영원히 그 계정에 접근할 수 없게 됩니다.

그래서 **MFA(Multi-Factor Authentication)**가 필수입니다. MFA는 마치 금고의 이중 잠금장치와 같습니다.

비밀번호라는 첫 번째 열쇠가 있어도, 두 번째 열쇠인 일회용 코드가 없으면 열리지 않습니다. 해커가 비밀번호를 알아내도 당신의 휴대폰에 설치된 인증 앱이 없으면 로그인할 수 없습니다.

MFA 설정 방법은 간단합니다. AWS 콘솔에서 IAM 대시보드로 이동한 뒤, 보안 권장 사항에서 MFA 추가를 클릭합니다.

Google Authenticator나 Authy 같은 앱으로 QR 코드를 스캔하면 됩니다. 앱에 표시되는 6자리 코드 두 개를 연속으로 입력하면 설정이 완료됩니다.

하지만 MFA만으로는 부족합니다. 두 번째 원칙이 있습니다.

루트 계정은 일상적인 작업에 절대 사용하지 마세요. AWS 공식 문서에서도 강력히 권고합니다.

루트 계정이 필요한 작업은 매우 제한적입니다. 계정 설정 변경, 결제 정보 수정, AWS 지원 플랜 변경 정도입니다.

그 외 모든 작업은 IAM 사용자로 해야 합니다. 실무에서는 어떻게 할까요?

루트 계정 비밀번호는 매우 복잡하게 설정하고, 안전한 곳에 보관합니다. 비밀번호 관리자를 사용하거나, 물리적인 금고에 적어서 보관하는 회사도 있습니다.

MFA 복구 코드도 별도로 보관해야 합니다. 휴대폰을 분실하면 MFA 복구 코드 없이는 계정에 접근할 수 없기 때문입니다.

박시니어 씨가 마지막으로 당부했습니다. "루트 계정은 비상금이라고 생각해.

있다는 건 알지만, 평소에는 절대 건드리지 않는 거야." 김개발 씨는 그 자리에서 바로 자신의 개인 AWS 계정에 MFA를 설정했습니다. 5분도 안 걸렸지만, 그 5분이 수천만 원의 피해를 막을 수 있다는 것을 깨달았습니다.

실전 팁

💡 - 루트 계정에는 반드시 하드웨어 MFA 또는 가상 MFA를 설정하세요

• MFA 복구 코드는 별도의 안전한 장소에 보관하고, 정기적으로 확인하세요

---

3. Admin 사용자 및 그룹 생성

루트 계정을 금고에 넣어두기로 한 김개발 씨. 그런데 문제가 생겼습니다.

"그럼 누가 새 직원 계정을 만들고 권한을 관리하죠?" 박시니어 씨가 화이트보드에 그림을 그리기 시작합니다. "관리자 역할을 할 IAM 사용자를 만들면 돼.

루트만큼 강력하지만, 추적이 가능하고 필요하면 삭제할 수도 있지."

Admin 사용자는 거의 모든 AWS 작업을 수행할 수 있는 IAM 사용자입니다. 루트 사용자 대신 일상적인 관리 작업을 담당합니다.

Admin 그룹을 만들고 AdministratorAccess 정책을 연결한 뒤, 관리자 역할을 맡은 사용자를 이 그룹에 추가하는 것이 모범 사례입니다.

다음 코드를 살펴봅시다.

// AWS CLI로 Admin 그룹과 사용자 생성하기

// 1. 관리자 그룹 생성
aws iam create-group --group-name Administrators

// 2. AdministratorAccess 정책을 그룹에 연결
aws iam attach-group-policy \
  --group-name Administrators \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

// 3. Admin 사용자 생성
aws iam create-user --user-name admin-park

// 4. 사용자를 관리자 그룹에 추가
aws iam add-user-to-group \
  --user-name admin-park \
  --group-name Administrators

// 5. 콘솔 로그인용 비밀번호 설정
aws iam create-login-profile \
  --user-name admin-park \
  --password "TempPassword123!" \
  --password-reset-required

박시니어 씨가 화이트보드에 간단한 도형을 그렸습니다. 맨 위에 왕관을 쓴 사람이 루트 사용자입니다.

그 아래에 관리자 배지를 단 사람이 Admin 사용자입니다. 겉보기에는 비슷해 보이지만, 결정적인 차이가 있습니다.

"루트 사용자는 AWS에 기록이 남지 않는 작업도 할 수 있어. 하지만 IAM 사용자는 모든 행동이 CloudTrail에 기록돼." 이것이 Admin 사용자를 만드는 첫 번째 이유입니다.

추적 가능성입니다. 누가 언제 무엇을 했는지 모든 기록이 남습니다.

보안 사고가 발생했을 때 원인을 파악하고 책임 소재를 명확히 할 수 있습니다. 두 번째 이유는 유연성입니다.

Admin 사용자라도 필요하면 권한을 제한하거나 계정을 삭제할 수 있습니다. 하지만 루트 사용자는 삭제할 수 없습니다.

AWS 계정이 존재하는 한 루트도 존재합니다. 그렇다면 Admin 사용자는 어떻게 만들까요?

먼저 Administrators라는 그룹을 만듭니다. 왜 바로 사용자에게 권한을 주지 않고 그룹을 만들까요?

회사에 관리자가 한 명이 아닐 수 있기 때문입니다. 박시니어 씨도 관리자고, CTO도 관리자일 수 있습니다.

그룹으로 관리하면 누가 관리자 권한을 가졌는지 한눈에 파악할 수 있습니다. 그룹을 만들었으면 AdministratorAccess 정책을 연결합니다.

이것은 AWS가 미리 만들어둔 정책으로, 거의 모든 AWS 서비스에 대한 전체 권한을 부여합니다. 정책 이름 앞에 "AWS managed"라고 표시된 것이 AWS 기본 제공 정책입니다.

다음으로 사용자를 생성합니다. 사용자 이름은 팀 내에서 규칙을 정해두면 좋습니다.

예를 들어 "admin-이름" 형식으로 하면 일반 사용자와 구분하기 쉽습니다. 마지막으로 사용자를 그룹에 추가합니다.

이 순간부터 해당 사용자는 관리자 권한을 갖게 됩니다. 실무에서 중요한 점이 있습니다.

Admin 사용자라도 반드시 MFA를 설정해야 합니다. 오히려 일반 사용자보다 더 강력한 보안이 필요합니다.

관리자 계정이 탈취되면 회사 전체의 AWS 인프라가 위험해지기 때문입니다. 또한 Admin 사용자는 최소한으로 유지해야 합니다.

모든 개발자에게 Admin 권한을 주는 것은 위험합니다. 실수로 프로덕션 데이터베이스를 삭제하거나, 보안 그룹 설정을 변경해서 서비스 장애를 일으킬 수 있습니다.

박시니어 씨가 정리해줍니다. "Admin 권한은 꼭 필요한 사람에게만 줘.

나머지는 각자 업무에 필요한 최소한의 권한만 가지면 돼." 김개발 씨는 자신이 Admin 권한이 없다는 것이 오히려 다행이라고 생각했습니다. 잘못된 명령어 하나로 회사 서비스를 날릴 걱정을 하지 않아도 되니까요.

실전 팁

💡 - Admin 그룹에 속한 사용자 목록을 정기적으로 검토하고, 불필요한 계정은 제거하세요

• Admin 사용자에게도 MFA 설정은 필수이며, 가능하면 하드웨어 MFA를 사용하세요

---

4. 정책 문서 작성

개발팀에 새 프로젝트가 시작되었습니다. 김개발 씨는 S3 버킷에 파일을 업로드해야 하는데, 권한이 없다는 에러가 발생합니다.

박시니어 씨에게 요청하자, 박시니어 씨가 말합니다. "직접 정책을 작성해볼래?

그래야 나중에 필요한 권한을 스스로 요청할 수 있거든." 김개발 씨 앞에 복잡해 보이는 JSON 문서가 펼쳐집니다.

**정책 문서(Policy Document)**는 AWS에서 권한을 정의하는 JSON 형식의 문서입니다. 마치 계약서처럼 누가 어떤 조건에서 무엇을 할 수 있는지 명확하게 기술합니다.

Effect, Action, Resource가 핵심 요소이며, 이 세 가지를 이해하면 어떤 정책도 읽고 작성할 수 있습니다.

다음 코드를 살펴봅시다.

// S3 버킷에 대한 읽기/쓰기 권한을 부여하는 정책 문서
{
  "Version": "2012-10-17",
  "Statement": [
    {
      // 허용(Allow) 또는 거부(Deny)
      "Effect": "Allow",

      // 허용할 작업 목록
      "Action": [
        "s3:GetObject",      // 객체 읽기
        "s3:PutObject",      // 객체 업로드
        "s3:DeleteObject"    // 객체 삭제
      ],

      // 권한이 적용되는 리소스 (ARN 형식)
      "Resource": [
        "arn:aws:s3:::my-project-bucket/*"
      ],

      // 선택사항: 조건 추가
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

박시니어 씨가 모니터에 JSON 문서를 띄웠습니다. 김개발 씨는 중괄호와 대괄호가 뒤섞인 문서를 보며 한숨을 쉬었습니다.

"이게 다 뭔가요?" "걱정 마. 생각보다 간단해.

핵심은 세 가지야." 박시니어 씨가 세 단어를 화이트보드에 적었습니다. Effect, Action, Resource.

먼저 Effect입니다. 이것은 허용할지 거부할지를 결정합니다.

값은 단 두 개뿐입니다. "Allow" 아니면 "Deny".

마치 문 앞의 경비원이 "들어오세요" 또는 "들어올 수 없습니다"라고 말하는 것과 같습니다. 다음은 Action입니다.

이것은 무엇을 할 수 있는지를 정의합니다. AWS의 모든 작업은 "서비스:작업" 형식으로 표현됩니다.

예를 들어 "s3:GetObject"는 S3에서 객체를 가져오는 것이고, "ec2:StartInstances"는 EC2 인스턴스를 시작하는 것입니다. 마지막은 Resource입니다.

이것은 어디에 적용되는지를 명시합니다. ARN(Amazon Resource Name)이라는 고유 식별자로 표현합니다.

"arn:aws:s3:::my-bucket/*"는 my-bucket이라는 S3 버킷의 모든 객체를 의미합니다. 이 세 가지를 조합하면 문장이 됩니다.

"my-bucket의 모든 객체에 대해 GetObject 작업을 허용한다." 여기에 Condition을 추가하면 더 정교해집니다. 예를 들어 특정 IP 주소에서만 접근을 허용하거나, 특정 시간대에만 작업을 허용할 수 있습니다.

조건은 선택 사항이지만, 보안을 강화할 때 매우 유용합니다. 정책 문서의 맨 위에는 Version이 있습니다.

현재는 "2012-10-17"을 사용합니다. 오래된 버전처럼 보이지만, 이것이 최신 버전이며 AWS에서 계속 사용하고 있습니다.

이 날짜를 바꾸면 정책이 제대로 동작하지 않을 수 있으니 주의하세요. Statement는 정책 규칙들의 배열입니다.

하나의 정책 문서에 여러 규칙을 담을 수 있습니다. 예를 들어 첫 번째 규칙에서는 S3 읽기를 허용하고, 두 번째 규칙에서는 EC2 조회를 허용할 수 있습니다.

실무에서 흔히 하는 실수가 있습니다. Action에 와일드카드(*)를 남발하는 것입니다.

"s3:*"라고 쓰면 S3의 모든 작업이 허용됩니다. 편리해 보이지만, 의도치 않게 버킷 삭제나 정책 변경 권한까지 주게 됩니다.

반드시 필요한 Action만 명시하세요. 또 다른 실수는 Resource를 너무 넓게 잡는 것입니다.

"*"로 설정하면 모든 리소스에 적용됩니다. 프로젝트 버킷만 접근해야 하는데, 실수로 다른 팀의 버킷까지 건드릴 수 있습니다.

김개발 씨가 고개를 끄덕였습니다. "결국 필요한 것만 최소한으로 적는 게 핵심이군요." 박시니어 씨가 웃으며 말했습니다.

"맞아. 그게 바로 최소 권한 원칙이야.

정책을 작성할 때 항상 기억해."

실전 팁

💡 - AWS 정책 시뮬레이터를 사용하면 정책이 의도대로 동작하는지 테스트할 수 있습니다

• Action과 Resource에는 필요한 것만 명시하고, 와일드카드(*)는 신중하게 사용하세요

---

5. 역할을 통한 서비스 간 권한 부여

김개발 씨가 Lambda 함수를 작성했습니다. 함수에서 S3 버킷의 파일을 읽어야 하는데, 계속 "Access Denied" 에러가 발생합니다.

"제 IAM 계정에는 S3 권한이 있는데 왜 Lambda에서는 안 되죠?" 박시니어 씨가 설명합니다. "Lambda는 네 계정이 아니라 자기 자신의 역할로 실행되거든.

서비스에게 권한을 주려면 역할을 사용해야 해."

**역할(Role)**은 AWS 서비스나 다른 계정이 임시로 사용할 수 있는 권한 세트입니다. 사용자에게 직접 권한을 줄 수 없는 상황에서 사용합니다.

Lambda가 S3에 접근하거나, EC2 인스턴스가 DynamoDB를 사용할 때 역할을 통해 권한을 부여합니다. 역할은 **신뢰 정책(Trust Policy)**과 **권한 정책(Permission Policy)**으로 구성됩니다.

다음 코드를 살펴봅시다.

// Lambda가 S3를 사용할 수 있게 하는 역할 생성

// 1. 신뢰 정책 (Trust Policy) - 누가 이 역할을 맡을 수 있는가
const trustPolicy = {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "lambda.amazonaws.com"  // Lambda 서비스가 이 역할을 맡음
    },
    "Action": "sts:AssumeRole"
  }]
};

// 2. 권한 정책 (Permission Policy) - 역할이 무엇을 할 수 있는가
const permissionPolicy = {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-data-bucket/*"
  }]
};

// AWS CLI로 역할 생성
// aws iam create-role --role-name LambdaS3AccessRole \
//   --assume-role-policy-document file://trust-policy.json

김개발 씨는 혼란스러웠습니다. 자신의 IAM 계정에는 분명히 S3 읽기 권한이 있습니다.

그런데 자신이 작성한 Lambda 함수는 왜 S3에 접근하지 못할까요? 박시니어 씨가 차근차근 설명했습니다.

"Lambda 함수가 실행될 때는 네 계정으로 실행되는 게 아니야. Lambda 서비스 자체가 실행하는 거지." 이것을 이해하려면 비유가 필요합니다.

당신이 회사에서 업무를 볼 때는 직원 카드로 건물에 출입합니다. 하지만 당신이 로봇을 만들어서 대신 일하게 했다면, 그 로봇도 출입 카드가 필요합니다.

당신의 카드를 로봇에게 줄 수는 없습니다. 로봇 전용 카드를 만들어야 합니다.

역할이 바로 그 "로봇 전용 카드"입니다. 역할은 두 가지 정책으로 구성됩니다.

첫 번째는 **신뢰 정책(Trust Policy)**입니다. 이것은 "누가 이 역할을 맡을 수 있는가"를 정의합니다.

Lambda 서비스가 역할을 맡을 수 있게 하려면 Principal에 "lambda.amazonaws.com"을 지정합니다. 두 번째는 **권한 정책(Permission Policy)**입니다.

우리가 이전에 배운 정책 문서와 같습니다. 역할을 맡은 대상이 무엇을 할 수 있는지 정의합니다.

신뢰 정책에는 특별한 Action이 있습니다. sts:AssumeRole입니다.

"역할을 맡다"라는 의미입니다. STS는 Security Token Service의 약자로, AWS에서 임시 보안 자격 증명을 발급하는 서비스입니다.

역할의 가장 큰 특징은 임시성입니다. 역할을 맡으면 임시 자격 증명을 받습니다.

이 자격 증명은 일정 시간이 지나면 만료됩니다. 기본적으로 1시간이며, 최대 12시간까지 설정할 수 있습니다.

왜 임시 자격 증명이 좋을까요? 만약 자격 증명이 유출되어도 일정 시간 후에는 자동으로 만료되기 때문입니다.

영구적인 Access Key보다 훨씬 안전합니다. 실무에서 역할은 다양한 곳에 사용됩니다.

Lambda가 다른 AWS 서비스를 호출할 때, EC2 인스턴스가 S3에 파일을 저장할 때, ECS 컨테이너가 Secrets Manager에서 비밀번호를 읽을 때 모두 역할을 사용합니다. 중요한 점이 있습니다.

역할에도 최소 권한 원칙을 적용해야 합니다. Lambda에 "AdministratorAccess" 역할을 부여하면 Lambda 코드에 취약점이 있을 때 공격자가 AWS 전체를 장악할 수 있습니다.

Lambda가 S3만 사용한다면 S3 관련 권한만 부여하세요. 김개발 씨가 물었습니다.

"역할 이름은 어떻게 짓나요?" 박시니어 씨가 대답했습니다. "서비스-용도-Role 형식을 추천해.

예를 들어 Lambda-S3Uploader-Role처럼 말이야. 나중에 봐도 무슨 용도인지 바로 알 수 있거든." 김개발 씨는 Lambda 함수에 적절한 역할을 연결하고, 드디어 S3에서 파일을 읽는 데 성공했습니다.

실전 팁

💡 - 역할 이름은 용도를 명확히 알 수 있게 짓고, 태그를 활용해 관리하세요

• Lambda, EC2 등 서비스용 역할에도 필요한 최소한의 권한만 부여하세요

---

6. 계정 간 역할 전환

회사가 성장하면서 AWS 계정이 여러 개로 늘어났습니다. 개발 계정, 스테이징 계정, 프로덕션 계정.

김개발 씨는 매번 로그아웃했다가 다른 계정으로 로그인하는 게 번거롭습니다. "매번 비밀번호 입력하기 귀찮은데, 더 좋은 방법 없나요?" 박시니어 씨가 답합니다.

"역할 전환을 사용하면 로그아웃 없이 계정을 오갈 수 있어."

**계정 간 역할 전환(Cross-Account Access)**은 하나의 AWS 계정에서 다른 계정의 역할을 맡아 작업하는 것입니다. 마치 한 회사의 직원이 협력 회사 건물에 임시 출입증을 받아 들어가는 것과 같습니다.

로그아웃 없이 계정 간 이동이 가능하고, 중앙 집중식 접근 관리가 가능해집니다.

다음 코드를 살펴봅시다.

// Cross-Account 역할 설정

// 1. 대상 계정(프로덕션)에 역할 생성 - 신뢰 정책
// 계정 ID: 111111111111 (개발 계정에서 접근 허용)
const crossAccountTrustPolicy = {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111111111111:root"  // 개발 계정
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" }  // MFA 필수
    }
  }]
};

// 2. 개발 계정 사용자에게 역할 전환 권한 부여
const assumeRolePolicy = {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::222222222222:role/ProdReadOnlyRole"
  }]
};

// AWS CLI로 역할 전환
// aws sts assume-role --role-arn arn:aws:iam::222222222222:role/ProdReadOnlyRole \
//   --role-session-name kim-developer-session

김개발 씨의 회사는 빠르게 성장했습니다. 처음에는 하나의 AWS 계정으로 모든 것을 관리했지만, 지금은 상황이 다릅니다.

개발 환경, 스테이징 환경, 프로덕션 환경이 각각 별도의 AWS 계정으로 분리되었습니다. 왜 계정을 분리했을까요?

첫 번째 이유는 격리입니다. 개발 환경의 실수가 프로덕션에 영향을 주지 않습니다.

두 번째는 비용 추적입니다. 각 환경의 비용을 명확하게 파악할 수 있습니다.

세 번째는 보안입니다. 프로덕션 계정에는 더 엄격한 보안 정책을 적용할 수 있습니다.

하지만 문제가 생겼습니다. 김개발 씨는 하루에도 여러 번 계정을 오갑니다.

개발 계정에서 코드를 테스트하고, 스테이징 계정에서 QA를 진행하고, 프로덕션 계정에서 모니터링을 확인합니다. 매번 로그아웃하고 다시 로그인하는 것은 번거롭고 시간 낭비입니다.

여기서 역할 전환이 등장합니다. 역할 전환의 원리는 간단합니다.

프로덕션 계정에 "이 역할을 개발 계정의 사용자가 맡을 수 있다"라는 설정을 합니다. 그러면 개발 계정에 로그인한 상태로 프로덕션 계정의 역할로 전환할 수 있습니다.

마치 출장 가서 협력 회사의 임시 출입증을 받는 것과 같습니다. 설정은 양쪽 계정에서 해야 합니다.

먼저 **대상 계정(프로덕션)**에서 역할을 만듭니다. 이 역할의 신뢰 정책에는 원본 계정(개발)의 ARN을 지정합니다.

"개발 계정의 사용자들이 이 역할을 맡을 수 있다"라고 선언하는 것입니다. 다음으로 **원본 계정(개발)**에서 사용자에게 역할 전환 권한을 부여합니다.

"이 사용자는 프로덕션 계정의 이 역할을 맡을 수 있다"라고 정책을 추가합니다. 양쪽 설정이 완료되면 콘솔에서 역할 전환이 가능합니다.

오른쪽 상단의 사용자 이름을 클릭하고 "역할 전환"을 선택합니다. 대상 계정 ID와 역할 이름을 입력하면 즉시 해당 계정으로 전환됩니다.

로그아웃 없이 화면 상단의 배경색이 바뀌면서 현재 어느 계정에 있는지 알 수 있습니다. 보안을 위해 추가 설정을 권장합니다.

신뢰 정책에 MFA 조건을 추가하세요. MFA 인증을 완료한 사용자만 역할 전환이 가능하게 됩니다.

프로덕션 계정처럼 중요한 환경에는 필수입니다. 또한 역할에 부여하는 권한도 신중하게 결정해야 합니다.

개발자가 프로덕션에 접근할 때 전체 관리자 권한이 필요할까요? 대부분의 경우 읽기 권한만으로 충분합니다.

로그 확인, 모니터링 조회 정도만 가능한 ReadOnly 역할을 만들어 사용하세요. 박시니어 씨가 조언합니다.

"역할 전환은 편리하지만, 그만큼 신중해야 해. 특히 프로덕션 계정에는 쓰기 권한을 가진 역할을 최소화하고, 반드시 MFA를 요구해야 해." 김개발 씨는 이제 로그인 정보 여러 개를 관리할 필요가 없어졌습니다.

하나의 계정으로 로그인한 후 필요에 따라 역할만 전환하면 됩니다. 작업 효율이 크게 올라갔습니다.

실전 팁

💡 - 역할 전환 시 표시되는 색상을 환경별로 다르게 설정하면 실수를 방지할 수 있습니다

• 프로덕션 계정의 역할에는 반드시 MFA 조건을 추가하고, 가능하면 읽기 전용 역할만 사용하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!