Category: Security, Identity, & Compliance

先日 (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 をどのように解釈するかを法務部門以外に任せるのは、リスクが大きく、時間とリソースの無駄になる可能性があります。法務部門から適切な助言を得て、方向性を統一して協力し、適切な緊急感を持って前進すれば、分析麻痺による作業停滞に陥らずにすみます。 […]

2021 年 8 月 1 日現在、日本語での SOC レポートは提供されていません。AWS Atifact 内において英文で提供されている最新版をご参照ください。 —————————————————————– 日本のお客様から問い合わせの多かった日本語での 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 […]

アプリケーションやフェデレーションされたユーザーが長時間実行の必要なワークロードを単一のセッションで完了できるように、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 についてより詳細に説明し、どうやって準備をすればよいのかお伝えします。