[AWS/SSA-C03] Module 3 - 보안 아키텍처 설계 Specify Secure Applications and Architecture

Self-paced digital training on AWS - AWS Skill Builder 를 보며 정리한 내용입니다.

Self-paced digital training on AWS - AWS Skill Builder

---

keyword

• 공동 책임 모델
• 최소 권한의 원칙 적용
• 자격 증명

공동 책임 모델

• 고객은 클라우드 내부의 보안을 책임 (애플리케이션 코드는 고객 책임)
• AWS는 클라우드 자체의 보안을 책임짐 (물리적 보안 측면) → 이때 관리형 서비스를 사용하면 공동 책임의 선이 늘어남

최소 권한의 원칙

• 사용자는 꼭 필요한 활동만 수행할 수 있습니다.
• AWS IAM
  • 사용자, 그룹, 역할, 정책을 생성
  • 권한을 정의하여 AWS 리소스 접근 제어

자격 증명

• IAM 사용자 → 계정 내에서 생성된 사용자
• 역할 → EC2 인스턴스, Lambda 및 외부 사용자가 사용하는 임시 자격 증명
• 연동 → Active Directory 자격 증명 또는 기타 기업 자격 증명이 있는 사용자에게는 IAM에서 역할할당
• 웹 자격 증명 연동 → 기타 오픈 ID 제공자의 웹 자격 증명이 있는 사용자에게는 STS(시큐리티 토큰 서비스)를 사용하여 역할 할당

IAM

• 루트 사용자 로그인 시 IP에 제한을 두는 것은 불가능
• MFA(Multi factor Auth) : 비밀번호 + 보안 장치(토큰)

VPC

• 주로 보안 그룹과 액세스 제어 목록을 사용해 통신 가능 여부를 제어(게이트 웨이) → 경로를 사용하여 서브넷 간의 연결을 결정
• 서브넷 권장 사항
  • 퍼블릭 서브넷을 통해 인바운드/아웃 바운드 액세스가 가능
  • 퍼블릭 서브넷 라우팅 테이블에는 인터넷 게이트웨이의 진입점이 포함되어야함
  • 프라이빗 서브넷에는 인터넷 게이트웨이에 대한 라우팅 항목 X → 퍼블릭 인터넷에서 직접 액세스가 불가
  • 프라이빗 서브넷에서 아웃바운드 액세스의 경우 인터넷을 사용할때는 NAT 인스턴스 또는 NAT 게이트웨이를 사용한다
  • 프라이빗 서브넷 인바운드 액세스의 경우 점프 박스 또는 배스천 호스트를 사용

VPC에서 액세스를 허용하는 두 가지 주요 메커니즘

tips. ACL과의 비교문제가 나오면 대체로 보안그룹을 사용할 것을 권장함

• 보안그룹 vs 액세스 제어 목록
• 보안 그룹
  • 인스턴스/네트워크 인터페이스 수준에서 작동
  • 허용 규칙만 생성 가능 → 블랙 리스트처럼 특정 차단은 불가능
  • 상태 저장(요청이 들어오면 요청의 응답이 나갈 수 있음) → 인바운드를 통과하는 트래픽은 아웃바운드의 규칙을 적용받지 않음(= 요청이 먹히면 무조건 return이 온다는 뜻 같음, 포트 등의 상태가 저장되니 아웃바운드 규칙이 따로 존재하지 않아도 데이터가 왕래한다는 뜻)
• 액세스 제어 목록(네트워크 ACL)
  • 서브넷 수준에서 작동
  • 트래픽 허용/거부 가능
  • 상태 비저장
  • 보니까 보안그룹까지 오기 전에 여기서 한번 걸러줄 수 있는듯

+) 이거 보고 참조함

[AWS] 📚 VPC 개념 & 사용 - 보안 설정 [Security Group / NACL]

애플리케이션의 티어, 구성 요소 구분

• 보안 그룹을 사용하여 구분
• 보안 그룹은 여러 가용영역에 걸쳐져 있을 수있음 → 예를 들어 새로운 DB를 파거나 EC2 인스턴스를 생성한 뒤 보안 그룹에 넣으면 다른 보안그룹과 자동으로 연결되어 따로 액세스를 허용해주지 않아도 됨 → 다만 여러 리전에 걸칠 수 는 없음
• 결국 이 서비스는 데이터가 VPC를 드나들 수 있게 하는 서비스임
  • 인터넷 게이트웨이 → 인터넷에 연결
  • 가상 프라이빗 게이트웨이 → VPN or AWS Direct Connect 를 통해 고객 데이터센터에 연결 (온프레미스 네트워크 간의 연결)
  • VPC 페어링 → VPC를 서로 연결
  • NAT 게이트 웨이 → 프라이빗 서브넷에서 인터넷 트래픽 허용

+) VPN 연결 이라는 용어는 일반적인 용어지만 이 설명서에서 VPN 연결은 VPC와 자체 온프레미스 네트워크 간의 연결을 의미합니다. Site-to-Site VPN은 인터넷 프로토콜 보안(IPsec) VPN 연결을 지원합니다.

NAT 인스턴스 / 게이트웨이

• NAT 인스턴스 → 퍼블릭 IP 포함, 퍼블릭 서브넷의 NAT로 사용되는 EC2 인스턴스
• VPC NAT 게이트 웨이 → 인스턴스에 비해 확장성이 뛰어난 관리형 서비스임
• 만약 게이트 웨이 말고 인스턴스를 생성한다면 가격이 더 싸긴 하지만 해당 인스턴스에 프라이빗 IP주소가 하나 생성됨에 따라 서브넷이 이 IP주소의 하위 집합을 만듬 (= 라우팅 테이블은 서브넷에 연결된다는 게 이런의미인듯)

데이터 티어

• 전송 데이터 → AWS 내에서 이동하거나, 외부로 드나드는 경우
  • AWS 인프라 안팎으로 데이터 전송 → 웹을 통한 SSL, IPsec용 VPN, AWS Direct Connect를 통한 IPsec, AWS import/Export → 데이터를 암호화된 상태로 유지
  • AWS API에 전송되는 데이터는 기본적으로 SSL 사용
• 저장 데이터 → AWS 내부 시스템에 저장되는 경우(S3, EBS 등)
  • S3에 저장된 데이터는 기본적으로 프라이빗 → 액세스하려면 자격증명 필요 (HTTP, HTTPS를 통해 액세스)
  • 모든 객체에 대한 액세스 감사 로그 존재
  • 버킷 수준 이하에서 ACL 및 정책에 대한 액세스를 잠글 수 있음
  • 암호화 옵션 선택 가능
    • 서버측 암호화 옵션 → S3 관리형 키(SSE-S3), KMS 관리형 키(SSE-KMS), 고객 제공 키(SSE-C) → AWS 서버 디스크에 도달하기 전에 암호화 됨
    • 클라측 암호화 옵션 → KMS관리 암호화 키(CSE-KMS), 고객 관리 암호화 키(CSE-C) → 데이터를 AWS 서비스로 전송하기 전에 암호화해야 함
  • 이때 암호화 키는 어디에 저장되나?
    • KMS를 사용하여 키를 관리 → 고객 소프트웨어 기반 키 관리, 애플리케이션에서 직접 사용
    • AWS CloudHSM 사용 → 하드웨어 기반 키 관리

Tip

• 루트 사용자는 사용 금지
• 보안 그룹은 허용만 가능, 네트워크 ACL은 명시적 거부가 가능
• 액세스 키보다 IAM역할을 선호할 것