안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
AWS를 처음 도입한 기업들이 가장 많이 놓치는 것이 있습니다.
바로 IAM(Identity and Access Management)입니다.
EC2 서버도 만들고, S3도 쓰고, 비용 최적화도 고민합니다. 그런데 정작 "누가 AWS에 접근할 수 있는가"에 대한 설계는 뒤로 미루는 경우가 많습니다.
하지만 AWS 보안 사고의 상당수는 외부 해킹이 아니라 잘못 설정된 IAM 권한에서 시작됩니다.
IAM은 한 문장으로 정리됩니다.
"누가, 무엇에, 어디까지 접근할 수 있는지를 제어하는 시스템"
현실 세계로 비유하면 이렇습니다.
회사 건물에 들어오는 사람마다 출입증이 다릅니다. 경비원은 로비만, 개발자는 서버실만, 임원은 전층 접근 가능. IAM은 AWS에서 이 출입 체계를 만드는 도구입니다.
IAM이 제어하는 대상은 크게 세 가지입니다.
✔ 사용자(User) — AWS 콘솔에 로그인하는 사람 ✔ 역할(Role) — EC2, Lambda 같은 서비스에 부여하는 권한 ✔ 그룹(Group) — 여러 사용자를 묶어 권한을 일괄 적용
많은 기업이 이런 실수를 합니다.
"일단 모든 권한 주고, 나중에 정리하자"
AWS 초기 설정 시 루트 계정(Root Account)에서 모든 작업을 처리하고, 팀원 전체에게 AdministratorAccess를 부여하는 방식입니다.
이 구조의 문제는 명확합니다.
✔ 퇴사자의 계정이 살아있으면 → 외부에서 접근 가능 ✔ 개발자 계정이 탈취되면 → 전체 인프라가 노출 ✔ 실수로 S3 버킷 삭제 시 → 복구 불가
실제로 AWS 보안 침해 사례의 상당수는 외부 공격이 아니라 유출된 Access Key 하나로 시작됩니다.
IAM의 가장 중요한 원칙입니다.
필요한 것만, 필요한 만큼만 허용한다
예를 들어 S3 버킷에 파일을 업로드하는 서비스라면 S3 전체 권한이 아니라 특정 버킷의 업로드 권한만 부여해야 합니다.
✔ 너무 많은 권한 → 사고 발생 시 피해 범위 커짐 ✔ 딱 필요한 권한 → 사고 발생해도 피해 최소화
권한을 정의하는 JSON 문서입니다. "어떤 서비스의, 어떤 작업을, 어떤 리소스에 허용/거부"를 명시합니다.
AWS가 미리 만들어둔 관리형 정책을 쓰거나 직접 인라인 정책을 작성할 수 있습니다.
처음에는 AWS 관리형 정책으로 시작하고, 운영이 안정되면 커스텀 정책으로 세분화하는 방식을 권장합니다.
사람이 아닌 서비스에 부여하는 권한입니다.
예를 들어: EC2 서버가 S3에서 파일을 읽어야 한다면 → EC2에 S3 읽기 권한이 있는 Role을 붙여줍니다.
Access Key를 서버에 직접 넣는 방식은 Key 유출 시 치명적입니다. Role을 사용하면 Key 없이도 안전하게 권한을 부여할 수 있습니다.
AWS 계정 생성 시 만들어지는 루트 계정은 모든 권한을 가진 최고 관리자 계정입니다.
이 계정으로 일상적인 작업을 하면 안 됩니다. MFA(다중 인증)를 설정하고, 실제 업무는 IAM 사용자 계정으로 처리해야 합니다.
팀원 5명이 계정 하나를 공유하는 구조는 위험합니다. 누가 무슨 작업을 했는지 추적이 불가능하기 때문입니다.
1인 1계정 원칙을 지켜야 CloudTrail 로그에서 책임 추적이 가능합니다.
Access Key는 유출되는 순간 끝입니다. GitHub에 실수로 올라간 Key 하나로 수천만 원의 과금이 발생한 사례가 실제로 있습니다.
가능하면 EC2 Role, Lambda 실행 Role 등으로 대체하고, 불가피하게 써야 한다면 주기적으로 교체하고 사용하지 않는 Key는 즉시 삭제해야 합니다.
이전 글에서 소개한 제로 트러스트 보안의 핵심은 "아무도 믿지 말고, 항상 검증하라" 였습니다.
IAM은 이 원칙을 AWS 안에서 실현하는 도구입니다.
✔ 네트워크가 아니라 아이덴티티로 접근을 제어 ✔ 한 번 인증했다고 끝이 아니라 권한 범위로 다시 제한 ✔ 로그로 모든 접근 행위를 기록
IAM이 제대로 설계되어 있어야 GuardDuty, CloudTrail, AWS Organizations 같은 보안 서비스들도 제대로 작동합니다.
IAM 없이 AWS 보안을 논하는 것은 기초 없이 건물을 짓는 것과 같습니다.
IAM은 복잡해 보이지만 핵심은 단순합니다.
최소한의 권한을, 필요한 사람에게만, 역할로 부여한다
이 원칙 하나만 지켜도 AWS 보안 사고의 상당수를 예방할 수 있습니다.
클라우드를 도입했다면 IAM 설계는 선택이 아닙니다. 가장 먼저 해야 하는 일입니다.
🔍 이런 기업에 필요합니다