Amazon Connect のサードパーティアプリケーションで検討したい 3 つのセキュリティ対策
はじめに
以前の記事では、Amazon Connect のエージェントワークスペースに組み込める「発信時にキューを選択できるサードパーティアプリケーション」を作成しました。
S3 と CloudFront を使って手軽にホスティングできるのが魅力ですが、この構成には 1 つ課題があります。
それは、 「CloudFront の URL を知っていれば、誰でもブラウザから直接アクセスして画面を開けてしまう」 という点です。
前回のアプリでは、ワークスペース外からのアクセスを検知した場合に 「Amazon Connect 内で開いてください。」 とエラーメッセージを表示する実装を入れました。
この実装により、ワークスペース外からアクセスしても発信などの機能は利用できません。
一方で、ブラウザからの直接アクセスそのものをブロックしているわけではないため、URL を知っていれば画面自体は開けてしまいます。
そこで今回は、サードパーティアプリケーションを本番環境で安全に運用するために、追加で設定できる 3 つのセキュリティ対策をご紹介します。
1. CloudFront のレスポンスヘッダーポリシーで iframe の埋め込み元を制限する
CloudFront の「レスポンスヘッダーポリシー」機能を使うと、HTTP レスポンスに Content-Security-Policy（CSP）というセキュリティ用のヘッダーを追加できます。
この CSP の中で frame-ancestors を設定することで、 Amazon Connect 関連のドメイン以外から iframe として勝手に埋め込まれることを防止 できます。
AWS の公式ドキュメントでも、エージェントワークスペース のベストプラクティスとして、アプリ側で Content-Security-Policy ヘッダーの frame-ancestors を適切に設定し、Amazon Connect からのみ埋め込みを許可することが推奨されています。例として、https://*.awsapps.com および https://*.my.connect.aws を許可する設定が案内されています。
このように設定しておくことで、悪意のある別の Web サイトにアプリ画面を埋め込まれるリスクを抑えられます。
なお、CloudFront 側でのヘッダー追加や上書きの仕組みについては、以下のドキュメントも参考になります。
2. AWS WAF で社内 IP や VPN 経由のアクセスのみを許可する
前述の frame-ancestors の設定は、あくまで「別サイトへの無断埋め込み」を防ぐためのものです。
そのため、ブラウザから URL へ直接アクセスすること自体は防げません。
「URL を知っていれば誰でもページを開けてしまう」 という状態をさらに制限したい場合は、CloudFront に AWS WAF を関連付けるのが有効です。
AWS WAF の IP 制限機能（IP set）を使えば、社内ネットワークや VPN の IP アドレスからのみアクセスを許可する構成を作れます。
3. サードパーティアプリケーションに独自の認証（SSO）を組み込む
IP 制限だけでなく、ユーザー認証によってより厳密にアクセス制御を行いたい場合は、サードパーティアプリケーション自体に認証機能（SSO フェデレーション）を組み込む構成が有効です。
このとき、Amazon Connect インスタンスの「ID 管理」の設定によって、エージェントのログイン体験が変わります。
① Amazon Connect を「SAML 2.0 ベースの認証」で運用している場合（推奨）
エージェントワークスペースへのログインに使用しているのと同じ ID プロバイダー（Entra ID や Okta など）を、サードパーティアプリの認証にも利用できます。
この構成にすると、エージェントは Connect ログイン時の認証セッションを引き継げるため、ID やパスワードを再入力することなくシームレスにアプリ認証を完了できます。
ブラウザの制限などにより、初回のみクリック操作が必要になる場合はありますが、基本的には自然なログイン体験を実現できます。
② Amazon Connect を「Connect 内でユーザーを管理」で運用している場合
アプリ側に任意の IdP（Amazon Cognito など）を組み込むこと自体は可能ですが、エージェントは Connect へのログインとは別に、ワークスペース内のアプリ画面で再度ログインを行う必要があります。
IdP 側でのアプリ登録について
SSO を導入する場合は、利用する IdP 側で今回のサードパーティアプリケーション（CloudFront の URL など）を 1 つのアプリケーションとして登録する作業が必要です。
これにより、IdP とアプリ間で安全に認証情報をやり取りできるようになります。
また、SSO のようにアプリが複数ドメインを利用する構成では、CloudFront の URL（Access URL）だけでなく、IdP のログイン画面など追加で利用するドメインを、Amazon Connect のサードパーティアプリ設定にある Approved origins（追加で許可するオリジン）に登録する必要があります。
たとえば、以下のようなドメインが対象になります。
- IdP のログイン画面のドメイン
- 認証コールバック先のドメイン
- 認証処理で利用する別サブドメイン
AWS のベストプラクティスでも、ログインフローを伴うアプリのように複数ドメインを利用する場合は、Access URL（CloudFront の URLなど） のドメインに加えて、Approved origins に必要なドメインを追加するよう案内されています。これらのドメインは エージェントワークスペース 側の Content Security Policy に組み込まれ、iframe 内で利用できるようになります。
ログインフローをサポートするアプリなど、複数のドメインを使用するアプリは、アプリケーション構成の承認済みオリジンリストにドメインを追加する必要があります。AccessUrlで指定されたドメインと、承認済みオリジンに追加されたドメインは両方とも、エージェントワークスペースのコンテンツセキュリティポリシーに組み込まれ、これらのドメインのiframe統合が可能になります。
https://docs.aws.amazon.com/agentworkspace/latest/devguide/recommendations-and-best-practices.html#recommendations-and-best-practices-multiple-domains
SSO 導入後の直接アクセスの挙動
SSO を設定すると、ブラウザから直接 URL にアクセスしたときの挙動は次のように変わります。
- 未認証のユーザー（第三者）の場合
- IdP のログイン画面にリダイレクトされるため、認証なしでアプリ画面を閲覧することはできません
- 認証済みのユーザー（社内エージェントなど）の場合
- 認証自体は通過しても、今回のアプリ側の制御によって 「Amazon Connect 内で開いてください。」 と表示され、機能は利用できません
このように、SSO を組み込むことで、少なくとも第三者が URL を知っているだけで画面を開けてしまう状態は避けやすくなります。
さらに、アプリ側のワークスペース判定や WAF による制御と組み合わせることで、より堅牢なアクセス制御を実現できます。
まとめ
Amazon Connect のサードパーティアプリケーションを本番運用する際に検討したいセキュリティ対策について解説しました。
CloudFront のレスポンスヘッダーポリシーによる iframe 制限、AWS WAF による IP 制限、そして SSO フェデレーションを組み合わせることで、安全性と利便性を両立しやすくなります。
要件に応じてこれらの対策を組み合わせながら、安全にサードパーティアプリケーションを活用してみてください。
参考
