≪  2020.03.19 「Salesforce - Spring '20 新機能をチェック（５ - 最終回）：開発者向け機能、コミュニティ、Pardot 連携」

2020.04.03 「【特別編】 Salesforce を軸にテレワークを導入する際の考慮事項、およびウフルの取り組みについて」 ≫

 

お世話になっております。
ウフル カスタマーサポート Salesforce 担当の 後藤 でございます。

 

Spring '20 のリリースから一ヶ月少々、新機能紹介シリーズも先週で一段落いたしましたので、今週から新シリーズ・・・の予定でしたが、最近複数のお客様から特定の内容でのお問合せを受けることがあり、多くのお客様にも関わってくる重要な内容なため、今回は不定期シリーズ「よくあるお問合せを深掘りします」と題して、通常サポートの回答ではご案内することのない詳細まで、しっかりとご案内させていただきたいと思います。

 

今回取り上げるのはこちらの２題です。

• 組織のインスタンス移行への備え
• セキュリティアラートへの対処

 

 

 

＊ 組織のインスタンス移行への備え

 

Salesforce が「マルチテナントのクラウドサービス」であることは皆様既にご存知かと思われます。

 

Trailhead モジュール - Salesforce アーキテクチャについて
https://trailhead.salesforce.com/ja/content/learn/modules/starting_force_com/starting_understanding_arch

 

「マルチテナント」は、よく「複数の棟を持つマンション群」に例えられます。
「マンション群」があり、そのなかに複数の「棟」があり、一つの棟には複数の「号室」があり、その「号室」がお客様の組織に相当します。

Salesforce にログインした際に、ホームページ URL に注目してみてください。

 

https:// ap3 .salesforce.com/

 

この URL の "ap3" が、「マンション群 - 棟番号」を表しています。
これが「インスタンス」と呼ばれるものです。

 

Salesforce のインスタンスは、データセンターの所在地によっていくつか存在し、お客様はご契約の国によって以下のインスタンスに振り分けられます。

• NA： 北アメリカ（アメリカ合衆国、カナダ、中南米諸国）
• EU： ヨーロッパ（EU諸国および北欧、ロシア、中東、アフリカ諸国）
• UM： イギリス
• AP： アジア太平洋（日本、アジア諸国、オーストラリアおよびニュージーランド）

 

弊社経由でライセンスをご購入いただいているお客様は、多国籍使用を前提とした例外対応のお申し込みをされた場合を除き、AP インスタンスに属しています。

 

各インスタンスはそれぞれ２箇所のデータセンター（AP インスタンスの場合は神戸と東京）を持っており、システムに不具合が発生した際にもう片方を瞬時に呼び出せるよう、完全に冗長化されています。

 

Salesforce インスタンスの場所は?
https://help.salesforce.com/articleView?id=000314281&language=ja&type=1&mode=1

 

古くなったマンションが修繕工事を必要とするのと同様に、Salesforce のデータセンターもまた、サーバーのストレージドライブやネットワークアダプタといった物理的パーツの交換などのメンテナンス作業が不可避となります。

小規模なメンテナンスならば、先述の冗長化によって数分間のサービス停止もしくは読み取り専用モードで済むことが多いですが、時として 「AP3 棟を集中工事するので、住人丸ごと AP17 棟に移ってもらう」といった大規模修繕が発生することがあり、その「お引越し」が、Salesforce で「インスタンス移行」と呼ばれるものです。

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

インスタンス移行は、後述するヘルプに記載のとおりお客様組織に大きな影響をもたらすため、およそ２ヶ月近く前から予告されます。

 

具体的にどのような影響があるのか、公式ヘルプを見てみましょう。

 

組織の移行への準備方法
https://help.salesforce.com/articleView?id=000334938&language=ja&type=1&mode=1

 

主なところでは以下のものになります。

• メンテナンス実施中のサービスへのアクセス
• IP アドレス制限を掛けている場合のホワイトリスト更新
• ハードコート化された参照の更新
• メンテナンス実施後のインテグレーションの更新

 

まず「メンテナンス実施中のサービスへのアクセス」ですが、こちらはインスタンス移行に限らずすべてのメンテナンスに共通して「メンテナンスの規模によって制限を受けるレベルが変わる」ので、事前のご案内を必ずご確認いただくようお願いをしております。

可用性レベルはおおむね以下の通りです。（下に行くほど制限の度合いが高い）

1. 通常通りログイン可能、通常通りの使用が可能、但し数秒間の瞬断が発生する可能性あり
2. 通常通りログイン可能、但しリードオンリー（読み取り専用）モードのため、作成と編集ができない
3. メンテナンスが完了するまでログイン不可

 

リードオンリーモードで受ける制限については、公式ナレッジに記事がございます。

 

リードオンリーモードの概要
https://help.salesforce.com/articleView?id=000334690&type=1&mode=1

 

単にレコードの保存ができないだけでなく、ファイルのダウンロードやレポートの実行など「システム上に一時データが発生する」作業にも影響が出る点にご注意ください。

併せて、インテグレーション（外部連携）を実装している組織では、送信側組織がリードオンリーモードの場合はバッチが実行されないため「何もなかったこと」になり、受信側組織がリードオンリーモードの場合は、送信側の設定によって再試行が行われます。

Web-to-リードおよびケースについては、リードオンリーモード中は待機キューに保存され、メンテナンス完了後に順次取り込まれるため、特に施策は不要とのことです。

 

次に「IP アドレスのホワイトリスト更新」についてです。

お客様の社内ネットワークでは、セキュリティ上の施策から、アクセスできる社外インターネットサービスに制限を掛けている場合があるかもしれません。
その場合、アクセス可能なサイトの IP アドレスをホワイトリスト登録し、登録のないサイトへのアクセスを制限する方法を取られていると思われます。

インスタンス移行によって、プライマリのデータセンターが神戸から東京に変更された際に、ホワイトリストに神戸データセンターの IP アドレスしか登録されていない場合、移行後のアクセスに制限が発生することが考えられます。
このようなことが無いよう、Salesforce では「ヘルプに記載の IP アドレスはすべてホワイトリストに登録するように」指示がされています。

データセンターの増設によって IP アドレスの追加が発生することもあるため、社内ネットワークからの外部アクセス制限を掛けているお客様では、以下のヘルプをお気に入りに登録し、定期的に更新履歴をご参照いただくことをお勧めいたします。

 

ホワイトリスト登録が必要な Salesforce の IP アドレスとドメイン
https://help.salesforce.com/articleView?id=000321501&type=1&mode=1

 

次に、ハードコード・・・を一旦飛ばして、 「インテグレーション（外部連携）の更新」 についてです。

外部基幹システムから Salesforce にデータを投入するよう構築されている場合、インスタンス変更によってエンドポイント URL や接続先 IP アドレスなどのインテグレーション情報に変更が発生します。

通常はメンテナンス完了後の同期実行時にインテグレーション情報が更新されるため、一般的には特に施策不要なことが多いですが、稀に更新前の情報が DNS にキャッシュされていることで同期に失敗することがあるため、管理者の方には、メンテナンス完了後に問題が発生した際に、インテグレーションの再起動および DNS キャッシュの削除を行えるよう、予め準備をしておくことをお勧めいたします。

 

さて、本件の「本丸」、「ハードコート化された参照の更新」についてたっぷりとご案内いたします。

そもそも「ハードコート化された参照」とはどのようなものでしょうか。
公式ヘルプでは次のように定義されています。

 

ハードコード化された参照の更新
https://help.salesforce.com/articleView?id=000335670&type=1&mode=1

 

===========================================================
大まかに言うと、ハードコード化された参照とは、インスタンス名 ( NA25、AP2、EU4、CS10 など) が含まれる URL です。

Salesforce 組織にハードコード化されたインスタンス固有の参照がある場合にインスタンスリフレッシュや組織移行メンテナンスが行われると、インテグレーションやメールテンプレート、ナレッジ記事、カスタマイズ設定などに支障が生じる可能性があります。たとえば、インテグレーションが破断したり、メールに記載されたリンクや画像が壊れたりすることがあります。
===========================================================

 

「ハードコート化された参照 ＝ インスタンス名を含む URL」とご認識いただければさしあたっては問題ないようです。

では、ハードコート化された参照を使用する場面・・・の前に、Salesforce 上で URL を使用する場面にどのようなものがあるかを確認してみましょう。

• カスタムリンク＆カスタムボタン
• Visualforce
• 外部基幹システムとのインテグレーション
• メールテンプレートやナレッジの画像

 

カスタムリンクおよびカスタムボタンが、一般的に最も多く URL が使われる場面になります。

では、カスタムリンクおよびカスタムボタンにてハードコード化された参照を使用するサンプルをご覧ください。

 

上記キャプチャは、ケースの詳細から「アップセル／クロスセル商談」を作成するサンプルです。
新規商談作成画面の URL に対し、商談取引先にケース取引先を、商談名に「Up-sell / Cross-sell」、商談種別に「Existing Customer」、リードソースに「Customer Support」を固定値で差し込む仕組みになっています。

URL の始まりが  https://ap3.salesforce.com/006/e ? ... つまり「AP3 インスタンス上の設定」を参照するようになっています。
このままでは、インスタンスが AP17 に移行した後でも「本来存在しない AP3 上の設定」を見に行くようになり、適切なアクセスができなくなる可能性が高くなります。
インスタンス移行後でも一応は「リダイレクト」の救済措置があるとヘルプには記載がありますが、永続的な保証はなく、パフォーマンスにも影響が出るとされているため、やはり事前の対処は非常に重要となります。

 

ハードコード化された参照の更新
https://help.salesforce.com/articleView?id=000335670&type=1&mode=1

 

===========================================================
4.ハードコード化された参照のうち、新しいインスタンスへの移動後に Salesforce サーバがリダイレクトできるのはどれですか?

 

ここで重要なワードが２つ出ました。

「私のドメイン」と「ハードコート化された参照をすべて削除」です。

まず「私のドメイン（マイドメイン）」ですが、URL のインスタンス名をユニークな文字列で置き換え、組織固有のサブドメインを生成して使用するというものです。

 

私のドメイン
https://help.salesforce.com/articleView?err=1&id=domain_name_overview.htm&type=5

 

===========================================================
ログインと認証の管理を向上するために、Salesforce 組織の独自のサブドメインを作成します。

サブドメインを使用することで、 https://yourcompanyname.my.salesforce.com  のように URL に会社名を含めることができます。
===========================================================

 

弊社でも社内組織で私のドメインを使用しています。

 

私のドメインを使用することのメリットは多々ありますが、インスタンス移行に関しては、「移行前と移行後で URL が変わらない」ことが最大のメリットになります。

先ほどのカスタムリンクの設定も、私のドメインを有効化することで以下のように変更できます。

 

 

私のドメインの有効化は、他にもシングルサインオン（SAML や OAuth）の実装、一部のサードパーティ AppExchange の導入、Lightning Web コンポーネントの使用などで必須要件となりますので、まだ有効化をされていない場合は、これを機にご検討を頂ければよろしいかと存じます。

 

Trailhead モジュール - [私のドメイン] を使用したログインプロセスのカスタマイズ
https://trailhead.salesforce.com/ja/content/learn/modules/identity_login/identity_login_my_domain

 

続いて、もうひとつの重要ワード、 「ハードコート化された参照の削除」 についてご案内します。

先ほどカスタムリンクの URL で「私のドメインでインスタンス名を置き換える」方法について言及いたしましたが、そもそも「同じ Salesforce 組織内でのページ遷移に、わざわざ絶対的なロケーション （インスタンス名にせよ私のドメインにせよ） を明記する必要はあるのか」、例えれば「同じ市内での電話で、発信の際に市外局番を含める必要はあるのか」という疑問が生じます。

同じ Salesforce 組織ならば、各ページは一意のサブドメイン配下での相対関係にあることは、Web に詳しい方ならすぐにお気づきになるはずです。

ならば、絶対的なロケーション識別子を省略して、現在のページから見てどの位置にあるページに遷移するか、の形式に URL を書き換えれば、インスタンス移行による絶対的ロケーション識別子の変更の影響を一切受けなくなります。

一般的には、ロケーション識別子を含む完全パス表示を 「絶対パス」 、現在の場所を基準に相対的な位置関係を示した部分パス表示を 「相対パス」 と呼びます。
例えば、先ほどの「ケース詳細から商談新規画面に遷移して取引先名を継承する」カスタムリンク URL の場合、絶対パスでは

 

 

これを、相対パスでは

 

 

に置き換えることができます。

確かに

 

 

も不正解ではないのですが、より推奨されているのは相対パスの方です。

 

「同じ組織内で遷移する」もの、つまり外部への発信を考慮しないカスタムリンクやカスタムボタン、Visualforce 内の URL はすべて相対パスで置き換え可能です。
一方、外部に発信する必要のあるもの、具体的にはメールテンプレートやナレッジの画像＆ページリンクについては、相対パスを使用することができません。

そのような場合は、私のドメインを有効化して、インスタンス移行があってもリンク先に影響が無いようにすることが重要になります。

 

まとめ：

インスタンス移行に対しては、以下のように備えればノープロブレムです！

• 私のドメインを有効化する
• カスタムボタンや Visualforce の開発者は、日ごろから相対パスを使うよう心掛ける
• あとはメンテナンス実施日を確認し、当該時間帯の外部連携のスケジュールを調整したり、社員に事前周知しておく

 

 

 

＊ セキュリティアラートへの対処

 

Spring '20 のリリース以来、画面上部に「セキュリティアラートを確認」メッセージが表示され、気になっている方も多いかと存じます。

＜Classic のセキュリティアラート通知＞

 

＜Lightning のセキュリティアラート通知＞

 

「重要なのはわかった、じゃあ具体的に何をすればいいの？」とお思いの方、推奨されるタスクは

 

「必須」マークの付いたセキュリティ更新をすべて有効化する

 

です。全部有効化すれば、新しい更新が追加されるまでアラートは非表示になります。

以上、何卒よろしくお願いいたします。

 

 

 

 

 

 

 

・・・一番の疑問点は「更新の有効化によって何がどう変わるのか」ですよね、失礼いたしました・・・。

 

Winter '20 から Spring '20 にかけてリリースされた「重要な更新」をリストアップいたしますのでご確認ください。

• ユーザプロファイルに基づくゲストユーザとポータルユーザの @AuraEnabled Apex メソッドへのアクセスの制限
• ゲストユーザ向けのセキュアオブジェクト権限
• ユーザプロファイルに基づく認証済みユーザの @AuraEnabled Apex メソッドへのアクセスの制限
• ゲストユーザプロファイルからの「すべてのユーザの参照」権限の削除
• ゲストユーザによって作成されたレコードのデフォルトの所有者への割り当て
• ゲストユーザの組織の共有設定と共有モデルの保護

 

一覧を見る限りでは、次の２パターンに大別できます。

• 「ゲストユーザアクセスの管理」
• 「@AuraEnabled Apex メソッドへのアクセス制限」

 

つまり、コミュニティ（Force.com Site および Site.com 含む）にてログイン認証不要のゲストユーザアクセスを有効化しておらず、コミュニティや Lightning アプリケーションページで Aura コンポーネントおよび Lightning Web コンポーネントを組み込んでいなければ、自動有効化の期限が来るまでそのまま放置しても、機械的にクリックして全部有効化してしまっても、実質的に問題ないと言えます。

逆に言えば、コミュニティで匿名アクセスを使用していたり、Lightning Web コンポーネントを組み込んでいる場合は、期限が来るまでに動作確認をしないと、いざ自動有効化されて想定外のアクセス制限が掛かったということになりかねません。

では、どのように動作確認をすればよいでしょうか。
公式ヘルプを見てみましょう。

 

セキュリティアラートの最新情報の取得
https://help.salesforce.com/articleView?id=security_updates_overview.htm&type=5

 

================================================================
警告 
各更新のテストは、Developer Sandbox またはピーク時以外の本番環境で行うことをお勧めします。
================================================================

 

つまり、以下の手順を段階的に踏むことが「もっとも推奨される」有効化手順となります。

1. 現在の本番環境を反映した Sandbox を作成または更新します
2. Sandbox 上で、優先度の高い順に更新を有効化します
3. コミュニティのゲストユーザアクセス、Lightning ページでの Aura / Lightning Web コンポーネントの挙動を確認します
4. この時点で動作に問題があれば、プロファイルのアクセス権限などを確認します
5. 引き続いて本番組織でピークタイムを外して同様に動作テストを行います
6. 問題が無いことが確認出来たら、必須の更新を全て有効化し、セキュリティアラートが表示されなくなったことを確認します

 

今後の重要な更新では、今回のような比較的限られた環境でのみ使用されている機能だけではなく、より汎用的な機能に関するものがリリースされる可能性も十分ございます。
今のうちに重要な更新の有効化手順に慣れておくと、後々作業がスムーズになると思われますので、せっかくの機会です、お時間ございます際に上記手順での有効化実施をお試しいただければと存じます。

 

まとめ： セキュリティアラートに対しては、以下のように備えればノープロブレムです！

• 最新の Sandbox でひととおり有効化して、本番組織同様の動作テストをしてみる
• 問題なければ、 金曜日夕方の本番組織で有効化してもう一度テストしてみる
• それでも何もなければ、月曜日にすべて有効化して、 メッセージが消えたことを確認する

 

 

 

===========================================================

不定期シリーズ「よくある問合せを深掘りします」の第一弾、如何でしたでしょうか。

実は、サポートコンサルタントとして一番「やるべきだと認識していた」シリーズがこちらになります。

今回は主に社内営業担当から「お客様から質問を受けているので、サポートから回答してほしい」とリクエストを受けたのが契機となっていますが、今後皆様から直接サポート宛に「このネタを深掘りしてほしい」リクエストを頂ければ、年三回のバージョンアップの新機能紹介シリーズ展開中以外は、優先度高で取り上げさせていただきますので、是非ご要望をお聞かせいただければ幸いでございます。

 

今後ともウフル カスタマーサポートを引き続きご愛顧いただきますよう、何卒よろしくお願い申し上げます。

Salesforce･Googleの運用･サポートでお困りなら

 カスタマーサポートへお問合せください。