Amazon Web Services ブログ

Category: Security, Identity, & Compliance

プロセッサの投機的実行 – オペレーティングシステムの更新

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin(セキュリティ情報)AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化(PV)インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離(信頼できないデータ処理やコードの実行、ユーザのホスト)にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点(およびインスタンスアップグレードパスのドキュメント)の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]

Read More

AWS データセンターのセキュアな設計について

AWS は AWS のデータセンターのデジタルなツアーを公開しました。AWS が世界中で運用しているデータセンターをいかにセキュアに保護しているのか初めてお客様にご紹介するものです。このデジタルなツアー内のビデオ、写真および情報は、データセンターの設計、グローバルの統制および AWS のカルチャーがセキュリティの本質であることを解説しています。 このツアーにご参加いただくことで、AWS データセンターのセキュリティストラテジーが、お客様の情報を保護するためにスケーラブルな統制と複数の防御レイヤーによって成り立っていることを理解いただけます。例えば、AWS は潜在的な洪水や地震活動のリスクを慎重に統制しています。 AWS は境界防御レイヤー、保安要員、侵入検知システムおよびその他の電子システムを用いてデータセンターへのアクセスを制限しています。AWS はシステムのバックアップを実施し、定期的に装置やプロセスのテストを行い、継続的にAWSの従業員にトレーニングを行うことで予測不能な事態に備えています。 データセンターのセキュリティを検証するために、年間を通して、外部の監査人が2,600以上もの基準や要求事項に沿ったテストを行っています。そのような独立したテストが、セキュリティ基準が継続的に満たされている、もしくは基準を上回っている事を証明するために役立っていることになります。その結果、AWS は世界中の最も厳しい基準を有する監査機関からお客様のデータ保護に関して信頼を得ています。 データセンターのセキュアな設計の詳細についてはこちらのツアーにご参加ください。 – Chad Woolf, AWS Security Assurance (翻訳:AWS セキュリティ・アシュアランス本部 戸内加奈。原文はTake a Digital Tour of an AWS Data Center to See How AWS Secures Data Centers Around The World)

Read More

AWS FinTech リファレンス・アーキテクチャー日本版の公開について

アマゾン ウェブ サービス(以下 AWS )は、日本の金融機関の皆様が参照される FISCのガイドライン や PCI DSS, ISO27001, ISO27017 などの様々な統制やセキュリティ基準への対応をしてきました。現在ではグローバルに世界各国の金融機関やFinTech のお客様にAWS のサービスをご活用いただいております。この度そうした知見や実績を活かし、日本の金融機関やFinTechのお客様が主に参照される各種のガイドラインの主要な要求事項と技術的検討が必要な項目を網羅的に確認し、「AWS FinTech リファレンス・アーキテクチャー 日本版」を作成し、本日AWSコンプライアンスWEBサイトの日本のFinTech向けのページにて公開しました。お客様は、このアーキテクチャーを活用することにより、 AWS 上に FinTech サービスの環境の構築を迅速に実現する、あるいは、既存環境に関連したセキュリティや統制についての確認を行うことが可能となります。 今回の取り組みは「AWS FinTech リファレンス・アーキテクチャー日本版のホワイトペーパー」、「AWS FinTech リファレンス・ガイド 日本版」、「AWS FinTech リファレンス・テンプレート 日本版」の3つの要素で構成されています。

Read More

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More

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 を使い始めに役立つよう説明します。: AWS SSO はどんなメリットを提供するか? AWS […]

Read 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をご覧ください。

Read More

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 Balancing、Amazon CloudFront、Amazon Route 53、およびEC2インスタンス時間についてサービスクレジットを要求できるようになりました。 EC2インスタンスとNetwork Load Balancer保護の開始 開始方法: AWS Management Consoleにサインインし、AWS WAFおよびAWS Shieldコンソールに移動します。 「AWS Shield Advancedを有効にする」を選択、条件をご確認いただき、AWS Shield Advancedを有効化します。 ナビゲーションペインで「Protected resources」に移動します。 保護するElastic IPアドレスを選択します(これらはEC2インスタンスまたはネットワークロードバランサを指し示します)。 AWS Shield […]

Read More

日本準拠法に関する 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 セキュリティ・アシュアランス本部    

Read More

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.comとVimIsTheBest.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拡張が使われていません。 […]

Read More

こんにちは、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タブでは、二つの選択肢:AccountsとServicesがあります。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 […]

Read More