Amazon Web Services ブログ

Category: Security, Identity, & Compliance

AWS Certificate Manager (ACM) が Certificate Transparency (CT) をサポートするための準備

  2018年4月30日 より、Google Chrome は全ての公式に信頼する証明書は少なくても 2 箇所の Certificate Transparency ログに記録されている事を必須条件とします。これにより Google Chrome ではログに記録されていない発行済の証明書にはエラーメッセージが表示される事になります。2018年4月24日より、お客様が Certificate Transparency ログへの記録を無効にしない限り、アマゾンは全ての新規や更新した証明書について少なくても 2 箇所以上の公開ログに記録を行うようにします。 Certificate Transparency ログが無い場合、所有するドメイン名に対する予期しない証明書発行を把握することは難しいでしょう。現行システムでは、発行された証明書の記録は保管されておらず、ドメインの所有者は不正な証明書を見つける信頼性のある方法はありませんでした。 この状況に対処するために、Certificate Transparency は発行された各証明書についての暗号化技術による安全なログを実現します。ドメインの所有者は間違いや悪意で発行されたものも含め、予期しない証明書を見つけるためにログを検索することができます。また、ドメインの所有者は不適切に証明書を発行している認証局 (CA) を見つける事も可能です。このブログ記事では、Certificate Transparency についてより詳細に説明し、どうやって準備をすればよいのかお伝えします。

Read More

Amazon EC2 テストポリシー

ネットワークストレステスト 【日本語訳】日本時間 2018年02月08日09:00 このポリシーは、お客様の Amazon EC2 インスタンスから、他の Amazon EC2 インスタンス、AWS プロパティ/サービス、外部エンドポイントのような他の場所へ、大規模なネットワークテストを直接実施することを計画しているお客様に関係するものです。 これらのテストは、ストレステストや負荷テスト、ゲームデーテストと呼ばれることがあります。このポリシーでは、テストにおいて正当な大規模トラフィックあるいはテストトラフィックを特定の対象アプリケーションに対し送信する行為を「ネットワークストレステスト」とします。エンドポイントとインフラストラクチャは、このトラフィックを処理できる必要があります。 このポリシーは、通常のプロダクションのトラフィックとは関係ありません。ネットワークストレステストは、多くの場合、特定のエンドポイントを対象とし、送信元や対象が集中することを含め、通常とは異なるトラフィックパターンを持ち、持続的に大規模なトラフィックが発生し、予期している上限値を超える可能性があるため、通常のプロダクションとは異なります。ネットワークストレステストにおけるこれらの違いは、外部エンドポイント、他のお客様、AWS サービスに対し意図しない影響を与えうる潜在的なリスクとなります。 パケットや接続のフラッディング、それ以外の大規模なトラフィックで、ターゲットやインフラストラクチャへ意図的に過大な負荷をかけるテストは、ネットワークストレステストではなく、分散型 DoS (DDoS) テストとして扱われます。ボリュームのあるネットワークベースの DDoS シミュレーションは、Amazon EC2 プラットフォームでは明示的に禁止されています。このポリシーは、https://aws.amazon.com/security/penetration-testing の範囲のセキュリティやペネトレーションテストは対象としません。 ほとんどのお客様はこのポリシーには該当しません。通常、ユニットテストのように大規模なワークロードをシミュレートするストレステストでは、ネットワークストレステストに該当するだけのトラフィックは生成されません。このポリシーは、お客様のネットワークストレステストによって、Amazon EC2 インスタンスで以下の基準を満たすトラフィックが生成されたときに適用されます。”持続的に 1分以上の間 1 Gbps(秒間 1億ビット)あるいは 1Gpps(秒間 1億パケット)を超えるトラフィック、悪用目的や悪意があるように見えるトラフィック、テスト対象以外(ルーティングや共有サービスのインフラストラクチャなど)へ潜在的に影響を及ぼしうるトラフィック” などが該当します。 お客様は、対象のエンドポイントへのテストが承認され、その起こりうる規模について理解している必要があります。いくつかの外部エンドポイントや AWS サービスは、ある種のテストシナリオに対して期待する閾値よりも低い性能しか発揮できない可能性があります。 AWS を利用する多くのお客様は通常のプロダクションモードで定期的に 1Gbps もしくは 1Gpps 以上のトラフィックを生成していることを確認しております。これは完全に正常であり、特にネットワークストレステストの目的のために実施されたものではない限り、このポリシーの範囲下ではありません。 このポリシーの基準を満たすネットワークストレステストにはリスクがあります。お客様が悪質であると検知され報告されるリスク、お客様が意図せず悪質となり他の対象に影響を及ぼすリスク、お客様が所有するインスタンスで機能制限を受ける可能性などがあり、この際にはテストだけではなく、プロダクションのワークロードへ影響する可能性があります。 実施するテストがこれらの基準を満たすか、お客様で不明な場合は、このポリシーに従い、AWS 側にテストの評価を依頼する必要があります。お客様の体験や、その他の影響を受ける可能性があるサービスを改善していくため、これらのストレステストを実行する前には、Amazon EC2 ネットワークストレステストを申し込みフォームから申請してください。このフォームは aws-security-simulated-event@amazon.com へメールを送ることで入手できます。 お客様のネットワークストレステストが 外部や他の AWS サービスのような EC2 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

Read More

ホワイトペーパー「日本におけるプライバシーに関する考慮事項に照らした AWSの利用」の公開

2017年5月30日、昨今の IT 技術の飛躍的に進歩に伴い、様々な個人情報の利活用の現状を踏まえ、改正個人情報保護法が全面施行されました。個人情報の取り扱いに関する義務が明確になりましたが、一方でクラウドをご利用する上で配慮すべき点が増え、考慮されているお客様もいらっしゃるかと思います。そのようなお客様の声にお答えするために、お客様が自身のクラウド利用を検討していく際の参考資料として「日本におけるプライバシーに関する考慮事項に照らした AWS の利用」(ホワイトペーパー)を準備し、コンプライアンスのリソースページにて公開しました。本ホワイトペーパーは、今回の改正個人情報保護法に沿った内容となっており、お客様がご自身の IT インフラストラクチャを AWS へ移行する際の主な検討事項となる以下の点について解説しています。   • コンテンツのセキュリティをどのように担保していくのか? • コンテンツはどこに保存されるのか? • コンテンツにアクセスできるのは誰か? • どのような法令がコンテンツに適用され、これらを遵守するには何が必要か?   上記のようなお客様がクラウドのセキュリティやプライバシーについて検討いただく際に、最も重要となるのが「責任共有モデル」についての理解です。AWS はクラウドサービスにおけるインフラストラクチャ自体のセキュリティについて責任を持ちます。一方で、お客様はサービス利用に際して法令を遵守し、併せて当該クラウド環境の上に構築するサービス、オプションの構成やデータ保護のための追加の構成等によりご自身のコンテンツについてのセキュリティを確保するという責任を持つことになります。AWS ではこのようにお客様と AWS の2者でシステム全体の統制やセキュリティを担保していくモデルを「責任共有モデル」と呼んでいます。詳しくは本ホワイトペーパーの「クラウドセキュリティの管理に対する 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, […]

Read More

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

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