Category: Security, Identity, & Compliance*


AWS Single Sign-On 紹介

12/7 にリリースされた AWS Single Sign-On (AWS SSO) サービスをご紹介します。このサービスにより、複数の AWS アカウントやビジネスアプリケーションへの SSO アクセスを簡単に集中管理できるようになります。AWS SSO はユーザポータルを提供するため、ユーザは既にある企業内の認証情報を使ってアサインされた全ての AWS アカウントやアプリケーションを確認して、アクセスできます。AWS SSO は AWS Organizations と統合されており、組織内にある複数の AWS アカウントへのアクセスを管理できます。加えて、AWS SSO は Security Assertion Markup Language (SAML) 2.0 をサポートしており、AWS SSO アプリケション設定ウィザートを使って SAML が利用できるアプリケーションへの SSO アクセスにも広げることができます。AWS SSO は Salesforce、BOX、Office 365 など多くのビジネスアプリケーションとの SSO 連携が組み込まれており、簡単に設定が行なえます。

このブログ記事では、以下の 3 つの質問に答えることで AWS SSO を使い始めに役立つよう説明します。:

  1. AWS SSO はどんなメリットを提供するか?
  2. AWS SSO の主要機能は何か?
  3. どうやって使い始めればいいか?

(more…)

すぐに使用できるマネージドルールがAWS WAFで利用可能に

現在利用可能となりました、AWS WAFマネージドルールにより、WebアプリケーションやAPIをインターネットの脅威から簡単に保護することができます。Alert Logic、Fortinet、Imperva、Trend Micro、TrustWaveなど、業界をリードするセキュリティ専門家がAWS Marketplaceで提供する事前設定済みのルールグループから選択します。ルールは新しい脅威が出現すると自動的に更新され、OWASP Top 10リスクの軽減、悪いボットからの防御、最新のCVEに対する仮想パッチの適用などに対応します。その他にもWordPressやDrupalなどのコンテンツ管理システムを含む、アプリケーションプラットフォームを保護するための、特定領域に特化したマネージドルールグループもあります。各ルールグループは、提供元のユニークな専門知識が入った製品で、使った分だけの手頃な価格でご利用頂けます。 AWSのマネージドルールは、セキュリティルールの作成やサーバーの管理などに費やす時間を短縮するのに役立ちます。

AWS WAFのマネージドルールは、長期契約や高価なプロフェッショナルサービス契約なしで利用できます。AWS MarketplaceまたはAWS WAF管理コンソールからAWS WAF用のマネージドルールを購入し、数回クリックするだけで展開できます。

AWS WAFのマネージドルールの詳細については、AWS Marketplaceをご覧ください。

AWS Shield Advancedを使用してAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました

11月22日から、AWS Shield Advancedは、インフラストラクチャレイヤの分散サービス拒否(DDoS)攻撃からAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました。 AWS Elastic IPアドレスに対してAWS Shield Advancedを有効にし、インターネットに接続されたEC2インスタンスまたはNetwork Load Balancerにアタッチすることで利用可能です。 AWS Shield Advancedは、Elastic IPアドレスの背後にあるAWSリソースの種類を自動的に検出し、DDoS攻撃を緩和します。

AWS Shield Advancedは、Amazon VPCネットワークアクセスコントロールリスト(ACLs)をAWSネットワークのエッジにあるAWS Shield上で自動的に実行し、追加の帯域幅とスクラビング容量を利用することで、大量のDDoS攻撃を軽減します。また、AWS DDoS対応チームと協力し、事前に軽減策を設定したり、発生したインシデントに対応したりすることで、AWS Shieldの追加の軽減策をカスタマイズできます。AWS Shield Advancedによって検出されたすべてのインシデントについては、Amazon CloudWatchのメトリックを通じて、ほぼリアルタイムに可視化されます。インシデントの詳細についても、攻撃の地理的な起点や送信元IPアドレスなどが確認いただけます。

Elastic IPアドレスに対応したAWS Shield Advancedは、DDoSコスト保護の適用範囲を拡大します。DDoSコスト保護により、DDoS攻撃の結果として利用リソースが増加した場合に、Elastic Load BalancingAmazon CloudFrontAmazon Route 53、およびEC2インスタンス時間についてサービスクレジットを要求できるようになりました。

EC2インスタンスとNetwork Load Balancer保護の開始

開始方法:

  1. AWS Management Consoleにサインインし、AWS WAFおよびAWS Shieldコンソールに移動します。
  2. 「AWS Shield Advancedを有効にする」を選択、条件をご確認いただき、AWS Shield Advancedを有効化します。
  3. ナビゲーションペインで「Protected resources」に移動します。
  4. 保護するElastic IPアドレスを選択します(これらはEC2インスタンスまたはネットワークロードバランサを指し示します)。

AWS Shield AdvancedがDDoS攻撃を検出した場合、CloudWatchを確認するか、AWS WAFおよびAWS Shieldコンソールの「Incidents」タブを調べることで攻撃の詳細を取得できます。 この新機能とAWS Shield Advancedの詳細については、AWS Shieldのホームページを参照してください。

この投稿に関するご意見やご質問は、(原文)記事の「コメント」セクションにお寄せいただく、またはAWS Shieldフォーラムで新しいスレッドを開始いただくか、AWSサポートにお問い合わせください

– Ritwik

原文:Now You Can Use AWS Shield Advanced to Help Protect Your Amazon EC2 Instances and Network Load Balancers(翻訳:SA安司)

 

日本準拠法に関する AWS カスタマーアグリーメントの変更: AWS Artifact

–この記事はAWS セキュリティ・アシュアランス本部の寄稿です–

2016年12月に AWS Artifact のサービスが開始され監査レポート等コンプライアンスに関する重要な情報を提供してきましたが、2017年11月より同サービスにおいて、日本のお客様に向けて「日本準拠法に関する AWS カスタマーアグリーメント変更契約」の手続きが可能な新機能の提供を開始しました。これにより、AWS Artifact を通じて日本準拠法に関する AWS カスタマーアグリーメント変更契約をリアルタイムに締結または終了することが可能となっています。

日本準拠法に関する AWS カスタマーアグリーメント変更契約とは、現在お客様がご利用中の AWS アカウントに適用されている、 AWS カスタマーアグリーメントの準拠法および管轄裁判所を変更する契約を指します。この契約を有効にすることで、 AWS カスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更することができます。

従来、AWSカスタマーアグリーメントの準拠法および管轄裁判所を変更する際に、その都度、書面で契約を締結して頂く必要がありましたが、AWSアカウントのマネジメントコンソールからお客様ご自身で受諾(有効に)することで、お客様の手間を省略することが可能となっています。

AWSでは今後も日本のお客様の声に耳を傾け、サービスの拡充に努めていきます。

【AWS Artifactの操作方法】

AWS Artifactを使用した日本準拠法に関するAWSカスタマーアグリーメントの変更方法、操作方法については下記のリンクから動画をご参照ください。より詳細なAWS Artifactの情報については以下のartifactのページをご参照ください。

https://aws.amazon.com/jp/artifact/

 

【留意事項】

  •  日本準拠法に関する AWS カスタマーアグリーメントは、請求連絡先アドレスが日本国内にあるアカウントに対してのみ提供されるものです。
  • 複数のアカウントをお持ちのお客様の場合、アカウント毎に有効にして頂く必要があります。
  • 既に個別に書面でカスタマーアグリーメントの準拠法および裁判管轄を変更する契約を取り交わしているお客様については、再度締結いただく必要はございません。

その他の詳細については下記のページをご参照ください。

https://aws.amazon.com/jp/artifact/faq/

 

– AWS セキュリティ・アシュアランス本部

 

 

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。

もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。

TLS? SSL? SNI?

SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。

TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。

SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。

フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。

ALBの証明書スマートセレクション

ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択肢、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。

ALBでSNIを利用する

ここではウェブサイトの例として、VimIsBetterThanEmacs.comVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。

最初に、コンソールから私のロードバランサを選択肢、listenerタブに行き、”view/edit cerfiticates”を選択します。

次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。

これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。

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

知っておくべきこと

  • ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。
  • ACMかIAMにある全ての証明書を利用することができます。
  • 同一ドメイン向けの複数の証明書を1つのsecure listenerに紐付けることができます。ALBはクライアントのサポート範囲を含む複数の因子を元に適切な証明書を選択します。
  • もしクライアントがSNIをサポートしていない時には、ALBは(listener作成時に1つ指定する)デフォルト証明書を使います。
  • 3つの新しいELB API呼び出しが追加されます: AddListenerCertificates, RemoveListenerCertificates, そしてDescribeListenerCertificatesです。
  • (デフォルト証明書を除いて) ロードバランサ毎に最大25個の証明書を紐付け可能です。
  • リリース時点でこれらの新しい機能はAWS CloudFormationでサポートされています。

私の同僚のJon Zobristが作ったウェブサイトでこれらの新しい機能が稼働している例を見ることができます: https://www.exampleloadbalancer.com/.

全体を通して、私は個人的にこの機能を使っていきますし、多くのAWS利用者もこのメリットを受けることができると確信しています。Elastic Load Balancingチームには、これを我々のユーザに届けるためのハードワークをしてくれたことに感謝したいと思います。

Randall

原文: Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI (翻訳: SA岩永)

こんにちは、Amazon Macie: コンテンツを自動的に発見、分類、保護する

Jeffと私が初めてこのサービスを聞いたとき、私たちはMacieという名前の意味が知りたくなりました。もちろん偉大な研究者であるJeffは、Macieという名前を調べ、二つの意味があることを発見しました。フランス語とイギリス英語両方からの語源があり、典型的な少女の名前で、様々な意味を持っていました。Macieの一つめの意味は”武器”を意味する名前です。もう一つの意味は、力強く、さっぱりとした、優しい人の表す名前です。ある意味、これらの定義はふさわしいです。本日、私たちはAmazon Macieという新しいセキュリティサービスの提供開始を喜んで発表します。機械学習によって、AWS上に保存された機密情報の特定し、データ侵害、情報漏えい、Amazon Simple Storage Service (S3)への不正アクセスから保護をします。よって、Amazon Macieが、あなたの保存データを悪意のあるアクセスから保護する、”さっぱりとした”ユーザーインターフェースを備えた”優しい”サービスとして、AWS顧客にとって”力強い””武器”になることを私は想像できるのです。ふー、喋り過ぎました。たった一文でMacieの全てを表現するなんて!やはり、私はみなさんとAmazon Macieの凄さを共有するのに興奮しています。

Amazon Macieは、Amazon S3に保存されているデータを自動的に発見し分類する、機械学習を用いたサービスです。しかし、Macieはそれだけではありません。一度Macieであなたのデータが分類されれば、それらにビジネス価値が割り当てられ、継続的に監視し、アクセスパターンに基づいて疑わしい振る舞いを検知します。Macieの主要機能は以下です。

  • データセキュリティの自動化:データの分析、分類、処理し、過去のパターン、データに対するユーザー認証、データアクセス場所、アクセス時間を把握する
  • データセキュリティと監視:利用ログデータの監視して異常検知したり、CloudWatch EventsやLambdaによってレポートされる問題を自動解決する
  • プロアクティブなデータ保護のためのデータ可視性:保存データの詳細を管理者向けに可視化すると同時に、手動入力いらずで即時保護を提供する
  • データ調査とレポート:管理者向けにレポーティングやアラートを構成可能にする

どのようにAmazon Macieはこれらを実現するのか?

自然言語解析(NLP)の機械学習アルゴリズムを使って、MacieがS3バケットにあるデータの分類を自動化します。加えて、Amazon Macieはデータアクセスパターンを動的に分析する予測分類アルゴリズムも利用し、学習によって疑わしい振る舞いの可能性を知らせてくれます。Macieは個人特定情報(PII)や機密個人情報(SP)を検知するエンジンとしても動作します。MacieはAWS CloudTrailを利用しながら、継続的にS3バケットへのPUTリクエストのCloudTrailイベントを確認し、自動的に新しいオブジェクトの分類をほぼリアルタイムで行います。

MacieがAWSクラウド上のセキュリティやデータ保護にとって強力な道具であるだけでなく、ガバナンスやコンプライアンス要件、監査基準などにおいてもあなたを助けます。多くの人は既に、現時点でEUの最も厳しいプライバシー規制である、2018年5月25日に施行される一般データ保護規則(GDPR)を知っています。Amazon Macieは個人特定情報(PII)を認識し、ダッシュボードとアラート機能を提供することで、顧客にデータの暗号化や仮名化によるGDPRへの準拠を可能にします。Lambdaクエリと共に利用すると、MacieはGDPRの懸念に対応する協力な道具になります。

Amazon Macieサービスツアー

それではAmazon Macieの詳細を見るためのツアーを開始しましょう。

まず最初に、私はMacieのコンソールにログインし、Macieのセットアップ処理を始めます。Get Startedボタンを押すことで私のデータの分類と保護を開始することができます。

下画面の通り、Amazon Macieサービスを有効化するには、このサービス用の適切なIAMロールを作成しなければなりません。また、私のアカウントでAWS CloudTrailを有効化する必要があるでしょう。

私はこれらのロールを作成し、私のアカウントでAWS CloudTrailサービスを有効化しました。Macieをより簡単にセットアップするために、Macieユーザーガイドから提供されているCloudFormationのサンプルテンプレートを利用することもできます。それは、必要なIAMロールとポリシーを作成するので、あとやるべきことはCoudTrailドキュメントに記載されている通りに証跡を設定するだけです。

もしあなたが複数のAWSアカウントをもっている場合は、Macieサービスを有効化したアカウントがマスターアカウントになることに注意してください。他のアカウントもMacieサービスと連携できますが、それらはメンバーアカウントということになります。メンバーアカウントのユーザーは、Macieコンソールにアクセスするために、マスターアカウントへフェデレートアクセスするためのIAMロールを使う必要があるでしょう。

さあ、IAMロールが作られ、CloudTrailが有効化されたら、Enable MacieボタンをクリックしてMacieによるデータ監視と保護を開始しましよう。

あるアカウントで一度Macieサービスが開始すると、サービス画面が表示され、そのアカウントにおける既存アラートが表示されます。今回、私はサービスを開始した直後なので、アラートはまだ存在していません。

Macieサービスのツアーで、ここから私のS3バケットとMacieを連携していきましょう。ただし、Macieが監視を開始するだけであれば、あなたはS3バケットを指定する必要はありませんでした。なぜならサービスは既に情報の分析や処理のためのAWS CloudTrail管理APIを使用しているからです。このMacieツアーでは、私は特定のバケットにおけるCloudTrailのいくつかのオブジェクトレベルAPIイベントを監視しようと思います。

S3と連携するために、MacieコンソールのIntegrationsタブに移動します。Integrationsタブでは、二つの選択肢:AccountsServicesがあります。AccontsオプションはメンバーアカウントがMacieと連携するために使用され、あなたのデータ保存ポリシーを設定します。特定のS3バケットとMacieを連携したい時は、ServicesタブからServicesオプションをクリックします。

MacieとS3サービスを連携させると、証跡とS3バケットが作成され、S3データイベントに関するログが保存されます。始めるには、Select an accountドロップダウンを使いアカウントを選択します。アカウントが選択されると、連携可能なサービスが表示されます。Addボタンをクリックして、Amazon S3サービスを選択します。

さて、Macieに分析させたいバケットを選択したので、Review and Saveボタンを押して確認画面に行き、オブジェクトレベルロギングを行うことを確認してからSaveボタンをクリックします。

次に、このMacieツアーでは、どのようにMacieのデータ分類をカスタマイズするか見ていきましょう。

前述の通り、Macieは自動的にあなたのデータを監視し、分類します。Macieがあなたのデータを特定すると、ファイルとコンテントタイプでそのデータオブジェクトを分類します。また、Macieはサポートベクターマシン(SVM)も使用し、ファイルのメタデータに加えてS3オブジェクト内のコンテンツも分類します。深層学習/機械学習の研究分野において、サポートベクターマシンは教師あり学習モデルであり、データの分類や回帰分析のための学習アルゴリズムを持っています。Macieは、たくさんのコンテンツタイプのデータによってSVMを学習させ、あなたが書いたかもしれないソースコードが含まれていようとも、データコンテンツの正確な検知に最適化されます。

Macieはデータオブジェクトやファイルに対して一つのコンテンツタイプを割り当てますが、あなたはコンテンツタイプやファイル拡張子を有効化や無効化することもできます。それにより、それらオブジェクトをMacieサービスの分類対象に含めたり除外することができます。Macieがデータを分類したら、1から10までのリスクレベルがそのオブジェクトに割り当てられます。10が最もリスクが高く、1が最もリスクレベルが低いです。

Macieのデータ分類をカスタマイズするためには、Settingsタブに行きます。Macieの分類設定にて、有効化や無効化が可能な選択肢が表示されます。

このMacieツアーでの例として、File extensionを選んでみましょう。Macieが追跡し、分類に使用するファイル拡張子のリストが表示されます。

テストのために、Androidアプリケーションのインストールファイルであるapkファイル拡張子を編集し、ドロップダウンリストからNo – disabledを選択し、Saveボタンをクリックして、このファイルの監視を無効にします。もちろん、後でこの設定は戻します。Android開発用バイナリファイルも含めて全てのデータファイルの安全を維持したいからです。

最後に、Macieによるデータ分類に関して述べると、このサービスはあなたのデータオブジェクトがどのように分類されたかを可視化します。あなたが保存したデータ資産を、コンプライアンスにとって、個人情報にとって、ビジネスにとって、どれほど重要な情報が保存されているかの点で浮き彫りにします。

さて、今までMacieが分類し監視するデータの探検をしてきました。このサービスのツアー終着駅は、Macieダッシュボードです。

Macieダッシュボードは、Macieによるデータ監視と分類によって集められた全てのデータや活動の完全な絵を提供します。ダッシュボードはカテゴリー毎のメトリクスとビューによって、データを色々な視点から表示することができます。このダッシュボード画面の中で、メトリクス画面からResearchタブへ直接行き、メトリクスに基づいたクエリを作成し実行することも可能です。これらのクエリは、起こりうるセキュリティの課題や問題を通知するためのカスタマイズされたアラートに使用できます。ここでは、ResearchタブやAlertsタブのツアーは行いませんが、Macieユーザーガイドには、これらの機能に関するより多くの情報があります。

ダッシュボードに話を戻すと、非常にたくさんの情報源がMacieダッシュボードにはあるため、このツアーで全てのビュー、メトリクス、機能をご紹介することはしません。ここでは、ダッシュボード機能の概要をお伝えいたします。

ダッシュボードメトリクス(Dashboard Metrics) – 次のカテゴリーで監視したデータ:

  • ハイリスクS3オブジェクト(High-risk S3 objects):リスクレベル8から10のデータオブジェクト
  • 全イベント発生回数(Total event occurrences):Macieが有効化されてからの全てのイベント発生回数
  • 全ユーザーセッション(Total user sessions):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サービスのツアーを終了します。Amazon Macieはセンセーショナルな新サービスで、機械学習と深層学習の力を使って、Amazon S3に保存されているデータを特定し保護します。自然言語解析(NLP)によって、データ分類を自動化するので、あなたはAmazon Macieを有効化するだけで、精度の高い分類と即時保護を簡単に始めることができます。インタラクティブなダッシュボードは、あなたの情報がどこで何が誰によっていつアクセスされたかを示すので、あなたの環境における大量のデータ、データアクセス、API呼び出しを分析できます。製品ページAmazon Macieユーザーガイドを参照し、Amazon Macieについてもっと知りましょう!

Tara

(翻訳はセキュリティSA桐山隼人が担当しました。原文はこちら

新機能- CloudTrailを全てのお客様に

Amazon Web Servicesをご利用の皆様に大変喜ばしいお知らせがあります。このお知らせが出来るまで辛抱強く待っていましたが、それも終わりです。

このたびAWS CloudTrailは、全てのお客様に対してあらかじめ有効にされるようになりました。

これにより、何も設定することなく過去7日間のAWSアカウント活動の可視性が提供されます。この新しい、常時有効となる機能には閲覧、検索、後述のCloudTrail Event Historyを通してのダウンロード機能が実装されています。

AWS CloudTrailの有用性をまだ得られてないお客様のために説明させてください。操作上のトラブルシューティングとレビュー、コンプライアンス、監査、セキュリティのための重要なサービスが、全てのお客様に対して提供されていることに興奮を覚えます。

AWS CloudTrailは、サポートされているAWSサービスに対するアカウント活動とイベントを記録します。

AWS CloudTrailは、あなたのAWSアカウントにおいてサポートされたAWSサービスのアカウント活動とイベントを捕捉し、Amazon Simple Storage Service(S3)、CloudWatch logsとCloudWatch Eventsにイベント・ログファイルを送ります。CloudTrailであなたはTrailを一般的につくれますし、その設定がアカウント活動とイベントの補足を可能にします。CloudTrailはまた、AWSアカウントで起こっているAPI活動に可視性を提供することによって、操作上のセキュリティ問題を分析することを可能にさせます。CloudTrailはマルチリージョン構成をサポートします。またCloudWatchとインテグレーションさせると、あなたはモニターしたいイベントのきっかけをつくることができたり、AWS Lambdaにアクティビティの記録を送るためのsubscriptionを生成するこができます。AWSコマンドラインインターフェース(CLI)、AWS Management Console、AWS SDKから、またAWSアカウントの他のAWSサービスからの呼び出しのデータの検索可能な履歴を得られることを、CloudTrailサービスを利用することは意味します。

AWS CloudTrailの主要な機能

  • Always On: 設定をする必要がなくあらかじめ全てのAWSアカウントで有効化され、全てのアカウント活動履歴の記録
  • Event History: 閲覧、検索、直近のAWSアカウント活動履歴のダウンロード
  • Management Level Events: 詳細な管理活動情報の取得、例えば、EC2例またはS3バケツの作成、削除と修正
  • Data Level Events: Amazon S3オブジェクトにおける全てのAPIアクションとAPIアクションの詳細な情報の記録
  • Log File Integrity Validation: S3バケットに格納したログファイルの完全性の検査
  • Log File Encryption: あらかじめ、S3のサーバサイド暗号化機能を用いたS3バケットによる全てのログファイルの暗号化。オプションとしてAWS Key Management Service (AWS KMS)によるログファイルの暗号化
  • Multi-region Configuration: マルチリージョンからのログファイルの送信設定

AWS CloudTrailのさらなる機能をお知りになりたい場合は、製品詳細ページに記載があります。

私の同僚であるランダル・ハントが私に思い出させてくれました。つまり、お客様の課題の解決を援助するとき、CloudTrailは重要であるということです。ほとんどのAWSの人間、例えばテクニカル・エバンジェリスト・チームに所属する我々またはソリューションアーキテクトチームに所属する人間が言うのは、何が起きているのかという詳細を調べることができるようにCloudTrailを有効化する、ということです。ですのでこのリリースで、AWSコンソールまたはAWS CLI/APIを用いてすべてのお客様がアカウント活動を見ることができる(検索機能や、全てのサポートされたAWSサービスの活動の7日間のアカウント活動履歴をダウンロードする能力を含む)ことは、驚きに値しません。

CloudTrailはあらかじめ有効化されており、すべてのお客様は、現在CloudTrailにてログを取得することができ、またEvent Historyを閲覧することが可能です。この画面はイベントを7日分見ることが出来るだけでなく、詳細な情報を見ることも可能です。

もちろんですが、直接CloudTrailログファイルにアクセスするか、監査のためにログをアーカイブしたいならば、さらにTrailを追加でき、ログファイルの送出のためにS3バケットを指定することができます。また、Trailの生成はイベントをCloudWatch LogsとCloudWatch Eventsに届けることができ、それは非常に簡単なプロセスです。

CloudTrailコンソールにログインした後に、あなたは単に「Trailの生成」ボタンををクリックするだけです。

それから、あなたはTrail名のテキストボックスにTrail名を入れ、構成をすべてのリージョンに適用するか、現在選択のリージョンにだけ適用するかをラジオボタンで選びます。

Management Event画面で、CloudTrailにどの活動を追って欲しいかについて、Read/Writeイベント・ラジオボタン・オプションを選びます。このケースでは「全て」を選びます。

次のステップは私ケースのためですが、S3オブジェクト・レベル活動を追ういたいためにS3バケツを選択します。これはオプションのステップとなります。デフォルトでは、TrailがData Eventsを記録しない点に注意してください。よって、S3オブジェクトイベント活動を追跡したい場合は、Data Eventセクションで指定するBacketのData Eventsを追跡するためにTrailを構成することができます。ここでは、私はaws-blog-tew-posts バケットを選んで、すべてのRead/Write活動を追うために、デフォルトのままとします。

CloudTrailログを格納するためのTrail設定での最終的なステップは、コンソールのStorage LocationセクションでS3 Backetを選ぶことです。Backetは新規作成もできますし、既存のBacketを選択することも可能です。ここでは、テキストボックスにaws-blog-tew-postsのBacket名を入力し新規Backet生成を選択します。また、すぐにログを見つけられるようにしたいので、Storage LocationのAdvancedセクションを開き接頭辞を加えます。Backetに格納されているログに検索条件を加えたいとき、これは最も役に立ちます。ここでは「tew-2017」という接頭辞を加えています。そのほかのAdvancedセクションの選択肢、ログファイル暗号化、イベントログファイル検査、SNS通知送信はデフォルトのままにします。

以上です。これで、Createボタンを押すだけでTrailの生成に成功しました。

 

準備は出来ていますか?

サービス製品ページCloudTrailドキュメンテーションAWS CloudTrailFAQをご覧いただけくことでAWS CloudTrailについてより多くを学ぶことができます。Trail構成の有無にかかわらず、いま一度CloudTrailサービス・コンソールに進んで見ていただき、CloudTrailイベントを捜してみてください。

全てのお客様のためのこのCloudTrailの新しい発表を楽しんでいただけましたらと思います。そうすることでこの素晴らしいサービスのメリットを享受いただけるかと思います。

Tara

翻訳は、PartnerSA市崎が担当しました。原文はこちらです。

AWS CloudHSM アップデート – 重要データや規制に対応することが可能で、コスト効果の高いクラウド型のハードウェアベース キーマネージメント

AWSのお客様は、AWS上で驚くほど多様なミッションクリティカルなワークロードを実行しており、その多くは機密データを処理して保管しています。 「セキュリティプロセスの概要」のホワイトペーパーで詳しく説明しているように、AWSのお客様は、データを暗号化して保護するための方法について、複数のオプションから選択が可能です。 たとえば、Amazon Relational Database Service(RDS)は、サポートされているデータベースエンジン(MySQL、SQL Server、Oracle、MariaDB、PostgreSQL、およびAurora)ごとにオプションがあり、転送中のデータの暗号化もサポートしています。

多くのお客様がAWS Key Management Service(KMS)を使用してキーを集中管理したり、AWS CloudHSMが提供するハードウェアベースの鍵管理、暗号化、復号を利用することで、重要データと規制に対応したワークロードはコンプライアンスの要求に応えることができています。(ハードウェアセキュリティモジュール(HSM)について、詳しくは、 AWS CloudHSM – Secure Key Storage and Cryptographic Operationsを参照してください)。

 

主要なCloudHSMアップデート

今日、私たちが第1世代の製品から学んだことを踏まえて、我々はCloudHSMを大幅にアップデートしました。専門的な運用ノウハウの必要性を軽減し、ハードウェアベースのキー管理の利点をより多くのユーザーに提供できるように、改良しました。改善の要約を以下に示します。

従量課金モデル – CloudHSMは、シンプルで費用対効果の高い、初期費用なしの従量課金モデルで提供します。

フルマネージド – CloudHSMはスケーラブルな管理サービスになりました。プロビジョニング、パッチ適用、高可用性、およびバックアップはすべて組み込まれています。スケジュールされたバックアップは、(HSMハードウェアだけが知っている鍵を使用して)ハードウェアからHSMの暗号化イメージを抽出し、AWS内の同一のHSMハードウェアにのみリストアできます。耐久性のために、これらのバックアップはAmazon Simple Storage Service(S3)に保存され、AWS KMSマスターキーを使用してサーバーサイドのS3暗号化を使用して再度暗号化されたセキュリティ層が追加されます。

オープンかつ互換性を考慮 – CloudHSMはオープンで標準に準拠しており、PKCS#11Java Cryptography Extension(JCE)、および、Microsoft CryptoNG(CNG)など、複数のAPI、プログラミング言語、および暗号化拡張機能をサポートしています。 CloudHSMのオープン性により、キーを(暗号化された形式で)1つのCloudHSMから別のCloudHSMに移動するプロセスをより詳細かつ簡単に制御し、他の市販のHSMとの間で移行することができます。

より安全に – CloudHSM Classic(オリジナルモデル)は、FIPS 140-2レベル2に準拠した鍵の生成と使用をサポートしています。我々は、HSMにアクセスまたは変更するための物理的な試行を検出して対応するように設計されたセキュリティー・メカニズムを備え、FIPS 140-2レベル3を段階的にサポートしています。バーチャルプライベートクラウド(VPC)内に改ざん防止を備えたHSMに対して、排他的なシングルテナントアクセスとしており、お客様のキーは保護されます。 CloudHSMは、重要な管理機能と鍵管理機能のためのクォーラム認証をサポートします。この機能を使用すると、機能にアクセスできるN個の可能なIDのリストを定義され、少なくともM人以上がアクションを承認する必要があります。また、提供するトークンを使用したマルチファクタ認証もサポートしています。

AWS-Native – アップデートされたCloudHSMはAWSに統合されており、他のツールやサービスとうまく連携します。 AWS管理コンソール、AWSコマンドラインインターフェイス(CLI)、またはAPI呼び出しを使用して、HSMのクラスタを作成および管理できます。

 

使ってみましょう

1〜32のHSMで構成されたCloudHSMクラスターを作成できます。それぞれのクラスターは、特定のAWSリージョンの別々のアベイラビリティゾーンにあります。 AZをまたいでHSMを展開することで、高可用性(組み込みロードバランシングを含む)を実現できます。また、より多くのHSMを追加すると、スループットの向上が得られます。 クラスタ内のHSMは同期して維持されます。クラスタ内の1つのHSMでタスクまたは操作を実行すると、自動的に他のHSMが更新されます。 クラスタ内の各HSMには、独自のElastic Network Interface(ENI)を持ちます。

HSMとの連携は、AWS CloudHSMクライアントを介して行われます。 これはEC2インスタンス上で実行され、証明書ベースの相互認証を使用してHSMへのセキュア(TLS)接続を作成します。

ハードウェアレベルでは、各HSMに暗号操作とキーストレージのハードウェア強制分離が含まれています。 各お客様のHSMは、専用のプロセッサコアで動作します。

 

クラスタの設定:
CloudHSM Consoleを使ってクラスタを設定しましょう。

Create clusterをクリックして、希望のVPCとその中のサブネットを選択します(必要に応じて新しいVPCやサブネットを作成することもできます)。

私は自分の設定を確認し、Createをクリックします:

数分後、クラスタが表示されますが、まだ、初期化されていません。

初期化とは、証明書署名要求(Cluster CSR)を取得することだけです。

プライベートキーを作成し、それを使用してリクエストに署名します(これらのコマンドはInitialize Clusterドキュメントからコピーされましたが、出力は省略されています)。IDはクラスタを識別します。

 

$ openssl genrsa -out CustomerRoot.key 2048
$ openssl req -new -x509 -days 365 -key CustomerRoot.key -out CustomerRoot.crt
$ openssl x509 -req -days 365 -in ID_ClusterCsr.csr   \
                              -CA CustomerRoot.crt    \
                              -CAkey CustomerRoot.key \
                              -CAcreateserial         \
                              -out ID_CustomerHsmCertificate.crt

 

次のステップでは、コンソールまたはCLIを使用して署名付き証明書をクラスタに適用します。 これが完了したら、Crypt Officer(CO)とも呼ばれるHSMの管理ユーザーのパスワードを変更して、クラスタをアクティブにすることができます。

クラスタを作成、初期化し、アクティブ化されたら、それを使ってデータを保護することができます。アプリケーションは、AWS CloudHSM SDKのAPIを使用して、キーの管理、オブジェクトの暗号化と復号化などを行うことができます。 SDKはCloudHSMクライアントへのアクセスを提供します(アプリケーションと同じインスタンスで実行します)。 クライアントは、暗号化された接続でクラスタに接続します。

 

今日から利用可能です。

新しいHSMは、米国東部(北部バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、およびEU(アイルランド)リージョンで現在利用可能であり、それ以外にも展開予定があります。 価格は1時間のHSMあたりで1.45ドルからです。

Jeff;

(翻訳はSA瀧澤与一が担当しました。原文はこちら

 

 

AWS WAF 用のレートベースのルールでウェブサイトとサービスを保護

AWS WAF (ウェブアプリケーションファイアウォール) は、悪質または不正なリクエストに関与する様々なタイプのアプリケーションレイヤー攻撃からアプリケーションを保護するために利用できます。このサービスについて説明したブログ (「新しい AWS WAF について (New – AWS WAF)」でもお見せしましたが、クロスサイトスクリプティング、IP アドレス、SQL インジェクション、サイズ、コンテンツ制約に見合うルールを定義できます。

受信リクエストがルールと一致すると、アクションが呼び出されます。アクションは許可やブロックを実行したり、単にマッチ数をカウントすることができます。既存のルールモデルはパワフルかつ様々な種類の攻撃を検出し対応することができます。ただし、特定の IP アドレスから送られた有効なリクエストが大量に送信されただけのケースでは、攻撃として対応することはできません。こうしたリクエストはウェブレイヤーの DDoS 攻撃や総当たりのログインの試行、もしくはパートナー統合で不具合があった場合の可能性があります。

新しいレートベースのルール
本日、WAF にレートベースのルールを追加しました。これにより、ブラックリストへの IP アドレスの追加または削除を管理できるようになり、例外や特別なケースに対応できる柔軟性も提供します。IP アドレスをブラックリストに追加 – 設定済みのしきい値を超える速度でリクエスト数を送信した IP アドレスをブラックリストに追加することができます。IP Address のトラッキング– どの IP アドレスがブラックリストに追加されているか見ることができます。IP Address の削除 – ブラックリストに追加された IP アドレスは、設定済みのしきい値を超える速度でリクエストを送信しないようになれば自動的にリストから削除されます。IP Address の例外 – 特定の IP アドレスをブラックリストの対象外として設定することができます。その場合はレートベースのルール内にある IP アドレスのホワイトリストを使用してください。たとえば、自分のサイトに信頼できるパートナーが高速でアクセスできるように許可したい場合もあるでしょう。モニタリングおよびアラーム発行 – 各ルールに発行した CloudWatch メトリクスでモニタリングしたりアラーム発行をすることができます。新しいレートベースのルールと WAF の条件を組み合わせて高度なレート制限戦略を取り入れることもできます。たとえば、レートベースのルールやログインページと一致する WAF 条件を使用できます。そうすることで、ログインページで適度なしきい値を適用できます (パスワードのブルートフォース攻撃を防ぐため)。そして、マーケティングやシステムステータスのページにより高いしきい値を設定することが可能になります。しきい値は 5 分間で 1 つの IP アドレスによる受信リクエスト数により定義されます。このしきい値を超えると、その IP アドレスからの追加リクエストはリクエストの速度がしきい値以下になるまでブロックされます。

レートベースのルールを使用
サイトの/ログインを保護するレートベースのルールを定義する方法を説明します。そのページの URI で希望のストリングと一致する WAF 条件を定義することから始めます。

次にこの条件を使用してレートベースのルールを定義します (レート制約は 5 分間隔で行われるリクエストをもとにしますが、制限を超え次第ブラックリストに追加されます)。

条件とルールの設定が完了したら、Web ACL (ProtectLoginACL) を作成し、すべて一緒に AWS リソースにアタッチさせます (この場合は CloudFront ディストリビューション)。

次にルール (ProtectLogin) を Web ACL にアタッチします。

これでリソースがルールと Web ACL に合致した状態で保護されるようになりました。関連の CloudWatch メトリクス (この場合は ProtectLoginProtectLoginACL) をモニタリングできます。CloudWatch アラームを作成し、保護用のしきい値を超えたら Lambda 関数の開始に使うこともできます。コードは寄与度が大きい IP アドレスを調べ、複雑なビジネス主導の決定を行ったり、信頼できるパートナーや特別な支払いプランを使用しているユーザーに普通以上の許可を与えられるよう、ホワイトリストのルールに追加することもできます。

今すぐ使用可能
この新しいレートベースのルールは今すぐご利用いただけます。レートベースのルール料金は通常ルールと同様です。詳しくは「WAF 料金 (WAF Pricing)」ページをご覧ください。

Jeff;

Cloud Directory の更新 – Typed Links のサポート

今年始めに公開したブログ「Cloud Directory – 階層データの AWS クラウドネイティブディレクトリ (Cloud Directory, our cloud-native directory for hierarchical data)」では、厳密に型指定された入力の階層データを大量保存できるように設計された方法について説明しました。Cloud Directory は何百万というオブジェクトを保存するようにスケールできるので、様々なクラウドアプリケーションやモバイルアプリケーションに最適です。最初のブログ投稿では、どのようにして各ディレクトリに 1 つ以上のスキーマがあるか、そしてそれにより 1 つまたはそれ以上のファセットがあるかについて説明しました。各ファセットは、オブジェクトの必須の属性および許容される属性の一連を定義します。

Typed Links の概要
本日より、Typed Links のサポートを追加することで Cloud Directory モデルの表記枠を拡大しました。次のリンクを使用して複数の階層に渡りオブジェクトとオブジェクトの関係を作成できます。ディレクトリにある複数のタイプのリンクをそれぞれ定義することができます (各リンクの種類はディレクトリと関連付けているスキーマ 1 つの個別ファセットです)。タイプの他に、各リンクには一連の属性を与えることができます。Typed Links は、他のオブジェクトと関係する既存のオブジェクトを不注意に削除しないようにすることで、参照データの整合性を維持する上で役立ちます。たとえばロケーション、ファクトリー、フロア番号、ルーム、マシン、センサーなどのディレクトリがあるとします。こうした情報はそれぞれ階層内で豊富なメタデータ情報を含む Cloud Directory のディメンションとして表示することが可能です。Typed Links を定義し使用することで、様々な方法でオブジェクトを連携させたり、メンテナンス要件に繋がる Typed Links の作成、サービス記録、保証、安全情報などをリンクの属性を使用してソースオブジェクトと対象オブジェクト間の関係の追加情報を保存できます。そしてリンクタイプや属性の値をベースにクエリを実行することができます。たとえば、過去 45 日以内に消去されていないすべてのセンサーや、保証期間が過ぎたモーターをすべて探すことができます。指定されたフロアにあるすべてのセンサーを探したり、指定されたタイプのセンサーがあるフロアすべてを探すことができます。

Typed Links を使用する
Typed Links を使用するには、1 つ以上の Typed Link ファセットをスキーマに追加します。追加するには CreateTypedLinkFacet関数を呼び出します。次に AttachTypedLink を呼び出し、ソースオブジェクトと対象オブジェクト、Typed Link ファセット、そのリンクの属性を受け渡します。その他の便利な機能として GetTypedLinkFacetInformationListIncomingTypedLinks、および ListOutgoingTypedLinks があります。詳細や機能一覧を確認するには「Cloud Directory API リファレンス (Cloud Directory API Reference)」をご覧ください。オブジェクトと同様に、属性ルールを使用して属性値を制御できます。文字列の長さやバイト配列を制御したり、特定の一連の値への文字列を制限、特定範囲の数字に上限を指定することもできます。私の同僚が Typed Links の使用法を表したいくつかのサンプルコードを共有してくれました。ARN とファセット名はこちらです。

String appliedSchemaArn   = "arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo/schema/demo_organization/1.0";
String directoryArn       = "arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo";
String typedLinkFacetName = "FloorSensorAssociation";

最初のスニペットが Typed Link ファセットを作成します。 FloorSensorAssociation LABEL=[NAME] によって sensor_typemaintenance_date 属性、といった順番になります (属性名と値はリンクのアイデンティティの一部なので順番を無視することはできません)。

client.createTypedLinkFacet(new CreateTypedLinkFacetRequest()
                                .withSchemaArn(appliedSchemaArn)
                                .withFacet(
                                      new TypedLinkFacet()
                                          .withName(typedLinkFacetName)
                                          .withAttributes(toTypedLinkAttributeDefinition("sensor_type"),
                                                          toTypedLinkAttributeDefinition("maintenance_date"))
                                          .withIdentityAttributeOrder("sensor_type", "maintenance_date")));

private TypedLinkAttributeDefinition toTypedLinkAttributeDefinition(String attributeName) {
 return new TypedLinkAttributeDefinition().withName(attributeName)
 .withRequiredBehavior(RequiredAttributeBehavior.REQUIRED_ALWAYS)
 .withType(FacetAttributeType.STRING);
}

次のスニペットは 2 つのオブジェクト間にリンクを作成します (sourceFloortargetSensor)、 sensor_type watermaintenance_date 2017-05-24:

AttachTypedLinkResult result = 
    client.attachTypedLink(new AttachTypedLinkRequest()
                               .withDirectoryArn(directoryArn)
                               .withTypedLinkFacet(
                                   toTypedLinkFacet(appliedSchemaArn, typedLinkFacetName))
                                   .withAttributes(
                                        attributeNameAndStringValue("sensor_type", "water"),
                                        attributeNameAndStringValue("maintenance_date", "2017-05-24"))
                                   .withSourceObjectReference(sourceFloor)
                                   .withTargetObjectReference(targetSensor));

private TypedLinkSchemaAndFacetName toTypedLinkFacet(String appliedSchemaArn, String typedLinkFacetName) {
   return new TypedLinkSchemaAndFacetName()
              .withTypedLinkName(typedLinkFacetName)
              .withSchemaArn(appliedSchemaArn);
}

最後のスニペットは sensor_type watermaintenance_date2017-05-20 から 2017-05-24 の範囲で受信した Typed Link すべてを列挙します。

client.listIncomingTypedLinks(
    new ListIncomingTypedLinksRequest()
        .withFilterTypedLink(toTypedLinkFacet(appliedSchemaArn, typedLinkFacetName))
        .withDirectoryArn(directoryArn)
        .withObjectReference(targetSensor)
        .withMaxResults(10)
        .withFilterAttributeRanges(attributeRange("sensor_type", exactRange("water")),
                                   attributeRange("maintenance_date", 
                                                  range("2017-05-20", "2017-05-24"))));

private TypedLinkAttributeRange attributeRange(String attributeName, TypedAttributeValueRange range) {
   return new TypedLinkAttributeRange().withAttributeName(attributeName).withRange(range);
}

private TypedAttributeValueRange exactRange(String value) {
   return range(value, value);
}

詳細については「オブジェクトとリンク (Objects and Links)」を「Cloud Directory 管理ガイド (Cloud Directory Administration Guide)」でご覧ください。

今すぐ利用可能
Typed Links は今すぐご利用いただけます。

Jeff;