핵심: 작업에 필요한 권한을 주되, 권한을 새로 만들거나 바꾸는 과정에도 제한과 리뷰가 필요하다.
한눈에 보는 흐름
왜 배웠는가?
팀원은 인프라를 만들 수 있어야 했지만, 계정 전체를 자유롭게 바꿀 수 있게 하는 것은 부담이었다. 콘솔의 편리한 기능과 팀의 권한 규칙이 충돌하기도 했다.
핵심 개념
- IAM User / Group: 사용자 계정 / 공통 권한을 묶어 주는 그룹.
- Role: 사용자나 서비스가 맡아서 사용하는 권한 역할.
- Policy: 어떤 작업을 어떤 대상에 허용·거부할지 적은 규칙.
- Permissions Boundary: 역할이나 사용자의 권한이 넘지 못하도록 정한 상한. 이것만으로 권한이 부여되지는 않는다.
- PassRole: AWS 서비스가 사용할 역할을 지정할 수 있게 하는 권한.
- MFA: 비밀번호 외에 추가 확인 수단을 요구하는 방식.
실제 기록 1 · 권한을 제한하자 정상 작업도 막혔다
조준환의 권한 위임 글에서는 CloudTrail을 CloudWatch Logs에 연결하는 과정이 막혔다. 콘솔이 자동 생성하려는 역할은 팀이 허용한 경로와 경계 조건에 맞지 않았다.
관리자가 조건에 맞는 서비스 역할을 직접 만들어 연결하자 로그가 흐르기 시작했다고 기록했다.
배운 점: 제한만 걸면 팀원 작업이 관리자에게 몰릴 수 있다. 안전한 역할을 만드는 절차와 리뷰 창구도 함께 필요하다.
실제 기록 2 · 기존 계정을 코드 관리로 옮겼다
장혜리의 마이그레이션 글에서는 실제 AWS 사용자·그룹·정책을 조회하고 YAML 명단을 채운 뒤, 기존 리소스 40개를 Terraform state에 등록했다.
이후 plan에는 추가 16개, 변경 8개, 삭제 0개가 나타났다고 기록했다. 이는 코드와 기존 환경 사이의 차이를 확인한 결과다. 해당 글에서는 MFA 정책 등의 실제 적용 시점을 별도로 조율한다고 적었다.
후속 개선 과제
후속 계정·권한 정리에서는 FullAccess 정책과 CI apply 역할의 넓은 권한을 개선 대상으로 남겼다. 코드 관리 이후에도 업무에 필요한 범위로 권한을 줄이는 작업이 과제로 이어졌다.
배운 점
권한의 목적은 “못 하게 막기”만이 아니다. 필요한 일을 안전하게 수행하고, 누가 무엇을 바꿨는지 남기는 것까지 포함한다.
원문과 작성자
- IAM Terraform 마이그레이션 — 장혜리
- IAM 계정/권한 최종 정리 — 장혜리
