※本記事は、2024年2月12日に開催されたAWS re:Invent 2024のセッション「The AI efficiency edge: Empowering your teams with Okta & Amazon Q (SEC209)」の内容を基に作成されています。セッションの詳細情報はhttps://www.youtube.com/watch?v=JSz2dOnFUwY でご覧いただけます。本記事では、セッションの内容を要約しております。

なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご覧いただくことをお勧めいたします。

AWSのイベント情報については、https://go.aws/3kss9CP をご参照ください。また、より多くのAWSに関する動画コンテンツは、http://bit.ly/2O3zS75 でご覧いただけます。

登壇者紹介： Wayne Smiley氏は、Oktaのアライアンスチームでシニアソリューションエンジニアとして活躍しています。主にAWSとOktaの連携に関する技術的なソリューションの開発と実装を担当しており、長年にわたりアイデンティティ管理の分野で豊富な経験を積んできました。本セッションでは、OktaとAmazon Q Businessの統合による革新的なアクセス管理ソリューションについて、実践的な知見を共有しています。

1. イントロダクション

1.1. 発表者の紹介

おはようございます。私はWayne Smileyと申します。Oktaのアライアンスチームでシニアソリューションエンジニアを務めています。私の日常業務は、主にAWSとOktaがどのように連携するかに焦点を当てています。

今日は私たちが全く聞いたことのないような新しいものについて話すつもりです...冗談です。実はAIについて話します。これは最近非常に注目を集めているトピックですが、それには理由があります。確かに過剰な期待が寄せられている面もありますが、実際の価値も確かに存在しているのです。

私は今日、特にAmazon Qについてはあまりたくさんのことは話しません。デモの中で少し触れる程度になると思います。その代わりに、OktaとQ Business、そしてQ Developerがどのように相互に補完し合って、より良いソリューションを生み出すことができるのかについて、重点的にお話ししたいと思います。

1.2. プレゼンテーションの目的

私たちは今日、OktaとAmazon Q Businessの統合について、3つの重要な観点から説明していきます：より良く（Better）、より安全に（Safer）、そしてより簡単に（Easier）です。

以前、私の上司がよく言っていた言葉があります。「良い（good）、速い（fast）、安い（cheap）の3つのうち、2つしか選べない」というものです。しかし、今日ご紹介する統合では、これら3つすべてを実現することができます。

私たちが目指しているのは、Amazon Qが使用するRAG（Retrieval-Augmented Generation）のためのデータに対して、適切なユーザーが適切なアクセス権を持つことを確実にすることです。これはHRシステムなどの信頼できるソースからリアルタイムでデータを取得することで実現します。

Amazon Q Businessの開発において一つの課題となっているのが、Identity Centerの使用です。私たちITの専門家にとっては、数回余分にクリックする必要があっても問題ありません。しかし、エンドユーザーにとってはそうではありません。また、ヘルプデスクの担当者にとってもこれは悩みの種です。OktaとAmazon Qの統合は、このような課題を解決し、より効率的で使いやすいシステムを提供することを目的としています。

Q Businessは素晴らしいツールです。私も常日頃から使用していて、非常に気に入っています。実際、Oktaでも全社的に使用できればと思っているほどです。これにより、様々な異なるシステムを統合し、すべてを一つにまとめることができます。本日は、このような統合がもたらす価値と、それを実現するための具体的な方法についてご説明していきます。

2. Okta と Amazon Q の統合の利点

2.1. より良い統合（Better）

OktaとAmazon Qの統合において、最も重要な利点の一つは、ユーザーアクセス管理の適切な制御です。これは単なるアクセス管理以上の価値を提供します。

例えば、私が営業部門に所属している場合と、妻がマーケティング部門に所属している場合、同じ質問をAmazon Qにしても、異なる回答が得られるようになります。これは、それぞれの部門で必要とされる情報やアクセス権限が異なるためです。

この統合の重要な特徴は、HRシステムなどの信頼できるソースからのデータをリアルタイムで活用できることです。人事異動や役割の変更があった場合、それらの変更は自動的にシステムに反映されます。新規採用、退職、役割の変更など、あらゆる人事異動に対して、システムは自動的に対応します。

私自身の経験を例に挙げると、以前はIT部門で15年間働いていましたが、その後プリセールスに異動しました。当時、私はドメイン管理者やExchange管理者など、様々な権限を持っていました。現在ではそのような広範な権限の付与は考えられませんが、当時はそうでした。このような場合、人事部門での一度の変更により、これらの権限を自動的に適切に調整することができます。

このように、OktaとAmazon Qの統合は、単なるアクセス管理システムではなく、組織の変化に柔軟に対応し、適切な情報アクセスを確実に提供する包括的なソリューションとなっています。

2.2. より安全な統合（Safer）

セキュリティは、OktaとAmazon Qの統合における重要な柱の一つです。私たちは、フィッシング耐性のある多要素認証を実装することで、高度なセキュリティを確保しています。これにより、ログインしようとしているユーザーが本当に本人であることを確実に確認でき、盗難された認証情報などによる不正アクセスを防止することができます。

セキュリティの実装において、私たちは2つの重要な要素に注目しています。一つはデバイストラストで、アクセスしているデバイスが実際にそのユーザーに属していることを確認し、想定されたデバイスであることを検証します。もう一つはユーザートラストで、アクセスしているユーザーの信頼性を確保します。

この組み合わせにより、単なるパスワード認証を超えた、より強固なセキュリティ基盤を提供することができます。これは後ほどデモでもお見せしますが、例えばMacBookでの指紋認証を使用したログインなど、ユーザーフレンドリーでありながらも高度なセキュリティを実現する方法を実装しています。

このような多層的なセキュリティアプローチは、特に機密性の高い情報や重要なビジネスデータを扱う環境において、不可欠な要素となっています。

2.3. より簡単な統合（Easier）

Amazon Q Businessの開発において、私たちが直面している一つの課題は、AWS Identity Centerの複雑さです。私自身、長年ITに携わってきた者として、いくつかの追加クリックや操作手順は気になりません。しかし、エンドユーザーにとっては、これは大きな課題となっています。また、ヘルプデスクのスタッフにとっても、この複雑さは業務の効率を低下させる要因となっています。

OktaとAmazon Qの統合により、これらの課題を解決することができます。従来のように様々なシステムを行き来する必要はありません。例えば、現在システムを使用している場合、ユーザーは複数のステップを経てIdentity Centerを通じてアクセスする必要があります。これは技術者である私たちにとっては問題ありませんが、一般のユーザーにとっては煩雑な作業となっています。

私たちの統合ソリューションでは、ユーザーはOktaにログインするだけで、他のすべてのアプリケーションと同じように直接Amazon Qにアクセスすることができます。すべての処理は期待通りに動作し、バックグラウンドで適切に処理されます。これは、アプリケーションのRAGで使用する他のデータソース（Zoom、Slackなど）についても同様です。これらすべてがOktaを通じて自動化され、シームレスに統合されています。

このように、私たちのアプローチは「良い意味での怠惰さ」を可能にします。一度設定してしまえば、その後は考える必要もありません。これこそが、私たちが目指す真の統合の姿なのです。

3. 実際のユースケース

3.1. セールスチームでの活用例

展示会フロアでの実際の経験をお話ししましょう。顧客が来場した際に、その顧客の担当営業を素早く特定する必要がありました。従来の方法では、スマートフォンでSalesforceにアクセスし、担当者を探すのに約5分かかっていました。

しかし、Amazon Qを活用することで、この作業を大幅に効率化することができます。単純に「企業Xの担当者は誰ですか？」とQに質問するだけで、Qが自動的にSalesforceのデータにアクセスして、即座に回答を提供してくれます。

このような効率化は営業活動だけでなく、福利厚生に関する質問への対応など、他の業務領域でも実現可能です。Q Businessは素晴らしいツールで、私は日常的にこれを使用しています。実際、Oktaでも全社的に導入できればと考えているほどです。

重要な点は、このようなアクセスが役割ベースで適切に制御されているということです。私が営業部門にいる場合と、他の部門の社員が同じ質問をした場合では、それぞれの役割に応じて異なる回答が提供されます。これにより、情報セキュリティを維持しながら、業務効率を最大化することができます。これは後ほどのデモンストレーションでも、同じ質問に対する異なる回答例をお見せする予定です。

3.2. 部門間でのアクセス権限の違い

私たちのシステムでは、同じ質問をしても、ユーザーの役割に応じて異なる回答が得られるように設計されています。これは、情報セキュリティと業務効率の両立を実現する重要な機能です。

例えば、私が営業部門に所属し、妻がマーケティング部門に所属している場合、同じ質問をしても異なる回答が返ってきます。これは、各部門で必要とされる情報の範囲や、アクセスが許可されるべきデータが異なるためです。この違いは、後ほどのデモンストレーションでも具体的にお見せする予定です。

特に機密性の高いプロジェクト情報へのアクセスについては、厳格な制御が実装されています。例えば、「Project Gandalf」という秘密プロジェクトについて、一般社員やヘルプデスク担当者が質問しても情報は得られませんが、プロジェクトに関与することを承認されたIT管理者は、必要な情報にアクセスすることができます。

このようなロールベースのアクセス制御により、各部門のニーズに応じた適切な情報提供と、セキュリティ要件の両立を実現しています。これは単なる情報の制限ではなく、各部門が必要とする情報に効率的にアクセスできるようにすることで、業務効率の向上にも貢献しています。

3.3. コスト最適化の方法

コスト管理の観点からも、OktaとAmazon Qの統合は大きな価値を提供します。Amazon Q Businessのライセンスは、私の記憶では1ユーザーあたり月額3ドルから20ドルほどです。この金額に関しては正確な数字でない可能性がありますが、コスト管理の重要性を示す良い例となります。

コスト最適化のために、私たちは全社員にQ Businessのライセンスを付与するのではなく、必要なユーザーにのみ提供する方針を取ることができます。その上で、追加でアクセスが必要になったユーザーのために、セルフサービスのリクエストプロセスを用意しています。

定期的な利用状況の確認も重要な施策です。アテステーション（証明）プロセスを通じて、実際のライセンスの使用状況を監視することができます。使用していないユーザーにライセンスを付与し続けることは、無駄なコストとなります。私たちのシステムでは、誰がQ Businessに実際にログインしているかを追跡し、レポートを生成することができます。

また、管理者に対して定期的にレポートを送信し、「Wayneはもうこのアクセス権が必要ないですね」といった判断を可能にします。このような定期的なレビューと最適化により、必要なユーザーに必要なアクセス権を提供しながら、コストを適切に管理することができます。これらの機能は、すべてOktaを通じて自動化されており、効率的なライセンス管理を実現しています。

4. 技術的な統合方法

4.1. AWS IAM Identity Centerを通じた統合

ここでは、30秒ほど技術的な説明をさせていただきます。私たちのOktaとAmazon Qの統合は、実際には2つの方法で実現できます。その一つがAWS IAM Identity Center（以前はAWS SSOとして知られていました）を通じた統合です。

Identity Centerを使用した統合には大きな利点があります。実際、AWSの製品管理者との会話の中でも、Identity Centerを使用することで彼らのサイドで大きなメリットがあることを確認しています。ただし、このアプローチは一般のユーザーにとっては若干複雑に感じられる場合があります。これは私たちIT担当者にとっては問題ありませんが、エンドユーザーには追加のクリックや操作が必要となります。

しかし、OktaとIdentity Centerの統合により、この複雑さを大幅に軽減することができます。ユーザーはOktaダッシュボードから直接Amazon Qにアクセスでき、バックグラウンドでIdentity Centerの認証が自動的に処理されます。これにより、技術的な統合の利点を維持しながら、ユーザー体験を向上させることができます。

私たちが多くの顧客から受ける質問の一つは、既存のフェデレーション環境を維持しながらIdentity Centerを使用できるかということです。この答えは「はい」です。Oktaを使用することで、両方の統合方式を同時に利用することが可能です。これについては、次のセクションで詳しく説明させていただきます。

4.2. IAM Federationを通じた統合

IAM Federation統合は、Identity Centerと並ぶもう一つの重要な統合オプションです。これは従来からAWSへのアクセスに広く使用されてきた方法です。多くのOktaのお客様は、AWS環境へのアクセスにすでにこのフェデレーション方式を利用しています。

私たちがよく受ける質問の一つは、「現在IAM Federationを使用しているが、これを続けることはできるか？」というものです。答えは「はい」です。Oktaを使用している場合、既存のフェデレーション統合を維持したまま、Amazon Qのために別途Identity Centerを使用することが可能です。

実際、AWSの製品管理者との話し合いの中で、彼らからIdentity Centerを使用することには大きな利点があると聞いています。しかし、これは既存のフェデレーション統合を廃止する必要があるということではありません。Oktaの重要な特徴の一つは、両方の統合方式を同時にサポートできることです。

顧客は自身のニーズに応じて、AWS環境へのアクセスにはIAM Federationを使用し、Amazon QへのアクセスにはIdentity Centerを使用するといった柔軟な構成を選択することができます。これにより、既存の投資を保護しながら、新しいテクノロジーの利点を活用することが可能になります。この柔軟性こそが、Oktaの統合アプローチの核心です。

4.3. ハイブリッド統合の可能性

Oktaの重要な特徴の一つは、両方の統合方式を同時にサポートできることです。多くのお客様からよく受ける質問の一つが、「Oktaを使用していて、AWSとの統合にFederationを使用している場合、そのまま継続できますか？」というものです。その答えは「はい」です。既存のFederation統合を維持したまま、Amazon QのためにIdentity Centerを使用することが可能です。

実際、多くのお客様がこの方法を採用しています。AWSの製品管理者と話をする中で、彼らの側からもIdentity Centerを使用することには大きな利点があると聞いています。Federationと比較した場合、Identity Centerには彼らのサイドで重要なメリットがあるとのことです。

さらに、複数のAWSアカウントを持っている場合でも、柔軟な構成が可能です。一部のアカウントではIdentity Centerを使用し、別のアカウントではFederationを使用する、あるいは両方の方式を同時に使用するなど、様々な組み合わせに対応できます。これはOktaの基本的な考え方の一つでもあります。

このような柔軟性により、お客様は既存のインフラストラクチャへの投資を保護しながら、新しいテクノロジーの利点を活用することができます。これは特に大規模な組織や、複雑なAWS環境を持つ組織にとって重要な利点となっています。

5. デモンストレーション

5.1. 新入社員（Jennifer Jones）のケース

それでは、新入社員のJennifer Jonesさんのケースをデモンストレーションしてみましょう。まず、Jenniferが初めてシステムにログインする様子をお見せします。

Jenniferは、Okta Verifyを使用してログインを行います。彼女はMacBookを使用しており、指紋認証リーダーで認証を行います。これにより、非常にスムーズかつ安全にログインすることができます。ログイン後、彼女のOktaダッシュボードが表示され、そこからAmazon Q Businessのアイコンをクリックするだけで、直接アクセスが可能です。追加の認証や複雑な手順は必要ありません。

新入社員として、Jenniferは基本的な業務に必要な情報へのアクセスを求めています。例えば、メールの設定方法について質問すると、ITチームが用意した文書から適切な情報が抽出され、要約されて表示されます。具体的には、ラップトップやスマートフォンでのメールの設定方法が、わかりやすい手順で提示されます。また、参考となる文書へのリンクも提供され、必要に応じて詳細な情報を確認することもできます。

しかし、メールボックスの容量が早くも限界に達した際の対応方法を尋ねると、一般的なエンドユーザー向けの回答が提供されます。「ITサービスにチャットで連絡してください」といった基本的な案内が表示されるのみです。

さらに興味深いのは、社内で話題になっている秘密プロジェクトについて質問した場合です。彼女は新入社員として、このプロジェクトについて何も情報を得ることができません。「Project Gandalf」と具体的な名前を指定して質問しても、アクセス権限がないため、一切の情報は表示されません。これは、役割ベースのアクセス制御が適切に機能していることを示しています。

このように、新入社員のケースでは、基本的な業務に必要な情報へのアクセスは保証されながら、機密情報や特定の権限が必要な情報へのアクセスは適切に制限されています。

5.2. ITヘルプデスク担当者（Emily）のケース

次に、ITヘルプデスク担当者のEmilyのケースをお見せします。Emilyは、Q Businessを使って業務をより効率的に行おうとしています。Oktaは彼女をIT Ops部門のメンバーとして認識しているため、一般ユーザーのJenniferとは異なるレベルの情報にアクセスできます。

Emilyは、チケットの中でエラーコード123について多くの問い合わせを受けています。彼女は基本的なヘルプデスク担当者として、このエラーコードについて詳しくありません。Amazon Qに問い合わせると、このエラーコード123がデータセンターの電源障害に関連していることがわかります。この情報は10ページほどの文書から自動的に要約されたものです。

しかし、Emilyはデータセンターと同じオフィスにいないため、この問題に直接対応することができません。そこで彼女は、このケースのエスカレーション方法について質問します。ここで興味深いのは、私がエスカレーションのスペルを間違えて入力しても、システムが正しく理解してくれることです。また、システムは先ほどのエラーコード123の文脈を維持しており、そのエラーに特化したエスカレーションプロセスを案内してくれます。

新入社員の「愚かなブーマー世代が毎日メールボックスを一杯にしている」というケースにも対応する必要があります。Emilyが同じメールボックス容量の増設について質問すると、先ほどのJenniferとは異なり、IT運用部門向けの詳細な手順が表示されます。これは長い文書が適切に要約されたものです。

さらに、Emilyは同僚が「Project Gandalf」に取り組んでいることを知っており、プロジェクトの名前を指定して質問してみます。しかし、彼女のアクセス権限レベルでは、このプロジェクトに関する情報は一切表示されません。何度質問を変えて試みても、情報にアクセスすることはできません。これは情報セキュリティが適切に機能していることを示しています。

5.3. ITマネージャー（Jean-Luc）のケース

最後に、ITマネージャーのJean-Lucのケースをご紹介します。Jean-Lucは先ほどCIOから、「Project Gandalf」に参加することを伝えられ、このプロジェクトへのアクセス権限が付与されたところです。

ここで興味深いのは、同じ「Project Gandalf」に関する質問に対する応答の違いです。一般社員のJenniferや、ITヘルプデスクのEmilyが質問した際には一切情報が表示されませんでしたが、Jean-Lucが質問すると、プロジェクトの詳細な情報が提供されます。具体的には、「無限のパワーを得るために、ブラックホールの力を活用する」というプロジェクトの本質的な内容が開示されます。これは、AWSにとっても有益なプロジェクトになるかもしれませんね。

このケースは、役職やプロジェクトへの参加資格に応じて、同じ質問に対して異なるレベルの情報が提供される仕組みを明確に示しています。これは単なる情報のフィルタリングではなく、ユーザーの役割や権限に基づいて、適切なレベルの情報が動的に提供される高度なアクセス制御の実例です。

このように、OktaとAmazon Qの統合により、組織の階層構造やプロジェクトの機密性に応じた、きめ細かな情報アクセス制御が可能になっています。これは情報セキュリティの維持と、業務効率の向上を両立させる重要な機能です。

6. セルフサービス機能

6.1. アクセス要求プロセス

ここで、セルフサービスの機能についてご紹介します。Q Businessへのアクセス権限を持っていないユーザーが、アクセスを必要とする場合のプロセスをお見せしましょう。

ユーザーはOktaにログインした後、セルフサービスポータルからアクセス要求を開始することができます。要求プロセスは非常にシンプルで、「Request Access」ボタンをクリックするところから始まります。実際のフォームでは、必要なアクセスのタイプを選択するためのドロップダウンメニューを用意することもできますが、今回のデモでは簡略化したバージョンをお見せします。

申請者は要求フォームに、アクセスが必要な理由を記入します。例えば、「部門でQ Businessの試験運用を始めることになったため、アクセス権限が必要です」といった具体的な理由を記載します。この情報は、承認者が適切な判断を下すための重要な参考情報となります。

このように、私たちは新しい部門がQの利用を検討する際に、簡単かつ効率的な方法でアクセス権限を要求できるプロセスを提供しています。これにより、必要なユーザーが必要なタイミングで適切なアクセス権を取得できる環境を実現しています。

6.2. 承認ワークフロー

アクセス要求が提出されると、承認ワークフローが開始されます。このプロセスでは、複数の承認者が順番に要求を確認し、承認を行います。このワークフローは、組織の要件に応じてカスタマイズすることが可能です。

デモで示したケースでは、アクセス要求を受けて承認プロセスが開始され、それぞれのレベルの承認者が設定されています。承認者は要求の内容、申請理由、そしてビジネス上の必要性を確認し、適切な判断を下します。これにより、無秩序なアクセス権限の付与を防ぎ、コストとセキュリティの適切なバランスを維持することができます。

承認プロセスが完了すると、システムは自動的に次のステップに進みます。このプロセスは透明性が高く、申請者は常に自身の申請のステータスを確認することができます。このように、承認ワークフローは、アクセス権限の付与を効率的かつ安全に管理するための重要な要素となっています。

このワークフローは、私たちのアイデンティティ管理の経験に基づいて設計されています。私は以前、ある企業でアイデンティティ管理を担当していましたが, その経験から、適切に設計された承認プロセスは、「良い意味での怠惰さ」を実現する重要な要素であることを学びました。

6.3. 自動グループ割り当て

承認プロセスが完了すると、私たちのシステムは自動的にグループ割り当てのプロセスを開始します。このプロセスは、ユーザーに適切なアクセス権限を効率的に付与するために重要な役割を果たします。

具体的な流れとしては、まずユーザーが承認されたグループに追加されます。このグループ情報はIdentity Centerと同期され、Identity Centerは自動的にそのグループに基づいてサブスクリプションを割り当てます。これにより、承認されたユーザーは必要なアクセス権限を自動的に取得することができます。

このプロセスでは、システムは自動的にユーザーを適切なグループに追加し、そのグループに基づいて必要な権限が付与されます。例えば、特定の部門やプロジェクトに関連するグループに追加されることで、そのグループに設定された権限に基づいて、必要なリソースへのアクセスが可能になります。

この自動化されたプロセスにより、管理者の手作業を最小限に抑えながら、効率的かつ正確なアクセス権限の管理を実現しています。これは、私が以前から提唱している「良い意味での怠惰さ」を実現する重要な要素の一つです。一度設定してしまえば、あとは自動的に処理されるため、管理者の負担を大幅に軽減することができます。

7. まとめ

7.1. 主要な3つのポイント

本日のプレゼンテーションで覚えていただきたい重要なポイントが3つあります。

第一に、Oktaを通じてAIへのシームレスなアクセスが実現できるということです。ユーザーはOktaにログインするだけで、追加の認証プロセスなしでAmazon Qにアクセスすることができます。これは単なる利便性の向上だけでなく、業務効率の大幅な改善にもつながります。

第二に、私たちの統合ソリューションは、生成AI環境における生産性を向上させます。デモでお見せしたように、異なる役割のユーザーが、それぞれの業務に必要な情報に適切にアクセスできます。例えば、ヘルプデスク担当者は詳細な技術文書にアクセスでき、一般ユーザーは基本的な情報のみを得られるといった、役割に応じた情報提供が可能です。

第三に、セキュリティの強化とユーザー認証の確実性です。フィッシング耐性のある多要素認証の実装により、ユーザーが確実に本人であることを確認できます。また、デバイストラストとユーザートラストの組み合わせにより、アクセスの安全性が確保されています。さらに、私たちのシステムでは、ユーザーが実際に誰であるかを確実に把握し、データに対して適切なアクセス権を持っていることを確認できます。

これらの3つのポイントは、OktaとAmazon Qの統合が、セキュリティを犠牲にすることなく、ユーザビリティと生産性の向上を実現できることを示しています。

7.2. 追加情報の入手方法

より詳細な情報が必要な方のために、いくつかの方法をご用意しています。スライドに表示されているQRコードをスキャンしていただくか、あるいはセキュリティ重視の方は直接リンクからアクセスしていただくことができます。これらを通じて、OktaとAmazon Qの統合についての詳細な情報をご覧いただけます。

また、私たちのブースは443番にございます。ちょうどこのすぐ近くです。プレゼンテーションの後、しばらくブースの後ろで待機していますので、具体的な質問やより詳細な技術的な相談がございましたら、お気軽にお立ち寄りください。

ご質問やご相談は、プレゼンテーションの内容に限らず、OktaとAWSの統合全般について承ることができます。私たちは多くの実装経験を持っており、皆様の具体的な課題に対するソリューションをご提案できると考えています。本日は、お時間をいただき、ありがとうございました。残りのre:Inventも楽しんでください。