클라우드에서 사고는 대부분 “권한”에서 시작합니다. AWS의 접근 제어를 어떻게 다루는지 정리해 둘게요.
루트 사용자는 금고에 넣어두기
루트 사용자(Root user) 는 계정을 만들 때 생기는, 전체 권한을 가진 최상위 사용자입니다. 그만큼 위험해서 일상 작업에는 절대 쓰면 안 됩니다.
- 비밀번호를 강력하게 설정하고, 암호와 액세스 키를 철저히 관리합니다.
- 루트 사용자의 액세스 키는 쓰지 않는다면 삭제하는 편이 안전합니다.
- MFA(다중 인증) 를 켜서 이중 보안을 구성합니다.
일상 작업은 뒤에 나올 IAM 사용자로 하고, 루트는 정말 필요할 때만 꺼내 쓰는 게 원칙입니다.
IAM: 세분화된 권한 관리
IAM (Identity and Access Management) 은 AWS 계정과 리소스에 대한 접근을 관리하는 서비스입니다. 어떤 사용자가 어떤 리소스에 무엇을 할 수 있는지 아주 세밀하게 허용하거나 거부할 수 있어요.
핵심은 최소 권한 원칙입니다. 필요한 만큼만 주고, 나머지는 막습니다.
IAM 그룹으로 관리 단순화
사용자가 늘어나면 개인별로 권한을 다는 건 금방 관리가 안 됩니다. IAM 그룹은 사용자의 모음이고, 그룹에 부여한 권한은 그룹에 속한 모든 사용자에게 상속됩니다.
예를 들어 “개발자” 그룹에 필요한 권한을 묶어두고 새 팀원을 그룹에 넣기만 하면, 권한이 자동으로 적용됩니다. 사람마다 일일이 설정하는 것보다 훨씬 깔끔하고 실수도 줄어듭니다.
Organizations: 여러 계정을 하나로
규모가 커지면 계정 자체가 여러 개가 됩니다. AWS Organizations 는 이런 계정들을 통합 관리하는 서비스입니다.
- 멤버 계정을 새로 만들거나 기존 계정을 초대해 하나의 조직으로 묶습니다.
- OU (Organizational Unit, 조직 단위) 라는 논리 그룹으로 계정을 묶어, 접근·규정 준수·보안 제어와 리소스 공유를 관리합니다.
- 여러 계정의 결제를 하나로 묶는 통합 결제에도 씁니다.
IAM과 헷갈리기 쉬운데, 차이는 대상에 있습니다. IAM은 계정 안의 “사용자”를 다루고, Organizations는 “AWS 계정” 자체를 다룹니다. 그리고 Organizations의 정책(SCP 등)이 IAM 정책보다 우선순위가 높아, 조직 차원에서 막아둔 것은 계정 안에서 아무리 허용해도 열리지 않습니다.
정리
권한 설계는 이 순서로 생각하면 편합니다.
- 루트는 잠가두고 MFA를 건다
- 일상 작업은 IAM 사용자·그룹으로, 최소 권한만 부여한다
- 계정이 여러 개면 Organizations로 묶고, 조직 정책으로 큰 울타리를 친다
권한은 “편하게”보다 “안전하게”가 항상 먼저입니다.