自己署名証明書の有効期限について

https://play.vidyard.com/UpkRJSXwCCdpV8PqMHYVxc​動画内容00:00～　各章の概要​00:42～　１．自己署名証明書、通知メールの意味とは？​01:20～　２．自己署名証明書の自動作成について​01:41～　３．自己署名証明書を使用する機能​01:57～　４．本動画のScopeについて​02:34～　５．シングルサインオン設定の有無を確認​03:47～　６．設定内の [証明書の署名要求] を確認​04:15～　７．証明書の署名要求の役割​04:50～　８．自己署名証明書の有効期限が切れた場合の影響​05:54～　９．本動画の Scope の他に影響のある機能について学習ツールシングルサインオン設定で期限切れの証明書を置き換えるエラー「Salesforce 組織の 1 つ以上の証明書の有効期限が近づいています」自己署名証明書の生成​​

拡張ドメイン適用前のURLにアクセスしたときのリダイレクト停止

この記事で学べること拡張ドメインの概要拡張ドメイン適用前の古いURLへアクセスした際のリダイレクトが停止されることリダイレクト停止に向けた準備の方法拡張ドメインの概要各種ブラウザの最新要件に対応するため、Salesforce は 2023 年 10 月に Winter ’24 のリリースで「拡張ドメイン」をすべてのSalesforce 組織に適用しました。Salesforce 組織への拡張ドメイン適用により、内部ユーザーが利用するURLだけではなく、Salesforce サイトや Experience Cloud サイトなど、外部ユーザーが使用する URL も更新されています。​これまでは拡張ドメイン適用前の URL にユーザーがアクセスした場合は拡張ドメイン適用後の URL にリダイレクトされていましたが、Salesforceでは以下のスケジュールでリダイレクトの停止を予定しています。​▼Winter ’25Sandbox, Developer Edition 組織, デモ組織, パッチ組織, スクラッチ組織, Trailhead Playground などの非本番組織​▼Spring’ 25本番組織​本記事ではリダイレクト停止の準備として活用できる機能や推奨アクションについて纏めております。拡張ドメイン適用により更新された URL拡張ドメインの適用により、Salesforce 組織で使用されていた 多くの URL が更新されました。詳細はヘルプドキュメント「拡張ドメインを有効にする場合の [私のドメイン] の URL 形式の変更」に記載がありますが、本番組織における拡張ドメイン適用前後のURLを以下にご紹介します（一部抜粋）。上記の表にある通り、内部ユーザーが使用する URL だけではなく、Salesforce サイトや Experience Cloud サイトのように外部に公開している URL も更新されました。なお、拡張ドメイン適用前の旧 URL にアクセスすると、拡張ドメイン適用後の新 URL に自動でリダイレクトされる動作となります。しかしながら、旧 URL にアクセスした場合に新 URL にリダイレクトされる動作は、Winter ’25 と Spring’25 で終了します。​​拡張ドメイン適用前の URL にアクセスした際のリダイレクトの停止Winter' 25 と Spring’25 では、拡張ドメイン適用前の URL にアクセスした際のリダイレクトが停止します。＊参考情報 : Update References to Your Previous Salesforce DomainsWinter'25でリダイレクトが停止する組織は以下のとおりです。・Sandbox、Developer Edition 組織、デモ組織、パッチ組織、スクラッチ組織、Trailhead Playground などの非本番組織​Spring’25でリダイレクトが停止する組織は以下のとおりです。・本番組織​そのため、リダイレクトが停止した際の動作確認や、リダイレクトの発生有無の確認を 各リリースまでに実施いただくことを推奨しています。​なお、新 URL へのリダイレクトが停止した際の影響を確認する手段として、システム管理者様にて手動でリダイレクトを停止させることができます。設定メニューの「私のドメイン」ページにある以下の２つの設定を OFF にすることで、その組織上におけるリダイレクトの動作を停止させることができます。（OFF にしたあと、再度設定を ON にしてリダイレクトを動作させることも可能です）以前の [私のドメイン] の URL を現在の [私のドメイン] にリダイレクト<旧 Domain>.secure.force.com および <旧 Domain>.force.com URL を現在の [私のドメイン]のサイト URL にリダイレクト＊参考情報 : [私のドメイン] のリダイレクトの管理​​リダイレクトが発生したユーザーへ新しい URL の通知「私のドメイン」ページで新しい URL へのリダイレクトを ON にしている場合、以下の設定を ON にすることができます。現在の [私のドメイン] の URL にリダイレクトする前にユーザーに通知現在のサイト URL にリダイレクトする前にユーザーに通知この設定が ON になっている場合、ユーザーが古い URL にアクセスしリダイレクトが発生するときに、以下の画面を表示することができ、新しい URL が画面上に表示され、ブックマークの更新を促すメッセージをユーザー側に表示させることができます。＊参考情報 : [私のドメイン] のリダイレクトの管理​​リダイレクト発生状況の確認管理者様はリダイレクトが発生しているかどうかを確認するために、ログを有効化することができます。リダイレクトに関するログを有効化する場合は、「私のドメイン」ページで以下の設定を ON にします。リダイレクトを記録＊参考情報 : [私のドメイン] のホスト名リダイレクトのログ記録​上記設定を ON にすると、「私のドメイン」ページに「リダイレクト ログをダウンロード」というボタンが表示され、システム管理者様はリダイレクトに関するログを取得することができるようになります。取得できるログのイメージを以下にご紹介します。＊ログの詳細については開発者ガイド「ホスト名リダイレクトのイベント種別」をご参照ください。​このログを活用することで、リダイレクトの発生状況を確認することができるようになり、顧客やユーザーへのコミュニケーションプランを検討することができます。ただし、リダイレクトのログには以下の留意点があるため、事前にご確認の上でご利用ください。ログは EventLogFile（イベントモニタリング）の領域に格納されますが、すべてのお客様が無料でダウンロード可能。Event Monitoring Analytics アプリケーションでのログ利用は不可。API でもログを取得することは可能だが、API バージョン 56 以降を利用する必要あり。ログは 1 つのファイルで作成され日次で更新されるため、最新の日次ログのみを取得可能。1 時間以内に同一ホスト名に関するリダイレクトがあった場合は1行しかログが出力されないため、リダイレクト件数を正確に取得するものではない。​​リダイレクト停止までの推奨アクションSpring’25 では本番組織で拡張ドメイン適用前の URL にアクセスした際のリダイレクトが停止します。リダイレクトが停止した際における業務影響の範囲を極力抑えるためにも、Salesforce組織のシステム管理者には以下のアクションを実施いただくことを推奨します。リダイレクト時に新しいURLをユーザに表示する機能を有効化して、ブックマークの更新を促します。定期的にリダイレクトログを確認し、お客様組織にて発生しているリダイレクトの発生状況を確認します。リダイレクトが発生していた場合は、ログから判断できる情報を以って、顧客やユーザーへのコミュニケーションプランを検討します。システム管理者様にてリダイレクトのON/OFFを切り替えることができますので、Spring'25のリリースまでにリダイレクトが無効化された際の影響確認を実施します。​これらの推奨アクションの実施には期間を要する可能性があるため、可能な限り早めの計画策定を推奨します。​​関連リソースWinter’25 リリースノートUpdate References to Your Previous Salesforce DomainsIdentify Blocked Redirections for Legacy Hostnamesヘルプドキュメント拡張ドメイン非拡張ドメインのリダイレクトの終了への準備[私のドメイン] のリダイレクト[私のドメイン] のホスト名リダイレクトのログ記録Developers Guideホスト名リダイレクトのイベント種別​​​​

サイバー脅威に対する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

認証情報の管理におけるベストプラクティス(セッション情報の管理)

この記事で学べること認証情報の管理の重要性セッションを管理するための設定認証情報の管理の重要性最も基本的な対策はユーザ自身による管理の徹底です。ユーザが認証情報（パスワードやセッション情報など）を適切に管理していない場合、第三者による意図しないアクセスを招く可能性があります。業務を終える際には必ず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アドレスの制御に加えて、アクセスを試みたユーザが本人なのか、接続するたびにチェックをかけることによって、情報漏洩のリスクを軽減することが可能となります。​​