빌드업웍스
클라우드 보안 사고로 이어지는 설정 실수에는 어떤 것이 많습니까
AWS를 쓰기 시작한 지 몇 년이 지나 계정과 리소스가 늘어난 회사에서, 외부 공격보다 내부 설정 실수가 더 걱정된다며 어디부터 점검해야 하는지 묻는 경우가 많습니다. 담당자가 여러 번 바뀌어 누가 왜 그렇게 설정했는지 모르는 리소스가 쌓인 환경에서 특히 자주 나오는 질문입니다.
빌드업웍스 답변
빌드업웍스 엔지니어핵심 답변
클라우드에서 반복해서 지적되는 설정 실수는 외부에 공개된 저장소, 필요 이상으로 넓은 권한, 코드나 설정 파일에 남은 장기 액세스 키, 인터넷 전체에 열린 관리 포트, MFA 없는 관리자 계정입니다. 공통점은 서비스가 정상적으로 동작하는 상태라 사고가 나기 전까지 드러나지 않는다는 것입니다. 계정 단위 공개 차단, 임시 자격 증명, 최소 권한을 기본값으로 두고 예외는 사유와 함께 기록하는 방식이 효과적입니다.
- 설정 실수는 정상 동작하기 때문에 드러나지 않습니다
- S3 공개 차단은 버킷만이 아니라 계정 단위로도 겁니다
- 사람과 애플리케이션 모두 임시 자격 증명을 기본으로 합니다
- 키가 노출되면 삭제보다 비활성화와 사용 기록 조회가 먼저입니다
설정 실수가 오래 남는 이유
외부 공격은 흔적을 남기지만 설정 실수는 서비스가 정상적으로 돌아가는 상태로 남습니다. 테스트 때문에 잠시 공개한 저장소, 급하게 붙인 관리자 권한, 임시로 열어 둔 원격 접속 포트는 모두 「잘 동작하는」 설정이라 아무도 다시 보지 않습니다. 미국 CISA와 NSA가 2023년 발표한 10대 보안 설정 오류도 기본 설정을 그대로 쓰는 것, 사용자·관리자 권한 분리 미흡, 약하거나 잘못 설정된 MFA, 허술한 자격 증명 관리처럼 새로운 공격 기법이 아니라 기본값과 관리 습관에서 비롯되는 항목이 여럿 들어 있습니다.
클라우드는 여기에 속도가 더해집니다. 콘솔에서 몇 번 클릭하면 리소스가 생기고, 만든 사람이 떠나도 리소스는 남습니다. 그래서 점검의 출발점은 개별 리소스가 아니라 계정 전체에 적용되는 기본값입니다. 리소스를 하나씩 확인하는 점검은 리소스가 늘어나는 속도를 따라가지 못하지만, 계정 단위 기본값은 앞으로 만들어질 리소스까지 함께 보호합니다. 리소스마다 만든 사람과 용도를 태그로 남기게 하는 규칙도 이 단계에서 함께 정해 두면, 나중에 「이 설정은 왜 이렇게 돼 있는가」를 묻는 시간이 줄어듭니다.
반복해서 지적되는 다섯 가지
| 유형 | 생기는 경위 | 확인 방법 |
|---|---|---|
| 외부에 공개된 저장소·스냅샷 | 파일 공유나 정적 웹 호스팅을 위해 공개 후 방치 | S3 계정 단위 공개 차단 설정, IAM Access Analyzer의 공개 접근 발견 항목 |
| 필요 이상으로 넓은 권한 | 처음에 넓게 주고 줄이지 않음 | 마지막 접근 정보로 쓰지 않는 권한 확인 |
| 코드·설정 파일에 남은 장기 액세스 키 | 개발 편의로 키를 파일에 넣고 저장소에 올림 | 저장소 비밀 정보 탐지, 키별 마지막 사용 시각 |
| 인터넷 전체에 열린 관리 포트 | 원격 작업을 위해 SSH·RDP·DB 포트를 전체 개방 | 보안 그룹의 0.0.0.0/0 허용 규칙 목록 |
| MFA 없는 루트·관리자 계정 | 초기 설정 담당자가 MFA 없이 사용 | 계정별 MFA 등록 현황 보고서 |
S3는 새로 만든 버킷과 객체가 기본적으로 공개되지 않지만, 버킷 정책이나 ACL을 바꾸면 공개할 수 있습니다. AWS는 네 가지 공개 차단 설정을 계정 단위로 모두 켜는 것을 권장하고, 각 버킷에도 같은 설정을 켜 두라고 덧붙입니다. S3는 계정과 버킷 설정 중 더 엄격한 쪽을 적용하므로, 버킷 단위로만 걸어 두면 버킷 권한을 가진 사람이 그 설정을 풀어 공개할 수 있지만 계정 단위로 걸어 두면 버킷 설정만 바꿔서는 공개되지 않습니다. 정적 웹사이트처럼 공개가 꼭 필요한 버킷은 예외로 두되 사유를 기록합니다.
KISA도 2026년 4월 보안 권고에서 외부에 열린 시스템 현황을 파악해 불필요한 연결을 차단하고, 22·1433·3389 같은 기본 서비스 포트 사용을 피하며, 외부 접속이 필요하면 접속 IP·단말 제한과 다중 인증을 적용하라고 권고했습니다.
어디부터 고치나
권한 축소가 「어려움」 칸에 있는 이유는 실제 호출 기록을 보지 않고 줄이면 서비스가 멈추기 때문입니다. AWS도 넓은 권한으로 시작했다면 사용 기록을 바탕으로 최소 권한으로 줄여 가라고 권하고, IAM Access Analyzer로 실제 활동 기반의 정책을 생성하는 방법을 제시합니다. 사람이 쓰는 계정은 통합 로그인으로 임시 자격 증명을 받게 하고, 애플리케이션은 IAM 역할을 쓰게 하는 것이 AWS의 기본 권장 사항입니다.
계정이 여럿이라면 개별 계정을 하나씩 고치기보다 조직 단위 안전장치를 먼저 거는 편이 효과가 오래갑니다. AWS는 AWS Organizations의 서비스 제어 정책(SCP)과 리소스 제어 정책(RCP)으로 여러 계정에 공통 권한 한계를 두라고 권합니다. 예를 들어 「계정 단위 공개 차단 설정을 끄는 행위」나 「감사 로그를 중지하는 행위」를 조직 정책으로 막아 두면, 어느 계정의 관리자가 실수하더라도 그 설정은 풀리지 않습니다. 이런 안전장치는 권한을 주는 장치가 아니라 넘지 못하는 선을 긋는 장치이므로, 실제 권한은 각 계정의 정책으로 따로 부여해야 합니다.
점검은 한 번으로 끝나지 않습니다. 리소스는 계속 생기고 담당자도 바뀌므로, 공개 차단·MFA·관리 포트처럼 기준이 분명한 항목은 AWS Security Hub 같은 도구의 자동 점검 결과로 상시 확인하고, 예외 목록은 정해진 주기로 사람이 다시 검토하는 구조가 현실적입니다.
액세스 키가 노출됐을 때
- 비활성화삭제보다 먼저 끕니다. 영향을 확인하면서 되돌릴 수 있습니다.
- 사용 기록 조회CloudTrail에서 그 키로 언제 무엇을 호출했는지 확인합니다.
- 생성된 리소스 확인모든 리전에서 새로 생긴 인스턴스·사용자·키·역할을 찾습니다.
- 대체와 삭제임시 자격 증명이나 새 키로 교체한 뒤 노출된 키를 삭제합니다.
- 재발 방지저장소 푸시 단계에서 비밀 정보를 차단하는 설정을 켭니다.
저장소 이력에서 키를 지우는 것만으로는 부족합니다. 이미 복제되거나 수집됐을 수 있으므로 키 자체를 무효화하는 것이 먼저입니다. GitHub의 푸시 보호(push protection)는 사용자 계정 기준으로 공개 저장소에 비밀 정보를 올리는 것을 기본적으로 막지만, 저장소 단위 설정은 기본적으로 꺼져 있어 관리자가 직접 켜야 합니다.
참고 자료
이어서 보기
보안 자주 받는 질문
퇴사자 계정과 권한은 무엇부터 어떤 순서로 정리해야 합니까
퇴사자 권한 정리는 계정 하나를 막는 일이 아니라 그 사람이 알고 있거나 그 사람 이름에 묶인 접근 수단 전체를 끊는 일입니다. 순서는 통합 로그인(SSO) 차단, 개인 이름으로 발급된 액세스 키·API 토큰 교체, 공유 계정 비밀번호와 MFA 기기 회수, 권한 변경 내역 보관입니다. 개인정보처리시스템이라면 안전성 확보조치 기준이 권한을 지체 없이 변경·말소하고 그 내역을 최소 3년간 보관하도록 정합니다.
답변 2026-10-22
보안 자주 받는 질문
OTP로 다단계 인증을 쓰고 있는데 패스키로 바꿔야 합니까
OTP나 문자처럼 사람이 코드를 옮겨 입력하는 방식은 가짜 로그인 화면에도 그대로 입력될 수 있어 피싱을 막지 못합니다. 패스키(FIDO2)는 인증이 접속한 사이트의 도메인에 묶여 있어 이 공격을 구조적으로 막으므로, 클라우드 콘솔·통합 로그인(SSO)·관리자 계정부터 우선 전환하는 것이 효과가 큽니다. 전환할 때는 기기 분실에 대비해 계정마다 인증 수단을 두 개 이상 등록하고 복구 절차를 함께 정해야 합니다.
답변 2026-10-22
보안 자주 받는 질문
ISMS-P 인증을 준비할 때 클라우드에서는 무엇부터 해야 합니까
ISMS-P 준비에서 클라우드 기술 조치는 운영 기록이 쌓여야 증적이 되므로 정책 문서와 함께, 가능하면 먼저 시작하는 편이 유리합니다. 인증 고시는 인증기준에 따른 관리체계를 구축해 최소 2개월 이상 운영한 뒤 신청하도록 정하고 있어, 계정·권한 정리, 감사 로그와 개인정보 접속기록, 암호화, 백업·복구, 취약점 관리를 그 전에 갖춰 두어야 합니다. AWS가 받은 인증은 클라우드 인프라 자체의 보안을 다루며, 고객 계정 안의 설정과 운영은 인증을 받는 기업이 갖춰야 합니다.
답변 2026-10-22
함께 보면 좋은 자료AWS 앞에 Cloudflare를 둘 때의 확인 사항함께 보면 좋은 자료웹사이트 기술·보안 상태 확인 도구함께 보면 좋은 자료1분 보안 태세 자가 점검댓글
답변에 덧붙일 질문이나 경험을 남겨 주세요. 빌드업웍스가 확인한 뒤 게시합니다.
댓글을 불러오는 중입니다.
궁금한 점을 편하게 남겨 주세요
영업 연락은 드리지 않습니다. 빌드업웍스 엔지니어가 영업일 2~3일 안에 답변드리고, 카카오톡·텔레그램 채팅으로도 상담하실 수 있습니다.