Category: Security, Identity, & Compliance*


ランサムウェア「WannaCry」に関するAWSへの影響について

 

2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。

このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。

 

WannaCryによるAWSサービスへの影響

 

EC2 Windows

 

Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。

AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。

AWSのWindows AMIのリリースノートはこちらです。

 

WorkSpaces

 

Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。

 

Directory Service

 

AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。

 

Elastic Beanstalk

 

AWS Elastic Beanstalkに関しては、2017 年5月4日以降のWindowsサーバーで構築された環境は、本問題の影響を受けません。ただし、既存のElastic Beanstalk Windows環境のアップデートは常に推奨しています。AWS管理コンソールから、もしくは、環境を再構築することでアップデート可能です。Elastic Beanstalkの現時点での最新のリリースノートはこちらです。

 

AWSによるセキュリティ速報(原文)は、こちらをご覧ください。

 

AWSサービスの効果的な使い方

 

Amazon Inspectorは、Amazon EC2インスタンスに対してエージェントを導入し、セキュリティ診断を行うサービスです。CVE(共通脆弱性識別子)のルールパッケージに基づいた診断も可能で、WannaCryに関連するCVE-2017-0143からCVE-2017-0148の脆弱性の検証ができます。AWS管理コンソール、CLI、APIから診断を実行できます。診断結果は、AWS管理コンソールで表示したり、エグゼクティブサマリー含むPDF形式のレポートとしても取得できます。

AWSコンソール上でのAmazon Inspector 結果一覧画面例

 

AWSコンソール上でのAmazon Inspector 結果詳細画面例

 

詳しくは、Amazon Inspector ユーザーガイドをご覧ください。

 

Amazon EC2 Systems Managerは、Amazon EC2インスタンスおよびオンプレミスサーバーに対してエージェントを導入し、ソフトウェアインベントリ収集やOSパッチ適用、OS構成変更などを一元的に管理できるサービスです。インスタンスに対して、シェルスクリプトやPowerShellコマンドの実行、パッチ適用の時間指定や定期実行などの管理タスクを簡単に自動化できます。今回のような、Windowsのセキュリティ更新プログラム適用にもご利用いただけます。詳しくは、Amazon EC2 Systems Manager ユーザーガイドをご覧ください。

 

推奨するAWSソリューション

 

今回のようなランサムウェアに対する最も有効な対策は、常日頃からバックアップを取得・管理し、セキュリティ推奨構成を保っておくことです。AWSではバックアップ&復旧に関する各種ソリューションの情報が提供されています。

上記の情報も参考に、これからも安心・安全なAWSライフをご満喫ください。

桐山 隼人, セキュリティソリューションアーキテクト
坪 和樹, クラウドサポートエンジニア
長谷川 淳, クラウドサポートエンジニア

Amazon Inspector の更新 – 評価レポート、プロキシサポートなど

Amazon Inspector は当社の自動セキュリティ評価サービスです。このサービスは AWS で実行するアプリケーションの動作を分析し、セキュリティ問題を識別する上で役立ちます。Inspector については 2015 年の後半にこのブログで紹介し、その使い方についてご説明したことがあります (「Amazon Inspector – 自動セキュリティ評価サービス (Amazon Inspector – Automated Security Assessment Service)」)。同サービスを使うには、まずタグを使用してアプリケーションを生成する AWS リソースのコレクションを定義します。次に、セキュリティ評価テンプレートを作成し評価の一部として実行したい一連のルールを特定します。

評価ターゲットとセキュリティ評価テンプレートを作成したら、クリック 1 つでターゲットリソースに対して実行することができます。この評価は Linux と Windows ベースの EC2 インスタンスで実行するエージェントを活用します (詳細については「AWS エージェント (AWS Agents)」をご覧ください)。評価は手動で実行したり、AWS Lambda を使用して既存の発券システムに結果を転送することができます (手順については「Amazon Inspector でセキュリティ脆弱性テストをスケールする (Scale Your Security Vulnerability Testing with Amazon Inspector)」をご覧ください)。実行するインスタンスが 1 件または何千件とある場合でも、定期的かつ頻繁に評価を行うことをおすすめします。デプロイや統合インスタンスといった DevOps パイプラインの一部として実行できます。そうすることで、セキュリティ評価テンプレートの作成時に選択したルールパッケージによる条件に見合った本稼働環境で、コードやシステムを安心してデプロイすることが可能になります。また、設定ドリフトを回避するため、本稼働システムに対しても頻繁に評価を実行することをおすすめします。Amazon Inspector には、次の強力な新機能を追加したばかりです。

  • 評価レポート – 新しい評価レポートはエグゼクティブサマリーから始まり、評価の総合的な概要を提供します。このレポートはチームやリーダーシップとの共有そしてコンプライアンス監査のドキュメントとしても使用できるように作成されています。
  • プロキシのサポート – プロキシ環境内で実行するようにエージェントを設定できるようになりました (これについては多くのお客様からリクエストいただきました)。
  • CloudWatch メトリクス – 長期に渡り変更をトラックして確認できるように、Inspector が Amazon CloudWatch にメトリクスを発行するようになりました。
  • Amazon Linux 2017.03 のサポートAmazon Linux AMI の新しいバージョンを本日リリースしました。Inspector もこれに対応しています。

評価レポート
評価の実行が完了したら、HTML 形式または PDF 形式で評価レポートの詳細をダウンロードすることができます。

レポートはカバーページとエグゼクティブサマリーで始まります。

評価ルールとテストしたターゲットを要約します。

各ルールパッケージの結果を要約します。

このレポートはコンプライアンス監査のドキュメントであるため、各結果と解決方法のヒントなど詳細情報を含んでいます。

レポートの全文は、すべてのターゲットインスタンスでどのルールがチェックされパスしたかを示します。

Proxy のサポート
Inspector エージェントが HTTP プロキシを介して Inspector と通信できるようになりました。Linux インスタンスでは HTTPS プロキシを、Windows インスタンスでは WinHTTP プロキシをサポートしています。AWS エージェントのプロキシサポート設定に関する手順については「Amazon Inspector ユーザーガイド (Amazon Inspector User Guide)」をご覧ください。

CloudWatch メトリクス
Amazon Inspector が各実行の後において Amazon CloudWatch にメトリクスを発行するようになりました。メトリクスはターゲットとテンプレート別に分類されています。AWS アカウントで実行されてきた評価の実行数を表示する集計メトリクスもご利用いただけるようになりました。これまでのように CloudWatch コンソールでメトリクスを確認できます。

ターゲットごとに発行したメトリクスの例は次をご覧ください。

テンプレートごとのメトリクスの例は次をご覧ください。

Amazon Linux 2017.03 のサポート
AWS の多くのお客様が Amazon Linux AMI をご利用されており、新しいバージョンが利用可能になり次第、自動アップグレードをされています。こうしたお客様に引き続き Amazon Inspector をご利用いただくため、AMI の現状バージョンだけでなく今後のバージョンでも、リリース当日に Amazon Inspector で必ずサポートされるようにしました。

今すぐ利用可能
これらのすべての機能は今すぐご利用いただけます。

料金はエージェント、評価ベースごとに定められます。毎月 45,000 以上の評価を実行する場合は、各評価 0.30 USD からスタートします。(詳しくは「Amazon Inspector の料金表 (Amazon Inspector Pricing)」をご覧ください)。

Jeff;

発表: Amazon Athena が暗号化されたデータのクエリのサポートを追加

昨年 11 月に、当社は毎日膨大な量のデータに安全にアクセスして調べる必要があるお客様を支援するための重要なステップとなることを期待して、サービスをマーケットに投入しました。このサービスは Amazon Athena にほかなりません。私はこれを、オブジェクトストレージのクエリにより「1 回のジャンプで背の高いクエリを飛び越える」ことを試みるマネージド型サービスであると考えています。AWS のお客様が、Amazon S3 に保存された大量のデータを簡単に分析してクエリを実行できるようにするサービスです。

Amazon Athena は、ユーザーが標準 SQL を使用して Amazon S3 のデータを簡単に分析できるようにする、サーバーレスでインタラクティブなクエリサービスです。Athena の中核となるのは、ANSI SQL のサポートによりクエリを実行する分散 SQL エンジンの Presto と、Athena が CSV、JSON、ORC、Avro、Parquet などのよく使用されるデータ形式に対応できるようにし、create table、drop table、alter table などのよく使用されるデータ定義言語 (DDL) オペレーションを追加する Apache Hive です。Athena は、構造化されたデータ形式および構造化されていないデータ形式で Amazon Simple Storage Service (S3) に保存されたデータセットへのパフォーマンスの高いクエリアクセスを可能にします。Hive 対応 DDL ステートメントと ANSI SQL ステートメントは、AWS マネジメントコンソールから、または Athena JDBC ドライバーをダウンロードして利用することで SQL Workbench などの SQL クライアントから、Athena Query Editor で記述できます。さらに、JDBC ドライバーを使用することで、目的の BI ツールからプログラムでクエリを実行できます。Amazon Athena サービスの詳細については、11 月のサービスリリース時の Jeff のブログ投稿を参照してください。Athena チームは、Amazon Athena サービスの初期の機能をリリースした後で、お客様を中心に考えるという Amazon の伝統に従い、サービスのカスタマーエクスペリエンスを向上させるよう勤勉に努力してきました。これにより、チームは今回発表する機能を追加し、Amazon Athena Amazon S3 での暗号化されたデータのクエリをサポートするようになりました。この新機能により、Athena は Amazon S3 で暗号化されたデータのクエリのサポートを提供できるだけではなく、Athena のクエリ結果からデータの暗号化を可能にします。Amazon S3 に保存された機密データを暗号化する要件または規制がある業種やお客様は、Athena が暗号化されたデータで提供する、サーバーレスな動的クエリを活用できます。  暗号化のサポート Athena の新機能の使用について説明する前に、データの保護と暗号化の必要があるお客様向けに S3 と Athena がサポートする暗号化オプションについて時間をかけて見てみましょう。現在、S3 は AWS Key Management Service (KMS) を使用したデータの暗号化をサポートしています。AWS KMS は、データの暗号化に使用される暗号化キーの作成と管理のためのマネージド型サービスです。さらに、S3 は、お客様による独自の暗号化キーを使用したデータの暗号化をサポートします。S3 に保存されたデータセットに対して Athena がサポートする暗号化オプションを理解することが重要であるため、S3 と Athena でサポートされる暗号化オプションの詳細と、暗号化されたデータアクセスに新しい Athena テーブルプロパティ has_encrypted_data が必要となる場合を、次の表に示します。

AWS KMS または Amazon S3 の暗号化オプションを使用した Amazon S3 の暗号化の詳細については、AWS KMS 開発者ガイドの「Amazon Simple Storage Service (Amazon S3) が AWS KMS を使用する方法」および Amazon S3 開発者ガイドの「暗号化を使用したデータの保護」の情報をそれぞれ参照してください。  暗号化されたデータベースとテーブルの作成とアクセス 前に説明したように、Athena へのアクセス方法はいくつかあります。もちろん、AWS マネジメントコンソールを通じて Athena にアクセスできますが、SQL Workbench などの SQL クライアントや他のビジネスインテリジェンスツールで JDBC ドライバーを使用するオプションもあります。さらに、JDBC ドライバーでは、プログラムによるクエリアクセスもできます。十分に説明したので、データベースといくつかのテーブルを作成し、テーブルからクエリを実行してクエリ結果を暗号化することにより、Athena サービスのこの新機能について詳しく見てみましょう。これらの操作はすべて、Amazon S3 に保存されている暗号化されたデータを使用して行います。初めてサービスにログインすると、次に示すような [Amazon Athena Getting Started] 画面が表示されます。Athena Query Editor に移動するには、[Get Started] ボタンをクリックする必要があります。

Athena Query Editor に移動したので、データベースを作成しましょう。Query Editor を開くときにサンプルデータベースが表示される場合は、[Query Editor] ウィンドウでクエリステートメントの入力を開始してサンプルクエリを消去し、新しいデータベースを作成します。[Query Editor] ウィンドウ内で Hive DDL コマンド CREATE DATABASE <dbname> を発行して、データベース tara_customer_db を作成します。

Query Editor の [Results] タブで、クエリの実行が成功したことの確認が表示されたら、データベースは作成され、ドロップダウンで選択できる状態です。

ここで、ドロップダウンで選択したデータベースを、新しく作成したデータベース tara_customer_db に変更します。 データベースを作成したので、S3 に保存されているデータからテーブルを作成できます。私はさまざまな暗号化タイプでデータを暗号化しなかったため、製品グループが、S3 バケットに保存するサンプルデータファイルを渡してくれました。私が受け取った最初のバッチのサンプルデータは SSE-KMS で暗号化されていて、上記の暗号化テーブルマトリックスで示したように、この暗号化タイプは AWS KMS で管理されたキーによるサーバー側の暗号化です。私は暗号化されたデータのこのセットを、適切に名前を付けた S3 バケットである aws-blog-tew-posts/SSE_KMS_EncryptionData に保存しました。私が受け取った 2 番目のバッチのサンプルデータは CSE-KMS です。この暗号化タイプは AWS を使用したクライアント側の暗号化で、aws-blog-tew-posts/ CSE_KMS_EncryptionData S3 バケットに保存されています。私が受け取った最後のバッチのデータは、古き良きプレーンテキストで、このデータは S3 バケット aws-blog-tew-posts/PlainText_Table に保存しました。

S3 バケットのこのデータは Athena サービスからアクセスすることを覚えておいてください。各バケットとそこに保存されているデータへの Athena によるアクセスを許可するため、データバケットに正しいアクセス権限があることを確認する必要があります。さらに、AWS KMS で暗号化されたデータを操作するには、ユーザーには適切な KMS キーポリシーを含むロールが必要です。KMS で暗号化されたデータを正しく読み取るには、ユーザーには S3、Athena、および KMS にアクセスするための正しいアクセス権限が必要です。S3 と Athena サービスの間で適切なアクセス権限を提供するには、いくつかの方法があります。

  1. ユーザーポリシーを通じてアクセスを許可する
  2. バケットポリシーを通じてアクセスを許可する
  3. バケットポリシーとユーザーポリシーを通じてアクセスを許可する。

Amazon Athena のアクセス権限、Amazon S3 のアクセス権限、またはその両方の詳細については、Athena のドキュメントの「ユーザーおよび Amazon S3 バケットのアクセス権限の設定」を参照してください。S3 バケットでデータの準備と設定ができたので、後は Athena Query Editor に移動して、SSE-KMS 暗号化データから最初の新しいテーブルを作成するだけです。新しいテーブル sse_customerinfo を作成するために使用する DDL コマンドは次のとおりです。

CREATE EXTERNAL TABLE sse_customerinfo( 
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
  ) 
ROW FORMAT SERDE  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' 
LOCATION  's3://aws-blog-tew-posts/SSE_KMS_EncryptionData';

sse_customerinfo テーブルを作成する DDL コマンドステートメントを Athena Query Editor に入力し、[Run Query] ボタンをクリックします。[Results] タブに、クエリが正常に実行されたことが示され、tara_customer_db データベースで利用できるテーブルの下に、新しいテーブルが表示されます。

このプロセスを繰り返して、CSE-KMS で暗号化されたデータのバッチから cse_customerinfo テーブルを作成し、S3 バケットに保存されている暗号化されていないデータソースから plain_customerinfo テーブルを作成します。cse_customerinfo テーブルを作成するために使用する DDL ステートメントは次のとおりです。

CREATE EXTERNAL TABLE cse_customerinfo (
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
)
ROW FORMAT SERDE   'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION   's3://aws-blog-tew-posts/CSE_KMS_EncryptionData'
TBLPROPERTIES ('has_encrypted_data'='true');

ここでも、Athena Query Editor に上記の DDL ステートメントを入力し、[Run Query] ボタンをクリックします。cse_customerinfo テーブルの作成に使用された DDL ステートメントを注意深く確認すると、新しいテーブルプロパティ (TBLPROPERTIES) フラグ has_encrypted_data が、新しい Athena 暗号化機能に導入されたことがわかります。このフラグは、指定されたテーブルのクエリに使用する S3 のデータは暗号化されたデータであることを Athena に指定するために使用します。時間を取って、Athena と S3 暗号化オプションについて前に確認した暗号化マトリックステーブルをもう一度参照してください。このフラグが必要なのは、[Client-Side Encryption with AWS KMS–Managed Keys] オプションを使用するときだけであることがわかります。cse_customerinfo テーブルが正しく作成されると、の記号がテーブルの横に表示され、テーブルは暗号化されたデータテーブルであることが識別されます。

最後に、サンプルデータから最後のテーブル plain_customerinfo を作成します。前のテーブルに対して実行したのと同じステップです。このテーブルの DDL コマンドは次のとおりです。

CREATE EXTERNAL TABLE plain_customerinfo(
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION 's3://aws-blog-tew-posts/PlainText_Table';


よくできました。Athena を使用して S3 から暗号化されたデータを正常に読み取り、暗号化されたデータに基づいてテーブルを作成しました。ここで、新しく作成した、暗号化されたデータテーブルに対してクエリを実行できます。  クエリの実行 新しいデータベーステーブルに対するクエリの実行は、非常に簡単です。ここでも、一般的な DDL ステートメントやコマンドを使用して、Amazon S3 に保存されたデータに対してクエリを作成できます。クエリの確認のため、Athena のデータのプレビュー機能を使用します。テーブルの一覧で、テーブルの横に 2 つのアイコンが表示されます。1 つのアイコンはテーブルプロパティアイコンで、これを選択すると、選択されたテーブルプロパティが表示されます。もう 1 つのアイコンはの記号で表示され、テーブル用の単純な SELECT クエリステートメントを生成するデータのプレビュー機能です。

  Athena を使用したクエリの実行を紹介するため、テーブルの横にある目のアイコンを選択して、plain_customerinfo のデータのプレビューを選択しました。データのプレビュー機能により、次の DDL ステートメントが作成されます。

SELECT * FROM plain_customerinfo limit 10;

plain_customerinfo テーブルでデータのプレビュー機能を使用したクエリ結果が、Athena Query Editor の [Results] タブに表示され、オプションでファイルアイコンをクリックすると、クエリ結果をダウンロードできます。

Athena の新しい暗号化されたデータ機能では、クエリ結果の暗号化と、結果の Amazon S3 への保存もサポートされます。クエリ結果でこの機能を活用するため、クエリデータを暗号化し、選択したバケットに保存します。現在、選択したデータテーブルは暗号化されていません。最初に Athena の [Settings] メニューを選択し、クエリ結果の現在のストレージ設定を確認します。暗号化に使用する KMS キーがないため、[Create KMS key] ハイパーリンクを選択し、クエリ結果を Athena と S3 で暗号化するために使用する KMS キーを作成します。KMS キーを作成し、適切なユーザーアクセス権限を設定する方法の詳細については、http://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html を参照してください。

s3encryptathena KMS キーを正しく作成し、Athena 設定で使用するキー ARN をコピーしたら、Athena コンソールの [Settings] ダイアログに戻り、[Encrypt query results] テキストボックスを選択します。次に、[Query result location] テキストボックスを更新し、s3 バケット aws-athena-encrypted を指します。これは暗号化されたクエリ結果を保存する場所となります。残っている唯一のことは、暗号化タイプの選択と KMS キーの入力です。これを行うには、[Encryption key] ドロップダウンから s3encryptathena キーを選択するか、[KMS key ARN] テキストボックスに ARN を入力します。この例では、暗号化タイプに SSE-KMS を使用するよう選択しました。以下で、KMS キーを選択する両方の例を参照できます。[Save] ボタンをクリックすると、プロセスが完了します。

ここで、plain_customerinfo テーブルの現在のクエリを再実行します。このテーブルは暗号化されていませんが、クエリ結果に暗号化を追加するために行われた Athena の設定変更により、このテーブルに対して実行されたクエリ結果が、KMS キーを使用して SSE-KMS 暗号化により保存されるようにしました。

再実行の後で Amazon S3 コンソールに移動し、指定したバケット aws-athena-encrypted に保存した CSV データファイルと、バケットおよびファイルの SSE-KMS 暗号化を表示すると、作業の成果を確認できます。

 

概要 言うまでもなく、この Athena の発表には、暗号化によりデータを保護しながら、さまざまなデータ形式で保存されているデータのクエリと分析を実行する機能を維持したいお客様にとって複数の利点があります。さらに、このリリースにはこのブログ投稿で説明しなかった機能強化が含まれています。

  • 新しい暗号化機能とキーの更新をサポートする、JDBC ドライバーの新しいバージョン
  • ALTER TABLE を使用して列を追加、置換、変更する機能の追加。
  • LZO 圧縮データのクエリのサポートの追加。

詳細については、Athena ユーザーガイドのリリースドキュメントを参照してください。また、Athena ドキュメントの「暗号化オプションの設定」セクションを参照し、Amazon S3 に保存された暗号化されたデータのクエリを、Athena を利用して開始してください。AthenaAmazon S3 でのサーバーレスクエリの詳細については、Athena 製品ページを参照するか、Athena ユーザーガイドを確認してください。さらに、Athena の機能および S3 を使用したデータの暗号化の詳細については、AWS ビッグデータのブログ投稿「Amazon Athena を使用した S3 のデータの分析」および AWS KMS 開発者ガイドを参照できます。それでは、暗号化をご活用ください。- Tara

AWS KMSを使用してAmazon Kinesisレコードを暗号化および復号する

コンプライアンスやデータセキュリティの要件が厳しいお客様は、AWSクラウド内での保存中や転送中など、常にデータを暗号化する必要があります。この記事では、保存中や転送中もレコードを暗号化しながら、Kinesisを使用してリアルタイムのストリーミングアプリケーションを構築する方法を示します。

Amazon Kinesisの概要

Amazon Kinesisプラットフォームを使用すると、要求に特化したストリーミングデータを分析または処理するカスタムアプリケーションを構築できます。 Amazon Kinesisは、ウェブサイトクリックストリーム、金融取引、ソーシャルメディアフィード、ITログ、トランザクショントラッキングイベントなど、何十万ものソースから1時間につき数テラバイトのデータを連続的にキャプチャして保存できます。
Amazon Kinesis Streamsは、HTTPSを使用してクライアント間でデータを暗号化し、転送されているレコードの盗聴を防止します。ただし、HTTPSで暗号化されたレコードは、データがサービスに入ると解読されます。このデータは24時間保管され(最大168時間まで延長可能)、アプリケーションの処理、再処理、処理遅延の際の巻き取りに対して十分なゆとりが確保されています。

ウォークスルー

Amazon Kinesis Producer Library(KPL)、Kinesis Consumer Library(KCL)、AWS KMSaws-encryption-sdkを使用してサンプルKinesisプロデューサおよびコンシューマアプリケーションへの暗号化と復号を行います。この記事で使用されているKinesisレコードの暗号化と復号に使用される方法とテクニックは、あなたのアーキテクチャに簡単に再現できます。いくつか制約があります:

  • AWSは、暗号化と復号のためのKMS APIリクエストの使用料金を請求します。詳しくは、「AWS KMSの料金」を参照してください。
  • Amazon Kinesis Analyticsを使用して、このサンプルアプリケーションのクライアントによって暗号化されたレコードのAmazon Kinesis Streamにクエリすることはできません。
  • アプリケーションでレイテンシの低い処理が必要な場合は、レイテンシに多少の上乗せがあることに注意してください。

次の図は、ソリューションのアーキテクチャを示しています。

(more…)

AWS Organizationsを利用したアカウント作成の自動化

こんにちは、ソリューションアーキテクトの千葉です。

本日はAWS Organizationsを利用したAWSアカウントの作成・管理の自動化方法についてご紹介します。

AWS Organizationsは、組織内のAWSアカウントを統合管理し、セキュリティを高めることができるサービスです。サービスコントロールポリシー (SCP)を利用することで、組織内のAWSアカウントに実行を許可するサービスとアクションを一元的に管理することができます。
AWS Organizationsのもう一つの特徴は、APIを通じて組織配下に新しいAWSアカウントを作成することができることです。これまでは、AWSアカウントを新たに作るにあたって、AWSアカウント作成、連絡先情報入力、お支払情報入力、(必要に応じて)一括請求設定といった手順をマニュアルで実施する必要がありましたが、AWS Organizationsを利用すればこれらの操作はCreateAccountというたった一つのAPIに置換えられます。

AWS Organizationsで作成されたメンバーアカウントには、マスターアカウントのユーザーからアクセス可能なIAMロールが自動作成されます。AWS Security Token Service (STS)を利用してこのIAMロールにアクセスする一時的なセキュリティ認証情報を取得し、AWS Command Line Interface (CLI)AWS SDKsを使って作成したメンバーアカウントに対して共通設定を施したり、定期的な環境チェックを実行したりすることができます。

それでは、アカウント作成およびSTSを利用したアカウント環境設定の手順を説明していきます。

 

メンバーアカウントの作成

まずは組織配下にメンバーアカウントを作成します。操作を実行するIAMユーザーまたはIAMロールには、以下のようにOrganizationsを操作する権限を与えておきます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                 "organizations:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

CreateAccountのパラメーターには、アカウント名およびEmailアドレスを指定する必要があります。IamUserAccessToBillingパラメーターはメンバーアカウントのIAMユーザーにBilling情報へのアクセスを許可するかどうかの設定で、デフォルトでALLOWになっています。RoleNameパラメーターはメンバーアカウントに作成されるIAMロールの名前で、何も指定しなければOrganizationAccountAccessRoleという名前が割り当てられます。

import boto3
orgs = boto3.client('organizations',region_name='us-east-1')
createAccountRequest = orgs.create_account(
    "AccountName": "string",
    "Email": "string",
    "IamUserAccessToBilling": "string",
    "RoleName": "string"
    )

メンバーアカウントの作成は非同期でおこなわれるため、CreateAccountAPIのレスポンスに含まれるリクエストIDを指定してDescribeCreateAccountStatusを実行し、アカウント作成のステータスをトラッキングします。

createAccountRequestId = createAccountRequest["CreateAccountStatus"]["Id"]
while orgs.describe_create_account_status(CreateAccountRequestId=createAccountRequestId)["CreateAccountStatus"]["State"] != 'SUCCEEDED':
        time.sleep(5)

ステータスが”SUCCEEDEDになればメンバーアカウントの作成は完了です。DescribeCreateAccountStatusのレスポンスは以下のとおりです。AccoutIdは後の手順で利用します。

{
   "CreateAccountStatus": { 
      "AccountId": "string",
      "AccountName": "string",
      "CompletedTimestamp": number,
      "FailureReason": "string",
      "Id": "string",
      "RequestedTimestamp": number,
      "State": "string"
   }
}

 

STSを利用したメンバーアカウントの操作

STSは、AWS リソースへアクセスする一時的な認証情報を提供する機能です。STSの利用方法の詳細はこちらのドキュメントを参照してください。一時認証情報取得にはSTSのAssumeRoleアクションを実行する必要があるので、以下の操作を実行するマスターアカウントのIAMユーザー/IAMロールには以下のIAMポリシーを付与しておいてください。<MemberAccountId>には前手順で取得したメンバーアカウントのAWSアカウントIDを指定します。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<MemberAccountId>:role/OrganizationAccountAccessRole"
  }]
}

STSのAssumeRoleアクションを実行し、一時的な認証情報を取得します。

import boto3
from boto3.session import Session

sts = boto3.client('sts')
assumeRoleResult = sts.assume_role(
        RoleArn = 'arn:aws:iam::<MemberAccountId>:role/OrganizationAccountAccessRole',
        RoleSessionName = 'OrgMasterRoleSession'
        )

accessKeyId = assumeRoleResult["Credentials"]["AccessKeyId"]
secretAccessKey = assumeRoleResult["Credentials"]["SecretAccessKey"]
sessionToken = assumeRoleResult["Credentials"]["SessionToken"]

続いて、取得した一時認証情報でメンバーアカウントを操作するセッションを生成します。regionパラメーターはこの後実行する操作に合わせて指定してください。

session = Session(
        aws_access_key_id=accessKeyId,
        aws_secret_access_key=secretAccessKey,
        aws_session_token=sessionToken,
        region_name='us-east-1'
        )

あとはこのセッションを利用してメンバーアカウントに対して操作をおこなうだけです。OrganizationAccountAccessRoleにはAdministratorAccessポリシーがアタッチされているため、STSをサポートしているアクションであればすべて実行可能です。

試しに作成したメンバーアカウントに対してBillingアラートを設定してみましょう。

sns = session.client('sns')
cloudwatch = session.client('cloudwatch')
    
#create sns topic
snsTopicArn = sns.create_topic(Name='DefaultBillingAlertTopic')["TopicArn"]
sns.subscribe(
    TopicArn=snsTopicArn,
    Protocol='email',
    Endpoint=<YourEmailAddress>
    )

#create billing alert
alertName = 'DefaultBillingAlart'
cloudwatch.put_metric_alarm(
    AlarmName=alertName,
    AlarmDescription=alertName,
    ActionsEnabled=True,
    AlarmActions=[snsTopicArn],
    MetricName='EstimatedCharges',
    Namespace='AWS/Billing',
    Statistic='Maximum',
    Dimensions=[
        {
           'Name': 'Currency',
           'Value': 'USD'
        },
        ],
   Period=21600,
   EvaluationPeriods=1,
   Threshold=100,
   ComparisonOperator='GreaterThanOrEqualToThreshold'
   )

まとめ

リソースをプログラマブルに管理できることは、AWSを利用する大きな利点のひとつです。AWS Organizationsを利用することで、AWSアカウントについてもプラグラマブルに管理することが可能です。今回はBillingアラートを設定する例をご紹介しましたが、AWS CloudTrailAWS Configなどの有効化、AWS CloudFormationを利用した標準構成のデプロイなど、お客様がAWSアカウントを作成時に実行している操作を自動化することができます。ぜひOrganizationsを活用したアカウント管理をお試しください!

 

注1:SCPの権限制御は、アタッチされたアカウントのrootユーザーを含む、すべてのユーザーに影響を与える可能性がある強力な機能です。既存のアカウントに対してOrganizationsを適用する場合、SCPの動作を事前に検証し、実行する操作が既存環境に影響が出ないことを確認した上で有効化してください。

注2:Organizationsで作成したメンバーアカウントは削除することができませんのでご注意ください。

 

AWS Microsoft ADとオンプレミスの資格情報を使用してAWS管理コンソールにアクセスする方法

これは、AWS Security blogに投稿された「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」の翻訳記事です。


 

AWS Microsoft ADと略される、AWS Directory Service for Microsoft Active Directory は、AW​​Sクラウドにホストされた管理されたMicrosoft Active Directory(AD)です。オンプレミスのAD管理ツールを使用して、AWSリソースを管理する権限をユーザに簡単に付与できます。AWS Microsoft ADを使用すると、Identity and Access Management(IAM)を利用してAWSリソースへのアクセス管理をしたり、セキュリティアサーションマークアップ言語(SAML)でADフェデレーションサービス(AD FS)を構成する代わりに、オンプレミスユーザーにAWS管理コンソールなどのリソースへのアクセス許可を与えることができます。

このブログ記事では、AWS Microsoft ADを使用してオンプレミスのADユーザーがオンプレミスのADユーザー資格情報を使用してAWS管理コンソールにサインインし、IAMロールを通じてAWSリソースにアクセスして管理する方法を示します。

 

概要

AWSのお客様は、オンプレミスADを使用してユーザーアカウントを管理し、グループメンバーシップを管理し、オンプレミスリソースへのアクセスを制御します。 多くのAWS Microsoft ADのお客様がいる場合は、オンプレミスのAD資格情報を使用してAWS管理コンソールにサインインして、 Amazon EC2Amazon RDSAmazon S3などのAWSリソースを管理できるようにすることもできます。

このようなサインインパーミッションを有効にすると、主に4つの利点があります。

  1. オンプレミスのADグループ管理者は、IAMの代わりに標準のAD管理ツールを使用して、AWSリソースへのアクセスを管理できるようになります。
  2. ユーザーは、ADとAWS Management Consoleにサインインするために1つのIDのみを記憶すればよくなります。
  3. ユーザーはオンプレミスのAD資格情報でサインインするため、AWS管理コンソールへのアクセスには、AD強制パスワードポリシーの量可能になります。
  4. ADからユーザーを削除すると、AWS Microsoft ADとIAMは自動的にAWSリソースへのアクセスを取り消します。

IAMロールは、AWSリソースを管理する権限を定義する便利な方法を提供します。 AWS Microsoft ADとオンプレミスADの間のAD信頼関係を使用することで、オンプレミスのADユーザーとグループをIAMロールに割り当てることができます。 これにより、割り当てられたユーザとグループにAWSリソースを管理するためのIAMロールの権限が与えられます。 オンプレミスのADグループをIAMロールに割り当てることで、ADユーザとコンピュータ(ADUC)などの標準的なAD管理ツールを使用してAWSアクセスを管理できるようになります。

オンプレミスのユーザーやグループをIAMロールに割り当てた後、ユーザーはオンプレミスのAD資格情報を使用してAWS管理コンソールにサインインできます。 そこから、割り当てられたIAMロールのリストを選択できます。 ロールを選択すると、IAMロールに割り当てた管理機能を実行できます。

この記事の残りの部分では、これを4つのステップで達成する方法を示します。

  1. アクセスURLの作成。
  2. AWS管理コンソールへのアクセスの有効化。
  3. オンプレミスのユーザーとグループをIAMロールへの割り当て。
  4. AWS管理コンソールへの接続。

 

前提条件

このブログ記事の指示に従い、次のコンポーネントを実行する必要があります。

  • AWSクラウドで作成されたMicrosoft ADディレクトリ。 詳細については、「Create a Microsoft AD Directory」を参照してください。
  • 既存のオンプレミスActive Directory。
  • AWS Microsoft ADからオンプレミスActive Directoryへの双方向におけるフォレストの信頼関係。 詳細は、「Now Available: Simplified Configuration of Trust Relationships in the AWS Directory Service Console」を参照してください。 信頼に関する追加情報、およびAWS管理コンソールへのドメインレスサインインのアクセス方法については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。
  • AWSディレクトリサービスに設定された信頼関係を持つIAMロール。 これを行うにはヘルプが必要な場合は、「Editing the Trust Relationship for an Existing Role」を参照してください。

注: AWS Microsoft ADに格納されているユーザーIDにIAMロールを割り当てることができます。この記事では、オンプレミスのADに格納されているユーザーIDにIAMロールを割り当てることに重点を置いています。 これには、オンプレミスのActive DirectoryとAWS Microsoft ADディレクトリの間にフォレストの信頼関係が必要です。

 

ソリューションの概要

私が自分の会社のADとIAMロールの両方を管理する管理者だとします。私の会社では、全従業員がオンプレミスの資格情報を使用してAWS管理コンソールにサインインし、AWSリソースにアクセスして管理できるようにしたいと考えています。私の会社はEC2、RDS、S3を使用しています。これらのリソースへの管理権限を管理するために、サービスに完全にアクセスできるように各サービスの権限を作成しました。これらのロールにEC2FullAccess、RDSFullAccess、および、S3FullAccessという名前を付けました 。

私の会社には責任の異なる2つのチームがあり、ADセキュリティグループのユーザーを管理しています。 MaryはDevOpsセキュリティグループのメンバーであり、RDSデータベースの作成と管理、EC2でのデータ収集アプリケーションの実行、S3での情報のアーカイブを担当しています。JohnとRichardはBIMgrsセキュリティグループのメンバーで、EC2を使用してデータベースに対して分析プログラムを実行します。 JohnンとRichardはデータベースとアーカイブされた情報にアクセスする必要がありますが、それらのシステムを操作する必要はありません。EC2インスタンスを管理するための許可が必要です。

AWSリソースへの適切なアクセスを許可するには、ADのBIMgrsセキュリティグループをIAMのEC2FullAccessロールに割り当て、 DevOpsグループを3つのロール(EC2FullAccess 、RDSFullAccess、およびS3FullAccess)すべてに割り当てる必要があります。また、AWS Management Consoleにサインインした後で、従業員全員が十分な管理作業を完了できるようにしたいので、コンソールセッションタイムアウトを60分から240分(4時間)に増やします。

次の図は、私の会社のADユーザーとグループと私の会社のAWSの権限とサービスの関係を示しています。 図の左側は、ユーザーとグループを含む私のオンプレミスのADを表しています。 右側は、AWS管理コンソール、AWSリソース、IAMロール、およびオンプレミスADにフォレストの信頼関係を介して接続されたAWS Microsoft ADディレクトリを含むAWSクラウドを表しています。

 

このシナリオの手順を開始しましょう。この記事では、すでにAWS Microsoft ADディレクトリが作成されており、AWS Microsoft ADからオンプレミスADへの双方向フォレストの信頼を確立しています。AWSリソースへのアクセスを管理するため、以下のIAMロールも作成してあります。

  • EC2FullAccess :EC2へのフルアクセスを提供し、 AmazonEC2FullAccess AWS管理ポリシーを添付します。
  • RDSFullAccess :AWS管理コンソール経由でRDSへのフルアクセスを提供し、 AmazonRDSFullAccess管理ポリシーを添付します。
  • S3FullAccess :AWS管理コンソール経由でS3へのフルアクセスを提供し、 AmazonS3FullAccess管理ポリシーを添付します。

IAMロールを作成して管理ポリシーを添付する方法の詳細については、「管理ポリシーのアタッチ」を参照してください。

注: Microsoft ADを使用してAWS管理コンソールにサインインするユーザーがアクセスする必要があるすべてのロールに、ディレクトリサービス信頼ポリシーを含める必要があります。 詳細は、「Editing the Trust Relationship for an Existing Role」を参照してください。

 

ステップ1 – アクセスURLを作成する

AWS Management Consoleへのアクセスを有効にするための最初の手順は、AWS Microsoft ADディレクトリのための一意のアクセスURLを作成することです。アクセスURLは、グローバルに一意のURLです。AWS管理コンソールなどのAWSアプリケーションは、URLを使用して、AWS Microsoft ADディレクトリにリンクされているAWSサインインページに接続します。 アクセスURLは、ディレクトリへの他のアクセスを提供しません。 アクセスURLの詳細については、「Creating an Access URL」を参照してください。

アクセスURLを作成するには、次の手順を実行します。

 

  1. ディレクトリサービスコンソールに移動し、AWS Microsoft AD Directory IDを選択します。
  2. Directory Detailsページで、Apps & Services タブを選択し 、Access URL ボックスに一意のアクセスエイリアスを入力し、 Create Access URLを選択してディレクトリのアクセスURLを作成します。ディレクトリのアクセスURLは、 <access-alias> .awsapps.comという形式にする必要があります。 この例では、 https://example-corp.awsapps.comを使用しています。

 

ステップ2 – AWS管理コンソールへのアクセスを有効にする

ユーザがオンプレミスの認証情報でAWS Management Consoleにサインインできるようにするには、AWS Microsoft ADディレクトリのAWS管理コンソールアクセスを有効にする必要があります。

  1. ディレクトリサービスコンソールから、AWS Microsoft AD Directory IDを選択します。 AWS apps & servicesセクションのAWS Management Consoleリンクを選択します。
  2. Enable AWS Management Consoleダイアログボックスで、 Enable Accessを選択して、ディレクトリに対するコンソールアクセスを有効にします。

    これにより、AWS Microsoft ADディレクトリのAWS Management Consoleへのアクセスが可能になり、コンソールに接続するためのURLが提供されます。 URLは、ステップ1: <access-alias>.awsapps.com/consoleで作成したアクセスURLの末尾に「 /console 」を付加して生成されます。 この例では、AWS管理コンソールのURLは、https://example-corp.awsapps.com/consoleです。

 

ステップ3 – オンプレミスのユーザーおよびグループをIAMロールに割り当てる

ユーザーがアクセスURLを使用してAWS管理コンソールにサインインする前に、オンプレミスのユーザーまたはグループをIAMロールに割り当てる必要があります。このステップで、オンプレミスのユーザーおよびグループがAWS管理コンソールからアクセス可能なAWSリソースを制御できます。

私のオンプレミスのActive Directoryでは、 Maryは既にDevOpsグループのメンバーであり、JohnとRichardはBIMgrsグループのメンバーです。私はすでにAWS Microsoft ADから私のオンプレミスADへの信頼関係を確立しました。EC2FullAccess 、RDSFullAccessおよびS3FullAccessの権限を作成できました。

これで、オンプレミスグループをIAMロールに割り当てる準備が整いました。私はDevOpsグループをEC2FullAccess、RDSFullAccess 、およびS3FullAccess IAMロールに割り当て、BIMgrsグループをEC2FullAccess IAMロールに割り当てます。オンプレミスグループをIAMロールに割り当てるには、次の手順に従います。

  1. AWS Microsoft ADディレクトリのディレクトリサービスの詳細ページを開き、Apps & servicesタブのAWS Management Console リンクを選択します。 Continue を選択して、 Add Users and Groups to Rolesページに移動します。
  2. Add Users and Groups to Rolesページでは、既に設定した3つのIAMロールが表示されます(次のスクリーンショットを参照)。 ディレクトリサービス信頼ポリシーが有効なIAMロールがない場合は、 新しいロールを作成するか、既存のロールに対してディレクトリサービスを有効にすることができます。
  3. オンプレミスのDevOpsグループとBIMgrsグループをEC2FullAccessロールに割り当てます。これを行うために、私はEC2FullAccess IAMロールリンクを選択して、Role Detailページに移動します。 次に、次のスクリーンショットに示すように、 Addボタンをクリックしてユーザーまたはグループをロールに割り当てます。
  4. Add Users and Groups to Role ポップアップウィンドウで、割り当てるユーザーとグループを含むオンプレミスのActive Directoryフォレストを選択します。 この例では、そのフォレストはamazondomains.comです。 注:オンプレミスADへの信頼を使用せず、AWS Microsoft ADディレクトリにユーザーとグループを作成する場合は、 このフォレストのデフォルトを選択してMicrosoft ADのユーザーを検索できます。
  5. Active Directoryグループを割り当てるには、Search forフィールドの上にあるGroupフィルタを選択します。 検索ボックスにActive Directoryグループの名前を入力し、検索ボタン(虫眼鏡のマークを選択します。 私はオンプレミスのActive DirectoryからDevOpsグループを検索できたことがわかります。
  6. この例では、社内のグループDevOpsとBIMgrsをEC2FullAccessロールに追加しています。終了したら、Addボタンを選択して、ユーザとグループをIAMロールに割り当てます。 これで、DevOpsとBIMgrsオンプレミスADグループにEC2へのフルアクセスが正常に付与されました。これらのADグループのユーザは、自社の認証情報を使用してAWS管理コンソールにサインインし、EC2インスタンスを管理できるようになりました。
    Add Users and Groups to Rolesページから、残りのグループをIAMロールに割り当てるプロセスを繰り返します。次のスクリーンショットでは、DevOpsグループを3つのロールに、BIMgrsグループを1つのロールに割り当てたことがわかります。
    ADセキュリティグループを自分のIAMロールに割り当てることで、オンプレミスユーザーをセキュリティグループに追加および削除して、IAMロールへのアクセス許可を付与または取り消すことができます。これらのセキュリティグループのユーザーは、割り当てられたすべての権限にアクセスできます。
  7. オプションで、AWS Microsoft ADディレクトリのログインセッション長を設定できます。デフォルトの長さは1時間ですが、最大12時間まで延長できます。私の例では、コンソールのセッション時間を240分(4時間)に設定しています。

 

ステップ4 – AWS管理コンソールに接続する

私は、ユーザが自社の認証情報でAWS Management Consoleにサインインできるようになりました。 ステップ2で作成したアクセスURL: https://example-corp.awsapps.com/consoleを自社のユーザーにメールで送信しました。 これで、ユーザーはURLにアクセスしてAWS Management Consoleにサインインできます。

DevOpsグループのメンバーであるMaryがアクセスURLにアクセスすると、AWS Management Consoleに接続するためのサインインページが表示されます。 Usernameボックスでは、3つの方法でサインイン名を入力できます。

  • 社内のNetBIOSログイン名(corp\mary)の指定。
  • 彼女の完全修飾ドメイン名(FQDN)のログイン名( amazondomains.com\mary)の指定。
  • ドメインなしのログインで彼女のユーザー名だけを使用。ドメインレスログインの詳細については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。

DevOpsグループは3つのIAMロールに関連付けられており、MaryはDevOpsグループに属しているため、ログイン後に表示されるリストから希望するロールを選択できます。次のスクリーンショットはこのステップを示しています。

マルチファクタ認証(MFA)を使用してAWS管理コンソールを保護する場合は、AWS Microsoft AD設定にMFAを追加することもできます。 Microsoft ADでMFAを有効にする方法の詳細については、「How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials」を参照してください。

まとめ

AWS Microsoft ADを使用すると、オンプレミスの資格情報を使用してAWS管理コンソールに簡単に接続できます。 また、AWSリソースへのアクセスを制御しながら、パスワード有効期限、パスワード履歴、アカウントロックアウトポリシーなどの社内ADセキュリティポリシーを再利用することもできます。

ディレクトリサービスの詳細については、 AWS Directory Serviceのホームページを参照してください 。 このブログの投稿に関するご質問がある場合は、 ディレクトリサービスフォーラムで新しいスレッドを開始してください。

– Vijay


 

翻訳:瀧澤与一(原文:「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」 – https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/

AWS Organizations – 複数の AWS アカウントのポリシーベースの管理

複数の AWS アカウントを管理しているお客様が少なくありません。いくつかの理由が考えられます。AWS を徐々に導入して全体に広げている組織では、個別のチームや部門が一元管理されることなくクラウドコンピューティングに移行している場合があります。合併や買収を通じて成長している組織では、既存のアカウントを引き継ぐ場合があります。厳格なコンプライアンスのガイドラインに従うため、またはアプリケーション間に強い隔離障壁を設けるための通常の対策として複数のアカウントを作成する場合もあります。さらに開発、テスト、実稼働の目的別に異なるアカウントを使用する場合もあります。アカウント数が増大すると、全体をスケーラブルに管理する方法が必要になります。お客様は、チーム、部門、アプリケーションごとのアカウントを個別に扱わずに、アクセスコントロールポリシーを定義して全体、一部、または個別のアカウントに簡単に適用する方法を求めています。このようなお客様は、さらに請求やコスト管理にも関心が高い場合が多く、ボリュームディスカウントやリザーブドインスタンスなどの AWS の料金面でのメリットを、より広範囲にアカウントに反映できることを希望しています。

AWS Organizations がプレビューから一般公開へ
このユースケースの重要性が増していることから、本日より、AWS Organizations のプレビューを終了して一般提供を開始します。AWS Organizations では複数の AWS アカウントを一元管理できます。組織単位 (OU) の階層構造を作成して各アカウントを OU に割り当て、さらにポリシーを定義して階層構造の全体、特定の OU、または特定のアカウントに適用できます。また、既存の AWS アカウントを招待して組織に追加できます。新規アカウントを作成することもできます。以上のすべての機能は、AWS Management ConsoleAWS Command Line Interface (CLI)、および AWS Organizations API から利用できます。AWS Organizations の理解に役立つ重要な用語と概念をいくつか紹介します (ユーザーが組織の AWS アカウント全体に対して全権を持ち、マスターアカウントを担当する管理者であることを前提とします)。

組織は、管理対象の AWS アカウントの統合セットです。新しい組織を作成して、サービスコントロールポリシーなどの高度なアカウントレベルのコントロールを実装できます。組織の管理者は、アカウント別に許可および拒否する AWS API 関数やリソースのリストを管理できます。たとえば、先端 R&D チームには広範な AWS のサービスへのアクセス権を与え、メインストリームの開発およびテストアカウントにはアクセス権を一部制限できます。または、実稼働環境では、HIPAA の準拠に該当する AWS のサービスに限ってアクセスを許可できます。AWS の既存のお客様は、一括請求 (コンソリデーティッドビリング) と呼ばれる AWS の機能を利用している場合があります。この機能で支払いアカウントを選択すると、複数の AWS アカウントのアカウントアクティビティを 1 つの請求書にまとめてコストを一元管理できます。今回のリリースで、現在一括請求をご利用のお客様は、AWS Organizations を通じて一括請求のすべての機能を利用できます。ただし、本日から提供開始される新しい機能 (サービスコントロールポリシーなど) はデフォルトでは利用可能になりません。この場合、AWS Organizations のすべての機能は簡単に有効にすることができます。まず、組織のマスターアカウントから AWS Organizations のすべての機能を使用可能にして、次に、この変更を各メンバーアカウントに認証してもらいます。最後に、当社では一括請求機能のみをサポートする組織の新規作成を今後もサポートします。今後も一元化された請求機能のみを使用できます。その場合は、マスターアカウントの管理者が組織のメンバーアカウントに詳細なポリシーコントロールを適用することを許可しません。AWS アカウントは、AWS リソースのコンテナです。マスターアカウントは、組織の管理ハブであり、組織のすべての AWS アカウントの支払いアカウントでもあります。また、マスターアカウントは、既存のアカウントを招待して組織に追加できます。新規アカウントを作成することもできます。メンバーアカウントは、組織のマスターアカウント以外のアカウントです。組織単位 (OU) は、AWS アカウントのセットのコンテナです。OU は、最大 5 階層で構成される階層構造内に配置できます。OU の階層構造の最上位は、管理ルートとも呼ばれます。サービスコントロールポリシー (SCP) は、組織のマスターアカウントが組織、選択された OU、または選択されたアカウントに適用できるコントロールのセットです。OU に適用すると、SCP は当該の OU と階層構造でそれより下位にある他のすべての OU に適用されます。メンバーアカウントの有効な SCP では、そのアカウントのルートユーザーに付与するアクセス許可を指定します。アカウント内では、IAM ユーザーおよびロールを通常どおりに使用できます。ただし、ユーザーやロールのアクセス許可の内容にかかわらず、有効なアクセス許可のセットが SCP で定義されている範囲を超えて適用されることはありません。これを利用して、アカウントレベルで AWS のサービスや API 関数へのアクセスを細かくコントロールできます。招待は、AWS に対して組織への参加をリクエストする際に使用します。招待の承諾期限は 15 日間ですが、メールアドレスまたはアカウント ID を使用して延長できます。未承諾の招待は同時に最大 20 件まで保持できます。招待ベースのモデルでは、マスターアカウントから既存のアカウントを招待できます。招待が承諾されると、アカウントが組織に追加され、すべての該当するポリシーが有効になります。組織に追加されたアカウントは、適切な OU に移動できます。AWS Organizations は、管理対象の AWS アカウント間に強力な隔離障壁を設ける場合に有効です。ただし、AWS リソース (EC2 インスタンス、S3 バケットなど) は特定の AWS アカウント内にあり、アカウント間では移動できないことに注意してください。さまざまなクロスアカウントの AWS 機能にはアクセスできます。たとえば、VPC ピア接続AMI の共有EBS スナップショットの共有RDS スナップショットの共有クロスアカウントの E メール送信IAM ロールによるアクセス委任クロスアカウントの S3 バケットのアクセス許可AWS マネジメントコンソールでのクロスアカウントアクセスなどの機能は利用できます。一括請求と同じように、EC2 および RDS リザーブドインスタンスの使用についても、AWS Organizations にはいくつかの利点があります。請求目的においては、組織のすべてのアカウントが 1 つのアカウントであるかのように扱われ、同じ組織の他の任意のアカウントで購入された RI の時間単位のコストメリットを受けることができます (このメリットが想定どおりに適用されるためには、RI のアベイラビリティーゾーンおよび他の属性が EC2 または RDS インスタンスの属性と一致する必要があります)。組織の作成 コンソールから組織を作成し、複数の組織単位を作成して、さらに複数のアカウントを作成してみましょう。まず、[Create organization] をクリックします。

次に [ENABLE ALL FEATURES] を選択して、[Create organization] をクリックします。

組織が数秒で作成されます。

新しいアカウントを作成するには、[Add account] をクリックして、[Create account] を選択します。

次に、詳細を指定します (IAM ロールを新しいアカウントで作成し、作成した IAM ロールからアカウントのカスタマイズに必要なアクセス許可を付与します)。

Dev アカウント、Test アカウント、Prod アカウントの作成後のコンソールは以下のようになります。

この時点では、すべてのアカウントが階層構造の最上位にあります。

下位構造を追加するには、[Organize accounts] をクリックして、[Create organizational unit (OU)] を選択し、名前を入力します。

2 つ目の OU にも同じ操作を行います。

次に Prod アカウントを選択し、[Move accounts] をクリックして、Operations OU を選択します。

次に、Dev アカウントと Test アカウントを Development OU 内に移動します。

この時点で 4 つのアカウント (最初の 1 つおよび先ほど作成した 3 つ) と 2 つの OU があります。次のステップとして、サービスコントロールポリシーを作成します。[Policies] をクリックして [Create policy] を選択します。ここで Policy Generator を使うか、既存の SCP をコピーしてカスタマイズするかを選択できます。Policy Generator を使うことにします。ポリシーに名前を付けて、Allow ポリシーとして指定します。

次に、Policy Generator を使用して EC2 と S3 への完全なアクセスと Lambda 関数を実行する (呼び出す) ことを許可するポリシーを構築します。

このポリシーでは、アカウント内の実行可能なアクションのフルセットを定義するだけであることに注意してください。これらのアクションをアカウント内の IAM ユーザーが使用することを許可するには、さらに適切な IAM ポリシーを作成してユーザーにアタッチする必要があります (すべてに操作はメンバーアカウント内で行います)。[Create policy] をクリックしてポリシーを作成します。

次に開発およびテスト用として 2 つ目のポリシーを作成します。このポリシーでも、AWS CodeCommitAWS CodeBuildAWS CodeDeploy、および AWS CodePipeline へのアクセスを許可します。

ここまでで、アカウントを作成して OU 内に配置しました。さらに OU のためのポリシーを作成しました。次にポリシーを使用可能にし、ポリシーを OU にアタッチする必要があります。ポリシーを使用可能にするには、[Organize accounts] をクリックして [Home] を選択します (ホームはルートと同じではありません。Organizations は複数の独立した階層構造をサポートするように設計されています)。さらに Root OU のチェックボックスをオンにします。次に、右側の [Details] セクションを展開し、[Enable] をクリックします。

これで、すべての要素が揃いました。Root OU をクリックして階層構造内に移動し、Operations OU のチェックボックスをオンにします。次に、右側の [Details] セクションを展開し、[Attach policy] をクリックします。

次に [OperationsPolicy] を見つけて [Attach] をクリックします。

最後に、[FullAWSAccess] ポリシーを削除します。

また、Development OU に DevTestPolicy をアタッチできます。上で説明したすべてのオペレーションを行うには、AWS Command Line Interface (CLI) を使用するか、以下の関数を呼び出すこともできます。 CreateOrganizationCreateAccountCreateOrganizationalUnitMoveAccountCreatePolicyAttachPolicy、および InviteAccountToOrganization。CLI を使用する方法については、「AWS Organizations を発表: 複数の AWS アカウントの一元管理」を参照してください。

AWS Organizations を使用するためのベストプラクティス
最後に、AWS Organizations を使用するためのベストプラクティスを紹介します。マスターアカウント – マスターアカウントには、オペレーション用の AWS リソースを (1 つを例外として) 関連付けないことをお勧めします。これにより、適切なコントロールを判断しやすくなり、AWS の請求内容を理解しやすくなります。CloudTrail – メンバーアカウントでのすべての AWS 使用状況を一元的に追跡するには、マスターアカウントで AWS CloudTrail (これが例外) を使用します。最少の特権 – OU のポリシーを設定する場合は、割り当てる特権をできるだけ少なくします。組織単位 – ポリシーはアカウントにではなく OU に対して割り当てます。これにより、組織構造および必要な AWS アクセスレベルがより適切にマッピングされます。テスト – スケールアップする前に 1 つのアカウントで新規ポリシーと変更されたポリシーをテストします。自動化 – API と AWS CloudFormation テンプレートを使用して、すべての新規作成されたアカウントが適切に設定されていることを確認します。テンプレートで IAM のユーザー、ロール、およびポリシーを作成できます。ログ記録の設定、VPC の作成と設定などを行うこともできます。

詳細
以下は、AWS Organizations の使用を開始するために役立つリソースです。

 

主要事項
AWS Organizations は、China (Beijing)AWS GovCloud (US) を除くすべての AWS リージョンで本日から無料で公開されます (より正確には、サービスエンドポイントが US East (Northern Virginia) にあり、SCP はすべての該当リージョンで適用されます)。すべてのアカウントの販売者は同一でなければならず、同じ組織内で AWS と AISPL (インドで AWS のサービスアカウントのリセラーとなっている現地インド法人) を合わせて使うことはできません。AWS Organizations は今後大きく拡張される予定であり、複数の支払いアカウント、リザーブドインスタンス割引の割り当てのコントロール、複数の階層構造、その他のコントロールポリシーなどに対するサポートの追加が現在検討されています。今回も、皆さまからのご意見やご提案をお待ちしております。

Jeff;

Amazon クラウドディレクトリ – 階層データ用のクラウドネイティブなディレクトリ

当社のお客様は、これまでディレクトリ (一般的には Active Directory ライトウェイトディレクトリサービスや LDAP ベース) を使って階層別に整理されたデータを管理してきました。しばしば階層として表されるものには、デバイスレジストリ、コースカタログ、ネットワーク設定、ユーザーディレクトリがあり、同じコレクション内のオブジェクト間で複数のタイプの関係を持つ場合もあります。たとえば、ユーザーディレクトリは物理的な場所 (国、都道府県、市町村、建物、フロアー、オフィス) に基づいて 1 つの階層を持ち、プロジェクトや請求コードに基づいて 2 つ目の階層を持ち、管理チェーンに基づいて 3 つ目の階層を持つ場合があります。ただし、従来のディレクトリ技術では、単一のディレクトリ内で複数の関係の使用がサポートされません。これを行う必要がある場合は、追加のディレクトリを作成して管理する必要があります。もう 1 つの重要な課題として、スケールがあります。階層の基本的なオペレーションとして、特定のオブジェクトの親オブジェクトまたは子オブジェクトを見つける必要があります。その階層を使用して大規模なネストした情報のコレクションを表すことができる場合、この基本的なオペレーションは、オブジェクトの数やネストの深さにかかわらず、可能な限り効率的でなければなりません。従来のディレクトリはスケールが困難で、複数の階層を表すために 2 つ以上のディレクトリを使用する場合、苦労が増すばかりです。

新しい Amazon クラウドディレクトリ
本日、Amazon Cloud Directoryをリリースします。このサービスは、上記で説明したような、厳密に型指定された大量の階層データの保存に焦点を絞ったものです。コスト効率を維持しながら数億個のオブジェクトにスケールする機能により、Cloud Directory はあらゆる種類のクラウドおよびモバイルアプリケーションに最適です。Cloud Directory は、Amazon CognitoAWS Organizations を含む、他の AWS のサービスで既に利用されている構成要素です。これは AWS 内で非常に重要な役割を果たすため、スケーラビリティ、高可用性、およびセキュリティを考慮して設計されました (データは保管時および伝送中に暗号化されます)。Amazon Cloud Directory はマネージド型サービスであるため、ソフトウェアのインストールやパッチ適用、サーバーの管理、ストレージまたはコンピューティングインフラストラクチャのスケーリングについて考える必要がありません。スキーマを定義し、ディレクトリを作成してから、クラウドディレクトリ API を呼び出してディレクトリへの入力を行うだけです。この API は速度とスケールを実現し、効率的なバッチベースの読み書き関数を持つよう設計されています。ディレクトリの長期間使用できる特性に、運用期間中にサポートする必要があるユースケースのスケールや多様性を組み合わせることで、別の課題が明らかになります。経験によれば、静的スキーマはスケールと新しいユースケースによって生じる変更に対応する柔軟性に欠けることがわかっています。この課題に対応し、ディレクトリを将来にも十分対応できるようにするため、Cloud Directory は変更の余地を明確に残したモデルという概念に基づいて作成されています。新しいファセットを追加して、既存のスキーマを拡張します。これは既存のデータをそのまま残す安全なオペレーションであり、既存のアプリケーションは引き続き予期どおり動作します。スキーマとファセットを組み合わせることにより、同じディレクトリ内で複数の階層を表すことができます。たとえば、最初の階層では組織図をミラーリングするとします。後で、各従業員の追加のプロパティ (2 番目の電話番号またはソーシャルネットワークのハンドルなど) を追跡するために別のファセットを追加できます。その後、同じデータ内で地理指向の階層を作成できます (国、都道府県、建物、フロアー、オフィス、従業員など)。説明したように、AWS の他の部分では既に Amazon Cloud Directory を使用しています。Cognito ユーザープールCloud Directory を使用してアプリケーション固有のユーザーディレクトリを提供しており、ユーザーのサインアップ、サインイン、および多要素認証をサポートしています。Cognito ユーザープールでは、数億人のユーザーをサポートするようスケールするフルマネージ型のサービスにより、モバイルおよびウェブアプリに簡単かつ安全にサインアップおよびサインイン機能を追加できます。同様に、AWS OrganizationsCloud Directory を使用して関連する AWS アカウントグループの作成をサポートし、複数の階層を十分に活用して幅広いポリシーを適用します。詳しい内容を見る前に、Amazon Cloud Directory のいくつかの重要な概念を簡単に説明します。ディレクトリには名前が付けられ、少なくとも 1 つのスキーマが必要です。ディレクトリは、オブジェクト、オブジェクト間の関係、スキーマ、およびポリシーを保存します。ファセットは、必須の属性および許容される属性を定義してデータをモデル化します。各ファセットは属性名の独立したスコープを提供します。これにより、ディレクトリを共有する複数のアプリケーションは、衝突または混乱を恐れることなく、特定のスキーマを安全かつ独立して拡張できます。スキーマは、1 つ以上のファセットを参照して、ディレクトリに保存されたデータの「シェイプ」を定義します。各ディレクトリは複数のスキーマを持つことができます。スキーマは 3 つのフェーズ (開発、公開済み、適用済み) のいずれかに存在します。開発スキーマは変更でき、公開済みスキーマはイミュータブルです。Amazon Cloud Directory には、人、組織、およびデバイス向けに事前定義のスキーマのコレクションが含まれています。スキーマとファセットの組み合わせにより、初期データモデルおよび対象領域への経時変化に伴う重要な追加が可能になる一方で、既存のアプリケーションは引き続き予期どおり動作します。属性は実際に保存されたデータです。各属性には名前が付けられ、型付けされます。データ型にはブール、バイナリ (blob)、日時、数値、および文字列があります。属性は、必須またはオプション、およびイミュータブルまたは編集可能とすることができます。属性の定義では、保存または更新する前に属性の長さまたはコンテンツ、あるいはその両方を検証するために使用するルールを指定できます。バイナリおよび文字列オブジェクトは、最小および最大の長さに対して長さをチェックできます。ルールは、文字列にはリストから選択された値が必要であるか、または数値が特定の範囲内であるかを示すことができます。オブジェクトはディレクトリに保存され、属性を持ち、スキーマによって定義されます。各オブジェクトは、スキーマの指定により、複数の子と複数の親を持つことができます。複数の親機能を使用して、1 つのディレクトリ内で複数の独立した階層を作成できます (ツリーのフォレストとも呼ばれます)。ポリシーは階層の任意のレベルで指定でき、子オブジェクトによって継承されます。Cloud Directory はポリシーを解釈したり、意味を割り当てたりせず、この操作をアプリケーションに任せます。ポリシーを使用して、アクセス権限、ユーザー権限、デバイス特性などを指定、管理できます。

ディレクトリの作成
ディレクトリを作成しましょう。AWS Directory Service コンソールを開き、最初の [Create directory] ボタンをクリックします。

ディレクトリの名前 (users) を入力し、person スキーマ (偶然 2 つのファセットを持ちます。これについてはすぐに説明します) を選択して、[Next] をクリックします。

事前定義された (AWS) スキーマがディレクトリにコピーされます。これに名前とバージョンを指定し、[Publish] をクリックします。

次に設定を確認し、[Launch] をクリックします。

ディレクトリが作成され、コードを記述してそのディレクトリにオブジェクトを追加できます。

料金と可用性
Cloud Directory は、US East (Northern Virginia)US East (Ohio)US West (Oregon)Europe (Ireland)Asia Pacific (Sydney)、および Asia Pacific (Singapore) リージョンで利用でき、今すぐ使い始めることができます。料金は、保存するデータの量、読み取り数、および書き込み数という 3 つの要素に基づきます (以下の料金は US East (Northern Virginia) のものです)。

  • ストレージ – 0.25 USD / GB / 月
  • 読み取り – 10,000 回の読み取りあたり 0.0040 USD
  • 書き込み – 1,000 回の書き込みあたり 0.0043 USD

進行中
クラウドディレクトリに関しては大きな計画があります。お客様のフィードバックにより優先順位は変更される可能性がありますが、当社はクロスリージョンレプリケーション、AWS Lambda の統合、および AWS CloudFormation を介した新しいディレクトリの作成機能を開発中です。

Jeff;

Amazon Route 53 および AWS Shield を使用した DDoS リスクの軽減

2016 年 10 月後半に、著名な DNS プロバイダーが、複数のサービス妨害攻撃で構成された大規模なサイバー攻撃の標的となりました。数千万の IP アドレスからの大量の DNS 参照で構成された攻撃により、多くのインターネットサイトやサービスが北米および欧州のユーザーに対して利用できなくなりました。プリンター、カメラ、家庭用ネットワークゲートウェイ、さらにはベビーモニターといったさまざまなインターネッツ接続デバイスで構成されたボットネットを使用して、この分散サービス妨害 (DDoS) 攻撃が実行されたと考えられます。これらのデバイスは Mirai マルウェアに感染し、1 秒あたり数百ギガバイトのトラフィックを生成しました。多くの企業ネットワークや教育ネットワークは、このような規模のボリューメトリック攻撃を吸収するだけのキャパシティーを持っていません。この攻撃や、それ以前のその他の攻撃を受けて、さまざまなタイプの DDoS 攻撃に対してより弾力性の高いシステムを構築できるようにするための推奨事項やベストプラクティスについてお客様から当社に問い合わせがありました。簡単な回答としては、スケール、耐障害性、および緩和を組み合わせ (詳細については「AWS Best Practices for DDoS Resiliency」ホワイトペーパーを参照)、Amazon Route 53 および AWS Shield を利用することです (詳細については、「AWS Shield – Protect Your Applications from DDoS Attacks」を参照)。

スケール – Route 53 は数多くの AWS エッジロケーションでホストされ、大量の DNS トラフィックを吸収することができるグローバルな対象領域を作成します。Amazon CloudFrontAWS WAF を含むその他のエッジベースのサービスにもグローバルな対象領域があり、大量のトラフィックを処理することができます。

耐障害性 – 各エッジロケーションには、インターネットへの数多くの接続があります。これにより、多様なパスが可能になり、障害の分離と阻止に役立ちます。また、Route 53 はシャッフルシャーディングエニーキャストストライピングを使って可用性を高めます。シャッフルシャーディングでは、委託セットの各ネームサーバーがエッジロケーションの一意のセットに対応します。この配置によって耐障害性が向上し、AWS のお客様間の重複が最小化されます。委託セットの 1 つのネームサーバーが利用できない場合、クライアントシステムまたはアプリケーションは別のエッジロケーションのネームサーバーを再試行し、レスポンスを受け取ります。エニーキャストストライピングは、最適な場所に DNS リクエストをダイレクトするために使用されます。これは、負荷を分散して DNS レイテンシーを減らす効果があります。

緩和 – AWS Shield Standard は、現在の最も一般的な攻撃の 96% からお客様を保護します。これには、SYN/ACK フラッド、反射攻撃、および HTTP スローリードが含まれます。私の投稿で前に述べたように、この保護は自動的かつ透過的に Elastic Load Balancing、CloudFront ディストリビューション、および Route 53 リソースに無料で適用されます。保護 (決定的パケットフィルタリングと優先順位をベースとしたトラフィック形成を含む) はすべての AWS エッジロケーションにデプロイされ、わずか数秒のオーバーヘッドですべてのトラフィックを検査します。すべては完全に透過的な方法で実行されます。

AWS Shield Advanced には、追加の DDoS 緩和機能、DDoS Response Team への年中無休のアクセス、リアルタイムのメトリクスとレポート、および DDoS コスト保護が含まれます。詳細については、「DDoS Resiliency」ホワイトペーパーを参照し、Route 53 エニーキャストについてご覧ください。

Jeff;

AWS Shield – DDoS攻撃からアプリケーションを保護

オンラインの世界は時として不愉快な場所です!あなたがウェブサイトを公開するや否や、問題を起こしたり、サイトを停止させようとする多くの種類の攻撃の標的にされます。DDoS (分散型サービス妨害) 攻撃は非常に一般的な問題の一つです。攻撃者はウェブ上のあらゆる侵害されたリソースを利用し、活動を特定の標的に集中させます。

DDoS攻撃には一般的に3つの種類があります。

アプリケーション層攻撃 はアプリケーションのリソースを消費するように設計された、整形式かつ悪意のあるリクエスト(HTTP GETやDNSクエリが一般的)からなります。たとえば複数のHTTP接続を開き、数秒または数分かけてレスポンスを読むことで、過剰にメモリが消費され、正当なリクエストが処理されなくなります。

State-Exhaustion 攻撃 はステートフルなプロトコルを悪用し、一接続当たりに多くのリソースを消費させることでファイヤーウォールや負荷分散装置に負荷を与えます。

ボリューム攻撃 は対処しきれないほどの大量なトラフィックを送りつけたり、無防備な被害者に驚くほど大量の低レベル”surprise”応答を送りつける偽クエリを発行(別名:リフレクション攻撃)させて、ネットワークを不通にします。

新サービス – AWS Shield

AWS Shieldは新しいマネージドサービスで、ウェブアプリケーションをDDoS (分散型サービス妨害) 攻撃から保護します。Elastic Load BalancingAmazon CloudFrontAmazon Route 53と連携して動作し、様々なタイプ、形状、サイズの攻撃からお客様を保護します。このサービスには二つのTierがあります。

AWS Shield Standard は追加費用なしで、すべてのAWS顧客が利用できます。 SYN/ACK フラッド、リフレクション攻撃、HTTPスローリードなど、今日最も一般的な攻撃の96%からお客様を守ります。 この保護は、Elastic Load Balancer、CloudFrontディストリビューション、Route 53リソースに自動的かつ透過的に適用されます。

AWS Shield Advanced は、ボリューム攻撃に対する追加のDDoS軽減機能、インテリジェントな攻撃検出、アプリケーションおよびネットワーク層での攻撃に対する軽減を提供します。 攻撃の軽減のカスタマイズ、高度なリアルタイムメトリクスとレポート、DDoS攻撃の影響で請求金額が跳ね上がるのを防ぐDDoSコスト保護のために、私たちのDDoSレスポンスチーム(DRT)に24時間365日アクセスできます。

詳しくは、AWS Shield もしくは Get Started with AWS Shield Advanced をご参照ください。

原文:AWS Shield – Protect your Applications from DDoS Attacks (翻訳:Security Solutions Architect 桐山 隼人)