AWS Security by Design - AWS 기반 보안, 규정 준수 및 감사 자동화 솔루션

오늘은 기본적인 보안의 틀을 제공하는 접근법에 대해 알아보겠습니다.

소개해드릴 내용은 Security by Design입니다.

보안 및 규정준수를 유지하기 위한 4단계 접근법을 주된 내용으로 하고 있습니다.

상세 자료는 아래 링크를 클릭해주세요.

http://d0.awsstatic.com/International/ko_KR/whitepapers/Compliance/Intro_to_Security_by_Design.pdf

저는 이 백서에서 안내하는 내용을 요약하고 실무에 적용될 수 있도록 저의 생각을 덧붙이겠습니다.

Security by Design(이하 SbD)

1. 서문

 SbD는 여러 산업계, 표준 및 보안 기준 전체에서 대규모의 보안 및 규정 준수를 유지하기 위한 4단계 접근법을 포괄합니다. 보안 감사가 과거 소급적으로 적용하는 반면, SbD는 AWS IT 관리 프로세스 전체에서 보안 제어를 선제적으로 구축할 수 있는 기능을 제공하는, 체계적인 보안 보장 접근법이라고 합니다.

 기존의 보안 혹은 감사가 이벤트가 발생한 이후 대응하는 체계였다고 한다면, 최근에는 이벤트가 발생하지 않도록 혹은 이벤트가 최소화되도록 하는 방향으로 관점이 바뀌고 있습니다. SbD는 이러한 맥락에서 AWS를 안전하게 구축/운영/관리되도록 하는 모델을 제시한다고 생각하시면 될 것 같습니다.

2. AWS 환경에서의 보안

  a. AWS의 Shared Responsibility에 언급합니다.(첫 포스팅을 참고해주세요)

  b. AWS 보안

    i. AWS 환경에서의 보안

      1) 보안에 구축하여 사용할 수 있는 구성 및 기능

      2) 자격 증명, 로깅 기능, 암호화 기능, 시스템 사용 및 네트워크 설정 규칙은 모두 사용자가 관리하는 AWS에 포함된 기능

    ii. 호스트 및 애플리케이션의 보안

      1) 운영 체제, 디스크에 저장된 데이터베이스 및 고객이 관리하는 애플리케이션 보안

      2) AWS 고객이 관리하기 나름(Shared Responsibility 참조)

      3) 오늘날 온프레미스 환경에서 사용하는 보안 프로세스, 도구 및 기술 역시 AWS에서 제공

  c. 클라우드 보안에서 Shared Responsibility가 중요한 개념이라는 것을 다시 한 번 확인할 수 있습니다.

  d. 위 'b.ii.3)'에서 언급한 내용이 반드시 맞지 않을 수 있습니다.

  e. 정확히 표현하자면 '오늘날 온프레미스 환경에서 사용하는 보안 프로세스, 도구 및 기술 등의 상당부분을 AWS에서 제공한다'고 해야 맞을 것 같습니다.

  f. 예를 들어 Docker에 최적화된 OS인 'CoreOS'의 경우 대부분의 보안솔루션이나 설정 등은 지원되지 않습니다.

3. Security by Design : 개요

  a. SbD를 사용하면 고객이 기본 구조를 자동화하여 AWS 환경의 보안 및 규정 준수를 안정적으로 개발할 수 있으므로 과거 항목을 제어하는 IT에 대해 규정 준수에 맞지 않는 항목을 적발하기 쉽습니다.

  b. 보안에 대한 클라우드 인프라 접근법에 보안 되고 반복 가능한 접근법을 만듦으로써 고객은 특정 인프라 제어 요소를 캡처, 보호 및 제어할 수 있습니다.

  c. 이러한 요소는 AWS Identify and AccessManagement(IAM), AWS Key Management Services(KMS) 및 AWS CloudTrail의설계를 사전 정의하고 제한하는 등, IT 요소의 보안 규정 준수 프로세스 구축을 가능케 합니다.

4. Security by Design : 접근법

  a. 1단계 – 요구 사항 확인

    i. 정책에 대해 간략히 설명

    ii. AWS에서 상속한 제어를 문서화

    iii. AWS 환경에서 소유하고 동작하는 제어를 문서화

    iv. AWS IT 환경에서 적용하고자 하는 보안 규칙을 결정

    v. 이 단계가 실행되기 위해서는 사전준비가 필요합니다.

      1) AWS와 Business에 대한 깊은 이해도

      2) Architecture 초안과 리소스 사용계획

    vi. 이런 사전준비가 되지 않는다면 이 단계는 상당히 많은 시간이 소요될 것입니다.

  b. 2단계 – 요구 사항 및 구현 조건에 맞는 "골드 환경" 구축

    i.  암호화 요구사항(S3 객체에 대해 서버 측 암호화 설정)

      - S3 객체 뿐만 아니라 Data at Rest와 Transport Data에 대한 암호화도 고려해야 합니다.

    ii. 리소스에 대한 권한(특정 환경에 적용할 역할)

    iii. 허가할 컴퓨팅 이미지(허가한 서버의 골드 이미지 기반) 및 설정해야 하는 로깅 종류(사용할 수 있는 모든 리소스에 CloudTrail 사용설정 등)

    iv. 위와 같은 AWS 구성 값 양식으로 필요한 구성을 정의

    v. “골드 환경”을 만드는 방법에 대한 추가 정보는 AWS 숙련 아키텍트, AWS 전문가 서비스 및 파트너의 IT 전환 리더 등으로부터 얻을 수 있습니다.

      - 위의 작업들은 전문가의 도움을 받는 것이 가장 효율적인 방법이라고 생각합니다.

  c. 3단계 – 템플릿 사용 설정

    i. 서비스 카탈로그를 설정하고 카탈로그에 템플릿을 사용하도록 설정

    ii. 신규 구축 환경에 "골드 환경"을 사용하도록 설정

    iii. "골드 환경" 보안 규칙에 맞지 않는 환경은 만들 수 없도록 함

    iv. 이 단계가 잘 진행되기 위해서는 선행단계가 매우 잘 진행되어야 합니다.

  d. 4단계 – 검증 작업 수행

    i. 위에서 정의한 규칙을 감사지침으로 사용할 수 있음

    ii. . AWS Config를 사용하면 환경의 현재 상태를 캡처할 수 있으며, 그런 다음 사용자의 "골드 환경" 규칙과 비교해 볼 수 있음

    iii. On-prem 환경에 비해 매우 효율적인 보안모델을 디자인했으나 잘 활용하기 위해서는 자동화가 필요합니다.

    iv. 4단계에서 끝나는 게 아니라 모니터링과 자동화, 분석 등에 대한 후속조치가 필요합니다.

5. Security by Design의 결과

  a. SbD 아키텍처는 다음과 같은 목표를 달성하도록 만들어졌습니다.

    i. 수정 권한이 없는 사용자가 재정의할 수 없는 강제 기능 생성

    ii. 안정적인 제어 작업 구축

    iii. 지속적인 실시간 감사 가능

    iv. 거버넌스 정책을 스크립팅하는 기술

  b. 앞서 설명했던 것처럼 자동화가 되지 않으면 원하는 목표를 달성하지 못할 수도 있습니다.

  c. 이 모델을 고려하시는 분들은 자동화까지를 목표로 하셔야 합니다.

6. 추가 - 자동화

  a. 모니터링과 감사의 기본은 로그수집입니다.

  b. 수집된 로그 중 모니터링 대상에 맞는 로그를 선별하여야 합니다.

  c. 모니터링 기준은 여러분의 보안정책과 비즈니스에 맞게 설정하셔야 합니다.

    i. 임계치 방식

    ii. 이벤트 탐지 방식

    iii. 통계 방식

    iv. 위 셋의 혼합 방식

SbD를 빠르게 적용할 수 있는 기초 리소스를 AWS에서 제공하고 있습니다.

맨 위 링크에서 확인하실 수 있습니다.