aws

[AWS]보안성 아키텍처

하리하링웹 2024. 8. 20. 18:44

개요

정보 보안의 기본 목표는 데이터의 보호, 특히 해당 데이터를 저장한 리소스 보호, 접근 보안이다. 데이터를 보호하기 위해 다음 세 가지 오류를 준수해야한다.

기밀성

특정 데이터에 대한 접근 권한이 있는 사람, 시스템만이 해당 데이터에 접근할 수 있어야 한다. 데이터 암호화와 ACL은 기밀성을 강화하는 주요 매커니즘이다.

무결성

데이터는 악의적으로 또는 우연히 변조돼서는 안 된다. 암호화를 위한 해싱, 로그 관리는 무결성을 검증하는 주요 도구다.

가용성

데이터를 필요로 하는 사람은 해당 데이터에 접속할 수 있어야 한다. 데이터가 무결성을 유지하고 있더라도 해커 등의 Dos 공격으로 해당 데이터에 접속할 수 없다면 가용성이 부족한 것이다.

신분 및 접근 권한 관리

AWS에서의 보안은 IAM에서 제공하는 신분을 기준으로 이뤄진다. AWS의 자격인증은 AWS의 각종 리소스에 접근할 수 있는 핵심 정보이다. 첫 번째 단계는 주요 정보의 실수에 의한 노출, 악의적인 이용을 방지해야하고 두 번째 단계로 개별 유저에게는 주어진 임무 수행에 필요한 권한만 부여해야한다.

AWS 자격인증 정보 보호

aws 리소스에 접근하려는 사람은 누구나 자격인증 정보를 이용해 접근권한을 확인받아야한다. aws리소스에 대한 작업 권한 개체를 principal이라 하며 이를 신분이라 부른다. 권한 개체는 다음 세 가지이다.

  • 루트 유저
  • IAM 유저
  • IAM Role

루트 유저 보안을 위해 되도록 사용하지 않는것이 좋고 MFA를 사용하는 것이 좋다.

IAM 유저의 경우 AWS Management Console에 접근하기 위한 패스워드 정책을 강화해 보안 수준을 높일 수 있다. 패스워드 정책은 아래와 같다.

  • 패스워드의 최소 길이 제한, 대소문자, 숫자, 기호 혼용 등 제약 사항 추가
  • 패스워드 만료시간 설정
  • 재사용 금지
  • 만료된 패스워드의 재설정은 어드민이 수행

IAM 유저 생성 시 AWS Management Console 접근, 프로그래밍 방식 접근 또는 두 방식 모두를 이용한 접근 허용 여부, AWS Management Console 접근 시 username과 password가 필요하며 MFA 토큰 옵션 추가가 가능하다.

프로그래밍 방식 접근 시 AWS API, CLI, SDK 등을 사용할 수 있으며 access key id와 secret access key가 필요하다.

세분화된 권한 부여

정보 보안의 근본적인 개념은 최소 권한부여 원칙이다.

IAM principals는 기본적으로 모든 개체의 접근을 허용하지 않으며 새로 생성한 IAM 유저, 롤은 어떠한 작업도 할 권한이 없다.

어드민은 유저에게 하나 이상의 정책을 작성해 principal에 명시하는 방식으로 권한을 부여한다. 정책에는 하나 이상의 permission이 포함되어 있으며 각 permission에는 다음 4가지 요소가 포함된다.

  • Effect: 리소스에 대한 액션의 허용 여부
  • Action/Operation: 각 AWS 서비스는 해당 리소스에 대한 작업 가능 요소인 액션 또는 작업 세트를 지닌다.
  • Resource: 액션 생성 시 하나 이상의 리소스를 지정해야 한다.
  • Condition: 퍼미션 부여를 위한 조건을 지정할 수 있다.

AWS 관리형 정책

AWS Managed Policies는 AWS제공하는 사전 정의된 정책이다. 네트워크 관리자, DBA, 보안 감사 담당자 등 전형적인 인프라 및 리소스 관리자의 업무 롤을 제공한다.

고객 관리형 정책

customer-managed policy는 AWS 계정의 권한 개체에 추가할 수 있는 개별적이며 독립적 정책이다. 사용자가 이 정책을 업데이트하면 여기 부탁되어 있는 모든 권한 개체에 변경 사항이 즉시 반영된다. 최대 5개의 버전을 이용할 수 있다.

인라인 정책

Inline policy는 IAM 권한 개체 또는 IAM 그룹에 포함돼 실행되는 정책이다. AWS 관리형 정책과 고객 관리형 정책이 권한 개체에 독립적으로 존재할 수 있는 것과 달리 특정 권한 개체의 일부로만 존재할 수 있따.

권한의 경계

특정 권한 개체의 접근을 허용하는 정책을 permissions policy라 하며 이러한 정책 속성을 이용해 permissions boundaries를 정의할 수 있다.

권한의 경계는 다수의 퍼미션 정책을 부여하는 가운데 특정 개체에 지나치게 많은 권한이 부여되는 것을 막는다.

롤은 패스워드나 액세스 키를 사용하지 않는 IAM 권한 개체로 다른 개체처럼 접근 권한 정책 또는 권한 경계 속성을 지닐 수 있다.

롤은 EC2 인스턴스에서 실행되는 애플리케이션에 액세스 키 없이 특정 AWS 리소스에 대한 접근 권한을 부여할 때 편리하게 이용할 수 있다.

인스턴스 프로필

롤은 퍼미션 정책 외에도 trust policy를 통해 어떤 AWS 리소스가 해당 롤을 지니고 있는지 설명할 수 있다.

롤 부여하기

롤을 생성한 뒤 어떤 IAM 유저에게든 롤을 부여할 수 있다. 롤을 부여받은 유저는 롤과 동일한 계정에 속해 있거나 다른 계정에 속해 있을 수 있다. 롤을 부여하는 경우 해당 롤에만 접근 권한을 제공할 수 있다.

서비스 레벨 보안 강화하기

IAM과 같이 리소스에 대한 접근 제어를 위해 identity-based policies를 정의 하는 방법 외에도 일부 AWS 서비스에서는 resource-based policies를 정의할 수 있다.

별도의 AWS 자격인증이 없는 유저의 경우 주로 리소스 기반 정책을 통해 AWS 서비스를 이용하는 경향이 있다. 리소스 기반 정책은 신분 기반 정책만으로 제어할 수 없는 리소스 또는 서비스에 접근 권한을 제공할 수 있다.

탐지 제어

AWS는 클라우드 환경에서 발생하는 다양한 이벤트를 추적, 기록하고 리소스 침탈 시도 및 잠재적 위협을 경고하는 다양한 탐지 제어 기법을 제공한다.

CloudTrail

AWS 계정에서의 각종 활동 로그를 기록한다. 로그 기록의 범위와 어떤 로그를 기록할지 혹은 하지 않을지를 먼저 결정해야한다. 아래는 그 항목들이다.

  • 관리 이벤트 또는 데이터 이벤트 기록 혹은 둘 다 기록
  • read-only 이벤트 또는 write-only 이벤트 기록 혹은 둘 다 기록
  • 모든 리소스 또는 특정 리소스만 기록
  • 모든 리전 또는 특정 리전만 기록
  • 글로벌 서비스 기록 여부

또한 trail의 수도 결정해야 한다.

CloudWatch Logs

CloudWatcfh Logs는 다수의 소스로부터 유입되는 로그를 수집해 저장 및 검색이 용이하도록 한다. 아래와 같은 다양한 AWS 서비스에서 로그가 유입된다.

CloudTrail Logs: CloudTrail 로그의 검색 및 확인의 편의성을 위해 CloudWatch Logs에 수집한다.

VPC Flow Logs: 여기에는 VPC로 유입되거나 VPC에서 유출되는 트래픽 정보가 수집된다. 네트워크 인터페이스, 원본 및 대상 IP 주소, 포트, 프로토콜, 패킷, 바이트 카운트 등 정보가 포함되지만 DHCP 트래픽이나 Amazon DNS 서버로 향하는 트래픽은 포함되지 않는다.

RDS Logs: RDS는 MariaDB, MySQL, MySQL 호환 Aurora, Oracle 등 데이터베이스 엔진의 로그를 수집한다.

Route 53 DNS Queries: Route 53을 이용해 호스팅 존의 DNS 쿼리 로그를 기록하고 CloudWatch Logs에 전송할 수 있다.

Lambda: Lambda 코드에 로그 명령을 추가할 수 있다.

Athena로 로그 검색하기

Athena는 SQL을 이용해 s3에 저장된 로그 데이터를 검색할 수 있도록 해준다. athena는 SQL을 이용하므로 CREATE TABLE DDL 명령을 사용해서 데이터 구조를 먼저 정의해야 한다. athena가 지원하는 데이터 포맷은 아래와 같다.

  • CSV, TSV
  • JSON
  • Apache ORC 및 Parquet

AWS Config를 이용한 리소스 환경설정 감사

전반적인 보안 전략 수립을 위해서 AWS 리소스의 환경설정 상태 모니터링도 필요하다. AWS Config는 AWS 계정 내 리소스의 환경설정 변경 사항을 모니터링하여 경고 메시지를 전송한다.

기업에서 정의한 기준선과 현재 리소스 환경설정 내역을 비교하기 위해 AWS Config Rules를 정의할 수 있다.

Amazon GuardDuty

Amazon GuardDucy는 VPC flow logs, CloudTrail management event logs, Route 53 DNS query logs 등 로그를 분석해 악성 IP 주소 및 도메인 네임, 악의적인 행동을 탐색한다.

잠재적인 보안 위협이 탐지되면 위협 탐지 또는 파인딩 notification을 생성해 세부 내용을 전달한다. 이 내용은 GuardDucy 콘솔에 표시되며 CloudWatcfh Events에도 전송된다.

위험 탐지는 위협의 종류에 따라 아래와 같은 타입으로 분류된다.

  • Backdoor: EC2 인스턴스가 악성 코드에 감염 돼 스팸 발송에 이용되거나 DDOS 공격 자원으로 활용될 때
  • Behavior: Ec2 인스턴스가 보통의 경우에 사용하지 않는 프로토콜 또는 포트를 이용하거나 비정상적인 트래픽을 전송 시
  • Cryptocurrency: EC2 인스턴스가 Bitcoin 채굴, 전송, 수신 등 작업에 사용될 때
  • Pentest: 모의 해킹 관련 API 호출을 생성하고 있을 때
  • Persistence: 작업 이력이 존재하지 않는 iAM 유저가 유저, 리소스 퍼미션, 보안 그룹, 라우트, 네트워크 ACLs 등울 수정했을 때
  • Policy: 루트 유저 권한이 사용됐거나, S3 퍼블릭 액세스 차단 기능이 해제되었을 때
  • Recon: 정찰 공격이 진행중일 때
  • ResourceConsumption: 작업 이력이 존재하지 않는 IAM 유저가 EC2 인스턴스 등의 리소스를 생성했을 때
  • Stealth: 패스워드 정책이 약화되거나 로그 기능이 비활성화, 삭제, 수정되었을 때
  • Trojan: EC2 인스턴스에 Trojan 악성코드가 설치되었을 가능성이 있을 때
  • UnauthorizedAccess: AWS 리소스에 대해 API 호출 또는 콘솔 로그인을 통한 비인가 접근 시도가 있을 때

AWS Inspector

aws inspector은 EC2 인스턴스에 대한 침해 행위를 탐지하는 에이전트 기반 서비스이다. GuardDuty가 인스턴스를 오가는 트래픽을 통해 보안 위협을 탐지하는 반면 이는 인스턴스 자체의 네트워크, 파일 시스템, 프로세스 활동의 적절성을 분석한다.

Amazon inspector는 다음 5개의 롤 패키지를 제공한다.

  • 보편적인 보안 위협 및 기밀 노출: 일명 CVEs로도 부르며, 리눅스 및 윈도우 등 상업용 및 오픈소스 기반 공개 배포 소프트웨어에서 흔히 발견되는 보안 위협이다.
  • 인터넷 보안 벤치마크 센터: 리눅스 및 윈도우 운영 체제의 환경설정 베스트 프랙티스를 반영한다.
  • 보안성 베스트 프랙티스: 위 인터넷 보안 벤치마크 센터 룰의 하위규칙이며 , 리눅스 인스턴스 사용과 관련된 간략한 규칙을 제공한다. SSH를 통한 루트 접근, 패스워드 보안 정책 부재, 시스템 디렉토리에 대한 권한 부여 등과 관련된 규칙이 포함된다.
  • 런타임 동작 분석: 안전하지 않은 클라이언트 및 서버 프로토콜 사용, 미사용 리스닝 TCP 포트 개방 등에 대한 규칙과 Linux 관련 부적절한 파일 접근 권한 및 소유권 관리 등이 포함된다.
  • 네트워크 연결의 적정성: VPC 내 리소스에 대한 보안상 부적절한 네트워크 환경설정에 대한 규칙이며, 퍼블릭 서브넷에 인스턴스 배포, 노출된 포트에서 애플리케이션의 리스닝 작업 수행 등이 포함된다.

보안 검증을 수행한 후 Inspector는 문제 수준에 따라 다음 단계로 주의 목록을 제공한다.

  • High: 해당 문제점을 즉시 해결해야 하는 수준
  • Medium: 해당 문제점을 조만간, 가능한 시점에 해결해야 하는 수준
  • Low: 해당 문제점을 원할 떄 해결하면 되는 수준
  • Information: 현재의 보안 환경설정 내역에는 문제가 없는 것으로 판단되지만, 조직의 요구 수준에 따라 관련 사항을 수정, 보완하면 되는 수준

Amazon Detective

Amazon Detective는 VPC flow logs, CloudTrail, GuardDuty 등으로부터 정보를 숮비해 이를 그래프 데이터베이스에 저장한다. 보안 관리자는 이를 이용해 AWS 리소스와 관계된 의심스러운 행동, 흥미로운 행동을 식별하고 서로의 관련성을 파악할 수 있다.

Security Hub

Security Hub는 전체 AWS 환경의 보안 상태를 한자리에서 보여주는 서비스이며 다양한 보안 서비스에서 정보를 수집한다. 보안 상태와 AWS 보안 베스트 프랙티스 및 PCI DSS를 비교할 수 있게 해준다.

Amazon Fraud Detector

Amazon Fraud Detector는 기업의 데이터 유형 및 위험 허용 수준에 맞춰 조정할 수 있는 사기 행위 감지 서비스이다.

Amazon Fraud Detector는 머신러닝 기술을 이용해 사용자가 선택한 기준에 따라 정상 거래 범위를 설정할 수 있게 돕는다.

AWS Audit Manager

AWS Audit Manager는 클라우드 리소스의 사용량 및 제어 수준을 평가하고 이에 대한 감사 보고서를 생성할 수 있는 서비스로서 PCI DSS(Payment Card Industry Data Security Standard) 등 산업 표준을 기준으로 감사 항목을 자동 구성한다.

네트워크 경계 보호하기

네트워크는 해킹 등 공격에 대한 1차 방어선이며 모든 AWS 서비스는 네트워크를 통해 제공된다. AWS 인프라 설계 시 AWS 리소스와 외부 리소스, 유저가 서로 어떤 방식으로 소통할 것인지를 고려해야한다.

NACL과 보안 그룹

VPC에서 리소스는 서브넷을 통해 제공된다 NACL은 서브넷으로 유입, 서브넷에서 유출되는 트래픽을 정의한다. 반면 보안 그룹은 EC2 인스턴스와 ELB 리스너 등 개별 리소스에 대한 유입 및 유출 트래픽을 정의한다.

네트워크 보안 설계 시 인터넷을 통해 어떤 리소스에 접근하도록 할 것인지 고려해야한다. VPC는 이터넷 게이트웨이를 통해 특정 리소스에 접근할 수 있도록 한다. 각 서브넷에 부착된 라우트 테이블 또한 기본 라우트 타겟으로 인터넷 게이트웨이를 설정해야한다.

AWS WAF

웹 어플리케이션 방화벽(WAF)는 애플리케이션 로드 밸런서 또는 CloudFront 배포에 대한 HTTP, HTTPS 요청을 모니터링하며 서비스 거부 공격, 비인가 접근으로부터 애플리케이션을 보호한다.

WFA는 크로스 사이트 스크립팅, SQL 주입, 비정상적인 장문의 쿼리 문자열 등 각종 웹 어플리케이션에서 발생 가능한 공격을 방어하며 IP 주소 패턴 또는 지리적 위치에 따라 특정 트래픽을 차단할 수 있다. Lambda 함수를 이용해 주요 보안 사이트에 등록된 악의적 IP 주소와 대조한 뒤 WAF 차단 리스트에 포함도 가능하다. 웹 서버 로그를 분석하는 Lambda 함수를 작성해 HTTP flood 공격 등을 일으키는 요청을 보낸 IP 주소를 파악한 뒤 WAF 차단 리스트에 포함시킬 수 있다.

AWS Shield

AWS Shield는 DDos 공격을 방지해주며 아래 두 가지 타입이 있다.

AWS Shield Standard

모든 고객에게 자동으로 제공되는 기본 서비스이다. SYN flood 공격, UDP reflection 공격 등 레이어 3, 4 타입의 DDos 공격을 방어한다.

AWS Shield Advanced

레이어 3,4는 물론 HTTP flood 공격 등 레이어 7 타입의 DDos 공격을 방어해준다. EC2 인스턴스에 레이어 7 보호 기능을 적용하려면 EIP를 지니고 있어야 한다. 추가적인 보호 기능 외 공격 알림, 분석 리포트, 대응 팀 연중 지원을 바등ㄹ 수 있다.

AWS Shield는 5분 이내에 DDos 공격의 99%를 무력화할 수 있고, ELB에 대한 공격은 5분 이내, CloudFront 및 Route53에 대한 공격은 1초 이내에 무력화할 수 있고 그 외에는 20분 이내에 무력화할 수 있다.

AWS Firewall Manager

AWS Firewall Manager는 AWS Organization 전반에 걸쳐 적용될 수 있는 일관된 보안 규칙 세트를 구성 및 적용할 수 있도록 돕는 서비스로서, 보안 그룹 규칙, AWS Network Firewalls, DNS 방화벽 규칙, AWS WAF 규칙 등 다양한 보안 서비스 규칙의 관리를 돕는다.

데이터 암호화

데이터 암호화는 데이터의 기밀성을 보장해준다. 데이터는 상태에 따라 EBS 볼륨이나 S3 버킷 등 저장 장치에 존재하는 저장중인 데이터, VPC, 인터넷 등 네트워크를 따라 이동중인 데이터로 구분할 수 있고 암호화 방식은 이에따라 달라진다.

저장중인 데이터

저장중인 데이터는 어디에 저장되냐에 따라 암호화 방식이 달라진다. AWS에서 대부분 데이터는 S3, EBS, EFS, RDS중 하나에 속해있다. 이들 서비스는 KMS와 통합적으로 사용 가능하며, 고객이 관리하는 CMK 또는 AWS가 관리하는 CMK중 하나로 키를 적용할 수 있다.

고객관리 CMK

키 정책으로 어떤 유저가 키를 이용해 암호화 및 복호화를 할지 설정할 수 있고, 키 순회, 비활성화, 삭제 등 작업을 수행할 수 있다.

AWS 관리 CMK

키는 연 1회 자동 순회되고 직접 키를 순회, 비활성화, 삭제할 필요가 없다.

DynamoDB를 포함한 대부분의 AWS 서비스는 저장 상태일 때 KMS 관리 키를 이용한 암호화를 지원한다. 단 CloudWatch Logs 등 일부 서비스의 암호화에는 AWS CLI 명령을 이용해야 한다.

S3 데이터 암호화

S3 버킷의 경우 아래 암호화 옵션을 선택할 수 있다.

  • SSE-S3: S3 관리형 Key를 이용한 서버 측 암호화
  • SSE-KMS: KMS 관리형 Key를 이용한 서버 측 암호화
  • SSE-C: 고객 제공 Key를 이용한 서버 측 암호화
  • CSE: 클라이언트 측 암호화

암호화는 버킷이 아닌 객체 단위로 적용되므로 하나의 버킷 내 다른 암호화 옵션 적용이 가능하며 아예 적용하지 않을수도 있다.

EBS 볼륨 데이터 암호화

KMS 관리형 키를 이용해 EBS 볼륨을 암호화할 수 있다. 볼륨 생성 단계부터 암호화를 할 수 있다. 하지만 기존에 존재하던 비암호화 스냅샷 또는 비암호화 AMI로 생성하는 볼륨은 생성 단계에서 바로 암호화를 할 수 없다. 우선 비암호화 볼륨으로 스냅샷을 생성한 뒤 해당 스냅샷을 암호화해야한다.

EFS 암호화

EFS 파일 시스템 생성 시에도 암호화 기능을 활성화할 수 있다. EFS 암호화에서 파일 암호화에는 KMS 고객 마스터 키를 사용하고, 파일 및 디렉토리 이름과 같은 파일 시스템 메타데이터의 암호화에는 EFS 관리형 키를 사용한다.

이동중인 데이터

이동중인 데이터 암호화에는 TLS 인증서가 사용된다. ACM을 이용해 TLS 인증서를 생성한 뒤 로드 밸런서 또는 CloudFront 배포에 인증서를 설치하면 된다.

단 ACM으로 생성한 TLS 인증서용 프라이빗 키는 export가 불가능하므로 EC2 인스턴스 또는 온프레미스 서버에 직접 인증서를 설치할 수 없다. 대신 기존의 TLS 인증서 및 프라이빗 키를 ACM으로 임포트 하는것은 가능하다. 임포트 하는 인증서는 유효해야 하고 기한이 만료되지 않아야 한다. CloudFront에서 임포트한 인증서를 사용할 경우 반드시 us-east-1 리전으로 임포트해야한다.

Macie

Macie는 S3 버킷에 저장된 민감한 데이터를 자동으로 분류하고 데이터의 위치를 알려주는 서비스이며, 데이터가 다른 서비스 속에서 어떻게 활용되고 있는지를 보여준다. Macie는 머신러닝을 이용해 아래 방식으로 클라우드 보안 수준을 높여준다.

  • 거래 기밀, 개인 신상 정보 등 민감한 데이터 파악
  • 접근 권한 설정 수준이 지나치게 낮은 S3 버킷에 대한 경고
  • 버킷 정책 및 ACL 변경 이력 추적
  • 커스텀 데이터 식별자 기반의 다른 데이터 타입 분류

Macie는 민감한 데이터를 정책 탐지 또는 민감 데이터 탐지 영역으로 분류한다. 정책 탐지 영역에는 버킷 정책 완화 또는 암호 제거 등 버킷의 보안 수준을 감소시키는 변경 사항을 포함시키고, 민감 데이터 탐지 영역에는 S3 버킷에 저장된 각종 민감 데이터를 포함시킨다.

Macie는 이 내용을 EventBridge 및 AWS Security Hub에 자동으로 배포하며 다른 애플리케이션은 이를 참고해 상응하는 동작을 취한다.

정리

  • 효과적인 보안 제어 체계를 구현하려면 배포 단계에 더 많은 복잡성이 수반되고 떄로는 업무가 중단되기도 한다. 모든 부문에서의 보안 체계 구현을 통해, 보안과 관련된 각종 문제점을 극복할 수 있다. 구현에 적지 않은 시간과 노력이 투입되어야 하지만 보안 제어를 완성한 뒤에 효과적으로 보안 문제를 처리할 수 있으며, 시스템에 대한 해킹 및 각종 위협을 좀 더 쉽게 차단할 수 있다.
  • 클라우드 기반 각종 서비스에 대한 환경 설정을 하는 초기 단계에는 정상 작동에 초점을 맞춰야하며 서비스 정상화 이후 보안 제어 구현에 집중해야한다. 최소권한부여 원칙에 따라 IAM, 리소스 기반, 네트워크 기반 정책, 제어를 구현한다. 로그 기록도 체계적으로 관리해야한다.
  • 데이터 전송 또는 저장 전 데이터 암호화를 통해 안전하게 데이터를 관리하고, 주요 이벤트에 대한 notification을 구현해 부적절한 환경설정, 공격 징후, 오류 발생 여부를 즉시 확인할 수 있도록 해야한다. Auto Scaling, CloudFormation, 사전 설정된 AMI 등의 도구를 이용해 자동화 수준을 높이면 각종 문제를 신속하게 벗어날 수 있으며 인적 오류 가능성 또한 줄어든다.