サイバー脅威に対するSalesforceの監視、検出、対応

この記事で学べること不正アクセス、ランサムウェア、DoS/DDoS攻撃等、多様なサイバー脅威に対してSalesforceはどのような監視、検出、対応を行っているか理解できる。​1.  はじめに本記事では不正アクセス、ランサムウェア、DoS/DDoS攻撃等、多様なサイバー脅威からSalesforceがどのようにしてお客様にご利用いただいているSalesforceの本番システムのインフラストラクチャーを保護しているかを説明します。​2. インシデントレスポンス計画の整備Salesforceではインシデントレスポンス計画が整備されています。Salesforceでは、標準化されたインシデント管理プロセス、各インシデントに応じたインシデント対応マトリックスおよび手順書が存在し、これに従い24時間365日体制で、セキュリティインシデントの軽重を問わず、お客様にサービスを提供する本番システムの安定性を維持するために、速やかな対応がとれる体制が整備されています。 インシデントレスポンス計画は以下のリンクからご確認いただけます。​また、このインシデント対応計画は、SalesforceのCSIRTチームによって四半期ごとにテストおよび訓練されています。3. CSIRTの設置Salesforceでは、セキュリティ・インシデント対応チーム(Computer Security Incident Response Team。以下CSIRT)を設置しており、正式なインシデント管理プロセスに従って調査、管理、コミュニケーションおよび解決の活動を行っております。4. CSIRTによるログ監視とセキュリティインシデントの検知と対応Salesforceの本番システムのインフラストラクチャーは、ネットワーク機器、サーバ、ファイアウォール、侵入検知システム、マルウェア対策、ファイル改ざん検知、データベース等のログを記録しています。これらのログはログ管理サーバで集約・相関分析され、CSIRTチームが24時間365日ログを監視しており、セキュリティアラートの通知を受け取った後、不正侵入の試みを検出した場合は、該当通信の遮断、マルウェアの駆除などの対応が即座にできる体制としています。このシステムログは1年間保管しており、また、システムログは改ざんや不正アクセスから保護するための様々なコントロールを実施しています。​また、DoS/DDoS攻撃については、ネットワークセキュリティチームが24時間365日体制でネットワークトラフィックを監視しており、DoS/DDoS攻撃を検出した後、社内対応プロセスに従い、迅速にDDoS攻撃を緩和する対応が行われます。​5. 脅威インテリジェンスを活用したプロアクティブな脅威の検知と対応上記では、セキュリティアラートをCSIRTがリアクティブに対応するインシデント監視、対応プロセスを説明しましたが、Salesforceではリアクティブにインシデントの監視、対応を行うだけでなく、プロアクティブなサイバー脅威への検出、対応も実施しています。​SalesforceのCSIRTは広範なパブリックおよびプライベートの脅威インテリジェンスフィードとコミュニティを常時監視し、最新のサイバー脅威を分析しています。これらの脅威インテリジェンス(IoCとTTP)は、新しい検知シグネチャとしてセキュリティ監視システムに自動的に配布されます。脅威インテリジェンスは未知の脅威の検出と攻撃の検出と対応にかかる時間を短縮するためにも利用しています。​また、これらの脅威インテリジェンスを使用して、SalesforceのDetection & Response チームはSalesforceの本番システムのインフラストラクチャー内に疑わしいアクティビティがないかどうかの検出を行う機械学習を使用したアノマリーベースによるスレットハンティングも実施しています。​また、Salesforceの脅威インテリジェンスチームはSalesforceの本番システムのインフラストラクチャーをターゲットに攻撃している攻撃グループを常時監視し、その影響度、攻撃可能性の観点から攻撃グループの優先付けを行い、定期的に攻撃グループの評価を実施しています。そして、それぞれの攻撃グループが使用する攻撃手法に対して、当社の事業運営とお客様のビジネスに損害を与えないように、随時、Salesforceの本番システムのインフラストラクチャーの防止、検知、対応措置の見直しを実施しています。​6. セキュリティインシデントが発生した場合のお客様への通知セキュリティインシデントが発生した場合、すべてのお客様に影響がある事象はTrustサイトに掲載されます。個別のお客様のセキュリティインシデントについては管理者とセキュリティコンタクトとして登録されたユーザーにメールが送信されます。セキュリティコンタクトの登録方法は以下のリンクをご参照下さい。​​

SalesforceによるセキュアなWebアプリケーション開発と開発における責任共有モデル

この記事で学べること・SalesforceがどのようにセキュアなWebアプリケーション開発をしているか、脆弱性対策を実施しているかが理解できる・Webアプリケーション開発におけるSalesforceとお客様の責任分界点が理解できる1. はじめにSalesforceが提供するSaaS とPaaSにおいてプラットフォーム部分はSalesforceの責任範囲であり、一方、利用者のアカウント管理、認証、、パスワードポリシーの設定、お客様のデータへのアクセス管理と監視等はお客様の責任範囲になりますが、このブログではWebアプリケーションの開発、特に脆弱性におけるお客様とSalesforceの責任分界点について説明します。​Salesforceが提供するSaaS とPaaSでは以下の2つの部分に分割されます。・プラットフォームの標準部分・プラットフォームの標準部分上にお客様が追加した部分「プラットフォームの標準部分」におけるセキュアなWebアプリケーション開発と脆弱性診断と対応はSalesforceが責任を負います。一方、「プラットフォームの標準部分上にお客様が追加した部分」におけるセキュアなWebアプリケーション開発と脆弱性診断と対応はお客様が責任を負います。2. Salesforceが責任を負う範囲「プラットフォームの標準部分」におけるセキュアなWebアプリケーション開発と脆弱性診断と対応はSalesforceが責任を負います。​「プラットフォームの標準部分」におけるセキュアなWebアプリケーション開発については、Salesforceは昨今のセキュリティ・バイ・デザイン、シフトレフトの考え方を採用し、セキュア開発ライフサイクル(SSDL)に従い、脅威モデリング、セキュアコーディング、静的コードスキャン(SAST)、DAST、ファジングテストを実施し、計画・設計、開発、テストのすべてのフェーズにおいて脆弱性等のセキュリティを考慮したWebアプリケーションの開発をしています。​そのため、SalesforceはWebアプリケーションの開発段階で、以下のようなOWASP Top 10脆弱性をはじめとする様々な脆弱性の対策を実施しています。・SOQLインジェクション・クロスサイトスクリプティング(XSS)・クロスサイトリクエストフォージェリ(CSRF)・コマンドインジェクション・HTTP/メールヘッダーインジェクション・ディレクトリトラバーサル・セッションハイジャック・クリックジャッキング等​​Salesforceのセキュア開発ライフサイクル(SSDL)の概要につきましては下記ホワイトペーパーをご確認ください。https://compliance.salesforce.com/en/faqs-and-white-papers「Salesforce Secure Development Lifecycle Overview」​しかし、日々あらたな脅威、脆弱性が発見されているため、Webアプリケーションの開発段階での脆弱性対策だけでは十分ではありません。​そのため、製品のリリース後、SalesforceはWebアプリケーションの「プラットフォームの標準部分」における第三者機関による脆弱性診断／ペネトレーションテストを定期的に実施しております(実施頻度は製品によって異なりますが、Salesforce Servicesの場合、年3回です)。​お客様はこの第三者機関による脆弱性診断/ペネトレーションテストの直近のサマリーレポートをSalesforceのコンプライアンスサイトからダウンロードいただき、診断結果をご確認頂くことが可能です。また、発見された脆弱性につきましてはSalesforceの基準に従って、迅速に対応しています。​また、Webアプリケーション自体の脆弱性対策だけではなく、システムが利用しているコンポーネントについても、SalesforceのTrustチームがベンダーやその他のソースからの脆弱性に関する警告とパッチリリースに関する通知を常にモニターし、脆弱性情報を一元管理し、対応の要否を検討しています。具体的には、システムに対する脆弱性の重大度とリスクに依存しますが、セキュリティパッチは直ちに展開するようにスケジュールされる場合や、適切な計画メンテナンス間隔まで実施延期される場合があります。また、適用せずに代替の方法でセキュリティコントロールを行う場合もあります。​​以上がSalesforceが責任を負う「プラットフォームの標準部分」におけるセキュアなWebアプリケーション開発と脆弱性対策になります。続いて、お客様が責任を負う範囲についてご説明します。​3. お客様が責任を負う範囲「プラットフォームの標準部分上にお客様が追加した部分」におけるセキュアなWebアプリケーション開発と脆弱性診断と対応はお客様が責任を負います。 ​お客様がノーコードまたはローコードを含むカスタム開発部分においてセキュアなWebアプリケーション開発を行っていただくために、Salesforceは以下の様々なガイドライン、ツールをご提供しております。お客様は、これらのガイドライン、ツールを使用し、お客様自身でセキュアな開発、定期的なセキュリティチェックを実施していただく責任があります。​Apex および Visualforce 開発のセキュリティガイドラインSecure Coding Guidelines (英語)Security Tips for Apex and Visualforce Development (英語)ソースコードスキャナ(Checkmarx)※Apex、Visualforceのソースコードスキャン。 SOQLインジェクション、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ等を検出可能。12ヶ月ごとに360000行は無償でご利用可能セキュリテ状態チェック※クロスサイトスクリプティング等の脆弱性の簡易チェック機能があります。Salesforce Optimizer※過剰なアクセス権限を付与していないか等を検出する機能があります。​しかし、日々あらたな脅威、脆弱性が発見されているため、Webアプリケーションの開発段階での脆弱性対策だけでは十分ではありません。​そのため、お客様によるカスタム開発部分につきましては、お客様自身で脆弱性診断を実施していただくことを推奨しております。お客様が脆弱性診断を実施していただく手順はこちらのリンクに記載しておりますが、その中のSecurity Assessment Agreement(SAA)に診断の際の禁止事項、診断実施可能タイミング等の注意事項を記載しておりますので、こちらの内容を十分ご理解いただいた上で、診断の実施をお願い致します(診断の事前申請は不要です)。​また、お客様によるカスタム開発の責任はお客様に帰属するため、お客様の脆弱性診断で発見されたお客様によるカスタム開発部分の脆弱性につきましては、お客様にて修正等の対応を実施していただく必要があります。一方、お客様の脆弱性診断で「Saelsforce提供のプラットフォームの標準部分」の脆弱性を発見された場合は、Salesforce(security@salesforce.com)にご報告をお願い致します。その際にSalesforceへ連携していただく情報につきましてはこちらのリンクをご参照下さい。​また、CookieへのHttpOnly属性の付加、セッションハイジャック対策のためのセッションタイムアウトの設定等、お客様が設定可能な項目もございますので、こちらにつきましては以下のリンクをご参照下さい。https://help.salesforce.com/s/articleView?id=000318378&type=1https://help.salesforce.com/s/articleView?id=sf.admin_sessions.htm&type=5

拡張ドメインの有効化とその準備

この記事で学べること拡張ドメインの機能概要拡張ドメインが有効化される背景拡張ドメインによる変更点想定される影響お客様による事前準備の内容拡張ドメインに関する参考情報拡張ドメインの概要拡張ドメインは 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が使われるようになることも重要な変更点の１つです。拡張ドメイン有効化において想定される影響範囲として以下のようなものがあります。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はリダイレクトされません（１世代前までの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時間以内に同一ホスト名に関するリダイレクトがあった場合はログに記録されないため、リダイレクト件数を正確に取得するものではない。​▼参考情報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 ’23​FAQQ1 : 「[私のドメイン] の名前」が外部の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からログアウトすることを徹底するなど、ユーザ自身による日常的な対策もセキュリティの観点で重要です。セッション情報のセキュリティ認証情報に起因するセキュリティリスクを軽減するために、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アドレスの制御に加えて、アクセスを試みたユーザが本人なのか、接続するたびにチェックをかけることによって、情報漏洩のリスクを軽減することが可能となります。​​