Mark Hammer's Blog

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

Salesforce MFAのマニュアル一覧

MFAのマニュアルについて、たまに質問されることがあったのでURLを書いておきます。

日本語版

英語版

その他外国語版

上記言語以外のユーザに対してはMFAロールアウトパックが用意されています。
これは、MFAに関するユーザ説明用資料が以下言語分全てダウンロードできる内容になっています。

  • 日本語(JP)
  • 英語(EN)
  • ドイツ語(DE)
  • スペイン語(es-MX)
  • フランス語(FR)
  • ポルトガル語(pt-BR)
  • 中国語(zh-CN)

多国籍のユーザに案内をする担当者には心強い資料だと思います。
ただし460MBありますのでダウンロード時間に注意してください。

レコードタイプ、ページレイアウト、○○プロセスの分け方を考える(認定アドミニストレータ向け)

最近、会社にてチームメンバーにSalesforce認定アドミニストレータ試験の勉強会を開いています。
その中で、「レコードタイプ、ページレイアウト、セールス/サポート/リードプロセスの使い分けが分かりません」と言われたので、サンプル問題を使って解説しました。
その内容をここにも残しておきます。

サンプル問題

AWコンピュータ社の営業とサポートは、ケースで異なる項目を管理しています。
またCPU、メモリ、マザーボードの3つの製品ラインがあり、それぞれ異なるサポートプロセスと入力が必要な項目があります。
この要件を満たす実装はどれですか?
【選択肢】
A. レコードタイプを2つ、ページレイアウトを6つ、サポートプロセスを2つ
B. レコードタイプを6つ、ページレイアウトを3つ、サポートプロセスを3つ
C. レコードタイプを3つ、ページレイアウトを6つ、サポートプロセスを3つ
D. レコードタイプを3つ、ページレイアウトを2つ、サポートプロセスを3つ

解説

選択肢の機能について

選択肢に記載されている3つの機能について詳しい解説はここでは行いませんが、この中でレコードタイプは特に制約がありません。
一方、他の2つの機能は、以下の通り別の機能が関連します。

  • ページレイアウト:レコードタイプとユーザプロファイルによって決まる
  • サポートプロセス:レコードタイプによって決まる

つまり、ページレイアウトを分けたいならレコードタイプかユーザプロファイルを追加する必要があり、サポートプロセスを分けたいならレコードタイプを追加する必要があります。

問題文の読み込み

1文目

まず、1文目から読み進めます。
「営業とサポートは、ケースで異なる項目を管理」とのことなので、ここから「営業とサポートには自分たちが管理する項目だけ表示させる必要がある」→「営業とサポートでページレイアウトを分ける必要がある」と読み取れます。
また、営業とサポートは利用ユーザのため、「営業とサポートで別のユーザプロファイルを用意し、各プロファイルごとに別のページレイアウトを割り当てる必要がある」と判断できます。

2文目

次に2文目ですが、
「CPU、メモリ、マザーボードの3つの製品ラインがあり、それぞれ異なるサポートプロセスと入力が必要な項目がある」とのことです。
つまり、サポートプロセスは3つの製品ラインごとに用意する必要があります。
また、「3つの製品ラインごとに異なる『入力が必要な項目』がある」とのことなので、3つの製品ラインごとにページレイアウトも用意する必要がある、と読めます。

ここで、前述の通り「ページレイアウトを分けたいならレコードタイプかユーザプロファイルを追加する必要があり、サポートプロセスを分けたいならレコードタイプを追加する必要がある」ので、3つの製品ラインごとにレコードタイプを用意する必要があります。
結果、2文目からは「3つの製品ラインごとにレコードタイプを用意し、それぞれ別のサポートプロセスとページレイアウトを割り当てる必要がある」と判断できます。

各機能の個数を決める

ここまでの話で、レコードタイプ、サポートプロセスは2文目の要件でしか使用しないこと、また3つの製品ラインごとにレコードタイプを用意することから、「レコードタイプは3つ」、「サポートプロセスは3つ」と決まります。
この時点で、回答はCかDのいずれかです。

【選択肢】
A. レコードタイプを2つ、ページレイアウトを6つ、サポートプロセスを2つ
B. レコードタイプを6つ、ページレイアウトを3つ、サポートプロセスを3つ
C. レコードタイプを3つ、ページレイアウトを6つ、サポートプロセスを3つ
D. レコードタイプを3つ、ページレイアウトを2つ、サポートプロセスを3つ

最後のページレイアウトですが、「問題文の読み込み」節にて以下のように読み取りました。

  • 1文目から、営業とサポートで別のユーザプロファイルを用意し、各プロファイルごとに別のページレイアウトを割り当てる必要がある
  • 2文目から、3つの製品ラインごとにレコードタイプを用意し、それぞれ別のページレイアウトを割り当てる必要がある

これを表にすると、以下のようになります。

「CPU」レコードタイプ 「メモリ」レコードタイプ 「マザーボード」レコードタイプ
「営業」プロファイル 「営業&CPU」ページレイアウト 「営業&メモリ」ページレイアウト 「営業&マザーボード」ページレイアウト
「サポート」プロファイル 「サポート&CPU」ページレイアウト 「サポート&メモリ」ページレイアウト 「サポート&マザーボード」ページレイアウト

よって、用意するページレイアウトは6つとなり、答えはCとなります。

【選択肢】
A. レコードタイプを2つ、ページレイアウトを6つ、サポートプロセスを2つ
B. レコードタイプを6つページレイアウトを3つ、サポートプロセスを3つ
C. レコードタイプを3つ、ページレイアウトを6つ、サポートプロセスを3つ
D. レコードタイプを3つ、ページレイアウトを2つ、サポートプロセスを3つ

おわりに

この問題を解くのに最も重要な点は、

  • ページレイアウト:レコードタイプとユーザプロファイルによって決まる
  • サポートプロセス:レコードタイプによって決まる

が理解できていることだと思います。
その上で、問題文からレコードタイプ、ページレイアウト、○○プロセスをどう分けるかを考える力が必要になるでしょう。

Lightningで活動タイムラインが表示されない時に確認する場所

はじめに

通常、Lightning Experienceのレコードページでは、「活動」タブに活動タイムラインが表示されます。

しかし、何をしたわけでもないのに「活動」タブが消え、活動タイムラインも表示されない場合があります。

今回は、このような「活動」タブが消えた際に確認した方がよい設定箇所をご紹介します。

「レコードページの設定」画面

Salesforceには「レコードページの設定」という設定画面があります。
そして、この画面にある「デフォルトの活動ビュー」にてLightning Experienceでの活動を「活動タイムラインで表示する」か「Classicと同様、関連リストとして表示する」かを選択できます。
なお、この設定画面は全体設定だけでなく、個人設定画面にも表示されます。

  • 設定画面

  • 個人設定画面

「デフォルトの活動ビュー」にて「関連リスト」を選択すると「活動」タブが消え、活動タイムラインも表示されません。
その代わり、Lightningレコードページに「活動予定」「活動履歴」関連リストが表示されます。(「活動タイムライン」を選択した場合は「活動予定」「活動履歴」関連リストは表示されません。)

「活動リスト」を選択した場合のLightningレコードページ

上記の通り、「デフォルトの活動ビュー」は個人設定画面にもあるため、「他の人は活動タブが表示されているのに、自分だけ表示されない」という事態も起こりえます。
このような場合は、まずは個人設定画面の「レコードページの設定」を確認することをお勧めします。

追記

「レコードページの設定」では「関連リスト」と「活動タイムライン」どちらかを選ぶ形式のため、「活動タイムライン」と「活動予定」「活動履歴」関連リストを同時に表示させることはできません。
ただし、Lightningレコードページにて「関連リスト - 1つ」コンポーネントを使うことで「活動タイムライン」と「活動予定」「活動履歴」関連リストを同時に表示させることができます。

Lightningレコードページ作成画面

Appendix

Salesforce MFAの紐づけをシステム管理者が代行する方法を考えてみた

(この投稿はSalesforce Advent Calendar 2021の12日目です) qiita.com

どうも、Mark Hammerです。
そういえば今日はSalesforce ハッカソン 2021の発表日ですね。
どういった成果物が出てくるのか楽しみに見たいと思います。

developer.salesforce.com

はじめに

2021年、Salesforce界隈を騒がせたMFA必須化。
皆さん2022/2/1の必須化開始に向けてアプリのインストールや機器の購入、社内調整等で大変かと思います。

私はTrailblazer CommunityのMFAに関するグループをたまに眺めているのですが、そこで出てくるのが「ユーザがMFAアプリを登録するのではなくシステム管理者が登録することはできないのか」という質問。
ちなみにSalesforce AuthenticatorやGoogle Authenticator等サードパーティアプリを使用する場合、以下の流れになります。

  1. 事前にSalesforceの私の設定画面でSalesforce AuthenticatorかGoogle Authenticator等サードパーティアプリの紐づけを行う。
  2. Salesforceログイン時にMFAを必須にする設定を行う。
  3. 2.設定後にSalesforceにログインした際に表示される認証画面で紐づけしたアプリを使用して認証する。

ここで必ずユーザが実施しなければならない作業が1.の紐づけなのですが、これをシステム管理者が代行できるとすれば、以下の要件を満たす必要があると考えます。

  1. ユーザの持つアプリを特定できる情報をSalesforce側にインポートできる。
  2. 1.でインポートした際にユーザの持つアプリに自動でSalesforce認証用情報が登録される。

しかし1.のインポートといっても、Salesforce Authenticator紐づけの際は英単語2個、サードパーティアプリ紐づけの際はSalesforce側に表示されるQRコードか認証コードを用いる必要があるため、アプリ側の情報をSalesforce側にインポートできるように見えません。
2. に至ってはアプリ側の操作なしに自動でSalesforce認証用情報が登録されるというのは無理があるように見えます。
よって、「頑張ってユーザに紐づけ操作してもらってください。」というのが今までの認識でした。

Secretコードによる認証アプリの紐づけ

この認識が変わったのは2021/11/4に行われたMFA FAQの更新です。(日本語版FAQには投稿時点で未反映)
「What are third-party TOTP authenticator apps?」にて、Salesforceにハードウェアトークンを登録できるとの情報が記載されました。
そこに記載されていた説明文では、データローダ等でTwoFactorInfoオブジェクトに対しSecretコードをインポートできるとの記載がありました。

To associate a hardware token with a user, insert a TwoFactorInfo object into the database, as described in the Salesforce Object Reference. You need to provide the Secret, the user's ID, and specify the Type field as 'TOTP'. You can use the Data Loader, Workbench, or custom Apex to insert TwoFactorInfo objects into the database.

おそらくハードウェアトークンであればSecretコードは製品のどこかに記載があるのだと思います。
ではアプリ紐づけの際に使えるSecretコードを取得することはできないのだろうか、と情報を探しました。
そして、ApexのSessionManagement クラスにて、 getQrCode() 関数の存在を知りました。

Apex 開発者ガイド:SessionManagement クラス より抜粋

getQrCode()
多要素認証 (MFA) 用の認証アプリケーションまたはデバイスを設定するための、QR (Quick Response) コードと時間ベースのワンタイムパスワード (TOTP) の共有秘密への URL が含まれる対応付けを返します。

これで、特定のSecretコードを認証アプリに登録するためのQRコードを発行できるURLを入手できました。

(匿名 Apex コード)
Map<String, String> codeResult = Auth.SessionManagement.getQrCode();
String result = 'URL: '+codeResult.get('qrCodeUrl') + ' SECRET:  ' + codeResult.get('secret');
System.debug(result);

(Output)
USER_DEBUG [3]|DEBUG|URL: https://sampledomain.my.salesforce.com/secur/qrCode?w=200&h=200&t=tf&u=sample%40example.com&s=3C2IC7JFL7SXMGSQSMLTJKFIZSXJOXG0 SECRET:  3C2IC7JFL7SXMGSQSMLTJKFIZSXJOXG0

このURLの secret 部分は英数字であれば書き換えても利用可能です。
これを利用して、Salesforceへの認証アプリ登録をシステム管理者が実施することが可能になりました。

システム管理者が認証アプリを紐づけする手順

データローダでの作業

※作業前に、システム管理者に「API で多要素認証を管理」権限を付与する必要があります。
この権限は「システム管理者」標準プロファイルにはないため、カスタムプロファイルか権限セットで付与してください。

UserId Type SharedKey
005xxYYYYYzzzzz*1 TOTP 0Z1Z2Z3Z4Z5Z6Z7Z8Z9Z0Z1Z2Z3Z4Z5Z*2
  • データローダ等を用いて「2要素情報(TwoFactorInfo)」オブジェクトにInsertを行う。
    • データローダ利用の際はオブジェクト選択時に「Show all Salesforce objects」にチェックを入れること。
    • Insert成功時、紐づけ先ユーザには「Salesforce アカウントに新しい検証方法が追加されました」というメールが届くため、事前にユーザに説明が必要。

ユーザへのQRコード提示

上記作業はあくまでSalesforce側への登録のため、これだけではユーザが持つアプリにSalesforce認証用の情報が入りません。
そのため、以下URLやSecretコードを連携してアプリに登録してもらいます。

メリットとデメリット

この方法のメリットとデメリットは以下の通りです。

  • メリット
    • ユーザが行うのは認証アプリでのQRコードの撮影、またはコード入力のみ。Salesforceの画面操作は不要。
    • QRコード撮影による登録の場合、アプリに表示する識別用文字列を自由に変更できる。*3
    • 極論、端末さえ貸してもらえればユーザのパスワードやメールで届く認証コードなしで多要素認証のアプリ紐づけが可能なのでシステム管理者のみの作業で済む。
  • デメリット
    • ユーザがアプリへの紐づけ登録を行わずに多要素認証を有効化した場合、Salesforceにログインできない状況が発生する。
      • この場合は一旦システム管理者がSalesforce側のアプリ接続を削除するしかない。
    • ユーザがアプリへの紐づけ登録をしたか否かはシステム管理者含む他の人には分からない*4ので、いちいちユーザに登録状況を確認する必要があり、面倒。
    • この方法で登録できるのはワンタイムパスワード認証(TOTP)のみで、Salesforce Authenticatorやセキュリティキーの登録はできない。

個人的には、この方法は「システム管理者が登録を代行したい」という要望がなければ考えない方法であり、あまり有用とは思っていません。
ただ、「こういう方法もあるよ」ということで今回投稿してみました。

悪い例:セキュリティ強度が落ちる紐づけ

通常、TwoFactorInfoオブジェクトに登録する SharedKey (Secretコード)はユーザごとに異なるのですが、 SharedKey 項目にはユニーク制約がないので、複数のユーザに同じSecretコードを設定することができます。
また、複数の認証アプリに同じSecretコードを設定すると、(当然ながら)同じ6桁の認証コードが表示されます。

つまり、以下のような設定も可能なわけです。

  • TwoFactorInfoオブジェクトへのインポートで、全ユーザに同じ SharedKey (Secretコード)を設定する。
  • ユーザのアプリ紐づけ用QRコードのURL、コードを1つ作成し、全ユーザに連携する。
    • URLの u パラメータは会社名などにする。
  • 全ユーザの認証アプリに表示される認証コードは同一のため、自分の端末を失くしても他の人の端末(認証アプリ)があれば認証できる。

…まぁこれは多要素認証の意味がなくなる設定なので、やったらダメですよ。

おわりに

TwoFactorInfoオブジェクトの存在から、MFAの紐づけをシステム管理者がどこまで代行できるか考えてみましたが、最終的なアプリの紐づけはユーザに実施してもらう必要がある*5以上、従来通りSalesforceの「私の設定」から紐づけしてもらうのが一番楽ではないか、という結論になりました。
ただ複数の方法を知っていることは何かの役に立つかもしれませんので、この投稿が(悪い例以外で)お役に立てれば幸いです。

追記:代理ログインによるMFA紐づけ代行

今回の調査を行った後に、システム管理者が他のユーザに代理ログインし、アプリ紐づけができるか試したところできることが分かりました。なので、この方法でもユーザのパスワードなしでMFA紐づけを代行することは可能です。
ただ、代理ログインでのアプリ紐づけの場合、ユーザ確認として確認コードのメール送信か、既に紐づけ済みのアプリによる認証が行われます。
通常アプリ紐づけは初回になるかと思いますので、ユーザに確認コードのメールを転送してもらう必要があります。

*1:紐づけしたいユーザID

*2:Secretコード

*3:従来のSalesforce画面で登録する場合、識別用文字列はユーザ名固定

*4:レポートやユーザ画面ではSalesforce上の紐づけ状況しか確認できないので、今回の方法ではアプリ紐づけ状況が分からない

*5:前述の通り端末を貸してもらえればユーザのパスワードなしに紐づけ代行はできますが、そこまでするシステム管理者はいないと思います

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

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

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

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

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

【Challenge要約】

※このChallengeにはセールスフォース・ドットコム社による解説があります。

  • 組織設定にて「言語のデフォルト値」を「英語」にしてください。
  • 事前に「ハンズオン Challenge の準備」節の作業を実施してください。
  • 新規Apexクラス「CountryCodeHelper」を作成してください。
  • 「ハンズオン Challenge の準備」節の「CountryCodeHelper Apex クラス」のコードをApexクラス「CountryCodeHelper」にコピー&ペーストしてください。
  • Apexクラス「CountryCodeHelper」を、getInstance メソッドを使用してカスタムメタデータの情報を返すように書き換えてください。
  • 不要なコードはコメントアウトではなく削除してください。(これはチェックしません)

Trailhead モジュール:Platform アプリケーションビルダー資格の更新 (Winter '22)

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

Winter '22 のアプリケーションビルダー向けの新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/platform-app-builder-certification-maintenance-winter-22/learn-whats-new-for-app-builders-in-winter-22

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

【Challenge要約】

※このChallengeにはセールスフォース・ドットコム社による解説があります。

  • 事前に設定|機能設定|アンケート|アンケートの設定 にて「アンケート」を有効にしてください。
  • 以下内容で権限セットを作成してください。
    • 表示ラベル:Create Surveys
      • API参照名:Create_Surveys
      • ライセンス:なし
      • 「アンケート」オブジェクト権限:参照、作成、すべて表示
    • 表示ラベル:Access to Contacts
      • API参照名:Access_to_Contacts
      • ライセンス:なし
      • 「取引先責任者」オブジェクト権限:参照、作成、すべて表示
  • 以下内容で権限セットグループを作成してください。
    • 表示ラベル:Contacts Survey
      • API参照名:Contacts_Survey
      • 説明:Access to create survey and read and edit access to contacts
      • セッションの有効化が必要:チェックを入れる
  • 作成した「Contacts Survey」権限セットグループに「Create Surveys」権限セットと「Access to Contacts」権限セットを追加してください。

SalesforceでログインをSSOに限定する方法

はじめに

Salesforceは通常ログイン画面でユーザ名・パスワードを入力してログインしますが、SSOログインも利用可能です。
また、ログイン方法をSSOのみに制限する方法もヘルプで公開しています。
Salesforce Help: SSO を使用したログインをユーザに要求

このヘルプの内容によると、ログイン方法をSSOのみに制限するには以下3点の設定が必要とのことです。

  • 私のドメイン設定にて [ https://login.salesforce.com からログインできないようにする ] を有効にする
  • シングルサインオン設定にて [Salesforce ログイン情報を使用したログインを無効化] を有効にする
  • ユーザプロファイルか権限セットで、ユーザに [シングルサインオンの有効] 権限を付与する

これを見たとき、こんな疑問を浮かべました。
「組織全体に影響するシングルサインオン設定でSalesforce ログイン情報を使用したログインを無効化して、ユーザに [シングルサインオンの有効] 権限を与える…。
これ [シングルサインオンの有効] 権限与えないとSalesforceにログインできなくなるのでは?」
ということで、検証してみました。

検証

まず、SSOログインが可能な環境を作成し、シングルサインオン設定にて [Salesforce ログイン情報を使用したログインを無効化] を有効にします。
その時の動作は以下の通りです。

  • SSOログイン:可能
  • ユーザ名・パスワードでのログイン:可能

[Salesforce ログイン情報を使用したログインを無効化] を有効にした時のログイン履歴

次にユーザプロファイルにて、 [Salesforce ログイン情報を使用したログインを無効化] を有効にした際に表示される [シングルサインオンの有効] 権限を付与します。
その時の動作は以下の通りです。

  • SSOログイン:可能
  • ユーザ名・パスワードでのログイン:「このシングルサインオンゲートウェイ URL は無効です」エラー

[シングルサインオンの有効] 権限を付与した時のログイン履歴

なお、 [シングルサインオンの有効] 権限を付与した場合APIログインもSSOを介さないとログインできなくなります。(ユーザ名・パスワードでのログインだと「このシングルサインオンゲートウェイ URL は無効です」エラー)

おわりに

[Salesforce ログイン情報を使用したログインを無効化] の名前だけ聞くとこの設定を有効にした時点で組織全体がSSOログイン以外無効化するように見えますが、実際はSSOログインに制限するためのユーザ権限である [シングルサインオンの有効] 権限を表示するためのものでした。
また、 [シングルサインオンの有効] 権限の名前だけだと「SSOログインができるようになるために必要な権限」と思われますが、実際には「SSOログインに限定するための権限」でした。
[シングルサインオンの有効] 権限の英語名は "Is Single Sign-On Enabled" ですので、日本語訳としては合っています。
ただ、(もう少し実際の動作に沿った権限名にしてほしかったなぁ…)と思った一件でした。

MFA FAQでは「システム管理者へのSSOログイン有効化はお勧めしません」とされていますが、仮にSSOを使用する場合、 [シングルサインオンの有効] 権限によるSSOログイン限定をシステム管理者のみ外す、という方法はありかな、と思いました。

Salesforce制限拡張、機能有効化のヘルプ一覧

はじめに

Salesforce Helpの中に、英語版のみではありますが制限拡張、機能有効化に関するヘルプ一覧がまとめられたページを発見しました。

Salesforce Help: Common Feature Activation and Limit Change requests

以下、上記ヘルプのリストを依頼方法に沿ってリスト化した制限拡張、機能有効化の一覧となります。
(日本語版が存在するヘルプは日本語版を、存在しないヘルプは英語版が表示されるようリンクを設定しています。)

制限拡張

Salesforceサポートへの問い合わせが必要なもの

拡張が有償、または担当営業(AE)に依頼するもの

拡張できないもの

機能有効化

Salesforceサポートへの問い合わせが必要なもの

有効化が有償、または担当営業(AE)に依頼するもの

有効化がユーザで可能なもの

依頼方法について

上記制限拡張、機能有効化を依頼する際、Salesforceサポートは以下の情報を要求します。

  • 依頼者がシステム管理者(「すべてのデータの編集」、「アプリケーションのカスタマイズ」両方の権限を持つユーザ)であること
    • 依頼ケースに依頼者のユーザ名を記載します。
  • 組織ID(本番、Sandbox)
  • 申請の理由

その他、申請内容によっては別途必要事項を記載する必要がありますので、事前に上記ヘルプを参照することをお勧めします。

*1:Winter '15 より前に Salesforce の使用を開始した場合はサポート問い合わせ

Salesforce DX CLI で脆弱性とされた機能の紹介と対応策

はじめに

2021/10/4に、CERT/CCよりSalesforce DX CLIについてアクセス制限不備の問題が指摘されました。

jvn.jp

www.security-next.com

これに対し、Salesforceでは Salesforce ヘルプ: Salesforce Developer Experience Command Line Interface の設定 を公開しましたが、具体性がなく何が起きているのか分からない内容となっています。

ここでは、実際にどのような操作が問題なのか、また対応策について書いていきます。

注意事項

筆者は普段Salesforce DX CLIを使っておらず、一部憶測を含む部分があります。
本投稿の内容を試した際など、掲載内容からいかなる損失や損害などの被害が発生したとしても、当ブログでは責任を負いません。(サイトポリシーの免責事項もお読みください。)

問題となる事象と再現方法

Salesforce DX CLI には、登録した組織・ユーザにコマンド1つでログインできる機能があるのですが、そのコマンドを実行した際にそのユーザとして組織にログインできるURLが出力されます。
これが今回問題となった機能と思われます。

再現方法

  • Salesforce DX CLI をインストールする。
    • インストール方法はこちらを参照してください。
  • sfdx force:auth:web:login を実行し、ブラウザ画面からSalesforceにログインする。これにより Salesforce DX CLI 側に組織、ユーザ情報が登録される。
  • sfdx force:org:open を実行する。これにより sfdx force:auth:web:login コマンドでログインしたユーザと同じユーザでログインした状態でブラウザが起動すると同時に、そのユーザとして組織にログインできるURLが出力される。

実際のコマンド実行と出力内容の例です。

> sfdx force:auth:web:login -a test
# このコマンド実行後、Salesforceログイン画面が表示された状態でブラウザが起動する。
# この画面でログインすることで Salesforce DX CLI 側に組織、ユーザ情報が登録される。

> sfdx force:org:list
=== Orgs
  ALIAS  USERNAME             ORG ID              CONNECTED STATUS
  ─────  ───────────────────  ──────────────────  ─────────────────────
  test   test@sampleorg.com   00DxxYYYYYzzzzzAAA  Connected
# force:auth:web:login でログインした情報が表示される

> sfdx force:org:open -u test
WARNING: This command will expose sensitive information that allows 
for subsequent activity using your current authenticated session.
Sharing this information is equivalent to logging someone in under the 
current credential, resulting in unintended access and escalation of privilege.
For additional information, please review the authorization section of the 
https://developer.salesforce.com/docs/atlas.en-us.234.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm

Access org 00DxxYYYYYzzzzzAAA as user test@sampleorg.com with the following 
URL: https://mysampledomain.my.salesforce.com/secur/frontdoor.jsp?sid=00DxxYYYYYzzzzz!heersgKJolaf0kq3rLMODASA...
Waiting to resolve the Lightning Experience-enabled custom domain...... done

上記コマンドの https://mysampledomain.my.salesforce.com/secur/frontdoor.jsp?sid=00DxxYYYYYzzzzz!heersgKJolaf0kq3rLMODASA... が「そのユーザとして組織にログインできるURL」です。
上記URLの sid はセッションIDを指すと思われます。つまりこのURLを悪用すればセッションハイジャックができてしまうということです。

cybersecurity-jp.com

なぜURLを出力しているのか

Salesforce DX CLI では、スクラッチ組織という開発者が開発のために作ることができる組織があります。(Developer Edition組織とは別です。)

trailhead.salesforce.com

この「スクラッチ組織を使って開発する」ことを考えたときに、複数人でチームとして開発しており、開発の内容をチーム内で確認してもらいたいときは「スクラッチ組織に開発者全員のユーザアカウントを作成してアクセスしてもらう」よりも「システム管理者としてログインできるURLを発行してそれをチーム内に連携する」方が便利です。
(「スクラッチ組織を作成→その組織にログイン」の流れが force:org:createforce:org:open とコマンドで完結し、ログイン画面を介さないため「ユーザ名とパスワードを連携する」という方法も不便になってしまう。)

よって、Salesforceとしてはこの機能は開発用に用意したものであり、本番環境はセッションハイジャックを防ぐためにセッション設定を用意しているのでそれを適用するように、というのが見解だと思われます。

対策方法

発行されたURLはログイン済のセッションを用いているため、ユーザ名、パスワードはもちろん多要素認証を必須にしていたとしても多要素認証の情報なしにログイン後の画面にアクセスできてしまいます。
さらに、ログイン履歴にもこのURLを用いたアクセスは記録されません。(アクセス後にレコードを参照すると、「最近参照したレコード」として記録はされます。)

発行されたURLからの外部アクセスを防ぐためには「セッションの設定」にて防止用の設定を導入する必要があります。 具体的には以下2点です。

ログイン時の IP アドレスとセッションをロックする

これはログイン時のIPアドレスとログイン後のIPアドレスが変わった場合にそのセッションを切断し、再度ログインを要求する機能です。
これにより、 Salesforce DX CLI で発行されたIDに外部からアクセスしようとしてもログイン画面に戻されます。
ただし、「ログイン時の IP アドレスとセッションをロックする」を有効にした後のログインが対象となります。有効にする前にログインした際のセッションはこの機能の制限を受けません。

これを有効にするとSalesforceアクセス後に自分の端末のIPアドレスが変わるとログイン画面に戻されることになります。(ノートPCやスマートフォンでは影響があるでしょう。)
また、Salesforceヘルプ: セッションセキュリティ設定の変更 にも「この設定は、さまざまなアプリケーションやモバイルデバイスの機能を妨げる可能性があります。」という注意書きがありますので、安易な設定はお勧めできません。

すべての要求でログイン IP アドレスの制限を適用

これはログイン IP アドレスの制限が設定されているユーザにてログイン後にIPアドレスがログイン IP アドレスの制限の範囲外になった場合、エラーとする機能です。

エラー画面

これも同様に、Salesforce DX CLI で発行されたIDにログイン IP アドレスの制限範囲外となる外部からアクセスしようとしてもエラーになりますが、Salesforceアクセス後に自分の端末のIPアドレスがログイン IP アドレスの制限範囲外になった場合もエラーになります。(ノートPCやスマートフォンで、VPN使用時にVPNが切断された場合などが該当するでしょう。)

備考

ここでは2つの設定を紹介しましたが、いずれにも言える点は「たとえ有効にしたとしてもセッションハイジャックを完全に防ぐことはできない」という点です。
具体的にはどちらの設定もログイン後にIPアドレスが変わったことをトリガとしてエラーとするため、「社内で Salesforce DX CLI により発行されたURLを盗み見てアクセスすればセッションハイジャックできる」といった内部犯行を防げません。(社内のPCに対しグローバルIPアドレスを個別に割り振っているのであればこのような内部犯行は防げますが、そのような会社はごく少数でしょう。)

よって、セッションハイジャックを完全に防ぐ方法として「本番環境では force:org:open を使わない」を提案します。
そもそも force:org:open はスクラッチ組織のためにあるものだと考えれば、ユーザ名、パスワードを入力すればログインできる本番組織には不要とも言えます。
コマンド1つでログイン画面が表示できるのは便利ではありますが、セキュリティを考慮すると本番環境では使わない方がよいと考えます。

おわりに

今回の問題はゲストユーザ問題と同様、責任共有モデルが大きく関わってきます。
つまり「Salesforceはセッションハイジャック防止用の設定を用意しているので、ユーザの責任で導入してください。」というものです。
しかし先述の通りアクセス元IPアドレスが変わらない状況にてセッションハイジャックを防ぐ機能がSalesforceにない現状では、片手落ちの印象も受けます。

本件について記載されたヘルプでは「今後、機能拡張があった場合は、この記事を更新します。」とのことですので、何らかの機能拡張があるか注目したいと思います。

Salesforceのリリースバージョン番号

はじめに

今年もDreamforceが終わりました。
Twitterを見てると、今年はワークフローとプロセスビルダーからフローに乗り換えに関する話題で盛り上がりましたね。
約1年後にはワークフローとプロセスビルダーの新規作成を禁止されるとなると結構な重要事項ですが、今回のテーマはそれではありません。

True to the Core オンデマンド録画の25分ごろからその話題になるのですが、ここでスピーカーのPatrick Stokes氏はタイムライン説明の際に "Spring ‘22" といった形ではなく ”Two thirty-six”, "Two thirty-eight", "Two fourty" と話しています。
しかし紹介したブログには、 "Spring ‘22", "Summer'22", "Winter'23" と従来のバージョン名で記載されています。
これはどういったことなのでしょうか。

Salesforceのリリースバージョンには番号がある

実はSalesforceのリリースバージョンには、"Winter'22"のような我々がよく知る「季節+年」の表記以外に数字のバージョン番号も設定されています。
それはSalesforceリリースノートのURLを見れば分かります。

このように、releaseURLパラメータがSummer'21では232、Winter'22では234と2増えています。
このルールは今後のバージョンでも同様ですので、

  • Summer'21: 232
  • Winter'22: 234
  • Spring'22: 236
  • Summer'22: 238
  • Winter'23: 240

となります。
Patrick Stokes氏はバージョンをこの番号で説明しており、それをブログ著者が「季節+年」の表記に書き換えたんですね。

おわりに

通常、Salesforceのバージョンは「季節+年」表記で表されており、一般ユーザがバージョン番号を聞くことは滅多にありません。*1
少なくともDreamforceのこのセッションは一般向けではなかった、ということでしょうか。

releaseURLパラメータはメジャーリリースごとに2増える、と覚えておくと先述のリリースノートのURLパラメータ書き換えだけで希望のリリースノートを見つけることができたりするなど*2、いいことがあるかもしれません。

*1:目にするのはSalesforceアプリのバージョン番号ぐらいでしょうか。それもあまり気にしませんよね。

*2:リリースノート画面にあるバージョン選択リストから選んだ方が早い、と言われるとそうですが…