Category: Security, Identity, & Compliance

この度、AWS GDPR (一般データ保護規則) に準拠したデータ処理補遺条項 (DPA) (.pdf) がオンラインサービス条件に組み込まれたことをご報告します。これにより、AWS のすべてのお客様が、グローバルに AWS GDPR DPA を利用できるようになりました。これは、2018 年 5 月 25 日以降、AWS のサービスを使用して一般データ保護規則に従って個人データを処理する場合に自動的に適用されます。AWS GDPR DPA には、欧州連合 (EU) のデータ保護機関によって承認され、29 条作業部会として知られる EU モデル条項も含まれています。このため、EU 加盟国及び欧州経済領域 (EEA) からそれ以外の国に個人データを転送する場合に、AWS の個人データが EEA で保護されるレベルと変わらない高いレベルで保護されるため、AWS のお客様は安心してデータを転送できます。 この発表は当社、お客様、APN（Amazon Partner Network）のパートナー各社にとって重要な GDPR コンプライアンスの構成要素となっています。クラウドサービスを使用して個人データを処理するすべてのお客様は、GDPR に準拠する場合、クラウドサービスのプロバイダーとの間にデータ処理契約を結ぶ必要があります。 2017 年 4 月の早い時期に、AWS は GDPR に対応した DPA をお客様が利用できることを発表しています。このように、2018 年 5 月 25 日の施行日より 1 年以上前に、当社はお客様への […]

EU の一般データ保護規則 (GDPR) には、データプロセッサー（取扱者）とデータコントローラー（管理者）の役割が記述されており、一部のお客様や APN（Amazon Partner Network）のパートナー各社から、こうしたGDPR上の役割が、AWS 責任共有モデルにどのような影響を与えるかといった質問をいただいています。今回は、GDPR の観点から、私たちとお客様にとっての責任共有について説明したいと思います。 AWS 責任共有モデルは GDPR によってどのように変わりますか? という質問への簡易な回答は「変わりません」ということになります。AWS は、お客様に提供するクラウド環境とサービスをサポートする基盤となるインフラストラクチャを保護する責任を負います。一方、データコントローラーまたはデータプロセッサーとして行動するお客様と APN パートナーは、クラウドに入れた個人データに責任を負います。責任共有モデルには、AWS とお客様、APN パートナーの様々な責任が示され、同じ分類の責任が GDPR の下で適用されます。 データプロセッサーとしての AWS の責任 GDPR によって、データコントローラーおよびデータプロセッサーに関する明確な規則と責任が導入されます。AWS のお客様が当社のサービスを使用して個人データを処理するとき、データコントローラーは通常 AWS のお客様 (および場合によっては AWS のお客様の顧客) です。また、あらゆるケースで、AWS は常にこのアクティビティに関してデータプロセッサーとなります。なぜなら、お客様は AWS のサービス管理との相互作用を通じてデータの処理を指示しており、AWS はお客様の指示を実行しているにすぎないからです。データプロセッサーとして、AWS は、当社のすべてのサービスを実行するグローバルなインフラストラクチャの保護に対して責任を負います。AWS を使用する管理者は、エンドユーザーのコンテンツと個人データを処理するためのセキュリティ構成の管理を含めて、インフラストラクチャの保護は当社の最優先事項であり、セキュリティ上の統制を検証するためにサードパーティーの監査に多額の出資をしています。そこで明らかになった問題があれば、AWS Artifact を通じてお客様にお知らせすることになります。当社の ISO 27018 レポートはよい例であり、特に個人データの保護に重点を置いてセキュリティ管理をテストしています。 マネージドサービスに対する AWS の責任は大きくなっています。マネージドサービスには、Amazon DynamoDB、Amazon RDS、Amazon Redshift、Amazon Elastic MapReduce、Amazon WorkSpaces 等があります。ゲストオペレーティングシステム (OS) やデータベースのパッチ適用、ファイアウォール構成、障害回復等の基本的なセキュリティタスクは AWS […]

セキュリティは、AWS の最優先事項です。AWS は、お客様のデータを保護することを何よりも重視しており、お客様のフィードバックを AWS サービスに継続的に取り入れ、迅速なイノベーションに取り組んでいます。お客様に AWS のこうした取り組みについて、よりご理解いただくために、この度、AWS のセキュリティやコンプライアンスについて紹介する動画の公開を開始しました。   ・AWS の責任共有モデルのご紹介動画 IT インフラストラクチャーを AWS に移行する際は、責任共有モデルを考慮いただく必要があります。AWS の責任範囲はクラウド環境自体のセキュリティ、お客様の責任範囲はクラウド環境上のセキュリティとなります。お客様は、お客様のシステムと全く同じように、コンテンツ、プラットフォーム、アプリケーション、システム、ネットワークを保護するためのセキュリティを設計いただく必要があります。AWS の責任共有モデルについては、下記よりご視聴ください。     ・AWS のデータセンターのご紹介動画 AWS は AWS のデータセンターのデジタルなツアーを既に公開していますが、AWS のデータセンターの一部についてツアーのようにご覧いただける動画をお客様に公開いたしました。AWS は自然災害や人為的なリスク等から AWS のインフラストラクチャーを保護するための AWS のデータセンターシステムについて、継続したイノベーションに取り組んでいます。膨大な数の実際にご利用いただいているお客様を保護するためのセキュリティ上の取り組みについて紹介しておりますので、下記よりご視聴ください。     ・Amazon GuardDuty のご紹介動画 Amazon GuardDuty は、インテリジェントな脅威検出サービスとなり、悪意のある操作や不正な動作に対してAWS アカウントおよびワークロードを継続的に監視します。Amazon GuardDuty について紹介しておりますので、下記よりご視聴ください。     ・Amazon Inspector Amazon Inspector は、AWS に展開されたアプリケーションのセキュリティとコンプライアンスを向上させるための、自動化されたセキュリティ評価サービスです。脆弱性やベストプラクティスから優先順位付けしたセキュリティに関する所見の詳細リストを生成します。Amazon Inspector について紹介しておりますので、下記よりご視聴ください。     – […]

日本時間 2018年6月13日 03:00 インメモリデータストアであるRedisのセキュリティアドバイザリが公開されました。Amazon ElastiCache によって管理される Redis互換のノードは、単一のエンジンが稼働する、お客様の VPC で独立したお客様専用のノードです。したがって、VPC の設定で明示的に許可されていない限りは、他のお客様がそれらのノードに対しアクセスすることはできません。 Amazon ElastiCache においても、アップデートを含む新しい Redis バージョンがリリースされました。2018年6月10日以降に起動された ElastiCache クラスターには、影響はありません。既存の ElastiCache クラスターをお持ちのお客様は、メンテナンスウィンドウにて新しいバージョンへのアップデートが予定され、順次実施されます。このアップデ―トは今回の問題に完全に対処できるよう設計されており、ElastiCache はデフォルトで意図しない外部からのアクセスを防ぎます。このアップデートに関して、お客様によるアクションは必要ありません。 本件に関してセキュリティの懸念がある場合は、http://antirez.com/news/119 をご覧ください。また、Amazon ElastiCache クラスターへのネットワークアクセスをセキュアに保つ方法は、”Amazon VPCs and ElastiCache Security”[1] をご覧ください。 [1]: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/VPCs.html   上記はAWS Japan Security Awareness Teamによって翻訳されました。原文は以下です： https://aws.amazon.com/jp/security/security-bulletins/AWS-2018-016/

先日 (2018/5/9) 開催しました AWS Black Belt Online Seminar「Amazon GuardDuty」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

本日は、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 プロバイダー用の […]

リレーショナルデータベースエンジンを選ぶとき、お客様は、管理、性能、信頼性、自動化など、さまざまな面に注目しますが、最近では、さらに保存されたデータをネイティブに暗号化する機能にも注目が集まっています。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 […]