목차
- 클라우드 보안은 “방화벽”보다 “IAM”에서 무너진다
- IAM 권한 설계 실수를 막는 3대 원칙
- IAM 권한 설계 실수 TOP 10과 예방책 총정리
- TOP 1) Root/Owner 계정 남용 — IAM 권한 설계의 가장 치명적 실수
- TOP 2) “일단 Admin” (Owner/Contributor/Editor) 권한을 남발한다
- TOP 3) IAM 정책에 와일드카드(*)를 남발한다
- TOP 4) 장기 자격증명 방치 — 클라우드 보안 사각지대
- TOP 5) IAM 사용자에게 직접 권한을 붙이고 추적이 안 된다
- TOP 6) IAM 권한 스코프가 너무 넓다 (조직/구독 전체 부여)
- TOP 7) 크로스계정/외부 공유(Trust/Resource Policy)를 ‘대충’ 열어둔다
- TOP 8) 조직 차원의 “가드레일”이 없다 (계정/프로젝트가 제각각)
- TOP 9) IAM 서비스 계정이 뭉개져 있다 (하나로 다 쓴다)
- TOP 10) “정기 점검/검증”이 없다 (권한은 계속 쌓이는데, 줄이지 않는다)
- IAM 권한 설계 실무 템플릿 — 클라우드 보안 체계 잡기
- 1) 정체성(Identity)을 3종으로 분리
- 2) 인증 방식(“키” vs “임시 토큰”)을 먼저 결정
- 3) IAM 역할(Role) 설계는 “업무 단위”로
- 4) 스코프를 최대한 좁히고, 조건(Conditions)으로 한 번 더 잠근다
- 5) 가드레일(조직 정책) + 지속 검증(Analyzer/Logs)
- IAM 권한 설계 실수 점검 체크리스트 (15분 완성)
- IAM 권한 설계 FAQ
- Q1. 최소 권한(Least Privilege)은 “처음부터 완벽하게” 해야 하나요?
- Q2. 와일드카드(*)는 무조건 나쁜가요?
- Q3. AWS에서 권한을 줄이는 가장 빠른 방법은?
- Q4. GCP에서 서비스 계정 키 파일(JSON)을 깃헙에 올리면 왜 치명적인가요?
- Q5. GCP는 왜 Workload Identity Federation을 자꾸 권장하나요?
- Q6. Azure에서 PIM을 쓰면 뭐가 달라지나요?
- Q7. Azure에서 Managed Identity를 쓰는 이유는 뭔가요?
클라우드 보안은 “방화벽”보다 “IAM”에서 무너진다
IAM 권한 설계 실수는 클라우드 사고의 가장 흔한 시작점입니다. 취약한 서버가 아니라 과도한 권한이 문제의 근원이며, IAM을 대충 설계하면 다음과 같은 사고가 연쇄적으로 터집니다.
- 누군가의 계정/토큰이 유출 → 권한이 넓어서 피해가 커짐
- 임시로 준 Admin 권한이 회수되지 않음 → “영구 Admin”이 조직에 남음
- 와일드카드(*) 정책이 남발 → 신규 서비스가 추가되는 순간 권한이 자동 확장됨
- 서비스 계정 키가 깃헙에 들어감 → 조용히 장기 침투
그래서 오늘은 “이론” 말고, 현장에서 가장 자주 보는 IAM 설계 실수 TOP 10과 예방책을 정리합니다.
(AWS/Azure/GCP 공통으로 적용 가능하게 구성했어요.)
IAM 권한 설계 실수를 막는 3대 원칙
- 최소 권한(Least Privilege): “필요한 일만, 필요한 범위에서, 필요한 시간만”
- 장기 자격증명 금지(Short-lived 우선): 사람/워크로드 모두 임시 토큰 기반으로
- 가드레일 + 검증(Guardrails & Verification): “실수해도 망하지 않게” 조직/계정 레벨 안전장치 + 지속 점검
AWS는 IAM 보안 모범사례에서 사람은 IdP 연동(페더레이션)과 임시 자격증명, 워크로드는 IAM Role 기반 임시 자격증명을 권장하고, MFA/정기 리뷰/Access Analyzer 활용 등을 함께 제시합니다. (AWS Documentation)
IAM 권한 설계 실수 TOP 10과 예방책 총정리
아래 10개는 “사고 확률이 높고, 피해도 커지는” 조합입니다.
TOP 1) Root/Owner 계정 남용 — IAM 권한 설계의 가장 치명적 실수
왜 위험한가
- Root/Owner는 “마지막 열쇠”라서 탈취 시 방어가 거의 불가능해집니다.
- 특히 Root access key(프로그램 접근 키)가 존재하면 유출 리스크가 폭증합니다.
예방책
- AWS: Root 사용자 사용을 최소화하고, 멤버 계정이라면 루트 자격증명 제거/중앙화 같은 접근을 권장합니다. (AWS Documentation)
또한 AWS는 “루트 사용자 접근 키를 쓰지 말라”는 취지의 보안 가이드를 제공합니다. (AWS Documentation) - Azure: 최상위 권한(구독 Owner 등)을 “상시 보유”하지 말고, PIM으로 필요할 때만(JIT) 활성화하는 방식이 권장됩니다. (Microsoft Learn)
- GCP: Project Owner/Org Admin 같은 상위 권한을 최소화하고, 실제 운영은 역할 기반으로 분리(아래 TOP 2~3에서 이어짐)
바로 점검 질문: “지금 이 순간에도 누군가가 Root/Owner 권한을 ‘상시’ 들고 있나?”
TOP 2) “일단 Admin” (Owner/Contributor/Editor) 권한을 남발한다
왜 위험한가
- 계정이 털렸을 때 “한 기능만” 뚫린 게 아니라, 계정 전체가 뚫린 것처럼 전개됩니다.
- 최소 권한을 하지 않으면, 보안 사고의 피해 범위를 줄일 수 없습니다.
예방책
- AWS: 최소 권한을 권장하고(작업에 필요한 권한만), 성숙도에 따라 넓은 권한에서 점차 줄여가라고 안내합니다. (AWS Documentation)
- Azure: Azure RBAC 모범사례는 “구독 전체에 무제한 권한을 주지 말고, 필요한 범위(scope)에 필요한 역할만”을 명확히 권고합니다. (Microsoft Learn)
- Azure(추가 팁): 구독 Owner는 “최대 3명” 권고가 문서에 들어가 있을 정도로, 소수화가 핵심입니다. (Microsoft Learn)
- GCP: 서비스 계정/사용자에 Owner를 주기 전에 “업무별 역할(역할 묶음)”로 먼저 설계
바로 점검 질문: “Admin 권한이 없으면 일을 못 하는 사람이 몇 %인가?”
TOP 3) IAM 정책에 와일드카드(*)를 남발한다
왜 위험한가
- 현재뿐 아니라 미래의 서비스/기능까지 권한이 자동으로 열릴 수 있습니다.
- 특히 Resource
*는 “모든 리소스”를 의미할 수 있어 치명적입니다.
예방책
- AWS: Resource 요소에서 와일드카드 사용 시 ARN 세그먼트 내에서 쓰는 것을 권장하는 등, 와일드카드 사용에 주의를 줍니다. (AWS Documentation)
또한 일부 권한은Resource:"*"가 필요한 경우가 있지만, 필요한 경우에만 쓰라고 안내합니다. (AWS Documentation) - AWS(검증 도구): IAM Access Analyzer는 정책을 “IAM 정책 문법 + AWS 모범사례” 기준으로 검증해 경고/오류/제안 사항을 제공합니다. (AWS Documentation)
- Azure: Azure RBAC 문서에도 “커스텀 역할 만들 때 wildcard(*)를 피하고 Actions/DataActions를 명시하라”는 권고가 있습니다. (Microsoft Learn)
바로 점검 질문: “정책 JSON에서 *를 검색하면 몇 줄이 뜨나?”
TOP 4) 장기 자격증명 방치 — 클라우드 보안 사각지대
왜 위험한가
- 키는 유출돼도 티가 안 납니다. (침투자가 “정상 호출”처럼 쓰기 쉬움)
- 교체(로테이션) 체계가 없으면 유출 대응이 늦어집니다.
예방책
- AWS: 사람/워크로드 모두 IAM Role 기반 임시 자격증명을 권장합니다. (AWS Documentation)
- GCP: 서비스 계정 키는 “관리 가이드(키 회전/만료/유출 방지)”가 매우 구체적으로 제공됩니다(리포지토리에 올리지 말 것, 임시 위치에 두지 말 것, 정기 로테이션 등). (Google Cloud Documentation)
- GCP(가능하면 더 좋은 선택): Workload Identity Federation은 서비스 계정 키를 대체(키리스)하는 방향으로 소개됩니다. (Google Cloud)
- Azure: Managed Identity는 애플리케이션이 자격증명을 코드/설정에 저장하지 않도록 하는 방식으로 설명됩니다. (Microsoft Learn)
바로 점검 질문: “지난 90일 동안 회전(교체) 안 한 키가 존재하나?”
TOP 5) IAM 사용자에게 직접 권한을 붙이고 추적이 안 된다
왜 위험한가
- 인원 이동(입사/퇴사/프로젝트 종료) 때 권한 회수가 누락됩니다.
- 감사/추적이 어렵고, “왜 이 사람이 이 권한을 갖지?”가 계속 쌓입니다.
예방책
- AWS: IdP 연동(페더레이션)을 통한 접근을 권장합니다. (AWS Documentation)
- Azure: Azure RBAC 모범사례는 “사용자에게 직접 역할을 주지 말고, 그룹에 역할을 부여”하라고 권고합니다. (Microsoft Learn)
- Azure: 관리자 역할은 PIM으로 “필요할 때만 활성화(JIT)”가 핵심입니다. (Microsoft Learn)
바로 점검 질문: “개별 사용자에게 직접 붙은 역할(Direct assignment)이 몇 개인가?”
TOP 6) IAM 권한 스코프가 너무 넓다 (조직/구독 전체 부여)
왜 위험한가
- 뚫리면 “한 리소스”가 아니라 “전체 구독/프로젝트”가 위험해집니다.
- 실수(삭제/변경)도 범위가 커져서 장애로 직결됩니다.
예방책
- Azure: “넓은 스코프(관리그룹/구독) 대신 리소스 그룹/리소스처럼 좁은 스코프를 쓰라”는 권고가 문서에 명시돼 있습니다. (Microsoft Learn)
- AWS: 정책은 “어떤 Action을 어떤 Resource에 어떤 Condition으로 허용할지”로 최소 권한을 설계하라고 안내합니다. (AWS Documentation)
- GCP: 프로젝트 단위로 권한을 주기 쉬운데, 실제로는 폴더/조직 정책(가드레일)과 함께 “정말 필요한 범위만” 주는 습관이 중요
바로 점검 질문: “왜 이 권한이 ‘구독 전체’여야만 하지?”
TOP 7) 크로스계정/외부 공유(Trust/Resource Policy)를 ‘대충’ 열어둔다
왜 위험한가
- 내부 계정이 아니라 외부 계정/인터넷에서 접근 가능해질 수 있습니다.
- 특히 S3 같은 리소스 정책은 “퍼블릭/크로스계정 노출”로 바로 이어집니다.
예방책
- AWS: IAM Access Analyzer는 리소스에 대한 “외부(계정 밖) 접근 경로”를 찾아 보고하는 용도로 설명됩니다. (AWS Documentation)
- AWS: Access Analyzer는 S3 버킷 정책/ACL을 평가해 퍼블릭 또는 크로스계정 접근 가능 리소스를 식별한다고 AWS가 설명합니다. (Amazon Web Services, Inc.)
바로 점검 질문: “우리 리소스 중 ‘외부 계정’이 접근 가능한 게 무엇인지, 한 번이라도 Access Analyzer로 확인했나?”
TOP 8) 조직 차원의 “가드레일”이 없다 (계정/프로젝트가 제각각)
왜 위험한가
- 팀이 실수로 위험한 구성을 만들면, 보안팀이 사후에 뛰어다녀야 합니다.
- 멀티계정/멀티프로젝트가 되면 “사후 통제”는 거의 실패합니다.
예방책
- AWS: SCP(Service Control Policy)는 “권한을 부여하는 게 아니라, 조직 내 IAM 사용자/역할이 할 수 있는 행동에 상한(guardrail)을 두는 것”이라고 문서에서 정의합니다. (AWS Documentation)
SCP 예시는 “어떻게 제한할 수 있는지”만 보여주며, 실제 적용 전 충분한 테스트를 강조합니다. (AWS Documentation) - AWS: 계정 내부에서 “개발자가 권한을 만들 수 있게 위임”해야 한다면, Permissions Boundary로 최대 권한을 제한하는 패턴이 공식 문서/블로그에 소개됩니다. (AWS Documentation)
바로 점검 질문: “누군가 실수로 ‘모든 리전에 리소스 생성’/‘퍼블릭 공유’/‘Admin 부여’를 해도, 조직 차원에서 막히나?”
TOP 9) IAM 서비스 계정이 뭉개져 있다 (하나로 다 쓴다)
왜 위험한가
- 한 서비스 계정이 여러 시스템에 쓰이면, 침해 시 피해가 연쇄로 커집니다.
- “어떤 앱이 어떤 권한을 썼는지” 추적이 어려워집니다.
예방책
- AWS: 워크로드는 IAM Role 기반 임시 자격증명 사용을 권장합니다. (AWS Documentation)
- GCP(WIF): Workload Identity Federation 모범사례는 “과도한 설정은 권한 상승으로 이어질 수 있다”는 점을 경고하고, 서비스 계정과 접근 범위를 최소화하라고 안내합니다. (Google Cloud Documentation)
- Azure: Managed Identity를 활용해 “리소스(앱) 단위”로 권한을 분리하는 방향이 보안/운영 모두에 유리합니다. (Microsoft Learn)
바로 점검 질문: “이 서비스 계정(또는 MI/Role)이 ‘두 개 이상의 앱’에서 공유되고 있나?”
TOP 10) “정기 점검/검증”이 없다 (권한은 계속 쌓이는데, 줄이지 않는다)
왜 위험한가
- IAM은 시간이 지날수록 권한이 누적되는 시스템입니다.
- 정기적으로 “안 쓰는 권한/계정/키”를 제거하지 않으면, 침해 가능성이 계속 상승합니다.
예방책
- AWS: IAM 모범사례는 “사용하지 않는 사용자/역할/권한/정책/자격증명을 정기적으로 리뷰하고 제거”하라고 강조합니다. (AWS Documentation)
또한 Access Analyzer는 CloudTrail 접근 활동을 기반으로 “필요 권한만 담은 정책 템플릿 생성”을 지원한다고 안내합니다. (AWS Documentation) - AWS: 정책을 저장/배포하기 전 Access Analyzer로 정책 검증을 하라고 문서가 안내합니다. (AWS Documentation)
- Azure: PIM은 특권 권한을 “필요한 시간만” 활성화해 노출 시간을 줄이는 방식으로 소개됩니다. (Microsoft Learn)
- GCP: 서비스 계정 키는 “미사용 키 식별/로테이션/만료” 같은 운영 지침이 공식 문서로 제공됩니다. (Google Cloud Documentation)
바로 점검 질문: “권한 검토(Access review)를 마지막으로 한 게 언제인가?”
IAM 권한 설계 실무 템플릿 — 클라우드 보안 체계 잡기
1) 정체성(Identity)을 3종으로 분리
- 사람(Human): 직원/협력사
- 워크로드(Workload): 앱/배치/서버리스/컨테이너
- 외부(External): CI/CD, 파트너 시스템, SaaS 연동
2) 인증 방식(“키” vs “임시 토큰”)을 먼저 결정
- 사람: IdP 페더레이션 + MFA + (가능하면) JIT
- 워크로드: 클라우드 네이티브라면 Role/Managed Identity, 외부라면 Federation(WIF 등)
- GCP는 WIF로 서비스 계정 키를 줄이는 방향을 안내합니다. (Google Cloud)
3) IAM 역할(Role) 설계는 “업무 단위”로
IAM 권한 설계 실수를 줄이려면 역할 이름 자체가 업무 범위를 드러내야 합니다. 예: Billing-ReadOnly, App-Deploy, DB-Backup-Operator, Security-Audit
4) 스코프를 최대한 좁히고, 조건(Conditions)으로 한 번 더 잠근다
- Azure는 넓은 스코프 대신 좁은 스코프를 명시적으로 권장합니다. (Microsoft Learn)
5) 가드레일(조직 정책) + 지속 검증(Analyzer/Logs)
- AWS: SCP(조직 상한) + Permissions Boundary(계정 내부 위임 상한) + Access Analyzer(검증/탐지). 권한 설정과 함께 AWS 비용 폭탄 방지 체크리스트도 점검하면 보안·비용을 동시에 잡을 수 있습니다 (AWS Documentation)
- GCP: 퍼블릭 바인딩(allUsers/allAuthenticatedUsers) 차단 + 키 관리 정책 (Google Cloud Documentation)
IAM 권한 설계 실수 점검 체크리스트 (15분 완성)
- Root/Owner 계정 “상시 사용” 여부 확인 (Root 키 존재 여부 포함) (AWS Documentation)
- Admin/Owner/Contributor/Editor 역할 보유자 목록 뽑기 → “왜 필요한지” 적기 (Microsoft Learn)
- 정책에서
*검색(Action/Resource) → 예외(정당한 필요)만 남기기 (AWS Documentation) - 장기 키(Access Key/Service Account Key) 목록 + 마지막 사용일 확인 → 미사용 제거/회전 (AWS Documentation)
- (AWS) Access Analyzer로 퍼블릭/크로스계정 접근 리소스 확인 (AWS Documentation)
- (GCP) Cloud Storage IAM에서 allUsers/allAuthenticatedUsers 바인딩 여부 점검 (Google Cloud Documentation)
- (Azure) 구독 Owner 수, 광범위 스코프 역할 부여 여부 점검 (Microsoft Learn)
- (Azure) PIM으로 JIT 전환 가능한 관리자 역할부터 전환. 비용·보안을 통합 관리하려면 FinOps 실전 가이드도 함께 확인 (Microsoft Learn)
IAM 권한 설계 FAQ
Q1. 최소 권한(Least Privilege)은 “처음부터 완벽하게” 해야 하나요?
완벽할 필요는 없지만, IAM 권한 설계 실수를 줄이려면 방향은 반드시 최소 권한이어야 합니다. AWS도 초기에는 넓은 권한으로 시작할 수 있지만, 성숙해질수록 권한을 줄여 최소 권한으로 가라고 설명합니다. (AWS Documentation)
Q2. 와일드카드(*)는 무조건 나쁜가요?
“항상 나쁜 것”은 아니지만, 위험도가 커서 기본값으로 쓰면 사고가 납니다.
AWS는 Resource에 *가 필요한 권한이 일부 존재하지만, 필요한 경우에만 사용하라고 안내합니다. (AWS Documentation)
Azure도 커스텀 역할에서 wildcard 사용을 피하고 Actions/DataActions를 명시하라고 권고합니다. (Microsoft Learn)
Q3. AWS에서 권한을 줄이는 가장 빠른 방법은?
Access Analyzer의 “정책 검증”으로 위험한 정책을 잡고, CloudTrail 기반 “정책 생성”으로 실제 사용 권한에 맞게 줄이는 흐름이 현실적입니다. (AWS Documentation)
Q4. GCP에서 서비스 계정 키 파일(JSON)을 깃헙에 올리면 왜 치명적인가요?
서비스 계정 키는 그 자체로 인증 수단이며, 유출 시 해당 서비스 계정으로 API 호출이 가능해질 수 있습니다. Google Cloud는 키를 리포지토리에 올리지 말 것, 정기 회전/만료, 미사용 키 식별 등 구체적인 관리 지침을 제공합니다. (Google Cloud Documentation)
Q5. GCP는 왜 Workload Identity Federation을 자꾸 권장하나요?
키를 배포/보관/회전하는 부담을 줄이고, 외부 IdP 기반으로 단기 토큰을 쓰는 “키리스 접근”을 가능하게 하기 때문입니다. Google Cloud는 WIF가 서비스 계정 키를 대체할 수 있다고 설명합니다. (Google Cloud)
Q6. Azure에서 PIM을 쓰면 뭐가 달라지나요?
관리자 권한을 “상시 보유”하지 않고, 필요할 때만 시간 제한(JIT)으로 활성화해 특권 노출 시간을 줄이고 가시성을 높이는 방향입니다. Azure RBAC 모범사례와 Entra 역할 모범사례 모두 PIM을 권장합니다. (Microsoft Learn)
Q7. Azure에서 Managed Identity를 쓰는 이유는 뭔가요?
앱이 자격증명을 코드/설정에 저장하지 않게 만들어 “시크릿 유출” 리스크를 줄이는 방향입니다. Microsoft 문서에서도 Managed Identity로 Key Vault 등 리소스에 접근할 수 있다고 설명합니다. (Microsoft Learn)
 | AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매 |
함께 읽으면 좋은 글:
디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매