Category: Security, Identity, & Compliance

2017年5月30日、昨今の IT 技術の飛躍的に進歩に伴い、様々な個人情報の利活用の現状を踏まえ、改正個人情報保護法が全面施行されました。個人情報の取り扱いに関する義務が明確になりましたが、一方でクラウドをご利用する上で配慮すべき点が増え、考慮されているお客様もいらっしゃるかと思います。そのようなお客様の声にお答えするために、お客様が自身のクラウド利用を検討していく際の参考資料として「日本におけるプライバシーに関する考慮事項に照らした AWS の利用」（ホワイトペーパー）を準備し、コンプライアンスのリソースページにて公開しました。本ホワイトペーパーは、今回の改正個人情報保護法に沿った内容となっており、お客様がご自身の IT インフラストラクチャを AWS へ移行する際の主な検討事項となる以下の点について解説しています。   • コンテンツのセキュリティをどのように担保していくのか? • コンテンツはどこに保存されるのか? • コンテンツにアクセスできるのは誰か? • どのような法令がコンテンツに適用され、これらを遵守するには何が必要か?   上記のようなお客様がクラウドのセキュリティやプライバシーについて検討いただく際に、最も重要となるのが「責任共有モデル」についての理解です。AWS はクラウドサービスにおけるインフラストラクチャ自体のセキュリティについて責任を持ちます。一方で、お客様はサービス利用に際して法令を遵守し、併せて当該クラウド環境の上に構築するサービス、オプションの構成やデータ保護のための追加の構成等によりご自身のコンテンツについてのセキュリティを確保するという責任を持つことになります。AWS ではこのようにお客様と AWS の２者でシステム全体の統制やセキュリティを担保していくモデルを「責任共有モデル」と呼んでいます。詳しくは本ホワイトペーパーの「クラウドセキュリティの管理に対する AWS 責任共有の考え方」をご参照ください。   また、AWS のサービスをご利用いただく際に、お客様のコンテンツの所有権と管理権はお客様に保有することになり、AWS にコンテンツの所有権と管理権が移るようなことはありません。したがって、コンテンツの性質やセキュリティ要件に応じたセキュリティの強度レベルを決定できるのはお客様自身となります。お客様が AWS サービスをどのように構成し、アクセス権をどのように付与し、どのリージョンを使用するか等の個別な設定については、お客様の判断と責任の下でコントロールしていただくことになります。（どのような場合に AWS がお客様のコンテンツにアクセスをする可能性があるかにつきましては、「カスタマーコンテンツにアクセスできるのは誰か？」をご参照ください。）   一方、AWS のクラウドサービスのインフラストラクチャーに関するセキュリティを確保するのは AWS の責任です。例えば、AWS はファシリティ、物理セキュリティ、物理インフラ、ネットワークインフラ、仮想インフラの管理につき責任を負います。セキュリティは、AWS における最優先事項です。セキュリティに対する継続的な投資を行い、セキュリティ専門部隊を設置しています。併せて、お客様が安心して AWS のサービスをご利用いただけるよう幅広いセキュリティ機能、ツールを備え、お客様に提供しています。AWS のサービスとインフラストラクチャーは、セキュリティコントロールの設計及び運用についての有効性を証明する、数多くの認定・認証・監査に関連して第三者からの評価を受けており、機密保持契約に基づき AWS Artifact を通じてオンラインにて直接確認いただくことが可能です。（AWS Service Organization Control(SOC) 1、SOC2、PCI DSS7 コンプライアンスレポート等。ISO27001, ISO27017, ISO27018, […]

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、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 & […]

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）

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

【日本語訳】日本時間 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 ハイパーバイザーのメモリを読み取ることもできません。 […]

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 […]

現在利用可能となりました、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をご覧ください。

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 […]

–この記事は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 (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拡張が使われていません。 […]