AWS 리드·아키텍트 보안 면접
새 면접Q. 글로벌 서비스를 운영 중인데, 여러 AWS 계정과 온프레미스 시스템이 혼재된 환경에서 통합 인증/인가 체계를 구축해야 합니다. AWS IAM Identity Center, Cognito, 자체 IdP 등 다양한 옵션이 있을 때, 어떤 기준으로 아키텍처를 설계하시겠습니까? 각 솔루션의 적합한 사용 사례와 함께 설명해주세요.
사용자 유형(내부 직원, 외부 고객, B2B 파트너)과 인증 주체(사람, 애플리케이션, 서비스)를 구분해서 생각해보세요.
먼저 사용자 유형을 구분합니다. 내부 직원의 AWS 리소스 접근은 IAM Identity Center를 통해 SSO를 구현하고, 기존 Active Directory나 Okta와 SAML 연동합니다. 외부 고객의 모바일/웹 애플리케이션 인증은 Cognito User Pool을 사용하여 확장 가능한 사용자 관리를 구현합니다. B2B 파트너나 서비스 간 인증은 OAuth 2.0 기반 자체 IdP를 구축하거나 API Gateway + Lambda Authorizer를 활용합니다. 크로스 계정 접근은 IAM Role의 AssumeRole을 통해 처리하고, 세밀한 권한 제어가 필요한 경우 ABAC(Attribute-Based Access Control)를 적용합니다. 온프레미스와의 통합은 AWS Directory Service나 AD Connector를 통해 하이브리드 환경을 구성하며, 모든 인증 이벤트는 CloudTrail과 EventBridge로 중앙 집중식 감사 로그를 구축합니다.
- • 사용자 유형별로 적합한 인증 솔루션 선택 (내부직원-IAM Identity Center, 외부고객-Cognito, B2B-자체IdP)
- • 크로스 계정 접근은 IAM Role AssumeRole로 처리하고 ABAC으로 세밀한 권한 제어
- • 하이브리드 환경은 Directory Service로 통합하고 모든 인증 이벤트를 중앙 집중식으로 감사
MSA 환경에서 수십 개의 마이크로서비스와 여러 AWS 계정을 운영할 때 통합 인증 체계 설계에 활용됩니다.
만약 컴플라이언스 요구사항으로 모든 인증 정보를 한국 리전에만 저장해야 한다면, Cognito의 글로벌 특성을 고려할 때 어떻게 아키텍처를 조정하시겠습니까?
Q. 금융 서비스를 AWS에서 구축 중인데, 개인정보와 금융정보를 저장하는 RDS, S3, DynamoDB에 대해 암호화 전략을 수립해야 합니다. KMS의 Customer Managed Key와 AWS Managed Key의 선택 기준, 키 로테이션 정책, 그리고 애플리케이션 레벨 암호화(Client-side)와 서버 레벨 암호화(Server-side)의 trade-off를 설명하고, 어떤 데이터에 어떤 방식을 적용할지 판단 기준을 제시해주세요.
컴플라이언스 요구사항, 성능 영향, 키 관리 복잡도, 감사 추적 필요성을 고려해보세요.
Customer Managed Key(CMK)는 키 정책 제어, 로테이션 시점 결정, 크로스 리전 복제가 필요한 경우 사용하며, AWS Managed Key는 관리 부담이 적지만 자동 로테이션만 가능하고 키 정책 수정이 불가능합니다. 금융정보나 주민등록번호 같은 고민감 데이터는 애플리케이션 레벨에서 Envelope Encryption을 적용하여 데이터 키를 KMS로 관리하고, AWS 관리자도 평문을 볼 수 없도록 합니다. RDS와 S3는 저장 시 암호화(Encryption at Rest)를 CMK로 활성화하고, 전송 중 암호화(Encryption in Transit)는 TLS 1.3을 강제합니다. DynamoDB는 테이블 단위로 CMK를 적용하되, 쿼리 성능이 중요한 인덱스 키는 암호화하지 않고 민감 속성만 클라이언트 측에서 암호화합니다. 키 로테이션은 CMK 자동 로테이션(1년)을 활성화하되, 규제 요구사항에 따라 수동 로테이션 프로세스도 준비하고, 모든 키 사용 내역은 CloudTrail로 감사합니다. 비용과 복잡도를 고려하여 일반 로그나 비민감 데이터는 AWS Managed Key를 사용합니다.
- • 고민감 데이터는 CMK + Envelope Encryption으로 애플리케이션 레벨 암호화 적용
- • 저장 시 암호화와 전송 중 암호화를 모두 적용하되, 성능이 중요한 인덱스는 선택적 암호화
- • 키 로테이션은 자동화하되 규제 대응을 위한 수동 프로세스 준비, CloudTrail로 전체 감사
금융권이나 헬스케어 서비스에서 개인정보보호법과 산업별 규제를 준수하면서 데이터를 안전하게 저장할 때 필수적입니다.
만약 GDPR의 '잊혀질 권리' 요구사항을 충족하기 위해 특정 사용자의 데이터만 복호화 불가능하게 만들어야 한다면, 암호화 키 구조를 어떻게 설계하시겠습니까?
Q. CloudFront와 ALB를 사용하는 웹 서비스에서 DDoS 공격, SQL Injection, XSS 등의 위협을 방어하기 위한 다층 보안 아키텍처를 설계해야 합니다. AWS WAF, Shield, Security Group, NACL 등을 어떻게 조합하여 배치하고, 각 레이어에서 어떤 룰을 적용할지 설명해주세요.
네트워크 레이어부터 애플리케이션 레이어까지 각 계층에서 방어할 수 있는 공격 유형을 구분해보세요.
가장 외곽에 CloudFront를 두고 Shield Standard를 자동 활성화하여 L3/L4 DDoS를 방어하며, 대규모 서비스는 Shield Advanced를 적용해 DDoS Response Team 지원을 받습니다. CloudFront에 WAF를 연결하여 지리적 차단, Rate Limiting, IP Reputation List를 적용하고, Managed Rule Group으로 OWASP Top 10 공격을 방어합니다. ALB 레벨에서도 WAF를 추가로 적용하여 SQL Injection과 XSS 패턴을 탐지하고, Custom Rule로 비즈니스 로직 기반 공격을 차단합니다. Security Group은 ALB에서 EC2로의 특정 포트만 허용하는 화이트리스트 방식으로 구성하고, NACL은 서브넷 레벨에서 알려진 악성 IP 대역을 블랙리스트로 차단합니다. 모든 WAF 로그는 Kinesis Data Firehose를 통해 S3에 저장하고 Athena로 분석하며, GuardDuty를 활성화하여 이상 행동을 탐지합니다. API 엔드포인트는 API Gateway의 Throttling과 Usage Plan으로 추가 보호합니다.
- • CloudFront + Shield로 DDoS 방어, WAF Managed Rule로 OWASP Top 10 차단
- • ALB와 CloudFront 양쪽에 WAF를 적용하여 다층 방어, Custom Rule로 비즈니스 로직 보호
- • Security Group 화이트리스트, NACL 블랙리스트 조합, GuardDuty로 이상 탐지 자동화
이커머스나 금융 서비스처럼 공격 표적이 되기 쉬운 대규모 웹 서비스의 보안 아키텍처 설계에 활용됩니다.
WAF의 Managed Rule이 정상 트래픽을 오탐지하여 차단하는 경우가 발생한다면, 어떤 프로세스로 룰을 튜닝하고 false positive를 줄이시겠습니까?
Q. 글로벌 SaaS 서비스를 운영하면서 GDPR, CCPA, 한국 개인정보보호법을 모두 준수해야 하는 상황입니다. 데이터 레지던시, 개인정보 처리 동의, 접근 로그, 데이터 삭제 요청 등을 AWS 아키텍처 레벨에서 어떻게 구현하고 관리하시겠습니까? 특히 크로스 리전 데이터 동기화가 필요한 경우의 컴플라이언스 리스크 관리 방안을 포함해주세요.
데이터의 물리적 위치, 접근 권한, 감사 추적, 자동화된 삭제 프로세스를 각각 어떻게 구현할지 생각해보세요.
먼저 데이터 레지던시를 위해 리전별로 독립된 AWS 계정을 구성하고, EU 사용자 데이터는 프랑크푸르트 리전, 미국은 버지니아, 한국은 서울 리전에만 저장합니다. S3 Bucket Policy와 SCP(Service Control Policy)로 데이터가 리전 외부로 복제되지 않도록 강제하고, VPC Endpoint를 사용해 인터넷을 거치지 않고 AWS 서비스에 접근합니다. 개인정보 처리 동의는 DynamoDB에 동의 이력을 타임스탬프와 함께 저장하고, 동의 범위에 따라 IAM Policy와 S3 Bucket Policy를 동적으로 적용합니다. 모든 개인정보 접근은 CloudTrail과 VPC Flow Logs로 기록하고, AWS Config로 암호화 설정과 퍼블릭 액세스 차단을 지속적으로 검증합니다. 데이터 삭제 요청은 Step Functions로 오케스트레이션하여 RDS, S3, Elasticsearch, 백업까지 모든 저장소에서 삭제하고, Lambda로 삭제 완료 증명서를 자동 생성합니다. 크로스 리전 동기화가 필요한 경우 DynamoDB Global Table 대신 이벤트 기반 복제를 구현하여 민감 정보는 제외하고, AWS Artifact에서 컴플라이언스 보고서를 정기적으로 다운로드하여 감사에 대비합니다.
- • 리전별 독립 계정 구성, SCP와 Bucket Policy로 데이터 레지던시 강제
- • 동의 이력 저장 및 동의 범위 기반 동적 권한 제어, CloudTrail과 Config로 지속적 감사
- • Step Functions로 다중 저장소 삭제 자동화, 크로스 리전 복제 시 민감정보 제외
글로벌 서비스를 운영하면서 각국의 개인정보보호 규제를 동시에 준수해야 하는 기업의 컴플라이언스 아키텍처 구축에 필수적입니다.
만약 규제 당국의 감사 요청으로 특정 기간의 모든 개인정보 접근 이력을 48시간 내에 제출해야 한다면, 어떤 로그 아키텍처와 쿼리 전략을 준비해두시겠습니까?
Q. 마이크로서비스 아키텍처에서 수십 개의 서비스가 데이터베이스 자격증명, API 키, 인증서 등 다양한 시크릿을 사용합니다. AWS Secrets Manager, Systems Manager Parameter Store, 환경변수 등 여러 방법이 있을 때, 어떤 기준으로 선택하고 어떻게 안전하게 배포 및 로테이션하시겠습니까? 특히 ECS/EKS 환경에서의 구현 방안을 설명해주세요.
시크릿의 민감도, 로테이션 필요성, 비용, 그리고 컨테이너 환경에서의 주입 방법을 고려해보세요.
데이터베이스 자격증명처럼 주기적 로테이션이 필요한 고민감 시크릿은 Secrets Manager를 사용하고, Lambda 함수로 자동 로테이션을 구성합니다. 변경 빈도가 낮은 설정값이나 비민감 정보는 Parameter Store의 무료 티어를 활용하되, 민감한 파라미터는 SecureString으로 KMS 암호화합니다. 환경변수에 시크릿을 직접 저장하는 것은 절대 금지하고, ECS Task Definition에서 secrets 필드를 사용해 Secrets Manager나 Parameter Store를 참조합니다. EKS에서는 External Secrets Operator를 배포하여 Secrets Manager의 값을 Kubernetes Secret으로 자동 동기화하고, IRSA(IAM Roles for Service Accounts)로 Pod별 세밀한 권한을 부여합니다. 모든 시크릿 접근은 IAM Policy로 최소 권한 원칙을 적용하고, 리소스 태그 기반 조건을 추가하여 특정 환경의 시크릿만 접근 가능하도록 제한합니다. VPC Endpoint를 통해 시크릿 조회 트래픽이 인터넷을 거치지 않도록 하고, CloudTrail로 모든 시크릿 접근을 감사합니다. CI/CD 파이프라인에서는 임시 자격증명만 사용하고, 빌드 완료 후 즉시 만료되도록 합니다.
- • 고민감 시크릿은 Secrets Manager로 자동 로테이션, 저민감은 Parameter Store 활용
- • ECS는 Task Definition secrets 필드, EKS는 External Secrets Operator + IRSA로 안전한 주입
- • IAM 최소 권한과 리소스 태그 조건, VPC Endpoint와 CloudTrail로 접근 통제 및 감사
MSA 환경에서 수많은 서비스의 시크릿을 중앙에서 안전하게 관리하고 자동으로 로테이션해야 할 때 필수적입니다.
개발자가 로컬 환경에서 테스트할 때 프로덕션 시크릿에 접근하지 못하도록 하면서도 개발 생산성을 유지하려면 어떤 전략을 사용하시겠습니까?
Q. 레거시 온프레미스 환경에서 AWS 클라우드로 전환하면서 제로 트러스트 보안 모델을 도입하려고 합니다. VPC 설계, 서비스 간 통신, 외부 접근 제어를 제로 트러스트 원칙에 맞게 구성하는 방법과, 기존 경계 기반 보안(Perimeter Security)에서 마이그레이션하는 단계별 전략을 설명해주세요.
네트워크 분리, 서비스 간 인증, 지속적 검증, 최소 권한 네트워크 접근 등 제로 트러스트의 핵심 원칙을 AWS 서비스에 매핑해보세요.
제로 트러스트는 '신뢰하지 않고 항상 검증한다'는 원칙으로, VPC를 마이크로 세그먼트로 나누고 서브넷별로 Security Group과 NACL을 엄격하게 적용합니다. 서비스 간 통신은 AWS PrivateLink를 사용하여 VPC 피어링 없이 격리된 연결을 구성하고, 모든 요청에 대해 IAM 인증과 mTLS(상호 TLS)를 강제합니다. API Gateway에서는 Lambda Authorizer로 모든 요청의 JWT 토큰을 검증하고, VPC Lambda는 VPC Endpoint를 통해서만 AWS 서비스에 접근합니다. 외부 접근은 Client VPN이나 AWS Verified Access를 사용하여 디바이스 포스처와 사용자 컨텍스트를 검증한 후에만 허용하고, Session Manager로 EC2 직접 접근을 제거하여 bastion host를 없앱니다. 네트워크 트래픽은 VPC Flow Logs를 S3로 전송하여 Athena와 QuickSight로 분석하고, GuardDuty와 Security Hub로 이상 패턴을 실시간 탐지합니다. 마이그레이션은 단계적으로 진행하여 1단계에서 VPC 분리와 Security Group 정리, 2단계에서 서비스 메시 도입, 3단계에서 인증 강화, 마지막으로 지속적 검증 체계를 구축합니다. Transit Gateway를 중앙 허브로 사용하되, 라우팅 테이블로 세그먼트 간 통신을 명시적으로 제어합니다.
- • VPC 마이크로 세그먼트 분리, PrivateLink로 격리된 서비스 간 통신, mTLS 강제
- • Verified Access로 디바이스 검증, Session Manager로 bastion 제거, 모든 요청 인증
- • VPC Flow Logs + Athena 분석, GuardDuty 이상 탐지, 단계적 마이그레이션 전략
클라우드 네이티브 환경에서 경계 기반 보안의 한계를 극복하고 내부 위협까지 방어하는 현대적 보안 아키텍처 구축에 활용됩니다.
제로 트러스트 모델을 도입한 후 네트워크 레이턴시가 증가하고 운영 복잡도가 높아진다는 개발팀의 반발이 있다면, 어떻게 trade-off를 조정하고 팀을 설득하시겠습니까?
Q. 프로덕션 환경에서 의심스러운 API 호출이 급증하고 일부 S3 버킷의 데이터가 외부로 유출된 것으로 추정되는 보안 사고가 발생했습니다. 초기 대응부터 근본 원인 분석, 재발 방지까지 AWS 환경에서 어떤 도구와 프로세스를 사용하여 사고를 처리하시겠습니까? 특히 증거 보전과 비즈니스 연속성 유지를 동시에 고려한 전략을 제시해주세요.
격리, 로그 분석, 영향 범위 파악, 복구, 사후 분석의 단계별로 사용할 AWS 서비스를 생각해보세요.
즉시 의심되는 IAM 사용자와 역할의 권한을 제거하거나 Deny All 정책을 연결하여 추가 피해를 차단하고, 손상된 EC2 인스턴스는 Security Group을 변경하여 네트워크 격리합니다. CloudTrail 로그를 S3에서 가져와 Athena로 쿼리하여 의심스러운 API 호출의 출처와 시간대를 분석하고, GuardDuty와 Security Hub의 알람을 확인하여 영향 범위를 파악합니다. S3 Access Logs와 VPC Flow Logs를 교차 분석하여 데이터 유출 경로를 추적하고, 손상된 인스턴스의 EBS 스냅샷을 즉시 생성하여 증거를 보전합니다. Detective를 사용하여 관련된 모든 리소스와 사용자의 행동 패턴을 시각화하고, 공격 타임라인을 재구성합니다. 비즈니스 연속성을 위해 Auto Scaling으로 새로운 깨끗한 인스턴스를 시작하고, ALB에서 손상된 인스턴스를 제거합니다. 근본 원인이 IAM 키 유출이라면 모든 키를 로테이션하고, Config Rules로 과도한 권한을 탐지하여 최소 권한 원칙을 재적용합니다. 사고 보고서를 작성하여 공격 벡터, 영향 범위, 대응 조치를 문서화하고, EventBridge + Lambda로 유사 패턴 자동 탐지 룰을 추가하며, 정기적인 침해 대응 훈련을 계획합니다.
- • 즉시 권한 제거와 네트워크 격리로 피해 차단, EBS 스냅샷으로 증거 보전
- • CloudTrail + Athena로 API 호출 분석, Detective로 공격 타임라인 재구성
- • Auto Scaling으로 비즈니스 연속성 유지, 근본 원인 제거 후 자동 탐지 룰 추가
실제 보안 침해 사고 발생 시 신속하게 피해를 최소화하고 증거를 보전하며 재발을 방지하는 전체 프로세스 구축에 필수적입니다.
보안 사고 대응 과정에서 개발팀과 경영진에게 각각 어떤 내용을 어떤 방식으로 커뮤니케이션하시겠습니까? 특히 법적 리스크가 있는 상황에서의 정보 공유 원칙은 무엇입니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!