Amazon Connectのベストプラクティス
📅 2020-08-22
はじめに
つい先日の8/20にAWSの無料デジタルトレーニングに6つのAmazon Connectのコンテンツが追加されました。
Amazon Connect の 6 つの新しいトレーニングコース
このトレーニング、というよりAmazon Connectのデジタルトレーニングは現在すべて英語でのみ公開されているので、ぜひこの翻訳版を読んでみてください。
個人的に補足している箇所には(補足)といれてあります。
このコースについて
Amazon Connectを設計、構築、運用する際のAWSが推薦する考慮事項とベストプラクティスをまとめています。これらのベストプラクティスはAWS Well-Architectedフレームワークと連携しており、運用の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱を軸としています。
このコースを完了すると以下のことができるようになります。
- サービスとテレフォニーのリージョン可用性におけるインスタンスレベルの影響について説明できるようになります。
- モジュール化、分類、および一貫した問い合わせブロックの使用に関する標準化されたアプローチを使用して、問い合わせフローを設計することができます。
- セキュリティ、データベース、AI / ML、開発、分析など、インテグレーションされたAWSサービスドメイン全体にベストプラクティスを適用することができます。
- DevOps環境にて推奨されるベストプラクティスを行うことができます。
- 仮想デスクトップ実装における要件をとらえることができます。
リージョンの考慮事項
サービスの可用性
2020年6月時点で、US East, US West, Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Tokyo), EU (Frankfurt), EU (London)のリージョンでAmazon Connectを利用可能です。今後他のリージョンへ拡張を行う予定です。
Amazon Connectと他のAWSサービスをインテグレーションする際、そのサービスがConnectと同じリージョンで利用可能かどうかを検証する必要があります。例えば、2020年6月時点で東京リージョンではLexをAmazon Connectへインテグレーションすることはできません。
(補足)Lexは6月末に日本リージョンで使用可能となりましたが、日本語対応はしていません。
ユーザーとサービス
可能な限り、ユーザーとサービスは同じリージョンにある必要があります。それができない場合は、サービス全体の品質を検証するメカニズムを実装する必要があります。
(補足)Amazon Connectでは通話を扱うので、レイテンシーの品質はカスタマーエクスペリエンスにおいて非常に重要です。また、運用開始後の管理面でもリージョンを分けると複雑になります。
サービスクォータ
Amazon Connectには、リージョンのパフォーマンスを確実に担保するために存在するデフォルトの制限があります。一部のサービスクォータはサポートチケットから増やすことができますが、調整できないものもあります。
Amazon Connectデプロイの設計フェーズが始まったら、想定されるユースケースに対してサービス制限を評価し、開始時に制限緩和が必要なクォータの増加をリクエストすることをお勧めします。
(補足)サービスクォータの詳細についてはぜひこちらの記事を参照してみてください!
Amazon Connectのサービスクォータ(制限)について
サポートチケットの起票方法
- 承認プロセスを容易にするために、基幹業務と、制限の引き上げで達成しようとしていることを必ず説明してください。 (補足)同時通話数の引き上げやSMSの金額制限緩和などは利用用途の詳細説明が求められます。
- 通話量(日と月のピークと同時)、平均通話時間、エージェント数、予測される増加など、できるだけ多くのデータを含めます。
- (制限)ドロップダウンでは、事前定義された制限のリストから選択できます。リストに表示されていない制限を引き上げることはできません。
- テクニカルアカウントマネージャー(TAM)がいる場合、サポートチケットを開くことはできません。チケットを開く必要があります。ただし、チケットに自動的にコピー(cc)されます。
- (補足)クラスメソッドさんから発行したアカウントの場合、クラスメソッドメンバーズ内からチケットを作成します。
テレフォニー
テレフォニーは、すべてのAmazon Connectコンタクトセンターの展開の基盤です。AWSはキャリアとして機能しますが、移行を円滑に進めるために実行できる手順がまだあります。
テレフォニーを立ち上げるための重要なステップ
- プロジェクトの初期段階で移行のための要件をまとめ、それらを完了するための十分な時間を確保します。
- ユースケースにおける、インバウンド/アウトバウンドの対象となる国を確認します。CCPのドロップダウンリストに対象の国がない場合、制限緩和の申請を行います。
- 発信者ID(発番表示される番号)がデフォルトのアウトバウンドキューで設定されたものであることを確認して、発番通知をテストします。
発信者IDはキャリアレベルで変更でき、Amazon Connectは一つのリージョンで複数の通信キャリアを使用しています。複数のキャリアに負荷分散を行って発信を行うため、何回か発信テストを行います。
(補足)これについては下記リンクにて米国についての詳細がありますが、東京リージョンでどうなっているかは公表されていません。 https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/concepts-telephony.html - 予想される呼量を想定したテストを行います。
通話品質とレイテンシーをテストするために、以下のツールを使用することができます。
CCP Connectivity Tool
問い合わせフロー
設計理念
問い合わせフローは、コンタクトセンターのカスタマーエクスペリエンスを最初から最後まで定義します。 Amazon Connectの強力な問い合わせフローエディタにより、ユーザーは顧客とのやり取りを簡単に作成できます。 ツールが使いやすいということは、最初からベストプラクティスを確立することが重要であることを意味しています。
- モジュール化
必要性に応じて、問い合わせフローを小さくモジュール化することができます。 モジュール化した問い合わせフローは、完全な顧客体験に組み合わせたり、複数の対話シナリオで使用したりできます。 モジュール化することで問い合わせフローを管理しやすくなり、テストサイクルを減らすことができます。 - 分類
命名規則ではすべてのAWSサービスと同様にキャメルケースを使用します。 さらに、複雑なソリューションを展開している場合、命名規則内に属性を追加すると将来的に参照が容易になります。 - 権限
Amazon Connectが、問い合わせフロー内の参照されるすべての他サービスとのインテグレーションポイントに対して適切なアクセス許可を持っていることを確認してください。
問い合わせ属性
問い合わせ属性名には、それ以降の処理に影響を与えるようなスペースや特殊文字は使用しないでください。 問い合わせ属性の設定ブロックでは必要なデータのみ保存していることを確認してください。
設定した属性はすべて問い合わせ追跡レコード(CTR)データの一部として保存されます。
問い合わせフローの構築
問い合わせフローを標準化することで機能要件を確実に満たしながらビルドプロセスを合理化することができます。
ログ記録動作の設定
ログ記録動作の設定ブロックを使用して、CloudWatchに保存できない機密情報が収集される連絡フローのセグメントのロギングを有効または無効にします。
エラーブランチ
お客様の要件に基づいて、すべてのエラーブランチが一貫して処理されるようにします。問い合わせフローを構築する前に、必要なエラー処理動作を定義します。
通話録音ブロックの設定
Amazon Connectは、要件に応じて、エージェントのみ、顧客のみ、またはエージェントと顧客の両方の通話を100%記録できます。コンタクトフローの通話録音ブロックを設定して、Contact Lensをアクティブにすることができます。これにより、相互作用の機械学習分析が提供されます。
ルーティングロジックブロック
コールがエージェントにルーティングされる際は、コンタクトのオペレーション時間の確認ブロックと人員の確認チェックブロックをキューへ転送ブロックの前に挿入して、コンタクトが営業時間内にあり、コンタクトに対応するエージェントが存在することを確認してください。
ユーザーアクセス
Amazon Connectは、組織のIDプロバイダーと簡単にインテグレーションできます。さらに、これらのベストプラクティスに従うことで、コンタクトセンター環境へのアクセスが適切に保護されます。
- すべてのプロファイル権限が可能な限り制限されていることを確認し、ユーザーの役割に絶対に必要なリソースへのアクセスのみを許可します。たとえば、Amazon Connectでユーザーの作成、読み取り、更新する権限をエージェントに付与しないでください。
- 多要素認証(MFA)がSAML 2.0 IDプロバイダーまたは該当する場合はRADIUSサーバーを介して設定されていることを確認します。構成されている場合、Amazon Connectログイン画面に3番目のテキストボックスが表示され、2番目の要素が提供されます。
- ID管理にAmazon Directory ServiceまたはSAMLベースの認証を通じて既存のディレクトリを使用している場合は、ユースケースに適したすべてのセキュリティ要件に従っていることを確認してください。詳細については、AWS Directory Serviceのドキュメントを参照してください。
(補足)SalesforceをIDプロバイダーとして設定する方法はこちら!
SalesforceからAmazon Connectへシングルサインオンする
インテグレーションのベストプラクティス
Amazon Connectのデプロイとは、ビルディングブロックとして追加のAWSサービスを使用することを意味します。設計プロセスを通じて、ユースケース内の各AWSサービスと、ユースケースに適用可能なサードパーティ統合ポイントを特定します。各サービスについて、リージョンの可用性とコンプライアンス/認定資格を確認し、ギャップを特定します。
デプロイ
Lambda
ターゲットのサードパーティ統合に、必要なすべての認証、ユースケースへの準拠、およびAPI呼び出しで送受信されるデータのタイプがあることを確認します。
サードパーティのAPIのレイテンシは、通話体験に影響を与える可能性があります。理想的には、ターゲットの統合テクノロジースタックはAWS内にあり、統合サービスと同じリージョン内にあります(例:Lambda / Lex)。
Lambda関数が適切なレベルの情報をCloudWatchに記録し、ログを記録する前に機密情報を削除することを確認します。重要な機能の重要な失敗時にエラーがCloudWatchに記録されていることを確認し、これらのエラーに対してCloudWatchメトリクスのアラートを設定します。
Amazon Lambdaを使用してコンタクトフロー内からサーバーレスコンピューティングを埋め込むと、ユーザーはソースデータと簡単に統合し、外部ソリューションで拡張機能を有効にすることができます。
ストレージ
S3
Amazon Kinesisを使用してAmazon Connectデータをサードパーティの消費または統合のためにS3にエクスポートする場合は、統合のユースケースに該当する情報のみを送信していることを確認してください。
統合の機能に絶対に必要なデータのみを提供する必要があります。
レコードのソースのトリガーとなるステップ関数を使用して、統合ポイントに配信する前に適切な情報をフィルタリングします。
すべてのバケットポリシーがデフォルトでAWS Key Management Service(KMS)と互換性があることを確認します。
Amazon Connectは、S3へのアクセスに適切なアクセス許可を適用して、通話の録音とスケジュールされたレポートを適用します(該当する場合)。バケットポリシーを変更する必要がある場合、または既存のバケットを使用する必要がある場合は、行った変更がAmazon Connectの機能に意図しない影響を与えないようにしてください。
データベース
DynamoDB
列/キー名が標準の命名規則に従っており、スペースや特殊文字を使用していないことを確認してください。スペースまたは特殊文字を使用すると、AWS Glueクローラーなどのダウンストリームレポートプロセスに影響を与える可能性があります。
AI/ML
Lex
COPPAフラグ(児童オンラインプライバシー保護法)が発話データの保存を防ぐために適切に設定されていることを確認します。これは、ボットを段階的に改善するために発話の欠落を監視する機能に影響します。
収集されたデータが考慮され、適切に、また関連するサービスと地域の認定資格に従って処理されることを確認します。
デフォルトのエラーメッセージと再試行設定がユースケースに適切であることを確認し、障害が発生した場合でも、高品質のエクスペリエンスを提供してください。
すべての使用シナリオに、通話に対応する手段があることを確認してください。
Polly
音声合成(TTS)プロンプトに句読点を含めて、強調または一時停止を追加します。反映、呼吸、発音の合図を追加することにより、顧客により人間的なエクスペリエンスを提供するために、SSMLタギングの使用をお勧めします。
使用する音声と言語がユースケースに適していることを確認してください。
分析
Kinesis
ダウンストリームで使用するためにAmazon Connectデータをエクスポートまたはフィードする場合は、ユースケースに該当する情報と、統合に絶対に必要な機能のみをエクスポートまたはフィードしていることを確認してください。
注:Amazon Connectは、サーバー側の暗号化が有効になっているKinesisストリームへのデータの発行をサポートしていません。
CTRデータの場合、AWS Lambdaステップ関数を使用してレコードソースのOffをトリガーし、統合エンドポイントに配信する前に機密情報または不要な情報をフィルタリングできます。
メッセージ
なし
セキュリティ
IAM
ユースケースに適用できるロール/ポリシーの変更について、CloudWatchでモニタリング/アラートを設定します。
AWS Directory Service
必要に応じて、Amazon Connectインスタンスに対してDirectory Services / Identityプロバイダーが設定されていることを確認します。
Amazon ConnectとのActive Directoryの統合はインスタンスの作成時に行う必要があり、インスタンスの作成後に変更することはできません。
ID管理オプションを変更するには、新しいインスタンスを作成し、インスタンスの作成時にそのオプションを選択する必要があります。
マネジメント
Cloud Watch
CloudWatchが有効であり、必要に応じてアクティブであることを確認します。
機密情報がCloudWatchログに保存されていないことを確認します。
関連するすべてのCloudWatchメトリックスとエラーアラートが有効になっており、構成されていることを確認します。
サードパーティの統合ポイントを特定します。
(補足)Amazon ConnectのCloudWatchメトリクスとアラームの設定については以下の記事をどうぞ!
ConnectのCloudWatchメトリクス
CloudWatchアラームでAmazon Connectを監視・通知する
DevOpsのベストプラクティス
Amazon Connectソリューションをより迅速かつ確実に構築できるようにするDevOpsのベストプラクティスです。
Polly
AWSコンソールのPollyでPollyの音声合成(TTS)プロンプトをテストします。これにより、Connectを呼び出さなくてもプロンプトを聞くことができ、SSMLテストでも機能します。 音声合成マークアップ言語(SSML)を使用して、アクセント/音素を追加し、国際音声文字(IPA)要素と拡張音声評価方法音声文字(X-SAMPA)要素を活用して個性を追加します。
サポートされているSSMLタグについては、こちらを参照してください
Supported SSML Tags
Lambda
AWSマネジメントコンソールの代わりにAWS SDK /外部統合開発環境(IDE)を使用してLambda関数を編集および作成すると、ブラウザーのタイムアウトとブラウザーの使用に関連するキャッシュの問題を防ぐことができます。 AWS Cloud9 はクラウドベースの統合開発環境(IDE)です。
AWSマネジメントコンソールを使用している場合は、テストの準備ができたら、ローカルソースからコードをコピーして貼り付けることができます。
AWS Cloud9を使用すると、AWSアカウントからAWS Lambda関数にアクセスできます。 AWSマネジメントコンソールを使用している場合は、キャッシュの問題を回避するために、同じLambda関数に対して複数のウィンドウを開かないでください。
Lambda関数の各バージョンをリポジトリに保存して保存し、変更を加える前にコードをバックアップします。
変数のキャメルケースなど、標準的で一貫した命名規則を使用します。
マルチステージテスト環境のセットアップ
必要な状態ごとに個別のAWSアカウントを作成します(所有者:AWSアカウント管理者)。
複数のアカウントの利点:
- アカウントごとに異なるクレジットカードを設定して、適切なコストセンターに請求したり、単一の請求構成でコストを組み合わせたりできます。
- AWSリソース間の安全な線引を行うことができます。
- 部門ごとに異なるアカウントとセキュリティ所有者を割り当てます。
- 他のステージまたはアカウントで使用されているリソースの意図しない変更を防止します。
- IAMの制御と構成が簡素化され、同じアカウントのすべてのステージでユーザーを構成する必要がなくなります。
- IAMユーザーと、ユーザーのステージと役割に関連する権限を追加して構成します。
- AWS API呼び出しに必要なユーザーキーを設定します。
- IAMユーザーをActive Directoryと統合します。
- IAMユーザーの多要素認証を構成します。
- ステージ固有の構成を除いて、インスタンス構成が同一であることを確認します(例:ユーザー、キュー、ルーティングプロファイル、およびクイック接続はステージ間で異なる可能性が高い)。
- ケースに該当する場合は、IDプロバイダー/ ADとのインスタンス統合を有効にします(詳細については、Amazon Connect Active Directory統合オプションを参照してください)。
注:グローバルに一意であるため、各アカウントに同じAmazon Connectインスタンスエイリアスを使用することはできません。本番環境より低いレベルの環境では、共通の識別子を使用します(例:MyInstanceDev、MyInstanceQA、MyInstanceStaging、MyInstanceProd)。
問い合わせフロー
- 属性名の宣言にはキャメルケースを使用してください。
- PlayプロンプトブロックのTTSで増分バージョン管理を使用して、変更が確実に反映され、最新バージョン、つまり「これはバージョン2です」を聞いていることを確認します。
- 問い合わせフローブロックに入力する問い合わせフローの名前と値には、標準的で一貫した命名規則を使用してください。
- Contact Flow exportを使用して、選択したリポジトリー内のすべてのフローのすべてのバージョンをバックアップします。詳細については、コンタクトフローのインポート/エクスポートを参照してください。
- 小さなモジュール式の連絡フローを作成し、「メイン」フローから転送して、連絡フローロジックを読みやすく維持できるようにします。
問い合わせフローの更新
- 変更が下位レベルであることを確認し、次のステージへの展開を承認します。
- キュー、リソースARNなどの問い合わせフローの依存関係、およびスコープ内にある必要がある他のフローでのこのフローへの参照に注意してください。
- 次のステージインスタンスですべてのフローの依存関係にアクセスできることを確認し、この変更の範囲内の他のすべてのフローがこのロールアウトに含まれていることを確認してください。解決されない参照があると、フローの特定の部分が失敗し、連絡フローを公開できなくなる可能性があります。公開できない場合は、次のドキュメントの「リソースの解決」を参照してください:インポートしたコンタクトフローのリソースを解決する
- 連絡フローをエクスポートし、バックアップして、次のステージのインスタンスにインポートします。
- 新しい連絡フローにテスト番号を割り当て、機能を確認するためにテストコールを発信します。
- 検証されたら、電話番号の割り当てを古いフローから新しいフローに変更します。
- 注:依存関係が不足していると、フローが公開されなくなります。
- 各段階を繰り返します。
エージェントのVDI(仮想デスクトップ)
仮想デスクトップインフラストラクチャ(VDI)環境は、発信者とエージェントの両方のエクスペリエンスの品質を最適化するためにPOCとパフォーマンステストを必要とするソリューションにさらに複雑なレイヤーを追加します。Amazon Connectコールコントロールパネル(CCP)は、シック、シン、ゼロクライアントVDI環境で動作できます。構成とサポートは、VDIサポートチームが最適に処理します。
以下は、VDIベースのお客様に役立つ考慮事項とベストプラクティスのコレクションです。
通信網
- エージェントのロケーション
理想的には、エージェントは、VDIホストの場所への往復時間が最も短いホップのできるだけ少ない場所に配置されます。 - VDIソリューションのホストの場所
理想的には、VDIホストの場所は、エージェントと同じネットワークセグメント上にあり、内部リソースとエッジルーターの両方からのホップをできるだけ少なくします。また、WebRTCとEC2の範囲のエンドポイントの両方で可能な最小の往復時間を求めます。 - 発信者の場所
理想的には、呼び出し元は、Amazon Connectインスタンスと同じリージョン内のソースであるか、呼び出し元とAWSリージョンの間の可能な限り最短距離です。 - ネットワークアーキテクチャー
多くのVDI環境はハブアンドスポークです。つまり、パブリックWANに到達するには、他のいくつかのネットワークセグメントを中継して、多くの場合広範囲をカバーする必要があります。トラフィックをルーティングするために必要なホップが多いほど、障害ポイントが増え、レイテンシが発生する可能性が高まります。基になるルートが最適化されていない場合、またはパイプの速度が十分でない/十分でない場合、ハブアンドスポーク環境は特に通話品質の問題の影響を受けやすくなります。ダイレクトコネクトはエッジルーターからAWSへの通話品質を向上させることができますが、このハブアンドスポークトラフィックは通常内部で行われるため、LANをアップグレードするか、ルートを変更して通話の音声の問題を回避する必要がある場合があります。 - エージェントのネットワーク要件
エージェントはオンプレミスまたはリモートであり、ワークステーションにアクセスするためにVPNが必要になる場合があります。VPNレイテンシとエージェントの個人ISPは、通話品質に大きく影響する可能性があるため、考慮する必要もあります。理想的には、エージェントはVDI環境と同じネットワークセグメント上にあり、リモートではなく、VPN経由で接続しないことが理想的です。 - 帯域幅
ベストプラクティスは、エージェントが持つ可能性のある他のネットワーク要件に加えて、エージェントごとに100〜150 kbのスコープを設定することです。 - Direct Connect
ダイレクトコネクトは、エッジルーターとAWSリソース間の遅延と通話品質の低下を解決できます。ご使用のVDI環境によっては、パブリックWANを経由するのではなく、専用ルーターを介してAWSトラフィックをリダイレクトするようにエッジルーターを構成する必要があるため、ダイレクトコネクトを利用できない場合があります。VDI環境がローカルのDXC対応ネットワークの外部でホストされている場合、直接接続を十分に活用できません。 - 画面キャプチャとAmazon Connectデータの連携
Amazon Connect Streams APIを利用して、サードパーティの画面記録ソリューションにフラグを設定し、Contact Trace Record(CTR)データに関連付けることができますが、これはカスタムです。それ以外の場合、画面記録をAmazon Connectデータに関連付けることは、今日の手動プロセスです(通常、電話番号=> agentID =>画面記録を検索して行われます)。 - 専用ネットワークセグメント
同じセグメントを実行している可能性のある他のソリューションとの競合を回避するために、ネットワークリソースを専用にする必要があります。たとえば、大容量ファイルの転送、メディアストリーミング、バックアップなどです。
テレフォニー
- エージェントの既存のデバイスを再ルーティング
オーディオを再ルーティングすることを選択した場合、追加のレイテンシが導入される可能性があるため、それらを考慮する必要があるため、Amazon Connectリージョンに対するデバイスの位置に注意する必要があります。 - 通話の転送と転送(例:別のベンダーから番号を要求し、それらの通話をAmazon Connectに転送する)
特に地理的に離れた場所でオーディオをリダイレクトする場合、オーディオ遅延として現れる遅延が発生する可能性があります。これは非VDI構成の場合にも当てはまりますが、エージェントとVDIクライアント間の余分なホップが原因で、VDI環境ではこれらの症状がより顕著になる可能性があります。 - 循環転送
Amazon Connectから転送されて戻ってくる通話は、追加のテレフォニーコストと公衆交換電話網(PSTN)遅延の導入の可能性があるため、可能な限り回避する必要があります。
ワークステーション
- 2GB専用メモリ
エージェントが使用する可能性のある他のアプリケーションに加えて、ブラウザからAmazon Connectにアクセスするために、少なくとも2GBのメモリをスコープする必要があります。追加のブラウザウィンドウを開く必要がある場合は、それらのメモリ要件も考慮する必要があります。 - USBデバイス
最高のエージェントとカスタマーオーディオエクスペリエンスのために、USBヘッドセットが推奨されます。または、エージェントの既存のテレフォニーを使用して、コールを外部のE.164番号にリダイレクトすることもできます。 - リモート接続専用のエンドポイント
エージェントがVDIを使用して別のリモートエンドポイントにジャンプする場合、異なるビジネスユニットのユーザーがリソースを異なる方法で使用するため、競合を避けるために、そのエンドポイントをそのエージェントリソースプール専用にする必要があります。エクスペリエンスの質への影響を回避するために、エージェントデバイスとリモート接続の間の待ち時間は100ミリ秒未満である必要があります。 - リモート接続でソフトフォンを使用する
エージェントがVDI環境からリモートエンドポイントに接続し、その環境で動作する場合は、オーディオを外部E.164エンドポイントに再ルーティングするか、ローカルデバイスを介してメディアを接続し、リモート接続を介してシグナリングを行うことをお勧めします。コールシグナリング用のメディアレスCCPを作成することにより、ストリームAPIを使用してカスタムコールコントロールパネル(CCP)を構築できます。このように、メディアは標準のCCPを使用してローカルデスクトップで処理され、シグナリング/コール制御はメディアレスCCPとのリモート接続で処理されます。ストリームAPIの詳細については、https://github.com/aws/amazon-connect-streamsにあるGitHubリポジトリを参照してください。
データガバナンス
該当するすべてのデータガバナンスが、ユースケースの国で遵守されていることを確認します。データガバナンスの要件は国によって異なり、変更される可能性があるため、ケースバイケースで評価する必要があります。
個人を特定できる情報(PII)
ユースケースで使用されるすべてのサービスとサードパーティの統合ポイントについて、コンプライアンス適格性監査を実施します。
Amazon Key Management Service(KMS)は、S3のデフォルトでレコーディング、ログ、保存されたレポートをカバーするオブジェクトレベルでAmazon S3コンテンツを暗号化しますが、転送中の暗号化と保管中のルールがダウンストリーム/サードパーティにも適用されることを確認してください。
機密性の高いデュアルトーンマルチ周波数(DTMF)情報のストア顧客入力で暗号化を使用します。
支払いカード情報(PCI)
ユースケースで使用されるすべてのサービスとサードパーティの統合ポイントについて、コンプライアンス適格性監査を実施します。
支払いカード情報(PCI)は、暗号化されたDTMFを介して収集する必要があります。 PCIが通話録音でキャプチャされた場合、PCIデータを録音から削除し、ログや文字起こしから難読化する必要があります。
ダウンストリーム統合ポイントの転送時および休止時の暗号化。 Amazon Connectはパブリックエンドポイントであるため、PCIへのアクセスには多要素認証(MFA)が必要です。
Amazon ConnectのPCI収集方法。 SecureIVRは、支払いが処理されたときに発信者がエージェントに戻ることができるカスタムデスクトップソリューションであり、エージェントを自動的に保留にして、聞く機能を削除します。支払いが完了すると、SecureIVRは通話をオフにします保留、録音の再開、およびエージェントと発信者間の対話を続行できます。
コールストリームAPI(https://github.com/aws/amazon-connect-streams)を利用して、転送をエージェントに保留させるカスタムデスクトップを作成します。
発信者が支払う準備ができると、エージェントは発信者をインバウンドコンタクトフローに転送し、暗号化されたDTMFを介して支払い情報を収集します。これは、対話型音声応答(IVR)の対話を記録しないため機能します。ただし、エージェントは、転送が行われた後も通話を続け、録音を続行することを決定できます。
リスク:エージェントは通話を体系的に制御せずに音声にアクセスできるため、内部の脅威となる可能性があります。
エージェントがPCIを収集し、記録からPCIをスクラブできるようにします。
リスク:インサイダーの脅威があります。技術によっては、エージェントがカード情報を聞くときにそれを書き留めることはできません。これは言われていることであり、推奨されるソリューションではありません。
Amazon Key Management Service(KMS)は、S3のデフォルトでレコーディング、ログ、保存されたレポートをカバーするオブジェクトレベルでAmazon S3コンテンツを暗号化しますが、転送中の暗号化と保管中のルールがダウンストリーム/サードパーティにも適用されることを確認してください。
機密のDTMF情報に対してストアの顧客入力で暗号化を使用する詳細については、https://www.pcisecuritystandards.orgにある資料を参照してください。
健康保険の相互運用性と説明責任に関する法律(HIPAA)
ユースケースで使用されるすべてのサービスとサードパーティの統合ポイントについて、コンプライアンス適格性監査を実施します。
Amazon Key Management Service(KMS)は、S3のデフォルトで記録、ログ、保存されたレポートをカバーするオブジェクトレベルでAmazon S3コンテンツを暗号化しますが、転送中の暗号化と保管中のルールがダウンストリーム/サードパーティにも適用されることを確認してください。
機密のDTMF情報には、ストアの顧客入力で暗号化を使用します。 HIPAAコンプライアンスの詳細については、https://www.hipaacompliance.org/にある資料を参照してください。
おわりに
このベストプラクティスのコースはAmazon Connectに関して非常に網羅的にまとめられています。
逆にいうと、このコースをすべて理解していれば相当なレベルにあると思います。私も100%完全に理解できているかと言われると微妙。。なので、継続して勉強します!
今後もこちらの記事は少しずつアップデートし、主に補足記事などを追加していきたいと思います!
不明点や疑問点、こういう記事書いてほしいなどのリクエストがありましたら、お気軽にお問い合わせからどうぞ。
お問い合わせ