Amazon Connect コミュニケーションウィジェットの「Add security for your communications widget」設定を整理してみた
はじめに
Amazon Connect のコミュニケーションウィジェットを利用すると、Web サイトや社内ポータルにチャット、タスク、E メール、ウェブ通話などの問い合わせ導線を埋め込めます。
コミュニケーションウィジェットの設定では、ウィジェットを配置するドメインを指定したうえで、Add security for your communications widget、日本語画面では「コミュニケーションウィジェットのためにセキュリティを追加する」に対して Yes または No を選択します。
公式ドキュメントでは Yes が推奨されています。一方で、社内イントラネット上の SSO 済みポータルに埋め込む場合、すでにポータル側で認証されているため、追加で JWT 発行の仕組みまで必要なのか迷う場面がありました。
そこで今回は、社内イントラネット上の SSO 済みポータルに Amazon Connect コミュニケーションウィジェットを配置する前提で、以下を整理します。
- Yes と No の違い
- No にした場合に残るリスク
- 同一ドメイン上にログイン不要ページがない場合の考え方
contactAttributesを使わない場合の考え方- No で進める場合に確認したいこと
- Yes を強く検討したほうがよい条件
なお、公式ドキュメント上は Yes が推奨されています。本記事ではその前提を踏まえ、特定の社内ポータル要件において No を選択する場合の残余リスクを整理します。
前提
今回の前提は以下です。
- コミュニケーションウィジェットは社内イントラネット上のポータルに配置する
- ポータル自体は SSO 済み
- 利用者は社内ユーザーのみ
- 外部公開サイトではない
- 問い合わせ用途は一般的な社内問い合わせ
- 本人確認が必要な問い合わせは想定しない
- 部署や拠点によるルーティング分岐は不要
contactAttributesは利用しない- バックエンド側の追加実装はできるだけ避けたい
この前提で、Add security for your communications widget = No を選択してよいかを考えます。
Yes を選んだ場合
公式ドキュメントでは、Add security for your communications widget で Yes を選択し、Web サーバー側で JWT を発行する構成が推奨されています。
[コミュニケーションウィジェットのためにセキュリティを追加する] で [はい] を選択して、ウェブサイトの管理者と協力して新しいチャットリクエストに対して JSON ウェブトークン (JWT) を発行するようにウェブサーバーを設定することをお勧めします。これにより、Amazon Connect に送信されるチャットリクエストが認証されたユーザーからのものであることを確認するなど、新しいチャットを開始する際により詳細に制御を行えます。
ここで出てくる JWT は、ざっくり言うと 自社 Web サーバーが発行する、短時間だけ有効な署名付きチケット です。
Yes を選んだ場合、チャット開始時にいきなり Amazon Connect へリクエストするのではなく、まず自社 Web サーバーに「このユーザーはチャットを開始してよいか」を確認します。
自社 Web サーバーは、SSO セッションなどを確認し、問題なければ JWT を発行します。Amazon Connect はその JWT を検証することで、「このチャット開始リクエストは、自社 Web サーバーが許可したものか」を確認できます。
つまり、Yes を選ぶ主な目的は、チャット開始前に自社 Web サーバーを関所として挟み、リクエストをより細かく制御できるようにすることです。
例えば、以下のような制御ができます。
- チャット開始時に Web サーバー側で認証状態を確認する
- 認証済みユーザー由来のリクエストであることを確認する
- 自社 Web サーバーで許可したリクエストだけを通す
- JWT に含めた属性の整合性を担保する
ドキュメントでは、Yes を選んだ場合の動作として以下が記載されています。
[はい] 選択すると、次のようになります。
Amazon Connect は、次のページで JSON ウェブトークン (JWT) の作成に使用できる 44 文字のセキュリティキーを提供します。
Amazon Connect は、チャットの開始時に JSON ウェブトークン (JWT) をチェックするコールバック関数をコミュニケーションウィジェットの埋め込みスクリプト内に追加します。
Yes の場合、処理の流れは以下のようになります。
- ユーザーが社内ポータル上でチャットを開始する
- コミュニケーションウィジェットが自社 Web サーバーに JWT を要求する
- 自社 Web サーバーが SSO セッションなどを確認する
- 問題なければ、自社 Web サーバーが JWT を発行する
- コミュニケーションウィジェットが JWT を Amazon Connect に渡す
- Amazon Connect が JWT を検証する
- 検証に成功するとチャットが開始される
SSO 済みポータルであれば、JWT を発行する API で SSO セッションを確認し、認証済みユーザーにだけ JWT を返す構成にできます。
そのため、Yes を選ぶ場合は、JWT を発行するためのバックエンド実装が必要になります。たとえば、自社 Web サーバー側に /token のような API を用意し、SSO セッション確認後に JWT を返す実装です。
JWT の仕様についても、公式ドキュメントに記載されています。
アルゴリズム: HS256
クレーム:
sub: widgetId
iat: 発行時刻。
exp: 有効期限 (最大 10 分)。
また、JWT に問い合わせ属性を含める場合は、JWT の attributes クレームとして渡します。JWT を使用して問い合わせ属性を渡すと、共有シークレットを適切に保護している限り、データの整合性を担保しやすくなります。
ただし、JWT は暗号化ではありません。JWT に含めた問い合わせ属性はエンコードされるだけで、デコードすれば読み取れます。
そのため、JWT に属性を含める場合でも、必要以上に機微な情報を入れないよう注意が必要です。
問い合わせ属性は JWT でのみエンコードされ、暗号化されないため、属性をデコードして読み取ることができます。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/pass-contact-attributes-chat.html
No を選んだ場合
No を選ぶと、チャット開始時に JWT による追加検証を行いません。
Yes の場合は、チャット開始前に自社 Web サーバーが JWT を発行し、Amazon Connect はその JWT を検証します。
一方、No の場合はこのチケット確認の流れがないため、Web サーバー側で JWT 発行 API を用意する必要はありません。ウィジェットの導入はシンプルになります。
ただし、Yes の場合に得られる以下の制御は使いません。
- チャット開始直前に SSO セッションをサーバー側で再確認する
- Web サーバーが発行した JWT であることを Amazon Connect 側で検証する
- 自社 Web サーバーで許可したリクエストかどうかを確認する
- JWT に含めた属性の整合性を担保する
つまり No は、「許可ドメイン上でウィジェットを読み込めること」を主な前提として利用する構成です。Yes に比べると実装は簡単ですが、チャット開始リクエストを自社 Web サーバーで認証、許可したうえで Amazon Connect に渡す構成ではない点を理解しておく必要があります。
ドメイン許可リストで制御できること
コミュニケーションウィジェットでは、ウィジェットを配置するドメインを指定します。
ドキュメントには以下のように記載されています。
コミュニケーションウィジェットを配置するウェブサイトのドメインを入力します。チャットは、このステップで選択したウェブサイトにだけ読み込まれます。
このため、ドメイン許可リストにより、ウィジェットを読み込めるドメインを制限できます。
ただし、ドメイン許可リストには注意点があります。
サブドメインは自動的に含まれる
ドキュメントには、サブドメインについて以下のように記載されています。
サブドメインは自動的に含まれます。例えば、example.com を許可すると、そのすべてのサブドメイン (sub.example.com など) も許可されます。
そのため、example.com のような上位ドメインを許可すると、想定より許可範囲が広くなる可能性があります。
社内ポータルだけで使う場合は、可能な限り社内ポータル専用のドメインを許可対象にするのがよさそうです。
例
https://portal.example.com
プロトコルは完全一致が必要
ドキュメントには、プロトコルについて以下のように記載されています。
プロトコル http:// または https:// は、設定と完全に一致する必要があります。許可するドメインを設定する際に、正確なプロトコルを指定してください。
http:// と https:// は別物として扱われます。社内ポータルが HTTPS の場合は、https:// で許可する必要があります。
URL パス単位では制御できない
ドキュメントには、URL パスについて以下のように記載されています。
すべての URL パスが自動的に許可されます。例えば、example.com が許可されている場合、その下位にあるページ (example.com/cart や example.com/checkout など) はすべてアクセス可能になります。特定のサブディレクトリを許可またはブロックすることはできません。
つまり、以下のようにパス単位で許可、拒否することはできません。
許可したい
https://portal.example.com/support
許可したくない
https://portal.example.com/public
https://portal.example.com/test
ドメインが許可されると、その配下の URL パスはすべて対象になります。
No にした場合のリスク
No にした場合に意識すべきリスクは、大きく2つあります。
リスク1：チャット開始リクエストが正規ポータル画面由来かを Amazon Connect 側で検証できない
ドメイン許可リストは、あくまで「どのドメインでウィジェットが読み込まれるか」を制御する仕組みです。
そのため No の場合、Amazon Connect 側では以下を JWT で確認しません。
- そのリクエストが SSO 済みユーザーからのものか
- そのリクエストが正規のポータル画面から発信されたものか
- そのリクエストが自社 Web サーバーで許可されたものか
SSO 済みポータルにアクセスできることと、チャット開始リクエストが正規のポータル画面から発信されたことは、厳密には同じではありません。
特に、許可対象のドメイン配下やサブドメインにログイン不要ページがある場合、想定外のページからウィジェットが動作しうる余地があります。
また、No 構成では、チャット開始前に自社 Web サーバーで「このユーザーはチャットを開始してよいか」を確認しません。つまり、許可ドメイン上でウィジェットを読み込めるユーザーであれば、追加のサーバー側確認なしにチャットを開始できる構成として考える必要があります。
Yes 構成であれば、チャット開始時に Web サーバー側で JWT を発行するため、そこで SSO セッションの確認や利用可否の制御を入れられます。
同一ドメイン上にログイン不要ページがなければ問題ないのか
同一ドメイン上にログイン不要ページがなければ、想定外のページからウィジェットが使われるリスクは下げられます。
ただし、それだけで No 構成が安全であるとは言い切れません。
No 構成では、チャット開始時に Web サーバー側で JWT を発行しないため、Amazon Connect 側では「このリクエストは自社 Web サーバーで認証、許可されたものです」と確認できません。
そのため、ログイン不要ページがないことはリスク低減要素の1つとして考えます。最終的には、JWT による追加検証を行わないことによる残余リスクを社内で許容できるかの判断になります。
リスク2：contactAttributes を使う場合、属性が改ざん可能
今回は contactAttributes を利用しない前提ですが、No 構成で contactAttributes を使う場合は注意が必要です。
ここでいう contactAttributes は、主にスニペットコードから amazon_connect('contactAttributes', ...) で直接渡す属性を指します。Yes 構成で属性を渡す場合は、JWT の attributes クレームとして扱います。
No 構成でスニペットコードから直接 contactAttributes を渡す場合、その値はブラウザ側で扱われます。そのため、利用者がブラウザの開発者ツールなどを使って値を変更できる可能性があります。
公式ドキュメントでも、JWT を使わずにスニペットコードから直接コンタクト属性を渡せる一方で、その属性はクライアント側で変更可能であり、PII や変更不可能なデータが必要な場合は JWT 設定を使うよう案内されています。
次の例は、ウィジェットのセキュリティを有効にせずに、スニペットコードから直接コンタクト属性を渡す方法を示しています。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/pass-contact-attributes-chat.html
これらの属性は、HostedWidget- プレフィックスでスコープが指定されますが、依然としてクライアント側では変更可能 (ミュータブル) です。フローで PII または変更不可能 (イミュータブル) なデータが必要となる場合は、JWT 設定を使用してください。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/pass-contact-attributes-chat.html
そのため、No 構成で contactAttributes に社員番号、氏名、メールアドレス、部署名などを渡し、それを信頼できる値として扱うのは避けるべきです。
今回は contactAttributes を利用しない前提のため、コンタクト属性の改ざんリスクは実運用上の主要論点から外せます。
ただし、将来的に社員番号、氏名、メールアドレス、部署、ルーティング条件などを contactAttributes として渡す場合は、No 構成のまま信頼できる値として扱うべきではありません。その場合は Yes 構成を再検討します。
今回の前提での判断
今回の前提では、No を選択する余地はあると考えます。
理由は、社内イントラネット上の SSO 済みポータルで利用し、外部公開サイトではなく、問い合わせ用途も一般的な社内問い合わせに限られるためです。また、本人確認が強く必要な用途ではなく、部署や拠点によるルーティング分岐も不要で、contactAttributes も利用しません。
さらに、Yes を選ぶ場合は Web サーバー側で JWT を発行する API が必要になり、セキュリティキーの管理、JWT の有効期限管理、実装後の運用も考える必要があります。バックエンド改修をできるだけ避けたい場合、この実装コストは判断材料になります。
ただし、これは AWS のベストプラクティスとして No が推奨されている、または No が許容可能と明示されている、という意味ではありません。
公式ドキュメント上の推奨は Yes です。No は「安全だから選ぶ」ものではなく、「今回の要件では Yes による追加制御が必須ではないと判断し、残るリスクを把握したうえで選ぶ」ものだと考えるのがよさそうです。
No で進める場合に確認したいこと
No で進める場合は、最低限以下を確認しておくとよいです。
1. 許可するドメインを必要最小限にする
許可ドメインは、できるだけ社内ポータル専用のドメインに限定します。
https://portal.example.com
example.com のような上位ドメインを許可すると、サブドメインも含めて許可範囲が広くなる可能性があります。
2. 許可対象のドメイン配下にログイン不要ページがないか確認する
以下のようなページがないか確認します。
- ログイン不要でアクセスできるページ
- 一部ユーザーだけが利用する別アプリケーション
- テストページ
- 古い静的ページ
- SSO の対象外になっているパス
3. 許可対象に含まれるサブドメインも確認する
許可対象に含まれるサブドメインに、SSO 対象外のページや別アプリケーションがないか確認します。
4. contactAttributes や本人確認が必要な用途に注意する
今回の方針では、No 構成で contactAttributes を使わないことを前提にします。
将来的に社員番号、氏名、メールアドレス、部署名、ルーティング条件などを信頼できる値として扱いたくなった場合は、ブラウザ側から直接渡す contactAttributes ではなく、Web サーバー側で発行する JWT の attributes として渡す Yes 構成を再検討します。
また、contactAttributes を使わない場合でも、人事、労務、アカウント関連、権限申請など、本人確認が重要な問い合わせに広げる場合は、社内ポータルを開けることだけで十分かを見直す必要があります。
Yes を強く検討したほうがよい条件
今回の前提では No を選択する余地はありますが、以下に当てはまる場合は Yes を強く検討したほうがよいです。
- チャット開始時に、SSO セッションや利用可否を自社 Web サーバー側で確認したい
- 社員番号、氏名、部署、ルーティング条件などを信頼できる属性として扱いたい
- 本人性や権限に応じて、チャット開始可否や対応内容を制御したい
- 許可対象の同一ドメインまたはサブドメインに、SSO 対象外のページや別アプリケーションが存在する
- セキュリティポリシー上、公式推奨構成を優先したい
Yes と No の比較
今回の整理を表にすると、以下のようになります。
| 観点 | Yes | No |
|---|---|---|
| 公式ドキュメント上の位置づけ | 推奨 | 推奨とは明記されていない |
| JWT による追加検証 | あり | なし |
| バックエンド実装 | 必要 | 不要 |
| チャット開始時の制御 | Web サーバー側で制御しやすい | 許可ドメインでの読み込みが主な制御 |
| 属性の信頼性 | JWT の attributes として渡すことで担保しやすい |
スニペットの contactAttributes はクライアント側で変更可能 |
| 向いている用途 | 本人性や属性の信頼性が必要な用途 | 一般的な問い合わせで追加実装を避けたい用途 |
まとめ
Add security for your communications widget は、公式ドキュメント上は Yes が推奨されています。
今回のように、社内イントラネット上の SSO 済みポータルで一般的な社内問い合わせに利用し、contactAttributes も使わない場合は、No を選択する余地はあると考えます。
ただし、No 構成ではチャット開始リクエストを JWT で追加検証しません。許可ドメインの範囲や用途を確認したうえで、残余リスクを社内で受容できるかを判断する必要があります。
