월요일 아침, 개발자가 배포가 안 된다며 AWS IAM 권한 설정하는 법을 묻는 상황이라면 먼저 관리자 권한을 통째로 주지 말아야 한다. 답은 간단하다. 사람에게는 로그인 수단을 연결하고, 실제 작업 권한은 역할과 정책으로 좁혀서 부여한다. 급할수록 이 순서가 중요하다.
권한 관리는 한 번 설정하고 끝나는 일이 아니다. 새 서비스가 붙고 담당자가 바뀌면 권한도 금방 낡는다. 초보 관리자라면 루트 사용자 보호, 업무용 로그인 분리, 최소 권한 정책, 검증과 기록 확인의 네 단계를 기준으로 잡으면 된다.
AWS IAM 권한 설정하는 법의 기본 구조
IAM은 AWS 리소스에 누가 어떤 작업을 어디까지 할지 정하는 서비스다. 사용자나 역할 같은 주체에 정책을 붙이고, 정책에는 허용하거나 거부할 작업과 대상 리소스를 적는다. 명시적 거부가 허용보다 우선한다. 이 원칙은 꼭 기억해야 한다.
직원용 접근은 AWS IAM Identity Center를 우선 검토하는 편이 관리하기 편하다. 사내 계정이나 외부 자격 증명 공급자와 연동해 사용자와 그룹을 관리하고, 여러 AWS 계정에 권한 세트를 배포하는 흐름에 맞기 때문이다. IAM 사용자는 접근 키가 필요한 자동화 계정이나 기존 구조를 유지해야 하는 경우에 제한해서 쓰는 편이 낫다.
| 방식 | 알맞은 대상 | 관리 기준 |
|---|---|---|
| IAM Identity Center | 직원, 운영자, 여러 계정 접근 | 그룹과 권한 세트로 부여 |
| IAM 사용자 | 제한된 기존 시스템, 예외적 자동화 | 개별 사용자와 접근 키를 정기 점검 |
| IAM 역할 | EC2, Lambda, 외부 계정, 임시 작업 | 신뢰 정책과 권한 정책을 분리 |
역할은 장기 접근 키를 서버나 소스 코드에 넣지 않게 해 준다. 예를 들어 Lambda가 S3 파일을 읽어야 한다면 Lambda 실행 역할에 필요한 S3 읽기 작업만 넣는다. 개발자 개인 키를 함수 설정에 넣는 방식은 피하는 편이 좋다.
설정 전에 정리할 세 가지
콘솔부터 열기 전에 업무 문장을 한 줄로 적는다. 예를 들면 운영팀은 운영 계정의 특정 S3 버킷에서 객체를 조회하고 내려받을 수 있으며 삭제는 불가처럼 쓴다. 짧지만 강력하다. 이 문장이 정책 범위를 정한다.
- 주체는 누가 쓰는지 정한다. 개인, 팀, 애플리케이션, 외부 협력사로 구분한다.
- 행위는 무엇을 하는지 적는다. 조회, 업로드, 배포, 삭제, 권한 변경은 분리한다.
- 대상은 어느 계정과 리전, 버킷, 테이블, 함수인지 좁힌다.
- 기간은 언제까지 필요한지 정한다. 일회성 작업에는 만료 시점과 회수 담당자를 남긴다.
관리자 권한이 필요한 사람도 일상 작업용 권한과 분리하는 편이 좋다. 평소에는 읽기나 운영 역할로 접속하고, 계정 구조를 바꾸는 작업에서만 별도 관리자 역할을 맡는 식이다. 권한 상승 절차를 팀 채널이나 승인 흐름에 남기면 나중에 이유를 확인하기 쉽다.
초보 관리자용 설정 순서
- 루트 사용자부터 보호한다. 루트 사용자는 다중 인증을 켜고 일상 업무에 쓰지 않는다. 루트 자격 증명, 복구 수단, 결제 알림 수신자는 조직의 보안 절차에 맞춰 별도로 관리한다.
- 사람과 시스템을 분리한다. 직원은 Identity Center 그룹 또는 조직 표준 로그인에 넣고, EC2나 Lambda 같은 워크로드에는 IAM 역할을 연결한다. 공유 계정은 책임 추적을 어렵게 만든다.
- 그룹 또는 권한 세트를 만든다. 개발 읽기 전용, 배포 담당, 운영 조회처럼 업무 이름으로 구분한다. 사람 이름을 권한 이름에 넣으면 인사 이동 때 관리가 꼬이기 쉽다.
- 관리형 정책을 출발점으로 삼되 그대로 끝내지 않는다. AWS 관리형 정책은 빠르지만 범위가 넓을 때가 있다. 초기 검증 뒤에는 필요한 Action과 Resource만 적은 고객 관리형 정책으로 줄인다.
- 역할의 신뢰 정책을 확인한다. 권한 정책이 무엇을 할지 정한다면 신뢰 정책은 누가 역할을 맡을지 정한다. 다른 AWS 계정이나 외부 인증 주체를 허용할 때 특히 신중히 좁혀야 한다.
- 테스트 계정에서 먼저 검증한다. 실제 사용자 계정이나 테스트 역할로 로그인해 필요한 작업과 차단돼야 할 작업을 모두 확인한 뒤 운영에 반영한다.
정책을 새로 만들 때 Resource에 별표를 넣는 순간 멈춰서 이유를 확인한다. 일부 서비스는 리소스 수준 권한을 지원하지 않아 별표가 필요할 수 있다. 그래도 Action은 읽기 작업으로 좁히고, 가능하면 리전이나 태그 조건을 더하는 방법을 검토해야 한다.
최소 권한 정책을 읽는 법
정책은 Effect, Action, Resource, Condition을 중심으로 읽는다. Effect는 Allow 또는 Deny이고 Action은 허용 작업, Resource는 대상 ARN이다. Condition은 요청 리전, 소스 IP, 태그, 다중 인증 여부처럼 추가 조건을 거는 자리다. 이름만 보고 적용하지 말자.
예를 들어 특정 버킷에서 파일 목록 확인과 다운로드만 필요하다면 버킷 목록 조회 작업과 객체 읽기 작업을 나눠야 한다. 버킷 자체 ARN과 버킷 안 객체 ARN의 형식도 다르다. 삭제 작업이나 버킷 정책 변경 작업을 넣지 않는 이유가 분명해진다.
권한 경계도 알아둘 만하다. 권한 경계는 IAM 사용자나 역할이 받을 수 있는 최대 권한을 제한하며, 권한을 새로 부여하지는 않는다. 여러 팀이 역할을 만들지만 중앙 보안팀이 상한선을 관리해야 하는 환경에서 유용하다. AWS Organizations를 쓰는 조직이라면 서비스 제어 정책도 계정 단위 상한선으로 작동하므로 함께 확인해야 한다.
배포 전 10분 점검
새 정책을 운영에 붙이기 전에는 아래 항목을 확인한다. 짧은 점검이 사고 대응 시간을 크게 줄인다.
- 사용자별 직접 연결 정책이 늘어나지 않았는지 확인한다.
- Action과 Resource에 불필요한 별표가 없는지 확인한다.
- 삭제, 권한 변경, 접근 키 생성 권한이 업무상 필요한지 재확인한다.
- 역할 신뢰 정책에 예상 밖 계정이나 주체가 없는지 본다.
- 정책 변경 전후의 승인 기록과 변경 목적을 남긴다.
- CloudTrail 같은 감사 기록 서비스가 필요한 계정과 리전에 켜져 있는지 조직 기준으로 확인한다.
콘솔의 IAM Access Analyzer 정책 검증 기능은 문법 문제나 보안상 주의할 구성을 찾는 데 도움을 준다. 다만 경고가 없다고 업무 권한이 적절하다는 뜻은 아니다. 실제 업무 시나리오로 로그인해 확인하고, 액세스 거부 오류가 나면 필요한 API 작업만 추가하는 방식으로 좁혀 가야 한다.
권한 회수 주기도 정해 둔다. 분기마다 한 번처럼 팀이 감당할 수 있는 주기를 정하고, 퇴사·부서 이동·프로젝트 종료 때는 즉시 검토 항목으로 넣는다. 마지막 접근 정보는 참고 자료가 되지만 사용 이력이 없다고 무조건 삭제하면 장애가 날 수 있다. 담당 서비스와 확인한 뒤 제거한다.
자주 묻는 질문
초보 관리자는 AdministratorAccess를 써도 되나?
초기 계정 설정이나 제한된 긴급 작업에서 필요할 때가 있지만 일상 권한으로 계속 주는 방식은 피하는 편이 낫다. 관리자 역할을 별도로 만들고 다중 인증, 승인 절차, 사용 기록 확인을 붙여서 필요한 때만 맡도록 설계한다.
IAM 사용자와 역할 중 무엇을 먼저 만들어야 하나?
사람의 콘솔 접근은 Identity Center 기반 그룹과 권한 세트를 먼저 검토하고, AWS 서비스가 다른 서비스에 접근해야 하면 역할을 먼저 만든다. 장기 접근 키가 꼭 필요한 기존 연동이 아니라면 IAM 사용자 생성부터 시작할 이유가 적다.
정책에 Resource 별표가 있으면 위험한가?
범위가 넓어질 가능성이 있어 확인이 필요하다. 서비스 특성상 필요한 경우도 있으므로 무조건 제거하지 말고, Action 축소와 Condition 추가로 통제할 방법이 있는지 살핀다. 적용 전에는 테스트 역할로 실제 동작을 확인한다.
권한 오류가 나면 어떤 순서로 확인하나?
요청한 API 작업, 대상 리소스 ARN, 로그인한 역할이나 사용자, 연결된 정책, 권한 경계와 조직 정책을 차례로 본다. 명시적 Deny가 있는지도 확인한다. 오류 메시지와 요청 시각을 남기면 운영 담당자가 감사 기록과 대조하기 수월하다.
협력사에 AWS 접근을 줘야 하면 계정을 공유해도 되나?
공유 로그인보다는 별도 주체와 기간 제한, 필요한 역할만 부여하는 구조가 추적과 회수에 유리하다. 외부 계정 역할 위임이나 연동 방식은 조직의 계정 구조와 계약 조건에 따라 달라지므로 보안·IT 담당 부서의 검토를 거쳐 정한다.
AWS IAM 권한 설정의 핵심은 빠르게 허용하는 일이 아니라 나중에 설명하고 회수할 수 있게 설계하는 일이다. 업무 문장으로 요구를 정리하고, 역할과 그룹으로 묶고, 좁은 정책을 테스트한 뒤 기록을 남기면 초보 관리자도 운영 기준을 세울 수 있다.
이 글은 일반적인 정보 제공과 참고 목적으로 작성되었으며, 법률 자문·보안 컨설팅·컴플라이언스 판단을 대체하지 않습니다. 소개하는 설정과 절차는 소프트웨어 버전이나 조직 환경에 따라 다르게 동작할 수 있으며, 어떤 보안 조치도 완전한 안전을 보장하지는 않습니다. 실제 적용 전에는 반드시 소속 조직의 정책과 담당 부서(보안·IT·법무)의 확인을 거치고, 중요한 시스템에는 백업과 사전 테스트 후 적용하시기 바랍니다. 규제 해석과 합법·불법 여부는 사안과 시점마다 달라질 수 있으므로 공식 규정과 전문가 상담으로 확인이 필요합니다. 본 사이트는 내용의 정확성과 최신성을 보장하지 않으며, 이 글의 내용을 적용하여 발생하는 어떠한 결과에 대해서도 책임을 지지 않습니다.