TIL - 20260615

juni·2026년 6월 15일

TIL

목록 보기

378/468

0615 AWS 운영 실무 기초 (6/N): IAM과 보안 권한 관리

✅ 1. IAM이란 무엇인가?

IAM(Identity and Access Management)은 AWS에서 사용자, 권한, 역할, Access Key를 관리하는 서비스입니다.
쉽게 말하면 “누가 AWS의 어떤 리소스에 접근할 수 있는지”를 정하는 권한 관리 시스템입니다.
AWS 운영에서 IAM은 가장 중요한 보안 기초입니다.

➕ 1-1. IAM이 중요한 이유

권한 오남용 방지
- 모든 사용자에게 관리자 권한을 주면 실수나 유출 사고가 커질 수 있습니다.
Access Key 유출 방지
- S3, EC2, RDS에 접근할 수 있는 키가 유출되면 과금 사고나 데이터 유출로 이어질 수 있습니다.
작업자별 권한 분리
- 개발자, 운영자, 외주 작업자, 배포 서버가 필요한 권한만 갖도록 제한할 수 있습니다.
보안 사고 영향 최소화
- 최소 권한 원칙을 지키면 한 계정이 유출되어도 피해 범위를 줄일 수 있습니다.

✅ 2. 루트 계정과 IAM 사용자

AWS 계정을 처음 만들면 루트 계정(Root Account)이 생성됩니다.
루트 계정은 AWS 계정 전체에 대한 모든 권한을 가진 최고 관리자입니다.
일상적인 운영 작업에는 루트 계정을 사용하지 않는 것이 원칙입니다.

➕ 2-1. 루트 계정으로 해야 하는 일

AWS 계정 생성
결제 정보 관리
루트 계정 MFA 설정
일부 계정 수준 설정
IAM 관리자 사용자 최초 생성

➕ 2-2. 루트 계정으로 하면 안 되는 일

EC2 생성
S3 업로드
RDS 관리
일상적인 배포 작업
Access Key 생성
외주 작업자에게 공유

좋은 운영 방식:
루트 계정은 잠가두고 거의 사용하지 않음
  ↓
IAM 사용자 또는 IAM Role로 일상 작업 수행

✅ 3. MFA

MFA(Multi-Factor Authentication)는 비밀번호 외에 추가 인증 수단을 사용하는 보안 방식입니다.
AWS 루트 계정과 관리자 IAM 사용자에는 반드시 MFA를 설정하는 것이 좋습니다.

➕ 3-1. MFA가 필요한 이유

비밀번호가 유출되어도 추가 인증 없이는 로그인하기 어렵습니다.
루트 계정 탈취 위험을 크게 줄일 수 있습니다.
관리자 계정 보호에 필수입니다.

➕ 3-2. MFA 적용 대상

루트 계정
관리자 IAM 사용자
결제 정보 접근 권한이 있는 사용자
운영 리소스 삭제 권한이 있는 사용자
IAM 권한 수정 권한이 있는 사용자

최소 기준:
루트 계정 MFA는 무조건 설정
관리자 IAM 사용자 MFA도 설정

✅ 4. IAM 사용자

IAM 사용자(User)는 AWS 콘솔이나 AWS CLI를 사용할 수 있는 개별 계정입니다.
사람마다 개별 IAM 사용자를 만들어야 합니다.
하나의 계정을 여러 명이 공유하면 누가 어떤 작업을 했는지 추적하기 어렵습니다.

➕ 4-1. IAM 사용자 예시

admin-dongjun
developer-api
designer-readonly
external-contractor

➕ 4-2. 사용자별 권한 분리 예시

사용자	권한
관리자	전체 운영 관리
백엔드 개발자	EC2, RDS 일부, CloudWatch
프론트 개발자	S3, CloudFront 일부
디자이너	S3 읽기 권한
외주 작업자	특정 버킷 또는 특정 서버만 접근

실무에서는 사람마다 필요한 작업 범위가 다르므로 권한도 다르게 주는 것이 안전합니다.

✅ 5. IAM 그룹

IAM 그룹(Group)은 여러 사용자에게 같은 권한을 한 번에 적용하기 위한 묶음입니다.
사용자마다 직접 권한을 붙이는 것보다 그룹을 만들어 관리하는 편이 깔끔합니다.

➕ 5-1. 그룹 예시

Administrators
Developers
FrontendDevelopers
BackendDevelopers
ReadOnlyUsers

➕ 5-2. 그룹을 사용하는 이유

권한 관리가 쉬워집니다.
팀원이 추가될 때 그룹에만 넣으면 됩니다.
권한 변경 시 그룹 정책만 수정하면 됩니다.
사람별로 권한이 제각각 섞이는 것을 줄일 수 있습니다.

나쁜 방식:
사용자마다 직접 정책을 여러 개 붙임

좋은 방식:
역할별 그룹을 만들고 사용자를 그룹에 추가

✅ 6. IAM 정책

IAM 정책(Policy)은 어떤 AWS 리소스에 어떤 작업을 허용하거나 거부할지 JSON 형식으로 정의한 권한 규칙입니다.

➕ 6-1. 정책의 기본 구조

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-bucket/*"]
    }
  ]
}

항목	의미
`Effect`	허용 또는 거부
`Action`	가능한 작업
`Resource`	대상 리소스
`Condition`	조건부 허용

✅ 7. 최소 권한 원칙

IAM의 핵심 원칙은 최소 권한(Least Privilege)입니다.
사용자가 필요한 작업을 할 수 있을 만큼만 권한을 부여해야 합니다.

➕ 7-1. 나쁜 예시

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

모든 AWS 리소스에 모든 작업을 허용하는 설정입니다.
개발 편의성은 높지만 보안상 매우 위험합니다.

➕ 7-2. 좋은 예시

{
  "Effect": "Allow",
  "Action": [
    "s3:PutObject",
    "s3:GetObject",
    "s3:DeleteObject"
  ],
  "Resource": [
    "arn:aws:s3:::togethermall-prod-assets/public/*"
  ]
}

특정 S3 버킷의 특정 경로에 필요한 작업만 허용합니다.
실무에서는 이런 방식으로 권한 범위를 줄이는 것이 좋습니다.

✅ 8. Access Key

Access Key는 AWS CLI, SDK, 백엔드 서버에서 AWS 리소스에 접근할 때 사용하는 인증 정보입니다.
AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY로 구성됩니다.

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
AWS_REGION=ap-northeast-2

➕ 8-1. Access Key가 필요한 상황

백엔드 서버에서 S3에 파일 업로드
GitHub Actions에서 S3 배포
AWS CLI로 리소스 관리
배치 서버에서 백업 파일 업로드
외부 도구에서 AWS API 호출

➕ 8-2. Access Key 보안 원칙

GitHub에 올리지 않는다.
프론트엔드 코드에 넣지 않는다.
Notion 공개 문서에 적지 않는다.
Slack, 카카오톡에 그대로 공유하지 않는다.
사용하지 않는 키는 삭제한다.
주기적으로 교체한다.
권한은 최소한으로 부여한다.
유출 의심 시 즉시 비활성화하고 새로 발급한다.

✅ 9. Access Key 유출 시 대응

Access Key가 유출되면 빠르게 대응해야 합니다.
키가 GitHub에 올라갔다면 이미 외부에 노출되었다고 봐야 합니다.

➕ 9-1. 대응 순서

1. 유출된 Access Key 즉시 비활성화
2. 새 Access Key 발급
3. 서버/CI/CD 환경변수 교체
4. CloudTrail에서 의심 활동 확인
5. 비용 이상 발생 여부 확인
6. 필요 시 IAM 권한 축소
7. Git 기록에서 Secret 제거
8. 재발 방지 설정 적용

➕ 9-2. 주의할 점

GitHub 파일에서 키를 삭제해도 커밋 히스토리에 남아 있을 수 있습니다.
유출된 키는 삭제가 아니라 폐기 후 재발급이 원칙입니다.
프론트엔드에 들어간 키는 사용자 브라우저에서 확인될 수 있으므로 즉시 폐기해야 합니다.

✅ 10. IAM Role

IAM Role은 사용자나 서비스가 임시로 권한을 받아 AWS 리소스에 접근할 수 있게 하는 방식입니다.
Access Key를 직접 저장하지 않고도 권한을 부여할 수 있어 보안상 더 좋습니다.

➕ 10-1. IAM Role이 필요한 상황

EC2에서 S3에 파일 업로드
Lambda에서 DynamoDB 접근
GitHub Actions에서 AWS 배포
ECS Task가 CloudWatch Logs에 로그 전송
CloudFront가 S3 원본에 접근

➕ 10-2. EC2 Role 예시

EC2 인스턴스에 S3 업로드 권한 Role 부여
  ↓
애플리케이션은 Access Key 없이 S3 API 호출
  ↓
AWS SDK가 EC2 Role 권한을 자동 사용

EC2에서 S3를 사용할 때는 가능하면 Access Key를 .env에 저장하는 것보다 IAM Role을 사용하는 것이 안전합니다.

✅ 11. IAM Role과 Access Key 비교

구분	Access Key	IAM Role
사용 방식	키를 직접 저장	AWS 리소스에 역할 부여
보안성	유출 위험 있음	상대적으로 안전
관리	키 교체 필요	임시 자격 증명 자동 관리
EC2 사용	가능하지만 키 저장 필요	권장
로컬 개발	사용 가능	설정 복잡할 수 있음
CI/CD	Secrets로 사용 가능	OIDC Role 방식 가능

➕ 11-1. 실무 기준

로컬 개발:
Access Key 사용 가능, 단 최소 권한

EC2 운영 서버:
IAM Role 권장

GitHub Actions:
가능하면 OIDC Role 권장
간단한 초기 구성은 Secrets에 Access Key 저장

✅ 12. S3 업로드용 최소 권한 정책 예시

백엔드 서버가 특정 S3 버킷에 파일을 업로드해야 한다면, 모든 AWS 권한을 줄 필요가 없습니다.
필요한 버킷과 경로에 대해서만 권한을 줍니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::togethermall-prod-assets/uploads/*"
      ]
    }
  ]
}

➕ 12-1. ListBucket이 필요한 경우

특정 경로의 파일 목록을 조회해야 한다면 s3:ListBucket 권한도 필요할 수 있습니다.

{
  "Effect": "Allow",
  "Action": ["s3:ListBucket"],
  "Resource": ["arn:aws:s3:::togethermall-prod-assets"],
  "Condition": {
    "StringLike": {
      "s3:prefix": ["uploads/*"]
    }
  }
}

✅ 13. CloudFront 권한 관리

CloudFront는 S3와 함께 사용할 때 권한 설정이 중요합니다.
운영에서는 S3 버킷을 public으로 열지 않고, CloudFront만 S3에 접근하도록 구성하는 것이 좋습니다.

➕ 13-1. 기본 구조

사용자
  ↓
CloudFront
  ↓
S3

S3는 직접 public 접근 차단
CloudFront를 통해서만 파일 제공

➕ 13-2. OAC

OAC(Origin Access Control)는 CloudFront가 S3 원본에 안전하게 접근하도록 하는 방식입니다.
예전에는 OAI를 많이 사용했지만, 최근 구조에서는 OAC 사용을 고려하는 것이 좋습니다.

S3 Public Access Block 활성화
  ↓
CloudFront OAC 생성
  ↓
S3 버킷 정책에서 CloudFront 접근만 허용

이렇게 하면 사용자는 S3 URL로 직접 접근하지 못하고 CloudFront URL을 통해서만 파일을 볼 수 있습니다.

✅ 14. CloudWatch와 CloudTrail

AWS 보안과 운영에서는 로그가 중요합니다.
CloudWatch와 CloudTrail은 이름이 비슷하지만 역할이 다릅니다.

서비스	역할
CloudWatch	서버/서비스 로그, 지표, 알람
CloudTrail	AWS 계정에서 누가 어떤 API 작업을 했는지 기록

➕ 14-1. CloudWatch

EC2 CPU 사용률
RDS 연결 수
애플리케이션 로그
알람 설정
Lambda 로그
배포 후 오류 확인

➕ 14-2. CloudTrail

누가 EC2를 생성했는지
누가 S3 버킷 정책을 바꿨는지
누가 IAM 권한을 수정했는지
누가 Access Key를 만들었는지
누가 RDS를 삭제하려고 했는지

CloudWatch:
서비스 상태와 로그 확인

CloudTrail:
AWS 계정 내 작업 이력 추적

✅ 15. IAM에서 자주 하는 실수

➕ 15-1. 모든 사용자에게 AdministratorAccess 부여

편하긴 하지만 매우 위험합니다.
실수로 RDS를 삭제하거나 S3 버킷을 public으로 열 수 있습니다.

초기에는 관리자 1명만 AdministratorAccess
나머지는 역할별 최소 권한

➕ 15-2. 루트 계정 Access Key 생성

루트 계정 Access Key는 매우 위험합니다.
특별한 이유가 없다면 만들지 않는 것이 좋습니다.

권장:
루트 계정 Access Key 없음
IAM 사용자 또는 Role 사용

➕ 15-3. 오래된 Access Key 방치

오래된 키는 누가 어디서 쓰는지 모르게 됩니다.
사용하지 않는 키는 비활성화 후 삭제해야 합니다.

정기 점검:
90일 이상 사용하지 않은 Access Key 확인
불필요한 키 삭제

➕ 15-4. 외주 작업자 권한 회수 누락

외주 작업이 끝났는데 IAM 사용자나 Access Key를 그대로 두면 위험합니다.
작업 종료 시 권한 회수 체크리스트가 필요합니다.

외주 종료 후:
IAM 사용자 비활성화
Access Key 삭제
S3 권한 제거
EC2 SSH Key 회수
GitHub 권한 제거

✅ 16. 1인 개발자 기준 IAM 운영 전략

1인 개발자는 구조를 너무 복잡하게 만들 필요는 없지만, 기본 보안은 반드시 지켜야 합니다.

➕ 16-1. 최소 구성 예시

루트 계정:
MFA 설정 후 거의 사용하지 않음

관리자 IAM 사용자:
콘솔 관리용, MFA 설정

EC2 Role:
운영 서버에서 S3 업로드용

GitHub Actions:
배포용 최소 권한 Access Key 또는 OIDC Role

로컬 개발자 키:
개발 버킷만 접근 가능

➕ 16-2. 권한 분리 기준

용도	권장 권한
콘솔 관리자	AdministratorAccess, MFA 필수
운영 EC2	필요한 S3/RDS/CloudWatch 권한만
GitHub Actions	배포에 필요한 S3/CloudFront/EC2 권한만
로컬 개발	dev 리소스만 접근
외주 작업자	기간 제한 + 특정 리소스만

✅ 17. GitHub Actions와 AWS 권한

GitHub Actions에서 AWS에 배포하려면 AWS 권한이 필요합니다.
간단한 방식은 Access Key를 GitHub Secrets에 넣는 것이고, 더 안전한 방식은 OIDC를 사용해 IAM Role을 연결하는 것입니다.

➕ 17-1. Secrets 방식

GitHub Secrets:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION

초기에는 구성하기 쉽습니다.
하지만 키가 장기적으로 존재하므로 유출 관리가 필요합니다.

➕ 17-2. OIDC Role 방식

GitHub Actions
  ↓
AWS OIDC 인증
  ↓
IAM Role 임시 권한 획득
  ↓
배포 작업 수행

장기 Access Key를 저장하지 않아도 되므로 더 안전합니다.
설정은 조금 더 복잡하지만 운영 안정성은 좋습니다.

✅ 18. 실무 체크리스트

➕ 18-1. 계정 보안 체크리스트

루트 계정 MFA를 설정했는가?
루트 계정 Access Key가 없는가?
관리자 IAM 사용자에 MFA가 설정되어 있는가?
사용자를 사람별로 분리했는가?
공용 계정을 사용하지 않는가?
퇴사자나 외주 작업자 권한을 회수했는가?

➕ 18-2. 권한 관리 체크리스트

모든 사용자에게 AdministratorAccess를 주지 않았는가?
S3 권한이 필요한 버킷과 경로로 제한되어 있는가?
운영 리소스와 개발 리소스 권한이 분리되어 있는가?
GitHub Actions 권한이 배포에 필요한 수준으로 제한되어 있는가?
EC2에는 Access Key 대신 IAM Role 사용을 고려했는가?
IAM 정책 변경 이력을 확인할 수 있는가?

➕ 18-3. Access Key 체크리스트

Access Key가 GitHub에 올라가지 않았는가?
프론트엔드 코드에 Access Key가 없는가?
사용하지 않는 Key를 삭제했는가?
키를 주기적으로 교체하는가?
유출 시 즉시 폐기할 수 있는가?
키별 사용 목적이 문서화되어 있는가?

✅ 19. AI를 활용해 IAM 문제를 해결할 때 질문법

IAM 문제는 권한이 너무 넓어도 문제고, 너무 좁아도 기능이 실패합니다.
AI에게 질문할 때는 “어떤 리소스에 어떤 작업을 하려는지”를 명확히 알려줘야 합니다.

➕ 19-1. 좋은 질문 예시

AWS IAM 권한을 최소 권한으로 만들고 싶어.

상황:
1. NestJS 백엔드가 EC2에서 실행 중
2. 백엔드는 S3에 배너 이미지를 업로드해야 함
3. 버킷 이름은 togethermall-prod-assets
4. 업로드 경로는 uploads/banners/* 만 사용
5. 파일 조회와 삭제도 필요함
6. 다른 S3 버킷에는 접근하면 안 됨
7. 가능하면 EC2 IAM Role로 처리하고 싶음

필요한 IAM 정책 예시와 EC2 Role 연결 흐름을 설명해줘.
보안상 주의할 점도 같이 알려줘.

➕ 19-2. AI 답변 검증 기준

Action: "*"와 Resource: "*"를 무조건 권하지 않는가?
버킷과 경로를 제한하는가?
EC2에서는 Access Key보다 IAM Role을 권장하는가?
프론트엔드에 AWS Secret을 넣지 말라고 하는가?
필요한 작업별 s3:PutObject, s3:GetObject, s3:DeleteObject를 구분하는가?
CloudTrail로 작업 이력을 확인할 수 있음을 설명하는가?
유출 시 키 폐기와 재발급 절차를 안내하는가?

📌 요약

IAM은 AWS에서 사용자, 그룹, 정책, 역할, Access Key를 관리하는 보안 서비스입니다.
루트 계정은 일상 작업에 사용하지 말고, MFA를 설정한 뒤 최대한 잠가두는 것이 좋습니다.
IAM 권한의 핵심은 최소 권한 원칙입니다.
모든 사용자에게 AdministratorAccess를 주면 편하지만, 운영 사고와 보안 사고 위험이 큽니다.
Access Key는 AWS 리소스에 접근할 수 있는 열쇠이므로 GitHub, 프론트엔드 코드, 공개 문서에 절대 올리면 안 됩니다.
EC2에서 S3에 접근할 때는 가능하면 Access Key 대신 IAM Role을 사용하는 것이 안전합니다.
CloudWatch는 서비스 상태와 로그를 보고, CloudTrail은 AWS 계정 내 작업 이력을 추적하는 데 사용합니다.
1인 개발자라도 루트 계정 MFA, 관리자 IAM 사용자 분리, S3 최소 권한, Access Key 관리, 비용/보안 로그 확인은 반드시 챙겨야 합니다.

juni

이전 포스트

TIL - 20260612

다음 포스트

TIL - 20260615

TIL

0615 AWS 운영 실무 기초 (6/N): IAM과 보안 권한 관리

✅ 1. IAM이란 무엇인가?

➕ 1-1. IAM이 중요한 이유

✅ 2. 루트 계정과 IAM 사용자

➕ 2-1. 루트 계정으로 해야 하는 일

➕ 2-2. 루트 계정으로 하면 안 되는 일

✅ 3. MFA

➕ 3-1. MFA가 필요한 이유

➕ 3-2. MFA 적용 대상

✅ 4. IAM 사용자

➕ 4-1. IAM 사용자 예시

➕ 4-2. 사용자별 권한 분리 예시

✅ 5. IAM 그룹

➕ 5-1. 그룹 예시

➕ 5-2. 그룹을 사용하는 이유

✅ 6. IAM 정책

➕ 6-1. 정책의 기본 구조

✅ 7. 최소 권한 원칙

➕ 7-1. 나쁜 예시

➕ 7-2. 좋은 예시

✅ 8. Access Key

➕ 8-1. Access Key가 필요한 상황

➕ 8-2. Access Key 보안 원칙

✅ 9. Access Key 유출 시 대응

➕ 9-1. 대응 순서

➕ 9-2. 주의할 점

✅ 10. IAM Role

➕ 10-1. IAM Role이 필요한 상황

➕ 10-2. EC2 Role 예시

✅ 11. IAM Role과 Access Key 비교

➕ 11-1. 실무 기준

✅ 12. S3 업로드용 최소 권한 정책 예시

➕ 12-1. ListBucket이 필요한 경우

✅ 13. CloudFront 권한 관리

➕ 13-1. 기본 구조

➕ 13-2. OAC

✅ 14. CloudWatch와 CloudTrail

➕ 14-1. CloudWatch

➕ 14-2. CloudTrail

✅ 15. IAM에서 자주 하는 실수

➕ 15-1. 모든 사용자에게 AdministratorAccess 부여

➕ 15-2. 루트 계정 Access Key 생성

➕ 15-3. 오래된 Access Key 방치

➕ 15-4. 외주 작업자 권한 회수 누락

✅ 16. 1인 개발자 기준 IAM 운영 전략

➕ 16-1. 최소 구성 예시

➕ 16-2. 권한 분리 기준

✅ 17. GitHub Actions와 AWS 권한

➕ 17-1. Secrets 방식

➕ 17-2. OIDC Role 방식

✅ 18. 실무 체크리스트

➕ 18-1. 계정 보안 체크리스트

➕ 18-2. 권한 관리 체크리스트

➕ 18-3. Access Key 체크리스트

✅ 19. AI를 활용해 IAM 문제를 해결할 때 질문법

➕ 19-1. 좋은 질문 예시

➕ 19-2. AI 답변 검증 기준

📌 요약

TIL - 20260612

TIL - 20260616

0개의 댓글