☁️클라우드

IAM

Identity and Access Management

클라우드 리소스 접근 제어 서비스. 사용자, 역할, 정책 기반 권한 관리.

📖 상세 설명

IAM(Identity and Access Management)은 클라우드 환경에서 "누가(Identity) 무엇에(Resource) 어떤 작업(Action)을 할 수 있는지(Permission)"를 제어하는 핵심 보안 서비스입니다. AWS IAM, GCP IAM, Azure RBAC 등 모든 주요 클라우드가 IAM을 제공하며, 클라우드 보안의 가장 기본이자 가장 중요한 요소입니다.

IAM의 핵심 개념은 사용자(User), 그룹(Group), 역할(Role), 정책(Policy)입니다. 사용자는 개별 계정, 그룹은 사용자의 집합, 역할은 임시로 부여할 수 있는 권한 집합, 정책은 JSON 형식의 권한 정의서입니다. "최소 권한 원칙(Principle of Least Privilege)"에 따라 필요한 최소한의 권한만 부여해야 합니다.

현대적 IAM 운영에서는 장기 자격 증명(Access Key) 대신 역할 기반 임시 자격 증명을 권장합니다. EC2 인스턴스에는 Instance Profile, Lambda에는 Execution Role, Kubernetes에는 IRSA(AWS)/Workload Identity(GCP)를 사용합니다. 이를 통해 자격 증명 유출 위험을 크게 줄일 수 있습니다.

실무에서 IAM은 단순한 권한 관리를 넘어 조직의 보안 거버넌스 구현 도구입니다. 서비스 제어 정책(SCP)으로 계정 전체에 제한을 걸고, 권한 경계(Permission Boundary)로 역할이 가질 수 있는 최대 권한을 제한하며, CloudTrail/Cloud Audit Logs로 모든 API 호출을 감사합니다.

💻 코드 예제

# AWS IAM 정책 예제 - S3 읽기 전용
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

# AWS CLI로 역할 생성 및 정책 연결
aws iam create-role \
  --role-name MyAppRole \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name MyAppRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# EC2 인스턴스 프로파일 생성 (Access Key 대신 사용)
aws iam create-instance-profile \
  --instance-profile-name MyAppProfile

aws iam add-role-to-instance-profile \
  --instance-profile-name MyAppProfile \
  --role-name MyAppRole

# IAM Access Analyzer로 미사용 권한 분석
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:region:account:analyzer/name

🗣️ 실무에서 이렇게 말하세요

💬 회의에서
"Access Key를 코드에 하드코딩하면 보안 사고로 이어집니다. EC2는 Instance Profile, Lambda는 Execution Role, EKS는 IRSA를 사용해서 임시 자격 증명으로 전환해야 합니다. IAM Access Analyzer로 현재 미사용 권한도 분석해서 최소 권한으로 정리합시다."
💬 면접에서
"IAM 설계 시 팀별 역할 분리와 최소 권한 원칙을 적용했습니다. 개발자는 dev 환경만, 운영팀은 prod 읽기+배포 권한만 부여하고, 관리자 권한은 MFA 필수로 설정했습니다. SCP로 특정 리전 외 리소스 생성을 차단하고, Permission Boundary로 개발자가 자신보다 높은 권한의 역할을 만들 수 없게 제한했습니다."
💬 보안 검토에서
"IAM 정책에 Resource가 '*'로 되어있으면 모든 리소스에 접근 가능합니다. S3 버킷명이나 DynamoDB 테이블명을 명시적으로 지정하고, Condition으로 IP 범위나 MFA 여부도 추가하세요. 특히 iam:PassRole은 권한 상승에 악용될 수 있으니 반드시 제한해야 합니다."

⚠️ 흔한 실수 & 주의사항

Access Key를 코드에 하드코딩

GitHub에 Access Key가 노출되어 수천만 원의 과금이 발생한 사례가 많습니다. 코드에 절대 넣지 말고, IAM Role이나 환경변수/Secret Manager를 사용하세요. git-secrets로 커밋 전 자동 검사를 추가하세요.

AdministratorAccess를 남발

편의상 모든 사용자에게 관리자 권한을 주면 사고 시 피해가 막대해집니다. 역할별 최소 권한을 정의하고, 관리자 권한은 MFA 필수+임시 승격(Just-In-Time) 방식으로 제한하세요.

올바른 접근법

AWS Organizations + SCP로 계정 수준 제한, IAM Identity Center(SSO)로 중앙 인증, CloudTrail로 감사 로그 활성화가 필수입니다. 정기적으로 IAM Access Analyzer와 Credential Report로 미사용 권한/키를 정리하세요.

🔗 관련 용어

📚 더 배우기