モチベーション
Amazon Connect からのパートナーテレフォニーを使用した Service Cloud Voice構築時に、開発環境や検証時に俊敏性を持って活動するため、1つのAWSアカウント内でService Cloud Voiceを試したいことがあると思います。
公式のドキュメントでは、複数のSalesforce組織に対して、1つの専用AWSアカウントを準備することがガイドライン1ではアナウンスされています。
しかし、AWSのブログ記事アーキテクチャマッピングパターンと考慮事項2によると、BYOA (Bring Your Own Amazon/AWS) モデル (Amazon Connect からのパートナーテレフォニーを使用した Service Cloud Voice)では、1つのAWSアカウント、1つのAmazon Connectインスタンスに対して、複数のSalesforce組織の構成は「Required Customization」となっています。
つまり、 技術的には複数のSalesforce組織に対して、1つの専用AWSアカウントの構成は可能であると言うことです。
本番運用ではリスクが伴うため、お勧めできません。
本ドキュメントでは、1つのAWSアカウントで複数組織のService Cloud Voiceとの連携の方法について説明します。
共存の構成図
手順の概要
1つ目のSalesforce組織から、プロビジョニングした後 IAM IDプロバイダーが上書きされないように手動でコピーを新規作成します。
その後、コピー後のIDプロバイダーはコピー後のARNに変化するため、Salesforce組織のSAML用接続アプリケーションのカスタム属性を修正します。
2つ目以降のSalesforce組織についてもプロビジョニングが完了した後、1つ目の組織と同様の手順を踏みます。
手順の詳細
1つ目のSalesforce組織から、Service Cloud Voiceのプロビジョニングが完了した状態からスタートします。
- AWS アカウントに管理者でログインします
- サービスの検索から
IAMと入力し、IAMの管理画面に移動します - 左メニューから [ID プロバイダー]を選択します
- ID プロバイダーの一覧から [SalesforceServiceVoiceIdp] を選択します
-
SalesforceServiceVoiceIdpの詳細画面で、下までスクロールしたところにある [メタデータをダウンロード]ボタンを押下します-
SalesforceServiceVoiceIdp.xmlファイルがダウンロードされます
-
- パンくずリストから1段上の [ID プロバイダ]を選択して、再度 ID プロバイダーの一覧画面に移動します
- [プロバイダーを追加]ボタンを押下します
- 作成画面で以下の内容を設定します
- プロバイダーの詳細
- プロバイダのタイプ:
SAML - プロバイダ名: 任意の名前 (ここでは、
SalesforceServiceVoiceIdp2ndとします) - メタデータドキュメント: [ファイルを選択]ボタンを押下し、ダウンロードした
SalesforceServiceVoiceIdp.xmlを選択
- プロバイダのタイプ:
- SAML 暗号化: 変更なし
- タグ: 変更なし
- プロバイダーの詳細
- 設定が完了したら、[プロバイダーを追加]ボタンを押下します
- IDプロバイダーのARNを控えます (値の例:
arn:aws:iam::012345678901:saml-provider/SalesforceServiceVoiceIdp2nd)
引き受けするIAMロールの信頼関係を修正します。
- IAMの管理画面の左メニューから [ロール]を選択します
-
${コンタクトセンターのAPI参照名}-SAMLRoleを探し選択します (ここでは、ContactCenterApiName-SAMLRoleというロール名として説明を進めます) - [信頼関係]タブを選択します
- [信頼ポリシー]を編集ボタンを押下します
-
$.Statement[0].Principal.Federatedを先ほど作成した、IDプロバイダーのARNで置き換えます - [ポリシーを更新]ボタンを押下します
信頼ポリシーの例
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::012345678901:saml-provider/SalesforceServiceVoiceIdp2nd"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"saml:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
続いて、Salesforceの設定を行います。
- Salesforce にシステム管理者でログインします。
- Salesforce の設定から [アプリケーション], [アプリケーションマネージャー]の順番に移動します
- API参照名が
${コンタクトセンターのAPI参照名}_Connected_Appの接続アプリケーションを探し出し、右のドロップダウンメニューから [参照] ボタンを選択します - [カスタム属性] セクションから、属性キー
https://aws.amazon.com/SAML/Attributes/Roleの [編集]ボタンを押下します - IDプロバイダーのARNの部分を作成した、IDプロバイダーのARNで置き換え [保存]ボタンを押下します
書式
'${IDプロバイダーのARN}' & ',' & '${引き受けるロールのARN}'
例
'arn:aws:iam::012345678901:saml-provider/SalesforceServiceVoiceIdp2nd' & ',' & 'arn:aws:iam::012345678901:role/ContactCenterApiName-SAMLRole'
標準でデプロイされる"SalesforceServiceVoiceIdp"を選択
SalesforceServiceVoiceIdpのメタデータをダウンロード
新しいIDプロバイダーを作成
接続アプリケーションからカスタム属性を修正
注意事項
us-east-1 にデプロイされた CloudTrail の証跡リソースのタグ orgId は後からデプロイされた組織によって上書きされます。
各々のSalesforce組織の操作内容 (例えばコンタクトセンターユーザーの作成など)の履歴が1つの証跡(S3バケット)に残ります。これはCloudTrail証跡がアカウントに対して1つのみしか作られないことの制約です。
つまり、本番と検証環境などを1つのAWSアカウントに共存させると証跡が汚れる点を受け入れなければならなくなります。
複数ある組織のうち1つの組織を削除するとき、us-east-1 のCloudFormationテンプレート SCVBYOATenantStack は削除しないでください。
IAMロール・ポリシーが消えるので全組織から利用できなくなります。
${コンタクトセンターAPI参照名}-SCVBYOAContactCenterStackで作成される、デプロイ先のリージョンのCloudFormationテンプレートのみ削除してください。
共存できる理由
LambdaにアタッチされるIAMロールが、コンタクトセンターごとではなく、us-east-1のスタックからデプロイされる一意な名前で問題ない理由は、各種ポリシーが許可するAWSのリソースについて、コンタクトセンターAPI参照名 の部分が入る部分がワイルドカードになっているため成立します。
留意点
将来のテンプレートの変更などで共存できなくなるリスクがあることは留意しておく必要があります。
リソースはデプロイのたびに上書きされてしまうため、異なる Service Cloud Voiceのバージョン例えば SCVコンタクトセンターのバージョン18.0 と 19.0は、原則共存できないです (機微情報の管理がパラメータストアからSecrets Managerに代わるなど仕組みが変化した時、共通の us-east1 でデプロイされる上書きされてしまうIAMポリシーに互換性が無くなってしまうなどケース)
参考URLと引用
ガイドラインの引用1
AWS アカウントは組織間で共有しないでください。Sandbox 組織を作成またはコピーしたら、その組織専用の AWS アカウントを作成します
-
Service Cloud Voice と Amazon Connect に関する Sandbox 組織のガイドライン
https://help.salesforce.com/s/articleView?id=service.voice_sandbox_guidelines.htm&language=ja&type=5 ↩ ↩2 -
アーキテクチャマッピングパターンと考慮事項
https://aws.amazon.com/jp/blogs/apn/integrating-amazon-connect-natively-into-salesforce-using-service-cloud-voice/ ↩