AWS 보안 신입 기술면접
새 면접Q. AWS에서 IAM 사용자(User)와 IAM 역할(Role)의 차이점은 무엇이며, 각각 어떤 상황에서 사용하나요?
누가 사용하는지, 자격 증명 방식이 어떻게 다른지 생각해보세요.
IAM 사용자는 특정 개인이나 애플리케이션에 할당되는 영구적인 자격 증명으로, 액세스 키와 비밀번호를 가집니다. 반면 IAM 역할은 임시 자격 증명을 제공하며, 특정 개체가 아닌 필요한 시점에 assume할 수 있는 권한 집합입니다. 사용자는 개발자나 관리자 같은 실제 사람에게 부여하고, 역할은 EC2 인스턴스나 Lambda 함수 같은 AWS 리소스에 부여합니다. 역할은 임시 자격 증명을 사용하므로 보안상 더 안전하며, 교차 계정 접근이나 서비스 간 권한 위임에 적합합니다.
- • 사용자는 영구 자격 증명, 역할은 임시 자격 증명
- • 사용자는 사람에게, 역할은 AWS 리소스에 부여
- • 역할이 보안상 더 안전하고 유연함
EC2 인스턴스나 Lambda 함수에 IAM 역할을 부여하여 코드에 자격 증명을 하드코딩하지 않고 안전하게 AWS 서비스에 접근합니다.
EC2 인스턴스에서 S3에 접근해야 할 때, IAM 사용자의 액세스 키를 하드코딩하는 것과 IAM 역할을 부여하는 것 중 어떤 방법이 더 안전한가요?
Q. AWS에서 제공하는 KMS(Key Management Service)는 무엇이며, 데이터 암호화 시 어떤 역할을 하나요?
암호화 키를 누가 관리하는지, 어떤 데이터를 보호할 수 있는지 생각해보세요.
AWS KMS는 암호화 키를 안전하게 생성, 저장, 관리할 수 있는 관리형 서비스입니다. 사용자가 직접 암호화 키를 관리할 필요 없이 AWS가 키의 보안을 책임지며, 키는 하드웨어 보안 모듈(HSM)에 저장됩니다. S3, EBS, RDS 등 다양한 AWS 서비스와 통합되어 저장 데이터(data at rest) 암호화에 사용됩니다. KMS를 통해 키 사용 이력을 CloudTrail로 추적할 수 있어 규정 준수와 감사에 유리합니다. 고객 관리형 키(CMK)를 생성하여 키 정책과 rotation을 직접 제어할 수도 있습니다.
- • 암호화 키의 생성과 관리를 AWS가 담당
- • HSM에 안전하게 저장되며 다양한 AWS 서비스와 통합
- • 키 사용 이력 추적 가능
S3에 업로드되는 개인정보나 민감 데이터를 KMS로 자동 암호화하여 규정 준수 요구사항을 충족합니다.
S3 버킷에 저장된 민감한 데이터를 암호화할 때, SSE-S3와 SSE-KMS의 차이점은 무엇인가요?
Q. AWS Security Group과 Network ACL의 차이점을 설명하고, 각각 어느 레벨에서 동작하는지 말해주세요.
상태 저장 여부와 적용 범위(인스턴스 vs 서브넷)를 비교해보세요.
Security Group은 EC2 인스턴스 레벨에서 동작하는 상태 저장(stateful) 방화벽으로, 허용 규칙만 정의할 수 있습니다. 상태 저장이므로 인바운드로 허용된 트래픽의 응답은 자동으로 아웃바운드가 허용됩니다. 반면 Network ACL은 서브넷 레벨에서 동작하는 상태 비저장(stateless) 방화벽으로, 허용과 거부 규칙 모두 정의 가능합니다. Network ACL은 인바운드와 아웃바운드를 독립적으로 평가하므로 양방향 규칙을 모두 설정해야 합니다. Security Group은 기본적으로 모든 트래픽을 거부하고, Network ACL은 기본적으로 모든 트래픽을 허용합니다. 일반적으로 Security Group을 주요 방어선으로 사용하고, Network ACL은 추가 보안 계층으로 활용합니다.
- • Security Group은 인스턴스 레벨의 stateful 방화벽
- • Network ACL은 서브넷 레벨의 stateless 방화벽
- • Security Group은 허용만, Network ACL은 허용과 거부 모두 가능
웹 서버는 Security Group으로 80/443 포트만 허용하고, Network ACL로 알려진 악성 IP 대역을 서브넷 레벨에서 차단합니다.
특정 IP 주소로부터의 접근을 명시적으로 차단하려면 Security Group과 Network ACL 중 어떤 것을 사용해야 하나요?
Q. S3 버킷에 저장된 고객 개인정보가 실수로 public으로 공개되는 것을 방지하기 위해 AWS에서 제공하는 기능들을 설명해주세요.
버킷 정책, 퍼블릭 액세스 차단, 암호화 등 여러 계층의 보호 방법을 생각해보세요.
먼저 S3 Block Public Access 설정을 활성화하여 계정 또는 버킷 레벨에서 모든 퍼블릭 액세스를 차단할 수 있습니다. 버킷 정책과 ACL에서 퍼블릭 읽기 권한을 명시적으로 거부하고, IAM 정책으로 최소 권한 원칙을 적용합니다. S3 Object Lock을 사용하여 중요 데이터의 삭제나 수정을 방지할 수 있습니다. CloudTrail과 S3 액세스 로깅을 활성화하여 모든 접근 이력을 추적하고, AWS Config로 버킷 설정 변경을 모니터링합니다. 추가로 KMS 암호화를 적용하여 데이터가 유출되더라도 암호화된 상태로 보호됩니다. Macie를 사용하면 S3에 저장된 민감 정보를 자동으로 탐지하고 분류할 수 있습니다.
- • S3 Block Public Access로 퍼블릭 접근 원천 차단
- • 버킷 정책과 IAM으로 최소 권한 적용
- • CloudTrail과 Config로 모니터링 및 감사
개인정보가 포함된 S3 버킷에 Block Public Access를 설정하고 CloudTrail로 접근 로그를 모니터링하여 GDPR 등 규정을 준수합니다.
S3 버킷 정책에서 특정 VPC에서만 접근 가능하도록 제한하려면 어떤 조건을 사용해야 하나요?
Q. 웹 애플리케이션에서 사용자 인증을 구현할 때 AWS Cognito를 사용하면 어떤 이점이 있으며, 직접 구현하는 것과 비교했을 때 보안상 어떤 장점이 있나요?
사용자 자격 증명 관리, 토큰 발급, 소셜 로그인 등의 기능을 생각해보세요.
AWS Cognito는 사용자 가입, 로그인, 액세스 제어 기능을 관리형 서비스로 제공하여 개발자가 직접 인증 시스템을 구축할 필요를 없앱니다. 비밀번호는 자동으로 암호화되어 저장되며, MFA(다중 인증) 설정, 비밀번호 정책 강제, 계정 복구 등 보안 기능이 내장되어 있습니다. JWT 토큰 기반 인증을 자동으로 처리하며, Google, Facebook 등 소셜 로그인과의 통합도 쉽게 구현할 수 있습니다. 직접 구현할 경우 발생할 수 있는 SQL 인젝션, 세션 하이재킹, 비밀번호 평문 저장 같은 보안 취약점을 원천적으로 방지합니다. User Pool로 사용자 디렉토리를 관리하고, Identity Pool로 AWS 리소스 접근 권한을 임시로 부여할 수 있어 안전한 권한 관리가 가능합니다.
- • 관리형 서비스로 인증 시스템 구축 부담 감소
- • MFA, 비밀번호 암호화 등 보안 기능 내장
- • JWT 토큰과 소셜 로그인 자동 지원
모바일 앱이나 SPA에서 Cognito로 사용자 인증을 처리하고, 발급받은 토큰으로 API Gateway를 통해 백엔드 리소스에 안전하게 접근합니다.
Cognito User Pool에서 발급된 JWT 토큰을 API Gateway에서 검증하는 과정은 어떻게 이루어지나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!