보안 계정을 처음부터 다시 설계했습니다.
Summary
불편한 SSH 포트는 안녕! Okta와 Transit Gateway로 설계한 Zero Trust 보안 아키텍처
인증, 네트워크, 서버 접근 통제 기준을 단 하나의 전용 보안 계정으로 단일화해 나가는 인프라팀의 리빌딩 여정
다중 AWS 계정 체계에서 파편화된 권한과 접근 경로 문제를 풀기 위해, 전용 보안 계정을 기반으로 인프라 보안 구조를 제로 트러스트(Zero Trust) 관점에서 재설계했습니다. Transit Gateway 허브-스포크 통합 네트워크부터 시작해 Okta Single Sign-On 및 불변 이미지 OS 도입까지, 개발자에게는 더 넓은 권한을 안전하게 위임하고 위협 요인은 원천 통제하는 기술적 성취를 보여줍니다.
- 01VPC 간의 직접 피어링(Peering)이나 개별 베스천(Bastion) 대신 Transit Gateway 허브-스포크 구조를 채택해 관리 확장성 확보
- 02개발 및 운영 환경 전반에서 개인별 IAM 사용자와 개별 VPN 계정을 완전히 제거하고, Okta SSO와 다중 인증(MFA) 하나로 관문 통합
- 03프로덕션 서버 내의 SSH 포트를 영구 폐지하고, 인프라팀의 필수 정비 작업에 한해서만 SSM 감사 로그 기반으로 접근하도록 예외화 처리
- 04루트 파일시스템이 읽기 전용인 Bottlerocket OS를 Karpenter와 조합하여 사용함으로써 서버 내 정적 관리 필요성 자체를 소멸
- 05인증부터 최종 조작까지의 실시간 로깅을 보장하는 구조(CloudTrail, QueryPie 등)를 완성하여 인프라 소유권 기반의 자율 배포 체계 실현
RECOMMENDATION
안전한 AWS 멀티 어카운트 거버넌스를 구축하고자 하는 시니어 데브옵스 엔지니어와 CISO에게 적극 권장합니다. 망 전환 시 일괄 교정보다는 허브-스포크 네트워크 영향 범위를 단계적으로 좁혀가며 순차 배포하는 실무적 교훈을 제공합니다.
The Problem
AWS 계정이 늘어나면서 인증, 네트워크, 서버 접근 방식이 개별적으로 관리되어 권한 매핑 파악과 보안 감사에 어려움이 발생했습니다. 특정 리소스에 접근할 때마다 인프라 담당자가 권한을 개별적으로 검토하고 임시 가동해야 하는 병목 현상이 발생하여 ISMS 심사에서도 구조적 개선 지적을 받았습니다.
The Solution
기존 운영 워크로드와 격리된 전용 보안 계정을 신설하고, 이를 네트워크·인증·배포의 통제 기준면으로 설정했습니다. Transit Gateway를 허브로 삼아 VPC들을 스포크 형태로 통합하고, Okta SSO, QueryPie, AWS Systems Manager(SSM), Bottlerocket OS를 도입하여 사람이 서버에 직접 진입하는 경로를 원천 폐지했습니다.
The Result
개인 엔지니어용 IAM 사용자 계정 54개를 전면 폐지하고 11개 앱의 인증을 단일 SSO로 전환했으며, 111개의 DB 연결 및 52명의 사용자를 단일 경로에서 안전하게 통제할 수 있게 되었습니다. 또한 전사 인프라 접근 이력이 실시간 감사 로그(CloudTrail, QueryPie, SSM)로 확보되어 안전한 소유권 기반 권한 위임이 가능해졌습니다.
Trade-off
새로운 허브-스포크 구조로 전환하는 과정에서 테스트 계정의 내부망 라우팅 및 이름 해석이 어긋나는 구간이 생겼으나, 설계된 계정 경계를 바탕으로 서비스 프로덕션 외부에서 한정적으로 제어하며 극복했습니다. 아울러 아직 모든 내부 도구가 하나의 관문으로 이관된 것은 아니어서 레거시 클러스터 이전 및 권한 위임 세분화 작업을 순차적으로 풀어가야 하는 부하가 존재합니다.
