Amazon Kendra を使用したアクセス制御を行う安全な検索アプリケーションの構築

多くの企業にとって、重要なビジネス情報は、複数のコンテンツリポジトリに分散した非構造化データとして保存されていることがよくあります。組織にとって、従業員が必要なときにこの情報を利用できるようにすることは難しいだけでなく、適切な権限を持つ従業員や従業員グループが関連情報を安全に利用できるようにすることも困難です。

Amazon Kendra は、機械学習 (ML) を利用した、非常に正確で使いやすいインテリジェントな検索サービスです。Amazon Kendra は、エンタープライズアプリケーション向けの安全な検索を実現し、ユーザーの検索クエリの結果に、そのユーザーが閲覧を許可されているドキュメントのみを含むようにすることができます。この記事では、ある組織のセキュリティモデルを反映したアクセス制御をサポートする Amazon Kendra 搭載検索アプリケーションを構築する方法を説明します。

Amazon Kendra は、検索アプリケーションが提供するユーザーアクセストークンと Amazon Kendra コネクタによって収集されたドキュメントアクセス制御リスト (ACL) に基づく検索フィルタリングをサポートしています。ユーザーアクセストークンが適用されると、検索結果には元のドキュメントリポジトリへのリンクが返され、簡単な説明が含まれます。ドキュメント全体へのアクセス制御は、元のリポジトリによって引き続き適用されます。

この投稿では、Amazon Kendra の Open ID を使ったトークンベースのユーザーアクセスコントロールを紹介します。Amazon Cognito はユーザープールを使用してユーザーを認証し、Open ID トークンを提供します。他の Open ID プロバイダーでも同様のアプローチを使用できます。

アプリケーション概要

このアプリケーションは、ゲストと登録ユーザーがドキュメントリポジトリに検索クエリを実行できるように設計されており、結果はユーザーによってアクセスが許可されたドキュメントからのみ返されます。ユーザーは役割に基づいてグループ化され、アクセス制御はグループレベルで行われます。次の表は、このユースケースで各ユーザーがアクセスできるドキュメントの概要を示しています。この例で使用されている文書は、AWS 公開文書のサブセットです。

ユーザ	役割	グループ	アクセスが承認されたドキュメントタイプ
	ゲスト		ブログ
Patricia	IT アーキテクト	顧客	ブログ、ユーザーガイド
James	営業担当	セールス	ブログ、ユーザーガイド、ケーススタディ
John	マーケティング担当役員	マーケティング	ブログ、ユーザーガイド、ケーススタディ、アナリストレポート
Mary	ソリューションアーキテクト	ソリューションアーキテクト	ブログ、ユーザーガイド、ケーススタディ、アナリストレポート、ホワイトペーパー

アーキテクチャ

次の図は、本アプリケーションのソリューションアーキテクチャを示しています。

クエリ対象のドキュメントは Amazon Simple Storage Service (Amazon S3) バケットに保存されます。各ドキュメントは、blogs、case-studies、analyst-reports、user-guides、white-papers という個別のキープレフィックスで区切られています (S3 においてキープレフィックスはいわゆるフォルダ構造を表します)。さらにこのフォルダー構造は、Data という共通のキープレフィックスを持ちます。また ACL を含むメタデータファイルは、Meta という名前のキープレフィックスを持ちます。

Amazon Kendra S3 コネクタを使用して、この S3 バケットをデータソースとして設定します。データソースが Amazon Kendra インデックスと同期されると、すべてのドキュメントをクロールしてインデックスを作成し、メタデータファイルから ACL とドキュメント属性を収集します。この例では、カスタム属性 DocumentType を使用してドキュメントのタイプを示します。

Amazon Cognito ユーザープールを使用して登録ユーザーを認証し、ID プールを使用してアプリケーションが Amazon Kendra と Amazon S3 を使用することを承認します。ユーザープールは、ユーザープールの署名 URL を設定することにより、Amazon Kendra インデックスの Open ID プロバイダーとして設定されます。

登録ユーザーが認証し、アプリケーションにログインしてクエリを実行すると、アプリケーションはユーザープールから提供されたユーザーのアクセストークンを、クエリ API 呼び出しのパラメータとして Amazon Kendra インデックスに送信します。ゲストユーザーの場合、認証は行われないため、クエリ API にパラメータとしてアクセストークンは送信されません。アクセストークンパラメータを指定しないクエリAPI呼び出しの結果は、アクセス制御制限のないドキュメントのみを返します。

Amazon Kendra インデックスは、ユーザーアクセストークンを含むクエリ API 呼び出しを受け取ると、ユーザープール署名 URL を使用してアクセストークンを復号し、ユーザーに関連付けられた cognito:username や cognito:groups などのパラメータを取得します。Amazon Kendra インデックスは、保存されている ACL とユーザーアクセストークンで受け取った情報に基づいて検索結果をフィルタリングします。これらのフィルタリングされた結果は、アプリケーションが行ったクエリ API 呼び出しに応答して返されます。

このアプリケーションの React のソースコードをダウンロードできます。また内部実装として、AWS Amplify フレームワークのコンポーネントを使用しています。AWS Amplify コンソールを使用して、継続的インテグレーションと継続的デプロイのパイプラインを実装しています。AWS CloudFormation テンプレートを使用して、以下を含む AWS インフラストラクチャをデプロイします。

Amazon Kendra インデックス
Amazon Cognito ユーザープールと ID プール
AWS Identity and Access Management (IAM) のロールとポリシー
AWS CodeCommit のソースコードリポジトリ
AWS Amplify コンソールアプリケーションの設定

この投稿では、バックエンドインフラストラクチャの設定、アプリケーションコードのビルドとデプロイ、およびアプリケーションの使用方法を順を追って説明します。

前提条件

この記事の手順を完了するには、次のものが揃っていることを確認してください。

IAM ロールとポリシーを作成する権限を持つ AWS アカウント。
AWS の基本的な知識。
ドキュメント用の S3 バケット。詳細については、「バケットの作成」と「Amazon S3 とは」を参照してください。先の CloudFormation Stack が us-east-1 リージョンで作成されるため、本バケットも us-east-1 リージョンに作成ください。
AWS コマンドラインインターフェイス (CLI) がインストールされたコマンドターミナルまたは AWS CloudShell にアクセスします。手順については、「AWS CLI バージョン 2 のインストール、更新、アンインストール」を参照してください。
Amazon Kendra。

S3 バケットをデータソースとして準備する

S3 バケットをデータソースとして準備するには、S3 バケットを作成します。AWS CLI がインストールされたターミナルまたは AWS CloudShell で、次のコマンドを実行して、ドキュメントとメタデータをデータソースバケットにアップロードします。

aws s3 cp s3://aws-ml-blog/artifacts/building-a-secure-search-application-with-access-controls-kendra/docs.zip .
unzip docs.zip
aws s3 cp Data/ s3://<S3 バケットの名前に置換>/Data/ --recursive
aws s3 cp Meta/ s3://<S3 バケットの名前に置換>/Meta/ --recursive

インフラストラクチャを CloudFormation スタックとしてデプロイする

別のブラウザタブで AWS マネジメントコンソールを開き、AWS アカウントにログインしていることを確認します。下のボタンをクリックして CloudFormation スタックを起動し、インフラストラクチャをデプロイします。

以下の画像のようなページが表示されます。

S3DataSourceBucket には、s3://プレフィックスを付けずにデータソースバケット名を入力し、[AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。] を選択し、 [スタックの作成] を選択します。

スタックの作成が完了するまでに 30～45 分かかることがあります。待っている間、[イベント]、[リソース]、[テンプレート] などのさまざまなタブが表示されます。スタックの作成ステータスは [スタック情報] タブで監視できます。

スタックの作成ステータスはスタック情報タブで監視できます。

スタックの作成が完了したら、[出力] タブを開いたままにします。以降のステップでは、[出力] タブと [リソース] タブの値が必要です。

Amazon Kendra の設定を確認してデータソース同期を開始する

次のステップでは、安全なトークンアクセスを有効にし、データソース同期を開始してドキュメントのクロールとインデックス作成を開始するように Amazon Kendra を設定します。

Amazon Kendra コンソールで、CloudFormation スタックの一部として作成されたインデックス AuthKendraIndex を選択します。

Amazon Kendra コンソールで、CloudFormation スタックの一部として作成されたインデックス AuthKendraIndex を選択します。

[User access control] では、トークンベースのユーザーアクセス制御が有効になり、署名キーオブジェクトは Amazon Cognito ユーザープールの Open ID プロバイダー URL に設定され、ユーザー名とグループはそれぞれ cognito:username と cognito:groups に設定されます。

User access control では、トークンベースのユーザーアクセス制御が有効になります。

ナビゲーションペインで、[Data sources] を選択します。
[Settings] タブには、設定中のデータソースバケットが表示されます。
データソースのラジオボタンを選択し、[Sync now] を選択します。

Sync now を選択します。

データソースの同期が完了するまでに 10～15 分かかることがありますが、次のステップに進むのを待つ必要はありません。

Amazon Cognito ユーザープールでのユーザーとグループの作成

AWS CLI がインストールされたターミナルまたは AWS CloudShell で、次のコマンドを実行して、アプリケーションに使用するユーザーとグループを Amazon Cognito ユーザープールに作成します。CloudFormation スタックの [リソース] タブから [UserPool] 行の [物理 ID] 列の内容をコピーする必要があります。これは、次のステップで使用するユーザープール ID です。AmazonKendra@2020 をすべてのユーザーの一時パスワードとして設定しました。このパスワードは初めてログインするときに必要で、Amazon Cognitoはパスワードのリセットを強制します。

USER_POOL_ID=<ユーザープール ID をここに貼り付け>
aws cognito-idp create-group --group-name customer --user-pool-id ${USER_POOL_ID}
aws cognito-idp create-group --group-name AWS-Sales --user-pool-id ${USER_POOL_ID}
aws cognito-idp create-group --group-name AWS-Marketing --user-pool-id ${USER_POOL_ID}
aws cognito-idp create-group --group-name AWS-SA --user-pool-id ${USER_POOL_ID}
aws cognito-idp admin-create-user --user-pool-id ${USER_POOL_ID} --username patricia --temporary-password AmazonKendra@2020
aws cognito-idp admin-create-user --user-pool-id ${USER_POOL_ID} --username james  --temporary-password AmazonKendra@2020
aws cognito-idp admin-create-user --user-pool-id ${USER_POOL_ID} --username john  --temporary-password AmazonKendra@2020
aws cognito-idp admin-create-user --user-pool-id ${USER_POOL_ID} --username mary  --temporary-password AmazonKendra@2020
aws cognito-idp admin-add-user-to-group --user-pool-id ${USER_POOL_ID} --username patricia --group-name customer
aws cognito-idp admin-add-user-to-group --user-pool-id ${USER_POOL_ID} --username james --group-name AWS-Sales
aws cognito-idp admin-add-user-to-group --user-pool-id ${USER_POOL_ID} --username john --group-name AWS-Marketing
aws cognito-idp admin-add-user-to-group --user-pool-id ${USER_POOL_ID} --username mary --group-name AWS-SA

アプリのビルドとデプロイ

次に、次の手順を使用してアプリをビルドしてデプロイします。

AWS Amplify コンソールで、AWSKendraAuthApp というアプリを選択します。
[ビルドの実行] を選択します。

ビルドの実行を選択します。

ビルドの進行状況はコンソールで監視できます。

ビルドを続行して、「プロビジョン」、「ビルド」、「デプロイ」、「検証」のステップを完了させます。この後、アプリケーションはデプロイされ、使用できる状態になります。

CodeCommit リポジトリを開くと、ソースコードを参照できます。確認すべき重要なファイルは src/App.tsx です。

左側のリンクを選択すると、新しいブラウザタブでアプリケーションが起動します。

左側のリンクを選択すると、新しいブラウザタブでアプリケーションが起動します。

試してみましょう

これで、アプリを試すことができます。

ログインページで、ユーザー名 patricia と仮パスワード AmazonKendra@2020 を使用してサインインします。

ログインページで、ユーザー名 patricia と仮パスワード AmazonKendra@2020 を使用してサインインします。

Amazon Cognitoでは、初めてログインするときにパスワードをリセットする必要があります。ログインすると、検索フィールドが表示されます。

Amazon Cognito では、初めてログインするときにパスワードをリセットする必要があります。ログインすると、検索フィールドが表示されます。

検索フィールドに、「what is serverless?」などのクエリを入力します。
[Filter search results] を展開すると、さまざまなドキュメントタイプが表示されます。

さまざまなドキュメントタイプを選択して検索結果をフィルタリングできます。

サインアウトして、Cognitoユーザープールで作成された他のユーザー、つまり james、john、mary に対してこのプロセスを繰り返します。

[Continue as Guest] を選択して、認証せずにアプリを使用することもできます。ただし、このオプションはブログの結果のみを表示します。

Continue as Guest を選択して、認証せずにアプリを使用することもできます。ただし、このオプションはブログの結果のみを表示します。

[Welcome Guest! Click here to sign up or sign in.] を選択すると、ログイン画面に戻ることができます。

アプリケーションを使用する

さまざまなユーザーとしてログインし、いくつかの検索クエリで開発したアプリケーションを使用できます。アクセス制御の仕組みを確認するには、異なるユーザーアカウントから同じクエリを実行して、検索結果の違いを確認してください。次のユーザーは、それぞれ異なるソースから結果を取得します。

ゲストと匿名ユーザー — ブログのみ
Patricia (お客様) — ブログ、ユーザーガイド
James (セールス) — ブログ、ユーザーガイド、ケーススタディ
John (マーケティング) — ブログ、ユーザーガイド、ケーススタディ、アナリストレポート
Mary (ソリューションアーキテクト) — ブログ、ユーザーガイド、導入事例、アナリストレポート、ホワイトペーパー

更なるクエリを実行して結果を観察できます。お勧めするクエリには、「What is machine learning?」、「What is serverless?」、および「Databases」などがあります。

クリーンアップ

CloudFormation スタックの一部としてデプロイされたインフラストラクチャを削除するには、AWS CloudFormation コンソールからスタックを削除します。スタックの削除には 20～30 分かかる場合があります。

スタックのステータスが [Delete Complete] と表示されたら、[イベント] タブに移動して、各リソースが削除されていることを確認します。また、Amazon Kendra、Amazon Amplify、および Amazon Cognito ユーザープールと ID プールのそれぞれのマネジメントコンソールを確認して、相互検証することもできます。

データソースバケットは CloudFormation スタックの一部として作成されていないため、個別に削除する必要があります。

結論

この投稿では、Amazon Kendra を使用して安全な検索アプリケーションを作成する方法を示しました。新規または既存の Amazon Kendra インデックスで Open ID 準拠の ID 管理システムを使用している組織は、安全なトークンアクセスを有効にして、インテリジェント検索アプリケーションが組織のセキュリティモデルと一致していることを確認できるようになりました。Amazon Kendra のアクセス制御の詳細については、「インデックスのドキュメントへのアクセス制御」を参照してください。

翻訳はソリューションアーキテクトの吉田が担当しました。原文はこちら。

著者について

Abhinav Jawadekar は、アマゾンウェブサービスのシニアパートナーソリューションアーキテクトです。Abhinav は AWS パートナーと協力してクラウドへの移行を支援しています。

Amazon Web Services ブログ