re:Invent 2024: AWSとNVIDIAが実現するUser-awareデータ分析とAI
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS and NVIDIA: Connecting workforce identity for gen AI and analytics (SEC315)
この動画では、AWS Identity のディレクターBrigid JohnsonとNVIDIAのSzymonが、User-awareなデータ分析の実装について解説しています。IAM Identity Centerを使用して企業のディレクトリをAWSに接続し、Trusted Identity Propagationを通じてユーザーコンテキストをサービス間で受け渡す方法を、具体的なデモを交えて説明しています。NVIDIAでは、この仕組みを活用して数億のファイルと数十億のレコードを扱うデータプラットフォームを4週間で実装し、認証情報管理の自動化とセキュリティ向上を実現しました。さらに、Amazon Q for businessを活用したGenerative AIアプリケーションでのUser-aware機能の実装方法まで踏み込んで解説しており、データアクセス制御からAIまでを包括的にカバーする内容となっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
User-awareなAWSへの取り組み：セッション概要
re:Inventへようこそ。本日はご参加いただき、ありがとうございます。月曜日の朝一番にIdentityに関する講演で始められることは、これ以上ない素晴らしいスタートだと思います。私はAWS Identityのディレクター、Brigid Johnsonです。本日は、NVIDIAがUser-awareなデータ分析を本番環境でどのように実現したかについて、Szymonにもお話しいただく予定です。この話題について、私は非常にワクワクしています。
皆さんの組織には、データアナリスト、ビジネスアナリスト、UXデザイナー、開発者など、様々な従業員がいて、彼らは全員AWSへのアクセスを必要としています。しかし、彼らがAWS内を移動する際、BrigidはつねにBrigidとして認識され、Brigidとそのグループに基づいてアクセス制御が確実に機能することが重要です。
これから1時間、このテーマについて話していきます。まず、より User-awareなAWSへの私たちの取り組みについてお話しし、その後User-awareなAWS環境を構築するステップを説明します。次に、企業のディレクトリとの接続について説明し、デモをお見せして実際の動作を確認していただきます。その後、SzymonがNVIDIAでこれらをどのように統合したかについてお話しします。技術的な内容に深く踏み込み、認証情報やトークン、Identity Providerについて、いくつかの面白いデモを交えながら説明します。データ分析で学んだこれらの概念を、Generative AIにも応用していきます。会場にいらっしゃる皆様、そして他の会場でストリーミング視聴されている皆様にも手を振ってご挨拶させていただきます。ありがとうございます。また、メモを取りたい方、メールで要約を作成したい方、上司に学んだことを報告したい方のために、チートシートもご用意しています。
ユーザー認識型データアクセスの必要性と実現方法
AWSは長年にわたってクラウドインフラストラクチャサービスを提供し、素晴らしい実績を上げてきました。S3、Secrets Manager、DynamoDB、EC2、Lambda など、必要なものは何でも揃っています。これらに対して、Roleは様々な理由で非常に優れた仕組みでした。企業のディレクトリに従業員ユーザーがいて、AWS アカウントのRoleを引き受け、そのRoleに基づいた権限を持ち、LambdaファンクションやEC2インスタンスをプロビジョニングすることができました。しかし時間とともに、データ分析やさまざまなジョブのために作られた、より高度なツール、つまりAWSマネージドアプリケーションを提供するようになり、これらのジョブはより User-awareである必要がありました。
これが現実のものとなるにつれて、お客様からは、ユーザーがデータ分析ツールを使用する際に、各レイヤーでアクセスできることを確認したいという要望がありました。誰が何にアクセスできるのかを、あらゆるレイヤーで監査できることを確実にしたいと考えていました。私たちは、BrigidがAWS内を移動する際にAWSがユーザーを認識し、ユーザーがQuickSight、Redshift、Athenaなどのアプリケーションから作業を開始して、単純に仕事を完了できるようにしたいと考えていました。
User-awareなAWSについてご紹介したいと思います。これは、企業のディレクトリ（つまりIdentity Provider）を一度接続するだけで、データアクセスがユーザーのアイデンティティに基づいて、より正確には所属グループに基づいて管理される仕組みです。ところで、Picklesは馬なのでしょうか？はい、私の馬のPicklesをご紹介させていただきます。今日は従業員として、つまりWorkforceユーザーとして参加してもらいます。彼は何でもやってくれる心強い仲間なので、今日は何度も登場することになります。従業員の方々がAWSを使用する際、PicklesはPicklesであり、常に馬であることを確認する必要があります。
では、User-awareなAWS環境を構築するために必要なものは何でしょうか？料理番組のように材料を見ていきましょう。まず、企業のディレクトリが必要です。ほとんどの企業がすでに持っているもので、Ping、Okta、Microsoft Entra IDなどがこれにあたります。ここでユーザーやグループが定義され、真実の源となります。これを変更する必要はありません。組織内の全アプリケーションに対してすでに存在しているものです。次に、AWS環境が必要です。これはAWS Organizationで、メンバーアカウントを含み、そのメンバーアカウント内にサービスやアプリケーションがあります。このAWSユーザージャーニーの出発点となるのがデータ分析で、Amazon S3、AWS Lake Formation、Amazon Redshiftがデモの基盤となります。そして、Amazon Qでパワーアップしたり、Amazon Q Developerで作成したりする従業員向けアプリケーションが必要です。
User-awareなAWSの実現には3つのパートがあります。まず、企業のディレクトリをAWSに接続します。今日は特にIAM Identity Centerについて詳しく説明します。これは一度接続すれば全体で使用できる方法だからです。次に、アイデンティティに基づいてデータアクセス制御を指定します。これについてはSzymonが説明します。Trusted Identity Propagationを使用してこれを実現し、データサービスがPicklesをユーザーとして、そして馬として認識できるようにします。さらに、従業員向けアプリケーションに生成AIを使用してチャットボットを実装する際には、Picklesが馬に関する質問はできても、人間に関する質問はできないようにするなど、パーソナライゼーションで機能を強化できます。
Amazon RedshiftとLake Formationを用いたデモンストレーション
AWS IAM Identity Centerの概要をご説明しましょう。今日のセッションで覚えていただきたいことは、まず第一に：従業員をAWSに接続するにはIAM Identity Centerを使用することです。Identity ProviderをIdentity Centerに接続することで、すべてが機能し始めます。すべての機能を使う必要はありませんが、接続すると、AWS Organization用のユーザーストアが作成されます。これはSCIM標準に基づいてユーザーとグループを同期します。これは一般的な方法で、AWS環境に対して一度だけ設定します。設定が完了すると、AWS管理アプリケーションにアクセスでき、メンバーアカウント内では、ローカル管理者が特定のアクセス権限を付与できます。個人やユーザーが移動する際、異なるサービスやデータに一度にアクセスする可能性があり、そこでTrusted Identity Propagationを通じてアイデンティティを伝播させ、Amazon Redshiftがアイデンティティを渡し、Lake FormationがS3に渡すことで、Picklesが常にPicklesであることを確実にします。
IAM Identity Centerには追加機能がありますが、AWSの人間が壇上に立って「全ての機能を使う必要はありません」と言うのは珍しいことですね。これらの機能は、既存のソリューションをお持ちでない場合や、使いたいと思った場合にのみ使用してください。これから説明する3つの機能を使わなくても、私は気にしません。多くのお客様から、アイデンティティを接続すると、DevアカウントやProdアカウントなどのアカウント内でのアクセス権限の付与にPermission Setsを使わなければならないと思っていたと聞きます。実際にはそうではなく、この機能をオフにしているお客様もいらっしゃいます。Identity Providerをまだお持ちでないスタートアップや小規模グループ向けのネイティブIdentity Storeなど、追加機能もあります。Lambda関数やS3バケットを作成するためのAWSアカウントへのアクセス権限を付与する既存のソリューションをお持ちでない場合は、Permission SetsとAccount Accessを使用できます。
これはPicklesの真剣な表情です。彼はコンペティションに向かう準備ができていて、皆さんに重要なメッセージがあります：IAM Identity Centerを使ってワークフォースをAWSに接続してください。すべての機能を使う必要はありません。まずは接続して、どの機能を有効にするか選択できます。
ディレクトリをAWSに接続することについて、何度も繰り返し説明しましたね。ここで実際の手順を説明させていただきます。こちらが実際の構成です：左側の緑色の部分は皆さんの環境です。これはIdentity Providerの設定で、ユーザーとグループを作成する場所です。これは全て皆さんが普段から行っていることです。右側がAWSの部分で、AWS OrganizationとIAM Identity Centerインスタンスを管理するための委任管理アカウントがあります。
ユーザーとグループはSCIMを介して同期され、そのように機能します。真のソースは緑色のシステムのままで、変更する必要はありません。私たちは、皆さんがいる場所でIAM Identity Centerに接続できるようにしています。今日のデモでは、OktaをAWS IAM Identity Centerに接続して使用します。
先に進む前に、Identity Centerがどのように見えるかお見せしましょう。今日はライブデモを行いますので、もし何か問題が起きたら、応援してください。少し時間を短縮するために、事前に読み込んでおきました。正しいパスワードを入力するようにしましょう。今日の管理者としてChromeでBrigidとしてサインインします。この部屋のインターネットは少し遅いですね。応援ありがとうございます。ここから始めましょう。うまくいくといいですね。もしダメな場合は、ビデオに切り替えます。よし、できました。管理者のBrigidとしてサインインしました。
管理者として組織の管理アカウントにアクセスし、IAM Identity Centerのインスタンスをご紹介したいと思います。 まずは設定画面をお見せしましょう。 はい、こちらが設定画面です。ご覧の通り、外部Identity ProviderがSAMLベースで接続されています。 これらのグループはすべてOktaで定義されています。先ほどBrigidがOktaにログインしたのをご覧になったと思いますが、human usersやhorse usersなどのグループがあります。 このIdentity情報がAWSに送られます。Identity Providerを接続すると、ユーザーとグループが同期されてAWSに保存されます。先ほど見ていただいたPicklesやBrigidといったユーザーはIAM Identity Centerで作成されたわけではなく、Oktaから来ています。これらはSCIM標準に基づいて更新され、メンバーアカウント内のローカル管理者が、主にグループを使用してユーザーやグループにアクセス権を付与できるようになります。
さて、従業員がAWSに接続できるようになったら、次は何でしょうか？シングルサインオンで多くのアクセス権を得ることができます。 本日は主にユーザー認識型データアクセスについて説明していきますので、まずはそこから始めましょう。Amazon Redshift、Amazon Athena、AWS Lake Formation、Amazon DataZoneがあり、ユーザーはユーザー認識型データアクセスを持つアプリケーションにシングルサインオンできます。また、Amazon Qによるパーソナライズされたエクスペリエンスもあり、そこにはさまざまな機能が用意されています。結局のところ、IAM Identity Centerに接続されていれば、ユーザーがシングルサインオンでアクセスできるアプリケーションということになります。
これからデータアクセスについて詳しく説明していきますが、ここでNVIDIAでの実践例についてSzymonさんにお話しいただきたいと思います。私はSzymonと申します。NVIDIAのソリューションアーキテクトとして、オペレーションとデータ分析チームに所属しています。私たちは、ハイパフォーマンスコンピューティングと生成AIをサポートするデータセンター製品の品質に関する洞察を提供しています。 いくつかの数字をご紹介しましょう。NVIDIA Blackwellアーキテクチャは世界最大のGPUで、1つのGPUに2,070億個のトランジスタを搭載し、20ペタフロップスという史上最速の演算性能を実現しています。また、NVIDIA GB 200は1つのラックでエクサスケールコンピューターを実現します。72個のBlackwell GPUと36個のGrace CPUを組み合わせることができ、ハイパフォーマンスコンピューティングでは36台のGB 200を組み合わせてワークロードを実行できます。
NVIDIAにおけるUser-awareなデータアクセスの実装
これらの数字は信じがたいほど大きいものですが、現実に起きていることなのです。このような高度に複雑な製品の背後には、同様に複雑なデータプラットフォームが存在します。複雑なサプライチェーンの一部である工場から、データは継続的に流れ込んでいます。製品組み立ての各段階における厳密なテストが、高品質な製品には不可欠です。これらすべてが膨大な量の情報を生み出しています。
私たちは数億のファイル、数十億のレコード、そして数百のテーブルを扱っています。製品開発からオペレーションまで、高品質なデータへの即時アクセスを必要とするチームをサポートしています。私たちのデータプラットフォームの秘訣は何でしょうか？もちろん、驚くことではありませんが、AWS cloudを使用しています。 AWS cloudは2年以上にわたって使用してきたソリューションです。顧客、工場、そして社内のソースからデータを取得し、Amazon S3バケットに保存します。次に、AWS Glueを使用してデータを処理し、Amazon Redshiftに保存します。AWS Redshiftのデータ共有によるデータメッシュアーキテクチャを活用することで、不要なデータ移動を最小限に抑えています。これらのデータはすべて1か所に集約され、ユーザーは様々な分析ツールを使用してクエリを実行できます。
AWSのデータアーキテクチャがもたらすビジネス価値は、インフラストラクチャではなく、ビジネスの課題やニーズ、ロジックに集中できることです。これは私のようなアーキテクトにとって最大の利点でした。ユーザーにとっては、データの所在を追跡する代わりに、データからの洞察を活用することに多くの時間を費やせるようになりました。私たちの最初のアクセス管理ソリューションは、ユーザーマネージャーとシステムマネージャーがデータへのアクセスを承認する2段階の承認プロセスに基づいていました。その後、Amazon Redshiftでユーザーとパスワードを作成し、特定のグループへのアクセス権を付与することで、手動でアクセスをプロビジョニングしていました。
このアプローチにはいくつかの課題がありました。まず、Redshiftにさらなる認証情報を作成することになりました。認証情報の管理にもセキュリティリスクが伴いました。また、管理者に追加の作業が発生し、これは変更が必要でした。 きっかけは、あるとき一部のデータが機密データとなり、セキュリティ、認証、承認方法を改善する必要が出てきたことでした。データオーナーがデータへのアクセスを承認する必要があり、これらの変更を実装するまでにわずか6週間しかありませんでした。
新しいデータガバナンスプロセスは大幅に改善されました。まず、 データカタログを作成し、そこですべてのデータのリスト化、データオーナーの割り当て、データの機密・非機密の分類を行いました。それを基に、自動化されたワークフロープロセスを設定しました。ユーザーは特定のデータへのアクセスをリクエストし、ユーザーマネージャーとシステムマネージャーがアクセスを承認する必要がありました。さらに、データオーナーもアクセスを承認する必要がありました。次の魔法は、Redshiftでのアクセスを自動的にプロビジョニングできたことです。
アクセスのプロビジョニングを自動化したことで、プレゼンテーション中に画面上で見えてしまう可能性のあるハードコードされたユーザー認証情報やパスワードが不要になりました。実際に、既存のアイデンティティを再利用しています。 ソリューションとして、IAM Identity Centerを使用しています。Microsoft Entra IDのアイデンティティプロバイダーをAWSと統合し、Amazon Redshiftでシングルサインオンを使用し、ワークフローからのグループを使用してAmazon Redshiftでロールベースのアクセスを設定します。Active DirectoryグループとAmazon Redshiftのロールの間には1対1の関係があります。これがアイデンティティプロバイダーとの素早い連携を可能にした魔法でした。私は常に魔法のファンなんです。
ユーザーの視点からは、シングルサインオンのおかげで生活が快適になりました。Trusted Identity Propagationのおかげで、ユーザーはNVIDIAだけでなく、AWS世界でも自動的に認証されました。Amazon Redshiftでも認証されていました。次に来たのが認可で、これはAmazon RedshiftのロールにリンクされたActive Directoryグループに基づいていました。こちらがPythonコードの例です。 ここには認証情報がありません。これは大きな勝利です。Credential ProviderやIssuer URLなど、提供する必要のあるパラメータがいくつかあります。認証はSSOで行われ、残りのコードは変更されません。
Amazon Redshiftの監査の観点からは、大きな変更はありませんでした。同じシステムテーブルを引き続き使用しています。大きな違いは、アクセス管理にグループではなくロールを使用するようになったことです。 ビジネス面での成果はどうでしょうか？Microsoft Entra IDとAWSで同じIDを再利用できるようになりました。認証情報が不要になったことで、ユーザーの手間が減り、リスクも低減されました。プロセスを自動化したことで管理・運用コストが削減され、管理者は何もする必要がなくなりました。このシングルサインオンと自動化という2つの要素により、セキュリティが大幅に向上しました。これが非常にスケーラブルなソリューションであることは誰の目にも明らかです。
私たちは6週間の予定でユーザーの移行を計画しましたが、実際には4週間で実装を完了することができました。これは、これらが本当にエンタープライズレベルのサービスであり、優れたスケーラビリティと統合性を持つだけでなく、セキュリティや機密データを扱う際のストレスを大幅に軽減できることを示しています。新しいソリューションへの移行には、ユーザーの協力が必要でした。7つか8つの異なるツールのセットアップ方法について、包括的な情報を提供する必要がありました。Pythonは一例に過ぎず、データグループ、Amazon SageMaker、そしてAmazon Redshiftに接続する様々なツールがあります。Amazon Redshiftで機密データを扱うための作業手順を提供し、それを4週間で完了しました。
次のステップは何でしょうか？すべてが完了したわけではありませんし、これからも完了することはないでしょう。だからこそ、私はリアルタイムのフィードバックを得るためにここにいます。これは継続的な旅なのです。また、このソリューションをサブタイプのソリューションやロールベースのアクセスとしても活用したいと考えています。現時点ではそれができませんが、AWSがその解決策に取り組んでいます。特にLas Vegasにいる時は、信頼しつつも検証が必要です。
新しいデータセットをチェックし、機密データか非機密データかを評価するジョブを実行しています。これにより、機密データに特化したロールを提供することができます。常にフィードバックを求めていますので、ご意見をお待ちしています。Szymonさん、共有ありがとうございました。
ユーザー認識型データアクセスの詳細と実装手順
Szymonが言及したように、これは魔法のように見えますので、その魔法が実際にどのように機能するのかを探っていきましょう。 私の願いは、皆さんがこれを実装し、私たちがどこに向かっているのかを理解できるようになることです。ユーザー認識型データアクセスに直接入っていきますと、IAM Identity Centerのセットアップ、データサービスのIAM Identity Centerへの接続、Picklesのようなユーザーコンテキストをサービス間で受け渡せるようにすること、そして特定のデータアクセスの監査が必要になります。
本日のデモで扱うシナリオについてご説明します。従業員のPicklesさんが、Amazon Redshift Query Editorを使用します。Amazon Redshiftには、アクセス制御が設定されたローカルテーブルと、AWS Lake Formationから提供されるFederatedテーブルがあります。Lake Formationが作成するテーブルのデータは、Amazon S3に保存されています。各レイヤーで、Amazon RedshiftはPicklesさんの詳細情報を取得し、その行動を記録し、Picklesさんの情報を受け渡します。これらはすべて、Identity Provider、IAM Identity Center、そしてこれらのアプリケーション間の連携によって実現されています。
ユーザー認識型アクセスのためのデータアプリケーションのセットアップと設定では、まずアプリケーションをIAM Identity Centerに接続する必要があります。それぞれのアプリケーションを接続し、ユーザーとグループを割り当てます。今回の例では、Amazon RedshiftとLake Formationを使用し、Trusted Identity Propagationを通じて各アプリケーションを連携させます。Trusted Identity Propagationを機能させるには、Amazon RedshiftがLake Formationを呼び出すためのロールを定義する必要があります。標準的なロールを使用しますが、今回はユーザーの認証情報を付加します。
Amazon Redshiftでの設定画面をリアルタイムでお見せしましょう。Identity Center統合に移動し、Trusted Identity PropagationのためにLake Formationでもロールの確認が必要になります。Lake Formationでも同様の連携設定を行います。 このデモでは、私が管理者として操作をお見せします。これは管理アカウントでの画面です。ここにすべてのアプリケーションが表示されており、将来のデモのヒントも見えます。シングルサインオン用のAmazon Redshift Query Editor、ローカルデータ用のAmazon Redshift本体、そしてLake FormationとAWS Glueがあります。
接続されたアプリケーションが表示されています。申し訳ありません、先ほどボタンを押し忘れました - 次回は指摘してください。では、データ管理用アカウントに移動します。今日は主にこのアカウントで管理者として作業を行い、Lake FormationとAmazon Redshiftのセットアップをお見せします。 Amazon Redshiftでは、このように進み、IAM Identity Center接続を行います。ここでロールとLake FormationへのTrusted Propagationが確認できます。 Lake Formationでも同様に、ここでIdentityの設定を行います。IAM Identity Center統合をお見せしましょう。
また、今日は「おやつ」についても触れる予定です。馬用のおやつと人間用のおやつがあります。 そして、Redshiftが使用するロールについてもお見せしたいと思います。ここで権限が設定されているのが確認できます。 Redshiftへの権限があり、さらにIAM Identity Center（Single Sign-on）に対する権限も持っています。 インスタンスの詳細確認などの権限や、AWS GlueとAWS Lake Formationを呼び出すための同様の権限も設定されています。
では、始める前のセットアップについて説明しましょう。この図を実現するために、2つのチェックボックスを完了しました。その役割は、上に3が書かれた黄色い線でした。パート1はサービスです。サービスは認証情報を取得し、それはユーザーを認識できる認証情報として、AWSでロールとしてユーザー認識機能を持って動作します。これは、PicklesがRedshift Query Editorにログインした場合のIAM Identity Centerトークンか、RedshiftがLake Formationを呼び出してユーザーコンテキストを付与したIAMロールのいずれかになります。
サービスがこの認証情報を取得すると、3つのことを行います。まず、ユーザーセッションを確認します - Picklesのセッションはまだ有効か、Picklesはまだ従業員かどうかを確認します。次に、ユーザーを特定します。Picklesの情報を取得し、そしてグループ情報を返します。Picklesは馬なので、その情報をRedshiftに送り返します。この時点で、RedshiftはPicklesが依然としてPicklesであり、牧場の馬であることを認識します。そして、Redshiftはそれに基づいて判断を下すことができます。
これらの判断において、まずユーザーについて説明します。各サービスには、サービス固有のアクセス制御がある場合があります。これはデータに関して特に重要です。アクセスを定義する必要のあるローカルテーブルがあるかもしれませんし、Lake Formationの場合は、アクセスを定義する必要のある連携テーブルがあるでしょう。Redshiftはそれを行い、さらにアクセスをログに記録します。そのログは、どちらのデモを先に見るかによってPicklesまたはBridgetとして記録されます。
ここで、セッションの最後にプレゼントを用意していることをお伝えしたいと思います。クイズがあり、このスライドはそのクイズにとても重要です。これからRedshiftに移動します。実は、管理者のBridgetとしてログインします。最初にアクセス制御をお見せし、その後でPicklesの例をお見せします。
データベース管理者として接続します。その理由はデータアクセス制御のためです。アクセス制御テーブルをお見せしたいと思います。馬のユーザーがoutfitスキーマにアクセスできることが確認できます。
それでは Pickles に移りたいと思います。Firefox を使用していますが、私も Firefox で Pickles を開いています。これが Pickles の最初のインスタンスですが、今後さらに多くの Pickles を見ることになります。Pickles は Okta 内のユーザーでもあります。これは IAM Identity Center が提供するアクセスポータルで、Pickles が Redshift Query Editor にアクセスできることが確認できます。 今はローカルテーブルの部分だけを見ています。先ほどキャッシュの問題があったので、問題を避けるために接続を一度削除しようと思います。
これが私たちのローカルテーブルで、先ほど見たアクセス制御に基づいて、Pickles はこれにアクセスできるはずです。 このデモの練習をしていたのですが、ご覧の通り Pickles は毛布や保冷バッグ、そして農夫のズボンを着用できることがわかりました。これはとても素晴らしいですね。
CloudTrailを用いたアクセスログの確認とユーザー認識の検証
管理者として最後にお見せしたいのがログです。デモが確実に動作するように、私が何度も練習したことが分かります。ログを見ていくと、基本的に Bridget と Pickles がたくさん表示されているのが分かります。これらは Amazon Redshift のログで、 ここでクエリを実行できます。 そして、Pickles がズボンを履けることが分かりました。素晴らしいですよね？
これまではすべてローカルテーブルの話で、IAM Identity Center とそのトークン、そしてユーザー認識に基づいて接続してきました。 次は、このアイデンティティの受け渡しについて説明します。これは Amazon Redshift が AWS Lake Formation と統合することで自動的に行われますが、後で重要になるので理解しておく必要があります。Amazon Redshift にはユーザーがいて、Pickles としてログインしています。次に、下流に渡す必要があるため、IAM Identity Center にユーザーコンテキストを問い合わせます。その後、ユーザーコンテキストを含むロールを引き受け、ロールの認証情報を取得し、その認証情報を使って Lake Formation を呼び出します。Lake Formation は、ユーザーコンテキストが付加されたロールの認証情報を確認し、Pickles のアクセスを記録します。
なぜこれが私のお気に入りのスライドなのでしょうか？それは、Amazon Redshift から Lake Formation を呼び出すためにロールを使用しているからです。つまり、セキュリティガードレール、そしてこれまで何年もかけて構築してきたロールに関する設定がすべて有効です。それらの権限は引き続き尊重されます。アクセスを制限したい場合は、サービスコントロールポリシーでアクセスを制限することもできます。これこそが美しいソリューションである理由です。お客様がよく躓くポイントがありますので、大声で言わせていただきます。先ほど見た Amazon Redshift のロールが次のサービスである Lake Formation にコンテキストを渡す必要がある場合、信頼ポリシーで STS set context の権限を持っている必要があります。
そして Lake Formation は、ユーザーコンテキストを持つユーザー認識クレデンシャルロールを取得し、AWS CloudTrail にログを記録するのに十分な情報を持つことになります。Amazon Redshift では Redshift アクセスログがあり、Lake Formation では CloudTrail があるので、誰がアクセスしたかを確認することができます。 では、Pickles がキャンディコーンが好きかどうかを確認してみましょう。Lake Formation でのデータアクセスを表示し、Federated テーブルからデータをクエリし、Bridget と Pickles を行き来してアクセスの様子を見せ、そしてログを確認してみます。
まず最初に、管理者の Bridget になって、 IAM Identity Center と信頼された ID 伝播について話しているので、当然の理由として IAM Identity Center への接続をレベルアップします。 Lake Formation でそれを行っている間、ここにあるテーブルにはいくつかのデータ権限があり、これはプリンシパルに基づいています。 ここで見ると、あるプリンシパルは馬用のお菓子に対して describe、add、select の権限を持ち、人間用のお菓子に対しては describe と select の権限を持っています。これは私、つまり Bridget のことです。馬用のものについては何でもできて、キャンディコーンを追加することもできます。また、馬は私たちが今のところ「食べる」と呼ぶものを describe できて、何を食べるかを select できます。このプリンシパルは人間用のお菓子も見ることはできますが、それについてあまり多くの情報は得られないようになっています。
ここでは基本的にポジティブなケースを示したいと思います。Bridget の好きなデザートが何かを見ることができます。 実は私の好きなデザートではないものもありますが、アイスクリームとブラウニーは間違いなく最高です。
Pickles にあげるヘイキューブを取りに行く必要があります。では Firefox で Pickles に戻りましょう。 Pickles の衣装はローカルテーブルでしたが、これは Federated テーブルです。Pickles は自分のお菓子を見たり食べたりできるはずでしょうか？ 接続を削除して、もう一度接続し直す必要がありそうです。申し訳ありません。 キャッシュに何か残っているようです。 もう一度試してみましょう。うまくいかない場合は、ビデオでお見せします。くるくる回っているのは、通常うまくいく兆候です。
できました。 Pickles が食べられるすべての馬用のお菓子が見えます。面白いことに、キャンディコーンはまだ入っていません。これはどうでしょう？ これは実際には権限不足となるはずです。これは良いことです。なぜなら、そうあってほしかったからです。CloudTrail を見てみませんか？ CloudTrail に戻りましょう。CloudTrail を開いて、 Lake Formation で何が起こったかをお見せします。イベント履歴に移動して、 イベント名を見ます。get data access を選択して、今はその一つだけをお見せします。
ご覧のように、これはhorseテーブルへのアクセスを試みていたPicklesの成功した実行例です。こちらにエラーコードを示す便利なカラムがあります。今日早くに作成したアクセス拒否エラーもいくつか表示されています。人間とPicklesの両方について、失敗したものと成功したものの両方が確認できます。多くのことを見てきましたが、クエリ内ではPicklesは常にPicklesとして扱われ、Picklesのアクセス制御は常にhorseに基づいていました - これは彼のグループメンバーシップによるものです。
ここまでたくさんのことを見てきました。とてもエキサイティングでしたね。そして、各ステップでPicklesの動きを確認することができました。ユーザー認識型データアクセスについて振り返ってみましょう。各アプリケーションはIAM Identity Centerに接続する必要があります。各サービスは、ロールを使用してダウンストリームサービスに接続する必要があります。私たちが重視しているTrusted identity propagationによって、このユーザーコンテキストをサービス間で受け渡すことが可能になります。パス上の各サービスは、Picklesの詳細を取得し、使用し、ログに記録し、次のサービスに渡します。これにより、皆さんは順調に進めることができます。
サードパーティアプリケーションとAmazon Q for Businessの統合
では、サードパーティの場合はどうなるのでしょうか？AWS管理サービス間では、自動的に処理されます。これは素晴らしいことですね。サードパーティの場合はどうでしょうか？サードパーティには興味深い特徴があります - それはIdentity Providerトークンを持っているということです。必要なのは、このトークンをロールクレデンシャルに変換することです。なぜなら、そのサードパーティはAtheneを呼び出し、Lake Formationを呼び出し、S3 access grantsを呼び出したいからです。これはどのように実現されるのでしょうか？Identity内にTrusted token issuerを作成し、Identity Providerを信頼することを宣言します。このアプリケーション、つまりサードパーティを信頼するわけです。これにより、サードパーティは自身のIdentity ProviderトークンでIAM Identity Centerトークンを要求できます。Identity Centerは「はい、あなたを信頼します」と応答し、サードパーティはユーザーコンテキストを取得できます。まるでサービスがユーザーコンテキストを持つロールを引き受け、ユーザーコンテキストを持つIAMロールクレデンシャルを取得するように。その後、Athenaに渡すことができ、黄色いボックスのPicklesは、Athena、Lake Formation、S3 Access grantsに存在することになります。
TrustとToken issuerについて、もう少し詳しく説明しましょう。これは生成AIで必要になるからです。これはIdentity Providerとの信頼関係を確立するために使用されます。IAM Identity Centerインスタンスと特定のサードパーティアプリケーションは、同じIdentity Providerで構成される必要があります。異なるものを使用して動作させようとすることはできません - 同じものでなければなりません。セットアップするには、サードパーティアプリケーションをIAM Identity Centerに接続し、Issuer URLを設定し、メールアドレスとメールアドレスが一致するようにアトリビュートマッピングを行います。これが実際の画面です。IAM Identity Centerに移動し、Trusted token issuerを作成します。下部にOktaが表示され、さらにアトリビュートマッピングでメールからメールへのマッピングが確認できます。時間があれば、これらの画面をもう少し詳しく見ていきましょう。さて、ここまでデータ分析とユーザー認識について深く掘り下げてきました。
ここで、生成AIに関連する点をつなげてみましょう。私たちにはAmazon Q for businessがあります。Amazon Q for businessは、ワークフォースアプリケーションをAmazon Qでパワーアップするのに最適です。Amazon Qでパワーアップする際は、Picklesが質問をする時に、アクセス権のあるデータについてのみ質問できるようにする必要があります。Picklesのチャット履歴に基づいてパーソナライズされていることを確認する必要があります。これらすべてがAmazon Q Businessで実現されます。また、ガードレールが引き続き有効であることを確認し、40の一般的なエンタープライズアプリケーションへの接続を提供します。
このように見えます。上部にデータソースがあります。今日のデモでは S3バケットについて説明し、そしてQがその素晴らしい機能を発揮します。Identity Centerと連携してユーザーとグループのコンテキストを取得できます。ユーザーのPicklesがWorkforce Applicationで認証を行い、チャットボット機能を使用すると、Picklesとして振る舞います。すべてが順調に進めば、Picklesは自分のおやつについて話すことができ、人間用のおやつや世の中の他のものについては話さないはずです。
このような仕組みになっています。Amazon Qを利用して動作させたいWorkforce Application（紫色のボックス）があり、そしてPicklesがいます。Picklesはそのワークフォースアプリケーションで認証を済ませています。このWorkforce Applicationは何を持っているでしょうか？Identity Providerトークンを持っています。Amazon Qを呼び出すには何が必要でしょうか？IAMロールの認証情報です。Workforce ApplicationはIdentity Providerトークンを持ち、信頼関係があるのでIdentity Centerトークンをリクエストし、ユーザーコンテキストを取得します。その後、Workforce Applicationはユーザーコンテキストを使用してロールを引き受け、Amazon Qを呼び出すためのIAMロール認証情報を取得します。
これはどのように機能するのでしょうか？両方のWorkforce ApplicationがIdentity Centerに接続されている必要があります。Workforce ApplicationとQ Business Applicationの両方がIdentity Centerに接続されている必要があります。Trust and Token Issuerが必要で、Workforce Applicationが持っているIdentity ProviderトークンでIDCトークンを取得する際に、この信頼関係のダンスが行われます。これが私たちの目標です。Picklesは自分が選べるおやつの選択肢を見つけようとします。リンゴもその一つかもしれません。設定手順を説明していきますが、Picklesに関するアプリケーションを用意しています。
これが本日最後のデモです。Amazon Q for Businessを開いてみましょう。Q Businessに移動すると、アプリケーションが表示されるはずです。実は少し面白い名前のアプリケーションで、Sweet Treatsアプリケーションと呼んでいます。チャット機能やアクセス権、アプリケーション名などが表示されています。より興味深いのは、実際にIdentity Centerに表示される内容です。組織の管理アカウントに戻って確認してみましょう。というのも、これを設定しようとする際に覚えておいていただきたいのは、両方のアプリケーションをそこで設定する必要があるということです。
アプリケーションに移動すると、先ほど見たように、Q Business Application Suite Treatsとその他のQ Businessアプリケーションが表示されます。これら両方を接続する必要があります。また、ここではユーザーとグループも確認できます。人間のユーザーも馬のユーザーもこのアプリケーションを使用できます。
このアプリケーションをご覧になりたいですか？デモをお見せしましょう。こちらが私たちのアプリケーションのリンクです。私はPicklesとしてログインします。すでにOktaで認証を済ませていることにお気づきでしょう。では、Web UIに移動して質問を始めてみましょう。Picklesはアイスクリームをもらえるでしょうか？以前テストしていた内容が表示されているのがお分かりですね。このチャットボットは何と答えると思いますか？答えが見つからない、でしょうか？Picklesがアクセスできるものを見てみましょう。はい、ここにすべてのおやつが文章形式で表示されています。面白いですよね？
次にPicklesはリンゴについて気になっているようです。おやつの種類がリンゴであることが分かります。おやつには2種類の形態があり、フレーバービスケットの形で提供されます。実は何度か実行してみましたが、答えは毎回異なります。では、Picklesがキャンディーコーンを好むかどうか確認してみましょう。チャットボットの回答を見てみましょう。データに含まれていなかったので、答えは見つかりませんでした。アイスクリームはデータにありましたが、Picklesはアイスクリームに関する情報を得られませんでした。これが最初の質問でしたね。キャンディーコーンはデータセットのどこにもありませんでした。このように、Picklesは常にPicklesとして一貫性を保っていることが分かります。
まとめと今後の展望：User-awareなAWSの継続的な進化
では、チートシートをお渡しします。メモを取って持ち帰る必要がある項目をご紹介します。まず第一に、ユーザー認識型データアクセスとパーソナライゼーションを可能にするために、Identity ProviderをIAM Identity Centerに接続します。データ分析とGenerative AIアプリケーションをIAM Identity Centerに接続します。Trusted Identity Propagationを使用して、Picklesが常にPicklesであることを確認します。Third-party Credentialの連携を実現するためにTrusted Token Issuerを使用します。AWS CloudTrailとサービスログを使用してデータアクセスを追跡し、User-aware AWSの最新情報をキャッチアップしましょう。
これは私たちが進めている旅路です。どんどん機能を追加していきます。時には明確に言及し、時には言及しませんが、IAM Identity Center統合について話すときは、必ずUser-awareを思い浮かべてください。そして、これは勝利です - Picklesの勝利です。これは継続的な旅路なので、私たちは何度も繰り返し話し合い、さらに拡張していきます。AWS re:Forceでもお話しできることを願っています。
デモは常に新しく、フレッシュなものに更新していきます。Szymonには壇上に来ていただき、ありがとうございました。そして皆様にも感謝申し上げます。アンケートへのご協力をお願いします。私はすべてのコメントを読ませていただきます。すべてのフィードバックに目を通し、年々成長するための糧としています。月曜日にこのセッションにお越しいただき、本当にありがとうございます。質問がある方は、こちらでお待ちしています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion