AWS 인프라를 운영하면서 보안 점검을 형식적으로 넘기다가 나중에 감사에서 지적 받는 경우를 실무에서 자주 봅니다. 서비스마다 점검 포인트가 다르고 놓치기 쉬운 기본 설정들이 있습니다. 이 글에서는 EC2, S3, RDS, EKS 네 가지 핵심 서비스를 중심으로 보안 설정 검토 시 실제로 확인해야 할 항목을 정리합니다.
AWS 보안 점검의 핵심은 서비스별 기본 설정값을 맹신하지 않는 것입니다. EC2는 네트워크 접근 제어, S3는 버킷 정책과 퍼블릭 접근 차단, RDS는 암호화와 접근 경로, EKS는 IAM 연동과 파드 권한이 각각의 핵심 검토 지점입니다.
AWS 보안 점검이 왜 서비스별로 달라야 하는가
AWS는 공동 책임 모델을 채택하고 있습니다. 인프라 자체의 보안은 AWS가 맡지만, 그 위에서 어떤 설정을 하느냐는 전적으로 사용자 책임입니다. 문제는 서비스마다 기본값과 위험 지점이 완전히 다르다는 점입니다. EC2에서 중요한 게 보안그룹이라면, S3에서 중요한 건 버킷 정책이고, RDS에서는 네트워크 격리, EKS에서는 IAM과 RBAC 연동이 핵심입니다.
실무에서 보면 이 네 가지를 하나의 체크리스트로 뭉뚱그려 점검하다가 정작 중요한 항목을 놓치는 경우가 많습니다. 서비스별로 점검 프레임을 분리하는 것이 첫 단추입니다.
EC2 보안 설정 검토 항목
EC2에서 가장 먼저 확인할 것은 보안그룹입니다. 인바운드 규칙에 0.0.0.0/0으로 열려 있는 포트가 있는지, 특히 22번과 3389번이 전체 공개로 열려 있지 않은지 확인해야 합니다. 이건 기본 중의 기본인데도 실제 점검에서 가장 많이 발견되는 항목입니다.
그다음으로는 IAM 인스턴스 프로파일 권한 범위, EBS 볼륨 암호화 여부, IMDSv2 강제 적용 여부를 봐야 합니다. IMDSv1이 여전히 활성화되어 있으면 SSRF 취약점을 통한 자격 증명 탈취 경로가 열려 있는 셈이라 이 부분이 핵심입니다. 많이들 여기서 막히더라고요. IMDSv2로 전환하려면 기존 애플리케이션 코드에서 메타데이터 호출 방식을 수정해야 하는데, 이 작업을 미루다가 보안 점검 때마다 같은 지적을 반복해서 받는 경우가 흔합니다.
| 점검 항목 | 확인 내용 | 위험도 |
|---|---|---|
| 보안그룹 인바운드 | 0.0.0.0/0 전체 공개 포트 존재 여부 | 높음 |
| IMDSv2 강제 적용 | 메타데이터 서비스 버전 설정 | 높음 |
| IAM 인스턴스 프로파일 | 최소 권한 원칙 준수 여부 | 중간 |
| EBS 볼륨 암호화 | 저장 데이터 암호화 활성화 여부 | 중간 |
| SSM 세션 매니저 활용 | SSH 키 노출 없이 접속 가능한지 | 중간 |
S3 보안 설정 검토 항목
S3는 퍼블릭 접근 차단 설정부터 확인합니다. 계정 레벨과 버킷 레벨 둘 다에서 퍼블릭 액세스 차단이 켜져 있는지 봐야 하는데, 둘 중 하나만 켜져 있고 다른 하나가 꺼져 있어서 실제로는 공개된 버킷이 나오는 경우가 생각보다 많습니다.
버킷 정책과 ACL도 별도로 봐야 합니다. 정책은 막혀 있는데 개별 객체 ACL이 퍼블릭으로 설정된 사례도 실무에서 종종 나옵니다. 이건 직접 겪어보면 체감되는데, 자동화 스크립트로 대량 업로드하는 파이프라인에서 ACL 기본값을 퍼블릭으로 잡아둔 채 몇 달간 방치되는 경우가 있습니다. 서버 측 암호화(SSE-S3 또는 SSE-KMS) 적용 여부, 버킷 정책의 최소 권한 여부, 액세스 로깅 활성화 여부도 함께 확인해야 합니다.
실무 팁: AWS Config의 s3-bucket-public-read-prohibited 규칙과 s3-bucket-public-write-prohibited 규칙을 상시 모니터링으로 걸어두면, 설정 변경이 발생하는 즉시 알림을 받을 수 있습니다. 수동 점검보다 훨씬 안정적입니다.
RDS 보안 설정 검토 항목
RDS는 퍼블릭 액세스 가능 여부부터 확인해야 합니다. 퍼블릭 액세스가 켜져 있으면 인터넷에서 데이터베이스 엔드포인트로 직접 접근이 가능한 구조가 되므로, 대부분의 운영 환경에서는 이 옵션을 꺼두고 VPC 내부에서만 접근하도록 구성해야 합니다.
암호화는 저장 시점과 전송 시점을 나눠서 봐야 합니다. 저장 데이터 암호화는 인스턴스 생성 시점에만 설정할 수 있어서, 이미 암호화 없이 운영 중인 인스턴스는 스냅샷을 통해 재생성하는 절차가 필요합니다. 전송 구간은 SSL/TLS 강제 여부를 파라미터 그룹에서 확인합니다. 보안그룹은 애플리케이션 서버의 특정 보안그룹에서만 접근 가능하도록 제한하는 것이 원칙이고, 자동 백업 보존 기간과 스냅샷 공유 설정도 함께 점검 대상입니다.
초보자와 실무자의 차이가 여기서 드러납니다. 초보자는 퍼블릭 액세스만 꺼두면 끝났다고 생각하지만, 실무자는 스냅샷이 실수로 퍼블릭 공유되지 않았는지, 파라미터 그룹의 로깅 설정이 감사 요구사항을 충족하는지까지 함께 확인합니다.
EKS 보안 설정 검토 항목
EKS는 네 가지 서비스 중 가장 복잡합니다. 먼저 클러스터 엔드포인트 접근 제어를 확인해야 합니다. 퍼블릭 엔드포인트가 무제한으로 열려 있는지, IP 화이트리스트가 걸려 있는지부터 봅니다.
그다음은 IAM과 쿠버네티스 RBAC의 연동 구조입니다. aws-auth 컨피그맵에 불필요하게 광범위한 권한이 매핑되어 있지 않은지, 파드가 사용하는 서비스 어카운트에 IRSA(IAM Roles for Service Accounts)가 적용되어 있는지가 핵심입니다. IRSA 없이 노드 IAM 역할을 파드가 그대로 상속받는 구조라면, 파드 하나가 뚫렸을 때 노드 전체 권한이 노출되는 셈이라 위험도가 높습니다.
네트워크 정책도 빠지지 않고 봐야 합니다. 기본적으로 쿠버네티스는 파드 간 통신을 전부 허용하기 때문에, 네임스페이스 단위로 네트워크 정책을 걸어두지 않으면 하나의 파드가 손상됐을 때 클러스터 전체로 이동이 가능해집니다. Secrets 암호화 설정(envelope encryption), 컨테이너 이미지 스캔 여부도 함께 확인 대상입니다.
실무에서 흔히 하는 오해와 교정
가장 흔한 오해는 “보안그룹만 잘 잠그면 안전하다”는 인식입니다. 네트워크 계층 통제는 여러 방어선 중 하나일 뿐이고, IAM 권한 설계나 암호화 설정이 허술하면 네트워크가 막혀 있어도 내부자 위협이나 자격 증명 탈취에는 무력합니다.
두 번째 오해는 “AWS 기본값이니까 안전할 것”이라는 믿음입니다. AWS는 편의성과 보안 사이에서 기본값을 균형점에 맞춰두는 경우가 많아서, 실제 운영 환경의 위험 수준에 맞추려면 대부분 추가 강화 설정이 필요합니다. 이 부분이 핵심입니다. 기본값을 그대로 두는 것과 검토 후 의도적으로 유지하는 것은 완전히 다른 이야기입니다.
서비스 통합 점검 체크리스트
정기 점검 시 아래 항목을 서비스별로 순회하면서 확인하는 것을 권장합니다.
- EC2 보안그룹에 0.0.0.0/0 전체 공개 인바운드 규칙이 없는가
- EC2 인스턴스가 IMDSv2를 강제 적용하고 있는가
- S3 버킷의 퍼블릭 액세스 차단이 계정과 버킷 레벨 모두 켜져 있는가
- S3 버킷에 서버 측 암호화가 적용되어 있는가
- RDS 인스턴스의 퍼블릭 액세스가 비활성화되어 있는가
- RDS 스냅샷이 실수로 퍼블릭 공유되지 않았는가
- EKS 클러스터 엔드포인트 접근이 제한되어 있는가
- EKS 파드가 IRSA를 통해 최소 권한으로 IAM을 사용하는가
- 모든 서비스에 대해 AWS Config 규칙 또는 Security Hub 알림이 설정되어 있는가
지금 바로 할 수 있는 일 하나는, AWS Security Hub 또는 Trusted Advisor를 열어서 위 체크리스트 항목 중 경고 표시가 뜨는 부분이 있는지 확인해보는 것입니다. 생각보다 오래 방치된 항목이 나올 수 있습니다.
여러분 조직에서는 EC2, S3, RDS, EKS 중 어떤 서비스의 보안 점검이 가장 까다로우셨나요? IAM 권한 설계는 어떤 기준으로 최소 권한 원칙을 적용하고 계신지도 댓글로 공유해주시면 좋겠습니다.
다음 글 추천: “AWS IAM 정책 설계 시 최소 권한 원칙 적용 방법”, “AWS Security Hub와 GuardDuty 연동 운영 가이드”
본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.