Notice
Recent Posts
Recent Comments
Link
Archives
Today
Total
관리 메뉴

윤서율의 블로그

AWS 안전한 애플리케이션 및 아키텍처 지정 본문

Cloud

AWS 안전한 애플리케이션 및 아키텍처 지정

Yoon Seo-yul 2022. 6. 19. 21:52

애플리케이션 티어를 보호하는 방법 결정

인프라: 공동 책임 모델(고객은 클라우드 내부의 보안을 책임지고 AWS는 클라우드 자체의 보안을 책임진다.)

AWS 리소스 보호: 최소 권한의 원칙 적용(필요한 작업을 수행할 수 있는 최소한의 권한을 사용자와 서버에 부여하는 것), 자격 증명 활용

AWS IAM

AWS에서 사용자와 사용자 권한을 중앙에서 관리하는 서비스

AWS IAM을 사용하여 사용자, 그룹, 역할, 정책을 생성하고 권한을 정의하여 사용자가 액세스할 수 있는 AWS 리소스를 제어한다.

역할은 회사 방문증과 같은것으로 임시 자격 증명으로 볼 수 있다. 이러한 자격 증명(역할)에 정책 형식으로 되어있는 권한을 부여한다.

정책은 리소스와 해당 리소스에서 수행할 수 있는 작업을 지정한다. 정책을 사용자, 그룹 또는 역할에 연결해야 리소스에서 작업을 수행할 수 있다.

SAML 자격 증명 연동을 통해 IAM을 AWS Active Directory Service 또는 Microsoft Active Directory와 같은 기타 자격 증명 공급자와 통합할 수 있다.

자격 증명

IAM 사용자: 계정 내에서 생성된 사용자

역할: EC2 인스턴스, Labmda 및 외부 사용자가 사용하는 임시 자격 증명

연동: Active Directory 자격 증명 또는 기타 기업 자격 증명이 있는 사용자에게는 IAM에서 역할 할당

웹 자격 증명 연동: Amazon.com 또는 기타 오픈 ID 제공자의 웹 자격증명이 있는 사용자에게는 STS(Security Token Service, 보안 토큰)를 사용하여 역할이 할당

데이터 보호 방법 결정

AWS에서 네트워킹 인프라를 보호하는 방법으로 VPC가 있다. VPC를 사용하여 인스턴스에 프라이빗 IP 주소 기반을 만들어 제공한다.

VPC(Virtual Private Cloud)

VPC는 프라이빗 IP 주소의 하위 네트워크 서브넷으로 구성된다.

보안 방법으로 보안그룹과 액세스 제어 목록(ACL)을 사용하여 누가 누구와 통신할 수 있는지 결정한다. 네트워크 격리 방법으로 인터넷 게이트웨이, 가상 프라이빗 게이트웨이, NAT 게이트웨이를 사용한다.

서브넷 사용 방법

서브넷을 사용하여 인터넷 접근성을 정의하는것이 권장사항이다.

퍼블릭 서브넷: 퍼블릭 인터넷에 대한 인바운드/아웃바운드 액세스를 지원하려면 인터넷 게이트웨이에 라우팅 테이블 항목을 포함시켜야 한다.

프라이빗 서브넷: 인터넷 게이트웨이에 대한 라우팅 테이블 항목이 없다. 퍼블릭 인터넷에서 직업 액세스가 불가능하다. 제한된 범위의 아웃바운드 전용 퍼블릭 인터넷 액세스를 지원하려면 NAT 인스턴스 또는 NAT 게이트웨이를 사용한다. 인바운드 액세스의 경우 점프박스, 프록시, 배스천 호스트를 사용한다.

  보안 그룹 액세스 제어 목록
액세스 유형 포트, 프로토콜, 소스 IP 지정 포트, 프로토콜, 소스 IP 지정
규칙 명시적 허용만 명시적 허용 또는 거부
상태 상태 저장 상태 비저장
애플리케이션 ENI에 적용 서브넷에 적용
연결 단일 VPC에 연결 단일 VCP에 연결
지원 VPC 및 EC2 Classic VPC 전용

보안 그룹의 장점으로 다른 보안 그룹에서 인스턴스나 ENI(Elastic Network Interface)에 액세스하는것을 허용하는것으로 설정할 수 있는 편리함이 있다. IP를 알 필요가 없다.

VPC가 리전간 연결은 해줄 수 없다.

VPC 연결

VPC 안팎으로 트래픽을 가져오거나 내보내는 서비스

  • 인터넷 게이트웨이: 인터넷 연결
  • 가상 프라이빗 게이트웨이: VPN 연결(고객의 데이터센터 연결)
  • AWS Direct Connect: AWS와 연결하는 전용 파이프(고객의 데이터센터 연결)
  • VPC 피어링: 다른 VPC에 연결
  • NAT 게이트웨이: 프라이빗 서브넷에서 인터넷 트래픽 허용

전송 데이터

AWS 인프라 안팎으로 데이터를 전송하는 경우

회사 데이터 센터와 AWS 간에 이동하는 데이터의 경우 웹을 통한 SSL이나 IPsec을 사용한 VPN 또는 AWS Direct Connect를 통한 IPsec, 그리고 Snowball이나 Snowmobile을 사용한 AWS Import/Export 서비스

AWS API에 전송된 데이터

AWS API 호출은 기본적으로 HTTPS/SSL을 사용한다.

저장 데이터

Amazon S3에 저장된 데이터는 기본적으로 프라이빗이고 액세스하려면 AWS 자격 증명이 필요하고 HTTPS 또는 HTTPS를 통한 액세스할 수 있다. 모든 객체에 대한 액세스 감사 로그가 있다.

버킷 수준 이하에서 ACL 및 정책에 대한 액세스를 잠글 수 있다. 버킷, 접두사(디렉토리/폴더) 객체

AWS에서 저장 데이터를 암호화 하는 경우 옵션

서버 측 암호화 옵션

코드에 대해 투명하며 구성하기가 쉽다. 데이터는 AWS의 서버 디스크에 도달하기 전에 암호화 된다.

Amazon S3 관리형 키(SSE-S3): S3가 암호화 키를 관리하는 서버측 암호화

KMS 관리형 키(SSE-KMS): KMS가 암호화 키를 관리하는 서버측 암호화

고객 제공 키(SSE-C): 고객이 암호화 키를 관리하는 서버측 암호화

클라이언트 측 암호화 옵션

서버 측 암호화보다 어렵다. 데이터를 AWS 서버에 전송하기 전에 클라이언트가 직접 암호화 해야한다.

KMS이 관리하는 마스터 암호화 키(CSE-KMS): KMS가 암호화 키를 관리하는 클라이언트측 암호화

고객이 관리하는 마스터 암호화 키(CSE-C): 고객이 암호화 키를 관리하는 클라이언트측 암호화

키 관리

Key Management Service

KMS를 사용하여 키를 관리할 수 있다. 고객 소프트웨어 기반 키 관리, 여러 AWS 서비스와 통합. 애플리케이션에서 직접 사용

AWS KMS 통합

AWS KMS에 통합된 서비스: EBS, S3, RDS, Redshift, Elastic Transcoder, WorkMail, EMR

암호화는 요청시 수행된다.

AWS CloudHSM

하드웨어 기반 키 관리, 애플리케이션에서 직접 사용, FIPS 140-2 규정 준수

보안을 위한 기본

루트 사용자는 사용 금지

보안 그룹은 허용만 가능하다! 상태 저장

네트워크 ACL은 명시적 거부가 가능하다. 상태 비저장

액세스 키보다 IAM 역할을 선호해라!