AWS IAM 사용자와 권한 완벽 가이드

AWS 계정을 안전하게 관리하는 IAM의 모든 것을 초급 개발자 눈높이에 맞춰 설명합니다. 루트 사용자의 위험성부터 IAM 사용자 생성, 그룹 관리, 정책 설정, 역할 활용까지 실무에서 바로 쓸 수 있는 내용을 담았습니다.

1. IAM이란 무엇인가

어느 날 김개발 씨가 AWS 계정을 만들고 처음으로 EC2 인스턴스를 띄워봤습니다. 그런데 선배 박시니어 씨가 심각한 표정으로 말했습니다.

"지금 루트 계정으로 작업하고 있어요? 그거 정말 위험한 행동이에요."

**IAM(Identity and Access Management)**은 AWS 리소스에 대한 접근을 안전하게 제어하는 서비스입니다. 마치 회사 출입증 시스템처럼, 누가 어떤 리소스에 접근할 수 있는지를 세밀하게 관리합니다.

IAM을 제대로 이해하면 보안 사고를 예방하고 팀원들에게 적절한 권한을 부여할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK를 사용한 IAM 사용자 확인 예제
const { IAMClient, GetUserCommand } = require("@aws-sdk/client-iam");

// IAM 클라이언트 생성
const client = new IAMClient({ region: "ap-northeast-2" });

async function getCurrentUser() {
  try {
    // 현재 인증된 사용자 정보 조회
    const command = new GetUserCommand({});
    const response = await client.send(command);

    console.log("현재 사용자:", response.User.UserName);
    console.log("사용자 ARN:", response.User.Arn);
    console.log("생성일:", response.User.CreateDate);
  } catch (error) {
    console.error("사용자 정보 조회 실패:", error.message);
  }
}

getCurrentUser();

김개발 씨는 입사 1주일 차 신입 개발자입니다. 처음으로 AWS 계정을 만들고 설레는 마음으로 여러 서비스를 테스트하고 있었습니다.

EC2도 띄워보고, S3 버킷도 만들어봤습니다. 그런데 옆자리 박시니어 씨가 화면을 보더니 깜짝 놀랐습니다.

"김개발 씨, 지금 루트 계정으로 작업하고 있어요? 그건 정말 위험해요!" 김개발 씨는 의아했습니다.

내 계정인데 뭐가 문제지? 하지만 박시니어 씨의 진지한 표정을 보니 심각한 문제인 것 같습니다.

그렇다면 IAM이란 정확히 무엇일까요? 쉽게 비유하자면, IAM은 마치 회사의 출입 관리 시스템과 같습니다.

회사에는 사장님부터 인턴까지 다양한 직급의 사람들이 있습니다. 사장님은 금고실까지 들어갈 수 있지만, 인턴은 자기 팀 사무실만 들어갈 수 있습니다.

이처럼 IAM도 AWS 계정에서 누가 어떤 리소스에 접근할 수 있는지를 세밀하게 관리합니다. IAM이 없던 초기 클라우드 시절에는 어땠을까요?

모든 팀원이 하나의 루트 계정 정보를 공유해야 했습니다. 이것은 마치 회사의 모든 직원이 사장님 출입증을 복사해서 쓰는 것과 같습니다.

누가 무엇을 했는지 추적하기도 어렵고, 퇴사한 직원이 생기면 비밀번호를 바꿔야 하는 번거로움이 있었습니다. 더 큰 문제는 실수로 중요한 리소스를 삭제해도 누가 한 것인지 알 수 없다는 점이었습니다.

바로 이런 문제를 해결하기 위해 IAM이 등장했습니다. IAM을 사용하면 각 팀원마다 개별 계정을 만들 수 있습니다.

또한 각 계정에 필요한 권한만 정확히 부여할 수 있습니다. 무엇보다 모든 작업 내역이 기록되어 누가 무엇을 했는지 추적할 수 있다는 큰 이점이 있습니다.

IAM의 핵심 구성 요소는 크게 네 가지입니다. 첫째, **사용자(User)**입니다.

실제 사람이나 애플리케이션에 대응되는 개별 계정입니다. 둘째, **그룹(Group)**입니다.

비슷한 역할을 하는 사용자들을 묶어서 관리합니다. 셋째, **정책(Policy)**입니다.

무엇을 할 수 있고 없는지를 정의하는 규칙입니다. 넷째, **역할(Role)**입니다.

임시로 권한을 부여받을 수 있는 자격증명입니다. 위의 코드를 살펴보겠습니다.

먼저 AWS SDK의 IAM 클라이언트를 생성합니다. 이 클라이언트를 통해 IAM 관련 작업을 수행할 수 있습니다.

다음으로 GetUserCommand를 사용해서 현재 인증된 사용자의 정보를 조회합니다. 결과로 사용자 이름, ARN(고유 식별자), 생성일 등을 확인할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 스타트업에서 새로운 개발자가 입사했다고 가정해봅시다.

CTO는 IAM을 통해 이 개발자에게 개발 환경의 EC2와 S3에만 접근할 수 있는 계정을 만듭니다. 프로덕션 환경이나 결제 정보에는 접근할 수 없도록 제한합니다.

이렇게 하면 실수로 인한 사고를 예방할 수 있고, 보안도 강화됩니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 "귀찮다"는 이유로 모든 권한을 다 주는 것입니다. 이렇게 하면 IAM을 사용하는 의미가 없어집니다.

따라서 **최소 권한 원칙(Principle of Least Privilege)**을 지켜서, 업무에 꼭 필요한 권한만 부여해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 회사마다 IAM 정책이 중요하다고 하는 거군요!" IAM을 제대로 이해하면 안전하고 체계적인 AWS 환경을 구축할 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 자신만의 IAM 전략을 세워보세요.

실전 팁

💡 - IAM은 무료 서비스입니다. 비용 걱정 없이 마음껏 사용하세요

루트 계정은 MFA를 설정하고 금고에 보관하듯 안전하게 관리하세요
권한을 줄 때는 항상 최소 권한 원칙을 따르세요

2. 루트 사용자 vs IAM 사용자

김개발 씨가 IAM의 중요성을 깨닫고 박시니어 씨에게 물었습니다. "그럼 루트 계정이랑 IAM 사용자가 정확히 뭐가 다른 건가요?" 박시니어 씨는 커피를 한 모금 마시고 차근차근 설명하기 시작했습니다.

루트 사용자는 AWS 계정을 처음 만들 때 생성되는 최고 권한자입니다. 반면 IAM 사용자는 제한된 권한을 가진 일반 사용자입니다.

마치 회사 사장님과 직원의 차이와 같습니다. 루트 사용자는 모든 것을 할 수 있지만, 그만큼 위험하기 때문에 일상적인 작업에는 IAM 사용자를 사용해야 합니다.

다음 코드를 살펴봅시다.

// 루트 사용자와 IAM 사용자의 권한 차이 확인
const { STSClient, GetCallerIdentityCommand } = require("@aws-sdk/client-sts");

async function checkCurrentIdentity() {
  const client = new STSClient({ region: "ap-northeast-2" });

  try {
    // 현재 사용 중인 자격증명 확인
    const command = new GetCallerIdentityCommand({});
    const response = await client.send(command);

    console.log("계정 ID:", response.Account);
    console.log("사용자 ARN:", response.Arn);

    // ARN으로 루트 사용자인지 확인
    if (response.Arn.includes(":root")) {
      console.warn("⚠️ 경고: 루트 사용자로 접속했습니다!");
      console.warn("일상 작업에는 IAM 사용자를 사용하세요.");
    } else {
      console.log("✓ IAM 사용자로 안전하게 접속했습니다.");
    }
  } catch (error) {
    console.error("자격증명 확인 실패:", error.message);
  }
}

checkCurrentIdentity();

박시니어 씨는 화이트보드에 그림을 그리기 시작했습니다. 왼쪽에는 왕관을 쓴 사람을, 오른쪽에는 일반 직원을 그렸습니다.

"루트 사용자는 AWS 계정의 절대 권한자예요. 계정을 처음 만들 때 이메일과 비밀번호로 생성되는 바로 그 계정이죠." 김개발 씨는 고개를 끄덕였습니다.

자신이 지금까지 사용하던 것이 바로 루트 계정이었습니다. 그렇다면 루트 사용자는 무엇이 특별할까요?

루트 사용자는 말 그대로 신과 같은 존재입니다. AWS 계정의 모든 리소스에 무제한으로 접근할 수 있습니다.

결제 정보를 변경할 수 있고, 계정 자체를 삭제할 수도 있습니다. 심지어 IAM으로도 제한할 수 없는 몇 가지 작업이 있는데, 이것들은 오직 루트 사용자만 할 수 있습니다.

하지만 큰 힘에는 큰 책임이 따릅니다. 루트 계정이 해킹당하면 어떻게 될까요?

상상만 해도 끔찍합니다. 해커가 모든 리소스를 삭제하고, 비싼 인스턴스를 대량으로 띄워서 수천만 원의 요금 폭탄을 만들 수 있습니다.

실제로 이런 사고가 종종 발생합니다. 개발자가 실수로 루트 계정의 액세스 키를 GitHub에 올렸다가 큰 피해를 입은 사례도 많습니다.

바로 이런 이유로 IAM 사용자가 필요합니다. IAM 사용자는 제한된 권한만 가집니다.

개발자에게는 개발에 필요한 권한만, 디자이너에게는 S3 접근 권한만 부여할 수 있습니다. 만약 이 계정이 해킹당해도 피해 범위가 제한적입니다.

또한 언제든지 해당 사용자를 비활성화하거나 삭제할 수 있습니다. AWS 모범 사례를 살펴봅시다.

첫째, 루트 계정은 초기 설정 이후에는 거의 사용하지 않습니다. 마치 회사 금고 열쇠를 평소에는 사용하지 않고 금고에 보관하는 것처럼요.

둘째, 루트 계정에는 반드시 **MFA(다중 인증)**을 설정합니다. 비밀번호만으로는 부족하니 추가 보안 장치를 달아두는 것입니다.

셋째, 일상적인 모든 작업은 IAM 사용자로 수행합니다. 위의 코드를 한 줄씩 살펴보겠습니다.

STS(Security Token Service) 클라이언트를 생성합니다. STS는 자격증명 관련 서비스입니다.

GetCallerIdentityCommand를 실행하면 현재 사용 중인 자격증명 정보를 확인할 수 있습니다. ARN 문자열에 "root"가 포함되어 있으면 루트 사용자로 접속한 것이므로 경고를 표시합니다.

실제 스타트업 사례를 들어볼까요? 어느 스타트업의 대표가 회사 AWS 계정을 만들었습니다.

처음에는 혼자 개발하니 루트 계정을 썼습니다. 그런데 팀원이 5명으로 늘어나면서 모두가 루트 계정 정보를 공유하게 됐습니다.

어느 날 누군가 실수로 프로덕션 데이터베이스를 삭제했습니다. 하지만 누가 한 건지 알 수 없었습니다.

모두 같은 계정을 쓰고 있었으니까요. 이 회사는 그때부터 IAM을 도입했습니다.

각 팀원에게 개별 IAM 사용자를 만들고, 역할에 맞는 권한만 부여했습니다. 그 뒤로는 비슷한 사고가 일어나지 않았습니다.

하지만 주의할 점이 있습니다. IAM 사용자라고 해서 무조건 안전한 것은 아닙니다.

IAM 사용자에게 Administrator 권한을 주면 사실상 루트 사용자와 다를 바 없습니다. 따라서 각 사용자에게 정말 필요한 최소한의 권한만 부여해야 합니다.

또 하나 명심할 점은 액세스 키 관리입니다. 프로그래밍 방식으로 AWS를 사용하려면 액세스 키가 필요합니다.

이 키는 비밀번호와 같으므로 절대 코드에 하드코딩하거나 GitHub에 올려서는 안 됩니다. 환경 변수나 AWS Secrets Manager를 사용해서 안전하게 관리해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 심각한 표정이 됐습니다.

"제가 지금까지 얼마나 위험하게 작업했는지 이제야 알겠어요!" 루트 사용자와 IAM 사용자의 차이를 이해하면 AWS 계정을 훨씬 안전하게 운영할 수 있습니다. 여러분도 오늘부터 루트 계정은 금고에 넣어두고 IAM 사용자로 작업하세요.

실전 팁

💡 - 루트 계정 이메일은 개인 이메일보다 팀 이메일을 사용하세요

루트 계정에 MFA를 설정하지 않았다면 지금 당장 설정하세요
IAM 사용자도 MFA를 설정하면 더욱 안전합니다

3. IAM 사용자 생성

김개발 씨가 결심했습니다. "좋아, 지금부터 제대로 된 IAM 사용자를 만들어보겠습니다!" 하지만 AWS 콘솔을 열어보니 메뉴가 너무 많아서 어디서부터 시작해야 할지 막막했습니다.

박시니어 씨가 옆에서 단계별로 알려주기 시작했습니다.

IAM 사용자 생성은 새로운 팀원에게 AWS 접근 권한을 부여하는 첫 단계입니다. 사용자 이름을 정하고, 접근 방식을 선택하고, 권한을 부여하는 과정을 거칩니다.

마치 회사에 신입사원이 입사하면 출입증을 만들고 필요한 시스템 계정을 발급하는 것과 같습니다. 올바른 절차로 사용자를 생성하면 보안과 관리 효율을 모두 잡을 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 IAM 사용자 생성하기
const { IAMClient, CreateUserCommand, CreateAccessKeyCommand } = require("@aws-sdk/client-iam");

async function createIAMUser(username) {
  const client = new IAMClient({ region: "ap-northeast-2" });

  try {
    // 1. IAM 사용자 생성
    const createUserCommand = new CreateUserCommand({
      UserName: username,
      Tags: [
        { Key: "Team", Value: "Development" },
        { Key: "Environment", Value: "Production" }
      ]
    });

    const userResponse = await client.send(createUserCommand);
    console.log("✓ 사용자 생성 완료:", userResponse.User.UserName);
    console.log("사용자 ARN:", userResponse.User.Arn);

    // 2. 프로그래밍 방식 액세스를 위한 액세스 키 생성
    const createKeyCommand = new CreateAccessKeyCommand({
      UserName: username
    });

    const keyResponse = await client.send(createKeyCommand);
    console.log("\n⚠️ 중요: 아래 정보는 다시 볼 수 없습니다!");
    console.log("액세스 키 ID:", keyResponse.AccessKey.AccessKeyId);
    console.log("시크릿 액세스 키:", keyResponse.AccessKey.SecretAccessKey);

    return userResponse.User;
  } catch (error) {
    console.error("사용자 생성 실패:", error.message);
    throw error;
  }
}

// 사용 예제
createIAMUser("kim.developer");

김개발 씨는 AWS 콘솔의 IAM 서비스 페이지를 열었습니다. 왼쪽 메뉴에 "사용자"라는 항목이 보였습니다.

클릭하니 현재는 사용자가 하나도 없다고 나왔습니다. 당연합니다.

지금까지 루트 계정만 사용했으니까요. "자, 여기서 '사용자 추가' 버튼을 클릭하세요." 박시니어 씨가 설명을 시작했습니다.

그렇다면 IAM 사용자 생성 과정은 어떻게 될까요? 쉽게 비유하자면, IAM 사용자 생성은 마치 은행에서 새 계좌를 만드는 것과 같습니다.

먼저 계좌 이름을 정하고, 통장을 받을지 카드를 받을지 선택하고, 어떤 서비스를 이용할지 설정합니다. IAM 사용자도 이름을 정하고, 접근 방식을 선택하고, 권한을 부여하는 과정을 거칩니다.

첫 번째 단계는 사용자 이름 정하기입니다. 사용자 이름은 AWS 계정 내에서 고유해야 합니다.

보통 이메일 형식이나 "이름.직책" 형식을 많이 사용합니다. 예를 들어 "kim.developer"나 "park.designer" 같은 식입니다.

명확한 네이밍 규칙을 정해두면 나중에 관리하기 편합니다. 두 번째 단계는 접근 방식 선택입니다.

접근 방식에는 두 가지가 있습니다. 하나는 콘솔 액세스입니다.

이것은 웹 브라우저로 AWS Management Console에 로그인할 수 있게 해줍니다. 비밀번호를 설정하면 됩니다.

다른 하나는 프로그래밍 방식 액세스입니다. 이것은 AWS CLI나 SDK로 AWS를 제어할 수 있게 해줍니다.

액세스 키 ID와 시크릿 액세스 키를 발급받습니다. 어떤 것을 선택해야 할까요?

대부분의 개발자는 두 가지 모두 필요합니다. 콘솔로 설정도 확인하고, 코드로 자동화도 해야 하니까요.

하지만 디자이너처럼 S3에 파일만 올리는 사람이라면 콘솔 액세스만 있어도 충분합니다. 세 번째 단계는 권한 부여입니다.

이것이 가장 중요한 단계입니다. 권한을 주는 방법은 세 가지가 있습니다.

첫째, 기존 그룹에 추가하기. 둘째, 기존 사용자의 권한 복사하기.

셋째, 정책을 직접 연결하기. 초보자라면 첫 번째 방법인 그룹 사용을 추천합니다.

네 번째 단계는 태그 추가입니다. 태그는 선택사항이지만 매우 유용합니다.

팀, 프로젝트, 환경 등을 태그로 지정하면 나중에 비용 분석이나 사용자 관리가 훨씬 쉬워집니다. 예를 들어 "Team=Development", "Project=MobileApp" 같은 식입니다.

마지막 단계는 검토 및 생성입니다. 모든 설정을 확인하고 "사용자 만들기" 버튼을 클릭합니다.

그러면 사용자가 생성되고, 프로그래밍 방식 액세스를 선택했다면 액세스 키 정보가 표시됩니다. 이 정보는 단 한 번만 볼 수 있으므로 반드시 안전한 곳에 저장해야 합니다.

위의 코드를 자세히 살펴보겠습니다. CreateUserCommand로 새 사용자를 생성합니다.

Tags 파라미터로 팀과 환경 정보를 추가했습니다. 사용자가 생성되면 CreateAccessKeyCommand로 액세스 키를 발급받습니다.

이 키는 프로그래밍 방식으로 AWS에 접근할 때 사용됩니다. 실제 스타트업 현장 이야기를 들어볼까요?

어느 스타트업에 새로운 백엔드 개발자가 입사했습니다. CTO는 "kim.backend"라는 이름으로 IAM 사용자를 만들었습니다.

콘솔 액세스와 프로그래밍 액세스 모두 활성화했습니다. 권한은 "Developers" 그룹에 추가하는 것으로 간단히 처리했습니다.

이 그룹에는 이미 개발에 필요한 권한들이 정의되어 있었습니다. 초기 비밀번호는 임시로 생성하고, 첫 로그인 시 변경하도록 설정했습니다.

액세스 키는 Slack DM으로 안전하게 전달했습니다. 새 개발자는 그날 오후부터 바로 작업을 시작할 수 있었습니다.

하지만 주의할 점이 있습니다. 가장 흔한 실수는 사용자를 만들고 바로 AdministratorAccess 권한을 주는 것입니다.

"일단 모든 권한을 주고 나중에 제한하자"는 생각이지만, 나중은 오지 않습니다. 처음부터 필요한 권한만 정확히 부여하는 습관을 들여야 합니다.

또 다른 실수는 액세스 키를 제대로 관리하지 않는 것입니다. 액세스 키를 코드에 하드코딩하거나 팀 채팅방에 평문으로 공유하는 경우가 있습니다.

이것은 집 열쇠를 현관문에 붙여놓는 것과 같습니다. 액세스 키는 반드시 안전한 방법으로 전달하고 저장해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 가이드에 따라 김개발 씨는 자신의 첫 IAM 사용자를 성공적으로 만들었습니다.

"와, 생각보다 간단하네요!" IAM 사용자 생성은 AWS 보안의 첫걸음입니다. 여러분도 오늘 배운 절차대로 팀원들의 IAM 사용자를 만들어보세요.

실전 팁

💡 - 사용자 이름은 회사의 네이밍 규칙을 따라 일관되게 작성하세요

액세스 키는 절대 코드나 버전 관리 시스템에 포함하지 마세요
초기 비밀번호는 복잡하게 생성하고 첫 로그인 시 변경하도록 설정하세요

4. IAM 그룹 활용

김개발 씨가 신이 나서 팀원 5명의 IAM 사용자를 만들었습니다. 그런데 각 사용자마다 일일이 권한을 설정하려니 너무 번거로웠습니다.

"이렇게 하나하나 권한을 줘야 하나요?" 박시니어 씨가 웃으며 말했습니다. "그래서 그룹이 있는 거예요."

IAM 그룹은 비슷한 역할을 하는 사용자들을 묶어서 관리하는 방법입니다. 마치 학교에서 학생들을 반으로 나누는 것처럼, 개발자 그룹, 디자이너 그룹, 운영팀 그룹 등으로 나눌 수 있습니다.

그룹에 권한을 부여하면 그룹에 속한 모든 사용자가 자동으로 그 권한을 갖게 됩니다. 이렇게 하면 권한 관리가 훨씬 쉬워집니다.

다음 코드를 살펴봅시다.

// IAM 그룹 생성 및 사용자 추가
const {
  IAMClient,
  CreateGroupCommand,
  AttachGroupPolicyCommand,
  AddUserToGroupCommand
} = require("@aws-sdk/client-iam");

async function setupDevelopersGroup() {
  const client = new IAMClient({ region: "ap-northeast-2" });

  try {
    // 1. 개발자 그룹 생성
    const createGroupCommand = new CreateGroupCommand({
      GroupName: "Developers",
      Path: "/engineering/"
    });

    const groupResponse = await client.send(createGroupCommand);
    console.log("✓ 그룹 생성:", groupResponse.Group.GroupName);

    // 2. 그룹에 정책 연결 (EC2와 S3 읽기 권한)
    const attachPolicyCommand = new AttachGroupPolicyCommand({
      GroupName: "Developers",
      PolicyArn: "arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess"
    });

    await client.send(attachPolicyCommand);
    console.log("✓ EC2 읽기 권한 부여 완료");

    // 3. 사용자를 그룹에 추가
    const addUserCommand = new AddUserToGroupCommand({
      GroupName: "Developers",
      UserName: "kim.developer"
    });

    await client.send(addUserCommand);
    console.log("✓ kim.developer를 Developers 그룹에 추가");

  } catch (error) {
    console.error("그룹 설정 실패:", error.message);
  }
}

setupDevelopersGroup();

김개발 씨는 화면을 보며 한숨을 쉬었습니다. 팀원이 5명뿐인데도 각자에게 권한을 설정하려니 벌써 머리가 아팠습니다.

각 사용자마다 EC2 접근 권한, S3 접근 권한, CloudWatch 접근 권한을 하나하나 추가해야 했습니다. 만약 팀원이 50명이라면 어떻게 될까요?

"김개발 씨, 그렇게 하면 안 돼요. 그룹을 사용해야죠." 박시니어 씨가 다가왔습니다.

그렇다면 IAM 그룹이란 정확히 무엇일까요? 쉽게 비유하자면, IAM 그룹은 마치 회사의 부서와 같습니다.

회사에는 개발팀, 디자인팀, 마케팅팀이 있습니다. 각 부서마다 필요한 시스템 접근 권한이 다릅니다.

개발팀은 서버에 접근해야 하고, 디자인팀은 디자인 파일 저장소에 접근해야 합니다. IAM 그룹도 이처럼 역할별로 사용자를 묶어서 관리합니다.

그룹이 없던 시절에는 어땠을까요? 모든 사용자의 권한을 개별적으로 관리해야 했습니다.

새로운 서비스 접근 권한을 추가하려면 100명의 개발자 계정에 일일이 권한을 추가해야 했습니다. 누군가 퇴사하면 그 사람의 모든 권한을 일일이 제거해야 했습니다.

실수로 권한을 빼먹거나 잘못 주는 경우도 많았습니다. 바로 이런 문제를 해결하기 위해 그룹이 등장했습니다.

그룹을 사용하면 권한 관리가 극적으로 간단해집니다. "Developers" 그룹에 개발에 필요한 모든 권한을 한 번만 설정해두면, 새로운 개발자를 뽑을 때마다 그냥 이 그룹에 추가하기만 하면 됩니다.

권한을 수정할 때도 그룹 권한만 바꾸면 그룹에 속한 모든 사용자에게 자동으로 적용됩니다. 전형적인 그룹 구조를 살펴볼까요?

대부분의 회사는 이런 식으로 그룹을 만듭니다. Developers 그룹은 개발 환경의 EC2, RDS, S3 등에 접근할 수 있습니다.

Operators 그룹은 프로덕션 환경을 모니터링하고 문제를 해결할 수 있습니다. Admins 그룹은 거의 모든 작업을 할 수 있지만, 결제 정보 변경 같은 민감한 작업은 제외됩니다.

Auditors 그룹은 읽기 전용으로 모든 것을 조회할 수 있습니다. 위의 코드를 단계별로 살펴보겠습니다.

먼저 CreateGroupCommand로 "Developers"라는 그룹을 만듭니다. Path 파라미터는 그룹을 논리적으로 구조화하는 데 사용됩니다.

다음으로 AttachGroupPolicyCommand로 AWS 관리형 정책을 그룹에 연결합니다. 마지막으로 AddUserToGroupCommand로 사용자를 그룹에 추가합니다.

실제 스타트업 사례를 들어볼까요? 어느 스타트업이 처음에는 팀원이 3명이었습니다.

그래서 그룹 없이 개별 사용자에게 권한을 줬습니다. 하지만 6개월 만에 팀원이 20명으로 늘었습니다.

CTO는 권한 관리에 하루에 1시간씩 쓰게 됐습니다. 그래서 그룹 시스템을 도입했습니다.

Developers, QA, DevOps, DataAnalysts 네 개의 그룹을 만들었습니다. 각 그룹에 필요한 권한을 정의했습니다.

그 후로는 신규 입사자가 와도 5분 안에 계정 설정이 끝났습니다. 해당 그룹에 추가하기만 하면 됐으니까요.

한 사용자는 여러 그룹에 속할 수 있습니다. 예를 들어 개발팀장은 Developers 그룹과 TeamLeaders 그룹 두 곳에 모두 속할 수 있습니다.

그러면 두 그룹의 권한을 모두 갖게 됩니다. 하지만 너무 많은 그룹에 속하면 권한이 복잡해지므로 적절한 수준을 유지해야 합니다.

하지만 주의할 점도 있습니다. 그룹에 너무 많은 권한을 주면 안 됩니다.

"일단 다 주고 보자"는 식으로 접근하면 그룹을 만드는 의미가 없습니다. 각 그룹이 정말 필요한 최소한의 권한만 가지도록 세밀하게 설계해야 합니다.

또 다른 실수는 그룹 이름을 대충 짓는 것입니다. "Team1", "Group2" 같은 이름은 나중에 무슨 그룹인지 알 수 없습니다.

"WebDevelopers", "MobileTeam", "DataEngineers" 같은 명확한 이름을 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언에 따라 김개발 씨는 그룹을 만들고 팀원들을 적절한 그룹에 추가했습니다. "와, 정말 편하네요!

이제 신규 입사자가 와도 걱정 없겠어요." IAM 그룹을 제대로 활용하면 수백 명의 사용자도 쉽게 관리할 수 있습니다. 여러분도 오늘부터 역할별로 그룹을 만들어 체계적으로 권한을 관리해보세요.

실전 팁

💡 - 그룹은 역할 기반으로 만들고, 프로젝트별 권한은 태그로 관리하세요

주기적으로 그룹 권한을 검토하고 불필요한 권한은 제거하세요
한 사용자가 4개 이상의 그룹에 속한다면 권한 구조를 재설계할 때입니다

5. IAM 정책 기초

김개발 씨가 그룹에 권한을 추가하려는데 정책이라는 단어가 계속 나왔습니다. "AWS 관리형 정책", "고객 관리형 정책", "인라인 정책"...

도대체 이게 뭘까요? 박시니어 씨가 설명을 시작했습니다.

"정책은 IAM의 핵심이에요. 이것만 이해하면 IAM의 80%를 안 거예요."

"Team A의 S3 폴더 접근 권한" }); const response = await client.send(command); console.log("✓ 정책 생성 완료:", response.Policy.PolicyName); console.log("정책 ARN:", response.Policy.Arn); } catch (error) { console.error("정책 생성 실패:", error.message); } } createCustomPolicy();

다음 코드를 살펴봅시다.

// 커스텀 IAM 정책 생성하기
const { IAMClient, CreatePolicyCommand } = require("@aws-sdk/client-iam");

async function createCustomPolicy() {
  const client = new IAMClient({ region: "ap-northeast-2" });

  // S3 버킷의 특정 폴더에만 접근 가능한 정책
  const policyDocument = {
    Version: "2012-10-17",
    Statement: [
      {
        Effect: "Allow",
        Action: [
          "s3:ListBucket"
        ],
        Resource: "arn:aws:s3:::my-company-bucket",
        Condition: {
          StringLike: {
            "s3:prefix": ["team-a/*"]
          }
        }
      },
      {
        Effect: "Allow",
        Action: [
          "s3:GetObject",
          "s3:PutObject",
          "s3:DeleteObject"
        ],
        Resource: "arn:aws:s3:::my-company-bucket/team-a/*"
      }
    ]
  };

  try {
    const command = new CreatePolicyCommand({
      PolicyName: "TeamAFolderAccess",
      PolicyDocument: JSON.stringify(policyDocument),

김개발 씨는 AWS 콘솔에서 정책 목록을 보고 깜짝 놀랐습니다. 정책이 수백 개나 되었습니다.

AdministratorAccess, AmazonS3ReadOnlyAccess, AmazonEC2FullAccess... 도대체 이 많은 정책을 다 알아야 하는 걸까요?

"전부 외울 필요는 없어요. 원리만 이해하면 됩니다." 박시니어 씨가 안심시켰습니다.

그렇다면 IAM 정책이란 정확히 무엇일까요? 쉽게 비유하자면, 정책은 마치 건물 출입 규정과 같습니다.

"3층 회의실은 부장급 이상만 출입 가능", "지하 주차장은 전 직원 출입 가능" 같은 규칙들입니다. IAM 정책도 이처럼 "EC2는 개발팀만 접근 가능", "S3는 모든 직원 읽기 가능" 같은 규칙을 정의합니다.

정책의 기본 구조를 살펴봅시다. 모든 IAM 정책은 JSON 형식으로 작성됩니다.

크게 네 가지 요소로 구성됩니다. Effect는 허용(Allow)인지 거부(Deny)인지를 나타냅니다.

Action은 어떤 작업을 할 수 있는지를 나타냅니다. Resource는 어떤 리소스에 적용되는지를 나타냅니다.

Condition은 추가 조건을 명시합니다. 정책의 종류는 크게 세 가지입니다.

첫째, AWS 관리형 정책입니다. AWS가 미리 만들어놓은 정책입니다.

일반적인 사용 사례에 맞춰 설계되어 있어서 바로 사용하기 편합니다. 예를 들어 AmazonS3ReadOnlyAccess는 모든 S3 버킷을 읽을 수 있는 권한을 줍니다.

둘째, 고객 관리형 정책입니다. 여러분이 직접 만드는 정책입니다.

회사의 특수한 요구사항에 맞춰 세밀하게 조정할 수 있습니다. 여러 사용자나 그룹에 재사용할 수 있다는 장점이 있습니다.

셋째, 인라인 정책입니다. 특정 사용자, 그룹, 역할에만 직접 붙이는 정책입니다.

일회성 권한이나 매우 특수한 경우에만 사용합니다. 위의 코드를 자세히 분석해봅시다.

이 정책은 S3 버킷의 특정 폴더에만 접근을 허용합니다. 첫 번째 Statement는 버킷 목록 조회를 허용하되, "team-a/" 접두사가 붙은 객체만 볼 수 있게 제한합니다.

두 번째 Statement는 "team-a/" 폴더 안의 파일을 읽고, 쓰고, 삭제할 수 있게 허용합니다. 실제 스타트업에서 있었던 일입니다.

어느 스타트업에서 모든 개발자에게 AdministratorAccess 권한을 줬습니다. 편하니까요.

그런데 어느 날 인턴 개발자가 실수로 프로덕션 데이터베이스를 삭제했습니다. 다행히 백업이 있어서 복구했지만, 서비스가 2시간 동안 중단됐습니다.

이 사고 이후 회사는 정책을 세밀하게 재설계했습니다. 주니어 개발자는 개발 환경만 접근 가능하게, 시니어 개발자는 프로덕션 읽기 권한까지, 데브옵스 팀만 프로덕션 쓰기 권한을 갖도록 했습니다.

그 뒤로 비슷한 사고는 일어나지 않았습니다. 정책을 작성할 때 주의할 점이 있습니다.

명시적 거부는 모든 허용보다 우선합니다. 예를 들어 한 정책에서 S3 접근을 Allow 했더라도, 다른 정책에서 Deny 했다면 최종적으로는 거부됩니다.

이것을 이해하지 못하면 "분명히 권한을 줬는데 왜 안 되지?"라는 상황에 빠집니다. 또 다른 중요한 개념은 최소 권한 원칙입니다.

"일단 모든 권한을 주고 필요 없는 것만 빼자"가 아니라 "필요한 권한만 정확히 주자"는 마인드로 접근해야 합니다. 처음에는 번거롭지만, 장기적으로 보안 사고를 예방하는 가장 확실한 방법입니다.

정책 테스트는 어떻게 할까요? AWS는 IAM Policy Simulator라는 도구를 제공합니다.

정책을 실제로 적용하기 전에 시뮬레이션할 수 있습니다. "이 사용자가 이 작업을 할 수 있을까?" 같은 질문에 답해줍니다.

정책을 만들었다면 반드시 시뮬레이터로 테스트해보세요. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 정책 문서를 다시 보니 이제 이해가 됐습니다. "아, Effect, Action, Resource 이 세 가지만 기억하면 되는구나!" IAM 정책을 이해하면 AWS 리소스를 정교하게 제어할 수 있습니다.

여러분도 오늘 배운 내용을 바탕으로 회사에 맞는 커스텀 정책을 작성해보세요.

실전 팁

💡 - 처음에는 AWS 관리형 정책으로 시작하고 점진적으로 커스터마이징하세요

정책은 버전 관리 시스템에 저장해서 변경 이력을 추적하세요
IAM Policy Simulator로 정책을 반드시 테스트한 후 적용하세요

6. 역할(Role) 개념

김개발 씨가 EC2 인스턴스에서 S3에 접근해야 하는 상황이 생겼습니다. "EC2 안에 액세스 키를 넣어야 하나?" 고민하던 중 박시니어 씨가 말했습니다.

"절대 그러면 안 돼요. 역할을 사용해야죠."

"EC2 인스턴스가 S3에 접근할 수 있는 역할" }); const roleResponse = await client.send(createRoleCommand); console.log("✓ 역할 생성:", roleResponse.Role.RoleName); console.log("역할 ARN:", roleResponse.Role.Arn); // 2. S3 접근 정책 연결 const attachPolicyCommand = new AttachRolePolicyCommand({ RoleName: "EC2-S3-Access-Role", PolicyArn: "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" }); await client.send(attachPolicyCommand); console.log("✓ S3 읽기 권한 연결 완료"); console.log("\n이제 EC2 인스턴스를 생성할 때 이 역할을 지정하세요."); } catch (error) { console.error("역할 생성 실패:", error.message); } } createEC2Role();

다음 코드를 살펴봅시다.

// EC2 인스턴스용 IAM 역할 생성
const { IAMClient, CreateRoleCommand, AttachRolePolicyCommand } = require("@aws-sdk/client-iam");

async function createEC2Role() {
  const client = new IAMClient({ region: "ap-northeast-2" });

  // 신뢰 정책: EC2가 이 역할을 맡을 수 있도록 허용
  const trustPolicy = {
    Version: "2012-10-17",
    Statement: [
      {
        Effect: "Allow",
        Principal: {
          Service: "ec2.amazonaws.com"
        },
        Action: "sts:AssumeRole"
      }
    ]
  };

  try {
    // 1. 역할 생성
    const createRoleCommand = new CreateRoleCommand({
      RoleName: "EC2-S3-Access-Role",
      AssumeRolePolicyDocument: JSON.stringify(trustPolicy),

김개발 씨는 난관에 부딪혔습니다. EC2 인스턴스에서 실행되는 애플리케이션이 S3 버킷의 파일을 읽어야 합니다.

가장 쉬운 방법은 액세스 키를 EC2의 환경 변수에 넣는 것입니다. 하지만 박시니어 씨가 강하게 말렸습니다.

"그렇게 하면 보안 사고 나요. 누군가 EC2에 접속하면 액세스 키를 훔칠 수 있어요." 그렇다면 어떻게 해야 할까요?

그렇다면 IAM 역할이란 정확히 무엇일까요? 쉽게 비유하자면, 역할은 마치 대리 운전 기사에게 주는 임시 권한과 같습니다.

여러분이 회식 후 대리 기사를 불렀습니다. 기사는 여러분의 차 키를 받아 목적지까지 운전합니다.

하지만 기사는 여러분의 차를 영구적으로 소유하는 것이 아닙니다. 목적지에 도착하면 권한이 끝납니다.

IAM 역할도 이처럼 필요한 순간에만 임시로 권한을 부여합니다. 역할과 사용자의 차이점은 무엇일까요?

사용자는 장기 자격증명입니다. 액세스 키가 있고, 비밀번호가 있습니다.

한 번 발급하면 명시적으로 삭제하기 전까지 계속 유효합니다. 반면 역할은 단기 자격증명입니다.

역할을 맡으면 임시 토큰을 받습니다. 이 토큰은 보통 1시간 정도 유효하고, 시간이 지나면 자동으로 만료됩니다.

역할이 필요한 대표적인 상황을 살펴봅시다. 첫째, EC2 인스턴스가 다른 AWS 서비스에 접근할 때입니다.

EC2에서 S3 파일을 읽거나 DynamoDB에 쓸 때 역할을 사용합니다. 둘째, 람다 함수가 실행될 때입니다.

람다는 항상 역할을 필요로 합니다. 셋째, 다른 AWS 계정에서 접근할 때입니다.

회사의 개발 계정에서 프로덕션 계정의 리소스에 접근해야 할 때 크로스 계정 역할을 사용합니다. 역할의 핵심 개념은 AssumeRole입니다.

"역할을 맡는다"는 의미입니다. EC2 인스턴스가 역할을 맡으면, AWS는 그 인스턴스에게 임시 자격증명을 발급합니다.

인스턴스는 이 자격증명으로 S3나 다른 서비스에 접근합니다. 자격증명이 만료되기 전에 AWS SDK가 자동으로 새로운 자격증명을 받아옵니다.

위의 코드를 단계별로 분석해봅시다. 먼저 신뢰 정책(Trust Policy)을 정의합니다.

이것은 "누가 이 역할을 맡을 수 있는가"를 명시합니다. 여기서는 EC2 서비스가 이 역할을 맡을 수 있도록 허용했습니다.

다음으로 CreateRoleCommand로 역할을 생성합니다. 마지막으로 AttachRolePolicyCommand로 S3 읽기 권한을 역할에 연결합니다.

실제 현업 사례를 들어볼까요? 한 스타트업에서 마이크로서비스 아키텍처를 구축했습니다.

각 서비스는 EC2 인스턴스에서 실행됩니다. 주문 서비스는 S3에서 상품 이미지를 읽어야 하고, 결제 서비스는 DynamoDB에 거래 내역을 저장해야 합니다.

처음에는 각 인스턴스에 액세스 키를 넣었습니다. 하지만 보안 감사에서 지적을 받았습니다.

그래서 서비스별로 역할을 만들었습니다. OrderServiceRole, PaymentServiceRole 같은 식입니다.

각 역할에는 해당 서비스에 꼭 필요한 권한만 부여했습니다. 인스턴스를 시작할 때 적절한 역할을 지정하기만 하면 끝입니다.

이렇게 바꾼 후 장점이 많았습니다. 첫째, 액세스 키가 코드나 설정 파일에 없으니 누출 위험이 사라졌습니다.

둘째, 역할 권한만 수정하면 모든 인스턴스에 즉시 적용됩니다. 셋째, CloudTrail 로그에서 어떤 역할이 무슨 작업을 했는지 명확히 추적할 수 있습니다.

하지만 주의할 점도 있습니다. 역할에도 과도한 권한을 주면 안 됩니다.

어떤 개발자들은 "귀찮다"는 이유로 모든 역할에 AdministratorAccess를 줍니다. 이것은 역할을 사용하는 의미를 퇴색시킵니다.

각 역할은 정말 필요한 최소한의 권한만 가져야 합니다. 또 다른 실수는 역할 신뢰 정책을 너무 느슨하게 설정하는 것입니다.

예를 들어 Principal을 "*"로 설정하면 누구나 이 역할을 맡을 수 있습니다. 반드시 특정 서비스나 특정 계정만 역할을 맡을 수 있도록 제한해야 합니다.

크로스 계정 역할도 강력한 기능입니다. 개발 계정에서 프로덕션 계정의 리소스를 안전하게 관리할 수 있습니다.

예를 들어 개발자는 자신의 개발 계정에 로그인합니다. 필요할 때만 프로덕션 계정의 읽기 전용 역할을 맡아서 로그를 확인합니다.

역할 사용이 끝나면 다시 개발 계정으로 돌아옵니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 가이드에 따라 김개발 씨는 EC2용 역할을 만들고 인스턴스에 지정했습니다. 코드에서 액세스 키를 완전히 제거했습니다.

"와, 이제 보안 걱정 없이 잘 수 있겠어요!" IAM 역할을 제대로 활용하면 액세스 키 없이도 안전하게 AWS 리소스에 접근할 수 있습니다. 여러분도 오늘부터 EC2, 람다 등에 역할을 적극 활용해보세요.

실전 팁

💡 - EC2 인스턴스에는 항상 역할을 지정하고 액세스 키는 절대 사용하지 마세요

역할 이름은 용도를 명확히 나타내도록 작성하세요 (예: EC2-S3-ReadOnly-Role)
임시 자격증명 갱신은 AWS SDK가 자동으로 처리하므로 걱정하지 않아도 됩니다

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

#AWS#IAM#보안#권한관리#클라우드

AWS IAM 사용자와 권한 완벽 가이드

# AWS IAM 사용자와 권한 완벽 가이드 AWS 계정을 안전하게 관리하는 IAM의 모든 것을 초급 개발자 눈높이에 맞춰 설명합니다. 루트 사용자의 위험성부터 IAM 사용자 생성, 그룹 관리, 정책 설정, 역할 활용까지 실무에서 바로 쓸 수 있는 내용을 담았습니다. --- ## 목차 1. [IAM이란_무엇인가](#iam이란-무엇인가) 2. [루트_사용자_vs_IAM_사용자](#루트-사용자-vs-iam-사용자) 3. [IAM_사용자_생성](#iam-사용자-생성) 4. [IAM_그룹_활용](#iam-그룹-활용) 5. [IAM_정책_기초](#iam-정책-기초) 6. [역할(Role)_개념](#역할(role)-개념) --- ## 1. IAM이란_무엇인가 어느 날 김개발 씨가 AWS 계정을 만들고 처음으로 EC2 인스턴스를 띄워봤습니다. 그런데 선배 박시니어 씨가 심각한 표정으로 말했습니다. "지금 루트 계정으로 작업하고 있어요? 그거 정말 위험한 행동이에요." **IAM(Identity and Access Management)**은 AWS 리소스에 대한 접근을 안전하게 제어하는 서비스입니다. 마치 회사 출입증 시스템처럼, 누가 어떤 리소스에 접근할 수 있는지를 세밀하게 관리합니다. IAM을 제대로 이해하면 보안 사고를 예방하고 팀원들에게 적절한 권한을 부여할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK를 사용한 IAM 사용자 확인 예제 const { IAMClient, GetUserCommand } = require("@aws-sdk/client-iam"); // IAM 클라이언트 생성 const client = new IAMClient({ region: "ap-northeast-2" }); async function getCurrentUser() { try { // 현재 인증된 사용자 정보 조회 const command = new GetUserCommand({}); const response = await client.send(command); console.log("현재 사용자:", response.User.UserName); console.log("사용자 ARN:", response.User.Arn); console.log("생성일:", response.User.CreateDate); } catch (error) { console.error("사용자 정보 조회 실패:", error.message); } } getCurrentUser(); ``` 김개발 씨는 입사 1주일 차 신입 개발자입니다. 처음으로 AWS 계정을 만들고 설레는 마음으로 여러 서비스를 테스트하고 있었습니다. EC2도 띄워보고, S3 버킷도 만들어봤습니다. 그런데 옆자리 박시니어 씨가 화면을 보더니 깜짝 놀랐습니다. "김개발 씨, 지금 루트 계정으로 작업하고 있어요? 그건 정말 위험해요!" 김개발 씨는 의아했습니다. 내 계정인데 뭐가 문제지? 하지만 박시니어 씨의 진지한 표정을 보니 심각한 문제인 것 같습니다. 그렇다면 IAM이란 정확히 무엇일까요? 쉽게 비유하자면, IAM은 마치 회사의 출입 관리 시스템과 같습니다. 회사에는 사장님부터 인턴까지 다양한 직급의 사람들이 있습니다. 사장님은 금고실까지 들어갈 수 있지만, 인턴은 자기 팀 사무실만 들어갈 수 있습니다. 이처럼 IAM도 AWS 계정에서 누가 어떤 리소스에 접근할 수 있는지를 세밀하게 관리합니다. IAM이 없던 초기 클라우드 시절에는 어땠을까요? 모든 팀원이 하나의 루트 계정 정보를 공유해야 했습니다. 이것은 마치 회사의 모든 직원이 사장님 출입증을 복사해서 쓰는 것과 같습니다. 누가 무엇을 했는지 추적하기도 어렵고, 퇴사한 직원이 생기면 비밀번호를 바꿔야 하는 번거로움이 있었습니다. 더 큰 문제는 실수로 중요한 리소스를 삭제해도 누가 한 것인지 알 수 없다는 점이었습니다. 바로 이런 문제를 해결하기 위해 IAM이 등장했습니다. IAM을 사용하면 각 팀원마다 개별 계정을 만들 수 있습니다. 또한 각 계정에 필요한 권한만 정확히 부여할 수 있습니다. 무엇보다 모든 작업 내역이 기록되어 누가 무엇을 했는지 추적할 수 있다는 큰 이점이 있습니다. IAM의 핵심 구성 요소는 크게 네 가지입니다. 첫째, **사용자(User)**입니다. 실제 사람이나 애플리케이션에 대응되는 개별 계정입니다. 둘째, **그룹(Group)**입니다. 비슷한 역할을 하는 사용자들을 묶어서 관리합니다. 셋째, **정책(Policy)**입니다. 무엇을 할 수 있고 없는지를 정의하는 규칙입니다. 넷째, **역할(Role)**입니다. 임시로 권한을 부여받을 수 있는 자격증명입니다. 위의 코드를 살펴보겠습니다. 먼저 AWS SDK의 IAM 클라이언트를 생성합니다. 이 클라이언트를 통해 IAM 관련 작업을 수행할 수 있습니다. 다음으로 GetUserCommand를 사용해서 현재 인증된 사용자의 정보를 조회합니다. 결과로 사용자 이름, ARN(고유 식별자), 생성일 등을 확인할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 스타트업에서 새로운 개발자가 입사했다고 가정해봅시다. CTO는 IAM을 통해 이 개발자에게 개발 환경의 EC2와 S3에만 접근할 수 있는 계정을 만듭니다. 프로덕션 환경이나 결제 정보에는 접근할 수 없도록 제한합니다. 이렇게 하면 실수로 인한 사고를 예방할 수 있고, 보안도 강화됩니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 "귀찮다"는 이유로 모든 권한을 다 주는 것입니다. 이렇게 하면 IAM을 사용하는 의미가 없어집니다. 따라서 **최소 권한 원칙(Principle of Least Privilege)**을 지켜서, 업무에 꼭 필요한 권한만 부여해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 회사마다 IAM 정책이 중요하다고 하는 거군요!" IAM을 제대로 이해하면 안전하고 체계적인 AWS 환경을 구축할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 자신만의 IAM 전략을 세워보세요. **실전 팁** 💡 - IAM은 무료 서비스입니다. 비용 걱정 없이 마음껏 사용하세요 - 루트 계정은 MFA를 설정하고 금고에 보관하듯 안전하게 관리하세요 - 권한을 줄 때는 항상 최소 권한 원칙을 따르세요 --- ## 2. 루트_사용자_vs_IAM_사용자 김개발 씨가 IAM의 중요성을 깨닫고 박시니어 씨에게 물었습니다. "그럼 루트 계정이랑 IAM 사용자가 정확히 뭐가 다른 건가요?" 박시니어 씨는 커피를 한 모금 마시고 차근차근 설명하기 시작했습니다. **루트 사용자**는 AWS 계정을 처음 만들 때 생성되는 최고 권한자입니다. 반면 **IAM 사용자**는 제한된 권한을 가진 일반 사용자입니다. 마치 회사 사장님과 직원의 차이와 같습니다. 루트 사용자는 모든 것을 할 수 있지만, 그만큼 위험하기 때문에 일상적인 작업에는 IAM 사용자를 사용해야 합니다. 다음 코드를 살펴봅시다. ```javascript // 루트 사용자와 IAM 사용자의 권한 차이 확인 const { STSClient, GetCallerIdentityCommand } = require("@aws-sdk/client-sts"); async function checkCurrentIdentity() { const client = new STSClient({ region: "ap-northeast-2" }); try { // 현재 사용 중인 자격증명 확인 const command = new GetCallerIdentityCommand({}); const response = await client.send(command); console.log("계정 ID:", response.Account); console.log("사용자 ARN:", response.Arn); // ARN으로 루트 사용자인지 확인 if (response.Arn.includes(":root")) { console.warn("⚠️ 경고: 루트 사용자로 접속했습니다!"); console.warn("일상 작업에는 IAM 사용자를 사용하세요."); } else { console.log("✓ IAM 사용자로 안전하게 접속했습니다."); } } catch (error) { console.error("자격증명 확인 실패:", error.message); } } checkCurrentIdentity(); ``` 박시니어 씨는 화이트보드에 그림을 그리기 시작했습니다. 왼쪽에는 왕관을 쓴 사람을, 오른쪽에는 일반 직원을 그렸습니다. "루트 사용자는 AWS 계정의 절대 권한자예요. 계정을 처음 만들 때 이메일과 비밀번호로 생성되는 바로 그 계정이죠." 김개발 씨는 고개를 끄덕였습니다. 자신이 지금까지 사용하던 것이 바로 루트 계정이었습니다. 그렇다면 루트 사용자는 무엇이 특별할까요? 루트 사용자는 말 그대로 신과 같은 존재입니다. AWS 계정의 모든 리소스에 무제한으로 접근할 수 있습니다. 결제 정보를 변경할 수 있고, 계정 자체를 삭제할 수도 있습니다. 심지어 IAM으로도 제한할 수 없는 몇 가지 작업이 있는데, 이것들은 오직 루트 사용자만 할 수 있습니다. 하지만 큰 힘에는 큰 책임이 따릅니다. 루트 계정이 해킹당하면 어떻게 될까요? 상상만 해도 끔찍합니다. 해커가 모든 리소스를 삭제하고, 비싼 인스턴스를 대량으로 띄워서 수천만 원의 요금 폭탄을 만들 수 있습니다. 실제로 이런 사고가 종종 발생합니다. 개발자가 실수로 루트 계정의 액세스 키를 GitHub에 올렸다가 큰 피해를 입은 사례도 많습니다. 바로 이런 이유로 IAM 사용자가 필요합니다. IAM 사용자는 제한된 권한만 가집니다. 개발자에게는 개발에 필요한 권한만, 디자이너에게는 S3 접근 권한만 부여할 수 있습니다. 만약 이 계정이 해킹당해도 피해 범위가 제한적입니다. 또한 언제든지 해당 사용자를 비활성화하거나 삭제할 수 있습니다. AWS 모범 사례를 살펴봅시다. 첫째, 루트 계정은 초기 설정 이후에는 거의 사용하지 않습니다. 마치 회사 금고 열쇠를 평소에는 사용하지 않고 금고에 보관하는 것처럼요. 둘째, 루트 계정에는 반드시 **MFA(다중 인증)**을 설정합니다. 비밀번호만으로는 부족하니 추가 보안 장치를 달아두는 것입니다. 셋째, 일상적인 모든 작업은 IAM 사용자로 수행합니다. 위의 코드를 한 줄씩 살펴보겠습니다. STS(Security Token Service) 클라이언트를 생성합니다. STS는 자격증명 관련 서비스입니다. GetCallerIdentityCommand를 실행하면 현재 사용 중인 자격증명 정보를 확인할 수 있습니다. ARN 문자열에 "root"가 포함되어 있으면 루트 사용자로 접속한 것이므로 경고를 표시합니다. 실제 스타트업 사례를 들어볼까요? 어느 스타트업의 대표가 회사 AWS 계정을 만들었습니다. 처음에는 혼자 개발하니 루트 계정을 썼습니다. 그런데 팀원이 5명으로 늘어나면서 모두가 루트 계정 정보를 공유하게 됐습니다. 어느 날 누군가 실수로 프로덕션 데이터베이스를 삭제했습니다. 하지만 누가 한 건지 알 수 없었습니다. 모두 같은 계정을 쓰고 있었으니까요. 이 회사는 그때부터 IAM을 도입했습니다. 각 팀원에게 개별 IAM 사용자를 만들고, 역할에 맞는 권한만 부여했습니다. 그 뒤로는 비슷한 사고가 일어나지 않았습니다. 하지만 주의할 점이 있습니다. IAM 사용자라고 해서 무조건 안전한 것은 아닙니다. IAM 사용자에게 Administrator 권한을 주면 사실상 루트 사용자와 다를 바 없습니다. 따라서 각 사용자에게 정말 필요한 최소한의 권한만 부여해야 합니다. 또 하나 명심할 점은 액세스 키 관리입니다. 프로그래밍 방식으로 AWS를 사용하려면 액세스 키가 필요합니다. 이 키는 비밀번호와 같으므로 절대 코드에 하드코딩하거나 GitHub에 올려서는 안 됩니다. 환경 변수나 AWS Secrets Manager를 사용해서 안전하게 관리해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 심각한 표정이 됐습니다. "제가 지금까지 얼마나 위험하게 작업했는지 이제야 알겠어요!" 루트 사용자와 IAM 사용자의 차이를 이해하면 AWS 계정을 훨씬 안전하게 운영할 수 있습니다. 여러분도 오늘부터 루트 계정은 금고에 넣어두고 IAM 사용자로 작업하세요. **실전 팁** 💡 - 루트 계정 이메일은 개인 이메일보다 팀 이메일을 사용하세요 - 루트 계정에 MFA를 설정하지 않았다면 지금 당장 설정하세요 - IAM 사용자도 MFA를 설정하면 더욱 안전합니다 --- ## 3. IAM_사용자_생성 김개발 씨가 결심했습니다. "좋아, 지금부터 제대로 된 IAM 사용자를 만들어보겠습니다!" 하지만 AWS 콘솔을 열어보니 메뉴가 너무 많아서 어디서부터 시작해야 할지 막막했습니다. 박시니어 씨가 옆에서 단계별로 알려주기 시작했습니다. **IAM 사용자 생성**은 새로운 팀원에게 AWS 접근 권한을 부여하는 첫 단계입니다. 사용자 이름을 정하고, 접근 방식을 선택하고, 권한을 부여하는 과정을 거칩니다. 마치 회사에 신입사원이 입사하면 출입증을 만들고 필요한 시스템 계정을 발급하는 것과 같습니다. 올바른 절차로 사용자를 생성하면 보안과 관리 효율을 모두 잡을 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 IAM 사용자 생성하기 const { IAMClient, CreateUserCommand, CreateAccessKeyCommand } = require("@aws-sdk/client-iam"); async function createIAMUser(username) { const client = new IAMClient({ region: "ap-northeast-2" }); try { // 1. IAM 사용자 생성 const createUserCommand = new CreateUserCommand({ UserName: username, Tags: [ { Key: "Team", Value: "Development" }, { Key: "Environment", Value: "Production" } ] }); const userResponse = await client.send(createUserCommand); console.log("✓ 사용자 생성 완료:", userResponse.User.UserName); console.log("사용자 ARN:", userResponse.User.Arn); // 2. 프로그래밍 방식 액세스를 위한 액세스 키 생성 const createKeyCommand = new CreateAccessKeyCommand({ UserName: username }); const keyResponse = await client.send(createKeyCommand); console.log("\n⚠️ 중요: 아래 정보는 다시 볼 수 없습니다!"); console.log("액세스 키 ID:", keyResponse.AccessKey.AccessKeyId); console.log("시크릿 액세스 키:", keyResponse.AccessKey.SecretAccessKey); return userResponse.User; } catch (error) { console.error("사용자 생성 실패:", error.message); throw error; } } // 사용 예제 createIAMUser("kim.developer"); ``` 김개발 씨는 AWS 콘솔의 IAM 서비스 페이지를 열었습니다. 왼쪽 메뉴에 "사용자"라는 항목이 보였습니다. 클릭하니 현재는 사용자가 하나도 없다고 나왔습니다. 당연합니다. 지금까지 루트 계정만 사용했으니까요. "자, 여기서 '사용자 추가' 버튼을 클릭하세요." 박시니어 씨가 설명을 시작했습니다. 그렇다면 IAM 사용자 생성 과정은 어떻게 될까요? 쉽게 비유하자면, IAM 사용자 생성은 마치 은행에서 새 계좌를 만드는 것과 같습니다. 먼저 계좌 이름을 정하고, 통장을 받을지 카드를 받을지 선택하고, 어떤 서비스를 이용할지 설정합니다. IAM 사용자도 이름을 정하고, 접근 방식을 선택하고, 권한을 부여하는 과정을 거칩니다. 첫 번째 단계는 사용자 이름 정하기입니다. 사용자 이름은 AWS 계정 내에서 고유해야 합니다. 보통 이메일 형식이나 "이름.직책" 형식을 많이 사용합니다. 예를 들어 "kim.developer"나 "park.designer" 같은 식입니다. 명확한 네이밍 규칙을 정해두면 나중에 관리하기 편합니다. 두 번째 단계는 접근 방식 선택입니다. 접근 방식에는 두 가지가 있습니다. 하나는 **콘솔 액세스**입니다. 이것은 웹 브라우저로 AWS Management Console에 로그인할 수 있게 해줍니다. 비밀번호를 설정하면 됩니다. 다른 하나는 **프로그래밍 방식 액세스**입니다. 이것은 AWS CLI나 SDK로 AWS를 제어할 수 있게 해줍니다. 액세스 키 ID와 시크릿 액세스 키를 발급받습니다. 어떤 것을 선택해야 할까요? 대부분의 개발자는 두 가지 모두 필요합니다. 콘솔로 설정도 확인하고, 코드로 자동화도 해야 하니까요. 하지만 디자이너처럼 S3에 파일만 올리는 사람이라면 콘솔 액세스만 있어도 충분합니다. 세 번째 단계는 권한 부여입니다. 이것이 가장 중요한 단계입니다. 권한을 주는 방법은 세 가지가 있습니다. 첫째, 기존 그룹에 추가하기. 둘째, 기존 사용자의 권한 복사하기. 셋째, 정책을 직접 연결하기. 초보자라면 첫 번째 방법인 그룹 사용을 추천합니다. 네 번째 단계는 태그 추가입니다. 태그는 선택사항이지만 매우 유용합니다. 팀, 프로젝트, 환경 등을 태그로 지정하면 나중에 비용 분석이나 사용자 관리가 훨씬 쉬워집니다. 예를 들어 "Team=Development", "Project=MobileApp" 같은 식입니다. 마지막 단계는 검토 및 생성입니다. 모든 설정을 확인하고 "사용자 만들기" 버튼을 클릭합니다. 그러면 사용자가 생성되고, 프로그래밍 방식 액세스를 선택했다면 액세스 키 정보가 표시됩니다. 이 정보는 단 한 번만 볼 수 있으므로 반드시 안전한 곳에 저장해야 합니다. 위의 코드를 자세히 살펴보겠습니다. CreateUserCommand로 새 사용자를 생성합니다. Tags 파라미터로 팀과 환경 정보를 추가했습니다. 사용자가 생성되면 CreateAccessKeyCommand로 액세스 키를 발급받습니다. 이 키는 프로그래밍 방식으로 AWS에 접근할 때 사용됩니다. 실제 스타트업 현장 이야기를 들어볼까요? 어느 스타트업에 새로운 백엔드 개발자가 입사했습니다. CTO는 "kim.backend"라는 이름으로 IAM 사용자를 만들었습니다. 콘솔 액세스와 프로그래밍 액세스 모두 활성화했습니다. 권한은 "Developers" 그룹에 추가하는 것으로 간단히 처리했습니다. 이 그룹에는 이미 개발에 필요한 권한들이 정의되어 있었습니다. 초기 비밀번호는 임시로 생성하고, 첫 로그인 시 변경하도록 설정했습니다. 액세스 키는 Slack DM으로 안전하게 전달했습니다. 새 개발자는 그날 오후부터 바로 작업을 시작할 수 있었습니다. 하지만 주의할 점이 있습니다. 가장 흔한 실수는 사용자를 만들고 바로 AdministratorAccess 권한을 주는 것입니다. "일단 모든 권한을 주고 나중에 제한하자"는 생각이지만, 나중은 오지 않습니다. 처음부터 필요한 권한만 정확히 부여하는 습관을 들여야 합니다. 또 다른 실수는 액세스 키를 제대로 관리하지 않는 것입니다. 액세스 키를 코드에 하드코딩하거나 팀 채팅방에 평문으로 공유하는 경우가 있습니다. 이것은 집 열쇠를 현관문에 붙여놓는 것과 같습니다. 액세스 키는 반드시 안전한 방법으로 전달하고 저장해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 가이드에 따라 김개발 씨는 자신의 첫 IAM 사용자를 성공적으로 만들었습니다. "와, 생각보다 간단하네요!" IAM 사용자 생성은 AWS 보안의 첫걸음입니다. 여러분도 오늘 배운 절차대로 팀원들의 IAM 사용자를 만들어보세요. **실전 팁** 💡 - 사용자 이름은 회사의 네이밍 규칙을 따라 일관되게 작성하세요 - 액세스 키는 절대 코드나 버전 관리 시스템에 포함하지 마세요 - 초기 비밀번호는 복잡하게 생성하고 첫 로그인 시 변경하도록 설정하세요 --- ## 4. IAM_그룹_활용 김개발 씨가 신이 나서 팀원 5명의 IAM 사용자를 만들었습니다. 그런데 각 사용자마다 일일이 권한을 설정하려니 너무 번거로웠습니다. "이렇게 하나하나 권한을 줘야 하나요?" 박시니어 씨가 웃으며 말했습니다. "그래서 그룹이 있는 거예요." **IAM 그룹**은 비슷한 역할을 하는 사용자들을 묶어서 관리하는 방법입니다. 마치 학교에서 학생들을 반으로 나누는 것처럼, 개발자 그룹, 디자이너 그룹, 운영팀 그룹 등으로 나눌 수 있습니다. 그룹에 권한을 부여하면 그룹에 속한 모든 사용자가 자동으로 그 권한을 갖게 됩니다. 이렇게 하면 권한 관리가 훨씬 쉬워집니다. 다음 코드를 살펴봅시다. ```javascript // IAM 그룹 생성 및 사용자 추가 const { IAMClient, CreateGroupCommand, AttachGroupPolicyCommand, AddUserToGroupCommand } = require("@aws-sdk/client-iam"); async function setupDevelopersGroup() { const client = new IAMClient({ region: "ap-northeast-2" }); try { // 1. 개발자 그룹 생성 const createGroupCommand = new CreateGroupCommand({ GroupName: "Developers", Path: "/engineering/" }); const groupResponse = await client.send(createGroupCommand); console.log("✓ 그룹 생성:", groupResponse.Group.GroupName); // 2. 그룹에 정책 연결 (EC2와 S3 읽기 권한) const attachPolicyCommand = new AttachGroupPolicyCommand({ GroupName: "Developers", PolicyArn: "arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess" }); await client.send(attachPolicyCommand); console.log("✓ EC2 읽기 권한 부여 완료"); // 3. 사용자를 그룹에 추가 const addUserCommand = new AddUserToGroupCommand({ GroupName: "Developers", UserName: "kim.developer" }); await client.send(addUserCommand); console.log("✓ kim.developer를 Developers 그룹에 추가"); } catch (error) { console.error("그룹 설정 실패:", error.message); } } setupDevelopersGroup(); ``` 김개발 씨는 화면을 보며 한숨을 쉬었습니다. 팀원이 5명뿐인데도 각자에게 권한을 설정하려니 벌써 머리가 아팠습니다. 각 사용자마다 EC2 접근 권한, S3 접근 권한, CloudWatch 접근 권한을 하나하나 추가해야 했습니다. 만약 팀원이 50명이라면 어떻게 될까요? "김개발 씨, 그렇게 하면 안 돼요. 그룹을 사용해야죠." 박시니어 씨가 다가왔습니다. 그렇다면 IAM 그룹이란 정확히 무엇일까요? 쉽게 비유하자면, IAM 그룹은 마치 회사의 부서와 같습니다. 회사에는 개발팀, 디자인팀, 마케팅팀이 있습니다. 각 부서마다 필요한 시스템 접근 권한이 다릅니다. 개발팀은 서버에 접근해야 하고, 디자인팀은 디자인 파일 저장소에 접근해야 합니다. IAM 그룹도 이처럼 역할별로 사용자를 묶어서 관리합니다. 그룹이 없던 시절에는 어땠을까요? 모든 사용자의 권한을 개별적으로 관리해야 했습니다. 새로운 서비스 접근 권한을 추가하려면 100명의 개발자 계정에 일일이 권한을 추가해야 했습니다. 누군가 퇴사하면 그 사람의 모든 권한을 일일이 제거해야 했습니다. 실수로 권한을 빼먹거나 잘못 주는 경우도 많았습니다. 바로 이런 문제를 해결하기 위해 그룹이 등장했습니다. 그룹을 사용하면 권한 관리가 극적으로 간단해집니다. "Developers" 그룹에 개발에 필요한 모든 권한을 한 번만 설정해두면, 새로운 개발자를 뽑을 때마다 그냥 이 그룹에 추가하기만 하면 됩니다. 권한을 수정할 때도 그룹 권한만 바꾸면 그룹에 속한 모든 사용자에게 자동으로 적용됩니다. 전형적인 그룹 구조를 살펴볼까요? 대부분의 회사는 이런 식으로 그룹을 만듭니다. **Developers** 그룹은 개발 환경의 EC2, RDS, S3 등에 접근할 수 있습니다. **Operators** 그룹은 프로덕션 환경을 모니터링하고 문제를 해결할 수 있습니다. **Admins** 그룹은 거의 모든 작업을 할 수 있지만, 결제 정보 변경 같은 민감한 작업은 제외됩니다. **Auditors** 그룹은 읽기 전용으로 모든 것을 조회할 수 있습니다. 위의 코드를 단계별로 살펴보겠습니다. 먼저 CreateGroupCommand로 "Developers"라는 그룹을 만듭니다. Path 파라미터는 그룹을 논리적으로 구조화하는 데 사용됩니다. 다음으로 AttachGroupPolicyCommand로 AWS 관리형 정책을 그룹에 연결합니다. 마지막으로 AddUserToGroupCommand로 사용자를 그룹에 추가합니다. 실제 스타트업 사례를 들어볼까요? 어느 스타트업이 처음에는 팀원이 3명이었습니다. 그래서 그룹 없이 개별 사용자에게 권한을 줬습니다. 하지만 6개월 만에 팀원이 20명으로 늘었습니다. CTO는 권한 관리에 하루에 1시간씩 쓰게 됐습니다. 그래서 그룹 시스템을 도입했습니다. Developers, QA, DevOps, DataAnalysts 네 개의 그룹을 만들었습니다. 각 그룹에 필요한 권한을 정의했습니다. 그 후로는 신규 입사자가 와도 5분 안에 계정 설정이 끝났습니다. 해당 그룹에 추가하기만 하면 됐으니까요. 한 사용자는 여러 그룹에 속할 수 있습니다. 예를 들어 개발팀장은 Developers 그룹과 TeamLeaders 그룹 두 곳에 모두 속할 수 있습니다. 그러면 두 그룹의 권한을 모두 갖게 됩니다. 하지만 너무 많은 그룹에 속하면 권한이 복잡해지므로 적절한 수준을 유지해야 합니다. 하지만 주의할 점도 있습니다. 그룹에 너무 많은 권한을 주면 안 됩니다. "일단 다 주고 보자"는 식으로 접근하면 그룹을 만드는 의미가 없습니다. 각 그룹이 정말 필요한 최소한의 권한만 가지도록 세밀하게 설계해야 합니다. 또 다른 실수는 그룹 이름을 대충 짓는 것입니다. "Team1", "Group2" 같은 이름은 나중에 무슨 그룹인지 알 수 없습니다. "WebDevelopers", "MobileTeam", "DataEngineers" 같은 명확한 이름을 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언에 따라 김개발 씨는 그룹을 만들고 팀원들을 적절한 그룹에 추가했습니다. "와, 정말 편하네요! 이제 신규 입사자가 와도 걱정 없겠어요." IAM 그룹을 제대로 활용하면 수백 명의 사용자도 쉽게 관리할 수 있습니다. 여러분도 오늘부터 역할별로 그룹을 만들어 체계적으로 권한을 관리해보세요. **실전 팁** 💡 - 그룹은 역할 기반으로 만들고, 프로젝트별 권한은 태그로 관리하세요 - 주기적으로 그룹 권한을 검토하고 불필요한 권한은 제거하세요 - 한 사용자가 4개 이상의 그룹에 속한다면 권한 구조를 재설계할 때입니다 --- ## 5. IAM_정책_기초 김개발 씨가 그룹에 권한을 추가하려는데 정책이라는 단어가 계속 나왔습니다. "AWS 관리형 정책", "고객 관리형 정책", "인라인 정책"... 도대체 이게 뭘까요? 박시니어 씨가 설명을 시작했습니다. "정책은 IAM의 핵심이에요. 이것만 이해하면 IAM의 80%를 안 거예요." "Team A의 S3 폴더 접근 권한" }); const response = await client.send(command); console.log("✓ 정책 생성 완료:", response.Policy.PolicyName); console.log("정책 ARN:", response.Policy.Arn); } catch (error) { console.error("정책 생성 실패:", error.message); } } createCustomPolicy(); 다음 코드를 살펴봅시다. ```javascript // 커스텀 IAM 정책 생성하기 const { IAMClient, CreatePolicyCommand } = require("@aws-sdk/client-iam"); async function createCustomPolicy() { const client = new IAMClient({ region: "ap-northeast-2" }); // S3 버킷의 특정 폴더에만 접근 가능한 정책 const policyDocument = { Version: "2012-10-17", Statement: [ { Effect: "Allow", Action: [ "s3:ListBucket" ], Resource: "arn:aws:s3:::my-company-bucket", Condition: { StringLike: { "s3:prefix": ["team-a/*"] } } }, { Effect: "Allow", Action: [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], Resource: "arn:aws:s3:::my-company-bucket/team-a/*" } ] }; try { const command = new CreatePolicyCommand({ PolicyName: "TeamAFolderAccess", PolicyDocument: JSON.stringify(policyDocument), ``` 김개발 씨는 AWS 콘솔에서 정책 목록을 보고 깜짝 놀랐습니다. 정책이 수백 개나 되었습니다. AdministratorAccess, AmazonS3ReadOnlyAccess, AmazonEC2FullAccess... 도대체 이 많은 정책을 다 알아야 하는 걸까요? "전부 외울 필요는 없어요. 원리만 이해하면 됩니다." 박시니어 씨가 안심시켰습니다. 그렇다면 IAM 정책이란 정확히 무엇일까요? 쉽게 비유하자면, 정책은 마치 건물 출입 규정과 같습니다. "3층 회의실은 부장급 이상만 출입 가능", "지하 주차장은 전 직원 출입 가능" 같은 규칙들입니다. IAM 정책도 이처럼 "EC2는 개발팀만 접근 가능", "S3는 모든 직원 읽기 가능" 같은 규칙을 정의합니다. 정책의 기본 구조를 살펴봅시다. 모든 IAM 정책은 JSON 형식으로 작성됩니다. 크게 네 가지 요소로 구성됩니다. **Effect**는 허용(Allow)인지 거부(Deny)인지를 나타냅니다. **Action**은 어떤 작업을 할 수 있는지를 나타냅니다. **Resource**는 어떤 리소스에 적용되는지를 나타냅니다. **Condition**은 추가 조건을 명시합니다. 정책의 종류는 크게 세 가지입니다. 첫째, **AWS 관리형 정책**입니다. AWS가 미리 만들어놓은 정책입니다. 일반적인 사용 사례에 맞춰 설계되어 있어서 바로 사용하기 편합니다. 예를 들어 AmazonS3ReadOnlyAccess는 모든 S3 버킷을 읽을 수 있는 권한을 줍니다. 둘째, **고객 관리형 정책**입니다. 여러분이 직접 만드는 정책입니다. 회사의 특수한 요구사항에 맞춰 세밀하게 조정할 수 있습니다. 여러 사용자나 그룹에 재사용할 수 있다는 장점이 있습니다. 셋째, **인라인 정책**입니다. 특정 사용자, 그룹, 역할에만 직접 붙이는 정책입니다. 일회성 권한이나 매우 특수한 경우에만 사용합니다. 위의 코드를 자세히 분석해봅시다. 이 정책은 S3 버킷의 특정 폴더에만 접근을 허용합니다. 첫 번째 Statement는 버킷 목록 조회를 허용하되, "team-a/" 접두사가 붙은 객체만 볼 수 있게 제한합니다. 두 번째 Statement는 "team-a/" 폴더 안의 파일을 읽고, 쓰고, 삭제할 수 있게 허용합니다. 실제 스타트업에서 있었던 일입니다. 어느 스타트업에서 모든 개발자에게 AdministratorAccess 권한을 줬습니다. 편하니까요. 그런데 어느 날 인턴 개발자가 실수로 프로덕션 데이터베이스를 삭제했습니다. 다행히 백업이 있어서 복구했지만, 서비스가 2시간 동안 중단됐습니다. 이 사고 이후 회사는 정책을 세밀하게 재설계했습니다. 주니어 개발자는 개발 환경만 접근 가능하게, 시니어 개발자는 프로덕션 읽기 권한까지, 데브옵스 팀만 프로덕션 쓰기 권한을 갖도록 했습니다. 그 뒤로 비슷한 사고는 일어나지 않았습니다. 정책을 작성할 때 주의할 점이 있습니다. **명시적 거부는 모든 허용보다 우선합니다**. 예를 들어 한 정책에서 S3 접근을 Allow 했더라도, 다른 정책에서 Deny 했다면 최종적으로는 거부됩니다. 이것을 이해하지 못하면 "분명히 권한을 줬는데 왜 안 되지?"라는 상황에 빠집니다. 또 다른 중요한 개념은 **최소 권한 원칙**입니다. "일단 모든 권한을 주고 필요 없는 것만 빼자"가 아니라 "필요한 권한만 정확히 주자"는 마인드로 접근해야 합니다. 처음에는 번거롭지만, 장기적으로 보안 사고를 예방하는 가장 확실한 방법입니다. 정책 테스트는 어떻게 할까요? AWS는 **IAM Policy Simulator**라는 도구를 제공합니다. 정책을 실제로 적용하기 전에 시뮬레이션할 수 있습니다. "이 사용자가 이 작업을 할 수 있을까?" 같은 질문에 답해줍니다. 정책을 만들었다면 반드시 시뮬레이터로 테스트해보세요. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 정책 문서를 다시 보니 이제 이해가 됐습니다. "아, Effect, Action, Resource 이 세 가지만 기억하면 되는구나!" IAM 정책을 이해하면 AWS 리소스를 정교하게 제어할 수 있습니다. 여러분도 오늘 배운 내용을 바탕으로 회사에 맞는 커스텀 정책을 작성해보세요. **실전 팁** 💡 - 처음에는 AWS 관리형 정책으로 시작하고 점진적으로 커스터마이징하세요 - 정책은 버전 관리 시스템에 저장해서 변경 이력을 추적하세요 - IAM Policy Simulator로 정책을 반드시 테스트한 후 적용하세요 --- ## 6. 역할(Role)_개념 김개발 씨가 EC2 인스턴스에서 S3에 접근해야 하는 상황이 생겼습니다. "EC2 안에 액세스 키를 넣어야 하나?" 고민하던 중 박시니어 씨가 말했습니다. "절대 그러면 안 돼요. 역할을 사용해야죠." "EC2 인스턴스가 S3에 접근할 수 있는 역할" }); const roleResponse = await client.send(createRoleCommand); console.log("✓ 역할 생성:", roleResponse.Role.RoleName); console.log("역할 ARN:", roleResponse.Role.Arn); // 2. S3 접근 정책 연결 const attachPolicyCommand = new AttachRolePolicyCommand({ RoleName: "EC2-S3-Access-Role", PolicyArn: "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" }); await client.send(attachPolicyCommand); console.log("✓ S3 읽기 권한 연결 완료"); console.log("\n이제 EC2 인스턴스를 생성할 때 이 역할을 지정하세요."); } catch (error) { console.error("역할 생성 실패:", error.message); } } createEC2Role(); 다음 코드를 살펴봅시다. ```javascript // EC2 인스턴스용 IAM 역할 생성 const { IAMClient, CreateRoleCommand, AttachRolePolicyCommand } = require("@aws-sdk/client-iam"); async function createEC2Role() { const client = new IAMClient({ region: "ap-northeast-2" }); // 신뢰 정책: EC2가 이 역할을 맡을 수 있도록 허용 const trustPolicy = { Version: "2012-10-17", Statement: [ { Effect: "Allow", Principal: { Service: "ec2.amazonaws.com" }, Action: "sts:AssumeRole" } ] }; try { // 1. 역할 생성 const createRoleCommand = new CreateRoleCommand({ RoleName: "EC2-S3-Access-Role", AssumeRolePolicyDocument: JSON.stringify(trustPolicy), ``` 김개발 씨는 난관에 부딪혔습니다. EC2 인스턴스에서 실행되는 애플리케이션이 S3 버킷의 파일을 읽어야 합니다. 가장 쉬운 방법은 액세스 키를 EC2의 환경 변수에 넣는 것입니다. 하지만 박시니어 씨가 강하게 말렸습니다. "그렇게 하면 보안 사고 나요. 누군가 EC2에 접속하면 액세스 키를 훔칠 수 있어요." 그렇다면 어떻게 해야 할까요? 그렇다면 IAM 역할이란 정확히 무엇일까요? 쉽게 비유하자면, 역할은 마치 대리 운전 기사에게 주는 임시 권한과 같습니다. 여러분이 회식 후 대리 기사를 불렀습니다. 기사는 여러분의 차 키를 받아 목적지까지 운전합니다. 하지만 기사는 여러분의 차를 영구적으로 소유하는 것이 아닙니다. 목적지에 도착하면 권한이 끝납니다. IAM 역할도 이처럼 필요한 순간에만 임시로 권한을 부여합니다. 역할과 사용자의 차이점은 무엇일까요? **사용자**는 장기 자격증명입니다. 액세스 키가 있고, 비밀번호가 있습니다. 한 번 발급하면 명시적으로 삭제하기 전까지 계속 유효합니다. 반면 **역할**은 단기 자격증명입니다. 역할을 맡으면 임시 토큰을 받습니다. 이 토큰은 보통 1시간 정도 유효하고, 시간이 지나면 자동으로 만료됩니다. 역할이 필요한 대표적인 상황을 살펴봅시다. 첫째, **EC2 인스턴스가 다른 AWS 서비스에 접근할 때**입니다. EC2에서 S3 파일을 읽거나 DynamoDB에 쓸 때 역할을 사용합니다. 둘째, **람다 함수가 실행될 때**입니다. 람다는 항상 역할을 필요로 합니다. 셋째, **다른 AWS 계정에서 접근할 때**입니다. 회사의 개발 계정에서 프로덕션 계정의 리소스에 접근해야 할 때 크로스 계정 역할을 사용합니다. 역할의 핵심 개념은 **AssumeRole**입니다. "역할을 맡는다"는 의미입니다. EC2 인스턴스가 역할을 맡으면, AWS는 그 인스턴스에게 임시 자격증명을 발급합니다. 인스턴스는 이 자격증명으로 S3나 다른 서비스에 접근합니다. 자격증명이 만료되기 전에 AWS SDK가 자동으로 새로운 자격증명을 받아옵니다. 위의 코드를 단계별로 분석해봅시다. 먼저 신뢰 정책(Trust Policy)을 정의합니다. 이것은 "누가 이 역할을 맡을 수 있는가"를 명시합니다. 여기서는 EC2 서비스가 이 역할을 맡을 수 있도록 허용했습니다. 다음으로 CreateRoleCommand로 역할을 생성합니다. 마지막으로 AttachRolePolicyCommand로 S3 읽기 권한을 역할에 연결합니다. 실제 현업 사례를 들어볼까요? 한 스타트업에서 마이크로서비스 아키텍처를 구축했습니다. 각 서비스는 EC2 인스턴스에서 실행됩니다. 주문 서비스는 S3에서 상품 이미지를 읽어야 하고, 결제 서비스는 DynamoDB에 거래 내역을 저장해야 합니다. 처음에는 각 인스턴스에 액세스 키를 넣었습니다. 하지만 보안 감사에서 지적을 받았습니다. 그래서 서비스별로 역할을 만들었습니다. OrderServiceRole, PaymentServiceRole 같은 식입니다. 각 역할에는 해당 서비스에 꼭 필요한 권한만 부여했습니다. 인스턴스를 시작할 때 적절한 역할을 지정하기만 하면 끝입니다. 이렇게 바꾼 후 장점이 많았습니다. 첫째, 액세스 키가 코드나 설정 파일에 없으니 누출 위험이 사라졌습니다. 둘째, 역할 권한만 수정하면 모든 인스턴스에 즉시 적용됩니다. 셋째, CloudTrail 로그에서 어떤 역할이 무슨 작업을 했는지 명확히 추적할 수 있습니다. 하지만 주의할 점도 있습니다. 역할에도 과도한 권한을 주면 안 됩니다. 어떤 개발자들은 "귀찮다"는 이유로 모든 역할에 AdministratorAccess를 줍니다. 이것은 역할을 사용하는 의미를 퇴색시킵니다. 각 역할은 정말 필요한 최소한의 권한만 가져야 합니다. 또 다른 실수는 역할 신뢰 정책을 너무 느슨하게 설정하는 것입니다. 예를 들어 Principal을 "*"로 설정하면 누구나 이 역할을 맡을 수 있습니다. 반드시 특정 서비스나 특정 계정만 역할을 맡을 수 있도록 제한해야 합니다. 크로스 계정 역할도 강력한 기능입니다. 개발 계정에서 프로덕션 계정의 리소스를 안전하게 관리할 수 있습니다. 예를 들어 개발자는 자신의 개발 계정에 로그인합니다. 필요할 때만 프로덕션 계정의 읽기 전용 역할을 맡아서 로그를 확인합니다. 역할 사용이 끝나면 다시 개발 계정으로 돌아옵니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 가이드에 따라 김개발 씨는 EC2용 역할을 만들고 인스턴스에 지정했습니다. 코드에서 액세스 키를 완전히 제거했습니다. "와, 이제 보안 걱정 없이 잘 수 있겠어요!" IAM 역할을 제대로 활용하면 액세스 키 없이도 안전하게 AWS 리소스에 접근할 수 있습니다. 여러분도 오늘부터 EC2, 람다 등에 역할을 적극 활용해보세요. **실전 팁** 💡 - EC2 인스턴스에는 항상 역할을 지정하고 액세스 키는 절대 사용하지 마세요 - 역할 이름은 용도를 명확히 나타내도록 작성하세요 (예: EC2-S3-ReadOnly-Role) - 임시 자격증명 갱신은 AWS SDK가 자동으로 처리하므로 걱정하지 않아도 됩니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, IAM, 보안, 권한관리, 클라우드

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS IAM 사용자와 권한 완벽 가이드

목차

1. IAM이란 무엇인가

2. 루트 사용자 vs IAM 사용자

3. IAM 사용자 생성

4. IAM 그룹 활용

5. IAM 정책 기초

6. 역할(Role) 개념

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드

보안 아키텍처 구성 완벽 가이드