Trusted Services｜Salesforce サクセスナビ

記事一覧

Trusted Services

Shield

アクセスログの参照ガイド

この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、確認したいケースごとにどのログを参照することにより、どういった情報を確認することができるか理解できます。イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとはここでは、確認をしたいケースごとにどのログを参照すべきか、リアルタイムイベントモニタリングのログを中心にまとめています。ケース1：ユーザがどこからログインしているのか確認したいLoginEventを調べることによって、ユーザがいつ、どのIPアドレス(国/都市)、ブラウザ、アプリケーション、OS(及びバージョン)からログインしたを確認することができます。各ログには、ユニークなLoginKeyが記録されますが、LoginKeyはその後のイベントログに記録されるため、LoginEventの該当ログレコード確認することにより、レコードがどのような環境からアクセスされたのか詳しく確認することができます。ケース2：ユーザがどのレコードを参照したのか確認したいLightningUriEvent(Salesforce Classic環境の場合は、UriEvent)を調べることによって、ユーザがいつどのレコードにどのような操作(参照/作成/更新/削除)にてアクセスしたか確認することができます。なお、作成または編集操作については、開始と終了の2つのログが記録されるため、その差から作業に要した時間も把握可能です。ただし、編集についてはデータの更新履歴は記録されません。こちらは項目履歴管理もしくは、項目監査履歴を使用を検討してください。ケース3：ユーザがどのレコードをレポート出力したのか確認したいReportEventを調べることによって、ユーザがいつレポート機能によって、どのエンティティ(取引先等)のどのレコードのどの項目を出力したか、またエクスポートしたか出力件数を含めて確認することができます。なおこちらは、保存されなかったレポートの実行結果および、編集中にプレビューで表示されたレコードも含みます。ケース4：ユーザがどのレコードをリストビューで一覧したのか確認したいListViewEventを調べることによって、ユーザがいつリストビュー機能によって、どのエンティティ(取引先等)のどのレコードのどの項目を出力したか確認することができます。ケース5：ユーザがAPIでどのレコードにアクセスしたのか確認したいApiEventを調べることによって、API経由でユーザがどのサービスからどのクエリ(Query/QueryAll/QueryMore)によって、どのエンティティ(取引先等)のどのレコードのどの項目が出力されたのか確認することができます。なお、クエリ以外(UpdateやDeleteなど)のAPIイベントは記録されません。ケース6：ユーザがどのファイルをダウンロードしたのか確認したいこちらは、現状リアルタイムイベントモニタリングでは記録されません。Lightning Experienceの画面でレコードに添付したファイル、Chatterに添付したファイル、ライブラリにアップロードしたファイルは、イベントモニタリングのコンテンツ転送イベント種別(ContentTransfer) を調べることによって、ユーザがどのファイルをアップロード、ダウンロード、プレビューしたか確認することができます。Classic の画面からレコードに添付したファイルおよびドキュメントに格納されているファイルは、イベントモニタリングのドキュメント添付ファイルのダウンロードイベント種別を調べることによって、ユーザがどのファイルをダウンロードしたのか確認することができます。学習ツールTrailhead - リアルタイムイベントモニタリングプラットフォーム開発者ガイド - リアルタイムイベント監視オブジェクトまとめ保存されているデータに対するユーザのアクセスログは、ファイルを除きリアルタイムイベントモニタリングのログに記録され、対象のログを確認することにより、ユーザがいつデータにアクセスしたか確認することができます。
Trusted Services

Shield

トランザクションセキュリティポリシーの活用例

この記事で学べることイベントモニタリングに含まれるトランザクションセキュリティ機能により、お客様はご自身で定義されたルールに沿って、組織内の特定のアクセスを検知・遮断することができるようになります。本記事では、このトランザクションセキュリティ機能を使い始めるにあたってどのような用途で活用できるのか、実際の条件例を交えながら具体的なポリシー例をご紹介します。(おさらい) イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとはこのうち、今回ご説明するトランザクションセキュリティポリシーはリアルタイムイベントモニタリングログを利用します。トランザクションセキュリティ機能の概要については、以下の記事をご参照ください。トランザクションセキュリティとは条件ビルダーによるポリシー作成例ApiEvent ポリシー例[特定のオブジェクトにて照会に○○ミリ秒以上かかったAPIクエリを検出]ポリシー設定 (“リード”オブジェクトの例)イベント: ApiEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)Elapsed Time / [＞＝] / “1,000” (任意の経過ミリ秒)[2つ以上の特定のオブジェクトのデータローダによるエクスポートの検出]ポリシー設定 (“取引先責任者”もしくは“リード”オブジェクトの例)イベント: ApiEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3 AND 4条件: 条件 / 演算子 / 値1. 照会されるエンティティ / [次の文字列と一致する] / “Contact” (任意のオブジェクト名)2. 照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)3. クエリ / [次の文字列と一致する] / “Select”4. Client / [次の文字列で始まる] / “DataLoader”ListViewEvent ポリシー例[APIを使用して照会されたリストビューの検出]ポリシー設定イベント: ListViewEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値イベントソース / [次の文字列と一致する] / “API”メモ: API の代わりに Classic または Lightning を指定することで、UIを利用したリストビューの照会についても追跡することができます。[2つ以上の特定のオブジェクトのリストビュー実行の検出]ポリシー設定 (“取引先責任者”もしくは“リード”オブジェクトの例)イベント: ListViewEvent条件ロジック: いずれかの条件に一致 (OR)条件: 条件 / 演算子 / 値照会されるエンティティ / [次の文字列と一致する] / “Contact” (任意のオブジェクト名)照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)[特定ドメインのユーザによるすべてのレコードもしくは特定のリストビュー実行の検出]ポリシー設定イベント: ListViewEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3条件: 条件 / 演算子 / 値1. 範囲 / [次の文字列と一致する] / “Everything”2. 名前 / [次の文字列と一致する] / “SuperSecureListView” (任意のリストビュー名)3. ユーザ名 / [次の文字列で終わる] / “@spy.mycompany.com” (任意のドメイン名)LoginEvent ポリシー例[特定のIPアドレスからのログインを検出]ポリシー設定イベント: LoginEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値アクセス元 IP / [次の文字列と一致する] / “12.34.56.78” (任意のIPアドレス)メモ: [次の文字列で始まる] や [次の文字列を含む] 演算子を使用することで、特定のIPアドレス以外にも、社内ネットワークなど特定のサブネットに所属するIPアドレスからのログインを追跡することができます。[特定のブラウザからのログインを検出]ポリシー設定イベント: LoginEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値ブラウザ / [次の文字列を含む] / “Chrome” (任意のブラウザ名)メモ: 文字列を変えることで、Safari や Firefox ブラウザからのログインについても追跡することもできます。ReportEvent ポリシー例[特定のオブジェクトで○○件以上のレコードを表示したレポート実行の検出]ポリシー設定 (“リード”オブジェクトの例)イベント: ReportEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値処理行 / [＞＝] / “2,000”照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)[出力にメールアドレスが含まれる列を持つレポート実行の検出]ポリシー設定イベント: ReportEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値列名 / [次の文字列を含む] / “Email” (任意の列名)メモ: [次の文字列を含む] 演算子を使用することで、Email、Customer Email、 Email of Customer など、列名に“Email”を含む項目を全て当てはめることができます。[2つ以上の特定のオブジェクトを元にしたレポートのエクスポートの検出]ポリシー設定 (“取引先責任者”もしくは“リード”オブジェクトの例)イベント: ReportEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3条件: 条件 / 演算子 / 値1. 照会されるエンティティ / [次の文字列と一致する] / “Contact” (任意のオブジェクト名)2. 照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)3. 演算子 / [次の文字列と一致する] / “ReportExported”[高保証セッションレベルセキュリティがないセッションからの機密レポート参照を検出]ポリシー設定イベント: ReportEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3条件: 条件 / 演算子 / 値セッションレベル / [次の文字列と一致する] / “LOW”セッションレベル / [次の文字列と一致する] / “STANDARD”名前 / [次の文字列を含む] / “AccountList” (任意のレポート名)PermissionSetEvent ポリシー例[“パスワード無期限”権限のユーザへの割り当てを検出]ポリシー設定イベント: PermissionSetEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値権限リスト / [次の文字列を含む] / “PasswordNeverExpires”演算子 / [次の文字列と一致する] / “AssignedToUsers”Apexによるポリシー作成例ReportEvent ポリシー例[特定のプロファイルに属するユーザによるレポートのエクスポートを検出]ポリシー設定イベント: ReportExportApexコード例global class BlockSpecificProfileReportExport implements TxnSecurity.EventCondition { public boolean evaluate(SObject event) { switch on event{ when ReportEvent reportEvent { return evaluate(reportEvent); } when null { return false; } when else{ return false; } } } private boolean evaluate(ReportEvent reportEvent) { // Retrieve User's profile id. User results = [SELECT Id, ProfileId FROM User WHERE Id = :reportEvent.UserId]; // Check ProfileId and report export operation. if (results.ProfileId.equals('00eXXXXXXXXXXXXXX') && reportEvent.Operation.contains('ReportExport')) { return true; } return false; }}学習ツール拡張トランザクションセキュリティポリシーの種別条件ビルダーの例Apex トランザクションセキュリティの高度な実装例まとめトランザクションセキュリティを活用することにより、プロファイルや権限セットでは表現できないような細かなユーザアクセスの検出や制御を実現し、リアルタイムで検知・遮断することが可能となります。条件ビルダーでは画面操作により誰でも簡単にポリシーを作成することができる一方で、より複雑な要件に対してはApexコードによるコーディングを用いたポリシーの作成にも対応しており、用途やシステム管理者の習熟度に応じて使い分けることが出来るようになっています。
Trusted Services

Shield

効率的なインシデントレスポンスに有効な項目監査履歴

この記事で学べること項目監査履歴は、データの正確性を維持し、第三者に改ざん等がされていないことを証明するための更新ログの記録という本来の目的とは別に万一のデータ漏えい事故において、漏えい時期の絞り込みに寄与し、インシデントレスポンスにおける効率的なログ調査を実現できることが新たに注目されています。本記事ではとあるオフィスにおける架空の情報漏えい事故の対応を見て行くことで、効率的な対応が可能である理由を学べます。とあるオフィスでの一幕とある架空企業A社はDXに関する提案・開発支援・運用支援のサービスを手掛ける企業で、多くの見込み客、顧客、商談、プロジェクト情報、サポート状況など、様々な情報をSalesforceで管理している。A社はとある官庁との取引があり、当該官庁向けのプロジェクト情報もステークホルダー管理（個人情報）をした上でSalesforceに保管していた。ある日、A社の営業が顧客でとある官庁から一通のメールを受信した。メールには、当該官庁のセキュリティ運用を担っているベンダーの調査で、ダークWebで取引される情報のサンプルデータ（犯罪者が取引する情報の信ぴょう性を喧伝するために窃取したデータの一部を公開したもの）に当該官庁向けプロジェクトの情報が確認されたこと、プロジェクト情報には個人情報であるステークホルダー情報を含んでいたこと、データの内容からA社より情報が漏えいしたと思われること、また緊急で調査をしてほしい旨が書かれていた。サンプルデータを確認するとA社とお客様でしか知り得ないプロジェクト情報がA社のSalesforce環境のデータと一言一句違わずに書かれており、また個人情報もA社が管理している内容とほぼ同等な内容であることが確認された。A社はCSIRTを中心としたインシデントレスポンスを即時開始。CSIRTは過去に遡ってSalesforce環境におけるアクセスログの調査を開始した。アクセスログの記録についてアクセスログはイベントモニタリングで提供される機能の一つであるリアルタイムイベントモニタリングで確認することができます。詳細はアクセスログの参照ガイドをご参照ください。再びオフィス（本記事のメイントピック）A社はイベントモニタリングを契約の上、リアルタイムイベントモニタリングを有効化し、また定期的にアクセスログの保管をしていたことから、アクセスログを調査できる目途は立った。しかしアクセスログの量は膨大で、またサンプルデータからは漏えい時期を隠匿するためか、レコードの作成日や更新日等の監査項目は記載されていなかった。そのためデータの漏えいした時期や漏えいに関与したユーザアカウントの絞りこみといった調査には相当な時間を要すると思われた。CSIRTに招集された官庁向けプロジェクトのプロジェクトマネージャが漏えいしたサンプルデータを見ると、いくつか古い状態のデータがあるのに気付いた。このデータが古い状態であった期間が特定できればログの絞り込みは容易になるのではないかと考え履歴の調査を開始した。項目監査履歴の特徴項目監査履歴は項目履歴管理の機能を拡張する製品となります。詳細は項目監査履歴とはをご参照ください。ここでは漏えいが発覚しCSIRTによる調査を開始した日を2020/12/31 として、サンプルデータや本番環境のデータの状態例を見ながら項目履歴管理を設定していない場合、項目監査履歴が無い場合、項目監査履歴がある場合の調査対象ログの絞り込み方を確認していきます。【漏えいしたサンプルデータから確認できた古い情報】【本番環境にある情報】※黄色はサンプルデータからの変更点、また日時データは簡略化のため年月以外は1日午前0時に統一、またデータの変更は、値から変更前後がわかりやすいように常に1が加算されるものとしています。例：99(変更前)→100(漏えい値)→101(変更後)項目履歴管理の設定をしていない場合それぞれのレコードでは作成日、最終更新日の監査情報しかありませんので、ログの調査対象期間は、漏えいしていた4つのレコードの中で一番最近に登録されたレコードの作成日(レコード4の2018/04/01)から、漏えい値から変更のあったレコード(レコード1,2,3)のうち、最も古い最終更新日(レコード2の2019/10/01)までの18ヶ月に絞り込まれます。この期間より古いと、レコード4が存在していませんし、また新しいとレコード2の項目Aの値が漏えいした値と異なることになるため調査対象期間から除外されるからです。青：レコードの値が確定できない時期　薄い緑：レコードの値が確定できる時期項目履歴管理の設定を実施していた場合項目履歴管理の設定をしている場合、項目レベルで変更履歴を確認することができます。A社の場合、項目Aに項目履歴管理の設定をしていた為、以下の履歴を確認することができました。【本番環境から確認できるレコード1の履歴】【本番環境から確認できるレコード2の履歴】このログによるとレコード1及びレコード2の項目Aの値が漏えい値から現在の値に変更された日時の特定ができましたが、24カ月より前の変更履歴が既に確認できないため、前の値から漏えい値に変更された日時の特定はできませんでした。また、A社においては履歴を管理できる項目の数が1オブジェクトあたり20項目という上限に抵触したために優先度の低い項目Bには履歴管理の設定ができていませんでした。青：レコードの値が確定できない時期　薄い緑：レコードの値が確定できる時期　濃い緑：漏えい値であったと確定した期間このログにより、レコード1とレコード2の項目Aが同時に漏えい値であった時期は2019年2月1日より前であることになり、調査期間も10ヶ月分に絞り込むことができました。2019年2月1日以降は、レコード1の項目Aが漏えい値と異なるため除外されるからです。項目監査履歴がある場合項目監査履歴があれば、1オブジェクトあたり項目履歴管理の3倍の60項目まで履歴管理を設定できるため、優先度の低かった項目Bの履歴管理も設定でき、またログの保存期間も無期限であるため、以下の情報が追加で確認することができます。【本番環境から確認できるレコード1の履歴】【本番環境から確認できるレコード2の履歴】【本番環境から確認できるレコード3の履歴】薄い緑：レコードの値が確定できる時期　濃い緑：漏えい値であったと確定した期間このログにより、すべてのレコードが存在し、各レコードの項目の値が漏えい当時の値であったのがいつであったのか、すなわちその期間にデータが抜き出されたことを特定できます。今回のお話では、各レコードの漏えい値がSalesforce内に存在していた期間は、2018年1月の僅か1ヶ月間であったことが判明、その調査対象期間のイベントモニタリングのログを解析することにより、漏えいに関与したユーザアカウントの特定と同時に漏えいしたデータの全貌が短期間で特定することが可能となりました。今回のお話では、外部から入手できたレコードが4件と項目も2つのみというシンプルなストーリーでしたが、実際には、外部から入手されたデータが多いほど、漏えい値の存在期間の被っている時期、つまり漏えいした時期がピンポイントで絞り込み可能となりますので、イベントモニタリングの導入には、ぜひセットで項目監査履歴の導入を検討いただければと思います。学習ツールヘルプ：項目履歴管理ヘルプ：項目監査履歴まとめ項目監査履歴は、更新頻度の多い項目に数多く設定しておくことにより、万一の情報漏えいに対してイベントモニタリングと合わせて効率的にインシデントレスポンスを行うことができます。
Trusted Services

Shield

トランザクションセキュリティとは

この記事で学べること標準機能と比較して、拡張トランザクションセキュリティで何ができるのか学べます。拡張トランザクションセキュリティとはリアルタイムイベントを活用して特定条件にマッチする操作をブロックする、管理者へ通知をする、あるいは高保証セッションではないユーザに多要素認証を要求することを可能にする機能です。条件が記載される設定をトランザクションセキュリティポリシー（以下、ポリシー）と呼びます。誰に何をさせて良いかといった権限周りの設定は標準機能のプロファイルや権限セットで実施することが基本ですが、拡張トランザクションセキュリティを利用することでより細やかにユーザに禁止させたい操作、管理者へ通知をさせたい操作等について条件設定ができる様になります。トランザクションセキュリティポリシーの実装に当たっては、ローコードで実装できる条件ビルダーとプロコードでのApex実装と2種類の方法が用意されています。どちらをご利用いただく場合でもトレイルヘッドの拡張トランザクションセキュリティを確認いただくことで作成方法を学ぶことができます。ここからは拡張トランザクションセキュリティで設定できる各ポリシーについて、そもそもプロファイルでどの様な制御ができるのか、そしてどの様な場合に本機能の実装を検討するべきなのかを記載していきます。条件ビルダーで設定できる条件については各ポリシーのリンク先をご確認ください。Apexを利用する際にはApex を使用する拡張トランザクションセキュリティポリシーの作成をご参照ください。ApiEventポリシーユーザは外部のアプリケーションと連携する等の目的でAPIを利用することができます。標準機能ではプロファイルで［システム管理者権限］配下の［APIの有効化］をオフにすることですべてのAPIの使用をブロックすることができます。本ポリシーは［APIの有効化］権限を持つユーザに対して更に細やかに参照系APIの使用条件を定めて利用させたい場合、あるいは条件にマッチする利用があった時に通知を受けたい場合に実装を検討します。BulkApiResultEventStoreポリシーBulk APIの実行結果は［設定］画面で［一括データ読み込みジョブ］を開く事で確認することができます。標準機能ではプロファイルで［システム管理者権限］配下の［データインテグレーションの管理］、［APIの有効化］、［設定・定義を参照する］のいずれかをオフにすることで［一括データ読み込みジョブ］へのアクセスをブロックすることができます。本ポリシーは上記3つの権限を持つユーザに対してさらに細やかにBulk APIのダウンロード実行結果へのアクセス条件を定めたい場合、あるいは条件にマッチする利用があった時に通知を受けたい場合に実装を検討します。Bulk APIの実行を制御をするポリシーではない点にご注意ください。ListViewEventポリシーユーザはリストビューからデータを一覧で表示することができます。標準機能では参照権限を持つオブジェクトに対するリストビューの閲覧を制限する機能はありません。本ポリシーは特定の条件にマッチするリストビューを表示をさせたくない、あるいは条件にマッチする利用があった時に通知を受けたい場合に実装を検討します。LoginEventポリシーユーザはアプリケーションを利用するためにログインをする必要があります。標準機能ではユーザの無効化及び凍結の機能を用いてログインをブロックすることができます。またプロファイルで［ログインIPアドレスの制限］や［ログイン時間帯の制限］の制限をかけることもできます。更にはログインフロー用いてログインの制限をかけることも可能です。本ポリシーはログインフローで使用するフローに馴染みがなく、レポートやリストビューの条件設定のように簡単に設定管理できる条件ビルダーを使用したい場合や、逆に複雑なポリシーや処理をApexでコーディングしたい場合に実装を検討します。ReportEventポリシーユーザはレポート機能を利用してデータを表示、またはデータをエクスポートすることができます。標準機能ではプロファイルで［一般ユーザ権限］配下の［レポートの実行］をオフにすることでレポートの使用を制限することができます。また［レポートのエクスポート］をオフにすることでエクスポートのブロックも可能です。本ポリシーはレポートの機能自体をブロックするのではなく、特定の条件にマッチするレポートの使用やエクスポートをブロックしたい場合や通知を受けたい場合に実装を検討します。PermissionSetEventStoreポリシーユーザに権限を割り当てる機能に権限セットがあります。標準機能ではプロファイルで［システム管理者権限］配下の［権限セットの割り当て］をオフにすることで権限セットの割り当てをブロックすることができます。また［プロファイルと権限セットの管理］をオフにすることで権限セットの作成をブロックすることもできます。本ポリシーはヘルプサイトに記載のある特定の権限を制御（有効化や無効化またはユーザへの割り当てや割り当て解除）したい場合、特定の条件にマッチする権限セットの操作をブロックしたい場合、あるいは条件にマッチする利用があった時に通知を受けたい場合に実装を検討します。脅威検知に関するポリシー類標準機能で脅威検知に関するイベントの通知を受ける機能はありません。脅威検知のイベントが発生した通知を受けたい場合に本機能の実装を検討します。併せて脅威検知の利用開始の記事もご確認ください。ApiAnomalyEventStore ポリシーCredentialStuffingEventStore ポリシーReportAnomalyEventStore ポリシーSessionHijackingEventStore ポリシー学習ツールヘルプ：拡張トランザクションセキュリティヘルプ：Apex を使用する拡張トランザクションセキュリティポリシーの作成トレイルヘッド：拡張トランザクションセキュリティまとめトランザクションセキュリティでは、標準機能の権限コントロールでは実現できない細かい条件設定によってブロックだけではなく、通知を要求するなどのアクションをローコートの条件ビルダーや複雑な条件設定をプロコードのApexで実装できます。
Trusted Services

Data Maskとは

この記事で学べることSandbox 環境に求められる条件と晒されるセキュリティリスク、Data Mask が提供する機能、および企業に提供する価値について学べますSalesforce Sandbox でアプリ開発を加速Sandbox とは、開発者や管理者が開発したアプリを検証するための、隔離された安全なテスト環境です。開発・テスト工程に応じて、Developer, Develop Pro, Partial, 及び Full Sandbox の種類があります。詳細はヘルプ記事を参照ください。Partial Sandbox および Full Sandbox では本番データの一部/全部がアプリケーションと一緒にコピーされます。本番データを使用するため、人為的に作成したテストデータでは発見できないデータパターンまでテストを行うことができ、効率的に品質向上を実現できます。また、実際のデータパターンとデータボリュームを使用することによりパフォーマンス問題を事前に予見することができます。テストデータの作成の手間がないため、開発工数・期間の削減、本番業務停止リスクの削減、といった効果も期待できます。Sandbox 環境のセキュリティリスクを理解するその一方で、Partial Sandbox および Full Sandbox では本番データの一部/全部がアプリケーションと一緒にコピーされるため、データの機密性を確保するために考慮すべき点があります。Sandbox 環境から重要情報が漏洩しないための対策を施し、業務のスピード・生産性の向上だけでなく、セキュリティ・プライバシーの確保と併せて適切なバランスとなるよう配慮することが重要です。Sandbox 環境のデータが晒される脅威とはPartial 及び Full Sandbox 環境のデータには、以下のようなセキュリティリスクがあることを認識しなければなりません。しかしながら、本番運用環境と同じセキュリティ施策を講じるための工数や費用をかけるのは現実的ではありません。システム開発プロジェクトの参画メンバーがアクセスする自社のアプリケーション開発担当者、開発委託先（海外のオフショアベンダ含む）の要員、サプライヤ、ビジネスパートナーなど、本番稼働後であればシステムにアクセスしない様々な人が、システム開発のテスト工程では必要に応じて参画することがあります。本来アクセスすべきでない情報にも一時的にアクセス権が付与される場合もあり、全体的にアクセス管理は緩くなりがちです。そのような状況では、データ漏洩などのインシデントが発生するリスクが高くなっていることを認識しておく必要があります。個人情報保護規制に準拠するための管理体制の維持が求められる今日では個人情報保護に係る法規制が世界の国々・地域で厳格化される傾向にあります。Partial 及び Full Sandbox 環境には、本番運用環境のデータがアプリケーションと一緒にコピーされますが、コピーされたデータもそれらの法規制の対象になります。つまり、Partial 及び Full Sandbox 環境では、本番運用環境と同じように厳格に管理しなければならず、お客様が従うべき法令や業界ガイドラインなどに準拠するための対策を行う義務は、Sandbox 環境でもそのまま適用されます。個人情報や機密データを仮名化してリスクを低減Sandbox 環境では、個人情報や機密データの値を仮名化することによって、本番運用環境と比較して少ない工数と費用でセキュリティリスクを低減する方法が効果的です。また、この方法を採用することにより、仮名化されたデータは改正個人情報保護法で定める個人情報管理のスコープ外となります。Data Mask を利用すると、簡単なクリック操作のみで、各データ項目ごとに求められるビジネスニーズや規制等の要求事項に対応するデータの仮名化・削除を実行できます。これにより、セキュリティリスクを低減しながら、可能な限り本番環境に近いデータで、本番環境のボリュームと同等のデータを迅速に準備できます。Data Mask が提供するマスキングレベルは、(1) データをランダム化する、(2) データを同様の値で置き換える、(3) パターンを使用して生成されたデータで置換する、(4) データを削除する、の4つです。詳細はヘルプ記事を参照ください。生産性を向上してアジャイルなシステム開発を実現今日のビジネスはスピードが重要視されます。法令遵守が求められる一方で、経営陣は品質の高いアプリ・製品が迅速に市場に投入されることを期待しています。Salesforce に格納されているデータには、主従関係・参照関係が設定され、更に入力規則、ワークフローやトリガー、などの機能が実装されます。マスキング処理を実行する上でこれらの設定や機能を無視することはできません。単純な手作業によるマスキング処理を行なったために、これらの機能が正常に動作しなくなり、トラブルシューティングに時間がかかってしまうと、場合によってはテスト工程のスケジュールだけでなく、開発プロジェクト全体のスケジュールに影響が出てしまいます。Data Mask は Salesforce ネイティブなアプリケーションとして開発され、マスキング処理の実行時には、前処理としてデータの依存関係や有効化された自動処理の機能を一時的に無効にする処理が組み込まれています。マスキング処理が完了すると、再度データの依存関係や自動処理の機能が有効になるので、設定や実装された機能には変更を加えることなく、データのみが仮名化された状態でご利用いただけます。Data Mask を使用するメリット（定量的な効果）万一 Sandbox 環境からデータ漏洩事故が発生したら企業の損失額はいくらになるか、または Data Mask によりどのくらい開発の生産性が向上するか、といったことを金額に換算してみると、Data Mask が提供する価値がより明確になります。1. データ漏えいによる損失額を試算する情報漏えい事故などが発生すると、損害賠償を請求される可能性があるだけでなく、営業機会の損失や社会的信用の低下など、企業にとって致命的な影響を与えかねません。ここではデータの漏えい事故がもたらす企業の損失額の計算例を示します。ここで使用される要素は以下の３つです。下記の例で与えられた値をそのまま当てはめて計算すると、最大損失予測額は日本円で5千万円超になります。データ漏えい事故の発生確率（Crown Records Management, 2017. Probability of Data Breaches Increases）漏洩したレコードの平均損失額（IBM, 2019. Cost of a Data Breach Report 2019）個人情報や機密情報が含まれるレコード数2. 開発プロジェクト費用の削減効果を試算するテストデータのマスキング処理は想像するよりもはるかに大変な作業です。マスキング処理を自動化することによって、年間で節約することができる開発プロジェクト費用の計算例を示します。ここで使用される要素は以下の4つです。下記の例で与えられた値をそのまま当てはめて計算すると、想定されるメリットは日本円で年間5百万円超になります。年間に企業で実施される開発プロジェクト数Data Mask 導入前の開発/テスト工程にかかる時間（日数）Data Mask 導入によって開発/テスト工程において向上した生産性1日あたりに開発プロジェクトで発生する費用合計3. マスキングに係る作業工数の削減効果を試算する一旦マスキングポリシーを作成すれば、以降のマスキング作業はポリシーを実行するための数クリックの操作のみです。ここではマスキングにかかる作業工数の効率化により削減される費用を試算します。ここで使用される要素は以下の4つです。下記の例で与えられた値をそのまま当てはめて計算すると、日本円で年間2百万円超のコスト削減になります。新規で Sandbox 環境を作成する回数/年Sandbox 環境の設定に係る作業日数これらの作業に関与する開発要員数開発要員の人件費/日Data Mask を使用するメリット（定性的な効果）データは常に Salesforce データセンター内で保護されるData Mask はお客様組織にインストールする管理パッケージとして提供され、作成される Sandbox 環境のデータをマスキングします。つまり、お客様データはマスキング処理中も含めて常に Salesforce 社が運営するデータセンター内で保持され、機密性が確保されます。お客様自身でマスキング処理を手動で行う場合、またはサードパーティ製品を使用する場合は、Sandbox 環境に格納されている本番データのコピーを、一旦ローカル環境等にダウンロードしなければなりません。マスキング処理を実行するために必要な工程とはいえ、本番データのコピーをデータセンターの外に持ち出すことになってしまい、この間はデータが晒される脅威に対して管理者が制御する術はありません。仕事をする環境に合わせたセキュリティ対策を実施する新型コロナウィルスの影響で、開発プロジェクトや中途採用者のトレーニングを在宅で行うといったように、ここ数年で私たちの働き方が大きく変わりました。また、オフショアチームと連携して遂行する開発プロジェクトの機会も増しています。そのような環境では、これまでのように職場で周囲にいる同僚が相互にチェックする「人間による防御シールド」によって不正行為を抑止することはできません。データ漏えいリスクが排除された Sandbox 環境を提供することで、リモートで仕事をする際の障害を排除することができます。学習ツールヘルプ：Sandbox: カスタマイズとテストのためのステージング環境トレイルヘッド：Salesforce Data Mask動画：Full Sandboxを活用しよう！まとめData Maskにより、対策が遅れがちな本番運用環境以外の開発・テスト環境においても重要な個人データを効率的にマスキングすることにより、開発やテストの生産性の向上とともに情報漏えいリスクを減らすことができます。
Trusted Services

Shield

ユーザーのイベントデータを紐解く2つの鍵

この記事で学べることイベントデータを分析する上で鍵となるログインキーとセッションキーについて解説します。それぞれのキーにおいて、リアルタイムイベントモニタリングのログを例に、ユーザのイベントデータをどのように紐解くことができるか事例を紹介します。(おさらい) イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとは今回ご説明するログインキー、セッションキーは以下の項目名でどちらのログ種別にも含まれております。それぞれのキーの値は、アルファベットの大文字小文字、数字、記号を含むランダムな16文字の文字列で構成されます。リアルタイムイベントモニタリングログログインキー：LoginKeyセッションキー：SessionKeyイベントモニタリングログログインキー：LOGIN_KEYセッションキー：SESSION_KEYログインキーについてログインキーは、ユーザがあるクライアントでログインしてからログアウトするまでの間に行った一連の操作に対して、一意に付与される値になります。例えば、あるユーザがSalesforceにログイン→レコードへアクセス→ログアウトし、その後再度ログイン→レコードアクセスした場合、最初のログイン後に実施したレコードアクセスのアクセスログに含まれるログインキーの値と、二回目のアクセスログに含まれるログインキーの値は異なります。ログインキーはログイン処理の度に生成されるので、もし仮に一人のユーザが同じ時間帯に複数のブラウザや端末で同時に操作していた場合でも、それぞれのブラウザや端末で実施したログインの数だけ異なるログインキーが割り当てられます。以下に、一人のユーザが同じ時間帯に複数端末からログインし、レコードへアクセスした際のリアルタイムイベントモニタリングログの例を示します。（ログのフォーマットは一部簡略化しています）このとき、ログに含まれるログインキーの値が各端末毎に異なること、また一度ログアウトし再度ログインした場合にログインキーの値が更新されることにご注目ください。このようにログインキーの値を確認することで、例え同一ユーザであっても異なる環境やログインセッションで操作をしていた場合に、これらを区別することが出来るようになります。セッションキーについてについてセッションキーはユーザのセッションに紐付く値になります。通常、ログイン処理に伴いセッションが発行されるため、ログインキーが変化する場面ではセッションキーも同じく更新されるケースが大半です。セッションキーのみが更新されるケースとして、他のユーザとしてのログインや frontdoor.jsp を使用したログインを伴わないSalesforceへのアクセスがあげられます。以下に、一人のユーザが一度だけログインし、その後frontdoor.jspを使用した別端末へのアクセスや他のユーザとしてのログイン操作に伴うリアルタイムイベントモニタリングのログ例を示します。このとき、frontdoor.jspや代理ログインによる別の端末や別のユーザによるアクセスログにおいて、ログインキーの値は全て同一でありながらも、セッションキーの値がそれぞれ変化している点にご注目ください。あるユーザがログイン処理を伴わずに別の端末やユーザとしてアクセスをした結果、ログインキーが同一であった場合でもセッションキーの値を確認することでそれぞれの操作を見分けることが出来ます。学習ツールsalesforce admins：Two New Keys to Unlock Your Users’ Event Data - Salesforce Admins(英語)サクセスナビ：アクセスログの参照ガイドまとめイベントモニタリングログとリアルタイムイベントモニタリングログに含まれるログインキーとセッションキーにより、Salesforce アプリケーション内のユーザーの行動をより詳細に把握することが可能となり、セキュリティ調査やユーザー行動の理解、アプリケーションやパフォーマンスの問題の調査などに役立てることができます。
Trusted Services

Shield

項目監査履歴とは

この記事で学べることデータの変更履歴の長期保存がどうして必要なのかを理解し、標準機能で提供される項目履歴管理との違いを理解します。項目単位に変更履歴を設定する方法を学びます。項目履歴管理（標準機能）との違い項目監査履歴（オプション）は、項目履歴管理（標準機能）の制限を拡張させたものですが、利用できるエディション、オブジェクトあたりの追跡できる項目数、保存期間、および保存場所に以下のような違いがあります。項目履歴管理項目監査履歴利用可能なエディション全てEnterprise、Performance、Unlimited項目数/オブジェクト最大20項目最大60項目保管期間本番組織に18 か月API 経由で最大 24 か月アクセス可本番組織に18ヶ月アーカイブ後は無期限保管場所StandardObjectNameHistory または CustomObjectName__Historyアーカイブ前は項目履歴管理と同じアーカイブ後はFieldHistoryArchive Big Object項目監査履歴を利用するメリットイベントモニタリングは、ページまたはレコードレベルでユーザのアクセス履歴を追跡するためのログを提供しますが、更に項目監査履歴を利用することで、レコード内の項目値がどのように変更されたかという履歴を追跡することができるようになります。以下のような要件を満たす必要があるお客様にメリットをもたらします。データの変更履歴を監査証跡として提示し、更新処理が正確で改ざんなどの不正がないことを証明することが求められるが、以下の点で標準機能ではお客様の要求を満たすことができない場合追跡したい項目がオブジェクトあたり20項目を超えるデータを21ヶ月以上の長期間保管したい個人情報保護法や GDPR に求められる個人情報の正確性に対して厳密に準拠したい場合企業の会計情報に影響を与える情報を Salesforce 内で保存管理をしている場合規制業種のお客様（金融サービス、ヘルスケア、ライフサイエンス、医療機器、研究機関など）が、法令やガイドラインで求められる履歴データの保持要件に適合する場合顧客のレコードの項目値がどのように変更されたかの履歴を、過去に遡って調べる必要がある場合変更履歴を保管する仕組みを予めユーザに周知することで期待される、不正行為（コミッションに関係する金額の改ざんなど）の抑止効果コーポレイトガバナンスを強化したい場合項目監査履歴の特徴項目監査履歴データは、Salesforce 組織のデータストレージ制限には含まれませんので、ログを蓄積することでお客様組織のストレージが消費されてしまう心配はありません（項目履歴管理も同様の仕様です）データの変更履歴は、オプションの契約手続きが完了すると、本番組織に18ヶ月保管した後 Big Object にアーカイブされるよう自動的に仕様が拡張されますので、お客様側での特別な設定作業は不要です一部のオブジェクトに対しては、オブジェクトごとに保持ポリシーを定義できます。本番組織の保存期間は 0 〜 18 ヶ月、アーカイブの保存期間は 0 〜無期限、の範囲で設定可能ですアーカイブデータには、データローダーやSOQL または Bulk API によるクエリを実行することでアクセスできます変更履歴を追跡するために必要な設定・操作項目の変更履歴を追跡するための基本的な設定手順は、項目履歴管理（標準機能）と同じです。レコードの変更履歴を管理するを参照ください。項目監査履歴（オプション）で必要となる設定や操作はに以下のものがあります。Salesforce メタデータ API を使用して、オブジェクト単位で変更履歴の保持ポリシーを更新できます。この設定を行うのは、アーカイブデータの保持ポリシーに設定されているデフォルト値（本番組織に18ヶ月、アーカイブは無期限）を変更する場合のみです。例えば、取引先オブジェクトの変更履歴は、本番組織には6か月間、アーカイブには5年間保持する、といった内容でポリシーを変更することができます。メタデータの具体的な編集例はヘルプ記事を参照くださいアーカイブデータを照会するには、FieldHistoryArchive オブジェクトに対して SOQL クエリを実行します。実行する SOQL 文の例は、SOQL with FieldHistoryArchive（英語）を参照くださいデータローダーで、FieldHistoryArchive オブジェクトのデータをエクスポートすることもできます一般的な考慮事項本番データのレコードを削除すると、関連する履歴レコードもカスケード削除される仕様は項目履歴管理と同じですが、Big Object にアーカイブされたデータは削除されません。このデータを削除するための手順は、「項目履歴および項目監査履歴データの削除」を参照してください項目監査履歴を有効にしている組織で、後からプラットフォーム暗号化を有効にした場合、アーカイブされたデータは自動的に暗号化されません。ヘルプ記事をご確認いただき、アーカイブされたデータを暗号化するためには弊社サポートにお問い合わせください学習ツールサクセスナビ：レコードの変更履歴を管理するヘルプ：項目監査履歴実装ガイド：Field Audit Trail Implementation Guide(英語)トレイルヘッド：アプリケーションへのセキュリティレイヤの追加まとめ項目監査履歴により、長年にわたり、内部統制が適切に行われていることを確認し、第三者に証明できることによりコーポレートガバナンスの強化が実現できます。項目履歴管理（標準機能）の制限拡張オプションですので、ライセンス購入後に特別セットアップは必要にありませんが、保存期間を調整する場合には設定が必要です。
Trusted Services

Shield

Salesforce利用分析のためのイベントログの参照ガイド

この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、活用に向けてユーザがどのようにSalesforceを利用しているか分析するために、確認したいケースごとにどこの情報を参照することにより、ユーザがどのようにSalesforceを利用しているかを確認することができることを理解できます。イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス/Event Monitoring Analytics分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとは利用状況の確認方法ログイン状況の確認（Event Monitoring Analytics から）利用状況確認の第一歩目としてログイン状況の確認が必要です。Event Monitoring Analytics のLoginsダッシュボードを活用すれば、数回のクリックで誰が頻繁にログインをしているか、また特定プロファイルや部門/役職（ロール）のユーザのログイン回数がどの程度か一目瞭然となります。従前の作業で必要であった、ログイン履歴のCSVファイルをダウンロード、表計算ソフトにインポート、関数やフィルタ機能を駆使して必要なデータを抽出しグラフ化、といった煩わしい作業が不要になります。あまりログインができていないユーザや部門があれば、ログインされない原因を確認して対応します。例えば、使い勝手が悪いとの事であればレコードタイプやページレイアウトのカスタマイズを実施する、使い方が分からないとの事であれば使用方法の従業員教育をする、そもそも使う理由や効果が納得できないとの事であれば導入目的を説明して理解を促す等の対応が考えられます。人気の高いレポート/ダッシュボード/ファイルの確認（Event Monitoring Analytics から）ログイン状況の改善がなされたら、次のステップとしてどの様な情報がよく参照されているかを把握します。利用頻度の高い情報は有益である可能性が高いと考えられるためです。例えば利用頻度の高いダッシュボードの情報をアナウンスすることで、ユーザやチームは今まで活用できていなかったダッシュボードに気付くことができるかもしれません。この様な利用傾向はEvent Monitoring Analyticsで提供されるダッシュボードから容易に確認ができます。Salesforceにおけるダッシュボードの利用傾向はDashboards、レポートの利用傾向はReportsまたはReport Downloads、ファイルの利用傾向はFilesのダッシュボードから確認ができます。また、この様な利用傾向を容易に共有できる機能をEvent Monitoring Analytics は有しています。どのキーワードで情報が検索されているか確認(Event Monitoring Analytics から）Event Monitoring Analytics においてダッシュボードではありませんが、データセットとして用意されているSearchデータセットのSEARCH_QUERY項目を調べる事によって、どのようなキーワードでSalesforce内の情報が検索がされたのかを確認ができます。Searchデータセットの内容についてはソースのログである検索イベント種別をご確認ください。Searchデータセットによってユーザが業務上どの様な情報に関心を持っているか分かり、効果的にナレッジを提供できる蓋然性が高まります。利用頻度の高いリストビューの確認（リアルタイムイベントモニタリングから）ユーザがどの様なフィルタ条件のリストビューを用いているかも重要な情報となり得ます。リアルタイムイベントモニタリングのListViewEventからFilterCriteria項目を確認することでフィルタ条件を確認できます。リアルタイムイベントモニタリングで確認できる内容についてはアクセスログの参照ガイドの記事も併せてご参照ください。レコードの作成や編集に要した時間を把握（リアルタイムイベントモニタリングから）ユーザが特定のレコードの作成や編集にどの程度の時間を要したか、リアルタイムイベントモニタリングのLightningUriEvent（Classic環境の場合はUriEvent）から、画面を開いた時刻と保存時の時刻の時間差で確認をする事ができます。具体的にどのオブジェクトに対する操作であったかはQueriedEntitiesを、どのレコードに対する操作であったかはRecordIdから確認をします。EventDate : 指定された URI イベントが捕捉された時間 (クエリの実行後)。たとえば、「2020-01-20T19:12:26.965Z」などです。最も細かい設定はミリ秒ですOperation : エンティティで実行されている操作。Read, Create, Update または Delete があります。作成および更新操作はペアで捕捉されます。つまり、操作ごとに 2 つのイベントレコードが予期されます。最初のレコードは操作の開始を表し、2 番目のレコードは操作が成功したかどうかを表します。2 つのレコードはRelatedEventIdentifier によって相互に関連付けられます。作成または更新操作に対して 2 番目のイベントが記録されていない場合、ユーザが操作をキャンセルしたか、クライアント側の検証で操作が失敗しています。(必須項目が空の場合など)。RecordId : 表示または編集されているレコードの IDQueriedEntities : URI によって参照されるオブジェクトの API 参照名Username : イベントが作成された時点での user@company.com 形式のユーザ名ハイパフォーマーの活用方法を共有ユーザによる利用状況の把握ができたら、次のステップとしてハイパフォーマーの活用方法を抽出して展開することが考えられます。ハイパフォーマーが良く使っているダッシュボードやレポート、ファイルなどを共有し、レコードの作成や編集にかける時間をどの様に短縮しているかといった工夫をヒアリングして展開します。ハイパフォーマーからのフィードバックを得る事で使い勝手の良いアプリケーションとなっていき、ログイン率が向上、改善のサイクルが回っていくことが期待できます。ケーススタディ太陽光発電システムを販売する米国最大のプロバイダーであるS社は、導入開始間もないモバイルアプリケーションの利用促進に課題を持っていましたが、イベントモニタリングを使用して課題を抱えているユーザーを特定し、的を絞ったコーチングを提供することで、モバイルアプリケーションの採用を加速しました。また、化粧品業界向けの特殊原料を製造する大手メーカーのT社は、一部の営業チームがCRMを使用していなかったことでが課題でしたが、イベントモニタリングにより、使用頻度と営業成績の観点から、営業チームの行動を追跡できるようになりました。時間と使用の質を調べることで、Salesforceを頻繁に使用する営業担当者がそうでない営業担当者よりり成績が良いことを証明できました。Salesforceの利用が増えることで、その価値を売上高で示すことができるので、実際にSalesforceをもっと使おうという気にさせることができSalesforceをより多く使用するように営業担当を動機付けることができました。学習ツールプラットフォームイベント開発者ガイド- リアルタイムイベント監視オブジェクトSOAP API 開発者ガイド - EventLogFile でサポートされているイベント種別サクセスナビ - アクセスログの参照ガイドまとめイベントモニタリンクおよび、リアルタイムイベントモニタリングのログを分析することにより、ユーザのログイン状況、よく使用されるリストビュー、レポート、ダッシュボード、ファイルなどが理解でき、レコードの作成や編集に要した時間も把握するとこができます。また、利用状況と売上や勤務時間など他の情報との関係性を発見できるかもしれません。これで得られた洞察により、利用活用の障壁に対策を講じたり、利用の動機付けを行うことによりSalesforce の利用および活用促進につなげることが可能となります。
Trusted Services

Shield

プラットフォーム暗号化とは

この記事で学べることプラットフォーム暗号化の導入メリット、従来の暗号化項目との違い、暗号鍵の管理方法の4つの違い、確率的暗号化と確定的暗号化の違いを理解できます。プラットフォーム暗号化の導入メリットSalesforceに格納されるデータは、データベースを取り巻くインフラレベルの物理的なセキュリティやマルチテナントデータベースの仕組み、そして内部脅威に対する厳格なアクセスコントロールによって常に高いセキュリティで守られています。また、多くのお客様は、認証やシングルサインオン、きめ細かいアクセス制御、ログイン監視などの標準機能により、データの安全性を十分に保っています。一方で、個人情報や機密データなどの慎重に扱うべきデータをSalesforceに保存するお客様の増加に伴い、外部および内部のデータコンプライアンスポリシーやガイドラインへの対応のため、標準のセキュリティ対策に加え「保存データの暗号化」が必要となるケースが増えています。お客様の業種は金融サービス、ヘルスケア、製造、テクノロジー、公共団体など多岐にわたりますが、このようなケースでは、主に以下のような要件への対応を求められます。クラウドサービスに保存する個人情報や機密データの暗号化暗号化鍵のライフサイクルの制御アプリケーションの機能の維持プラットフォーム暗号化は、検索、フロー、検証ルールなど、主要なアプリケーション機能を阻害しないよう設計されており（注）、お客様にて暗号化鍵のライフサイクルを制御しながら、Salesforceに保存されているデータをネイティブに暗号化することができます。外部および内部のデータコンプライアンスポリシーやガイドラインの要求を満たし、お客様のコンプライアンス対応における有効な追加レイヤーになる。これがプラットフォーム暗号化の導入メリットです。（注）プラットフォーム暗号化にはデータが暗号化されて保存されることに伴う機能制限やトレードオフがあります。また、AppExchangeアプリをご利用の場合、互換性の問題により一部または全部のサービスが制限される場合がございます。アプリの提供元にご確認いただくか動作をテストしてから本番環境でご利用いただくことを推奨します。プラットフォーム暗号化で暗号化できる項目Shield Platform Encryption のトレードオフおよび制限事項従来の暗号化とプラットフォーム暗号化との違い標準機能において、カスタム項目作成時に「テキスト（暗号化）」のデータ型で作成した項目のデータは保存時に暗号化されます。これを「従来の暗号化」と呼びます。従来の暗号化では、「テキスト（暗号化）」のデータ型で作成したカスタム項目のデータのみを保護できるのに対し、プラットフォーム暗号化は、広く使用されているさまざまな標準項目、一部のカスタム項目、および種々のファイルを暗号化できます。また、プラットフォーム暗号化では、個人取引先、ケース、検索、承認プロセス、およびその他の主要なアプリケーション機能やお客様による暗号化鍵のライフサイクルの管理もサポートしています。カスタム項目の従来の暗号化従来の暗号化と Shield Platform Encryption との違い4つの鍵管理方法と鍵の循環プラットフォーム暗号化を使用すると、4つの方法でデータの暗号化に使用される鍵素材の管理および循環が可能になります。デフォルトの鍵管理方式では、お客様はSalesforceを使用して「テナントの秘密」を生成し、それをSalesforceが管理するリリースごとの「主秘密」と結合してデータ暗号化鍵を抽出できます。抽出されたデータ暗号化鍵は、暗号化と復号化の両方の機能で使用されます。また、Bring Your Own Key（BYOK）サービスを使用して独自の鍵素材を使用する方法として、アップロードした鍵素材とSalesforceが管理する「主秘密」を結合してデータ暗号化鍵を抽出するBYOK 1、アップロードした鍵素材を「主秘密」と結合せず暗号化鍵として使用するBYOK 2、更に、鍵素材をSalesforce の外部に保存し、キャッシュのみの鍵サービスで鍵素材をオンデマンドで取得するBYOK 3の方法が用意されています。いずれの方式においても、お客様はテナントの秘密や鍵素材のライフサイクルを制御することで、データ暗号化鍵のライフサイクルを制御することが可能です。鍵の管理と循環確率的暗号化と確定暗号化プラットフォーム暗号化は、各データが暗号化されるたびに完全にランダムな暗号文字列に変換される「確率的暗号化」を基本としていますが、一部のデータ型の項目では、同じデータ文字列は同じ暗号文字列に変換される「確定的暗号化」を選択することが可能です。確率的暗号化は、ランダム初期化ベクトル（IV）とCBCモードでのAES-256bit暗号アルゴリズムを使用します。各データが暗号化されるたびに完全にランダムな暗号文字列に変換されるため、並べ替え操作などの一部の機能が失われますが、これはセキュリティを優先するための妥当なトレードオフと考えられています。一方、確定的暗号化は、静的初期化ベクトル（IV) を使用することで、同じデータ文字列は同じ暗号文字列に変換される仕組みを実現しており、暗号化されたデータを特定の項目値と照合できるようにしています。これにより絞り込みなどの制限が緩和され、ビジネス要求を最大限確保した暗号化が実現できます。確定的暗号化には、大文字と小文字を区別するものと、大文字と小文字を区別しないものの2種類があります。大文字と小文字を区別する暗号化では、取引先責任者オブジェクトに対するSOQLクエリでLastName = Jonesとすると、Jonesのみが返され、jonesやJONESは返されません。大文字と小文字を区別しない場合には、LastName = Jonesとすると、Jones、jonesまたはJONESが返されます。採用すべき暗号化方式について、米国政府機関やPCI DSSなどの米国発のガイドラインでは、NIST Special Publication 800-57 Part 1「鍵管理における推奨事項」が参照されています。また、日本においては多くの企業が「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」が参照しています。これらのガイドラインでは確定的暗号化の暗号方式は推奨されていません。電子政府推奨暗号リストに含まれる暗号方式を採用する必要がある項目や、お客様のPCI DSS認証において当社のPCI DSS AoC（準拠証明書）を利用する場合の対象項目には確定的暗号化は利用することができませんのでご注意ください。学習ツールTrailhead - モジュール Shield Platform Encryptionホワイトペーパー - Shield Platform Encryption Architecture（英語）まとめプラットフォーム暗号化は、企業に求められるデータコンプライアンス要件や業界基準、ガイドラインなどの暗号化要件を満たし、コンプライアンスにおける追加のレイヤーとして、クラウド上の非公開データの保護というステークホルダーとの契約上の義務を果たしていることを証明するために有効なオプションです。暗号化鍵の管理方法においては、鍵の生成及び管理を完全にお客様側でコントロールするといった厳しい要求にも対応が可能です。なお、機能上の制限は従来の暗号化と比較してかなり緩和されていますが、データが暗号化されて保存されることに伴うトレードオフがあるため、注意が必要です。
Trusted Services

Shield

パフォーマンス分析のためのイベントログの参照ガイド

この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、パファーマンス分析のために、確認したいケースごとにどのログのどの項目を参照することにより、ボトルネックやチューニングのポイントを確認することができるか理解できます。イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとはここでは、パフォーマンス分析用のログとしてイベントモニタリングのログを対象に説明しています。パフォーマンス監視の重要性生産性向上を実現するために導入したせっかくのシステムもレスポンスが悪く利用にストレスがあると利用が促進されない場合があります。パフォーマンスはシステムを利用するにあたって重要な要因です。しかしパフォーマンスは様々な要因で劣化してしまいます。例えば、大量データの取り扱い、データベースのインデックス、冗長なロジックのコード、またお客様環境においてもネットワークやクライアントの環境によってもパフォーマンス劣化が発生します。そのため継続的なパフォーマンスの監視はシステムの導入を成功に導くために重要なポイントとなります。イベントモニタリングによるログの取得多くのイベントログに要求の完了にかかった CPU 時間 (CPU_TIME)が記録されます。また、APEX実行に関するログにはデータベースのパフォーマンスに係る数値(DB_TOTAL_TIME)が記録されます。パフォーマンスの問題が発生した際は、イベントログから要求の完了に係ったCPU時間とデータベースの処理にかかった時間を比較することで、パフォーマンス上の問題が独自のコードの部分にあるかデータベースレイヤのどちらにあるか、またはクライアント環境に起因するものか判断することが出来ます。また、大まかに処理に時間がかかった部分を判断した上で、デバッグログの設定をしていただく事でより具体的にどの処理に時間を要したか、効率よく確認をしていく事が可能となります。ヘルプ : デバッグログの設定取得するべきイベントログファイル以下にパフォーマンスに関する調査において参考となるイベントログファイルおよびその項目について例示をします(表中黄色いハイライト部分は、ログ対象のイベントを特定する項目です)。各イベントログファイルの内容については以下をご参照ください。SOAP API開発ガイド：EventLogFile でサポートされているイベント種別Lightning ページビューイベント種別Lightning Experience および Salesforce モバイルアプリケーションでイベントが発生したページに関する情報を表します。Lightning ページビューイベントは、ユーザがアクセスしたページ、そのページにユーザが滞在した時間、ページの読み込み時間を追跡します。Summer ‘22のリリースで、EFFECTIVE_PAGE_TIME_DEVIATION、EFFECTIVE_PAGE_TIME_DEVIATION_ERROR_TYPE、および EFFECTIVE_PAGE_TIME_DEVIATION_REASONの3項目が追加されました。これらの項目によりページのロードに時間がかかる原因の特定が容易になります。項目名説明PAGE_URLユーザが開いた最上位の Lightning Experience ページまたは Salesforce モバイルアプリケーションページの相対 URL。ページには、1 つ以上の Lightning コンポーネントを含めることができます。複数のレコード ID を PAGE_URL に関連付けることができます。EFFECTIVE_PAGE_TIMEページを読み込んでからユーザがページの機能を操作できるようになるまでにかかった時間 (ミリ秒) を示します。実効ページ時間は、複数の要素 (ネットワーク速度、ハードウェアパフォーマンス、ページの複雑さなど) の影響を受けます。60 秒を超える有効なページ時間が検出された場合、この項目の値は null に設定されます。EFFECTIVE_PAGE_TIME_DEVIATION逸脱が検出されると EFFECTIVE_PAGE_TIME_DEVIATION はtrueを記録します。デフォルト値はfalseです。EFFECTIVE_PAGE_TIME_DEVIATION_REASONページ読み込み時間の逸脱の理由が記録されます。値の意味についてはLightning ページビューイベント種別からAPI version v55.0以降をご確認くださいEFFECTIVE_PAGE_TIME_DEVIATION_ERROR_TYPEこのフィールドはEFFECTIVE_PAGE_TIME_DEVIATION_REASONにPAGE_HAS_ERRORが記録された場合に入力されます。入力されうる値はCUSTOMまたはSYSTEMとなります。・CUSTOM ：顧客システムまたはネットワークに起因するエラー・SYSTEM ：セールスフォースに起因するエラーLightning パフォーマンスイベント種別Lightning Experience および Salesforce モバイルアプリケーションのパフォーマンスのトレンドを追跡します。レコードに対するユーザアクションに関する所要時間が把握できます。項目名説明UI_EVENT_SOURCEレコードに対するユーザアクション(作成/編集/削除/参照など)。この項目の値は、ユーザのアクションが 1 つのレコードに対して実行されたか複数のレコードに対して実行されたかを示します。たとえば、read は (レコード詳細ページなどで) 1 つのレコードが参照されたことを示し、reads は (リストビューなどで) 複数のレコードが参照されたことを示します。DURATIONページ開始時刻からの時間 (ミリ秒)。Apex 実行イベント種別実行された Apex クラスに関する詳細が含まれます。項目名説明URI要求を受信しているページの URI。NUMBER_SOQL_QUERIESイベント中に実行された SOQL クエリ数。IS_LONG_RUNNING_REQUEST要求が実行時間が長い組織の同時 Apex 要求の上限にカウントされるか (true)、否か (false) を示します。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU使用率にカウントされません。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。EXEC_TIMEエンドツーエンドの Apex 実行時間 (単位: ミリ秒)。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。Apex REST APIイベント種別すべての Apex REST API 要求に関する情報を取得します。項目名説明URI要求を受信しているページの URI。ROWS_PROCESSED要求で処理された行数。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU使用率にカウントされません。DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されているアクティビティ量を示します。DB_BLOCKSデータベースで発生しているアクティビティ量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。Apex SOAP イベント種別Web サービス API コールに関する詳細が含まれます。項目名説明CLASS_NAMEApex クラス名。クラスが管理パッケージの一部である場合、この文字列にはパッケージ名前空間が含まれます。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。Apex トリガイベント種別組織で起動されたApexトリガに関する詳細が含まれます。項目名説明TRIGGER_ID起動されたトリガの 15 文字の ID。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。EXEC_TIMEエンドツーエンドの Apex 実行時間 (単位: ミリ秒)。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。非同期レポート実行イベント種別非同期レポート実行イベントは、スケジュールされたレポート要求に対して作成されます。このカテゴリには、ダッシュボードの更新、非同期レポート、スケジュールレポート、分析スナップショットが含まれます。項目名説明REPORT_ID実行されたレポートの 15 文字の ID。ROW_COUNT非同期レポート実行イベントで処理された行数。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_BLOCKSデータベースで発生している活動量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。実行時間が長い同時 Apex 制限イベント種別組織の同時実行制限に達した後に Salesforce によって終了された、組織内の実行時間が長い同時 Apex 要求に関する情報が含まれます。確立された Apex コンテキストが 5 秒間実行される要求は、実行時間が長い同時要求の組織の制限に含まれます (非同期要求は制限に含まれません)。実行時間が長い要求数が 10 (組織のデフォルトの制限) を超えた場合、その他の実行時間が長い要求は終了されます。項目名説明REQUEST_URISalesforce によって終了された実行時間が長い Apex 要求の URI。継続コールアウトサマリーイベント種別トランザクション中に実行されたすべての非同期コールアウト、その応答状況コード、実行時間、および対象の URL エンドポイントに関する情報が含まれます。項目名説明URLコールアウトエンドポイント URL。継続で使用された HTTP 要求数によっては、この項目に最大 3 個のスペース区切り値が含まれる可能性があります。DURATION合計継続時間 (ミリ秒)。外部のカスタム Apex コールアウトイベント種別Salesforce Connect のカスタムアダプタを介した外部データコールアウトを表します。項目名説明ENTITYアクセスされる外部オブジェクトの名前。ACTIONコールアウトによって実行されるアクション(query/upsert/delete)。ROWS_FETCHEDコールアウトによって取得された行の数ROWS結果セットの総レコード数FETCH_MS外部システムからクエリ結果を取得するのに要した時間 (ミリ秒)。THROUGHPUT1 秒間で取得されたレコード数。EXECUTE_MSSalesforce がクエリの準備および実行に要した時間 (ミリ秒)。TOTAL_MSクエリの準備、実行、およびクエリ結果の取得に要した時間 (ミリ秒)外部の OData コールアウトイベント種別Salesforce Connect の OData 2.0 および OData 4.0 アダプタを介した外部データコールアウトを表します。項目名説明ENTITYアクセスされる外部オブジェクトの名前。ACTIONコールアウトによって実行されるアクション(query/upsert/delete)。ROWS_FETCHEDコールアウトによって取得されたレコードの数。コールアウトによって取得されたレコードは、大きな結果セットのサブセットである場合がありますROWS結果セットの総レコード数FETCH_MS外部システムからクエリ結果を取得するのに要した時間 (ミリ秒)THROUGHPUT1 秒間で取得されたレコード数。EXECUTE_MSSalesforce がクエリの準備および実行に要した時間 (ミリ秒)TOTAL_MSクエリの準備、実行、およびクエリ結果の取得に要した時間 (ミリ秒)レポートイベント種別ユーザがレポートを実行したときの動作に関する情報が含まれます。このイベント種別には、レポートのエクスポートイベント種別のすべての活動とその他の活動が含まれます。項目名説明REPORT_ID実行されたレポートの 15 文字の ID。ROW_COUNTレポートイベントで処理された行数。行数が多く、かつ AVERAGE_ROW_SIZE も大きい場合は、ユーザが詐欺目的で情報をダウンロードしている可能性があります。たとえば、競合他社に転職する前にすべてのセールスリードをダウンロードする営業担当などがこれに該当します。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されている活動量を示します。DB_BLOCKSデータベースで発生しているアクティビティ量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。フロー実行イベント種別合計実行時間、インタビューの数、エラーの数などの詳細を含む、実行されたフローに関する情報が含まれます。項目名説明FLOW_VERSION_ID実行されたフローバージョンの ID。FLOW_LOAD_TIMEフローのメタデータの読み込みにかかった時間 (ミリ秒単位)。TOTAL_EXECUTION_TIMEすべてのフローインタビューの開始と終了にかかった合計時間 (ミリ秒単位)。Wave パフォーマンスイベント種別Analytics パフォーマンスのトレンドを追跡するのに役立ちます。項目名説明RECORD_IDTableau CRM オブジェクトの Salesforce ID。TAB_IDユーザインターフェースの特定の [分析] タブの ID。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。RUN_TIME要求にかかった時間 (ミリ秒単位)。EPT体験ページ時間 (ミリ秒単位)。Visualforce 要求イベント種別Visualforce 要求に関する詳細が含まれます。要求はブラウザ (UI) から実行できます。項目名説明PAGE_NAME要求された Visualforce ページの名前。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されている活動量を示します。DB_BLOCKSデータベースで発生している活動量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。コンソールイベント種別Salesforce コンソールのパフォーマンスと使用に関する情報が含まれます。サイドバーコンポーネントで [コンソール] タブが開かれるたびに、コンソールイベントがログに記録されます。それ以外は、Salesforce Classic の場合と同様に、[コンソール] タブが開かれると、通常のレコードの詳細の表示イベントが記録されます。項目名説明COMPONENT_IDコンポーネントの 15 文字の ID。CONSOLE_IDコンソールの 15 文字の ID。RECORD_IDコンソールに関連付けられたレコードの 15 文字の ID。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。学習ツールSOAP API開発ガイド：EventLogFile でサポートされているイベント種別ヘルプ : デバッグログの設定トレイルヘッド：Lightning Experience のパフォーマンスの最適化ヘルプ：技術要件とパフォーマンスのベストプラクティスまとめパフォーマンス分析に関するログは、イベントモニタリングのログに記録され、対象のログと項目を確認することにより、パフォーマンス問題がどこで発生しているのか、またどこがボトルネックになっているのか確認することができます。この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、パファーマンス分析のために、確認したいケースごとにどのログのどの項目を参照することにより、ボトルネックやチューニングのポイントを確認することができるか理解できます。
Trusted Services

Shield

脅威検知の利用開始

この記事で学べること脅威検知機能の概要脅威検知アプリケーションの設定方法トランザクションセキュリティによる管理者への通知設定イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとは脅威検知は、リアルタイムイベントモニタリングに含まれるログとなります。脅威検知機能の概要脅威検知機能はイベントモニタリングに含まれる機能の一つであり、統計および機械学習の手法を駆使してSalesforce組織に対する脅威を検知します。この機能により、組織内で発生しているアクティビティに対して、不審なもの・普段とは傾向が異なるものがないかどうかが自動で分析され、万が一異常な傾向があった場合には「脅威検知イベント」としてその内容をログに記録します。また、同じイベントモニタリングに含まれるトランザクションセキュリティ機能と組み合わせることで、脅威検知イベントが作成された際に管理者に対してメールやアプリ内通知で知らせることもできます。このように、AIの力を借りることでシステム管理者が蓄積されたログを逐一分析することなく、組織に対する脅威を確認する手助けを行ってくれます。設定は簡単ですので、ログを分析できる要員がいない組織でも有効な機能です。脅威検知機能にて検知できる機能は以下の4種類です。クレデンシャルスタッフィングクレデンシャルスタッフィングは、盗取したログイン情報を使用する一種のサイバー攻撃です。「パスワードスプレー」「クレデンシャル漏洩」ともいいます。攻撃者は、脆弱なウェブサービスに対するサイバー攻撃や、過去に流出した情報などから大量のユーザ名とパスワードを取得します。そして、取得したログイン情報を使用して、Salesforce などの Web アプリケーションに大規模な自動ログイン要求を仕掛け、ログイン出来るアカウントがないかどうか調査します。もし万が一ユーザ名とパスワードを使いまわしているユーザがいた場合、ユーザアカウントに不正にアクセスされてしまいます。セッションハイジャックセッションハイジャックは、ログイン中のユーザのセッションを乗っ取り、そのユーザに成りすましてアクセスを行う攻撃です。通常ウェブページにおいてログイン処理が正常に行われると、ユーザのクライアントはセッショントークンを受け取り、次回以降ログイン後の状態でアクセスが出来ます。攻撃者はそのセッショントークンを窃取して、クライアントのセッションを乗っ取ろうとします。万が一セッションが乗っ取られた場合、攻撃者はトークンを窃取されたユーザに成りすましてウェブページへアクセス出来るため、ログイン後にしかアクセスできないような機密情報にアクセス出来てしまう可能性があります。(注意) イベントモニタリングライセンスの有無にかかわらず、Salesforceのすべてのお客様はクレデンシャルスタッフィングおよびセッションハイジャックが発生した場合に、影響を受けたユーザに対してセッションの切断やID 検証、強制パスワード変更といった軽減措置が実施されます。ただし、これらの軽減措置はシステムによって自動で実行されるものであり、対象組織の管理者はその措置が発動されたかどうかを確認することは通常出来ません。イベントモニタリングの脅威検知機能により、これらの不正なアクティビティがイベントログとして記録されるため、お客様の組織に対して不正なアクセスがあったことを表面化させる(認知する)ことができ、システム管理者がその内容を確認することが出来るようになります。レポートの異常過去90日分のユーザのレポート生成とその周辺アクティビティの傾向を元に、ユーザーが普段とは異なる傾向でレポートを実行またはエクスポートしたかどうかを調査します。もしユーザのレポートアクティビティが普段とは異なる傾向であった場合、脅威検知イベントとしてその内容がログとして記録されます。システム管理者は生成されたログにより組織内の異常な行動について感知することができ、ログ内容を確認することで検知された行動が本当に悪意のあるものであったかどうかを確認していくことができます。API 異常レポートの異常と同じく、過去90日分のユーザのAPI生成とその周辺アクティビティの傾向を元に、ユーザーが普段とは異なる傾向でAPIを利用していないかどうかを調査します。脅威検知アプリケーションの設定方法脅威検知機能には、アプリケーションランチャーからアクセスができる専用のアプリケーションが用意されています。この脅威検知アプリケーションにアクセスし、組織内で発生した脅威検知イベントを確認するためには、以下の手順を実施して管理ユーザに表示できるようにしておく必要があります。イベントマネージャを使用して、4種類の脅威検知イベント (CredentialStuffingEvent, SessionHijackingEvent, ReportAnomalyEvent, ApiAnomalyEvent) のストリーミングとストレージを有効にします。詳細な手順はこちらの記事をご確認ください。Salesforce ライセンスに関連付けられた権限セットを作成します。権限セットについてはこちらの記事をご確認ください。権限セットの [システム権限] ページを編集し、[脅威検知イベントを表示] 権限を有効にします脅威検知アプリケーションを管理するユーザにこの権限セットを割り当てます。脅威検知アプリケーションを使用する各ユーザプロファイルの [タブの設定] を編集し、5 つのタブの表示を指定します。5 つのタブは、[セッションハイジャックイベントストア]、[クレデンシャルスタッフィングイベントストア]、[レポート異常イベントストア]、[API 異常イベントストア]、[脅威検知フィードバック] です。たとえば、システム管理者は通常 UI を使ってあらゆる機能にアクセスするため、システム管理者プロファイルでは 5 つのすべてのタブの表示を [デフォルトで表示] に設定します。脅威検知管理者プロファイルを作成した場合も、同じ表示を設定します。標準ユーザがフィードバックを表示できないようにする場合は、標準ユーザプロファイルの [脅威検知フィードバック] の表示を [タブを隠す] に設定します。[設定] で、[クイック検索] ボックスに「アプリケーションマネージャ」と入力し、Lightning Experience アプリケーションマネージャに移動します。脅威検知アプリケーションの右側にあるドロップダウンボックスで [編集] を選択し、このアプリケーションを編集します。もし [タブの選択] セクションに手順.5で設定した 5 つのタブが含まれていない場合は、適宜 [選択されたタブ] へ移動させます。[プロファイルへの割り当て] セクションで、脅威検知アプリケーションを表示可能にするプロファイルを選択し、設定を保存します。トランザクションセキュリティによる管理者への通知設定イベントモニタリングに含まれる「トランザクションセキュリティ」機能を利用し、脅威検知イベントを対象としたトランザクションセキュリティポリシーを作成することによって、新たに脅威検知イベントが生成された際に管理者に対してメールやアプリ内通知によってアラートをあげることができます。これにより、管理者は脅威検知アプリケーションの内容を確認し、新たな脅威が発生していないか定期的に確認する必要がなくなります。以下の例では、セッションハイジャックイベントが生成された際に、管理者に対してメール通知およびアプリケーション内通知を行うポリシーを条件ビルダーを用いて作成します。[設定] で、[クイック検索] ボックスに「トランザクション」と入力し、トランザクションセキュリティポリシーに移動します。(初回のみ) トランザクションセキュリティ画面の [有効化] ボタンをクリックします。新しくトランザクションセキュリティポリシーを作成するため、[新規] ボタンをクリックします。GUI操作でポリシーを作成していく場合は [条件ビルダー] を、予めトランザクションセキュリティ用に作成したApexクラスを指定する場合は [Apex] を選択します。（今回は条件ビルダーでの作成方法で解説します）ポリシー作成画面より、以下の条件を設定し、[次へ] をクリックします。[行動]：セッションハイジャックイベントストア[条件ロジック]：すべての条件に一致 (AND)※今回、設定する条件は1つのみなのでロジックどれでもOKです[条件]： “スコア” ＞＝ “0”アクション設定画面にて、以下の条件を設定し、[完了] をクリックします。[アクション]：なし[通知]：メール内通知・アプリケーション内通知のチェックをON[受信者]：脅威検知イベントの通知を受け取る管理者を指定[名前]：Session Hijacking Trigger Alert※作成したポリシーの内容が分かる名前を任意につけてください[状況]：有効ポリシーが有効な状態で、脅威検知機能により新たにセッションハイジャックイベントが生成された際には、以下のようなメール通知・アプリケーション内通知が指定された管理者に対して送信されます。各々のイベントが発生した場合、前述の通りクレデンシャルスタッフィングおよびセッションハイジャックについては既にシステムによって自動で対処は完了していますが、再度同様の攻撃を受け続けないためにも、該当ユーザに対して使いまわしているパスワードがないかどうかのヒアリングや、利用端末に対するウイルスチェックの実施などを行うことで、根治対処を行うことも重要となります。同様に、レポートの異常やAPI 異常についても該当ユーザへのオペレーション内容の確認やイベントモニタリングで生成されたログの確認を行うことで本当に脅威となるアクティビティであったかどうか確認を実施します。これらの調査については、以下のヘルプページが用意されておりますので合わせてご参照ください。セッションハイジャックの調査クレデンシャルスタッフィングの調査レポートの異常の調査API 要求の異常の調査機械学習アルゴリズムへのフィードバック脅威検出イベントが生成された後は、その検知内容が適切であったかどうか管理者によって機械学習アルゴリズムに対してフィードバックを送信することができます。不正なアクセスを正しく検知できていた（正検知）という場合と、通常の業務内容などによって発生した検知であり、不正なアクセスではなかった（誤検知）という場合の両方のケース対して送信が可能になっており、こまめにフィードバックを行うことで脅威検出機能の検知精度を高めることができます。詳細はこちらのヘルプをご確認ください。フィードバックを送信したい、誤検知となった脅威検出イベントへアクセスし、右上の [Provide Feedback] をクリックします。指定した脅威検出イベントの内容について Malicious(悪意あり)、Suspicious(疑わしい)、Not a Threat(脅威ではない)、Unknown(不明)の4つから選択し、保存ボタンを押してください。学習ツールHelp - 脅威検知Help - 脅威検知イベントの表示とフィードバックの提供Help - 拡張トランザクションセキュリティTrailhead - 拡張トランザクションセキュリティまとめ脅威検知機能により、Salesforce組織に発生した脅威を顕在化させることができ、組織の管理者はこれらに気付くことで追加の対応や対策を検討するきっかけを得ることが出来るようになります。ただし、本機能の活用に当たってはログの有効化やトランザクションセキュリティポリシーの活用など、いくつか事前に準備を行っておくことが重要となりますので、本記事をきっかけに対応を進めていただけると幸いです。
Trusted Services

Shield

ログの取得方法

この記事で学べることイベントモニタリングに含まれる2種類のログの違いリアルタイムイベントモニタリングのログの取得方法イベントログファイル(EventLogFile)のログの取得方法イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントログファイル(EventLogFile)：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとは2種類のログは、取得方法が異なりますので、それぞれのログの取得方法について説明します。リアルタイムイベントモニタリングのログ取得リアルタイムイベントモニタリングでは、イベントデータをストリーミング視聴したり、Salesforceオブジェクトに保存してクエリしたりすることができます。保存イベントの多くは、大量データの最大6か月間(認証系ログは10年間)の保存に適したSalesforce Big Objectが対応します。Big Objectではデータが Salesforce ネイティブとして保存されるため、アクセスしてレポートやその他の用途に使用できます。一部の保存イベント（脅威検知イベントなど）は、標準 Salesforce オブジェクトが対応します。リアルタイムログの記録開始については以下の記事を参照してください。ログの記録開始リアルタイムログの取得に必要な権限の設定[設定] から、次のいずれかの操作を実行します。[クイック検索] ボックスに「権限セット」と入力し、[権限セット] を選択します。[クイック検索] ボックスに「プロファイル」と入力し、[プロファイル] を選択します。権限セットまたはプロファイルを選択します。権限セットとプロファイルのどちらを使用するかに応じて、次のいずれかの操作を実行します。権限セットまたは拡張プロファイルユーザインターフェースで、権限を選択します。[設定の検索] ダイアログボックスに、「リアルタイムイベントモニタリングデータの表示」と入力します。[編集] をクリックし、オプションを選択して、[保存] をクリックします。「アプリケーションのカスタマイズ」権限についても上記の手順を繰り返します。元のプロファイルユーザインターフェースで、プロファイル名を選択し、[編集] をクリックします。トランザクションセキュリティポリシーを作成する予定の場合は、[リアルタイムイベントモニタリングデータを表示] と [アプリケーションのカスタマイズ] を選択します。[保存] をクリックします。リアルタイムイベントモニタリングを有効にするのに加えて、リアルタイムイベントオブジェクトに対するユーザ権限を設定します。リアルタイムイベントモニタリングオブジェクトには機密データが含まれる場合があります。リアルタイムログのストリーミングログの取得ここでは“Streaming Monitor”を利用してストリーミングイベントを確認する方法を紹介します。Streaming MonitorはSalesforceから提供している管理パッケージとなり、誰でも無償でご利用いただけますがサポートの対象外です。AppExchangeの“Streaming Monitor”ページより、パッケージをインストールしてください。https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000FYEEWUA5&tab=eパッケージが正常にインストールされると、アプリケーションランチャーにて“Streaming Monitor”が表示されます。Streaming Monitorページにアクセスし、[Subscribe to a channel] → [Monitoring events] → [確認したいイベント]を順に選択し、[Subscribe]ボタンを押します。（Relay optionはデフォルトのままでOK）確認したいイベント分だけ、No.3の手順を繰り返します。[Subscriptions]カラムに、指定したイベントログが表示されていることを確認します。（ここでは、一例として“LightningUriEvent”と“ReportEvent”をSubscribeしています）この状態で実際のイベントが発生すると、画面上にキャプチャされたイベントログがグラフに表示されます。グラフ上の該当ログをクリックすることで、実際のログの内容を確認することができます。リアルタイムログのストレージログの取得リアルタイムイベントモニタリングの保存イベントの多くは、大量データの最大6か月間の保存に適したSalesforce Big Objectに保存されます。保存されたログデータはデータローダを用いてダウンロードすることが可能です。データローダは、データを一括でインポートまたはエクスポートするためのクライアントアプリケーションです。データローダのインストールや利用方法の詳細は『データローダガイド』をご参照ください。データローダを開きます。[Export (エクスポート)] をクリックします。アーカイブされた活動レコードと論理削除されたレコードもエクスポートする場合は、代わりに [Export All (すべてをエクスポート)] をクリックします。Salesforceユーザ名とパスワードを入力し、[ログイン] をクリックします。ログインしたら、[次へ] をクリックします。オブジェクトを選択します。オブジェクト名がリストに表示されない場合は、[すべてのオブジェクトを表示] を選択して、アクセス可能なオブジェクトをすべて表示します。データのエクスポート先とするCSVファイルを選択または新規作成します。[次へ] をクリックします。データエクスポート用のSOQLクエリを作成します。[完了] をクリックし、[はい] をクリックして確認します。[View Extraction (抽出を表示)] をクリックして CSV ファイルを表示するか、[OK] をクリックして閉じます。イベントログファイル(EventLogFile)のログについてイベントログファイルのログは、“EventLogFile”という名前の専用オブジェクトに格納されます。EventLogFileオブジェクトではイベント種別、対象日（または対象時間）ごとに1件のレコードが作成され、ログデータがBase64に符号化されてLogFile列に格納されています。EventLogFile でサポートされているイベント種別イベントログファイルの保存期間はSpring’24のアップデートにより30日間から1年間に拡張されました。この保管期間の拡張を有効にするには、[イベントモニタリング設定] より、[イベントログファイルを保持]にチェックを入れてください。イベントログファイルの取得に必要な権限の設定[設定] から、次のいずれかの操作を実行します。[クイック検索] ボックスに「権限セット」と入力し、[権限セット] を選択します。[クイック検索] ボックスに「プロファイル」と入力し、[プロファイル] を選択します。権限セットまたはプロファイルを選択します。権限セットとプロファイルのどちらを使用するかに応じて、次のいずれかの操作を実行します。権限セットまたは拡張プロファイルユーザインターフェースで、権限を選択（または新規作成）します。[設定の検索] ダイアログボックスに、「イベントログファイルを参照」と入力します。[編集] をクリックし、オプションを選択して、[保存] をクリックします。「API の有効化」権限についても上記の手順を繰り返します。元のプロファイルユーザインターフェースで、プロファイル名を選択し、[編集] をクリックし、[イベントログファイルを参照] と [API の有効化] を選択します。[保存] をクリックします。イベントログファイルのダウンロードイベントログファイルはSalesforceオブジェクトのレコードであるため、さまざまな方法でダウンロードできます。イベントログファイルブラウザーデータローダーcURLスクリプトPythonスクリプトetcここではイベントログファイルブラウザーを使用し、base64デコード済みのcsvファイルを直接ダウンロードする方法を紹介します。組織にログインします。[設定] から、クイック検索で“イベントモニタリング”と入力し、[イベントログファイルブラウザー] を選択します。検索する日付範囲を入力します検索するイベント種別を入力します間隔（すべて / 毎日 / 1時間ごと）を入力します[適用] をクリックしますこのリストには、指定した日付や時間、イベント種別に該当するイベントログファイルが表示されます。これらのログをブラウザアプリケーションで直接開くことはできませんが、csvファイルとして手元にダウンロードすることができます。右端の▼マークのアイコンをクリックして、[csvファイルとしてダウンロード] を選択します。今回は一例としてLightningページビューイベントのログファイルをダウンロードします。このファイルをスプレッドシートで開いて内容を確認します。PAGE_URL項目でアクセスしたページやレコードを示すURLを、USER_ID項目でユーザのIDを確認することが可能です。学習ツールTrailhead - リアルタイムイベントモニタリングTrailhead - イベントモニタリング動画 - イベントモニタリング設定動画_基礎編（ログの有効化と取得）まとめイベントモニタリングで取得できる二種類のログ（リアルタイムログおよびイベントログファイル）の取得方法はそれぞれ異なります。今回はストリーミングや取得方法の一例をご紹介しました。ご利用開始後、適切な方法でログを取得しイベントモニタリングを最大限にご活用ください。