(2022年6月) Salesforceの運用に関する重要なお知らせ

この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート​動画で学ぶhttps://play.vidyard.com/y8sBUf8h8bm8ME6JqcPG18全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ当記事は「Salesforce の運用に関するお知らせ」の6月号となります。前半は技術関連情報、後半はセキュリティ関連情報の構成で、特に重要な情報に絞ってご紹介いたします。お客様に必要なアクションにいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。まずは技術編です。2022年6月のトピックはこちらになります。本記事では、前月との差分である赤字の部分についてご紹介します。Summer ’22 のバージョンアップに向けた情報です。7/6, 7, 8, 13に新機能説明会がありますので、まだお申し込みしていないお客様は、Summer ’22 新機能リリースのサクセスナビより、ぜひお申し込みください。​関連リンクプレリリース環境サインアップSummer'22リリースノートリリースモジュールRODとFeature Matrixサクセスナビ : バージョンアップに備えましょうサクセスナビ：Summer '22 新機能リリース（新機能説明会のお申し込みはこちら）次に、Summer’22 リリースノートの更新情報です。リリースノートは定期的に更新されており、ここでは6月の更新情報のうち、特に管理者の皆様に知っていただきたいものを抜粋してご紹介いたします。なお、この情報は6/20時点のものとなります。最新情報はこちらのリンクよりリリースノートをご確認ください。​関連リンクUpdated Field History Data Retention Enforcement PeriodUpdated Data Retention Limit for Field Audit TrailDevOps Center (Beta)Enable Enhanced Domains (Release Update)​続いて、次は、IE11 のサポート終了に関するお知らせです。Microsoft 社による IE11 のサポートを終了の発表を受けて、Salesforce も IE11 のサポートポリシーのブログを公表いたしました。Salesforce は、お客様が十分な準備をする時間を確保するために、Microsoft 社のサポート終了日から６ヶ月間、ビジネスの停止に繋がる回避策がないような重要な問題（重要度1 またはそれ以上の問題）に限定してサポートを延長します。お客様に必要なアクションなどの詳細は関連リンク内の記事をご参照ください。関連リンクLightning Platform における IE11 サポート終了についてInternet Exploere 11 のサポート終了に伴い必要なアクションとは​​​改めてのご案内となりますが、機能の廃止に関連するすべての情報を 1 か所で簡単に見つけることができるように、 Salesforce 機能の廃止のダイジェストを月次でメールをお送りしています。メールを受信されている管理者様はお見逃しのないようにご確認をお願いいたします。今後の機能廃止予定の一覧です。新たな追加情報として、赤字部分の２点となります。メンテナンス計画の頻度種別項目の廃止対象：Field Service をご利用中で、メンテナンス計画をご利用中のお客様終了日：頻度項目は、Spring ’22 から段階的な廃止が始まっており、Spring ’23 で完全に廃止される予定です。必要なアクション：頻度項目に変わるメンテナンス作業ルールオブジェクトに移行をお願いいたします。JDK ロケール形式の廃止対象：Salesforce Platform をご利用中で、当該機能をご利用中のお客様終了日：Spring '23必要なアクション：Sandbox では2023年1月、本番では2023年2月に新しいロケール形式が自動的に有効になりますので、それまでに ICU ロケールに移行するようにお願いします。その他の廃止機能につきましても、ご利用中の機能がある場合は必ずご確認いただけますようお願いいたします。​​6月分の技術関連情報は以上となります。​​続きまして、セキュリティに関する情報をご紹介します。先月との差分は、MFA 適用に関する FAQ とロードマップ、Spring’23 のリリース更新、そして拡張ドメインの４点となります。まず、多要素認証(MFA)に関する更新情報です。FAQ が６月１日に更新されており、B2C Commerce Cloud と Quip をご利用のお客様において2022年5月に MFA が強制適用されたことが追記されています。次に、MFA 適用のロードマップについて更新内容としては２点となります。１つ目は Marketing Cloud Engagement における MFA 強制適用日です。Marketing Cloud Engagement では６月３０日までにMFA の強制適用が行われました。２つ目は Tableau Online の特権ユーザーに関するもので、７月１１日から７月１８日の間で強制適用が順次行われる予定です。関連リンク多要素認証 (MFA) 適用ロードマップ続いて、Spring’23 で適用されるリリース更新についてです。「SAML シングルサインオンフレームワークの更新」のリリース更新が適用されると、SAML フレームワークが更新され、セキュリティとパフォーマンスが向上します。また、この更新は SAML によるシングルサインオンの動作に影響を与える可能性がございますため、Sandbox でリリース更新を有効にしていただき、動作の事前確認をお願い致します。関連リンクSAML シングルサインオンフレームワークのアップグレード (リリース更新)サービスプロバイダとして Salesforce を使用した SAML シングルサインオンSAML ID プロバイダとしての SalesforceSalesforce 組織または Experience Cloud サイト間の SAML SSO の設定シングルログアウト次に、拡張ドメインについてです。当初拡張ドメインの強制適用は Winter’23 を予定していましたが、Spring’23 に延期されております。強制適用の時期は延期となりましたが、拡張ドメインの有効化についてはお客様側での準備や計画にお時間を要することが想定されるため、参考情報にございます資料をご確認の上で、できるだけ早めのご準備をお願い致します。関連リンクナレッジ : Salesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備ヘルプ : 拡張ドメインを使用する理由ヘルプ :My Domain and Enhanced Domains Quick Reference Guideサクセスナビ：拡張ドメインの有効化とその準備 解説動画：拡張ドメインの有効化​６月度分のアップデートは以上となります。最後までご覧いただき、ありがとうございました。​​​​​​

APIバージョンを定期的に更新しましょう

この記事で学べることAPIバージョンを定期的に更新することの重要性APIバージョンのサポート対象期間APIとはAPI（Application Programing Interfaceの略）は、外部システムから自システムに対するリクエストを受け取るために用意された窓口（インターフェース）です。外部システムからSalesforceの情報にアクセスする必要がある時にはSalesforceのAPIを使用します。例えば、基幹システムの売上データをSalesforceに取り込む処理（夜間バッチなど）であったり、社内システムからのリクエストでSalesforceのデータを参照する時に使用します。APIのバージョンAPIにはバージョンという概念があります。APIを使用するときは、以下のように宛先とバージョンを指定してアクセスをします。以下の例では、外部システムから、Salesforceに対してSOAP APIの54.0のバージョンでアクセスをしています。上記例はSOAP APIですが、他にもいくつか種類があり、いずれも、バージョンを指定する必要があります。※APIの種類については、Salesforce プラットフォーム API について知る（Trailhead）をご確認ください。​APIの最新バージョンは、Salesforce の年3回のバージョンアップのタイミングで更新されます。​例Summer ’22： APIバージョン55.0 Winter ’23：APIバージョン56.0・・・​しかし、APIバージョンは外部システムによって明示的に指定されるため、お客様（外部システム）にて定期的に新しいバージョンに更新していただく必要があります。そして、Salesforceではあらかじめ最低限のサポート対象期間が決まっています。​APIのサポート対象期間Salesforce は、API バージョンを最初のリリース日から最低 3 年間サポートします。API の品質およびパフォーマンスを充実させ、改善するために、3 年を超えるバージョンのサポートは停止される場合があります。API バージョン廃止の予定がある場合、サポートが終了する最低 1 年前までに事前通知されます。​※実際に廃止になった例は、Salesforce Platform API バージョン 7.0 ～ 20.0 の廃止（ナレッジ）をご覧ください​APIをご利用の場合は、上記サポート期間を目安に定期的にAPIバージョンを更新いただくことを推奨します。​APIバージョンの更新更新箇所の確認：APIバージョンを更新する際は、まずはどこでAPIを使用しているかを把握している必要があります。開発を外部発注した場合は、ベンダーから受け取った仕様書に、使用しているAPIバージョンの記載があることを確認し、大切に保管します。社内で開発をする場合も、APIバージョンを含めた仕様を後で確認ができるように管理方法を決めて、社内で共有しておきましょう。​更新作業：実際のAPIバージョン更新作業は、Salesforce以外のシステムの設定変更であったり、AJAX Toolkitを使用した開発をしている場合はデプロイが必要になります。そのため、通常はベンダーや開発者様にて実施いただく作業になります。外部ベンダーへ依頼する場合には、社内プロセス（予算取りや承認申請など）に時間がかかることもあるかもしれませんので、早めに準備をしておきましょう。​その他：データローダもAPIを使用します。PCの画面上でデータローダを起動しご利用いただいている場合は、Salesforceの[設定]画面からデータローダのダウンロードをする事で、新しいAPIバージョンを使用する最新のデータローダを再インストールすることができます。データローダのツール自体のサポートは最新バージョンのみとなりますが、少なくとも3年に1度はデータローダを再インストールすることをお勧めします。学習ツールSalesforce プラットフォーム API について知る（Trailhead）Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止（サクセスナビ）Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止（ナレッジ）SOAP API 開発者ガイドREST API 開発者ガイドBulk API 開発者ガイドデータローダのインストール手順（ナレッジ）まとめSalesforceのAPIバージョンは、年3回のバージョンアップで更新されるリリース日から3 年を超えるAPIバージョンのサポートは停止される場合がありますAPIバージョン廃止の影響を防ぐため、定期的にお客様でのAPIバージョン更新作業を推奨します

Salesforceの機能廃止（EOS/EOL）について

この記事で学べることSalesforceのサポート終了/機能廃止に関する情報の確認方法Salesforce にもEOS、EOLがありますシステム管理者の皆様は、EOSやEOLという言葉を聞いたことがあると思います。Salesforceでも同じ概念があり、古くなった製品のサポートを終了（End of Support）したり、機能が廃止（End of Life）されることがあります。​※初耳というお客様は、機能廃止の方針（ナレッジ）に、Salesforceの機能廃止についての考え方が纏められておりますので、ぜひご確認ください。サポート終了/機能廃止の時期のお知らせSalesforceでは、原則として、機能を廃止する少なくとも12ヶ月前に、製品及びサービスに関するお知らせで通知をしています。また、月次で、以下のような機能廃止ダイジェストメールも送信しています。​​ダイジェストには、お客様のご利用中の機能に関する廃止について記載されています。毎月必ずご確認ください。廃止される機能をご利用の場合製品およびサービスに関するお知らせに、代替機能や対応方法が記載されておりますので、その情報を元にお客様にてご検討をお願いします。直近で廃止予定の機能Salesforce 機能の廃止（ナレッジ）に、今後廃止予定の機能・製品が纏められておりますので、ブックマークしていつでも参照できるようにしておくことをお勧めします。​学習ツール機能廃止の方針（ナレッジ）製品及びサービスに関するお知らせ（ナレッジ）まとめSalesforceの機能や製品は、廃止されることがあります原則、機能や製品を廃止する少なくとも12ヶ月前に、システム管理者様宛に通知をしています機能廃止ダイジェストメールは、毎月必ず確認しましょう

拡張ドメイン適用前のURLにアクセスしたときのリダイレクト停止

この記事で学べること拡張ドメインの概要拡張ドメイン適用前の古いURLへアクセスした際のリダイレクトが停止されることリダイレクト停止に向けた準備の方法拡張ドメインの概要各種ブラウザの最新要件に対応するため、Salesforce は 2023 年 10 月に Winter ’24 のリリースで「拡張ドメイン」をすべてのSalesforce 組織に適用しました。Salesforce 組織への拡張ドメイン適用により、内部ユーザーが利用するURLだけではなく、Salesforce サイトや Experience Cloud サイトなど、外部ユーザーが使用する URL も更新されています。​これまでは拡張ドメイン適用前の URL にユーザーがアクセスした場合は拡張ドメイン適用後の URL にリダイレクトされていましたが、Salesforceでは以下のスケジュールでリダイレクトの停止を予定しています。​▼Winter ’25Sandbox, Developer Edition 組織, デモ組織, パッチ組織, スクラッチ組織, Trailhead Playground などの非本番組織​▼Spring’ 25本番組織​本記事ではリダイレクト停止の準備として活用できる機能や推奨アクションについて纏めております。拡張ドメイン適用により更新された URL拡張ドメインの適用により、Salesforce 組織で使用されていた 多くの URL が更新されました。詳細はヘルプドキュメント「拡張ドメインを有効にする場合の [私のドメイン] の URL 形式の変更」に記載がありますが、本番組織における拡張ドメイン適用前後のURLを以下にご紹介します（一部抜粋）。上記の表にある通り、内部ユーザーが使用する URL だけではなく、Salesforce サイトや Experience Cloud サイトのように外部に公開している URL も更新されました。なお、拡張ドメイン適用前の旧 URL にアクセスすると、拡張ドメイン適用後の新 URL に自動でリダイレクトされる動作となります。しかしながら、旧 URL にアクセスした場合に新 URL にリダイレクトされる動作は、Winter ’25 と Spring’25 で終了します。​​拡張ドメイン適用前の URL にアクセスした際のリダイレクトの停止Winter' 25 と Spring’25 では、拡張ドメイン適用前の URL にアクセスした際のリダイレクトが停止します。＊参考情報 : Update References to Your Previous Salesforce DomainsWinter'25でリダイレクトが停止する組織は以下のとおりです。・Sandbox、Developer Edition 組織、デモ組織、パッチ組織、スクラッチ組織、Trailhead Playground などの非本番組織​Spring’25でリダイレクトが停止する組織は以下のとおりです。・本番組織​そのため、リダイレクトが停止した際の動作確認や、リダイレクトの発生有無の確認を 各リリースまでに実施いただくことを推奨しています。​なお、新 URL へのリダイレクトが停止した際の影響を確認する手段として、システム管理者様にて手動でリダイレクトを停止させることができます。設定メニューの「私のドメイン」ページにある以下の２つの設定を OFF にすることで、その組織上におけるリダイレクトの動作を停止させることができます。（OFF にしたあと、再度設定を ON にしてリダイレクトを動作させることも可能です）以前の [私のドメイン] の URL を現在の [私のドメイン] にリダイレクト<旧 Domain>.secure.force.com および <旧 Domain>.force.com URL を現在の [私のドメイン]のサイト URL にリダイレクト＊参考情報 : [私のドメイン] のリダイレクトの管理​​リダイレクトが発生したユーザーへ新しい URL の通知「私のドメイン」ページで新しい URL へのリダイレクトを ON にしている場合、以下の設定を ON にすることができます。現在の [私のドメイン] の URL にリダイレクトする前にユーザーに通知現在のサイト URL にリダイレクトする前にユーザーに通知この設定が ON になっている場合、ユーザーが古い URL にアクセスしリダイレクトが発生するときに、以下の画面を表示することができ、新しい URL が画面上に表示され、ブックマークの更新を促すメッセージをユーザー側に表示させることができます。＊参考情報 : [私のドメイン] のリダイレクトの管理​​リダイレクト発生状況の確認管理者様はリダイレクトが発生しているかどうかを確認するために、ログを有効化することができます。リダイレクトに関するログを有効化する場合は、「私のドメイン」ページで以下の設定を ON にします。リダイレクトを記録＊参考情報 : [私のドメイン] のホスト名リダイレクトのログ記録​上記設定を ON にすると、「私のドメイン」ページに「リダイレクト ログをダウンロード」というボタンが表示され、システム管理者様はリダイレクトに関するログを取得することができるようになります。取得できるログのイメージを以下にご紹介します。＊ログの詳細については開発者ガイド「ホスト名リダイレクトのイベント種別」をご参照ください。​このログを活用することで、リダイレクトの発生状況を確認することができるようになり、顧客やユーザーへのコミュニケーションプランを検討することができます。ただし、リダイレクトのログには以下の留意点があるため、事前にご確認の上でご利用ください。ログは EventLogFile（イベントモニタリング）の領域に格納されますが、すべてのお客様が無料でダウンロード可能。Event Monitoring Analytics アプリケーションでのログ利用は不可。API でもログを取得することは可能だが、API バージョン 56 以降を利用する必要あり。ログは 1 つのファイルで作成され日次で更新されるため、最新の日次ログのみを取得可能。1 時間以内に同一ホスト名に関するリダイレクトがあった場合は1行しかログが出力されないため、リダイレクト件数を正確に取得するものではない。​​リダイレクト停止までの推奨アクションSpring’25 では本番組織で拡張ドメイン適用前の URL にアクセスした際のリダイレクトが停止します。リダイレクトが停止した際における業務影響の範囲を極力抑えるためにも、Salesforce組織のシステム管理者には以下のアクションを実施いただくことを推奨します。リダイレクト時に新しいURLをユーザに表示する機能を有効化して、ブックマークの更新を促します。定期的にリダイレクトログを確認し、お客様組織にて発生しているリダイレクトの発生状況を確認します。リダイレクトが発生していた場合は、ログから判断できる情報を以って、顧客やユーザーへのコミュニケーションプランを検討します。システム管理者様にてリダイレクトのON/OFFを切り替えることができますので、Spring'25のリリースまでにリダイレクトが無効化された際の影響確認を実施します。​これらの推奨アクションの実施には期間を要する可能性があるため、可能な限り早めの計画策定を推奨します。​​関連リソースWinter’25 リリースノートUpdate References to Your Previous Salesforce DomainsIdentify Blocked Redirections for Legacy Hostnamesヘルプドキュメント拡張ドメイン非拡張ドメインのリダイレクトの終了への準備[私のドメイン] のリダイレクト[私のドメイン] のホスト名リダイレクトのログ記録Developers Guideホスト名リダイレクトのイベント種別​​​​

Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止

Summer '25 で廃止される Salesforce Platform API バージョン 21.0 ～ 30.0 の概要と影響有無の確認方法についての解説動画です。お客様での調査にお役立てください。https://play.vidyard.com/iE8EjS3tstXxdJS4jBUM3W投影資料のダウンロードはこちらからこの記事で学べることSummer '25に廃止される API バージョンと種類を知ることができますAPI バージョンの廃止スケジュールを知ることができますお客様にて必要な対応を知ることができますご存知ですか？ Summer ’25 で古い API バージョンが廃止されます​Salesforce では、API の品質およびパフォーマンスを充実させ、改善するために、最初のリリース日から最低 3 年間サポートしますが、それを超えるバージョンのサポートは停止されたり、廃止される場合があります。そのため、定期的に API バージョンを更新いただくことを推奨しています。※API バージョンを定期的に更新しましょう（サクセスナビ）も是非ご覧ください​今回廃止対象の API の種類とバージョンは以下のとおりです。SOAP：21.0、22.0、23.0、24.0、25.0、26.0、27.0、28.0、29.0、30.0REST：v21.0、v22.0、v23.0、v24.0、v25.0、v26.0、v27.0、v28.0、v29.0、v30.0Bulk：21.0、22.0、23.0、24.0、25.0、26.0、27.0、28.0、29.0、30.0注意事項この廃止には、以下は含まれませんApex クラス、Apex トリガ、Visualforce ページ、フロー、プロセスビルダーただし、AJAX Toolkit を介して行われるバージョン指定された API コールを埋め込んだ Visualforce ページやカスタムボタン、S コントロールはこの廃止による影響を受けます標準の Salesforce B2B Commerce for Visualforce 製品バージョン 30.0 以前のメタデータコンテンツを参照している管理パッケージカスタム Apex REST & SOAP Web Services​この廃止は以下のものに影響します。データローダー　Web Services ConnectorAJAX Toolkit を介して行われる廃止対象のバージョンが指定された API コールを埋め込んだ Visualforce ページやカスタムボタン、S コントロール SForceOfficeToolkit COM インターフェースを介して行われる従来の API コールForce.com Toolkit for PHPアウトバウンドメッセージによって生成されたペイロードから呼び出された SOAP API最新ではない API バージョンを使用している接続アプリケーション廃止スケジュールSummer ‘25以降、廃止された API バージョンを使用した場合場合、以下のようなエラーが発生します。REST API : 「410:GONE」SOAP API :「500:UNSUPPORTED_API_VERSION」Bulk API :「400:InvalidVersion」お客様にて必要な対応「そんな急に廃止と言われても・・・」と戸惑っているシステム管理者の方もいらっしゃるかもしれません。Salesforce では、システム管理者様宛に、月次で、以下のような 機能廃止ダイジェストメール等でお知らせしています。※ 終了日は 2025 年 6 月 1 日となっていますが、こちらのナレッジに記載の通り、実際の終了日は Summer ’25 リリース日となります。（リリース日は Trust サイトにてご確認いただけます）​推奨する対応順序設計書や仕様書などのシステム導入時のドキュメントや、実際のデータ連携実装箇所を調査する外部システムやツール（データローダー等）を使って Salesforce へ接続するアプリケーションの有無とバージョンを確認組織内の開発で AJAX Toolkit 等を使用した実装有無とバージョンを確認こちらの資料を参考に、見落としがちな設定を確認追加でご確認いただく手段として、ログイン履歴の確認や API でのアクセス状況をイベントモニタリングログから確認いただくことが可能です。（こちらの P.10 参照）　手順１、２で確認した箇所の API バージョンを更新[リリース更新] の [テスト実行] を有効化後に、APIバージョンを更新した外部システムやツールを実行 *手順１、２で確認した方法（ログイン履歴等）で、手順４の接続結果を確認* Winter’25 より、[リリース更新]の[テスト実行]をご利用いただけます。[テスト実行] 有効化後は、廃止対象の Platform API バージョンの利用は不可となります。具体的には、廃止対象バージョンの API バージョンに対して外部システムからアクセスすると その API  コールは失敗、エラーが発生するようになります。[テスト実行を有効化]をするには、[使用開始] をクリック後の画面で [テスト実行を有効化] をクリックします。この機能を利用し、外部システムからの API コールをテストをすることができます。※適用スケジュールまでの間は、いつでも [テスト実行] の有効 / 無効を切り替えることができます。​学習ツールSalesforce Platform API バージョン 21.0 ～ 30.0 の廃止（ナレッジ）API バージョンを定期的に更新しましょう（サクセスナビ）イベントモニタリング（Trailhead）API 合計使用量（開発者ガイド）​まとめSalesforce の API は、最初のリリース日から 3 年経過すると廃止になる場合があるので、定期的にバージョンを更新する必要があります機能廃止に関するダイジェストメールが月次で配信されていますので、システム管理者様は必ず確認して下さい廃止対象の API バージョンを使用しているかどうか、使用箇所や実装された詳細については、Salesforce では確認ができないため、利用有無および対応方法については、開発会社や開発担当者様へご確認をお願いします。

認証情報の管理におけるベストプラクティス(セッション情報の管理)

この記事で学べること認証情報の管理の重要性セッションを管理するための設定認証情報の管理の重要性最も基本的な対策はユーザ自身による管理の徹底です。ユーザが認証情報（パスワードやセッション情報など）を適切に管理していない場合、第三者による意図しないアクセスを招く可能性があります。業務を終える際には必ずSalesforceからログアウトすることを徹底するなど、ユーザ自身による日常的な対策もセキュリティの観点で重要です。セッション情報のセキュリティ認証情報に起因するセキュリティリスクを軽減するために、Salesforceには様々な機能が用意されています。このドキュメントでは、認証情報の一つである「セッション情報」のセキュリティを強化するための機能について取り上げます。​セッション設定セッション設定を見直すことで、セッション情報が流出した場合のリスクを軽減することができます。*1)接続アプリケーションのセッションポリシーの管理（ヘルプ）*2)接続アプリケーションの IP 制限の緩和および IP の継続的な適用（ヘルプ）各設定方法およびその他の関連する設定については、「セッションセキュリティ設定の変更」（ヘルプ）をご参照ください。尚、表に記載されている設定が適用される範囲は以下の通りです。​「すべての要求でログイン IP アドレスの制限を適用」は他のいくつかの設定と連動しながら動作します。当設定を有効化する場合は、以下の順序で検討してください。*1)拡張プロファイルユーザインターフェースでのログイン IP アドレスの制限（開発者ドキュメント）*2)セッションセキュリティ設定の変更（ヘルプ）*3)接続アプリケーションの IP 制限の緩和および IP の継続的な適用（ヘルプ）認証情報が流出した場合の対処万が一、セッション情報などの認証情報を第三者に流出させてしまった場合、影響範囲を限定的にするために早期対処が鍵となります。*1)ユーザのパスワードのリセット（ヘルプ）*2)Salesforce 多要素認証に関する FAQ（ナレッジ）*3)ユーザセッション（ヘルプ）*4)現在の OAuth 接続アプリケーションセッションの管理（ヘルプ）参考情報Salesforce セキュリティガイド（開発者ガイド）接続アプリケーションのセッションポリシーの管理（ヘルプ）セキュリティ状態チェック（ヘルプ）

MFAによるランサムウェア対策

IPA（独立行政法人情報処理推進機構）は、その年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から脅威候補を選出し、情報セキュリティ分野の有識者が審議・投票を行い決定したものを「情報セキュリティ 10大脅威」として公開しています。2021年度、「ランサムウェアによる被害」が昨年５位から１位にランクを上げて注目を浴びています。（出典：IPA(情報処理推進機構) 情報セキュリティ 10大脅威 2021 組織別順位・2021年8月23日）​ランサムウェアとは、マルウェアの一種です。特徴は、ランサムウェアに感染したコンピュータは、利用者のシステムへのアクセスを制限されてしまう。（暗号化、ロックなど）この制限を解除するための身代金を要求すること。身代金を払うことでその制限を解除するという犯罪に利用される。​日本国内でもランサムウェアによる被害が多数報告されています。2021年7月、ランサムウェアによる攻撃を受け、財務/販売管理の基幹システムやファイルサーバ、グループネットワークで運用していた販売管理システムや財務会計システムが暗号化された事例がありました。この事例で特徴的なのは、BCP（事業継続計画）として用意していたバックアップサーバも暗号化されて、業務復旧までに想定以上の時間を要し、四半期決算報告を延期せざるをえない結果となった点です。​同様に、10大脅威の3位にランキングしている「テレワーク等のニューノーマルな働き方を狙った攻撃」、8位の「インターネット上のサービスへの不正ログイン」に関しても、ランサムウェアによる攻撃につながる脅威として対応が求められます。​ランサムウェア対策の一つとして、MFA（多要素認証）を活用してユーザ認証を実施することにより、情報漏洩リスクを低減することが可能です。​コロナウイルス禍の影響で、ニューノーマルと言われる、クラウドシフトした業務システムの利用やリモートワークのような働き方改革が一般的になりました。ただ、企業のセキュリティ対策が、この変化に対応が取れていないのが現状です。従来のセキュリティ対策は、社員がオフィスへ出社し、イントラネットワークからアクセスすることを想定したものでした。ファイアウォールによって社内ネットワークをインターネットから切り離し、社外からのアクセスをチェックしていた境界防御です。ニューノーマルにおいては、境界をまたぐ形で社員からのアクセスや業務システムへの通信が発生し、外と内に分ける考え方では制御しきれない状況となりました。​ランサムウェアによる攻撃の例として、悪意の第三者が社内ネットワークにリモートからVPN接続するために必要なIDとパスワードを詐取した場合、従来型のセキュリティ対策ではプロアクティブに犯行を発見/防止することが困難です。社内ネットワークへ侵入した悪意の第三者は、正規ユーザとして社内の重要な資産にアクセスが可能で、その制御や発見するすべもありません。インターネットサービスの利用に関しては、企業内部からのアクセスを許可するIPアドレス制限をかけていたとしても、社内ネットワーク経由の接続は全て許可され、本人確認のチェックが効きません。詐取されたIDとパスワードを利用し、インターネットサービス上の業務システムから重要情報を取得し、社外へ持ち出されてしまいます。​ランサムウェア対策としてMFAを活用する背景には、ゼロトラストという「誰も信用しない」という考え方に基づき、ユーザを認証して社内外のアクセスをコントロールする必要性があるからです。全てのユーザはMFAという「関所」にアクセスし、認証された結果に応じて適切なアクセス権を付与されます。また、必要なタイミングでアクセス権を確認し、ユーザのコントロールと可視化をMFAは実現できます。​セールスフォース社の場合、全社員がVPN経由で社内ネットワークにアクセスする際、IDとパスワード以外にMFAによる認証が求められます。社内ネットワーク接続後も、重要な社内情報を閲覧する際にもMFAによる認証を求められ、アクセス権を有する社員かどうかをチェックする体制を取っております。​2022年2月1日から、セールスフォース社はサービスログイン時にMFAによる認証を必須とします。この背景には、上述のゼロトラストの思想より、ランサムウェアによる攻撃を防止することにあります。​インターネット上のサービスへの不正アクセスへの対策としてMFAが有効なのは、ゼロトラストの観点から、IDやパスワードでチェックするだけではなく、ユーザ個人が有するデバイスを活用して多面的に認証をかける点にあります。アクセス元のIPアドレスの制御に加えて、アクセスを試みたユーザが本人なのか、接続するたびにチェックをかけることによって、情報漏洩のリスクを軽減することが可能となります。​​

組織の体制変更がある場合の対応のポイント

この記事で学べることSalesforce稼働後の（自社の）組織体制変更時の対応の流れを知ることができます組織体制変更時に使用するツールについて知ることができます組織体制変更時の対応の流れSalesforceのシステム管理者のみなさまは、普段新入社員のユーザを作成したり、退職するユーザを無効化したり、ユーザ情報の更新（部署やロール、プロファイルの変更）等のユーザ管理業務を行なわれていると思います。※ ユーザの管理については「ユーザ管理の便利機能」も参考にしてください。​今回は、期初や期末にみなさまの会社で行われる事があるであろう、組織の体制変更に伴い、Salesforceにどのような変更を行う必要があるかを考慮点含めて説明します。※人事異動の場合はユーザ情報の更新（ロール項目の変更）になりますが、今回はロール自体を変更する場合の作業の流れになります​一般的に、組織の体制変更がある場合、以下のような変更が行われると思います。それをSalesforceに反映させるための変更箇所は以下のとおりです。組織の変更に伴う変更点Salesforceの設定変更箇所組織の体制変更（新たな部署が設置される/既存の部署が統合されるなど）・ロール（自体）の変更・階層構造の変更既存の部門/部署名の変更・ロール（の名称）変更・ユーザの[部署名]の変更部署のメンバーの変更・ユーザの[ロール]の変更役職名の変更・ユーザの[役職]の変更お客様の担当替え・取引先や商談の[所有者]変更・活動の[任命先]変更注意事項：上記以外にも、例えば[ロール名]を条件にしたレポート、ダッシュボード、数式項目、フロー等の自動化設定がある場合は、それらの変更も忘れずに実施しましょうユーザの[ロール]や[役職]項目以外にも、プロファイル、マネージャーや権限セットの変更が必要な場合は一緒に変更しますSalesforceの設定変更箇所を把握したので、「早めに変更作業をしたい」と思うかもしれませんが、その前に！決めておくべきことがあります。移行ルール変更作業に着手する前に、関連部署のメンバーとあらかじめ以下を決めておくことで、変更作業をスムーズに進めることができます。組織の体制変更後に、Salesforceのデータをどのようなルールで共有するか（データへのアクセス権をどうするか）最終的に、どのようなロール階層にするか共有ルールを使用するか、使用する場合にはどのようなルールにするか誰がどの取引先を担当するか取引先の新旧担当者一覧の作成商談の担当はどうするか例：現在進行中の商談の担当者は変更しない、完了している商談の担当は変更しない（過去の実績を組織の体制変更前の担当で把握する必要がある場合は、担当者を変更しないでください）活動の担当はどうするか例：まだ完了していない活動の任命先を変更するか/しないか注意事項：上記以外のオブジェクトを使用している場合は、オブジェクト毎に担当をどのようにするかを決めておきましょう。​移行ルールが決まったら、次の流れで変更作業を行いますロール・共有ルールの変更ユーザ情報の変更各データの所有者変更１．ロール・共有ルールの変更まずは組織の土台となるロール、およびロールを使用した共有ルール（アクセス権）の設定を行います。ロールや共有ルールは、2.ユーザ情報の変更作業が完了するまでは反映されません。そのため、ユーザ情報変更作業前に、あらかじめ準備をしておきます。​組織の体制変更後の状態に合わせて、ロールを変更します。新たな部署が追加される場合は、[ロールの追加]からロールを作成します部署が統合される場合も、新たな部署を作成します。統合前の部署を残しておくと、退職したユーザのロールを変更する必要がありません​階層構造の変更はなく単なる名称変更の場合は、[表示ラベル]と[レポートに表示するロール名]を変更します階層構造が変わる場合は、[このロールの上位ロール]項目を変更します会社の合併など、大幅な組織体制変更の場合は、新しいロール階層を定義することをお勧めします。​組織の体制変更の前日までは、旧体制のまま業務を行う必要があると思いますので、あらかじめ新組織体制の準備でロールを作成しておき、新組織体制に変わるタイミングでユーザ情報を更新して新しいロール設定を反映させます。​次に、ユーザ情報を変更して、新しい組織体制を反映させましょう。２．ユーザ情報の変更組織の土台となるロールおよび共有ルールの設定が終わったら、ユーザ情報の変更を行います。​ユーザ情報は、以下3種類の方法で変更することができます。ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面から複数ユーザを一括で変更するデータローダを使用する​ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面の[ユーザをロールに割り当て]で、複数ユーザを一括で変更する（具体的な操作手順は、「ユーザへのロールの割り当て」（ヘルプ）をご覧ください）​データローダを使用する​組織の体制変更がある場合、一般的には、ロールを変更するタイミングでプロファイルや部署名、役職名等も変更になることがあると思いますので、それらを一度に変更ができるデータローダを使用することをお勧めします。（データローダの使い方ついては「初めてのデータローダ 〜Update編〜」（サクセスナビ）をご覧ください）​注意点：承認プロセスにマネージャー項目を使用している場合は、マネージャー項目も忘れずに変更しましょう。​ユーザ情報の変更が完了したら、取引先や商談などのデータを変更します。３．各データの所有者変更事前に定義した移行ルールに従い、データの所有者（や任命先）を変更します。​所有者の変更は、画面上から行える「所有権の一括変更」もしくはデータローダをご利用いただけます。どちらのツールが適しているかは、以下をご確認ください。​注意点：「所有者の一括変更」機能を利用できるのは、リード、取引先、カスタムオブジェクトのみです上記フロー以外のデータ（例：現在の所有者が所有している完了している商談など）の扱いについては、オプションで選択をすることができます。​以上で、組織の体制変更があった場合に、システム管理者様にて対応が必要な作業は完了です。学習ツールロールの項目（ヘルプ）ユーザの項目（ヘルプ）データの所有権の移行（ヘルプ）取引先の一括変更で、同時に移行されるデータについて（ナレッジ）まとめ変更作業を始める前に、移行ルールを決めておくことが重要ですデータ変更に使用できるツールは「所有権の一括変更」とデータローダがありますので、要件にあう方を選択しましょう

ユーザ管理の便利機能

この記事で学べることユーザ管理に必要な基礎知識を学ぶことができますユーザの管理に使用できる便利な機能を知ることができます知っていますか？Salesforceのユーザを削除することはできませんSalesforceのシステム管理者様の業務で欠かすことができないのものの1つはユーザ管理だと思います。新入社員が入る、長期休暇を取得するユーザがいる、異動するユーザがいる等の様々なイベントに対して、システム管理者様はユーザを作成したり編集したりされていると思います。​さて、ここで質問です。「ユーザが退職するとき」どのように対応しますか？​答えは、「ユーザを無効化する」です。Salesforceのユーザは一旦登録をすると削除をすることはできません。ユーザには様々なデータが紐付いています。例えば、そのユーザが担当（所有していた）取引先や商談、活動、カスタムオブジェクト等があります。そのユーザが退職した後も、そのユーザが勤務していた時の状態でデータを残しておけるように、削除ではなく「無効化」ができるようになっています。そして、無効化をすることで、そのユーザが使用していたライセンスが開放され、他のユーザがライセンスを使用することができるようになります。​ですが、何らかのエラーが発生し、すぐにユーザを無効化できない場合があります。（もちろんあなたは、退職後のユーザにはSalesforceにログインしてほしくありません！）​こんな時に使えるのが「凍結」です。凍結をしておけば、あなたがエラーの原因を確認（必要に応じてサポートへ問い合わせを）している間、そのユーザがSalesforceにログインできないようにすることができます。​注意点：「無効化」と異なり、「凍結」をしてもユーザライセンスは開放されませんので、他のユーザにライセンスを使用することはできませんので、ご注意ください。知っていますか？ユーザにもリストビューを作ることができますSalesforceには、オブジェクト（取引先や商談）毎にデータの一覧を簡単に表示できるように「リストビュー」という機能があります。システム管理者のみなさまは、現場のユーザが業務で使用するリストビューを作成しているかと思いますが、そのリストビューを[ユーザ]オブジェクトに対しても作成することができます。​特にユーザ数が多い組織の場合、全ユーザの一覧画面をスクロールして対象ユーザを探すのは大変だと思います。あらかじめ部署毎、ロール毎、プロファイル毎などの条件でリストビューを作成しておくと管理しやすくなります。（リストビューの作成方法は、「Salesforce Classic でのカスタムリストビューの作成」(ヘルプ)をご覧ください）​知っていますか？プロファイルにもリストビューを作成することができますリストビューつながりで、もう一つ、ユーザのアクセス権管理の便利機能をご紹介します。​※「プロファイルって何だろう？ユーザとどういう関係が？」という方は、「ユーザを登録する」(サクセスナビ)「プロファイルと権限セットを使って、アクセス方法や権限を設定する」(サクセスナビ)をご覧ください​規模の大きな組織では、ユーザに割り当てるプロファイルの数も多くなります。「プロファイル毎にどういう権限が付いているのか見比べたい」「複数のプロファイルの権限を一括で変更したい」という場面もあるかと思います。そんな時におすすめなのが、「プロファイルのリストビュー」です。​※ もし、[編集 | 削除 | 新規ビューの作成]リンクが表示されていない場合は、[拡張プロファイルリストビュー]を有効にします。具体的な手順は、「拡張プロファイルリストビューを有効化」(ヘルプ) をご覧ください。​以下は、プロファイル毎に、取引先のオブジェクト権限の設定を表示するリストビューのサンプルです。（リストビューの作成手順は「プロファイルリストビューの作成と編集」(ヘルプ) をご覧ください）​他のオブジェクト（取引先や商談など）のリストビューと同様に、必要な項目（オブジェクト権限やユーザ権限）を追加して、リスト上でインライン編集したり、複数プロファイルの権限を一度に編集することができます。​また、「特定の権限が付与されているユーザは誰か？」というように権限を条件にユーザやプロファイル、権限セットを検索したい場面もあるかと思います。そんな時には、AppExchangeサイトで公開されている「Permission Helper」アプリケーションをぜひご活用ください。​以下は、[すべてのデータの編集]権限を持つユーザの一覧を表示していますが、特定のオブジェクト権限を持つユーザの一覧を表示することもできます。知っていますか？設定画面で、ユーザを直接検索できますここまで、リストビューを活用したユーザ管理についてご紹介してきましたが、設定画面でも、グローバル検索と同じようにユーザを検索することができます。一人のユーザのパスワードリセットを行う場合などは、リストビューを表示して特定ユーザを探すよりも検索をしたほうがスムーズです。​以下は「標準」の文字列で検索をしていますが、[ユーザ]だけでなく[項目名]なども検索することができます。（あいにく、[プロファイル名]を検索することはできません）注意点：画面左上の[クイック検索]はメニューを検索するものです。ユーザや項目を検索するときは、画面上部の虫眼鏡から検索してください。​学習ツールSalesforce Classic でのカスタムリストビューの作成（ヘルプ）プロファイルリストビューの作成と編集（ヘルプ）Permission Helper（AppExchange）ユーザ管理（Trailhead）まとめSalesforceではユーザを削除することはできません。代わりに[無効化]や[凍結]を行います。ユーザやプロファイルのリストビューを活用することで、スムーズにユーザ管理業務を行うことができます。

サンプルデータを削除しましょう

この記事で学べることサンプル（トライアル）のデータを一括削除する方法を知ることができます“(Sample)“データを効率よく削除する方法Salesforceのトライアル組織には、以下のように“(Sample)”と記載された初期データ（サンプルデータ）が入っています。ご契約前であれば、サンプルデータを削除する機能をご利用いただけます。注意事項：[すべてのデータの一括削除]は、初期データだけでなく、お客様自身が作成したサンプルデータを含めて、組織のすべてのデータを削除します。[すべてのデータの一括削除]を使用して削除されたデータを復元することはできません。お客様自身が作成したサンプルデータは残しつつ、初期データのみ一括削除をしたい場合、もしくは既にご契約をされている場合は、[一括削除]機能を使用することができます。具体的な操作方法は、「新しい Salesforce 組織で事前にロードされたサンプルデータを削除する」（ナレッジ）の「オプション2」をご確認ください。​[一括削除]画面に表示されていないオブジェクトのデータを削除する場合は、データローダを利用します。データローダの操作方法は、「初めてのデータローダ 〜Delete編〜」（サクセスナビ）をご覧ください学習ツールトライアルデータの削除（ヘルプ）組織データのデフォルトへのリセット（ナレッジ）新しい Salesforce 組織で事前にロードされたサンプルデータを削除する（ナレッジ）まとめご契約前のお客様は、サンプルデータを一括削除することができます。ご契約後であったり、自動作成されたサンプルデータのみを削除する場合は、[一括削除]や[データローダ]を使用します。

CoEの役割・構成例

ただいま改訂を行っております。公開まで今しばらくお待ちください。

テストのポイント

この記事で学べること多要素認証 (MFA) のテストをする際のポイントを理解することができますMFA のテスト多要素認証のテストの推奨事項は製品毎に異なっております。​MFA 実装のテスト ​この記事では Salesforce Platform で構築された製品 (Sales Cloud や Service Cloud 等) におけるテストの推奨事項について紹介させて頂きます。その他の製品におけるテスト時の推奨事項は上記ヘルプ記事内の各製品毎のヘルプページへのリンクをご参照頂ければ幸いです。 Salesforce Platform で構築された製品 における MFA のテストテストに利用する環境検証に利用する環境ですが、本番環境で実施する前に Sandbox 環境、もし利用できる Sandbox 環境が無い場合には Developer Edition 組織をサインアップ頂き、そちらの環境でのテスト実施を推奨しております。テストに利用するユーザテストを実施する際には、テストを実施頂くシステム管理者のアカウントについては誤って自身がロックアウトされるのを防ぐため、システム管理者権限の無いテストユーザを作成頂き、テストユーザのアカウントを使用する事を推奨しております。テストで確認することテストで確認頂く事としてはテストユーザとしてログインし、選定頂いた検証方法*での登録フローの実施・完了検証方法登録後、Salesforce に正常にログイン頂けるかを確認エンドユーザーが検証用のデバイスを忘れた場合を想定して、管理者アカウントで仮のコードの発行仮のコードを利用してのログインの流れの確認といった点があげられます。​*Salesforce Authenticator、 3rd party の TOTP アプリケーション、セキュリティキー 等。学習ツールMFA 実装のテストMFA のテスト (Salesforce Platform で構築された製品)仮のコードによる ID の検証 まとめMFA のテストを実施する上ではまず本番環境ではなく、Sandbox や Developer Edition 組織でお試し頂く管理者ユーザがロックアウトされる事を防ぐため、テストユーザを作成しテストに使用するエンドユーザでの実施事項と管理者で実施しなければならない動作をテストでは検証するといった点がポイントとなる旨、紹介させて頂きました。MFA のテスト計画を立てる際の参考となれば幸いです。どうぞよろしくお願いいたします。