GWS로 우리 회사 AX 하는 법 무료 배포
AWS 계정 보안, 4가지 질문으로 점검하는 기본 체크리스트
인사이트
AWS 계정을 처음 만들던 날, 보안 설정까지 챙기셨나요?
대부분은 서버를 띄우고 서비스를 올리는 게 먼저입니다. 계정 보안은 "나중에 정리하자"며 미뤄두기 쉽죠. 하지만 클라우드에서는 계정 하나로 서버와 데이터베이스, 스토리지까지 모두 다룹니다. 계정 하나가 뚫리면 그 안의 모든 것이 위험해진다는 뜻입니다. 과금 폭탄, 데이터 유출, 리소스 삭제가 한꺼번에 터질 수도 있습니다.
다행히 계정 보안의 기본은 아래 네 가지 질문만으로 점검할 수 있습니다. 우리 회사는 이 중 몇 개에 바로 "괜찮다"고 답할 수 있을지 세어 보세요. 질문마다 왜 중요한지, 지금 무엇을 하면 되는지도 차례로 정리했습니다.
- 루트 사용자, MFA 없이 쓰고 있지 않나요?
- IAM 사용자 하나를 여러 명이 같이 쓰고 있지 않나요?
- 모든 사용자에게 Admin 권한을 주고 있지 않나요?
- 액세스 키가 외부로 새고 있지 않나요?
- 네 가지 항목 한눈에 점검하기
루트 사용자, MFA 없이 쓰고 있지 않나요?
루트 사용자는 AWS 계정을 처음 만들 때 입력한 이메일 주소와 비밀번호로 로그인하는 자격 증명입니다. 모든 서비스와 리소스는 물론 결제 정보까지 다룰 수 있는, 계정에서 가장 큰 권한을 가진 사용자죠.
그만큼 이메일과 비밀번호만 유출돼도 공격자는 계정을 통째로 조작할 수 있습니다. 리소스를 마음대로 만들어 과금을 일으키거나, 데이터를 빼낸 뒤 지워버릴 수도 있습니다. 권한이 가장 큰 계정이니, 가장 덜 써야 하는 계정이기도 합니다.
이렇게 점검하세요
☑️ 루트 사용자에 MFA(다중 인증)를 등록하셨나요?
현재 AWS는 모든 계정 유형의 루트 사용자에 MFA 설정을 요구하고, 첫 로그인 시도 후 35일 안에 등록하도록 하고 있습니다. 기기는 최대 8개까지 등록할 수 있으니 분실에 대비해 2개 이상 등록해 두시기 바랍니다.
☑️ 루트 사용자의 액세스 키가 남아 있지 않나요?
루트 액세스 키가 유출되면 CLI와 API로 계정 전체를 다룰 수 있게 됩니다. 처음부터 만들지 않는 게 원칙이고, 이미 있다면 삭제합니다.
☑️ 복구 수단에 접근할 수 있나요?
MFA 기기를 모두 잃어버렸을 때는 루트 이메일 수신함과 계정에 등록된 전화번호로 본인 확인을 합니다. 퇴사자 메일이나 예전 번호로 남아 있지 않은지 확인해보세요.
MFA 기기는 휴대폰 앱으로 6자리 코드를 만드는 가상 인증 앱, 같은 코드를 생성하는 전용 기기인 하드웨어 토큰, 지문이나 안면 인식으로 인증하는 패스키 중에서 고를 수 있습니다.
루트 계정으로 로그인한 뒤, 우측 상단 계정 메뉴의 '보안 자격 증명'에서 멀티 팩터 인증 영역을 찾아 MFA 디바이스를 할당하면 됩니다.
Root 계정으로 로그인
우상단 계정 메뉴 내 보안 자격 증명 진입 및 멀티 팩터 인증 영역 확인
멀티 팩터 인증 영역 내 MFA 디바이스 할당 진입 및 MFA 생성과 등록
↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)
계정 하나를 여러 명이 함께 쓰고 있지 않나요?
루트 사용자를 일상 업무에 쓰지 않으려면, 그 대신 쓸 사용자가 필요합니다. 이 역할을 하는 게 IAM(Identity and Access Management)입니다.
IAM은 AWS 리소스에 대한 접근을 제어하는 서비스로, 두 가지를 관리합니다. 누가 로그인할 수 있는지를 정하는 인증(Authentication), 그리고 로그인한 사용자가 무엇을 할 수 있는지를 정하는 권한 부여(Authorization)입니다. 별도 비용 없이 쓸 수 있으니 계정을 만든 날 바로 설정해두는 게 좋습니다.
IAM 사용자가 AWS에 접근하는 방식은 두 가지로 나뉩니다.
- 콘솔 접근
- 자격 증명: 사용자 이름 + 비밀번호 (+ MFA)
- 쓰는 곳: 웹 브라우저의 AWS Management Console
- 프로그래밍 방식 접근
- 자격 증명: 액세스 키 ID + 시크릿 액세스 키
- 쓰는 곳: AWS CLI, SDK, API 호출
계정 하나를 여러 명이 돌려 쓰면 누가 무엇을 했는지 추적할 수 없습니다. 한 명이 퇴사하거나 비밀번호가 새어 나가면, 함께 쓰던 모두의 접근 정보를 한꺼번에 바꿔야 하죠. 사용자를 나눠두면 문제가 생긴 사용자 한 명만 막으면 됩니다.
이렇게 점검하세요
☑️ 한 사람당 IAM 사용자 하나를 쓰고 있나요?
자격 증명은 팀원끼리도 공유하지 않습니다.
☑️ 권한을 그룹 단위로 주고 있나요?
개발, 운영, 재무처럼 역할별 그룹을 만들고 사용자를 그룹에 넣으면 입·퇴사 때 관리가 훨씬 쉬워집니다.
☑️ IAM 사용자에게도 MFA가 적용돼 있나요?
MFA는 루트만의 일이 아닙니다.
☑️ 쓰지 않는 사용자와 자격 증명이 남아 있지 않나요?
IAM 콘솔의 '마지막 액세스' 정보를 보면 오래 쓰지 않은 사용자와 액세스 키를 찾을 수 있습니다.
↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)
모든 사용자에게 Admin 권한을 주고 있지 않나요?
사용자를 나눴다면 다음은 권한입니다. 원칙은 단순합니다. 업무에 필요한 권한만 주는 것, 흔히 최소 권한 원칙이라고 부르는 방식이죠.
그런데 실무에서는 권한 오류를 피하려고 사용자를 만들 때마다 AdministratorAccess 정책을 붙여두는 경우가 많습니다. 이 정책을 열어보면 내용은 이렇습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Action과 Resource가 모두 “*”입니다. 모든 서비스의 모든 작업을, 모든 리소스에 허용한다는 뜻입니다.
이 권한을 가진 사용자의 비밀번호나 액세스 키가 유출되면 피해 범위는 계정 전체가 됩니다. 반면 특정 S3 버킷의 읽기 권한만 가진 사용자라면, 키가 새어 나가도 피해는 그 버킷을 읽는 데서 그칩니다.
권한의 크기가 곧 사고의 크기입니다.
예를 들어 특정 S3 버킷의 파일을 읽기만 하는 애플리케이션이라면, 아래 정도의 권한이면 충분합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::my-app-bucket",
"arn:aws:s3:::my-app-bucket/*"
]
}
]
}이렇게 점검하세요
☑️ AWS 관리형 정책으로 시작하고 있나요?
ReadOnlyAccess나 직무별 관리형 정책처럼 이미 만들어진 정책을 먼저 활용하면 출발이 쉽습니다.
☑️ 고객 관리형 정책으로 범위를 좁혀가고 있나요?
AWS 관리형 정책은 모든 고객을 위해 만들어진 것이라, 우리 회사 용도에는 넓을 수 있습니다. 실제로 쓰는 작업과 리소스만 남긴 정책을 직접 만들어 교체합니다.
☑️ IAM Access Analyzer를 써보셨나요?
CloudTrail에 기록된 실제 사용 내역을 바탕으로, 필요한 권한만 담은 정책을 생성해줍니다.
☑️ 안 쓰는 권한을 주기적으로 회수하고 있나요?
'마지막 액세스' 정보에서 오래 쓰지 않은 권한을 찾아 정리합니다.
☑️ 관리자 권한은 소수에게만 있나요?
꼭 필요한 담당자에게만 주고, 이 사용자에게는 MFA를 반드시 적용합니다.처음부터 완벽한 최소 권한을 설계하기는 어렵습니다. 넓게 시작했더라도 사용 내역을 보며 조금씩 줄여가는 과정이 더 중요합니다.
↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)
액세스 키가 공개 저장소에 올라가 있지 않나요?
CLI나 SDK로 AWS를 다루려면 액세스 키가 필요한데요. 이 키를 .env, .yaml, .config 같은 설정 파일에 적어둔 채 GitHub나 Bitbucket의 공개 저장소에 그대로 푸시하는 경우가 생각보다 많습니다. 계정 유출 사고에서 가장 자주 보이는 경로이기도 합니다.
예를 들어 # .env - 이 파일이 공개 저장소에 올라가면 사고입니다
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY특히 놓치기 쉬운 게 Git 히스토리입니다. 나중에 파일을 지우고 다시 커밋해도, 이전 커밋에는 키가 그대로 남아 있습니다. 한 번이라도 공개 저장소에 올라간 키는 이미 유출된 것으로 봐야 합니다.
예방: 이렇게 점검하세요
☑️ 액세스 키 없이 쓸 방법을 먼저 찾아보셨나요?
EC2나 Lambda 같은 AWS 컴퓨팅 리소스에 IAM 역할을 연결하면 임시 자격 증명이 자동으로 전달됩니다. 코드에 키를 넣을 필요 자체가 없어지죠.
☑️ 비밀 값을 AWS Secrets Manager에 보관하고 있나요?
DB 비밀번호나 외부 API 키는 코드에 적지 않고 Secrets Manager에 저장한 뒤, 애플리케이션이 실행 시점에 불러오도록 합니다. SDK 호출 몇 줄이면 충분합니다.
☑️ .gitignore에 설정 파일을 등록해뒀나요?
.env처럼 비밀 값이 들어가는 파일은 처음부터 Git 추적 대상에서 빼둡니다.
☑️ 푸시 전에 키를 검사하고 있나요?
GitHub의 푸시 보호(push protection)나 git-secrets 같은 도구를 쓰면 커밋에 섞인 키 패턴을 찾아 경고해줍니다.
☑️ 쓰지 않는 액세스 키를 정리하고 있나요?
미사용 키는 비활성화한 뒤 삭제하고, 꼭 필요한 키는 담당자가 바뀔 때처럼 필요한 시점에 교체합니다.
이미 노출됐다면
- 해당 액세스 키를 즉시 비활성화하고, 새 키로 교체한 뒤 기존 키를 삭제합니다.
- CloudTrail에서 그 키의 사용 내역을 확인합니다. 관리 이벤트는 기본으로 최근 90일치가 기록됩니다.
- 모르는 리소스가 생기지 않았는지, IAM 사용자와 역할, 청구 내역까지 함께 확인합니다.
- AWS Support 케이스로 안내를 받아 후속 조치를 진행합니다.
AWS도 자체 안전장치를 두고 있습니다. GitHub 시크릿 스캐닝과 연동해 공개 저장소에서 키가 발견되면, 해당 IAM 사용자에 AWSCompromisedKeyQuarantine 정책을 자동으로 붙이고 이메일과 Support 케이스로 알려주죠.
다만 이 정책은 위험한 작업 일부만 막을 뿐, 키 자체는 여전히 유효합니다. 교체와 삭제는 직접 해야 한다는 점을 꼭 기억해두세요!
액세스 키 삭제는 IAM 콘솔에서 키가 있는 사용자를 선택한 뒤, '보안 자격 증명' 탭의 액세스 키 영역에서 진행합니다.
IAM 내 IAM 사용자 중 액세스 키 존재 사용자 선택
보안 자격 증명 내 액세스 키 영역 중 삭제 작업 선택
↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)
[참고] Bedrock 같은 생성형 AI 서비스의 키가 새어 나가면 피해가 얼마나 빨리 커지는지 궁금하다면?
👉 늘어나는 Bedrock 해킹 사고, 우리 AWS 계정은 안전한가요?
4가지 질문, 한눈에 점검하기
지금까지 살펴본 내용을 질문과 정답, 핵심 조치로 다시 정리했습니다.
☑️ 루트 사용자를 MFA 없이 사용하고 있나요?
정답: 아니요
루트에 MFA 등록, 루트 액세스 키 삭제, 일상 작업에 루트 사용 금지
☑️ 계정 내 IAM 사용자를 만들어 쓰고 있나요?
정답: 예
한 사람당 사용자 하나, 그룹 단위 권한, 전원 MFA
☑️ 모든 사용자에게 Admin 권한이 있나요?
정답: 아니요
최소 권한 부여, 미사용 권한 주기적 회수
☑️ 자격 증명이 외부 저장소에 공개돼 있나요?
정답: 아니요
IAM 역할과 Secrets Manager 사용, 미사용 키 삭제, 푸시 전 검사
네 가지 모두 계정을 만든 날 바로 적용할 수 있는 항목입니다. 하나라도 놓친 게 있다면 오늘 아래 순서대로 확인해보세요.
- 루트 사용자에 MFA가 등록돼 있는지 확인
2. 루트 사용자의 액세스 키가 있다면 삭제
3. 일상 작업용 IAM 사용자를 따로 만들고 MFA 적용
4. AdministratorAccess가 붙은 사용자 목록을 확인하고 축소
5. 오래 쓰지 않은 액세스 키를 비활성화한 뒤 삭제
6. 저장소에 .env 같은 설정 파일이 올라가 있지 않은지 검색
계정 보안은 한 번 설정하고 끝나는 일이 아닙니다. 사람이 늘고 서비스가 늘면 사용자와 권한도 함께 늘어나기 때문에, 분기에 한 번 정도는 같은 체크리스트로 다시 점검하는 게 안전합니다.
여기까지 읽고 나면 "우리 계정은 지금 몇 개나 통과할까" 궁금해지실 텐데요. 막상 IAM 사용자와 정책을 하나씩 열어보면, 누가 언제 만든 건지 알 수 없는 사용자나 용도가 불분명한 키가 생각보다 많이 나옵니다.
파이브클라우드는 AWS 계정의 루트·IAM 설정과 권한 구조를 함께 점검하고, 우리 회사 조직 구조에 맞는 권한 체계를 설계해 드립니다. 설정 이후에도 이상 징후를 빠르게 알아차릴 수 있도록 알림 체계까지 이어서 지원합니다.
[참고] 보안 설정 이후, 이상 징후를 놓치지 않고 바로 통보받는 방법이 궁금하다면?
👉 상주 관제 없이 하는 AWS 운영, 월 5만 원부터 가능한 이유
