SharepointをデータソースとしたKendraを実装し検索してみた

こんにちは、つくぼし(tsukuboshi0755)です！

Kendraには様々なリソースを接続して検索システムを作る事ができますが、その中にSharepointがあります。

以下のAWS公式ブログでも、Sharepointをデータソースとする場合の設定方法について紹介されています。

今回は上記のブログを参照しながら、SharepointをデータソースとしたKendraの実装方法について、より詳細に確認してみたいと思います！

前提条件

Sharepointの種類

SharepointをKendraに接続するには、KendraデータソースでSharepointコネクタを使用する必要があります。

Sharepointコネクタでは、Sharepoint Online(クラウド型)またはSharepoint Server(オンプレミス型)のいずれかを指定できます。

今回はSharepoint Onlineを使用します。

もし現時点でSharepoint Onlineを利用できるMicrosoft 365プランに加入していない場合は、事前に以下のページよりプランへの加入をお願いします。

Entra IDの設定

今回の構築手順でSharepoint OnlineをKendraに接続するためには、AWSの他に、Microsoft 365に含まれるMicrosoft Entra ID(旧称Azure Active Directory)での設定が必要になりますのでご注意ください。

Entra IDの設定は、Microsoft Entra管理センター、またはMicrosoft Azure Portalから実施できます。

今回はMicrosoft Entra管理センターを使用して、Entra IDの設定を行います。

Sharepointコネクタのバージョン

Sharepointのコネクタは、2024年1月現在でv1.0とv2.0の2つが提供されています。

この内v1.0は、公式で近々サポートが終了する予定だと明記されているためご注意ください。

SharePoint connector V1.0/SharePointConfiguration API のサポートは 2023 年に終了する予定です。SharePoint コネクタ V2.0/TemplateConfiguration API に移行するか、こちらを使用することをお勧めします。

今回はv2.0を使用します。

Sharepointコネクタの認可

Sharepointコネクタの認可方式として、アクセスコントロールリスト (ACL) の有効化が可能です。

ACLを使用する事で、SharePointデータソース内のユーザーのドキュメントアクセスレベルに基づいて、検索結果を制御できるようになります。

今回はACLを有効化します。

またIDクローラーを使用する事で、SharePointデータソース内のローカルまたはEntra IDを使用し、その中のユーザーおよびグループのアクセス制御権限に基づいて、Kendraインデックスの検索結果を表示できるようになります。

今回はIDクローラーも合わせて有効化します。

Sharepointコネクタの認証

Sharepointコネクタでは、認証方式として以下の4種類から選択できます。

• Basic認証
• OAuth 2.0認証
• Azure ADアプリ専用認証
• SharePointアプリ専用認証

Sharepoint独自の認証方式として提供されている、Azure ADアプリ専用認証及びSharePointアプリ専用認証については、下記をご参照ください。

今回はAWS公式ブログでも紹介されている、OAuth 2.0認証を使用します。

構成

今回の構成図は以下になります。

Secrets Managerに登録したEntra IDユーザー及びエンタープライズアプリケーションを用いて、Sharepoint Onlineにアクセスし、Kendraにデータを同期します。

構築手順

Sharepoint サイトの準備

データソースとなるSharepointサイトが存在しない場合、事前に作成しておきます。

以下を参考に、Microsoft 365よりSharepoint Onlineにアクセスしてください。

以下のSharepoint画面にアクセスできるようになればOKです。

次に、以下を参考にSharepoint上でサイト及びページを作成してください。

今回は作成したサイト配下に、以下のようなサンプルページという名前のページを作成します。

サイトの所有者ユーザーの準備

同様にデータ同期の認証に用いるSharepointサイトの"所有者"となるEntra IDユーザーが存在しない場合、事前に作成しておきます。

以下を参考に、Microsoft Entra管理センターにて、Entra IDユーザーを作成してください。

以下のEntra IDユーザー画面の新しいユーザーの作成をクリックする事で、作成可能です。

以下のようなユーザーが作成できればOKです。

ユーザーが作成できましたら事前にログインし、初期パスワードの変更を変更しておいてください。

ここで作成したユーザー名及びパスワードは、後ほどKendraのデータソース設定で使用するのでメモしておいてください。

ユーザーのログイン確認が取れましたら、以下を参考にSharepoint管理センターにて、このユーザーを所有者として指定します。

以下のように、先ほど作成したユーザーが、作成したサイトの"所有者"として指定されている事が確認できればOKです。

(サイトの所有者タブではなく、所有者タブで表示されているユーザになります。紛らわしいのでご注意ください。)

エンタープライズアプリケーションの登録

今回KendraはSharepointサイトにAPI経由でアクセスするため、さらにEntra IDでエンタープライズアプリケーションの登録が必要になります。

以下を参考に、Microsoft Entra管理センターにて、アプリケーションを登録します。

以下のEntra IDアプリの登録画面にて、アプリケーションの名前を設定し、サポートされているアカウントの種類をシングルテナントにしてください。

リダイレクトURIは空欄で構いません。

以下のようなアプリケーションが作成されていればOKです。

ここで作成したアプリケーションのテナントID及びクライアントIDは、後ほどKendraのデータソース設定で使用するのでメモしておいてください。

続いて以下を参考に、アプリケーションのシークレットを発行します。

以下のEntra IDアプリの概要画面にて、証明書またはシークレットの追加をクリックします。

証明書とシークレット画面にて、新しいクライアントシークレットをクリックし、シークレットを作成します。

以下のようなシークレットが発行されていればOKです。

ここで作成したクライアントシークレット(の値)は、後ほどKendraのデータソース設定で使用するのでメモしておいてください。

最後に以下を参考に、アプリケーションのAPIアクセス許可を設定します。

以下のAWS公式ドキュメントに基づき、必要な権限を許可します。

SharePoint コネクタ V2.0 - Amazon Kendra

今回はOAuth認証とACL認可を使用するため、以下の権限を許可します。

権限の付与方法としてアプリケーションの許可と委任されたアクセス許可の2種類があるので、各々の権限で間違えないようご注意ください。

• Microsoft Graph
  • GroupMember.Read.All (アプリケーションの許可) - すべてのグループメンバーシップを読み取る
  • Notes.Read.All (アプリケーションの許可) - OneNoteノートブックをすべて読み込む
  • Sites.FullControl.All (委任されたアクセス許可) - すべてのサイトコレクションを完全に制御する
  • Sites.Read.All (アプリケーションの許可) - すべてのサイトコレクションの項目を読み取る
  • User.Read.All (アプリケーションの許可) - すべてのユーザーの完全なプロフィールを読み取る
• SharePoint
  • AllSites.Read (委任されたアクセス許可) - すべてのサイトコレクションの項目を読み取る

以下のEntra IDアプリにおけるAPIのアクセス許可画面にて、アクセス許可の追加をクリックし、必要な権限を追加します。

また一部の権限は管理者の同意が必要になるため、以下を参考に管理者の同意を取得しておいてください。

以下の管理者の同意を与えますをクリックし、管理者の同意を取得します。

以下のようにアプリケーションに権限が付与され、管理者の同意が取得されていればOKです。

Kendraインデックスの作成

データの検索元となるKendraインデックスを作成します。

まずインデックスの名前とロール名を設定します。

次にアクセスコントロール設定を有効化します。

トークンタイプはJSONとし、ユーザー名及びグループはデフォルトのままで進めます。

最後にエディションについては、今回検証のためDeveloperを選択します。

設定内容に問題がなければ、インデックスを作成してください。

Kendraデータソースの作成

Sharepointと接続するためのKendraデータソースを作成します。

今回データソースとしては、Sharepoint connector v2.0を選択します。

まずデータソース詳細を設定します。

データソースの名前を入力し、Default LanguageをJapaneseに設定します。

続いてアクセス制御を設定します。

ソースのHosting MethodとしてSharepoint Onlineを選択します。

Sites URLには、SharepointサイトURL(https://yourdomain.sharepoint.com/sites/mysite)を入力します。

Domainには、Sharepointサイトドメイン(サイトURLにおけるyourdomainの部分)を入力します。

認可用のACLは今回有効化します。

今回はUser principal nameをフィールドとして使用します。

認証方式はOAuth 2.0を選択します。

ここでは先ほどメモしたテナントIDを入力してください。

その後新しくシークレットを作成するために、メモしたユーザ名、パスワード、クライアントID、クライアントシークレットを入力します。

VPCは今回使用しないため、無効化します。

IDクローラーは今回有効化します。

ローカルグループ及びADグループの両者とも、マッピングは有効化します。

ロール名もここで設定します。

さらに同期設定を実施します。

今回はAllを選択しますが、Regex Patternを用いて同期対象のドキュメントを細かく制御する事も可能です。

同期モードには、過去のコンテンツも含めて同期するFull Syncを選択します。

同期スケジュールは、手動で同期を実行するRun on demandを選択します。

最後にフィールドマッピングを設定します。

今回はデフォルトのままで進めます。

設定内容に問題がなければ、データソースを作成してください。

検索テスト

最後にKendraのデータを同期し、想定通りSharepointのサイトを検索できるか確認します。

まずSymc nowボタンをクリックし、データソースの同期を実行します。

下記の通りデータ同期が成功し、Addedに同期されたデータの数が表示されていればOKです。

もし同期に失敗した場合や、同期されたデータの数が想定と異なる場合は、CloudWatch Logsの/aws/kendra/<KendraデータソースID>ロググループに出力されているエラーログを確認してください。

同期が完了したら、Search indexed contentより検索を実行します。

検索言語はJapaneseを選択します。

検索ワードとして「サンプル」を入力すると、想定通りサンプルページが検索されている事が確認できました！

最後に

今回はKendraとSharepointの接続方法について確認してみました。

S3やWebサイトをデータソースとする場合と比較して、Sharepointの場合はEntra ID側での設定も必要になるため、事前にEntra IDをどのように設定するかについては検討しておく必要があります。

とはいえ一度Kendraを構築してしまえば、Sharepoint側でデータを追加するだけで、Kendra側で同期し検索できるようになるためとても便利です。

普段Sharepointを利用している方は、ぜひKendraと連携した検索システムの構築を検討してみてはいかがでしょうか。

以上、つくぼし(tsukuboshi0755)でした！