AWS 分析サービスがデータへのユーザーアクセス、アクセス許可設定、監査を効率化

AWS IAM アイデンティティセンターの最近導入された機能として、信頼されたアイデンティティ伝播に基づいた新しいユースケースが発表されました。

一般的に使用されているビジネスインテリジェンス (BI) アプリケーションである Tableau でエンドユーザーのアイデンティティを Amazon Redshift に伝播できるようになりました。これには 3 つのメリットがあります。エンドユーザーのサインインエクスペリエンスが簡素化されます。データ所有者は実際のエンドユーザーアイデンティティに基づいてアクセスを定義できます。監査人はユーザーによるデータアクセスを検証できます。

信頼されたアイデンティティ伝播では、データを消費するアプリケーション (Tableau、Amazon QuickSight、Amazon Redshift クエリエディタ、Amazon EMR Studio など) からデータを保存および管理するサービス (Amazon Redshift、Amazon Athena、Amazon Simple Storage Service (Amazon S3)、Amazon EMR など) にユーザーのアイデンティティとグループメンバーシップを伝播できます。信頼されたアイデンティティ伝播は IAM アイデンティティセンターの機能で、複数の分析アプリケーションにわたるサインインエクスペリエンスを向上させ、データアクセス管理と監査を簡素化します。エンドユーザーはシングルサインオンのメリットを利用できるので、システムに接続するために引き受ける IAM ロールを指定する必要がありません。

詳細を説明する前に、用語を確認しておきましょう。

ここでは、ユーザーアイデンティティとグループメンバーシップを保持するシステムを指すために「ID プロバイダー」という用語を使用します。これらは、ユーザーに認証情報の入力を要求し、認証を実行するシステムです。例えば、Azure Directory、Okta、Ping Identity などがあります。サポートされている ID プロバイダーの完全なリストを確認してください。

「ユーザー向けアプリケーション」という用語は、データを消費するアプリケーション (Tableau、Microsoft PowerBI、QuickSight、Amazon Redshift クエリエディタなど) を指します。

最後に、「ダウンストリームサービス」は、データの処理、データの保存、またはデータへのアクセスの管理を行う分析エンジンとストレージサービス (Amazon Redshift、Athena、S3、EMR など) を意味します。

信頼されたアイデンティティ伝播のメリットを理解するために、5月29日までデータアクセスがどのように付与されていたかを簡単に説明しましょう。ユーザー向けアプリケーションがダウンストリームサービスのデータにアクセスすると、アップストリームサービスは、一般的な認証情報 (「tableau_user」など) を使用するか、IAM ロールを引き受けることによってダウンストリームサービスに対する認証を行います。その結果、2 つの課題が生じます。

まず、ダウンストリームのサービス管理者にとって、リクエストを行う実際のユーザーに合わせて微調整されたアクセスポリシーを定義することが困難になります。ダウンストリームサービスから見ると、すべてのリクエストは、その共通のユーザーまたは IAM ロールから送信されます。例えば、Jeff と Jane の両者が BusinessAnalytics IAM ロールに割り当てられている場合、読み取り専用や読み取り/書き込みなど、それぞれに異なるレベルのアクセスを付与することはできません。さらに、Jeff が Finance グループにも属する場合、操作を行うロールを選択する必要があります。同じセッションで両方のグループからデータにアクセスすることはできません。

次に、データアクセスイベントをエンドユーザーに関連付ける作業には、差別化につながらない手間のかかる作業が伴います。リクエストが BusinessAnalytics という IAM ロールから送信された場合、そのアクションの背後にいるユーザーを識別するには追加の作業が必要です。

この例は非常にシンプルに見えるかもしれませんが、実際の組織には、数百のデータセットに対応する数百のユーザーと数千のグループがあります。これは、私たちにとって Invent and Simplify の機会でした。

新しい信頼されたアイデンティティ伝播の設定が完了すると、ユーザー向けアプリケーションがキーボードを操作する実際のユーザーに代わってデータにアクセスするための技術的メカニズムが提供されます。実際のユーザーアイデンティティを知ることによって、主に 3 つのメリットが生まれます。

まず、ダウンストリームのサービス管理者は、実際のユーザーアイデンティティ、所属グループ、またはこれら 2 つの組み合わせに基づいてアクセスポリシーを作成および管理できます。ダウンストリームサービスの管理者は、ユーザー、グループ、データセットの観点からアクセスを割り当てることができるようになります。これは、ほとんどのお客様がデータへのアクセスについて考える自然な流れです。このようなパターンを実現するために IAM ロールへの中間マッピングは必要なくなります。

次に、監査人は、システムログ内の元のユーザーアイデンティティにアクセスできるようになり、ポリシーが正しく実装されていること、および会社または業界レベルのポリシーのすべての要件に従っていることを確認できます。

第 3 に、BI アプリケーションのユーザーは、複数のアプリケーション間のシングルサインオンのメリットを活用できます。エンドユーザーにとっては、会社の AWS アカウントと IAM ロールに関して理解する必要がなくなります。代わりに、作業で行う他の多くのことで使い慣れた企業のシングルサインオンを使用して EMR Studio などにサインインできます。

信頼されたアイデンティティ伝播の仕組み
信頼されたアイデンティティ伝播は、業界の標準メカニズム (OAuth2 と JWT) に依存します。OAuth2 は、アクセス委任のオープンスタンダードです。ユーザーは自分の認証情報を公開することなく、サードパーティのユーザー向けアプリケーションに他のサービス (ダウンストリームサービス) のデータへのアクセスを付与できます。JWT (JSON ウェブトークン) は、2 つのパーティ間で転送されるアイデンティティとクレームを表現するコンパクトで URL セーフな手段です。JWT は署名されているため、その整合性と真正性を検証できます。

信頼されたアイデンティティ伝播の設定方法
信頼されたアイデンティティ伝播を設定するには、IAM アイデンティティセンター、ユーザー向けアプリケーション、ダウンストリームサービスにエンドユーザーアイデンティティと連携するように指示する必要があるので、これらの個々のコンポーネントでの設定が必要です。詳細はアプリケーションごとに異なりますが、すべて次のパターンに従います。

1. AWS IAM アイデンティティセンターで ID ソースを設定します。AWS では、ほとんどの ID プロバイダーがサポートしている自動プロビジョニングを有効にすることを推奨しています。自動プロビジョニングは、SCIM 同期標準に従って機能し、ディレクトリのユーザーとグループを IAM アイデンティティセンターに同期します。現在 IAM アイデンティティセンターを使用して AWS マネジメントコンソールで従業員のフェデレーションを行っている場合、この設定は既に完了していると思われます。これは 1 回限りの設定で、このステップを個々のユーザー向けアプリケーションで繰り返す必要はありません。
2. ID プロバイダーでユーザーを認証するようにユーザー向けアプリケーションを設定します。例えば、Okta を使用するように Tableau を設定します。
3. ユーザー向けアプリケーションとダウンストリームサービスの間の接続を設定します。例えば、Amazon Redshift にアクセスするように Tableau を設定します。場合によっては、Redshift 用の ODBC または JDBC ドライバーを使用する必要があります。

次に、信頼されたアイデンティティ伝播に固有の設定を行います。例えば、ID プロバイダーでユーザーを認証するユーザー向けウェブアプリケーションが組織で開発されていて、現在認証済みのユーザーに代わって AWS 内のデータにアクセスする場合を考えてみます。このユースケースでは、IAM アイデンティティセンターで信頼されたトークン発行者を作成します。この強力な新しいコンストラクトでは、アプリケーションの認証済みユーザーを IAM アイデンティティセンターのディレクトリユーザーにマップして、信頼できるアイデンティティ伝播を利用できるようになります。私の同僚の Becky が、このようなアプリケーションを開発する方法を紹介するブログ記事を書いています。この追加設定は、AWS の外部で認証される Tableau などのサードパーティアプリケーション (またはお客様が開発したアプリケーション) を使用する場合にのみ必要です。AWS が管理するユーザー向けアプリケーション (Amazon QuickSight など) を使用する場合、追加のセットアップは必要ありません。

最後に、ダウンストリームサービスの管理者は、ユーザーアイデンティティとグループメンバーシップに基づいてアクセスポリシーを設定する必要があります。正確な設定は、ダウンストリームサービスごとに異なります。アプリケーションが Amazon S3 でデータの読み取りまたは書き込みを行う場合、データ所有者は Amazon S3 コンソールで S3 Access Grants を使用して、ユーザーとグループに Amazon S3 内のプレフィックスへのアクセスを付与できます。アプリケーションが Amazon Redshift データウェアハウスにクエリを行う場合、データ所有者は Amazon Redshift コンソールで IAM アイデンティティセンターの信頼された接続を設定し、ID プロバイダーからのオーディエンスクレーム (aud) に一致させる必要があります。

設定の高レベルの概要が理解できたところで、最も重要な部分であるユーザーエクスペリエンスの詳細を確認しましょう。

エンドユーザーエクスペリエンス
エンドユーザーの正確なエクスペリエンスはアプリケーションごとに異なるのは明らかですが、いずれの場合でも、従業員ユーザーにとっては以前よりもシンプルで使い慣れたものになります。ユーザーインタラクションは、リダイレクトベースの認証シングルサインオンフローから始まります。このフローでは、ユーザーは ID プロバイダーにリダイレクトされ、そこで認証情報や多要素認証などを使用してサインインできます。

信頼されたアイデンティティ伝達が設定されている場合にエンドユーザーが Okta や Tableau とどのようにやり取りするかを詳しく見ていきましょう。

以下にシステムとサービスの間のフローと主なインタラクションの図を示します。

この仕組みを以下に示します。

1.ユーザーとして Tableau にサインインを試みます。

2.Tableau がブラウザーベースのフローを開始し、Okta のサインインページにリダイレクトします。ユーザーは、このページでサインインの認証情報を入力できます。認証が成功すると、Okta は Tableau に認証トークン (ID とアクセストークン) を発行します。

3.Tableau が Amazon Redshift との JDBC 接続を開始し、接続リクエストにアクセストークンを含めます。Amazon Redshift JDBC ドライバーが Amazon Redshift を呼び出します。Amazon Redshift 管理者が IAM アイデンティティセンターを有効にしているので、Amazon Redshift はアクセストークンを IAM アイデンティティセンターに転送します。

4.IAM アイデンティティセンターがアクセストークンを確認して検証し、アクセストークンを アイデンティティセンター発行のトークンと交換します。

5.Amazon Redshift はアイデンティティセンターのトークンを解決し、対応するアイデンティティセンターユーザーを決定してリソースへのアクセスを許可します。認証が成功すると、ユーザーは Tableau から Amazon Redshift に接続できます。

認証が完了すると、いつものように Tableau を使い始めることができます。

Amazon Redshift クエリエディタに接続すれば、sys_query_history テーブルを参照して、クエリを実行したユーザーが誰であるかを確認できます。Tableau からの接続に使用された Okta の E メールアドレスが awsidc:<email address> として正しくレポートされます。

この設定の詳細については、 Tableau のドキュメントを参照してください。

料金と利用可能なリージョン
信頼されたアイデンティティ伝達は、現在 AWS IAM アイデンティティセンターを利用できる 26 の AWS リージョンで追加コストなしで提供されています。

信頼されたアイデンティティ伝播とダウンストリームサービスの設定の詳細については、以下を参照してください。

ご活用ください。

信頼されたアイデンティティ伝播では、分析システムを設定して、実際のユーザーアイデンティティ、グループメンバーシップ、属性を Amazon Redshift、Amazon Athena、または Amazon S3 などの AWS のサービスに伝播できるようになります。その結果、これらのサービスのアクセスポリシーの管理が簡素化されます。また、監査人は、データにアクセスしているユーザーの実際のアイデンティティを把握する組織のコンプライアンス体制を検証できます。

今すぐ始めて、Amazon Redshift と Tableau の統合を設定してください。

— seb

PS: AWS でのブログ記事の執筆は、常にチームとしての取り組みとなります。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、信頼されたアイデンティティ伝播の多くの微妙な点と技術的詳細の理解に関する多くの支援に対して Eva Mineva、Laura Reith、Roberto Migli に謝意を表します。

原文はこちらです。