“������������������”の検索結果
-
この記事で学べること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のサポート終了/機能廃止に関する情報の確認方法Salesforce にもEOS、EOLがありますシステム管理者の皆様は、EOSやEOLという言葉を聞いたことがあると思います。Salesforceでも同じ概念があり、古くなった製品のサポートを終了(End of Support)したり、機能が廃止(End of Life)されることがあります。※初耳というお客様は、機能廃止の方針(ナレッジ)に、Salesforceの機能廃止についての考え方が纏められておりますので、ぜひご確認ください。サポート終了/機能廃止の時期のお知らせSalesforceでは、原則として、機能を廃止する少なくとも12ヶ月前に、製品及びサービスに関するお知らせで通知をしています。また、月次で、以下のような機能廃止ダイジェストメールも送信しています。ダイジェストには、お客様のご利用中の機能に関する廃止について記載されています。毎月必ずご確認ください。廃止される機能をご利用の場合製品およびサービスに関するお知らせに、代替機能や対応方法が記載されておりますので、その情報を元にお客様にてご検討をお願いします。直近で廃止予定の機能Salesforce 機能の廃止(ナレッジ)に、今後廃止予定の機能・製品が纏められておりますので、ブックマークしていつでも参照できるようにしておくことをお勧めします。学習ツール機能廃止の方針(ナレッジ)製品及びサービスに関するお知らせ(ナレッジ)まとめSalesforceの機能や製品は、廃止されることがあります原則、機能や製品を廃止する少なくとも12ヶ月前に、システム管理者様宛に通知をしています機能廃止ダイジェストメールは、毎月必ず確認しましょう
-
この記事で学べること拡張ドメインの機能概要拡張ドメインが有効化される背景拡張ドメインによる変更点想定される影響お客様による事前準備の内容拡張ドメインに関する参考情報拡張ドメインの概要拡張ドメインは Spring'23 のリリースから自動有効化が始まり、Winter'24 のリリースで強制適用されます。自動有効化は管理者様で拡張ドメインを無効化することができますが、強制適用が行われると拡張ドメインを無効化することはできません。拡張ドメインが適用されることによるお客様組織への変更は以下となります。(1)ブランドExperience Cloud サイト、Salesforce サイト、Visualforce ページ、コンテンツファイルの URL を含め、組織のすべての URL に [私のドメイン] の名前が含まれます。また一部のURLではドメインサフィックス ([私のドメイン] の名前の後の部分) も更新されます。(2)安定性お客様組織で使用されているすべてのURLからAP3やAP4などのインスタンス名が削除されます。今後インスタンス名を意識したお客様作業、メンテナンスが不要になります。(3)コンプライアンスお客様にてご利用いただいているブラウザにおける最新の要件(サードパーティ Cookieに関する対応)に準拠します。上記の通り、本機能の有効化を以って公開 URL を含むドメイン(URL)が更新されるため、Winter'24での強制適用までに Sandbox で動作確認/テストを実施いただき、お客様組織での影響度を確認の上で本番組織での有効化を推奨します。*2022年10月時点では Spring'23 のリリースにて拡張ドメインの強制適用を予定していましたが、強制適用は Winter'24 に延期しました。▼参考情報Salesforce ヘルプ : Enhanced Domains Timeline拡張ドメイン適用の背景主要なWebブラウザにて、サードパーティ Cookieをブロックすることが既定の動作となることがアナウンスされています。Cookieとはなにかというと、Webサイトにアクセスしたユーザの情報を一時的にクライアントに保存しておくためにサーバから送信されたファイルです(ページ遷移やWebサイトへの再訪問に、同一ユーザー/ブラウザであることの判別に使用)。サードパーティ Cookieとは、アクセスしたサイトとは異なるドメインから送られるCookieのことです。プライバシー保護の観点より、サードパーティcookieの利用に関する規制が強くなっている背景があり、各ブラウザでサードパーティ Cookieをブロックすることを既定の動作とする動きがあります。その制限によりSalesforceのページで、異なるURLからコンテンツを読み込む際に問題が発生する可能性があります。例 : lightning.force.com というURLのページから、documentforce.com というURL を介してコンテンツを読み込む。このようなブラウザの最新要件にSalesforceも対応するため、URLを更新することを目的として「拡張ドメイン」の自動有効化を予定しています。拡張ドメイン適用までのロードマップ拡張ドメインはSpring'23から自動有効化が始まり、Winter'24で強制適用されます。Spring'23以降のリリースで予定されているイベントと、お客様に選択いただけるオプションは以下のとおりです。上記の表に記載されているようにSpring’23 リリースにおける自動有効化については、管理者様がSalesforce組織を自動有効化の対象から除外(オプトアウト)することができます。除外する場合は「私のドメイン」の設定ページにある「Automatically deploy enhanced domains with Spring ’23」をオフにします。尚、この除外の設定はSummer’23では使用することはできません。(設定名称は機能導入初期の表記であり、翻訳される予定です)▼参考情報公開ナレッジ : Opt Out of the Automatic Deployment of Enhanced Domains in Spring ’23自動有効化の除外設定はWinter'23で設定することができ、Spring23のリリース時のみ有効です。Winter'23で除外設定を行っていない場合は、Spring'23で拡張ドメインが自動有効化されますが、無効化することができます。Spring'23で拡張ドメインが適用されなかった場合は、次回リリースのSummer'23で拡張ドメインが自動有効化されます。これは除外することはできませんが、拡張ドメインを無効化することは可能です。Summer'23で拡張ドメインが適用されなかった場合は、次回リリースのWinter'24で強制適用されます。これは無効化することができません。自動有効化や強制適用を待つのではなく、管理者様にて拡張ドメインを手動で有効化することは可能です。Salesforce組織の「リリース更新」メニューでは、拡張ドメインを有効化するまでのステップをご確認いただくことができます。拡張ドメイン有効化後の実際の動作を評価するためにも、まずはSandboxで拡張ドメインを有効化し、検証やテストを実施いただくことを推奨します。▼補足 : リリース更新の画面▼補足 : リリース更新「拡張ドメインを有効化」の画面拡張ドメイン適用による変更点本セクションでは、URLの用途と適用前後のURLをまとめています。本番組織のURL 形式SandboxのURL形式SaleforceサイトやExperience CloudサイトのURLをみると、変更後のURLには私のドメインが指定されていることが確認できます。このように外部に公開しているURLが変更となります。またVisualforceやコンテンツのURLをみると、すでに私のドメインが含まれているURLも更新されていることが確認できます。このようなかたちで拡張ドメインの適用によりお客様組織のURLが更新されます。尚、すべてのURLについてご確認いただく場合は、ヘルプ「拡張ドメインを有効にする場合の [私のドメイン] の URL 形式の変更」を御覧ください。想定される影響URL を直接参照するようなカスタマイズ/インテグレーションがある場合など、エラーが発生する可能性があります。また拡張ドメインの有効化で、Experience CloudについてはCDNが使われるようになることも重要な変更点の1つです。拡張ドメイン有効化において想定される影響範囲として以下のようなものがあります。Salesforce の埋め込みコンテンツの一部が表示されなくなる可能性がある。サードパーティアプリケーションからデータへのアクセスができなくなる可能性がある。Sandbox とのシングルサインオンインテグレーションが失敗する可能性がある。*.cloudforce.com や *.database.com のドメインサフィックスを使用した組織では、変更される前のドメインサフィックスである *.cloudforce.com や *.database.com を使用したSSOやインテグレーションが失敗する可能性がある。組み込みサービスのコードスニペット機能では「*.force.com」が使用されるので、正しく動作しない可能性がある。Experience Cloud サイト、Salesforce サイト、Visualforce などへのアクセス時にエラーが発生する可能性がある。拡張ドメインが有効化されると、Experience Cloud サイト(*.my.site.com)で CDN が使用されます。また CDN では IPv6 がサポートされています。そのため以下の条件がそろうとアクセス時にエラーが発生する可能性がありますので、回避するためには、プロファイルの IP アドレス制限の設定に IPv6 のアドレス範囲を追加します。サイトにアクセスするユーザのプロファイルで、IP アドレス制限を IPv4 で設定している。ユーザが IPv6 で Experience Cloud サイトにアクセスする。▼参考情報拡張ドメインを使用するデジタルエクスペリエンスの Salesforce CDNSalesforce IPv4 and IPv6 supportCDN の有効化によるアプリケーションの読み込みの高速化お客様によるご準備拡張ドメインは Spring'23 と Summer'23 のリリースで自動有効化が実施され、Winter'24 では強制適用されます。前述の影響を事前に認識/対策するためにも 自動有効化や強制適用までに下記を進めていただくことを推奨します。Sandbox で拡張ドメインを有効化します。Sandbox で影響箇所の有無を確認し、影響箇所があった場合の対応方法を検討します。確認箇所やテスト方法については、以下の参考情報をご覧ください。[私のドメイン] の変更に対する組織の更新[私のドメイン] の変更のテストSandbox で確認できた対応方法(インテグレーション/カスタマイズの改修など)を本番組織に適用します。URL が更新(時期や変更箇所)されることをユーザへアナウンスします(ブックマークの更新等)。お客様公開サイトやマニュアル等に配置されているリンクを変更します。Spring’23 と Summer’23のリリースでは拡張ドメインが自動有効化されます。Spring'23までに対応が間に合わない場合は、自動有効化の除外設定を実施します(詳細は「拡張ドメイン適用までのロードマップ」セクションを参照)。Spring’23 または Summer’23 のリリースで自動有効化が行われた場合、拡張ドメインを無効化することができますが、無効化処理にはお時間がかかる場合がありますので、自動有効化の前にテスト/検証を完了し、手動で拡張ドメインを有効化することを推奨します。拡張ドメイン有効化に関するステップはお客様組織の[リリース更新]でもご確認いただくことができます。お客様でのご準備にあたり、ご不明点等がございましたら弊社サポートまでお問い合わせください。自動有効化や強制適用に備えて、影響確認とその対策をお願いします。拡張ドメイン有効化後におけるURLのリダイレクト拡張ドメイン有効化後、以前のURLのアクセスは新しいURLへリダイレクトされますが、新しいURLへのリダイレクトはWinter'25で停止される予定です。URLの種類によってリダイレクトの動作が異なるため、以下に詳細を記載します。Experience Cloud サイト等の外部に公開されている拡張ドメイン有効化前の force.com ドメインのURLは、Winter'25 のリリースで旧URLから新URLへのリダイレクトが停止します。また、管理者様にて[私のドメイン]ページの以下の設定を OFF にすることでリダイレクトを停止させることもできます。その他(外部向けの force.comドメイン以外)の拡張ドメイン有効化前のURLについても、 Winter'25 のリリースでリダイレクトが停止します。また、管理者様にて[私のドメイン]ページの以下の設定を OFF にすることでリダイレクトを停止させることもできます。尚、拡張ドメイン有効化後に[私のドメイン]を変更すると、拡張ドメイン有効化前のURLはリダイレクトされません(1世代前までのURLのみリダイレクト可能)。▼参考情報Prepare for the End of Redirections for Non-Enhanced Domainsリダイレクトに関するログの取得Winter’23 からURLのリダイレクトのログを CSV 形式でダウンロードすることが可能になります。このログを活用することで、URLの変更について、顧客やユーザーへのコミュニケーションプランを検討することができます。尚、本機能をご利用いただく場合、Winter'23 のリリース後に[私のドメイン]ページから機能(リダイレクトの記録)を有効化する必要があります。リダイレクトのログには以下の留意点があるため、事前にご確認の上でご利用ください。ログは EventLogFile(イベントモニタリング)の領域に格納されますが、ログ自体は無料でダウンロード可能。Event Monitoring Analyticsではログは利用不可。APIでもログを取得することは可能だが、API バージョン 56 以降を利用する必要あり。ログは1つのファイルで作成され日次で更新されるため、最新の日次ログのみを取得可能。1時間以内に同一ホスト名に関するリダイレクトがあった場合はログに記録されないため、リダイレクト件数を正確に取得するものではない。▼参考情報Log Your Redirected My Domain HostnamesHostname Redirects Event Type関連リソースのまとめTrailblazer CommunityMy Domain and Enhanced Domains グループWinter’23 リリースノートDeploy Enhanced Domains (Release Update)Review the New Timeline for Enhanced DomainsWinter’22 リリースノート拡張ドメインの有効化 (リリース更新)Summer’22 リリースノート拡張ドメインの有効化 (リリース更新)拡張ドメインを有効にした後のサイト URL のリダイレクト新規および更新後の Sandbox での拡張ドメインの使用ヘルプドキュメント/ナレッジ拡張ドメイン拡張ドメインを使用する理由拡張ドメインに関する考慮事項(*1)拡張ドメインを有効にする場合の [私のドメイン] の URL 形式の変更必要なドメインを許可拡張ドメインを使用するデジタルエクスペリエンスのコンテンツ配信ネットワークExperience Cloud 向け Mobile Publisher アプリケーションと拡張ドメインSalesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備Log Your Redirected My Domain HostnamesHostname Redirects Event TypePrepare for the End of Redirections for Non-Enhanced DomainsCDN の有効化によるアプリケーションの読み込みの高速化Enhanced Domains TimelineOpt Out of the Automatic Deployment of Enhanced Domains in Spring ’23FAQQ1 : 「[私のドメイン] の名前」が外部のURLに使用されることを回避することはできますか。A1 : 「[私のドメイン]の名前」を変更する方法とカスタムドメインを使用する方法があります。「私のドメイン」を変更すると、既存動作に影響を与える可能性もあるため、カスタムドメインを使用することを推奨しております。詳細は「拡張ドメインに関する考慮事項」の「公開 URL の変更」をご覧ください。Q2 : 拡張ドメインが適用される前のURLにアクセスするとどうなりますか?A2 : 拡張ドメインで変更される URL では、古い URL にアクセスすると、Salesforce がWinter'25でリダイレクトを停止するまで、新しいホスト名にリダイレクトされます。またリダイレクトの動作には以下の注意点がございますのでご確認ください。・拡張ドメインが有効になった後に「[私のドメイン] の名前」を変更すると、名前変更前のURLでのアクセスは名前変更後のURLにリダイレクトされますが、拡張ドメイン有効前のURLはリダイレクトされなくなります。(拡張ドメイン有効化以前のURLへリダイレクトが必要な場合には、拡張ドメイン有効化後に「[私のドメイン] の名前」を変更をしないで下さい)・「以前の[私のドメイン]を削除」ボタンを押下すると、リダイレクトはされなくなります。・「以前の [私のドメイン] の URL を現在の[私のドメイン]にリダイレクト」のチェックをOFFにしてテストをする事で、リダイレクトされなくなるので問題が発生する部分を確認する事ができます。Q3 : Salesforce Edge Networkが有効になっていることはどこで確認できますか?A3 : [設定] > [クイック検索] >「私のドメイン」と入力し、[私のドメイン]を選択してください。 [ルーティング] セクションでご確認いただくことができます。詳細は 「拡張ドメインの前提条件」の「組織が Salesforce Edge Network の対象かどうかの判断」をご覧ください。尚、現在はSalesforce Edge Networkが無効でも拡張ドメインは有効化できます(参考情報 : Enhanced Domains Available Everywhere Except Public Cloud)Q4 : Experience Cloud サイトや Salesforce サイトを使用していない場合は、影響はありませんか。A4 : 外部向けのURLだけではなく、内部向けのURLが更新されるものもございます(Visualforceなど)。これによりAppExchangeパッケージやお客様のカスタマイズに影響がある可能性もございますので、Experience Cloud サイトや Salesforce サイトを使用していない場合も、Sandboxでの動作確認/テストを推奨します。Q5 : Salesforce Edge Networkも自動有効化の対象でしょうか。A5 : いいえ。Salesforce Edge Networkは自動有効化の対象ではありません。Q6 : 現在使用しているカスタムドメインには影響はありますか?A6 : Experience Cloud サイトや Salesforce サイトで使用するカスタムドメイン自体には影響はありません。CDN 等の外部 HTTPS ベンダーでカスタムドメインを使用している場合、外部 HTTPS ベンダーが Salesforceへの転送先ドメインを変更する必要がある場合があります。詳細は「ドメインの外部 HTTPS の有効化」を参照ください。Q7 : API接続には影響があるのでしょうか?A7 : Sandbox についてはURLに「sandbox」という文字列が追加されるため、影響がでる可能性があります。また、.cloudforce.com や .database.com のドメインサフィックスを使用した組織では、変更される前のドメインサフィックスである .cloudforce.com や .database.com を使用したインテグレーションで失敗する可能性があります。Q8 : 拡張ドメインの有効化後に何かしらの問題が発生した場合にはどのように対応したらよいでしょうか?A8 : 自動有効化の前であれば拡張ドメインは有効化/無効化を実施することが可能です。自動有効の前に拡張ドメインを有効にする事で、何か問題が発生しても拡張ドメインを戻せるため、問題に対応する時間が取れます。もし、何かしらの問題が確認された場合は、弊社サポートにお問合せ下さい。
-
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 REST & SOAP Web Services、Apex クラス、Apex トリガ、Visualforce ページただし、AJAX Toolkitを介して行われるバージョン指定されたAPIコールを埋め込んだVisualforceページやカスタムボタン、Sコントロールはこの廃止による影響を受けますバージョン 30.0 以前のメタデータコンテンツを参照している管理パッケージ標準の Salesforce B2B Commerce for Visualforce 製品お客様の実装にこの変更の影響を受けるカスタマイズが含まれているか確認するには、記事を参照してください。この廃止は以下のものに影響します。データローダ Web Services ConnectorAJAX Toolkit を介して行われる従来のAPIコールSForceOfficeToolkit COM インターフェースを介して行われる従来のAPIコールForce.com Toolkit for PHPアウトバウンドメッセージによって生成されたペイロードから呼び出されたSOAP API廃止スケジュールお客様にて必要な対応「そんな急に廃止と言われても・・・」と戸惑っているシステム管理者の方もいらっしゃるかもしれません。Salesforceでは、システム管理者様宛に、月次で、以下のような 機能廃止ダイジェストメール等でお知らせしています。※終了日は2023年6月1日となっていますが、最新情報はSummer '25リリース日となります。(リリース日はTrustサイトにてご確認いただけます)推奨する対応順序例えば、設計書や実際にデータ連携している箇所を調査する。外部システムやツール(データローダ等)を使って Salesforce へ接続するアプリケーションの有無とバージョンを確認組織内の開発で AJAX Toolkit等を使用した実装有無とバージョンを確認こちらの資料を参考に、見落としがちな設定を確認追加でご確認いただく手段として、ログイン履歴の確認やAPI でのアクセス状況をイベントモニタリングログから確認いただくことが可能です。(こちらのP.10参照) 手順1、2で確認した箇所の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 セキュリティガイド(開発者ガイド)接続アプリケーションのセッションポリシーの管理(ヘルプ)セキュリティ状態チェック(ヘルプ)
-
IPA(独立行政法人情報処理推進機構)は、その年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から脅威候補を選出し、情報セキュリティ分野の有識者が審議・投票を行い決定したものを「情報セキュリティ 10大脅威」として公開しています。2021年度、「ランサムウェアによる被害」が昨年5位から1位にランクを上げて注目を浴びています。(出典: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のデータをどのようなルールで共有するか(データへのアクセス権をどうするか)最終的に、どのようなロール階層にするか共有ルールを使用するか、使用する場合にはどのようなルールにするか誰がどの取引先を担当するか取引先の新旧担当者一覧の作成商談の担当はどうするか例:現在進行中の商談の担当者は変更しない、完了している商談の担当は変更しない(過去の実績を組織の体制変更前の担当で把握する必要がある場合は、担当者を変更しないでください)活動の担当はどうするか例:まだ完了していない活動の任命先を変更するか/しないか注意事項:上記以外のオブジェクトを使用している場合は、オブジェクト毎に担当をどのようにするかを決めておきましょう。移行ルールが決まったら、次の流れで変更作業を行いますロール・共有ルールの変更ユーザ情報の変更各データの所有者変更1.ロール・共有ルールの変更まずは組織の土台となるロール、およびロールを使用した共有ルール(アクセス権)の設定を行います。ロールや共有ルールは、2.ユーザ情報の変更作業が完了するまでは反映されません。そのため、ユーザ情報変更作業前に、あらかじめ準備をしておきます。組織の体制変更後の状態に合わせて、ロールを変更します。新たな部署が追加される場合は、[ロールの追加]からロールを作成します部署が統合される場合も、新たな部署を作成します。統合前の部署を残しておくと、退職したユーザのロールを変更する必要がありません階層構造の変更はなく単なる名称変更の場合は、[表示ラベル]と[レポートに表示するロール名]を変更します階層構造が変わる場合は、[このロールの上位ロール]項目を変更します会社の合併など、大幅な組織体制変更の場合は、新しいロール階層を定義することをお勧めします。組織の体制変更の前日までは、旧体制のまま業務を行う必要があると思いますので、あらかじめ新組織体制の準備でロールを作成しておき、新組織体制に変わるタイミングでユーザ情報を更新して新しいロール設定を反映させます。次に、ユーザ情報を変更して、新しい組織体制を反映させましょう。2.ユーザ情報の変更組織の土台となるロールおよび共有ルールの設定が終わったら、ユーザ情報の変更を行います。ユーザ情報は、以下3種類の方法で変更することができます。ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面から複数ユーザを一括で変更するデータローダを使用するユーザの詳細画面の[ロール]項目を変更するロールの詳細画面の[ユーザをロールに割り当て]で、複数ユーザを一括で変更する(具体的な操作手順は、「ユーザへのロールの割り当て」(ヘルプ)をご覧ください)データローダを使用する組織の体制変更がある場合、一般的には、ロールを変更するタイミングでプロファイルや部署名、役職名等も変更になることがあると思いますので、それらを一度に変更ができるデータローダを使用することをお勧めします。(データローダの使い方ついては「初めてのデータローダ 〜Update編〜」(サクセスナビ)をご覧ください)注意点:承認プロセスにマネージャー項目を使用している場合は、マネージャー項目も忘れずに変更しましょう。ユーザ情報の変更が完了したら、取引先や商談などのデータを変更します。3.各データの所有者変更事前に定義した移行ルールに従い、データの所有者(や任命先)を変更します。所有者の変更は、画面上から行える「所有権の一括変更」もしくはデータローダをご利用いただけます。どちらのツールが適しているかは、以下をご確認ください。注意点:「所有者の一括変更」機能を利用できるのは、リード、取引先、カスタムオブジェクトのみです上記フロー以外のデータ(例:現在の所有者が所有している完了している商談など)の扱いについては、オプションで選択をすることができます。以上で、組織の体制変更があった場合に、システム管理者様にて対応が必要な作業は完了です。学習ツールロールの項目(ヘルプ)ユーザの項目(ヘルプ)データの所有権の移行(ヘルプ)取引先の一括変更で、同時に移行されるデータについて(ナレッジ)まとめ変更作業を始める前に、移行ルールを決めておくことが重要ですデータ変更に使用できるツールは「所有権の一括変更」とデータローダがありますので、要件にあう方を選択しましょう
-
この記事で学べることユーザ管理に必要な基礎知識を学ぶことができますユーザの管理に使用できる便利な機能を知ることができます知っていますか?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 組織で事前にロードされたサンプルデータを削除する(ナレッジ)まとめご契約前のお客様は、サンプルデータを一括削除することができます。ご契約後であったり、自動作成されたサンプルデータのみを削除する場合は、[一括削除]や[データローダ]を使用します。
-
-
この記事で学べること多要素認証 (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 のテスト計画を立てる際の参考となれば幸いです。どうぞよろしくお願いいたします。
-
この記事で学べること多要素認証導入 (MFA) に際しての体制とロールアウト戦略の検討ポイントを把握することができます ロールアウトの計画ロールアウトを成功させるにあたっては、下記の 3 点をプロジェクトの計画の条件に含める事が重要です。ロールアウト戦略変更管理サポートチームロールアウト戦略ロールアウトの戦略を考えていく上では、まずどのユーザに対して MFA を有効化していくかという点を考慮する必要があります。考慮する際には、ユーザが持つ権限が 1 つ考慮する上でのポイントとなります。例えば、“システム管理者権限”を持つユーザは全てのデータへのアクセスや、組織の設定自体も変更可能です。なので、まずはこのような強力な権限を持つユーザに対して優先して MFA を適用頂く事がセキュリティを担保する上で重要となります。次に、一部のユーザグループから適用を進めるのか、それとも全ユーザに対して同時にロールアウトするのかを検討します。会社の規模等にもよりますが、例えば一部のシステム管理者権限のユーザでパイロットとして開始パイロット後、残りの管理者ユーザや権限が強いユーザで開始最後にその他の一般ユーザーに対して開始といったステップや、部署ごとにロールアウトするといった選択肢が考えられます。また、ロールアウトのスケジュールを考えるにあたっては、自社内の競合する可能性があるプロジェクトの有無を確認し、同時での稼働開始を避けることもポイントとなります。ロールアウトのプランを計画する際に役に立つ推奨事項とガイドラインについては、下記のヘルプサイトの記事も併せてご参照下さい。MFA 実装およびテスト計画の定義 変更管理次に変更の管理です。変更の管理の主な目的はエンドユーザーに対して MFA が導入される旨を伝え、実際のリリース日までに告知やトレーニングを通じて MFA の導入に関与してもらい、リリースに備えるという点になります。観点としては、ユーザにどう伝えるのか (コミュニケーションとマーケティング)ユーザをどうトレーニングするのか導入やリリース当日のサポート体制の検討はどうするのかといった事があげられます。サポートチーム3 点目はサポートの体制です。一度 MFA をエンドユーザにロールアウトされますと、例えば認証に使う携帯電話を家に忘れて来てしまった、セキュリティキーを紛失してしまった、といった事が発生する可能性が見込まれます。このような事態に備えて、ポリシーとプロセスを先んじて確立・周知しておくことが重要になります。また導入にあたってサポートを実施される方に対して、設定やトラブルシューティング、またアクセスの復旧手順を整え、事前にトレーニングを施すことも重要です。併せて、新しく会社に入社された方が最初から MFA を利用できるような運用(例:入社時の実施必須事項に追加する)も継続的な運用の観点から大切なポイントとなります。学習ツール管理者向け多要素認証クイックガイド多要素認証ロールアウトの計画MFA 実装のサポートの準備 まとめこの記事では、MFA のロールアウトにあたっては、ロールアウト戦略変更管理サポートチームの 3 つの観点をプロジェクトの計画を立てる際に条件として含める事が重要である旨を紹介させて頂きました。お客様毎にロールアウトの戦略も変わってくるものと想定されます。上記の内容をご参照の上で、ロールアウトの戦略・体制作りの検討をお願い致します。