Category: Security, Identity, & Compliance

日本のお客様から問い合わせの多かった日本語での SOC1 レポートの提供ですが、2018 年 5 月 23 日より日本語の AWS SOC1 レポートの翻訳文書（以下、日本語 AWS SOC1 レポート）を AWS Artifact 経由で提供を開始しました。今回提供開始の日本語AWS SOC1レポートの対象期間は2017年4月1日から2017年9月30日のものとなります。AWS は最新の SOC1 レポートに合わせてのタイムリーな日本語文書の提供に向けて継続して取り組んでいく予定です。また、SOC レポートに関連してお客様から問い合わせの多い質問と回答を下記に記載しています。各 SOC レポートの詳細、および最新の情報に関しては、以下のサイトをご参照ください。 https://aws.amazon.com/jp/compliance/soc-faqs/   ・SOC1レポートの主目的 SOC1は財務報告に係る内部統制に関連する可能性がある AWS の統制環境について、顧客に情報を提供すること、および財務報告に係る内部統制（ICOFR）の有効性に関する評価および意見について、顧客とその監査人に情報を提供することを目的としています。   ・SOC1 レポートの内容 AWS の統制環境に関する説明、および AWS が定義した統制と目標の外部監査に関する説明   ・各 SOC レポートの入手方法 AWS SOC 1 レポート、日本語AWS SOC1レポート、および AWS SOC2 レポートは、お客様が AWS Artifact (AWS のコンプライアンスレポートをオンデマンドで入手するためのセルフサービスポータル)を 経由して直接入手できます。   […]

アプリケーションやフェデレーションされたユーザーが長時間実行の必要なワークロードを単一のセッションで完了できるように、IAM ロールの最大セッション時間を 12 時間まで延長できるようになりました。ユーザーおよびアプリケーションはこれまで通り AWS Security Token Service (AWS STS) を使ってロールを引き受けつつも、AWS SDK または CLI で取得した一時的な認証情報の有効期間が最大 12 時間となるようにできます。この変更により、ユーザーやアプリケーションは、S3 への大量アップロードやCloudFormation テンプレートといった長時間実行が必要なワークロードを、単一のセッションで実行できるようになります。最大セッション期間の延長は、IAM コンソール、または CLI で行えます。最大セッション期間を延長すると、対象の IAM ロールを引き受けているユーザーやアプリケーションが次に一時的な認証情報をリクエストした際には延長された有効期限の認証情報が得られるようになります。 本ブログ記事では、IAM コンソールを使用して、既存の IAM ロールの最大セッション期間を 4 時間 (設定可能な最大期間は 12 時間) に設定する方法をご紹介します。4 時間にする理由は、AWS では、ロールのセッション期間を設定する場合、フェデレーションされたユーザーが AWS リソースへのアクセスを最低限必要と思われる期間に設定することを推奨しているためです。次に、既存のフェデレーションされたユーザーが、AWS SDK や CLI を使用して、ロールのセッションの有効期限が切れると失効する一時的なセキュリティ認証情報をリクエストする方法についてご説明します。 前提条件 本ブログ記事では、フェデレーションの例を使用します。既存の ID プロバイダーがある場合は、SAML (Security Assertion Markup Language) を使ったフェデレーションを有効にして、ユーザーによる AWS リソースへのアクセスを許可している方もおられると思います。本ブログ記事では、フェデレーションされたユーザーの権限を定義する外部 ID プロバイダー用の […]

リレーショナルデータベースエンジンを選ぶとき、お客様は、管理、性能、信頼性、自動化など、さまざまな面に注目しますが、最近では、さらに保存されたデータをネイティブに暗号化する機能にも注目が集まっています。Amazon Aurora は、可用性と拡張性が高い最適なリレーショナルデータベースエンジンで、MySQL と PostgreSQL の両方をサポートしています。Amazon Aurora は、保存されたデータのネイティブ暗号化をサポートしており、AWS Key Management Service (AWS KMS) を使用して暗号化用のキーの保管と管理をします。 AWS KMS を使用して暗号化キーの作成、保管、管理をすることができます。これはハードウェアセキュリティモジュール (HSM) で強化されており、確実にキーを安全に保管できます。 AWS KMS は、次のようなさまざまなコンプライアンススキーマに準拠しています。 連邦情報処理標準 (FIPS) 140-2 System and Organization Controls (SOC) 1、2、3 ペイメントカード業界データセキュリティ基準 (PCI-DSS) レベル 1 Federal Risk and Authorization Management Program (FedRAMP) 医療保険の相互運用性と説明責任に関する法令 (HIPAA) AWS KMS の特長は、お客様管理のカスタマーマスターキー、すなわちCMKです。AWS KMS では CMK を使用することで、独自のポリシーに基づくキーのローテーション、キーの削除、KMS ポリシーと IAM ポリシーによるキーへのアクセス制御などの機能が得られます。AWS KMS […]

こんにちは、マーケティングの鬼形です。 先日 (2018/4/4) 開催致しました AWS Black Belt Online Seminar「Amazon Macie」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

この度、AWS のサービス全てが GDPR (EU 一般データ保護規則) に準拠しましたことをご報告致します。この準拠によって、お客様は、AWS がサービスのセキュリティを維持する目的で、すでに講じているさまざまな対策から得られるメリットに加え、GDPR に準拠する計画の重要な構成要素として AWS のサービスを導入できるようになります。 この発表は、GDPR サービス準備状況に対する監査がすべて完了したことを示しており、これはすなわち、GDPR がデータ処理者に要求するプライバシーに関する高いハードルとデータ保護基準に対し、一般的に利用可能な AWS のすべてのサービスと機能が準拠したことを示しています。この作業は、GDPR の施行開始日となる 2018 年 5 月 25 日の 2 か月前に完了しています。これにより、独自の GDPR 準拠の製品、サービス、ソリューションを、自信を持って構築できる環境をお客様や APN パートナーの皆様に提供するものです。 AWS が GDPR サービスの準備を完了したことは、今回の発表内容の一部に過ぎません。私たちは GDPR への準拠を支援するため、お客様と APN (AWS Partner Network) の皆様との協力を継続していきます。この発表に加え、お客様自身が GDPR 準拠への取り組みを加速するために AWS がどのようにお役に立てるかについて、以下に例を挙げ、ご紹介いたします。 個人データのセキュリティ GDPR サービス準備状況に対する監査では、AWS が GDPR に従って個人データを保護する目的でデータ処理者に対し技術的および組織的措置を効果的に講じていることを、私たちのセキュリティと法令遵守の専門家が確認しています。私たちにとってセキュリティは依然として最優先事項であり、イノベーションを継続させ、あらゆるグローバルオペレーションにおいてセキュリティと法令遵守のための高い基準を達成できるように投資していきます。私たちが持つ業界最高レベルの機能では、国際的に認知されているさまざまな認証や認定の基盤を提供し、厳しい国際規格に準拠できることを実証しています。準拠している国際規格には、技術的な対策に関する ISO 27001、クラウドセキュリティに関する ISO 27017、クラウドプライバシーに関する ISO 27018、SOC […]

オンプレミスのユーザー管理者が、AWS Managed Microsoft ADとも呼ばれる “AWS Directory Service for Microsoft Active Directory” を管理できるようになりました。 Active Directory（AD）信頼と新しいAWS委任ADセキュリティグループを使用すると、オンプレミスADディレクトリのグループメンバシップを管理することで、オンプレミスユーザーに管理アクセス許可を与えることができます。これにより、管理を実行できるユーザーを簡単に管理できます。また、管理者は、オンプレミスのAD資格情報を使用して既存のワークステーションにサインインして、AWS Managed Microsoft ADを管理できるため、管理者の作業が楽になります。 AWSは、AWS Managed Microsoft ADディレクトリに新しいドメインローカルADセキュリティグループ（AWS委任グループ）を作成しました。各AWS委任グループには、一意のAD管理者権限があります。新しいAWS委任グループのメンバーであるユーザーは、ユーザーの追加、細かいパスワードポリシーの構成、Microsoftエンタープライズ認証局の有効化などの管理タスクを実行するためのアクセス許可を取得します。 AWS委任されたグループは、範囲内のドメインローカルなので、オンプレミスADに対するAD信頼を使用してそれらを使用できます。これにより、AWS Managed Microsoft ADを管理するために別個のIDを作成して使用する必要がなくなります。代わりに、選択したオンプレミスユーザーを必要なAWS委任グループに追加することで、管理者に権限の一部またはすべてを付与できます。オンプレミスのADセキュリティグループをAWS委任グループに追加することで、これをさらに簡素化できます。これにより、オンプレミスのADセキュリティグループからユーザーを追加したり削除したりして、AWS Managed Microsoft ADの管理者権限を管理できるようになります。 このブログでは、オンプレミスのユーザーに権限を委任して、管理タスク（AWS Managed Microsoft ADディレクトリの細かなパスワードポリシーの設定）を実行する方法を説明します。この記事の手順に従うことで、グループマネージドサービスアカウントとKerberos制約付き委任の構成などの他の管理アクセス許可をオンプレミスのユーザーに委任できます。   背景 これまで、AWS Managed Microsoft ADは、組織単位（OU）にADセキュリティグループを作成し、これらのAWS委任グループに共通管理アクティビティを許可することによって、ディレクトリの管理者権限を委任していました。ディレクトリ内の管理者ユーザーは、OU内にユーザーアカウントを作成し、これらのユーザーにこれらのAWS委任グループの1つ以上にディレクトリを追加してディレクトリを管理する権限を与えていました。 ただし、オンプレミスADフォレストへの信頼をAWS Managed Microsoft ADに構成した場合、オンプレミスディレクトリのユーザーをこれらのAWS委任グループに追加することはできませんでした。これは、AWSがグローバルスコープのAWS委任グループを作成し、別のフォレストからのユーザーの追加を制限するためです。そのため、管理目的でAWS Managed Microsoft ADに異なるユーザーアカウントを作成する必要がありました。その結果、AD管理者は、通常、AWS Managed Microsoft ADの追加の資格情報を覚えておく必要がありました。 これに対処するために、AWSはドメインローカルスコープを持つ新しいAWS委任グループを、AWS Delegated Groupsと呼ばれる別個のOUに作成しました。ドメインローカルスコープを持つこれらの新しいAWS委任グループは柔軟性が高く、他のドメインやフォレストからのユーザーやグループの追加を可能にします。これにより、管理者ユーザは社内のユーザおよびグループの管理者権限をAWS Managed Microsoft ADディレクトリに委任できます。 備考: […]

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

ネットワークストレステスト 【日本語訳】日本時間 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 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

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