Category: Security, Identity, & Compliance*


AWS 최신 기능 모음 – Amazon RDS 사용자 인증, SES 데이터 추적 및 AWS 솔루션 업데이트 등

AWS의 새로 출시된 몇 가지 서비스와 기능을 따라잡기 위해, 이 게시물에서는 지난 여름부터 9월 말까지 출시된 몇 가지 멋진 서비스를 요약 정리하고자 합니다. 더 자세한 업데이트 내역은 AWS 신규 기능 업데이트 페이지를 참고하세요.

오늘 여러분께 소개할 새로운 서비스와 기능은 다음과 같습니다.

  • RDS MySQL 및 Amazon Aurora의 데이터베이스 사용자 인증을 위한 AWS IAM
  • Amazon SES 평판 대시보드
  • Amazon SES 확인 및 클릭 추적 지표
  • Solutions Builder 팀의 서버리스 이미지 핸들러
  • Solutions Builder 팀의 AWS Ops Automator

그럼 자세히 살펴보겠습니다.

RDS MySQL 및 Amazon Aurora의 데이터베이스 사용자 인증을 위한 AWS IAM

Amazon RDS 데이터베이스 인스턴스 및 클러스터에 대한 액세스를 AWS IAM으로 관리하고 싶지 않으셨습니까? 이제 그 소원이 이루어졌습니다. Amazon RDS에서 MySQL용 Amazon RDS 및 Amazon Aurora DB에 대한 데이터베이스 액세스를 IAM으로 관리하는 기능을 출시했습니다.

이 새로운 서비스 기능에서 가장 마음에 드는 부분은 시작하기가 정말 쉽다는 점입니다. IAM을 이용한 데이터베이스 사용자 인증을 활성화하려면 DB 인스턴스 또는 클러스터를 생성, 수정 또는 복원할 때 [Enable IAM DB Authentication] 확인란을 선택하면 됩니다. RDS 콘솔, AWS CLI 및/또는 Amazon RDS API를 사용해서 IAM에 액세스하도록 할 수 있습니다.

IAM 인증을 사용하도록 데이터베이스를 구성하면, 클라이언트 애플리케이션은 데이터베이스 엔진에 대해 자신을 인증할 때 IAM 보안 토큰 서비스에서 생성된 임시 보안 자격 증명을 제출합니다. 데이터베이스 엔진에 암호를 제시하는 대신 이러한 자격 증명을 사용하는 것입니다.

IAM으로 MySQL 및 Aurora에 대한 목표 권한 및 인증을 제공하는 자세한 방법은 Amazon RDS 사용 설명서에서 알아볼 수 있습니다.

Amazon SES 평판 대시보드

Amazon Simple Email Service 고객이 이메일 전송을 위한 모범 사례 지침을 활용할 수 있도록 이메일 전송 상태를 포괄적으로 보고해 주는 평판 대시보드가 출시되었다는 소식을 기쁜 마음으로 알려 드립니다. 이제 고객들은 전반적인 계정 상태, 전송 지표, 규정 준수 또는 시행 상태를 파악하여 전송 중인 이메일을 선제적으로 관리할 수 있습니다.

평판 대시보드는 다음과 같은 정보를 제공합니다.

  • 계정 상태: 계정 상태에 대한 설명입니다.
    • 정상 – 현재 계정에 영향을 주는 문제가 없습니다.
    • 관찰 – 계정이 관찰 상태입니다. 일시 중지 사태를 방지하기 위해 관찰을 유발한 문제를 해결해야 합니다.
    • 관찰 종료 결정 보류 중 – 계정이 관찰 상태입니다. Amazon SES 팀원이 해당 계정을 검토한 뒤 조치를 취해야 합니다.
    • 종료 – 계정이 종료되었습니다. Amazon SES를 사용해 이메일을 보낼 수 없습니다.
    • 종료 보류 중 – 계정이 관찰 상태이고 관찰 상태를 유발한 문제가 해결되지 않았습니다.
  • 반송 메일 발생률: 반송된 이메일의 비율과 반송률 상태에 대한 메시지입니다.
  • 불만 제기 비율: 수신자가 스팸으로 보고한 이메일의 비율과 불만 제기율에 대한 상태 메시지입니다.
  • 알림: 기타 계정 평판 문제에 대한 메시지입니다.

Amazon SES 확인 및 클릭 추적 지표

최근 Amazon SES에 추가된 또 한 가지 흥미로운 기능은 이메일 확인 및 클릭 추적 지표입니다. SES 고객은 이제 이메일 확인 및 클릭 추적 지표 기능으로 보낸 이메일의 확인 시점과 이메일 내 링크의 클릭 시점을 추적할 수 있습니다. 이 SES 기능을 사용하면 이메일 캠페인에 대한 참여도와 효과를 더욱 정확하게 추적할 수 있습니다.

이 기능은 어떻게 작동할까요?

이메일 확인 추적 기능을 사용하는 경우, SES에서는 사용자가 추적하도록 선택한 이메일에 투명한 작은 이미지를 추가합니다. 받는 사람이 이메일을 열어 보면 메일 애플리케이션 클라이언트가 앞서 언급한 추적 이미지를 로드하고, 이에 따라 Amazon SES에서 확인 추적 이벤트가 트리거됩니다. 이메일 클릭(링크) 추적의 경우 이메일 및/또는 이메일 템플릿에 들어 있는 링크가 사용자 지정 링크로 바뀝니다. 받는 사람이 이 사용자 지정 링크를 클릭하면 SES에 클릭 이벤트가 기록되고, 이메일 사용자는 사용자 지정 링크를 통해 원본 이메일의 링크 대상으로 리디렉션됩니다.

새로운 확인 추적 및 클릭 추적 기능을 사용하려면 SES에서 새로운 구성 집합을 생성하거나 기존 구성 집합을 변경하면 됩니다. 두 방법 중 하나를 선택한 다음, 확인 및 클릭 지표를 수신하기 위한 AWS 서비스로 Amazon SNS, Amazon CloudWatch 또는 Amazon Kinesis Firehose를 선택하십시오. 이제 전송할 모든 이메일에 대해 이러한 새 기능을 적용하는 새로운 구성 집합만 선택하면 됩니다.

AWS 솔루션: 서버리스 이미지 핸들러 및 AWS Ops Automator

AWS Solution Builder 팀은 AWS에서 애플리케이션 빌드 및 실행을 위해 일반적인 아키텍처 질문에 대한 답변을 쉽게 찾을 수 있도록 많은 노력을 기울이고 있습니다. 이러한 솔루션은 AWS Answers 페이지에서 찾을 수 있습니다. 올 가을 초 AWS Answers에 발표된 두 가지 새로운 솔루션은 서버리스 이미지 핸들러AWS Ops Automator입니다.
서버리스 이미지 핸들러AWS 클라우드의 이미지 취급 과정을 실시간으로 처리, 조작 및 최적화하는 고객을 위한 지원 솔루션으로 개발되었습니다. 이것은 캐싱을 위해 Amazon CloudFront를, 실시간 이미지 검색과 수정을 위해 AWS Lambda를, 이미지 저장을 위해 Amazon S3 버킷을 결합한 솔루션입니다. 또한 서버리스 이미지 핸들러는 이미지를 더 세밀하게 조작, 처리 및 최적화할 수 있도록 오픈 소스 이미지 처리 제품군인 Thumbor를 사용합니다.

AWS Ops Automator 솔루션의 자동 작업 프레임워크에서 시간 기반 트리거나 이벤트 기반 트리거를 사용하여 스냅샷 예약 등의 수작업을 자동화할 수 있습니다. 여기에는 작업 감사 추적, 로깅, 리소스 선택, 조정, 동시 처리, 작업 완료 전달 및 API 요청 재시도 등이 포함됩니다.

이 솔루션에는 다음 AWS 서비스가 포함됩니다.

  • AWS CloudFormation: 마이크로서비스 및 솔루션에서 생성한 작업 구성의 핵심 프레임워크를 시작하기 위한 템플릿
  • Amazon DynamoDB: 이벤트 트리거 및 리소스를 정의하기 위한 작업 구성 데이터와 작업 및 오류의 결과를 저장하는 테이블
  • Amazon CloudWatch Logs: 경고 및 오류 메시지 추적을 위한 로깅 기능 제공
  • Amazon SNS: 솔루션에서 로깅 정보를 보내는 구독자 이메일 주소로 관련 주제의 메시지 전송

즐겁게 탐구하고 코딩하시기 바랍니다.

Tara

이 글은 Just in Case You Missed It: Catching Up on Some Recent AWS Launches의 한국어 번역입니다.

애플리케이션 로드 밸런서(ALB) 기반 서버 이름별(SNI) 다중 TLS 인증서 지원

오늘부터 우리는 애플리케이션 로드 밸런서(ALB)에서 서버 이름 표시(SNI)를 사용해 다중 TLS/SSL 인증서 지원을 시작합니다. 이제 단일 로드 밸런서 뒤에서 각각 자체 TLS 인증서를 갖는 다수의 TLS 보안 애플리케이션을 호스팅할 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의TLS 인증서를 자동으로 선택합니다. 이러한 새로운 기능은 추가 요금 없이 제공됩니다.

새로운 기능의 사용 방법에 대한 TL;DR을 찾고 있다면 여기를 클릭하십시오. 저처럼 TLS(Transport Layer Security)에 대해서 약간 서툴다고 생각한다면 아래 이어지는 내용까지 계속해서 읽어주십시오.

TLS? SSL? SNI?

SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다. 하지만 쉽게 이해할 수 있도록 이번 포스트에서는 TLS라는 용어를 사용하겠습니다.

TLS는 암호, 쿠키, 신용 카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 즉 인증 기관(CA)을 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.

SNI 지원이 시작되면서 이제는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 되었습니다. 다수의 인증서가 필요한 가장 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 단순 패턴이 일치하는 하위 도메인에서만 사용 가능합니다. 또한 SAN 인증서가 다수의 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.

포럼과 reddit, 그리고 저의 이메일 수신함으로 가장 자주 도착하는 요청 중 하나가 바로 TLS의 서버 이름 표시(SNI) 확장을 사용하여 클라이언트 인증서를 선택할 수 있도록 해달라는 것이었습니다. TLS는 HTTP 아래 단계인 전송 레이어에 속하기 때문에 클라이언트가 요청하는 호스트 이름을 알지 못합니다. 이때 클라이언트가 처음 연결 시 서버에게 “이것이 내가 인증서를 원하는 도메인입니다”라고 지정할 수 있도록 도와주는 것이 바로 SNI입니다. 그러면 서버가 올바른 인증서를 선택하여 클라이언트에게 응답할 수 있습니다. 오늘날 모든 웹 브라우저와 대다수 클라이언트는 SNI를 지원합니다. 실제로 CloudFront에 연결되는 클라이언트의 99.5% 이상이 SNI를 지원하고 있습니다.

ALB의 스마트 인증서 선택

ALB의 스마트 인증서 선택은 SNI보다 한 걸음 더 나아갑니다. 유효한 도메인 이름 목록이 저장되는 것 외에도 키 교환 유형과 서버가 지원하는 암호화, 그리고 인증서 서명에 사용되는 알고리즘(SHA2, SHA1, MD5)이 인증서에 설명되어 있습니다. TLS 연결을 구성하려면 먼저 클라이언트가 프로토콜 버전, 확장자, 암호 그룹, 압축 방법 등 클라이언트의 기능을 간략히 나타낸 “ClientHello” 메시지를 전송하여 TLS 핸드섀이크를 시작합니다. 그러면 ALB의 스마트 선택 알고리즘이 각 클라이언트가 지원하는 기능에 따라 연결에 적합한 인증서를 선택하여 클라이언트에게 보냅니다. ALB는 고전적인 RSA 알고리즘과 최근에 등장하여 더욱 빠른 속도를 자랑하는 타원 곡선(Elliptic-curve) 기반 ECDSA 알고리즘을 모두 지원합니다. ECDSA 지원이 SNI만큼 클라이언트 사이에 널리 퍼진 것은 아니지만 오늘날 모든 웹 브라우저에서는 이미 지원되고 있습니다. 속도가 더욱 빠를 뿐만 아니라 CPU 사용량도 적기 때문에 지연 시간이 매우 낮은 애플리케이션에 유용할 뿐만 아니라 모바일 애플리케이션에서 사용되는 배터리 양을 절약하는 데도 매우 효과적입니다. ALB가 TLS 핸드섀이크를 통해 각 클라이언트가 지원하는 기능을 알 수 있기 때문에 RSA 인증서와 ECDSA 인증서를 동일한 도메인에 모두 업로드할 수 있습니다. 그러면 ALB가 각 클라이언트마다 가장 알맞은 인증서를 자동으로 선택합니다.

ALB와 SNI의 사용

여기에서 2개의 웹사이트인 VimIsBetterThanEmacs.comVimIsTheBest.com를 예로 들겠습니다. 저는 이 두 도메인을 구매하여 Amazon Route 53에 호스팅한 후 각 도메인에 사용할 인증서 2개를 AWS Certificate Manager(ACM)에 프로비저닝하였습니다. 이때 단일 ALB를 통해 두 사이트를 모두 안전하게 운영하고 싶다면 콘솔에서 인증서 2개를 빠르게 추가할 수 있습니다.

먼저 콘솔에서 내 로드 밸런서를 선택한 후 리스너 탭으로 이동하여 “view/edit certificates”를 선택합니다.

그런 다음 왼쪽 상단 모퉁이에 있는 “+” 버튼을 사용하여 인증서를 선택한 다음 “Add” 버튼을 클릭합니다.

이제 다 끝났습니다. GUI 사용에 익숙하지 않다면 AWS 명령줄 인터페이스(CLI)(또는 SDK)를 사용하여 새로운 인증서를 쉽게 추가하는 방법도 있습니다.

aws elbv2 add-listener-certificates --listener-arn <listener-arn> --certificates CertificateArn=<cert-arn>

알아야 할 것들

  • ALB 액세스 로그에는 클라이언트가 요청한 호스트 이름과 사용한 인증서 ARN이 포함됩니다. “hostname” 필드가 비어있다면(“-“로 표시) 클라이언트가 요청에서 SNI 확장을 사용하지 않았기 때문입니다.
  • ACM 또는 IAM에서는 어떤 인증서든 사용할 수 있습니다.
  • 동일한 도메인이라고 해도 다수의 인증서를 보안 리스너로 바인딩할 수 있습니다. 그러면 ALB가 클라이언트 기능을 포함하여 여러 가지 요인에 따라 최적의 인증서를 선택합니다.
  • 클라이언트가 SNI를 지원하지 않으면 ALB가 기본 인증서(리스너 생성 시 지정한 인증서)를 사용합니다.
  • 새로운 ELB API 호출은 AddListenerCertificates, RemoveListenerCertificates, DescribeListenerCertificates 등 세 가지가 있습니다.
  • 로드 밸런서 1개당 바인딩이 가능한 인증서는 최대 25개입니다(기본 인증서 제외).
  • 이번에 새롭게 추가된 기능은 처음부터 AWS CloudFormation에서 지원됩니다.

새로운 기능의 사용 예는 저의 동료인 Jon Zobrist가 만든 웹사이트(https://www.exampleloadbalancer.com/)에서 찾아볼 수 있습니다.

저는 개인적으로 이 기능을 사용할 예정이며 수많은 AWS 사용자들 역시 커다란 이점을 경험하게 될 것입니다. AWS 사용자들을 위해 이처럼 멋진 기능을 개발하느라 수고해 주신 Elastic Load Balancing 팀에게 깊은 감사를 드립니다.

Randall;

이 글은 Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI 한국어 번역입니다.

Amazon Macie 신규 출시 – 기계 학습 기반 자동 콘텐츠 검색, 분류 및 보안 설정 서비스

Amazon Macie는 Amazon S3에 저장된 데이터를 기계 학습 기반으로 자동으로 검색하고 분류 할 수 있는  서비스입니다. 데이터가 Macie에 의해 분류되면, 각 데이터 항목에 비즈니스 가치를 할당 한 다음 데이터를 지속적으로 모니터링하여 접근 패턴을 기반으로 의심스러운 활동을 탐지합니다. 이를 통해 서비스명의 뜻 그대로 여러분의 안전한 무기(Weapon)이 될 수 있습니다.

Macie 서비스의 주요 기능은 다음과 같습니다.

  • 데이터 보안 자동화 : 데이터를 분석, 분류 및 처리하여 기록 패턴, 데이터에 대한 사용자 인증, 데이터 접근 위치 및 시간을 파악
  • 데이터 보안 및 모니터링 : CloudWatch Events 및 Lambda를 통해보고 된 문제의 자동 해결과 함께 탐지 된 예외에 대한 사용 로그 데이터를 적극적으로 모니터링
  • 사전 손실 방지를 위한 데이터 가시성 : 스토리지 데이터의 세부 사항에 대한 관리 가시성을 제공하는 동시에 매뉴얼 방식 없는 즉시 보호 기능 제공
  • 데이터 연구 및 리포트 : 데이터 리포트 및 경고 관리 요구 사항에 대한 관리 구성 허용

Macie는 자연어 처리 (NLP)를 위한 기계 학습 알고리즘을 사용하여  S3 버킷의 데이터 분류를 자동화 할 수 있습니다. 또한, Macie의 예측 분석 알고리즘을 활용하여 데이터 접근 패턴을 동적으로 분석 할 수 있습니다. 모델 학습은 가능한 정보를 알려주고 가능한 의심스러운 행동에 대해 알려주는 데 사용됩니다. Macie는 또한 개인 식별 정보 (PII) 또는 민감한 개인 정보 (SP)의 일반적인 출처를 탐지하기 위해 특별히 엔진을 실행합니다. Macie는 AWS CloudTrail을 활용하고 S3 버킷의 PUT 요청에 대한 Cloudtrail 이벤트를 지속적으로 확인하고, 새로운 개체를 거의 실시간으로 자동 분류합니다.

Macie는 AWS 클라우드 보안 및 데이터 보호를 위한 강력한 도구이면서, 자원 관리, 표준 규정 준수 요구 사항 및 감사 표준을 지원할 수도 있습니다. 2018년 5월 25일 시행 될 수 있는 EU의 GDPR (General Protection Data Regulation)은 가장 엄격한 개인 정보 보호 규정입니다. Amazon Macie는 개인 식별 정보 (PII)를 확인하고, 고객에게 대시 보드를 제공합니다 이를 통해 고객이 데이터 암호화 및 익명화에 관한 GDPR 규정을 준수 할 수 있습니다. AWS Lambda와 결합하면 Macie는 GDPR 문제를 해결하는 데 도움이 되는 강력한 도구가 됩니다.

Amazon Macie 살펴 보기
이제 서비스를 잠깐 돌아 보겠습니다. 먼저 Macie 콘솔에서 Get Started을 클릭하여 데이터 분류 및 보호를 시작합니다.

아래에서 보시다시피 Amazon Macie 서비스를 사용하려면 서비스에 적합한 IAM 역할을 만들어야 하며 AWS CloudTrail을 활성화해야 합니다. (오늘 부터 AWS CloudTrail은 모든 고객이 자동으로 활성화 되었습니다.)

Macie를 쉽게 설정할 수 있도록 Macie User Guide에서 제공되는 CloudFormation 용 샘플 템플릿을 활용하여 필요한 IAM 역할 및 정책을 설정하면, 사용자가 직접 IAM 역할 및 정책을 설정하기 만하면 됩니다. (CloudTrail 시작하기 문서 참고)

AWS 계정이 여러 가지인 경우, Macie 서비스를 사용하는 마스터 계정과 다른 계정은 Macie 서비스와 통합 할 수 있습니다. 회원 계정의 사용자는 Macie 콘솔에 접근하기 위해 IAM 역할을 사용하여 마스터 계정에 대한 접근을 허가 받아야 합니다.

이제 IAM 역할이 만들어지고 CloudTrail이 활성화되었으므로 Enable Macie 버튼을 클릭하여 Macie의 데이터 모니터링 및 보호를 시작합니다.


여러분 계정에서 Macie가 서비스를 시작하면, 서비스 메인 화면이 나타나고 계정의 기존 알림이 표시됩니다. 방금 서비스 이용을 시작했기 때문에 현재 현재 현재 알림이 없습니다.

Macie 서비스를 사용해 보기 위해, S3 버킷 중 일부는 Macie와 연결해 보겠습니다. 그러나, 이미 AWS CloudTrail Management API를 사용하여 정보를 분석하고 처리하고 있기 때문에, Macie가 모니터링을 시작할 S3 버킷을 지정할 필요가 없습니다. 여기서는 CloudTrail의 특정 버킷에서 개체 수준의 API 이벤트를 모니터링 해 보겠습니다.

Amazon S3와 통합하기 위해 Macie 콘솔의 Integrations 탭으로 이동합니다. Integrations 탭에서 AccountsServices라는 두 가지 옵션이 표시됩니다. 계정 옵션은 회원 계정을 Macie와 통합하고 데이터 보존 정책을 설정하는 데 사용됩니다. 특정 S3 버킷을 Macie와 통합하려는 경우, Services 옵션을 클릭하고 Services 탭으로 이동합니다.


이제 Macie를 S3 서비스와 통합하면, S3 데이터 이벤트에 대한 로그를 저장하기 위한 Cloudtrails과 S3 버킷이 생성됩니다. 이제 계정 선택드롭 다운을 사용하여, Select an account 합니다. 여러분 계정을 선택하면 통합에 사용할 수 있는 서비스가 표시됩니다. Add 버튼을 클릭하여 Amazon S3 서비스를 선택하겠습니다.

이제 Macie가 분석 할 버킷을 선택할 수 있습니다. Review and Save 버튼을 선택하면 Save 버튼을 클릭하여 객체 수준 로깅을 확인하는 화면으로 이동합니다.

다음으로 Macie 데이터 분류를 맞춤 설정할 수 있는 방법을 살펴 보겠습니다.

앞에서 설명 드린 대로 Macie는 데이터를 자동으로 모니터링하고 분류합니다. Macie가 데이터를 식별하면, 데이터 개체를 파일 및 콘텐츠 유형 별로 분류합니다. Macie는 SVM (Support Vector Machine) 분류를 사용하여, 파일의 메타 데이터 외에도 S3 객체 내의 내용을 분류합니다.  딥러닝/기계 학습 분야에서 SVM은 데이터 분류 및 회귀 분석에 사용되는 학습 알고리즘이 있는 학습 모델입니다. Macie는 작성할 수 있는 소스 코드를 포함하여 데이터 콘텐츠의 정확한 탐지를 지원하기 위해 최적화 된 다양한 콘텐츠 유형의 데이터를 사용하여 SVM 분류를 학습합니다.

Macie는 데이터 개체 또는 파일 당 하나의 콘텐츠 형식만 할당하지만, 이러한 개체를 분류하는 Macie 서비스에서  콘텐츠 형식 및 파일 확장명을 사용하거나 사용하지 않도록 설정할 수 있습니다. Macie가 데이터를 분류하면, 개체의 위험 수준을 1에서 10 사이의 값으로 지정합니다. 위험도가 가장 높은 위험도는 10이며 가장 낮은 위험도는 1입니다.

Macie에서 데이터 분류를 맞춤 설정하려면 Settings 탭으로 이동합니다. 이제 Macie 분류 설정을 활성화 또는 비활성화 할 수 있는 선택 항목이 표시됩니다.


예를 들어, Macie의 File extension을 선택합니다.  Macie가 분류를 위해 추적하고 사용하는 파일 확장자 목록이 제시됩니다.

테스트로 Android 애플리케이션 설치 파일의 apk 파일 확장명을 편집하고, 드롭 다운에서 No – disabled를 선택하고 Save 버튼을 클릭하면, 파일의 모니터링을 비활성화합니다. 물론, 나중에 안드로이드 개발 바이너리를 포함하여 데이터 파일의 전체 컬렉션을 안전하게 유지하고자 할 때, 이 기능을 다시 사용하도록 설정할 수 있습니다.

마지막 한가지는 Macie를 통한 데이터 분류는 개인 혹은 비즈니스와 표준 규정 등 중요한 정보를 취급하기 위해 저장된 데이터와 자원을 쉽게 분류하여 가시성을 제공합니다.

이제 Macie를 통해 분류하고 모니터하는 데이터를 탐험을 시작하면, 마지막에는 Macie 서비스 콘솔 대시 보드를 살펴 보게 됩니다.

Macie 대시 보드는 Macie가 여러분의 데이터를 모니터하고 분류함에 따라 수집 된 모든 데이터와 활동에 대한 완벽한 시각화를 제공합니다. 대시 보드에는 범주별로 그룹화 된 측정 항목 및 보기가 표시되어 데이터에 대한 다양한 시각적 시각을 제공합니다. 대시 보드 화면에서 통계 관점으로 직접 Research 탭으로 이동하여 통계치를 기반으로 쿼리를 작성하고 실행할 수 있습니다. 이 쿼리는 가능한 보안 문제 또는 문제에 대한 알림을 위해, 사용자 지정된 경고를 설정하는 데 사용할 수 있습니다. ResearchAlerts 탭을 둘러 볼 기회는 없었지만, Macie 사용자 가이드에서 이러한 기능에 대한 자세한 정보를 확인할 수 있습니다.

대시 보드로 되돌아 가면, Macie 대시 보드에는 투어 중 생중계, 통계 및 기능 등 많은 리소스가 있으므로, 이들 기능의 개요를 알려 드리겠습니다.

Dashboard 통계치는 아래와 같습니다.

  • 고위험 S3 개체 – 10까지 8의 경우, 위험 수준 데이터 객체
  • 총 이벤트 발생 – Macie 이후의 모든 이벤트 발생의 총량
  • 총 사용자 세션 – 데이터 CloudTrail의 5 분 스냅 샷

Dashboard Views – 모니터링 데이터 및 활동의 다양한 항목을 표시

  • S3 objects for a selected time range
  • S3 objects
  • S3 objects by personally identifiable information (PII)
  • S3 objects by ACL
  • CloudTrail events and associated users
  • CloudTrail errors and associated users
  • Activity location
  • AWS CLoudTrail events
  • Activity ISPs
  • AWS CloudTrail user identity types

요약

지금까지 Amazon Macie 서비스에 대해 간략히 알아보았습니다. Macie는 S3에 저장된 데이터를 보호하는 데, 기계 학습 및 딥러닝을 활용한 신규 데이터 보안 서비스입니다.  Macie에 자연 언어 처리 (NLP)를 사용하면, 쉽게 단순히 서비스를 사용하여 높은 정확도 분류 및 즉각적인 데이터 보호를 시작 할 수 있습니다. 대화형 대시 보드는  데이터, 데이터 접근 및 API 호출의 거대한 흐름을 분석 할 수 있는 가시성을 제공합니다.

더 자세한 것은 제품 페이지 또는 사용 설명 문서를 참고 하시기 바랍니다.

Tara

이 글은 Launch – Hello Amazon Macie: Automatically Discover, Classify, and Secure Content at Scale 의 한국어 편집본입니다.

[기술 백서] AWS WAF를 통해 OWASP 상위 10 웹 애플리케이션 취약점 방어하기

Open Web Application Security Project (OWASP)의 웹 애플리케이션 보안 향상 프로젝트를 알고 계시나요? 그 중에서도 OWASP Top 10이라는 가장 중요한 10 가지 애플리케이션 보안 결함 목록이 있습니다. 이 목록은 최근 웹 사이트 및 웹 애플리케이션에서 자주 발견되는 일반적인 취약점에 대한 내용을 포함합니다.

AWS WAF는  이전 블로그 글에서 설명 드린 대로  SQL 인젝션 및 크로스 사이트 스크립팅과 같은 애플리케이션 계층 공격으로부터  사용자 지정 규칙을 만들어 허용 및 거부 트래픽 유형을 정의함으로서 보안을 강화할 수 있습니다.

신규 기술 백서 Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities 에서는 OWASP의 상위 열 가지 취약점을 완화하기 위한  AWS WAF 사용 방법을 설명합니다. 즉, OWASP Top 10 (공식적으로 A1에서 A10으로 알려짐)에서 가장 중요한 항목에 대한 세부적이고 구체적인 완화 전략 및 구현 세부 정보가 포함됩니다.

지금 다운로드 하세요!
한국어 기술 백서(영문)는 각 취약점에 대한 배경 및 배경을 제공하고 WAF 규칙을 작성하고 차단하는 방법을 보여줍니다. 또한 HTTP 요청에 제공된 매개 변수를 미리 검증하기 위해 Lambda @ Edge를 사용하는 아주 멋진 제안을 포함하여 심층 방어 권고를 제공합니다.

이 백서에서는 권장 조건 유형 및 규칙과 함께 웹 ACL을 만드는 동반자 AWS CloudFormation 템플릿에 연결됩니다. 이 템플릿을 자신의 작업을위한 시작점으로 사용하여 더 많은 조건 유형과 규칙을 원하는대로 추가 할 수 있습니다.

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS WAF Basic OWASP Example Rule Set

## ::PARAMETERS::
## Template parameters to be configured by user
Parameters:
  stackPrefix:
    Type: String
    Description: The prefix to use when naming resources in this stack. Normally we would use the stack name, but since this template can be us\
ed as a resource in other stacks we want to keep the naming consistent. No symbols allowed.
    ConstraintDescription: Alphanumeric characters only, maximum 10 characters
    AllowedPattern: ^[a-zA-z0-9]+$
    MaxLength: 10
    Default: generic
  stackScope:
    Type: String
    Description: You can deploy this stack at a regional level, for regional WAF targets like Application Load Balancers, or for global targets\
, such as Amazon CloudFront distributions.
    AllowedValues:
      - Global
      - Regional
    Default: Regional
...

Jeff;

이 글은 Prepare for the OWASP Top 10 Web Application Vulnerabilities Using AWS WAF and Our New White Paper 의 한국어 번역입니다.

AWS Organizations – 정책 기반 멀티 계정 조직 관리 서비스 정식 출시

많은 AWS 고객이 여러 개의 AWS 계정을 관리하고 있습니다. 이러한 상황은 여러 가지 이유로 발생할 수 있습니다. 때로는 점진적인 개발 방식의 진화에 따라 서비스 팀과 부서가 분산되어 진화 하는 경우나, 합병 및 인수를 통해 성장하는 경우도 기존 계정을 사용해야 합니다. 표준 규정 준수를 위한 엄격한 가이드 라인을 준수하거나 개발, 테스트 및 정식 서비스을 위해 별개의 계정을 사용하여 애플리케이션 테스트 및 배포를 할 때 이를 격리하기 위해 여러 계정을 정기적으로 생성합니다.

계정이 많아지면 확장성 높은 방식의 관리가 필요합니다. 팀 단위, 부서 단위 또는 애플리케이션 단위의 수 많은 계정을 따로 관리하는 대신 전체 계정, 일부 계정 또는 개별 계정에 쉽게 적용 할 수 있는 접근 제어 정책이 필요하다는 피드백을 많이 받았습니다. 대부분의 경우 이러한 고객은 요금 청구 및 비용 관리에 관심이 있으며, 대량 할인 및 예약 인스턴스와 같은 AWS 가격 책정이 각 계정에 적용되는 관리하고자 합니다.

AWS Organizations 정식 출시
이러한 요구 사항을 지원하기 위해 만든 AWS Organizations 서비스를 미리보기에서 정식으로 출시합니다. 본 서비스를 사용하여 조직 단위(OU)의 계층 구조를 만들고, OU에 각 계정을 할당하고, 정책을 정의한 다음 전체 계층 구조에 적용하고, OU를 선택하거나, 또는 OU를 선택하여 여러 AWS 계정을 중앙에서 관리 할 수 ​​있습니다. 기존 AWS 계정을 조직에 가입하도록 초대 할 수 있으며 새 계정을 만들 수도 있습니다. 이 모든 기능은 AWS 관리 콘솔AWS 명령어 모드 (CLI), AWS Organizations API를 사용할 수 있습니다.

다음은 본 서비스를 을 이해하는 데 도움이 되는 몇 가지 중요한 용어 및 개념입니다 (사용자가 AWS 멀티 계정 전체와 마스터 계정을 담당하고 있다고 가정합니다.)

Organization은  여러분이 관리하는 통합 AWS 계정 세트입니다. 새로 생성 된 Organization에서는 서비스 제어 정책과 같은 정교한 계정 제어 기능 구현할 수 있습니다. 이를 통해 조직 관리자는 허용 및 차단 AWS API 함수 목록과 개별 계정에  배치하고, 리소스를 관리 할 수 ​​있습니다. 예를 들어, R&D 팀에 다양한 AWS 서비스에 대한 접근 권한을 부여한 후, 개발 및 테스트 계정에 대해 좀 더 엄격한 접근 제어를 할 수 있습니다. 또는, 정식 서비스에는 (의료 정보만을 다루는 규정을 준수하는) HIPAA 자격이 있는 AWS 서비스에만 액세스 할 수 있습니다.

기존 고객 중 일부는 AWS 통합 결제 (Consolidated Billing) 기능을 사용합니다. 이를 통해 여러 AWS 계정에서 계정 사용량을 하나의 청구서(Invoice)로 모아서  비용을 추적하는 중앙 집중식 방법을 제공하는 최종 지불 계정을 선택할 수 있습니다.

이번 출시와 함께 현재 통합 결제를 사용하는 고객은 모든 기능을 제공하는 가상 조직을 갖게 되었습니다. 그러나, 기본적으로 현재 제공되는 새로운 기능 (예 :서비스 제어 정책)은 없습니다. 이러한 고객은 AWS Organization의 모든 기능을 쉽게 사용할 수 있습니다. 이는 조직의 마스터 계정에서 모든 Organization 기능을 사용하도록 설정 한 다음 각 구성원 계정으로 조직에 대한 변경 사항을 승인하도록 할 수 있습니다. (통합 결제 기능 만 지원하는 새로운 조직을 만드는 것을 계속 지원할 것입니다. 통합 결제 기능만 사용하려는 고객은 마스터 계정 관리자가 조직의 구성원 계정에 대한 고급 정책 제어를 시행하지 않고도 계속해서 그렇게 할 수 있습니다.)

먼저 AWS account는 AWS  자원을 가지고 있습니다. 이 중 Master 계정은 전체 조직의 관리 허브이며, 모든 AWS 계정에 대한 지불 계정이기도 합니다. 마스터 계정은 기존 계정을 가입하도록 초대 할 수 있으며 새 계정을 만들 수도 있습니다.

Member accounts는 조직의 비 마스터 계정입니다. Organizational Unit (OU) 은 AWS 계정 세트의 컨테이너입니다. OU는 최대 5 단계까지 계층 구조로 정렬 할 수 있습니다. OU 계층 구조의 최상위를 Administrative Root라고도 합니다. .

Service Control Policy (SCP)는 조직의 마스터 계정이 조직, 각 OU 또는 계정에 적용 할 수 있는 일련의 제어 방법입니다. OU에 적용되면, OU와 그 하위 계층의 다른 OU에 적용됩니다. 계정에 SCP를 적용하면, 해당 계정의 루트 사용자에게 부여 된 사용 권한을 지정합니다. 계정 내에서 IAM 사용자 및 역할을 평소와 같이 사용할 수 있습니다. 그러나, 사용자 또는 역할의 권한과 관계없이 SCP에 정의 된 것 이상으로 확장되지 않습니다. 이를 사용하여 계정 수준에서 AWS 서비스 및 API 기능에 대한 접근을 세부적으로 제어 할 수 있습니다.

Invitation은 AWS 계정에 가입을 요청하는 데 사용합니다. 15 일 이내에 수락해야 하며 이메일 주소 또는 계정 ID에 대해 연장할 수 있습니다. 최대 20 회의 초대장이 주어진 시간에 미해결 상태가 될 수 있습니다. 초대 기반 모델을 사용하면 마스터 계정에서 시작하여 기존 계정을 접을 수 있습니다. 초대장이 수락되면 계정이 조직에 가입하며 모든 적용 가능한 정책이 효력을 발생합니다. 계정이 조직에 가입하면 적절한 OU로 이동할 수 있습니다.

AWS Organizations 관리하는 AWS 계정간에 강력한 격리 경계를 만들려는 경우에 적합합니다. 그러나 AWS 리소스 (EC2 인스턴스, S3 버킷 등)는 특정 AWS 계정 내에 존재하며 한 계정에서 다른 계정으로 이동할 수 없습니다. VPC 피어링, AMI 공유, EBS 스냅샷 공유, RDS 스냅샷 공유, 멀티 계정 이메일 전송, IAM 역할 별 권한 배정, 멀티 계정 S3 버킷 접근, 멀티 계정 AWS 콘솔 접근 등 여러 가지 교차 계정 AWS 기능에 접근할 수 있습니다.

통합 결제와 마찬가지로 AWS Organizations은 EC2 및 RDS 예약 인스턴스를 사용할 때, 몇 가지 이점을 제공합니다. 과금 청구의 경우, 조직의 모든 계정은 하나의 계정 인 것처럼 취급되며 동일한 조직의 다른 계정으로 구입 한 RI의 시간당 비용 혜택을받을 수 있습니다 (이 혜택이 예상대로 적용될 수 있도록, 가용성 구역 및 RI의 기타 속성은 EC2 또는 RDS 인스턴스의 속성과 일치해야합니다.

Organization 만들기
처음 부터 직접 시작해 보겠습니다. AWS 관리 콘솔에서 신규 조직을 만들고  조직 단위를 만든 다음, 계정을 연결하거나 만듭니다. Create organization를 클릭하여 시작합니다.

그런 다음 ENABLE ALL FEATURES을 선택하고 Create organization를 클릭하십시오.

몇 초 내에 구성을 완료합니다.

Add account를 클릭 한 다음 Create account를 선택하여 새 계정을 만들 수 있습니다.

그런 다음 세부 정보를 제공합니다 (IAM 역할은 새 계정에서 생성되고 계정이 생성 된 후, 맞춤 사용자 정의를 통해 충분한 권한을 부여합니다).

Dev, Test 및 Prod 계정을 만든 후에 콘솔 모습은 다음과 같습니다.

이 시점에서 모든 계정이 계층 구조의 맨 위에 있습니다.

계층 구조를 추가하려면 Organize accounts을 클릭하고 Create organizational unit (OU)을 선택한 다음 이름을 입력하십시오.

두 번째 OU에 대해서도 동일한 작업을 수행합니다.

그런 다음 Prod 계정을 선택하고 Move accounts을 클릭 한 다음, 이동할 해당 조직(Operations OU)를 선택합니다.

다음으로 개발 및 테스트 계정을 개발 OU로 이동합니다.

현재 4개의 계정 (원래 만든 계정과 방금 만든 계정)과 2 개의 OU를 가지고 있습니다. 다음 단계는 Policies을 클릭하고 Create policy을 선택하여 하나 이상의 서비스 제어 정책을 작성하는 것입니다. Policy Generator를 사용하거나 기존 SCP를 복사 한 다음, 설정할 수 있습니다. Policy Generator를 사용하겠습니다. 내 정책에 이름을 지정하고 Allow으로 지정합니다.

그런 다음 Policy Generator를 사용하여 EC2 및 S3에 대한 전체 접근 권한과 Lambda 함수를 실행 (호출) 할 수 있는 정책을 구성합니다.

이 정책은 계정 내에서 허용되는 모든 행위를 정의합니다. 계정 내의 IAM 사용자가 이러한 작업을 사용하려면, 적절한 IAM 정책을 만들어 사용자 (모두 회원 계정 내)에 연결해야 합니다. Create policy을 클릭하면 정책을 만들 수 있습니다.

그런 다음 개발 및 테스트를 위한 두 번째 정책을 만듭니다. AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline에 접근 할 수 있습니다.

요약하면, AWS 계정을 OU에 넣고 이에 대한 정책을 만들었습다. 이제 정책 사용을 활성화하고 OU에 정책을 첨부해야합니다. 정책을 사용하려면 Organize accounts을 클릭하고 Home 을 선택합니다 (조직이 여러 개의 독립적인 계층 구조를 지원하도록 설계 되었기 때문에 루트를 의미하는 게 아닙니다). 그런 다음 최상위 OU의 확인란을 클릭합니다. 그런 다음 오른쪽에서 Details 섹션을 확장하고 Enable을 클릭합니다.

이제 이를 모두 통합해 보겠습니다! 최상위 OU를 클릭하여 계층 구조로 내린 다음 Operations OU의 확인란을 클릭합니다. 그런 다음 오른쪽의 Control Policies을 확장하고 Attach policy을 클릭하십시오.

그런 다음 OperationsPolicy를 찾아 첨부를 클릭합니다.

마지막으로 FullAWSAccess 정책을 제거합니다.

DevTestPolicy를 Development OU에 연결할 수도 있습니다.

위에서 설명한 모든 작업은 AWS Command Line Interface (CLI)에서 시작하거나  CreateOrganization, CreateAccount, CreateOrganizationalUnit, MoveAccount, CreatePolicy, AttachPolicy, and InviteAccountToOrganization과 같은 함수를 호출하여 시작할 수 있습니다. 실제 CLI를 보려면 Announcing AWS Organizations: Centrally Manage Multiple AWS Accounts를 살펴 보시기 바랍니다.

서비스 활용 시 모범 사례
AWS Organizations 서비스에 대한 몇 가지 모범 사례를 알려드립니다.

  • Master Account 리소스 사용 금지– 한 가지 예외를 제외하고는 마스터 AWS 리소스를 사용하지 않는 것이 좋습니다. 이를 통해 고품질 제어 결정을 보다 쉽게 ​​수행 할 수 있을 뿐만 아니라 AWS 청구서 항목을 더 쉽게 이해할 수 있습니다.
  • CloudTrail 활용 – 마스터 계정에서 (뛰어난 기능을 가진) AWS CloudTrail을 사용하여 회원 계정의 모든 AWS 사용 현황을 추적합니다.
  • 최소 권한 부여 – OU에 대한 정책을 설정할 때 최대한 적은 권한을 할당하십시오..
  • 조직 구성 단위 (OU) 활용 – 계정이 아닌 OU에 정책을 할당합니다. 이렇게 하면 조직 구조와 필요한 AWS 접근 수준 간의 매핑을 잘 유지할 수 있습니다.
  • 테스트 필수 – 규모를 확대하기 전에 단일 계정에서 새 정책과 수정 된 정책을 테스트합니다
  • 자동화 – API와 AWS AWS CloudFormation 템플릿을 사용하여 새로 생성 된 모든 계정이 원하는 대로 구성합니다. 템플릿은 IAM 사용자, 역할 및 정책을 만들 수 있습니다. 또한 로깅을 설정하고 VPC를 만들고 구성 할 수 있습니다.

자세한 정보
아래는 WS Organizations 서비스를 시작하는 데 도움이 되는 정보 모음입니다.

정식 출시
AWS Organizations은 현재 중국 (베이징) 및 AWS GovCloud (US) (미국)를 제외한 모든 AWS 리전에서 무료로 사용할 수 있습니다. (서비스 엔드포인트인 미국 동부 (버지니아 북부) 및 SCP는 모든 관련 리전에 적용됩니다). 모든 AWS 계정은 동일한 회사의 계정이어야 하며, 동일한 조직에서 AWS와 AISPL (인도 AWS 서비스 계정의 리셀러 역할을 하는 현지 법인)을 혼합 할 수 없습니다.

앞으로 Organizations 서비스에 대한 많은 서비스 계획을 가지고 있으며, 현재 다중 지불 지원 추가, 예약 인스턴스 할인 할당, 다중 계층 구조 및 기타 제어 정책 추가를 고려 중입니다. 항상 여버룬의 의견과 제안은 환영합니다.

Jeff;

이 글은 AWS Organizations – Policy-Based Management for Multiple AWS Accounts의 한국어 번역입니다.

AWS Directory Service (Microsoft AD) 서울 리전 출시!

오늘 부터 AWS Directory Service for Microsoft Active Directory 기능을 서울 리전에서 사용 가능합니다.

AWS Directory Service, 즉 AWS Microsoft AD를 사용하여, 디렉터리 작업이 필요한 서비스와 AWS 자원으로부터 AWS 클라우드에서 관리형 Active Directory를 활용할 수 있습니다. Microsoft AD 서비스는 실제 Microsoft Active Directory상에 구축되어 있으며 기존 Active Directory 데이터를 클라우드와 동기화하거나 클라우드로 복제할 필요가 없습니다.

aws-directory-service-microsoft-ad-seoul

또한, 표준 Active Directory 관리 도구를 사용하여 Group Policy, 트러스트, SSO 등 Active Directory의 기본 기능을 활용할 수 있습니다. Microsoft AD의 경우 Amazon EC2SQL Server용 Amazon RDS 인스턴스를 도메인에 손쉽게 활용하고, Active Directory 사용자 및 그룹으로 Amazon WorkSpaces와 같은 AWS 엔터프라이즈 IT 애플리케이션을 사용할 수 있습니다.

  • Microsoft Active Directory 관리형 서비스: AWS Microsoft AD는 AWS 관리형 인프라에서 실행되는 실제 Microsoft Active Directory입니다. AWS Microsoft AD를 사용하면 Active Directory Administrative Center 및 Active Directory Users and Computers와 같이 이미 알고 있는 도구를 통해 Microsoft AD의 사용자와 디바이스를 관리할 수 있습니다.
  • 신뢰성 지원: Active Directory 트러스트 관계를 사용하여 AWS Microsoft AD와 기존 Active Directory를 손쉽게 통합할 수 있습니다. 트러스트를 사용하면 Microsoft AD를 리소스 도메인으로 구성하고 어떤 Active Directory 사용자가 기존 Active Directory에서 AWS 리소스에 액세스할 수 있는지 제어할 수 있습니다.
  • 그룹 기반 정책: AWS Microsoft AD가 실제 Microsoft Active Directory에서 실행되므로 Active Directory 기본 Group Policy objects(GPOs)를 사용하여 사용자와 디바이스를 관리할 수 있습니다. Group Policy Management Console(GPMC)과 같은 기존 도구로 GPOs를 생성할 수 있습니다.
  • SSO(Single Sign-On) 지원: AWS Microsoft AD는 Active Directory와 마찬가지로 Kerberos 기반 인증을 사용하여 SSO를 제공합니다. AWS 리소스를 Microsoft AD와 통합함으로써 사용자는 단일 자격 증명 세트로 SSO를 통해 AWS 애플리케이션과 리소스에 로그인할 수 있습니다.
  • 원활한 도메인 조인: AWS Microsoft AD를 사용하면 Windows Server용 기존 및 신규 Amazon EC2 인스턴스에 원활한 도메인 조인 기능을 사용할 수 있습니다. Windows Server용 신규 EC2 인스턴스의 경우 시작할 때 AWS Management Console을 사용하여 조인할 도메인을 선택할 수 있습니다. Windows Server용 기존 EC2 인스턴스의 경우 EC2Config 서비스를 통해 원활한 도메인 조인 기능을 사용할 수 있습니다.
  • 단일 디렉터리 제공: AWS Microsoft AD에서는 클라우드 워크로드별로 별도의 디렉터리를 사용하지 않고 클라우드 리소스를 위한 단일 디렉터리를 사용할 수 있습니다. 단일 디렉터리를 사용함으로써 여러 Active Directory, Lightweight Directory Access Protocol(LDAP) 및 사용자 정의 디렉터리 전체에서 데이터와 정책을 동기화하는 오버헤드를 관리할 필요가 없습니다.
  • AWS 관리 콘솔에 대한 연동 접근: AWS Microsoft AD를 사용하면 사용자와 그룹에 AWS Management Console에 대한 연동 접근을 손쉽게 제공할 수 있습니다. 연동을 사용하면 개별 사용자 암호를 없애고 Active Directory의 단일 자격 증명을 기반으로 액세스를 관리할 수 있으므로 AWS 환경의 보안을 강화하는 데 도움이 됩니다.
  • 고가용성(HA) 및 일일 스냅샷: 디렉터리는 미션 크리티컬 인프라이므로 AWS Microsoft AD는 여러 가용 영역에 걸쳐 HA로 배포됩니다. 또한, 변경 사항을 롤백해야 하는 경우 Microsoft AD는 기본적으로 일일 자동 스냅샷을 제공합니다.
  • AWS 완전 관리 서비스: AWS Microsoft AD는 AWS 관리형 인프라에서 실행되며 장애가 발생한 도메인 컨트롤러를 자동으로 탐지하여 교체하는 모니터링이 제공됩니다. 또한, 데이터 복제와 일일 자동 스냅샷도 구성됩니다. 소프트웨어를 설치할 필요가 없으며 AWS에서 모든 패치와 소프트웨어 업데이트를 처리합니다.

정식 출시 및 가격
본 서비스는 오늘 부터 서울 리전에 사용 가능하며, 한 달(750시간) 동안 무료로 사용 가능합니다. 그 이후에는 시간당 $0.418 (서울 리전 기준)으로 더 자세한 것은 AWS Directory Service 요금표를 참고하세요.

AWS코리아 마케팅팀;

Amazon Cloud Directory – 클라우드 기반 신규 디렉토리 관리 서비스 출시

AWS 고객은 일반적으로 디렉터리 (Active Directory, Lightweight Directory Service 또는 LDAP 기반)를 사용하여 계층적인 데이터를 관리하고 있습니다. 예를 들어, 장치 레지스트리, 교육 과정 카탈로그, 네트워크 구성 및 사용자 디렉터리는 종종 같은 개체 사이에 계층 구조로 표시됩니다. 사용자 디렉토리는 실제 위치 (국가, 주, 도시, 건물, 층 및 사무실)를 기반으로 하는 하나의 계층 구조, 프로젝트 및 빌링 코드를 기반으로 두 번째 계층 및 관리 체인을 기반으로 하는 세 번째 계층을 가질 수 있습니다. 그러나, 기존 디렉토리 기술은 단일 디렉토리에서 다중 관계 사용을 지원하지 않습니다. 필요한 경우 추가 디렉토리를 만들고 유지해야 합니다.

디렉토리 서비스 확장성 또한 중요한 문제입니다. 계층 구조의 기본 조작시 지정된 오브젝트 상위 또는 하위 오브젝트를 찾게 됩니다. 계층 구조를 사용하여 더 크고 중첩된 정보 모음을 나타낼 수 있으므로, 이러한 작업은 얼마나 많은 개체가 있는지 또는 얼마나 많이 중첩되어 있는 지에 관계없이 최대한 효율적이어야 합니다. 기존 디렉토리는 확장하기가 어려울 수 있으며, 여러 계층을 나타내기 위해 두 개 이상의 디렉토리를 사용하는 경우에 더 관리가 힘들어 지게 됩니다.

Amazon Cloud Directory 서비스 소개
오늘 Amazon Cloud Directory를 시작합니다. 이 서비스는 위에 설명한 대로, 고객들이 손쉽게 대용량 계층적 데이터를 저장 및 관리하기 위한 목적으로 만들어졌습니다. Cloud Directory는 수백만 개의 개체를 비용 효율적으로 확장 할 수 있는 기능을 갖추고 있으며,  대부분 클라우드 및 모바일 응용 프로그램에 매우 적합합니다.

AWS Cloud Directory는 이미 Amazon CognitoAWS Organizations를 비롯한 다른 AWS 서비스에서 사용하고 있던 빌딩 블록입니다. AWS에서도 매우 중요한 역할을 하고 있기 때문에 확장성, 고가용성 및 보안을 염두에 두고 설계되었습니다. (항상 데이터는 전송되는 동안 암호화됩니다).

Amazon Cloud Directory는 완전 관리형 서비스입니다. 즉, 소프트웨어 설치 또는 패치, 서버 관리, 스토리지 확장 또는 인프라 스트럭처 확장에 대한 관리 부담이 전혀 없습니다. 간단하게 스키마를 정의하고 디렉토리를 만든 다음 Cloud Directory API를 호출하여 디렉토리를 만들 수 있습니다. 본 API는 효율적인 배치 기반 읽기 및 쓰기 기능을 통해 빠른 속도와 확장성을 제공하도록 설계하였습니다.

대개 디렉토리는  사용하는 기간이 길고, 중단할 때까지 확장성 및 사용 사례 등이 다양하게 결합되면서 문제가 많이 발생합니다. 특히, 정적 스키마에서는 확장성 및 새로운 기능 추가 시 발생하는 변경 사항을 적용할 수 있는 유연성이 부족합니다. 이러한 과제를 해결하고, 디렉토리의 향후 기능성을 보장하기 위해 클라우드 디렉토리는 명시적으로 변화의 여지가 있는 모델로 구축합니다. 새 패싯(Facets)을 추가하여 기존 스키마(Scheme)를 확장하면 됩니다. 기존 응용 프로그램이 예상대로 계속 작동 할 수 있도록 기존 데이터를 손상시키지 않는 안전한 작업  방식입니다. 스키마와 패싯을 결합하면 동일한 디렉토리에서 여러 계층 구조를 나타낼 수 있습니다. 예를 들어, 첫 번째 계층 구조는 조직도를 만들 수 있습니다. 나중에 각각 회사 직원의 추가 속성 (전화 번호 또는 소셜 네트워크 주소)을 추적하기 위해 추가 패싯을 추가 할 수 있습니다. 그런 다음 국가, 주, 건물, 층, 사무실 및 직원과 같은 데이터 내에서 지리적으로 계층화 된 계층 구조를 만들 수 있습니다.

앞서 언급했듯이  이미 AWS의 많은 서비스가 Amazon Cloud Directory를 사용합니다. Cognito User Pools은 Cloud Directory를 사용하여 사용자 가입, 로그인 및 다중 요소 인증을 지원하는 응용 프로그램 별 사용자 디렉토리를 제공합니다. Cognito 사용자 풀을 사용하면 수억 명의 사용자를 지원할 수 있도록 완벽하게 관리되는 서비스로 모바일 앱 및 웹 앱에 등록 및 로그인 기능을 쉽고 안전하게 추가 할 수 있습니다. 마찬가지로 AWS Organizations은 Cloud Directory를 사용하여 관련 AWS 계정 그룹을 만들 수 있도록 지원하며, 다양한 정책을 시행하기 위해 여러 계층을 효과적으로 활용합니다.

먼저 Amazon Cloud Directory의 주요 개념을 간단히 살펴 보겠습니다.

  • Directories: 디렉토리의 이름을 지정 한 후, 하나 이상의 스키마를 만듭니다. 디렉토리는 객체, 객체, 스키마 및 정책 간의 관계를 저장합니다.
  • Facets: 필수 및 허용 가능한 특성을 정의하여 데이터를 모델링합니다. 각 패싯은 속성 이름에 대해 독립적인 범위를 제공합니다. 이를 통해 디렉토리를 공유하는 여러 응용 프로그램이 충돌 위험 없이 주어진 스키마를 안전하고 독립적으로 확장 할 수 있습니다.
  • Schemas: 하나 이상의 패싯을 참조하여 디렉토리에 저장된 데이터의 “모양(shape)”을 정의합니다. 각 디렉토리에는 하나 이상의 스키마가 있을 수 있습니다. 스키마는 3 단계 중 하나 (개발, 출시 또는 적용) 중 하나로 존재합니다. 개발(Development) 스키마는 수정할 수 있습니다. 이미 출시(Publish)된 스키마는 변경할 수 없습니다. Amazon Cloud Directory에는 사람, 조직을 위한 이미 정의 된 스키마 모음이 포함되어 있습니다.
  • Attributes: 실제 저장된 데이터입니다. 각 속성 이름을 지정하고 입력합니다. 데이터 유형에는 부울(Boolean), 이진 (Blob), 날짜/시간, 숫자 및 문자열이 포함됩니다. 각 속성은 필수 또는 선택 사항에 따라 변경 불가능하거나 편집 할 수 있습니다. 속성의 정의는 속성이 저장되거나 업데이트되기 전에 속성의 길이 및 내용을 검증하는 데 사용되는 규칙을 지정할 수 있습니다. 이진 및 문자열 객체는 최소 및 최대 길이에 대해 길이를 확인할 수 있습니다. 규칙은 문자열이 목록에서 선택한 값을 가져야 하거나 숫자가 주어진 범위 내에 있어야 함을 나타낼 수 있습니다.
  • Objects: 디렉토리에 저장되고 속성을 가지며 스키마에 의해 정의됩니다. 각 개체는 스키마에 지정된 대로 여러 자식 및 여러 부모를 가질 수 있습니다. 다중 상위 기능을 사용하여 단일 디렉토리 (여러 개의 트리 포리스트라고도 함) 내에 여러 개의 독립적 인 계층 구조를 만들 수 있습니다.
  • Policies: 계층 구조의 모든 수준에서 지정할 수 있으며 자식 개체에 상속됩니다. 클라우드 디렉토리는 정책에 어떤 의미도 해석하거나 할당하지 않으므로 애플리케이션에 그대로 남겨 둡니다. 정책을 사용하여 접근 권한, 사용자 권한, 장치 특성 등을 지정하고 제어 할 수 있습니다.

디렉토리 만들어 보기
이제 직접 디렉토리를 만들어 봅시다! 우선 AWS Directory Service Console을 열고, Create Directory 버튼을 클릭합니다.

내 디렉토리 (users)의 이름을 입력하고, person 스키마 (두 개의 패싯에 뒤에 자세히 설명합니다)를 선택하고 Next을 선택하세요.

미리 정의 된 (AWS) 스키마가 내 디렉토리에 복사됩니다. 이름 및 버전 정보를 주고 Publish를 선택합니다.

그런 다음 구성을 검토하고 Launch을 선택하십시오.

디렉토리가 생성되고 나면, 객체를 추가하는 코드를 작성할 수 있습니다.

정식 출시 – 가격 및 가용성

Cloud Directory is available now in the US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (Ireland), Asia Pacific (Sydney), and Asia Pacific (Singapore) Regions and you can start using it today.

Pricing is based on three factors: the amount of data that you store, the number of reads, and the number of writes (these prices are for US East (Northern Virginia)):

Cloud Directory는 현재 미국 동부 (버지니아 북부), 미국 동부 (오하이오), 미국 서부 (오레곤), EU (아일랜드), 아시아 태평양 (시드니) 및 아시아 태평양 지역 (싱가포르)에서 오늘 부터 사용 가능합니다.

서비스 가격은 저장하는 데이터의 양, 읽기 및 쓰기 수 의 세 가지 요소를 기반으로 합니다. (아래는 버지니아 리전 기준)

  • 저장 용량 – GB / GB 당 0.25 달러
  • 읽기 – 1 만 건마다 $ 0.0040
  • 쓰기 – 1,000 회 쓰기 당 0.0043 달러

향후 기능
Cloud Directory에 대한 다양한 추가 기능을 계획 중입니다. 우선 순위는 고객 피드백으로 인해 바뀔 수 있지만, 리전 간 복제, AWS Lambda 통합 및 AWS CloudFormation을 통해 새 디렉토리를 생성하는 기능 추가 작업을 진행 중입니다.

Jeff;

이 글은 Amazon Cloud Directory – A Cloud-Native Directory for Hierarchical Data의 한국어 번역입니다.

Amazon Route 53와 AWS Shield를 통한 DDoS 공격 위험 줄이기

지난 2016 년 10월말에 주요 DNS 공급자가 서비스 거부 공격(DDoS)으로 인한 대규모 사이버 공격 표적이되었습니다. 수천 만개의 IP 주소에서 대량 DNS 조회를 일으켜 공격함으로서 많은 인터넷 사이트 및 서비스에 대해 북미 및 유럽 사용자 접속이 불가능했습니다. 프린터, 카메라, 홈 네트워크 게이트웨이, 모니터 등 다양한 사물 인터넷(IoT) 장치로 구성된 봇넷을 사용하여 이러한 분산 서비스 거부 공격이 실행된 것으로 알려져 있습니다. 이러한 기기는 Mirai 악성 코드에 감염되어, 초당 수백 기가 바이트의 트래픽을 생성했습니다. 많은 기업 네트워크 등은 이러한 규모의 공격을 흡수 할만한 용량을 가지고 있지 않습니다.

이러한 다양한 공격 유형 DDoS 시도에 대해 보다 탄력 있고 빠른 복원력을 가진 시스템을 구축 할 수 있도록 하기 위한 권장 사항 및 모범 사례에 대한 고객의 요구가 많았습니다. 이를 위한 자료로는 “DDoS 복원력을 위한 AWS 모범 사례” 백서, Amazon Route 53AWS Shield 를 활용하는 것입니다 (자세한 내용은  AWS Shield – DDoS 공격 대비 애플리케이션 보안 서비스 참조)

  • 확장성 – Route 53는 다수 AWS 엣지 로케이션에서 호스팅하는 대량 DNS 트래픽을 흡수 할 수 있는 글로벌 서비스입니다. Amazon CloudFrontAWS WAF등 다른 엣지 기반 서비스에도 대량 트래픽을 처리 할 수 있습니다.
  • 복원력각 에지 로케이션은 수 많은 인터넷 연결이 진행됩니다. 이를 통해 다양한 경로에 대해 장애 분리가 가능합니다. 또한, Route 53는 셔플 샤드(shuffle sharding)와 애니 캐스트 스트라이핑(anycast striping )을 사용하여 가용성을 향상합니다. 셔플 샤드에서는 위탁 집합(delegation set)의 각 네임 서버가 에지 로케이션의 고유 집합에 해당합니다. 이렇게 배치하면 내결함성이 향상되고 AWS 고객 간의 중복을 최소화합니다. 위탁 세트 중 하나의 네임 서버를 사용할 수 없는 경우, 클라이언트 시스템 또는 응용 프로그램은 다른 에지 로케이션의 네임 서버에 다시 요청을 시도하고 응답을 받습니다. 애니 캐스트 스트라이핑은 최적의 장소에 DNS 요청을 하는데 사용됩니다. 부하를 분산하여 DNS 지연 시간을 줄이는 효과가 있습니다.
  • 완화력AWS Shield Standard는 가장 일반적인 공격의 96 %로 부터 고객을 보호합니다. 여기에는 SYN/ ACK 플로드 반사 공격 및 HTTP 천천히 읽기 공격 등이 포함되어 있습니다. 이전 블로그 글에서도 언급했듯이 자동으로 Elastic Load Balancing, CloudFront 배포 지점 및 Route 53 자원에 무료로 적용됩니다. (결정적 패킷 필터링과 우선 순위를 기반으로 한 트래픽 형성을 포함한) 보호 기능은 모든 AWS 에지 로케이션에 배치 된 후, 수 마이크로 초 단위로 투명하게 모든 트래픽을 검사합니다.  AWS Shield Advanced에는 추가적인 DDoS 세부 공격 차단, 24×7 대응팀 연락, 실시간 통계 리포트 및 공격에 따른 비용 차단 등의 기능이 포함되어 있습니다.

더 자세한 것은 DDoS 복원력을 위한 AWS 모범 사례Amazon Route 53 anycast를 참고하시기 바랍니다.

Jeff;

이 글은 Reduce DDoS Risks Using Amazon Route 53 and AWS Shield의 한국어 번역입니다.

AWS Shield – DDoS 공격 대비 애플리케이션 보안 서비스

온라인 세계는 우호적인 장소는 아닐 수 있습니다. 웹 사이트를 온라인으로 올리자마자 다운되거나 침입 당할 수 있는 여러 가지 유형의 공격 대상이 될 수 있습니다. DDoS (Distributed Denial of Service) 공격은 흔히 발생하는 문제 중 하나입니다. 인터넷 전체에서 취약한 자원을 모아서 특정 대상을 공격할 수 있게 됩니다.

아래에 세 가지 일반적인 유형의 DDoS 공격 타입이 있습니다.

응용 프로그램 계층 공격: 응용 프로그램 리소스를 사용하도록 설계되어 있지만, 실제로는 악의적인 요청 (HTTP GET 및 DNS 쿼리가 많이 사용됨)으로 구성됩니다. 예를 들어, 여러 개의 HTTP 연결을 열어 몇 초 또는 몇 분 동안 요청을 해서 과도한 메모리가 소모되도록 합니다.

고갈 상태 공격: 상태 별 프로토콜을 어뷰징하고, 각 통신 연결 당 많은 리소스를 소비함으로써 방화벽 및 로드 밸런서에 강한 스트레스를 유발합니다.

볼륨 공격: 실제 처리 할 수 있는 것보다 많은 트래픽을 네트워크에 보내거나, 가짜 쿼리를 발행하여 네트워크를 혼란시킵니다.

AWS Shield 신규 서비스
AWS Shield는 DDoS (Distributed Denial of Service) 공격으로부터 웹 애플리케이션을 보호하는 새로운 관리 서비스입니다. Elastic Load Balancing, Amazon CloudFront, Amazon Route 53와 함께 작동하며 다양한 유형, 모양 및 크기의 DDoS 공격으로부터 사용자를 보호합니다. 두 가지 계층의 서비스가 있습니다. 여기에 두 가지 계층의 서비스가 있습니다.

AWS Shield Standard: 비용 없이 모든 AWS 고객이 사용할 수 있습니다. SYN/ACK Floods, 반사 공격 및 HTTP 저속 읽기와 같은 가장 일반적인 공격의 96 %를 방지합니다. 이 보호 방식은 Elastic Load Balancer, CloudFront 배포 및 Route 53 리소스에 자동으로 적용됩니다.

AWS Shield Advanced: 볼륨 공격, 지능형 공격 탐지 및 애플리케이션 및 네트워크 계층에서의 공격 완화를 위한 DDoS 완화 기능을 제공합니다. DDoS 공격의 여파로 인한 비용 청가 증가를 방지하기 위해 고급 실시간 통계  보고서 및 DDoS 비용 보호와 사용자 지정 완화를 위해 DDoS 대응 팀 (DRT)에 24 시간 연중 항상 지원 받을 수 있습니다.

더 자세한 사항은 AWS ShieldGet Started with AWS Shield Advanced를 참고하시기 바랍니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Shield – Protect your Applications from DDoS Attacks의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS 9월 온라인 세미나 – 클라우드 보안 특집

AWS 한국팀에서도 AWS 클라우드를 아껴주시는 한국 고객 분들을 위해 지속적으로 “AWS 월간 웨비나 시리즈”를 진행하고 있습니다.

aws-security-webinar-2016-09

이번 9월 웨비나에서는 AWS의 보안 전문 파트너사들과 함께 클라우드 도입과 활용 과정에서 고려해야 할 다양한 보안 관련 요소들을 소개해 드리고자 합니다.

기존 온프레미스 환경에서의 보안 절차를 클라우드에서 구현하는 방법, AWS의 다양한 보안 관련 기능 및 서비스를 활용해 보안을 강화할 수 있는 모범사례, AWS 클라우드 기반의 아키텍처 보안을 더 강화하기 위한 파트너사 솔루션의 소개 등 다양한 내용으로 준비되어 있습니다.

기초 | AWS와 함께하는 클라우드 컴퓨팅
연사: 박은애 어카운트 매니저
일시: 2016년 9월 27일 (화) 오전 10:00 – 오전 11:30

강연 요약: AWS 클라우드는 IT의 새로운 기준을 정립하며 클라우드 컴퓨팅 산업을 혁신하고 있습니다. 이 세미나에서는 클라우드 컴퓨팅의 개념과 AWS가 제공하는 서비스 및 솔루션의 특장점, 주요 사용사례에 대해 말씀드리고 질답 시간을 가질 예정입니다. 부디 참석하셔서 귀사의 사업과 서비스에 적용할 수 있는 정보를 얻어가시기 바랍니다.

기초 | AWS 클라우드 보안의 이해
연사: 양승도 솔루션즈 아키텍트
일시: 2016년 9월 27일 (화) 오후 02:00 – 오후 03:30

강연 요약: AWS 클라우드를 사용하는 고객들의 데이터와 애플리케이션을 보호하기 위해 다양한 종류의 기능과 서비스를 제공하고 있으며, 강력한 보안 체계를 구축할 수 있도록 이런 기능과 서비스들을 도입하고 고객의 상황에 맞는 모범사례에 따라 인프라를 구축할 것을 권하고 있습니다. 이 강연에서는 AWS가 제시하는 보안 모델의 기초적 개념을 소개하고 다양한 보안 관련 기능 및 서비스의 활용법을 안내해 클라우드 위에서 확장성과 안전성을 두루 갖춘 아키텍처를 구축할 수 있는 방법을 알려 드리도록 하겠습니다.

기초 | AWS에서의 네트워크 보안(DDoS, UTM 및 WAF)
연사: 이경수 솔루션즈 아키텍트
일시: 2016년 9월 28일(수) 오전 10:00 – 오전 11:30

강연 요약: AWS 클라우드가 제공하는 보안 관련 서비스는 애플리케이션 레벨, 네트워크 레벨 등 다양한 레이어와 범위에 걸쳐 있습니다. 이 강연에서는 네트워크 레벨에서 허가되지 않은 접근과 DDoS 등 보안상의 위협을 막기 위해 취해야 할 모범사례들에 대해 소개하고 이를 구현하기 위해 네트워크 보안 구성 요소인 UTM과 WAF를 구성하는 방법에 대해 알아보도록 하겠습니다.

중급 | Deep Security를 통한 AWS에서의 보안 적용
연사: 양희선 차장, 트렌드마이크로
일시: 2016년 9월 28일(수) 오후 02:00 – 오후 03:30

강연 요약: 기업이 클라우드를 본격적으로 활용하기 위해 필요한 요소 중 하나는 기존 온프레미스 환경의 보안 체계를 클라우드에서도 활용할 수 있도록 설정하는 것입니다. 이 강연에서는 트렌드마이크로 Deep Security를 통해 기존의 물리적 환경에 구현되어 있던 보안 체계를 AWS 클라우드 상에 동일하게 구현하는 방법에 대해 말씀드리도록 하겠습니다.

중급 | AWS에서의 웹방화벽(WAPPLES)과 암호플랫폼(D’Amo) 적용
연사: 남경문 부장, 펜타시큐리티
일시: 2016년 9월 29일 (목) 오전 10:00 – 오전 11:30

강연 요약: 펜타시큐리티에서는 클라우드를 사용하는 기업들이 웹 어플리케이션과 최종 사용자들의 개인정보를 보호할 수 있도록 위하여 웹방화벽(WAPPLES)과 암호플랫폼(D’Amo)을 클라우드 환경에 맞추어 제공하고 있습니다. 이 강연에서는 클라우드 환경에서 왜 웹방화벽과 암호플랫폼을 사용해야 하는지 말씀드리고 AWS 클라우드에서 활용할 수 있는 펜타시큐리티의 보안 아키텍쳐와 이를 구현하는 방법에 대해서 소개하겠습니다.

중급 | AWS 클라우드 환경에서의 사전 방어(Prevention)
연사: 김민석 수석부장, 팔로알토 네트웍스
일시: 2016년 9월 29일 (목) 오후 02:00 – 오후 03:30

강연 요약: 팔로알토 네트웍스는 클라우드 환경을 위한 East West 트래픽 보안 통제 시스템을 통해 애플케이션에 대한 철저한 검증 및 클라우드 사용 권한 설정을 보안 관점에 촛점을 맞춰 원치 않은 이용자들의 접근을 제한해 드립니다. 이 강연에서는 클라우드 IT 환경에서의 다양한 보안 이슈 분석을 통해 위협에 사전 방어(Prevention)할 수 있는 구체적이면서도 효율적인 방안을 제시하고자 합니다.

클라우드 보안 특집 웨비나를 통해 클라우드 도입에 대한 다양한 정보를 얻으시길 바라며, 본 온라인 세미나에 대한 자세한 발표 내용 및 연사 소개는 월간 웨비나 홈페이지를 참고하시기 바랍니다.

– AWS 코리아 마케팅팀;