2020.07.10 「Salesforce のセキュリティ機能について：（２）セキュリティの観点から見た「シングルサインオン」と「私のドメイン」」

≪ 2020.07.03 「Salesforce のセキュリティ機能について：（１）データセキュリティの基本機能とプラットフォーム暗号化による拡張」

2020.07.17 「Salesforce のセキュリティ機能について：（３ - 最終回）シングルサインオンの補足とデバイス管理について」 ≫

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

皆様いかがお過ごしでしょうか。

冒頭の挨拶が毎回コロナ関連で恐縮ですが、本記事を執筆している時点（7/9）で、東京都の一日あたりの感染者が最多（224人）とのニュースが入ってきました。

弊社も５月末の緊急事態宣言解除以降、徐々に出勤者も増えてきましたが、先週あたりからの感染者数が再び増大しつつある状況を受けて、今後しばらくは在宅勤務中心の形態に戻るよう指示が出ております。

「長期戦の覚悟」で、必要以上に悲観することなく悠然と構えて、仕事でも日々の生活でも、やるべきことをしっかりとやっていきたいと思います。

Yahoo! Japan - 新型コロナウイルス感染症まとめ～「新しい生活様式」での感染症対策
https://hazard.yahoo.co.jp/article/20200207#LIFE

さて、現在お送りしているテーマは、「Salesforce のセキュリティ機能について」です。

第二回の今週は、「リモートワーク時代に必須の施策」ともいえる「シングルサインオンを活用した強固なセキュリティの構築」についてお送りします。

お客様の会社でも「コロナの第二波が来る前にリモートワーク体制を万全なものにしたい」というニーズがあるかもしれません。

その際にシングルサインオンの導入は非常に有益になるはずです。

併せて、先週の第一回「プラットフォーム暗号化」も、ご覧になられていない方は是非ご一読いただけると、今回の内容がよりご理解いただけるかと存じます。

2020.07.03 「Salesforce のセキュリティ機能について：（１）データセキュリティの基本機能とプラットフォーム暗号化による拡張」
https://csminfo.uhuru.jp/hc/ja/articles/900001638086

＊複数のサービスへのログインを一元管理することの利点と考慮事項

従来より Salesforce だけではなく G Suite や Microsoft Office 365 といった複数のネットワークサービスを併用されているお客様も多いかと思われます。最近はテレワーク需要から Zoom や WebEx などのオンライン会議アプリケーションもそれに加わっているものと存じます。

その場合、パスワード管理はどのように実施されていますでしょうか。
サービスごとに別々に管理されているお客様、決して少なくないのではと思われます。

サービスごとにアカウントとパスワードをそれぞれ管理することで、ユーザにおいては

パスワードを忘れてしまいがち
パスワードを忘れないように、毎回同じパスワードを設定しがち

というセキュリティのリスクを発生させてしまいます。
（中には「各サービスのパスワードを一つ一つ手書きして付箋をPCに貼り付ける」なんてことをされている方もいらっしゃるかもしれません！）

一方システム管理者にとっては、

ユーザがパスワードを忘れる頻度が高くなることで、その度にリセット手続きを実施することで管理コストが高まる
リセット手続きの頻度が高くなることで、「なりすましの申請」によって不適切にリセットが実施されてしまうリスクが高まる

という問題点があります。

それらの問題を解決するために、複数のネットワークサービスを接続し、一ヶ所のログイン認証によって、それ以外のサービスの認証を可能にするというセキュリティ上の仕組みがあります。

それが「シングルサインオン（SSO）」です。

SSO の利点は以下の通りです。

対ユーザ：各々のアカウントとパスワードを個別管理する必要が無く、パスワード漏洩のリスクが低減する
対管理者：ユーザのパスワードリセットの手間が低減されるなどの管理コストの低減、およびそれによるセキュリティリスクの低減

勿論いいことばかりではありません、当然デメリットもあります。

アカウントの管理場所が一ヶ所に集約されることで、「その一ヶ所」が攻撃されたら他のサービスにも波及してしまう
ログインを管理するサービスが仮に停止してしまった場合、復旧まで他のサービスにもログインできなくなる

SSO を導入する際は、これらのデメリットも考慮しておくことが重要になります。

ログインを管理するサービスのセキュリティ要件をできる限り高いものにする
（２要素認証の導入など）
ログインを管理するサービスが停止しても他のサービスが使用できるよう、システム管理者の何名かは他のサービスへのログイン手段も確保しておく

それでは「シングルサインオン（SSO）とは何か」、および Salesforce でのシングルサインオンの設定例について確認をしていきましょう。

＊ ID プロバイダ（IdP）とサービスプロバイダ（SP）

冒頭で、SSO は「一ヶ所のログイン認証によって他の組織のログインを管理する」と述べました。

「ログイン認証をする組織」「ログインを管理される組織」を、それぞれ以下のように呼称します。

ログイン認証を集約管理する組織 = 「ID プロバイダ（IdP）」
IdP の認証を経てサービスを提供する組織＝「サービスプロバイダ（SP）」

例えば、Salesforce のログインによって G Suite や Office 365 がアクセス可能な構成になっている場合、

Salesforce = ID プロバイダ
G Suite や Office 365 = サービスプロバイダ

となります。

ID プロバイダとサービスプロバイダ
https://help.salesforce.com/articleView?id=identity_provider_about.htm&type=0

========================================================
ID プロバイダは、ユーザがシングルサインオン (SSO) を使用して他の Web サイトにアクセスできるようにする信頼済みプロバイダです。

サービスプロバイダは、アプリケーションをホストする Web サイトです。Salesforce を ID プロバイダとして有効化し、1 つ以上のサービスプロバイダを定義できます。

これにより、ユーザは SSO を使用して、Salesforce から他のアプリケーションに直接アクセスできるようになります。

SSO を使用すると、いくつものパスワードを覚える必要がなく、1 つだけ覚えておけばよいため、ユーザは非常に助かります。
========================================================

どの組織を IdP とするかについては、それぞれのサービスが IdP と SP のどちらに対応しているかによって決まります。

Salesforce は IdP と SP の両方に対応 しています。

つまり、二つの Salesforce 組織を SSO で連携させることも可能、ということになります。

実際に運用する場合は「複数の独立した顧客組織を一社で管理し、かつログイン管理は自社で行う」といった特例的な場合に限られますが、SSO の仕組みを手っ取り早く理解するには非常に有益だと思います。実際に設定してみましょう。

【ハンズオン：二つの Salesforce 組織を SSO で接続する】

まず、開発者コミュニティ https://developer.salesforce.com/ja/ にて、Developer Edition 組織（以下「DE 組織」）を二つ取得してください。

右上の「サインアップ」でユーザ情報を入力することで、それがそのまま DE 組織のアカウントになります。

メールアドレスは同一で構いませんが、ユーザ名はわかりやすいように　 admin@ idp .***.dev と admin@ sp .***.dev のように区別して付けておきましょう。

DE組織の取得方法については、以下の開発者向け公式ブログに記載がありますので、こちらもご参考にしてください。

Developer Edition サインアップ手順
https://developer.salesforce.com/jpblogs/2016/04/developer-edition-signup/

DE 組織を取得したら、先ず最初に行うことは「私のドメインの設定」です。
SSO を設定する上で、組織固有のドメインは「リダイレクト先」として必須のものとなります。

数分もあれば完了しますので、忘れないようにすぐに設定しておきましょう。

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

========================================================
ログインと認証の管理を向上するために、Salesforce 組織の独自のサブドメインを作成します。サブドメインを使用することで、"https://yourcompanyname.my.salesforce.com" のように URL に会社名を含めることができます。ロゴの追加、配色の変更、およびログインページの右側で独自のコンテンツを追加するなど、ログインページをカスタマイズすることもできます。独自のサブドメインを作成するには、Salesforce Identity の [私のドメイン] 機能を使用します。
========================================================

＜IdP 組織の「私のドメイン」＞

＜SP 組織の「私のドメイン」＞

※ 設定に違いがありますが、今は特に考慮しないで差し支えありません。
リダイレクトポリシーなどは後程詳しく説明いたします。

私のドメインが未設定で、もし二つの DE 組織が同じインスタンス（AP16 とか NA13 とか）だと、同一ブラウザでセッションが両立できないので、私のドメインを設定して、同じブラウザでタブを切り替えて両方の組織に同時にログインが可能になることは、作業効率の向上にも貢献します。

私のドメインの設定が完了したら、早速 SSO の設定に着手しましょう。

SSO にはいくつかの種類があり、Salesforce では以下種別の SSO が使用できます。

代理認証（LDAP）
SAML を使用した統合認証
OpenID Connect を使用したソーシャルログイン

Salesforce を IdP とする場合は、一般的に SAML を使用します。

シングルサインオン実装のベストプラクティスとヒント
https://help.salesforce.com/articleView?id=sso_tips.htm&type=5

SAML SSO の設定の流れは、大まかにいうと以下の通りです。

IdP の情報を収集する
SP 組織にて SAML の設定を行う
IdP にて接続アプリケーションの設定を行う
SP と IdP でユーザを登録して接続テストを行う

まずは IdP 組織で「ID プロバイダ情報」を参照してみましょう。
私のドメインを設定することで、自動的に IdP としての設定が行われ、自己署名証明書が一つ作成されます。

SAML を試すためのレベルでしたら勿論自己署名証明書のままで構いませんが、本業務で使用する場合は、Verisign などの認証機関が発行した署名済みの証明書を入手して差し替える方が、より高い信頼性を享受することができます。

認証機関によって署名された証明書の生成
https://help.salesforce.com/articleView?id=security_keys_uploading_signed_cert.htm&type=5

IdP 設定画面を閉じる前に、「証明書のダウンロード」「メタデータのダウンロード」を行っておきましょう。SP 設定で必要になります。

次は SP 組織にログインして、「シングルサインオン設定」を開きます。
初期状態では SAML が有効化されていないので、有効化チェックを入れます。

SAML を有効化したら、先ほど IdP でダウンロードしておいた XML メタデータを使用して、「メタデータファイルから新規作成」を行います。

IdP 組織からダウンロード済みの XML メタデータを参照することで、SAML 設定の値が殆ど自動で指定されます。

以下は作業が必要になります。

「ID プロバイダの証明書」は先ほど IdP からダウンロードしたものを参照します。
「SAML ID 種別」は「アサーションには、ユーザオブジェクトの統合 ID が含まれます」に変更します。

この「アサーションには統合 ID が含まれます」を意識することが、SAML 接続にて非常に重要になってきます。

完了したら保存します。
「エンティティ ID」と「エンドポイントのログイン URL」の値は後で IdP 組織側の設定で必要になるのでテキストエディタにコピーペーストしておきます。

SP 組織で「私のドメイン」設定を開くと、認証設定の「認証サービス」に SAML 設定が追加されています。
こちらをチェックして保存します。
（「ログインフォーム」は、接続検証後にチェックを外しますので、まだ付けておいてください。）

次は IdP 組織に移動します。

ID プロバイダ設定を開き、「サービスプロバイダ」セクションの「接続アプリケーションでサービスプロバイダが作成されました。こちらをクリックしてください。」リンクをクリックします。

新規接続アプリケーション作成画面が開きます。

接続アプリケーション名、API 参照名は任意で入力します。
取引先責任者メールはご自身のものを入力いただいて構いません。

「エンティティ ID」には先ほどの SAML 設定でコピーしておいたものを、「ACS URL」には同じく SAML 設定の「エンドポイントのログイン URL」をペーストします。

「件名種別」が「統合 ID」になっていることを確認します。

設定を保存したら、接続アプリケーションに対してプロファイルを登録します。
「プロファイルを管理する」より、SAML 接続を行うユーザのプロファイルすべてを登録します。

いよいよ接続テストです。

IdP 環境と SP 環境にそれぞれ標準ユーザを登録します。

ユーザを登録する際、IｄP ユーザは「パスワードをリセットしてユーザに通知する」チェックをオンのままで、SP ユーザはチェックをオフにして保存してみてください。
「SP ユーザはログインパスワードなしでアクセスできる」ことを確認するためです。

IdP ユーザについては「ようこそメール」を受信して、忘れないようにパスワードの設定を行っておきましょう。

＜IdP 環境の標準ユーザ＞

＜SP 環境の標準ユーザ＞

先ほど SAML 設定で「統合 ID を使用することを意識する重要性」について述べました。

統合 ID が、異なる組織のユーザを結びつける非常に重要なものになります。
IdP 組織でユーザ認証が完了して、SP でログインを許可するには、統合 ID を一致項目として参照します。

複数の Salesforce 組織で統合 ID を管理する場合のベストプラクティスは次の通りです。

IdP 組織においては「統合 ID = ユーザ名」
SP 組織においては「統合 ID = IdP 組織上のユーザ名」

ユーザ登録が完了し、IdP ユーザのパスワード設定も済んだところで、管理者としてログインしているものとは別にブラウザを立ち上げ（例えば今まで作業を Chrome で行っていた場合は Firefox または Edge や Safari などの OS 標準ブラウザ）、IdP 組織と SP 組織の「私のドメイン」にアクセスします。

※ 以下、「左タブが IdP 組織、右タブが SP 組織」とします。

それぞれのログインフォームが開きますが、SP 組織の場合はフォームの下に「または次を使用してログイン： [認証サービスに追加した SAML 設定名]」が表示されるはずです。
（追加されていない場合は SP 組織の「私のドメイン」で「認証設定」を再度確認してください）

SP 組織ログインフォーム下の SAML 設定名をクリックすると、IdP 組織のログインフォームにリダイレクトされます。
URL を見ると、SP 組織からリダイレクトされた際のパラメータを引き継いでいることが確認できます。

先ほど IdP 組織の標準ユーザ登録時に「ようこそメール」を受信して設定したパスワードを使用して、ログインを試みます。

無事ログインできましたでしょうか。
ログインができてホーム画面が表示されたら URL を確認しましょう。きちんと SP 組織のドメインになっているはずです。

引き続いて、左タブに戻ります。
まだ IdP 組織のログイン画面が表示されたままのはずですが、何も操作をせずページの再読み込みボタンをクリックしてください。

きちんとホーム画面に切り替わりました。

SP 組織の管理者画面で、SP 標準ユーザのログイン履歴を見てみましょう。
種別が「SAML Sfdc Initiated SSO」と表示されているのが確認できるはずです。

（※ IdP 組織の標準ユーザでは、通常通り「アプリケーション」です。）

ここでエラーとなった場合、SP 組織の管理者アカウントで SAML 設定を開き、「SAML アサーション検証」を開きます。
直近の SAML エラーのレスポンスログが表示されます。（時間制限があるのですぐに参照しましょう）

一番多いパターンが「件名を Salesforce.com ユーザにマッピングすることはできません」です。
これは殆どの場合「統合 ID の不一致」によるものなので、先述の「統合 ID の設定」を再確認しましょう。

「件名を Salesforce.com ユーザにマッピングすることはできません」エラーが発生する
https://help.salesforce.com/articleView?id=000315253&type=1&mode=1

その他のエラーについては以下のヘルプをご参照ください。

シングルサインオンエラー発生時の対処方法
https://help.salesforce.com/articleView?id=000315249&language=ja&type=1&mode=1

ちなみに、今回は「SP 組織のログインからスタートする」方法を取りましたが、「予め IdP 組織にログインしておいて、同一ブラウザの別タブで SP 組織のドメインにアクセスして、ログイン不要でホーム画面を開く」ことも勿論可能です。

今回の「二つの Salesforce 組織を SAML で接続する」については、以下の開発者コミュニティのナレッジを参考に設定しました。

シングルサインオン実装ガイド - 複数の Salesforce 組織の SSO の設定
https://developer.salesforce.com/docs/atlas.ja-jp.sso.meta/sso/sso_examples_sf2sf.htm

＊ Salesforce Identity ライセンス

今回ご説明した実装例に対して、SP 側を G Suite や Office 365 に置き換えることで、「Salesforce のログイン認証によって、G Suite や Office 365 のアカウントも一括管理する」が可能になります。

少々高度になりますが、「ユーザプロビジョニング」の機能を使用すると、Salesforce （IdP 組織）のユーザ登録と連動して、G Suite や Office 365 のユーザ登録を自動で行うこともできます。

接続アプリケーションのユーザプロビジョニング
https://help.salesforce.com/articleView?id=connected_app_user_provisioning.htm

ここで疑問を持たれる方もいらっしゃるかと存じます。

「G Suite のアカウントは社員全員に付与しているけど、Salesforce のアカウントは一部付与していない社員がいる、その場合はどうすれば？」

実は、「Salesforce Identity」という安価なライセンス形態があり、Sales Cloud や Service Cloud の機能は使わない、Salesforce のログイン機能だけ使いたいという場合に使用することができます。

"すべてがつながる世界" の ID 管理サービス
https://www.salesforce.com/jp/products/platform/products/identity/

さしあたって Salesforce の標準機能は使用しないというユーザについては Identity ライセンスを割り当てておき、後々 Identity ライセンスのユーザが Sales Cloud も使用する必要が出てきたら、ユーザ登録はそのままにライセンスだけを Sales Cloud に変更するという方法が取れます。

＊「私のドメイン」設定でのセキュリティの管理

冒頭でも述べましたが、SSO で IdP 組織にユーザ管理を集約することで、設定箇所の減少によるセキュリティリスクの低減という効果がある一方で、リスクの分散化という意味では逆行することになります。

そのため、「リスクが集約する」IdP 組織のログインを適正に管理することと、SP 組織の「IdP を経由しないログイン方法」をきちんと塞ぐことが重要になってきます。

まずは「SP 組織にて IdP を経由しないログインを塞ぐ」方法です。

Salesforce を SP として使用する場合、「私のドメイン」の「認証設定」で、「認証サービス」から「ログインフォーム」を外すことで、SSO 以外のログインが行えないようにすることができます。
この場合、SP 組織のドメインにアクセスした際、自動で IdP 組織のログインフォームにリダイレクトされます。

（Salesforce 以外を SP とする場合、恐らく「シングルサインオン以外のログインをブロックする」設定が何かしらあるはずですので、各サービスのヘルプなどをご参照ください。）

これでログインの入り口が IdP 組織に限定されることになりました。

今度は「私のドメインの設定」にて、次のように設定します。

https://login.salesforce.com からのログインを抑止
以前のインスタンス固有のドメインからのユーザをリダイレクトしない（推奨）

これにより、「私のドメイン」を知らない外部からの不正なログインをブロックすることが可能になります。
併せて、２要素認証やプロファイルごとのログイン IP アドレスおよび時間帯の制限などを有効にして、万全の対策を施します。

Salesforce のログインセキュリティ機能は非常に強固なため、適切に設定さえすれば、「IdP 組織が突破されないという一点にリソースを集中する」ことは実に有効性が高いと言えます。

FAQ - 私のドメイン
https://help.salesforce.com/articleView?id=faq_domain_name.htm&type=5

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

「Salesforce のセキュリティ機能」の第二回、如何でしたでしょうか。

Salesforce 歴11年の私にとっても、シングルサインオン機能は未だに敷居が高いもので（＝シングルサインオンに限らず「複数の組織を接続する」全般について敷居が高いとも言えますが）、今回の記事を執筆するのに、デモ組織での設定で何度もエラーを出し、オフィス内で苦悩しているのを複数の同僚に目撃されています。

但し、きちんと苦悩したからこそ理解できた部分も多いので、お客様におきましても、お時間ございましたら是非今回のハンズオンをお試しいただき、エラーを乗り越えて、シングルサインオンの知見を獲得し、御社の業務運用にフィードバックいただければ幸いでございます。

エラーで行き詰ったら是非詳細をお知らせください、今後の記事で取り上げさせていただき、皆様とナレッジを共有できればと存じます。

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

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

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

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

コメント