AWS 보안 주니어 기술면접

최소 권한 원칙은 사용자나 서비스가 업무를 수행하는데 필요한 최소한의 권한만 부여하는 보안 원칙입니다. 실무에서는 처음에 모든 권한을 거부하고, 필요한 액션과 리소스에 대해서만 명시적으로 허용합니다. 예를 들어 S3 읽기만 필요한 Lambda라면 s3:GetObject만 허용하고, 특정 버킷으로 Resource를 제한합니다. 와일드카드(*)는 최대한 피하고, 정기적으로 권한을 검토하여 불필요한 권한을 제거해야 합니다. IAM Access Analyzer를 활용하여 과도한 권한을 탐지할 수 있습니다.

S3 버킷의 퍼블릭 노출을 방지하기 위해 Block Public Access 설정을 계정 및 버킷 레벨에서 활성화해야 합니다. 이 설정은 BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets 네 가지 옵션을 제공합니다. 버킷 정책에서는 Principal을 특정 IAM Role이나 사용자로 제한하고, Condition을 활용해 VPC Endpoint나 특정 IP에서만 접근하도록 설정합니다. S3 Object Ownership을 BucketOwnerEnforced로 설정하여 ACL을 비활성화하고, CloudTrail로 버킷 액세스를 로깅하여 이상 접근을 모니터링합니다. AWS Config의 s3-bucket-public-read-prohibited 규칙을 활성화하여 규정 준수를 자동으로 확인할 수 있습니다.

퍼블릭 서브넷의 웹 서버 Security Group은 인바운드에서 80/443 포트를 0.0.0.0/0에서 허용하고, 아웃바운드는 DB Security Group으로 3306 포트만 허용합니다. 프라이빗 서브넷의 DB Security Group은 인바운드에서 3306 포트를 웹 서버 Security Group에서만 허용합니다. Network ACL은 서브넷 레벨에서 추가 방어선으로, 퍼블릭 서브넷 NACL은 80/443 인바운드와 Ephemeral 포트 아웃바운드를 허용합니다. 프라이빗 서브넷 NACL은 웹 서버 서브넷 CIDR에서 3306 포트만 허용하고, 인터넷 게이트웨이로의 직접 접근을 명시적으로 거부합니다. Security Group은 상태 저장(Stateful)이고 NACL은 상태 비저장(Stateless)이므로 인바운드와 아웃바운드를 모두 설정해야 합니다.

API 키는 간단한 식별자로 주로 사용량 추적과 할당량 관리에 사용되며, 보안 메커니즘이라기보다는 클라이언트 식별 수단입니다. x-api-key 헤더로 전달되며 정적이고 장기간 유지됩니다. 반면 Lambda Authorizer는 커스텀 인증 로직을 구현할 수 있어 JWT 토큰 검증, OAuth 토큰 검증, 외부 인증 서버 연동 등이 가능합니다. 요청마다 Lambda 함수가 실행되어 토큰을 검증하고 IAM 정책을 반환하여 세밀한 권한 제어가 가능합니다. API 키는 파트너사 구분이나 요금제별 할당량 관리에 적합하고, Lambda Authorizer는 사용자 인증과 세션 기반 권한 제어가 필요한 경우 사용합니다. 보안이 중요한 경우 Lambda Authorizer와 API 키를 함께 사용하여 다층 보안을 구현할 수 있습니다.

저장 데이터 암호화(Encryption at Rest)는 디스크나 스토리지에 저장된 데이터를 암호화하여 물리적 접근이나 스토리지 유출 시 데이터를 보호합니다. S3의 SSE, RDS의 암호화 옵션, EBS 볼륨 암호화 등이 해당됩니다. 전송 중 데이터 암호화(Encryption in Transit)는 네트워크를 통해 데이터가 이동할 때 암호화하여 중간자 공격이나 패킷 스니핑을 방지합니다. HTTPS/TLS, VPN, AWS Certificate Manager를 통한 SSL/TLS 인증서 적용이 대표적입니다. 실무에서는 두 가지를 모두 적용해야 하며, 예를 들어 사용자가 HTTPS로 API Gateway에 요청하고(전송 중 암호화), Lambda가 암호화된 RDS에 데이터를 저장(저장 데이터 암호화)하는 방식으로 구현합니다.

AWS WAF는 Web ACL을 생성하여 CloudFront, API Gateway, ALB 앞단에 배치할 수 있습니다. SQL Injection 방어를 위해 AWS Managed Rules의 SQLi 규칙 그룹을 활성화하거나, 커스텀 규칙으로 쿼리 문자열과 바디에서 SQL 패턴을 탐지합니다. XSS 방어는 XSS 관리형 규칙 그룹을 사용하거나, <script> 태그와 자바스크립트 이벤트 핸들러 패턴을 차단하는 규칙을 만듭니다. Rate-based 규칙으로 특정 IP의 과도한 요청을 제한하여 DDoS를 방어할 수 있습니다. CloudFront와 통합 시 엣지 로케이션에서 차단하여 오리진 서버 부하를 줄이고, API Gateway와 통합 시 리전 수준에서 보호합니다. WAF 로그를 CloudWatch나 S3에 저장하여 공격 패턴을 분석하고 규칙을 지속적으로 개선해야 합니다.

Lambda 함수에서 Secrets Manager를 사용할 때는 핸들러 외부(전역 스코프)에서 시크릿을 조회하여 컨테이너 재사용 시 캐싱 효과를 얻습니다. AWS SDK의 getSecretValue API를 호출하고, 예외 처리를 통해 시크릿이 없거나 권한이 없는 경우를 처리합니다. 시크릿 버전 스테이징 레이블(AWSCURRENT)을 사용하여 최신 시크릿을 가져오고, 자동 로테이션이 설정된 경우 Lambda가 주기적으로 재시작되어 새 시크릿을 가져옵니다. IAM Role에는 secretsmanager:GetSecretValue 권한을 부여하고, 특정 시크릿 ARN으로 제한합니다. VPC Lambda의 경우 Secrets Manager VPC 엔드포인트를 사용하여 인터넷 경유 없이 시크릿을 조회할 수 있습니다. 시크릿 조회 실패 시 재시도 로직과 기본값 처리를 구현해야 합니다.

CloudTrail은 AWS 계정의 모든 API 호출과 이벤트를 기록하는 감사 로깅 서비스입니다. 관리 이벤트(Management Events)는 리소스 생성, 수정, 삭제 등을 기록하고, 데이터 이벤트(Data Events)는 S3 객체 액세스나 Lambda 함수 실행을 기록합니다. 보안 감사를 위해서는 IAM 정책 변경, Security Group 규칙 수정, S3 버킷 정책 변경, 루트 사용자 로그인 등을 모니터링해야 합니다. CloudTrail 로그는 S3에 저장되며, 로그 파일 무결성 검증을 활성화하여 변조를 방지합니다. CloudWatch Logs와 통합하여 실시간 알람을 설정하고, AWS Config와 함께 사용하여 규정 준수를 자동으로 확인할 수 있습니다.

AssumeRole을 사용한 크로스 계정 액세스에서 신뢰 정책(Trust Policy)은 역할을 맡을 수 있는 Principal(계정, 사용자, 서비스)을 정의하고, 권한 정책(Permissions Policy)은 역할이 수행할 수 있는 작업을 정의합니다. 신뢰 정책에는 외부 계정의 ARN을 Principal로 지정하고, Condition으로 ExternalId를 요구하여 혼동된 대리자 문제(Confused Deputy Problem)를 방지합니다. MFA 인증을 요구하려면 aws:MultiFactorAuthPresent 조건을 추가합니다. 소스 IP를 제한하려면 aws:SourceIp 조건을 사용하고, 특정 VPC Endpoint에서만 접근하도록 aws:SourceVpce를 설정할 수 있습니다. 세션 지속 시간(DurationSeconds)을 최소화하여 임시 자격증명의 유효 기간을 제한하고, 역할 세션 이름(RoleSessionName)으로 사용자를 추적할 수 있습니다.

사용자 삭제 요청 시 RDS의 개인정보 테이블에서 해당 레코드를 DELETE하고, S3에 저장된 사용자 파일(프로필 사진, 업로드 파일 등)을 삭제합니다. RDS 자동 백업과 스냅샷에는 삭제 전 데이터가 남아있으므로, 보관 기간 경과 후 자동 삭제되도록 설정하거나 수동 스냅샷을 별도 관리합니다. S3 버전 관리가 활성화된 경우 이전 버전까지 모두 삭제하고, CloudFront 캐시도 무효화합니다. CloudWatch Logs, CloudTrail 로그에 포함된 개인정보는 로그 보관 정책에 따라 삭제하거나 익명화합니다. ElastiCache에 캐싱된 데이터는 TTL 만료를 기다리거나 명시적으로 삭제합니다. 삭제 작업은 Step Functions로 오케스트레이션하여 각 단계를 추적하고, 삭제 완료 후 감사 로그를 별도 테이블에 기록하여 규정 준수 증적을 남깁니다.