Category: Security, Identity, & Compliance

本日は、Application Load Balancer (ALB) に組み込みの認証サポートを発表できることにワクワクしています。ALB は、今後、ユーザーがアプリケーションにアクセスする際、ユーザーを安全に認証できるようになり、開発者に認証をサポートするためコードを書く必要を排除し、バックエンドからの認証責任を軽減させます。チームは認証機能を試せる素晴らしいライブサンプルの環境を構築できます。 アイデンティティベースのセキュリティは、最新のアプリケーションの重要なコンポーネントであり、顧客がミッションクリティカルなアプリケーションのクラウドへの移行を継続するにつれて、開発者は同じ認証コードを何度も何度も実装するように要求されます。企業は、それぞれのクラウドアプリケーションによりそれぞれのオンプレミスアイデンティティを使用したいと考えています。ウェブ開発者は、ソーシャルネットワークのフェデレーシフェデレーティッド認証を使用して、それぞれのユーザーがサインインできるようにしたいと考えています。ALB の新しい認証アクションは、Google、Facebook、および Amazon Cognito を通した Amazon のようなソーシャルアイデンティティプロバイダ (IdP) を通した認証を提供します。さらに、任意の OpenID Connect プロトコル準拠の IdP とネイティブで統合され、セキュアな認証およびご使用のアプリケーション間でのシングルサインオンを提供します。 ALB 認証が機能する方法とは？ 認証は複雑な話題であり、読者の皆さんの専門知識のレベルが同じとは限りません。それゆえ、皆さんのすべてに適用可能な状況が確実であるようないくつかの重要な概念をカバーしたいと思います。あなたがすでに認証の専門家であり、ALB 認証がどのように機能するかだけを確認したい場合には、次のセクションをご自由に飛ばしてもらっても構いません！ 認証とは、アイデンティティを検証することです。 許可とは、1 個のアイデンティティが実行を許可される「モノ」へのアクセス許可です。 OpenID Connect (OIDC) は、シンプルなアイデンティティまたは認証のレイヤーであり、OAuth 2.0 プロトコルの最上位階層に構築されるレイヤーです。OIDC 仕様書はかなりよく書かれており、機会があれば読んでみるべき価値があるものです。 アイデンティティプロバイダー (IdP) はアイデンティティ情報を管理し、認証サービスを提供します。ALB は任意の OIDC 準拠 IdP をサポートしており、Amazon Cognito や Auth0 を使用し、Active Directory、LDAP、Google、Facebook Amazon のようなさまざまな IdP からか、または AWS もしくはオンプレミスでデプロイされたその他のタイプからかの、異なるアイデンティティを集約することができます。 専門用語からは少し離れてしまいますが、これらのすべての事項は、ユーザーが誰であるか、彼らには何を実行することが許可されるのかと言うことに帰結します。これをセキュアでかつ効率的に実行することは困難です。従来、企業では、それぞれの IdP […]

セキュリティは AWS の最優先事項です。これはサービスの開始時から変わりません。GDPR (EU 一般データ保護規則、2018 年 5 月 25 日に施行開始) の導入により、私たちのセキュリティ中心の文化でもプライバシーとデータ保護がより強く意識されるようになりました。締切りよりかなり前でしたが、数週間前に AWS のすべてのサービスが GDPR の基準を満たしていることを発表しました。つまり、お客様の GDPR の課題を解決する 1 つの方法として AWS をご利用いただけるようになりました (詳細は GDPR Center をご覧ください)。 GDPR への準拠に関しては、多くのお客様で順調に準備が進んでおり、当初の不安はかなりなくなったようです。この話題でお客様とお話をさせていただくと、いくつかのテーマが共通しているように感じます。 GDPR は重要です。EU のデータ主体の個人データを処理する場合は、よいプランが必要です。これはガバナンスの問題だけでなく、GDPR に違反した場合には重い罰則があるからです。 この問題の解決は複雑で、多数の要員とツールが必要になる可能性があります。GDPR のプロセスでは多岐にわたる訓練も必要になるため、人員、プロセス、テクノロジーに影響が及びます。 お客様ごとに状況は異なり、GDPR への準拠を評価する方法も多数あります。そのため、お客様のビジネスの特性を意識することが重要です。 ここでは、私たちが学んだ教訓を共有したいと思います。GDPR の課題を解決するために、重要だったのは次の点です。 経営陣の参加が重要です。GDPR の詳細なステータスを当社 CEO の Andy Jassy と定期的に話し合っています。GDPR が非常に重要であることを AWS の経営陣は理解しています。必要な注意が GDPR にまだ向けられていないなら、今すぐ経営トップに知らせる必要があります。 GDPR 関連の作業を集中管理する必要があります。すべての作業の流れを集中管理することが重要です。当然のことのようですが、管理が分散すると、作業の重複やチーム・メンバーの方向性にズレが生じます。 GDPR の課題の解決で最重要のパートナーは法務部門です。お客様独自の環境に対して GDPR をどのように解釈するかを法務部門以外に任せるのは、リスクが大きく、時間とリソースの無駄になる可能性があります。法務部門から適切な助言を得て、方向性を統一して協力し、適切な緊急感を持って前進すれば、分析麻痺による作業停滞に陥らずにすみます。 […]

日本のお客様から問い合わせの多かった日本語での 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 プロバイダー用の […]

こんにちは、マーケティングの鬼形です。 先日 (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, […]