IAM 권한 설계, 관리자 계정 하나로 운영하지 않기

누가 어떤 일을 하는지부터 권한을 나눕니다

IAM 권한은 편의를 위해 모든 사람에게 관리자를 주기보다 업무에 필요한 행동을 기준으로 나눕니다. 사람이 콘솔에서 하는 작업과 프로그램이 실행 중 수행하는 작업도 구분합니다. AWS 공식 문서는 최소 권한과 임시 자격 증명 활용을 보안 모범 사례로 안내합니다. 1단계로 배포, 로그 조회, 비용 확인, 데이터 관리 같은 업무와 담당자를 적습니다. 단순 조회 담당자에게 자원 삭제 권한까지 줄 이유는 없습니다. 그렇다고 필요한 업무가 불가능할 만큼 좁힌 뒤 매번 임시 관리자 권한을 공유해서도 안 됩니다. 실제 작업 목록을 기준으로 역할을 만들고 허용된 작업이 정상 동작하는지 시험하면서 조정합니다.

장기 키를 배포 파일에 넣지 않습니다

2단계는 프로그램이 자격 증명을 얻는 경로를 점검하는 것입니다. 소스 코드나 이미지에 장기 접근 키를 넣으면 저장소 복제본과 배포 산출물로 퍼질 수 있습니다. 실행 환경에서 역할과 임시 자격 증명을 받을 수 있는지 먼저 검토합니다. 비밀값은 적절한 저장소와 접근 정책으로 관리하고 로그에 출력되지 않게 합니다. 키를 바꾸는 작업은 새 키를 발급하는 것으로 끝나지 않습니다. 서비스를 새 자격 증명으로 전환하고 정상 동작을 확인한 뒤 이전 키의 사용을 중지해야 합니다. 노출이 의심되는 경우에는 영향 범위 조사와 자격 증명 폐기를 함께 진행하되 운영 중단 여부를 고려한 대응 절차를 마련해 둡니다.

권한 범위를 가상 업무 목록으로 비교합니다

예를 들어 가상의 배포 작업이 산출물 읽기, 새 버전 등록, 상태 조회라는 3개 행동만 필요하다고 놓겠습니다. 편의상 자원 생성·삭제를 포함한 10개 행동을 허용했다면 목록 기준으로 10−3=7개 행동이 업무 목적과 직접 연결되지 않습니다. 이 계산은 IAM 정책의 위험도를 정량화한 점수가 아니며 실제 API 권한 수와도 다릅니다. 의존 권한이나 자원 정책 때문에 필요한 범위가 달라질 수 있습니다. 최종 행동은 불필요한 권한을 무작정 일괄 제거하는 것이 아니라 시험 환경에서 배포 흐름을 실행하며 필요한 행동과 자원을 확인하는 것입니다. 정상 경로뿐 아니라 실패 후 되돌리기에 필요한 권한도 함께 점검합니다.

퇴사와 비상 상황까지 운영 절차에 넣습니다

3단계는 계정 생명주기와 비상 접근을 정하는 것입니다. 신규 담당자의 접근 승인, 역할 변경, 퇴사 시 회수, 사용하지 않는 자격 증명 점검을 반복 가능한 절차로 만듭니다. 다중 요소 인증을 적용하고 계정을 공유하지 않으면 작업 기록의 책임자를 구분하기 쉬워집니다. 비상용 접근은 보관과 사용 기록, 사용 후 검토 방법을 명시합니다. 권한을 줄였다는 사실만으로 안전하다고 결론내리지 말고 실제 정책의 적용 결과와 접근 기록을 확인합니다. 최종 문서에는 역할별 업무, 승인자, 만료 또는 재검토 조건을 남깁니다. 서비스가 바뀌었는데 예전 권한이 계속 남지 않도록 배포와 조직 변경을 권한 검토의 계기로 연결합니다.

서버 운영 실행 전 점검표

• 사람과 프로그램의 접근을 나눴다
• 업무에 필요한 역할을 시험했다
• 장기 키가 코드와 로그에 없는지 점검했다
• 접근 회수와 비상 절차를 정했다