Mark Hammer's Blog

SalesforceやTrailheadに関する情報を投稿しているブログです。

PCだけでSalesforce多要素認証を実現する(Authy)

2024/2/14追記

Authyデスクトップアプリは2024/3/19に提供終了(EOL)となるとのリリースが出ています。
引き続きPCにてMFA対応が必要な場合は、WinAuthChrome 拡張機能: Authenticatorの利用をご検討ください。代替アプリの詳細が知りたい場合は、合わせて「おわりに」節も参照ください。

はじめに

Salesforce多要素認証では、Salesforce AuthenticatorアプリかGoogle Authenticator等サードパーティ TOTP 認証アプリ、またはYubiKeyなどのセキュリティキーが必要となるため、「スマートフォンがない人はセキュリティキーを用意する必要がある」という認識でした。
しかし、以下のイベントでは「SMSの受信、または受電ができるデバイス(フィーチャーフォン含む)」と「Google ChromeがインストールされたPC」で多要素認証に対応する方法を説明する、とのことでした。

trailblazercommunitygroups.com

調べた結果、AuthyであればPCと電話でSalesforce多要素認証の対応が可能と分かりましたので、手順を書いてみます。

手順

Authy セットアップからログイン

まず、 https://authy.com/download/ にアクセスし、Desktopの枠から自分の利用しているOSを選択して 「Download」をクリックします。
この時、Windowsは32bitと64bitを選択する欄がありますが、自分がどちらを利用しているかは Microsoft社のヘルプ などを参考にしてください。

ダウンロードした exeファイルを起動すると、Account Setup 画面が表示されます。
この画面に電話番号を入力します。左の枠には「Japan」と入力して日本の国番号である「+81」を選択し、右の枠には自分の電話番号を入力します。

次に、認証方法を選択します。 スマートフォンなど、SMS受信可能な場合はSMSを、電話のみ可能な場合は Phone Call を選択します。
※この画面は既に初回認証が完了している電話番号を使用しているため、認証済みの端末を表す Existing Device が表示されていますが、一番最初の認証時は表示されないはずです。

・SMS を選択した場合
SMSを選択した場合は6桁の認証番号を入力する画面が表示され、認証番号がSMSにて英語の文面で届きます。
SMSで届いた認証番号を画面に入力すればOKです。

・Phone Call を選択した場合
Phone Call を選択した場合は、画面に2桁の数字が表示され、入力した電話番号宛に電話がかかってきます。 その電話を取り、表示された2桁の数字を入力すればOKです。(電話音声は英語です。)

認証が終わると、このような画面が表示されます。
これで準備は完了です。

Salesforce アカウントの多要素認証登録

※ここでは、「ユーザインターフェースログインの多要素認証」にチェックがあるユーザを利用します。

Salesforce ログイン画面からログインします。

「Salesforce Authenticator を接続」画面が表示されるので、「別の検証方法を選択」をクリック

「検証方法を選択してください」画面が表示されるので、「認証アプリケーションからの確認コードを使用」を選択し、「次へ」をクリック

「認証アプリケーションを接続」画面にてQRコードが表示されるので、「QRコードをスキャンできません」をクリック

「認証アプリケーションを接続」画面にてキーと確認コード入力画面が表示されるので、キーの文字列を全てコピー

Authy に戻り、「+」マークをクリック

コピーしたキーの文字列を「Enter Code ...」の枠に貼り付け、「Add Account」をクリック

確認コードを識別するための名前(任意。ここではSalesforceユーザ名として「admin@testaccount.com」を設定)、Authy上でのアイコン(Salesforceを選択)、トークン長(「6-digit」を選択)を設定し、「Save」をクリック

これで、Salesforce多要素認証用の認証コードが表示されました。

最後に、Salesforce画面に戻り「認証アプリケーションを接続」画面にてAuthyに表示されている確認コードを入力し、「接続」をクリック

以上でSalesforce アカウントの多要素認証登録は完了です。

多要素認証登録後のSalesforceログイン

通常通り、Salesforceログイン画面からログインします。

「IDを検証」画面にてAuthyに表示されている確認コードを入力し、「検証」をクリックします。

以上でログインは完了です。

おわりに

今回はAuthyを使って、スマートフォンアプリなしで多要素認証を行う手順を記載しました。
ちなみに検証していませんが、電話なしでPCのみでの多要素認証が可能なアプリもあるそうです。

なお、注意事項として多要素認証の認証コードを発行できる端末がPCのみの場合、そのPCがなければSalesforceにログインできないことになります。
また、電話番号が会社の固定電話の場合、会社以外からAuthyにログインできないため、会社以外でのSalesforce接続は不可、ということにもなります。
このようにSalesforceへの接続場所が固定されるデメリットもあるため、利用時は利用環境も含め検討されることをお勧めします。

Salesforce多要素認証: API接続でも多要素認証を求められるケース

※この投稿は2021/3時点の内容を基に記載しています。

はじめに

2022/2から必須となるSalesforceでの多要素認証(MFA)。
セールスフォース・ドットコム社のFAQでは、API接続は多要素認証必須化の対象外としています。

FAQから抜粋

しかし、「ユーザインターフェースログインの多要素認証」を有効にして多要素認証対応した場合でも、API接続に多要素認証が必要な場合があります。

データローダの場合

パスワード認証の場合

「ユーザインターフェースログインの多要素認証」を有効にしたユーザを用意し、データローダでパスワード認証を行った場合は、従来通り正常にログインができます。

パスワード認証の場合

OAuth認証の場合

一方OAuth認証の場合、表示されるSalesforceログイン画面にユーザ名、パスワードを入力すると多要素認証画面が表示され、多要素認証を行わなければログインできません。

OAuth認証の場合

Data connector for Salesforce の場合

Data connector for Salesforce は初めて利用する場合Salesforceアカウント認証を行いますが、その際にSalesforceログイン画面からのログインとなるため、「ユーザインターフェースログインの多要素認証」を有効にしたユーザの場合は多要素認証画面が表示されます。

Data connector for Salesforce 認証の流れ

ただし、既にSalesforceにログインした状態でData connector for Salesforce のSalesforce認証を行う場合は、AUTHORIZEボタンクリック後即アクセス権画面に移動するため、多要素認証は不要です。

Salesforce既ログイン時の Data connector for Salesforce 認証の流れ

まとめ

API接続の多要素認証について、実際はログイン経路によって多要素認証の要不要が決まるようです。

  • 多要素認証が必要な場合
    • Salesforceログイン画面からログインする場合(例: Data LoaderのOAuth認証、Data connector for Salesforce)
  • 多要素認証が不要な場合
    • ユーザ名、パスワードを直接ツールに入力してログインする場合(例: Data Loaderのパスワード認証)

実際に各自が利用しているツールで多要素認証が必要となるかは上記で判断できると思いますが、最終的には「ユーザインターフェースログインの多要素認証」を有効にしたユーザを用意し、ログインを試すのが一番確実かと思います。

「多要素認証の話」発表資料公開

2021/2/27の Salesforce Saturday 赤坂 にてLTで発表した、「多要素認証の話」の資料を公開します。

注意事項

  • この資料は2021/2/22週の資料、Salesforce動作に沿っています。
    • 情報は常に更新されますので、何か設定される際は最新情報をご確認ください。
    • この資料を参考にしたことによってトラブルが発生しても一切の責任を負いかねます。
  • この資料には、一部に個人的な予想・推測が含まれます。
    • 実際の行動は必ずセールスフォース・ドットコム社の公開情報を参考にしてください。

資料

Salesforceの多要素認証(MFA)必須化に合わせるための設定

※注意:この記事は投稿時点の情報、Salesforce動作に沿って記載しています。
SSOログインに対する多要素認証の扱いなど、現在のSalesforce公開情報とは異なる場合がございます。ご了承ください。

はじめに

今年2月に発表された、2022/2/1からのSalesforceログイン時多要素認証(MFA)必須化。

Salesforce ヘルプ:Salesforce 多要素認証に関する FAQ より

顧客は MFA を有効化する必要がありますか?
2022 年 2 月 1 日以降、すべての Salesforce 製品では MFA の有効化が必須になります。

Salesforce ヘルプ:Salesforce 多要素認証に関する FAQ では、ログイン時にMFAが必要なのは内部ユーザがユーザインターフェース ( https://login.salesforce.com からのログインやSalesforceモバイルアプリケーションからのログインなど )からログインする場合のみ、となっており、DataLoaderなどのAPIログインやSSOによるログインは必須化対象外となっております。

さて、実際にログイン時のMFAを有効化するにあたり、Salesforce ヘルプ:多要素認証ログイン要件の設定 ではユーザ権限とプロファイルのセッションの設定を変更する、2通りの実装方法が記載されております。

ユーザ権限
「ユーザインターフェースログインの多要素認証」権限をコピーしたユーザプロファイルまたは権限セットに割り当てます。

プロファイルベースのポリシー
デフォルトでは、ログイン時のセッションセキュリティ要件のプロファイル設定は [なし] になっています。プロファイルの [セッションの設定] を編集して要件を [高保証] に変更できます。[高保証] 要件が設定されたプロファイルユーザが、高保証ではなく標準レベルのセキュリティのログイン方法を使用すると、MFA を使用して ID を検証するように求められます。

これを見て、「なぜ2通り記載しているんだろう…どちらかでよいのでは?」と思い、実際の動作を検証してみました。

MFA設定と動作確認

ユーザ権限でMFAを実装

設定方法
  • 権限セットの場合
    システム権限から「ユーザインターフェースログインの多要素認証」にチェックを入れた権限セットを作成し、ユーザに割り当てる。

    権限セット設定箇所

  • プロファイルの場合
    一般ユーザ権限にある「ユーザインターフェースログインの多要素認証」にチェックを入れる。

    プロファイル設定箇所

結果

MFA必須化対象のログイン方法のみMFAが必要になりました。

  • ユーザインターフェースからのログイン:MFA必要
  • API(DataLoader)からのログイン:MFA不要
  • SSOでのログイン*1:MFA不要

プロファイルの「セッションの設定」でMFAを実装

設定方法

プロファイルの設定にて、「セッションの設定」セクションにある「ログインに必要なセッションセキュリティレベル」を「高保証」に設定します。

プロファイル設定画面

合わせて、セッションの設定画面で「セッションセキュリティレベル」の高保証に「多要素認証」を追加します。

セッションの設定画面

結果

ユーザインターフェースからのログインの他、API、SSO経由のログインもMFAが必要となりました。

  • ユーザインターフェースからのログイン:MFA必要
  • API(DataLoader)からのログイン:MFA必要
  • SSOでのログイン:MFA必要

おわりに

MFA必須化を実際に試す場合、現時点では「ユーザインターフェースログインの多要素認証」権限の割り当てが必須化対象に沿っており、最適だと思います。
なお、標準プロファイルでは権限変更ができないため、権限セットでの割り当てが必須となりますので注意です。

*1:SSOログインの検証はTrailhead: 内部ユーザのシングルサインオンの設定の手順にて実施。以下同様。

Salesforce Optimizerの「毎月実行」はいつ実行されるか確認してみた

はじめに

Summer' 20 からアプリケーションでのアクセスも可能になり、便利になったSalesforce Optimizer。

リリースノート:Optimizer アプリケーションによる組織メンテナンスのスピードアップ より

新たに登場した Salesforce Optimizer アプリケーションにより、対話的に組織の実装を確認して、エキスパートの推奨に基づいて Salesforce 組織をメンテナンスできます。パッケージをインストールする必要はなく、アプリケーションを有効にして、クリック操作で実行するだけで、組織が自動的に調べられます。

Salesforce Optimizer アプリケーションではどのようなことができるかは、以下が非常に参考になります。 note.com

dev.classmethod.jp

さて、Salesforce Optimizer の設定画面では毎月実行できるオプションがありますが、ヘルプテキストには「(毎月実行を)設定すると、Optimizerは毎月最後の週に実行されます」と表示されます。

Salesforce Optimizer 設定画面

一番最初に毎月実行を設定したのは11/22週だったのですが、「最終週だから11/29か11/30に実行されるのかなぁ…。」と思っていたら…、
11月には実行されませんでした。

理由が分からなかったため、自分の持つ環境にOptimizer毎月実行を設定し、しばらく放置してみました。*1

「毎月実行」のスケジュール結果

本番環境、Sandbox環境それぞれの結果は以下でした。

環境 2020/12の実行日 2021/1の実行日
本番環境 2020/12/20(日) 0:02 2021/1/20(水) 0:03
Sandbox環境 2020/12/22(火) 1:03 2021/1/22(金) 1:07

結果からの考察

  • 実行日はおそらく毎月20日以降。具体的な日付は組織単位(またはインスタンス単位)で決まっている。
    • その月の実行日を超えた後に「毎月実行」を設定してもその月は実行されない。「はじめに」節で11/22週に設定しても11月には実行されなかったのはそのためだと思われる。
  • 実行開始時間はおそらくAM0時。(Optimizerの最終実行日として記録されるのは開始時間ではなく終了時間。)
    • SandboxのOptimizer完了時間が1時となっているが、これはカスタマイズ量が多いSandboxを使用したためと思われる。

おわりに

考察通り「毎月実行」の実行日は毎月20日以降とすると、「Optimizerは毎月最後の週に実行されます」は正しくないことになりますが、そういうものと認識するほかなさそうです。
20日以降に「毎月実行」を設定したが、設定月の情報も欲しい、という方は手動実行でも情報取得できますので、そちらをお勧めいたします。

*1:ちなみにSalesforceサポートからは「実行スケジュールについては公開情報がないので自分で確認してください」といった回答でした。

Trailhead モジュール:Flow Troubleshooting

※この内容は2021/2時点のものです。

Review Flow Terminology and Sign Up for a Special Org

https://trailhead.salesforce.com/ja/content/learn/modules/flow-troubleshooting/review-flow-terminology-and-sign-up-for-a-special-org

  • 説明:英語
  • Challenge:英語ハンズオン

【Challenge要約】

Fix Access Issues in a Flow

https://trailhead.salesforce.com/ja/content/learn/modules/flow-troubleshooting/fix-access-issues-in-a-flow

  • 説明:英語
  • Challenge:英語ハンズオン

【Challenge要約】

重要:このチャレンジを完了するには、最初のユニットでサインアップした本モジュール用 Developer Edition 組織を使用してください。通常の Trailhead Playground 組織ではこのチャレンジを完了することはできません。

  • 事前にプロセスの自動化設定にて、「システム管理者が他のユーザとしてフローをデバッグできるようにする」を有効にしてください。
  • 「ケースを作成」フローを確認してください。
  • 以下内容でフローをデバッグしてください。
    • 別のユーザとしてフローを実行 にチェックを入れ、ユーザにMario Cruz*1を指定
    • あなた自身の情報を画面フローの各項目に入力してください
  • フローのエラー結果を確認してください。
  • ユーザ:Mario Cruzでもこのフローが実行できるよう、適切な権限を付与してください。
  • ユーザ:Mario Cruzへの権限付与後、再度以下内容でフローを実行し、成功することを確認してください。
    • 実行ユーザ:Mario Cruz
    • 名:Avi
    • 姓:Green
    • 電話番号:(212) 842-5500
    • ケース件名:Broken Laptop
    • ケースの詳細:Faulty power button

Fix Issues Caused by a Null Value in a Flow

https://trailhead.salesforce.com/ja/content/learn/modules/flow-troubleshooting/fix-issues-caused-by-a-null-value-in-a-flow

  • 説明:英語
  • Challenge:英語ハンズオン

【Challenge要約】

  • 「Alert Acct Owner of New Case Added」フローを有効化してください。
  • 取引先、取引先責任者を関連付けせずにケースを作成してください。
  • フローのエラー内容を確認してください。
  • フロー内のケースオブジェクトに条件の要件を追加して、エラーの原因を修正してください。
  • 以下内容で新規ケースを作成し、フローが成功することを確認してください。
    • 状況:New
    • 発生源:Phone
    • 件名:Server Offline
    • その他の項目はそのままにしてください。

*1:ユーザ地域が日本の場合、「Cruz Mario」と表示されます。以下同様。

Spring'21から使えるダッシュボードのURLパラメータフィルターの制約がレポートより厳しい話

はじめに

本投稿の基となったのはこちらの投稿です。(お役立ちコンテンツの数々、いつも見ております。) sf.forum.circlace.com

簡単に言うと、Spring'21からダッシュボードもレポート同様、URLパラメータによるフィルター指定ができるようになった、とリリースノートにはあるのですが、期待通り動作しないという話です。

Spring'21 リリースノート:検索条件 URL パラメータを使用したダッシュボードの結果の保存 より

Lightning Experience でダッシュボードを表示するたびに、同じ検索条件を設定する必要はありません。検索条件パラメータを含むカスタム URL を作成します。これにより、URL にアクセスしたときに、検索条件がすでに設定された状態でダッシュボードが開きます。たとえば、各取引先に異なる URL を使用して商談フェーズダッシュボードをカスタマイズしたり、取引先所有者またはリードソースのカスタム URL を作成したりできます。

最初に見たときは Idea Exchange でも「プレリリース環境で動かない」という投稿があったので未リリースなのかな、と思ったのですが、その後Salesforce担当者から使えるようになったとの投稿がありましたので、実際の動作を調べてみました。

実際の動作

結論から言うと、ダッシュボードのURLパラメータによるフィルターはリリースノート通りに動くのですが、レポートより制約が強い形でした。
具体的な動作の差は以下の通りです。

  • レポート
    • 検索条件の値の部分をfv0, fv1, ...パラメータで指定する。fv0=...の値の部分は何を入れてもよい。*1
  • ダッシュボード
    • 検索条件の値の部分をfv0, fv1, ...パラメータで指定する。fv0=...の値の部分はダッシュボードで設定した検索条件値しか許可されない。それ以外の値を入れると "This filter URL is invalid." エラーになる。

動作確認

以下は2021/2/1時点のSpring'21プレリリース環境で試しています。

レポートの場合

まず、フェーズと取引先名を検索条件としたレポートを作成します。

このレポートのURLに、 &fv0=Closed%20Won&fv1=Edge を追加すると、以下のようにURLパラメータを検索条件に反映したレポートが表示されます。

ダッシュボードの場合

ダッシュボードの場合、まず編集画面で検索条件を設定します。
ここでは、以下2つの条件を設定します。

  • フェーズ:「"Prospecting"と一致する」、「"Qualification"と一致する」の2つ
  • 取引先名:「"United"を含む」の1つ

フェーズの検索条件設定

取引先名の検索条件設定

次に、ダッシュボードのURLに&fv0=Prospecting&fv1=United を指定すると、指定された検索条件に沿ったダッシュボードが表示されます。

一方、ダッシュボードに設定していない検索条件、例えば&fv0=Closed%20Wonを指定すると以下のように "This filter URL is invalid. Please try again." が表示されます。

&fv0=Closed%20Won を指定したい場合は、事前にフェーズの検索条件に Closed Won を追加する必要があります。

おわりに

ダッシュボードのURLパラメータフィルターは確かに使えるようにはなっていましたが、レポートほどの自由度はありませんでした。
これは複数のコンポーネントを制御するダッシュボードでは、レポートほどの自由度を持たせることができなかったからかもしれません。
とは言っても検索条件さえ設定すれば期待通り動作しますので、従来より使いやすくなったとは言えるでしょう。

*1:スペースを"%20"に、といったパーセントエンコーディングは必要です

カスタム項目の作成日をまとめて取得したい

今回は、会社で依頼された「特定オブジェクトにあるカスタム項目の作成日を一覧化してほしい」という要望について手順を追って記載いたします。

黄色線の部分を各項目ごとに取得したい

全体の手順

  • 開発者コンソールを起動し、CustomFieldオブジェクトからSOQLにて項目作成日を取得
  • 開発者コンソールのSOQL結果をコピーし、Excelに表形式で貼り付け
  • 必要に応じて、貼り付けた結果をExcel上で加工

手順詳細

CustomFieldオブジェクトから項目作成日を取得

CustomField オブジェクトに対し、以下SOQLを発行します。

標準オブジェクトの場合
  • Lightning Experience の場合はオブジェクトマネージャから対象オブジェクトのAPI参照名を取得する。
  • Salesforce Classic の場合は設定|カスタマイズ|(オブジェクト)から対象オブジェクトを選択し、URLから対象オブジェクトのAPI参照名を取得する。 -- 例: Salesforce Classic で商談オブジェクトを選択した場合、URL https://XXX.salesforce.com/ui/setup/Setup?setupid=OpportunityOpportunity の部分
  • 取得したAPI参照名を使用し、開発者コンソールで以下SOQLを実行する。この時、[Use Tooling API]にチェックを入れてから[Execute]をクリックする。

例:商談(Opportunity)の場合

SELECT TableEnumOrId, DeveloperName, CreatedDate, LastModifiedDate 
FROM CustomField 
WHERE TableEnumOrId = 'Opportunity'

実行後の開発者コンソールキャプチャ

カスタムオブジェクトの場合
  • Lightning Experience の場合はオブジェクトマネージャ、Salesforce Classic の場合は設定|作成|オブジェクトから対象オブジェクトを選択し、URLからカスタムオブジェクトIDを取得する。
    • 例1: Lightning Experience の場合、URL https://XXX.lightning.force.com/lightning/setup/ObjectManager/01IxxXXXXXxxxxx/Details/view01IxxXXXXXxxxxx の部分
    • 例2: Salesforce Classic の場合、URL https://XXX.salesforce.com/01IxxXXXXXxxxxx?setupid=CustomObjects01IxxXXXXXxxxxx の部分
  • 取得したカスタムオブジェクトIDを使用し、開発者コンソールで以下SOQLを実行する。この時、[Use Tooling API]にチェックを入れてから[Execute]をクリックする。
SELECT TableEnumOrId, DeveloperName, CreatedDate, LastModifiedDate 
FROM CustomField 
WHERE TableEnumOrId = '01IxxXXXXXxxxxx'

実行後の開発者コンソールキャプチャ

開発者コンソールの結果をExcelにコピー

残念ながら、開発者コンソールにはSOQLの結果をCSV等にエクスポートする機能がありません。
そこで、Chromeデベロッパーツールを使ってSOQLの結果をExcelに貼り付けます。

  • F12キーを押してChromeデベロッパーツールを開く
    • この時、別タブの結果を取得しないよう開発者コンソールのタブは1つにすることが望ましい。

Chromeデベロッパーツールを開く

  • Ctrl+F キーを押して検索窓を開き、 grid-table と入力する

検索窓に"grid-table"を入力

  • grid-table 検索結果のうち一番上の行を右クリックし、 Copy -> Copy Element をクリック

Copy Elementを選択

  • Excelを起動し、適当なセルに貼り付ける
    • この時の注意事項は以下の通りです。
      • ヘッダがないため、必要であれば手作業で追加してください。
      • カスタム項目名はAPI参照名から __c がないものになっています。必要に応じて追加してください。
      • 日付/時間はUTC基準です。日本時間に直したい場合は9時間追加する必要があります。
        Excel数式だと =DATEVALUE(MIDB(<元データのセル>,1,10))+TIMEVALUE(MIDB(<元データのセル>,12,8))+TIME(9,0,0) とすれば修正できます。

Excelに貼り付け

Excelに貼り付けた内容を加工

おわりに

開発者コンソールでSOQL取得するまでは想定通りでしたが、そこからの加工が思っていたより大変でした。
開発者コンソールのクエリエディタにエクスポート機能を付けるIdeaExchangeもありますが、ぜひ実装いただきたいと思った一件でした。

trailblazer.salesforce.com

Appendix

今回参考にしたリソース一覧です。

salesforce.stackexchange.com

developer.salesforce.com

www.youtube.com

a1-style.net

Salesforce Tips: ゲストユーザの有無を調べたい

はじめに

楽天、PayPayにてSalesforceの設定不備により不正アクセスを受け、情報流出があったとの報道がありました。

xtech.nikkei.com

xtech.nikkei.com

これを受けてか、セールスフォース・ドットコム社でもプレスリリースを発表。
「当社製品の脆弱性に起因するものではなく、ゲストユーザに対する情報の共有に関する設定が適切に行われていない場合に発生する事象」と、設定の不備による点を強調しています。 www.salesforce.com

本件のまとめとしては以下Blogが参考になります。

piyolog.hatenadiary.jp

ここでは、改めて今回話題となったゲストユーザとは何か、そしてゲストユーザの有無をチェックする方法を記載します。

ゲストユーザとは

通常Salesforceはログイン画面からユーザ名、パスワードを入力してログインして使うものですが、Salesforceサイト、Experience Cloud(旧 Community Cloud)では公開Webサイトを作ることができます。
このとき、Salesforce認証を必要とせずにSalesforceの情報にアクセスさせることができます。

Salesforce ヘルプ: Salesforce サイト より

Salesforce サイトでは、公開 Web サイトとアプリケーションを作成できます。それらは Salesforce 組織と直接統合されるため、ユーザがログインする場合にユーザ名やパスワードは必要ありません。組織に保存された情報を任意のブランド URL を介して公開し、サイトのページを会社のブランドのデザインと一致させることができます。

Salesforce ヘルプ: ゲストユーザプロファイルを使用して認証されていないユーザに安全なアクセスを提供 より

公開コミュニティは、B2C (企業対消費者) での活用に適しており、幅広い利用者にアプローチできます。ゲストユーザプロファイルを使用して、コミュニティ内の認証を必要としないデータ、コンテンツ、オブジェクトへの公開アクセスを制御できます。たとえば、既存の顧客と見込み客がログインせずに他のメンバーまたはサポートによって投稿された公開ディスカッション、既知の問題、およびソリューションを参照できる、カスタマーサポートコミュニティを作成できます。

この「Salesforce認証を必要とせずにSalesforceの情報にアクセスさせる」時に使われるのがゲストユーザです。
ちなみに Experience Cloudではコミュニティユーザライセンスによりコミュニティ専用のユーザを作成することができますが、このユーザはSalesforce認証(ユーザ名、パスワード入力など)を行ったうえでコミュニティにアクセスするため、ゲストユーザとは別のものです。

ゲストユーザの有無チェック

ゲストユーザは Salesforceサイト、Experience Cloudを使用することで自動的に作成されます。
そのため、有効なSalesforceサイト、Experience Cloudがなければ今回の情報流出と同じことが起きる心配はありません。

ここでは、自分のSalesforce組織でSalesforceサイト、Experience Cloudを使用しているか否かを確認する方法を記載します。

Salesforceサイトの使用有無チェック

  • Salesforce設定画面左上にあるクイック検索ボックスに「サイト」と入力し、設定メニューの「サイト」をクリック。
  • この時に以下のようなドメイン名を登録する画面が表示された場合は、Salesforceサイトを利用していません。

Salesforceサイトを利用していない場合

  • 一方サイト一覧が表示された場合、そのサイト一覧のうち「有効」にチェックが入った行があればSalesforceサイトを利用しています。「有効」にチェックが入った行が一つもなければSalesforceサイトを利用していません。

サイト一覧に「有効」なサイトがある場合

サイト一覧に「有効」なサイトが一つもない場合

Experience Cloud(旧 Community Cloud)の使用有無チェック

  • Salesforce設定画面左上にあるクイック検索ボックスに「コミュニティ」と入力し、設定メニューの「コミュニティ設定」をクリック。
  • この時に以下のようなコミュニティを有効化するための画面が表示された場合は、Experience Cloudを利用していません。

コミュニティを有効化していない場合

  • 一方「コミュニティ設定」がこの画面ではなく設定一覧が表示される場合は、設定メニューの「すべてのコミュニティ」をクリック。
  • この時に表示されるコミュニティ一覧に「状況」が「有効」か「プレビュー」の行があればExperience Cloudを利用しています。コミュニティ一覧に何も表示されない、または「状況」が「無効」の行しかない場合は現在Experience Cloudを利用していません。

有効なコミュニティがある場合(状況がプレビュー)

有効なコミュニティがある場合(状況が有効)

有効なコミュニティがない場合(状況が無効)

ゲストユーザがあった場合

上記の手順で有効なSalesforceサイト、Experience Cloudが自分のSalesforce組織にあった場合、次にそのサイト、コミュニティで作成されているゲストユーザの権限を確認します。
セールスフォース・ドットコム社が公開している Trailblazer Community: ゲストユーザセキュリティベストプラクティスの解説 (※要Salesforceアカウント) では具体的な確認手順を含め記載されているため、こちらを参考にされることをお勧めいたします。
資料に書かれていた、主に確認すべき内容は以下の通りです。

  • ゲストユーザプロファイルに対し不要なオブジェクト権限(参照など)を付与していないこと
  • ゲストユーザプロファイルに対し「APIの有効化」権限を付与していないこと
  • ゲストユーザプロファイルに対し不要なApexクラスへのアクセスを許可していないこと*1
  • ゲストユーザに対し不要な個別共有ルールを設定していないこと*2
  • ゲストユーザに対し権限セットが設定されていないか確認すること
    • 権限セットが設定されている場合は、その権限セットに対してもゲストユーザプロファイルと同様の内容を確認すること

ちなみに問題を紹介したブログではauraエンドポイントを用いた情報取得を行っているため、一部ブログでは対策としてSalesforceサイトの「ゲストユーザのLightning機能」設定の無効化を案内していますが、セールスフォース・ドットコム社としては根本を断つ設定を案内しており、資料では「ゲストユーザのLightning機能」設定については触れていませんでした。

おわりに

今回はインパクトが大きい報道のため不安になった方も多いですが、まずはSalesforceサイト、Experience Cloudの状況を確認することをお勧めします。
そのうえでSalesforceサイト、Experience Cloudを使用している場合は、改めてゲストユーザの確認を行いましょう。
また、不明点はセールスフォース・ドットコム社の案内通り、サポートへ問い合わせて不安を解消されることをお勧めいたします。

*1:オブジェクト権限を付与していなくても、Apexクラス経由で情報を取得できる場合があるため

*2:セールスフォース・ドットコム社の資料によれば、ゲストユーザに対する組織の共有設定は現在「非公開」で固定されているとのことです

Trailhead モジュール:認定 Platform デベロッパー資格の更新 (Winter '21)

※この内容は2020/12時点のものです。

Platform デベロッパーの Apex の新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/platform-developer-i-certification-maintenance-winter-21/learn-whats-new-in-apex-for-platform-developers

  • 説明:日本語
  • Challenge:日本語選択問題

Lightning Web コンポーネントと Visualforce の新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/platform-developer-i-certification-maintenance-winter-21/learn-whats-new-in-lightning-web-components-and-visualforce

  • 説明:日本語
  • Challenge:日本語選択問題

項目レベルとオブジェクトレベルのセキュリティや安全なナビゲーション演算子を使ってみる

https://trailhead.salesforce.com/ja/content/learn/modules/platform-developer-i-certification-maintenance-winter-21/get-handson-with-field-and-objectlevel-security-and-safe-navigation-operator

  • 説明:日本語
  • Challenge:英語ハンズオン

【Challenge要約】

※このChallengeには、Salesforce公式解説があります。
注意:Challengeの前にこのユニットの「ハンズオン Challenge の準備」節の作業を完了してください。

  • 新規Apexクラス「ApexSecurityRest」を作成してください。
  • Apexクラス「ApexSecurityRest」に、「ハンズオン Challenge の準備」節にあるApexSecurityRest コードブロックのコードをコピーアンドペーストしてください。
  • results 変数に対し Security.stripInaccessible メソッドを使用して、ユーザに参照アクセス権がない項目を削除してください。
  • Name 項目と Top_Secret 項目に対するオブジェクト権限、項目レベル権限のチェックは冗長となるため削除してください。
    • 注意:不要なコードはコメントアウトではなく削除してください。
  • null 参照を回避するために、安全なナビゲーション演算子機能を取引先(Account)を参照している箇所に適用してください。