こんにちは、アプリケーションサービス本部の上田です。
最近セールで某ソウルシリーズをまとめて購入しちまちま進めています。 無印版はDLCまで終わったんですが基本的に1対2になるボスは卑怯じゃないですか？
さて、本題ですが今回はAmazon Connect内で設定できるアクセスコントロールの項目について、いくつか例を動かしながら確認してみたいと思います。
Amazon Connectのアクセスコントロールについて
Amazon Connectはインスタンスの中でユーザーに対し、アクセスコントロール権限を設定することが可能です。
アクセスコントロール機能を利用することで部門・チームごとに通話履歴やルーティングプロファイルを管理したり、オペレーターに必要以上の情報を見せないようにしたりすることが可能です。
Amazon Connectのアクセスコントロールは「階層ベースのアクセスコントロール」と「タグベースのアクセスコントロール」の2種類があります。これらの内容はユーザーに割り当てられているセキュリティプロファイルから設定を行えます。
2つの特徴を簡単にまとめると以下のようになります。
- 階層ベースのアクセスコントロール
- ユーザーに割り当てられたエージェント階層に基づいて、特定のリソースへのアクセスを設定可能
- タグベースに比べると設定が簡単
- 現在サポートされているリソースがユーザーのみ
- タグベースのアクセスコントロール
- 割り当てられたリソースタグに基づいて特定のリソースへのアクセスをきめ細かく設定可能
- 設定対象となるすべてのリソースにタグ付けが必要
- Amazon Connect内の設定変更・閲覧可能なほぼすべてのリソースに対して設定が可能
それぞれの詳しい説明はAmazon Connectの公式ドキュメントをご確認ください。
階層ベース https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/hierarchy-based-access-control.html
タグベース https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/tag-based-access-control.html
特にタグベースのコントロールはリソースに設定できる数に制限があったり、セキュリティプロファイルに関する制限があったりするので利用前に確認しておくことをおすすめします。
それぞれのアクセスコントロールについて確認できたところで、さっそく動作確認を行ってみます。
今回は以下のようなユーザーと階層を用意しました。
Ope1～Ope6のユーザーを使用して、アクセスコントロールを行った場合どのように見えるのかを検証します。
階層ベースのアクセスコントロールの例
検証のためにまずはセキュリティプロファイルからアクセスコントロールを設定します。 今回は「Osaka_SV」のセキュリティで以下のように設定します。
設定が終わったのでそれぞれのアカウントでユーザー表示を確認してみます。
ちなみにオペレーターはユーザー一覧を表示する権限を付けていないため省略します。
ユーザー一覧
- Ope1（セキュリティプロファイル：Admin）
- 制限していないため、すべてのユーザーが確認できる
- Ope2（セキュリティプロファイル：Osaka_SV）
- 所属しているエージェント階層「大阪CC/Aチーム」のメンバーのみが表示されている
- Ope3（セキュリティプロファイル：Osaka_SV）
- 所属しているエージェント階層「大阪CC/Bチーム」のメンバーのみが表示されている
という状態になりました。
Ope2とOpe3はアクセスコントロール設定がされていることについての案内が表示されています。
この設定は「ユーザー」に対する設定のため、ほかの項目では制限されないものになります。
が、一応ルーティングプロファイルなども確認してみます。
ルーティングプロファイル
予想通りではありますが、階層によるアクセスコントロールの対象ではないためすべてのルーティングプロファイルが閲覧できます。
タグベースのアクセスコントロールの例
続いて比較のためにタグベースでのアクセスコントロールを確認します。
タグベースでの設定はかなり細かくできるのですが、すべて紹介すると長くなってしまうので階層ベースの際に確認した「ユーザー」と「ルーティングプロファイル」について設定してみます。
リソースにも対応するタグをつけておきます。
ユーザー一覧
- Ope1（セキュリティプロファイル：Admin）
- 制限していないため、すべてのユーザーが確認できる
- Ope2（セキュリティプロファイル：Osaka_SV）
- タグ付けされたメンバーのみが表示されている（4名分）
- Ope3（セキュリティプロファイル：Osaka_SV）
- タグ付けされたメンバーのみが表示されている（4名分）
の状態になりました。階層の表示とは異なり、タグ付けされたメンバーであれば確認することができるためチームが違うメンバーの情報も参照できる状態になっています。
ここでもアクセスコントロールが設定されていることを確認することができます。
ルーティングプロファイル
これもユーザーの表示のされ方と同じです。タグ付けされたリソースのみが確認できます。
階層ベース＋タグベースの組み合わせの例
では最後に2つのアクセスコントロールを掛け合わせてみます。
タグの設定はそのままに、階層ベースコントロールを追加で設定します。
ユーザー
- Ope1（セキュリティプロファイル：Admin）
- 制限していないため、すべてのユーザーが確認できる
- Ope2（セキュリティプロファイル：Osaka_SV）
- 所属階層（Aチーム）のタグ付けされたメンバーのみが表示されている（Ope2,Ope5）
- Ope3（セキュリティプロファイル：Osaka_SV）
- 所属階層（Bチーム）のタグ付けされたメンバーのみが表示されている（Ope3,Ope6）
となりました。
Ope4のユーザーはAチームに所属していますが、タグ付けがされていないのでOpe2からは確認できないようになっています。
このように、階層ベースとタグベースのアクセスコントロールを組み合わせることによってより細かいアクセス制限が可能です。
ルーティングプロファイル
こちらはタグベースのコントロールのみが適用された結果となっていますが、階層ベースのコントロールではルーティングプロファイルを制限することができないので設定内容としては正しい動作をしています。
おまけ
コンタクトの検索について制限ができないのか確認したところ、この項目についてはアクセスコントロールではなくセキュリティプロファイルの項目の一つとして管理されていることがわかりました。
セキュリティプロファイルの「連絡先のアクセスを制限」の項目を有効にした場合は自分の階層レベル以下のコンタクトに制限することができ、無効の場合はすべてのコンタクトが表示される状態となります。
まとめ
今回検証してみた結果から、それぞれの違いを簡単に書き出してみると以下のようになりました。
| 階層ベース | タグベース | |
|---|---|---|
| 制御対象 | 主にユーザー（エージェント）と、そのユーザーが担当する問い合わせの参照・検索 | キュー、ルーティングプロファイル、セキュリティプロファイル、フロー、モジュールなど多様なAmazon Connectリソース |
| 制御粒度 | 組織階層に基づいたユーザーの範囲 | きめ細やかなリソース単位 |
| 設定方法 | エージェント階層の定義とセキュリティプロファイルの権限設定 | リソースへのタグ付与 |
| 柔軟性 | 限定的（ユーザーのみ） | 高い |
| 主なメリット | 直感的な管理、レポート機能との連携、問い合わせ検索の制限 | きめ細やかなアクセス制御、柔軟な対応、拡張性 |
| 主なデメリット | 適用範囲の限定性、柔軟性の欠如 | タグ管理の手間、設定の複雑さ |
| 向いているユースケース | 一般的なコンタクトセンター組織、役割に基づくレポート参照、問い合わせ検索の制限 | 複数部署・事業部、特定のスキルセット要件、データ保護 |
簡単なアクセスコントロールであれば、階層コントロールが一番楽ではありますが凝ったことをしようとするならタグベースコントロールを使用することになる印象です。
アクセスコントロール設定時に一番下に要約としてどんなアクセス制限になるか教えてくれるのでそれも参考になるかと思います。
場合によっては、階層ベースのコントロールとタグベースのコントロールを組み合わせて使うことも有効ですが、規模によっては運用管理や設定が複雑になるため注意が必要です。
ここまでお読みいただきありがとうございました。
