Spring'20新機能:拡張トランザクションセキュリティポリシーを試してみよう！

# はじめに
　今回は、『Salesforce 開発者によるブログ投稿キャンペーン』に参加するブログとして、Spring'20の新機能の[拡張トランザクションセキュリティポリシー](https://releasenotes.docs.salesforce.com/ja-jp/spring20/release-notes/rn_security_em_txn_sec_critical_update.htm)について書こうと思います。[拡張トランザクションセキュリティポリシー](https://help.salesforce.com/articleView?id=enhanced_transaction_security_policy_types.htm)はリアルタイムモニタリングの機能の一つでWinter'20に提供された機能です。
　興味を持った理由は、私の関わったプロジェクトで、会社提供のPCやモバイル端末を利用して社内ネットワークも含めた複数の場所からSalesforceにアクセスした際に、お客様のセキュリティ要望として、ユーザの操作を監視して、ブロックや二要素認証、追跡ができる仕組みがないのかと問合せを頂くことがいくつかありました。
　ログインフローとセッションベースの権限で動的に権限を変更すること以外に、各ユーザの操作をリアルタイムに監視し制御する機能としてこの機能を注目しました。

# トランザクションセキュリティポリシーとは
目的やロジックについては以下のッ通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/c288330e-cc14-d3c6-d42a-abead833dff1.png)

# ポリシーの設定流れ
ポリシーの設定の流れは以下の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/a588cb80-044e-4458-e299-e56247a67f11.png)

# 活用のユースケース
　[条件ビルダーの使用例](https://help.salesforce.com/articleView?id=enhanced_transaction_security_cb_examples.htm&type=0)を読んで、ユースケースを考えました。

## 条件ビルダー
固定文字列で条件を設定する場合のユースケースです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/5a7aec0d-f342-7223-b0a9-50da03d89722.png)

## Apex
[高度な実装例](https://help.salesforce.com/articleView?id=enhanced_transaction_security_policy_apex_examples.htm&type=0)と[非同期通信](https://releasenotes.docs.salesforce.com/ja-jp/winter20/release-notes/rn_security_em_asynccondition.htm)([AsyncConditionインターフェース](https://developer.salesforce.com/docs/atlas.ja-jp.222.0.apexcode.meta/apexcode/apex_interface_TxnSecurity_AsyncCondition_interface.htm#apex_interface_TxnSecurity_AsyncCondition))から、ユースケースを作成しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/255d79aa-5f11-cb50-baf2-545a574962af.png)

## トリガーされるイベント情報
トリガーするイベントオブジェクトを確認するために、Salesforceのヘルプでトランザクションポリシーが動かない場合のトラブルシューティングのやり方として紹介されていた『[イベントマネージャ](https://help.salesforce.com/articleView?id=event_monitoring_monitor_events_with_event_manager.htm)』を利用して、レコードが作成されるタイミングを”〇”、”×”、”-”で表しています。”〇”はレコードが作成されます。”×”は個人的に確認対象としてましたがレコードが作成されませんでした。”-”は対象外です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/16a02b80-e023-ed4d-14f0-775583224417.png)

# トリガーされるイベント情報
各アプリケーション毎に登録されるイベント情報を一覧にしました。

**ログインイベント**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/60ba3254-96d2-426a-08b4-6ca7e062df02.png)

**APIイベント**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/64d2b0ad-03ed-ded6-2d7a-85a7f869196a.png)

**レポートイベント情報**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/3588f294-3e25-e7f9-1354-178b1fa4f722.png)

**リストビューイベント情報**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/33da1aa8-f901-e2fd-1a68-190c0acc9841.png)

確認用のSOQLを記載します。開発者コンソールで確認することができます。

``` 
# APIEvent
SELECT Username, UserId, ApiType, ElapsedTime, Operation, Platform, QueriedEntities, Query, SourceIp, UserAgent, RowsProcessed, SessionLevel,  ApiVersion, Application, Client FROM ApiEvent
# ListViewEvent
SELECT EventDate, Username, AppName, ColumnHeaders, DeveloperName, EventSource, ListViewId, Name,  OrderBy, OwnerId, QueriedEntities, RowsProcessed, Scope, NumberOfColumns, SessionLevel, SourceIp, UserId FROM ListViewEvent
# LogingEvent
SELECT EventDate, Username, UserType, Application, Browser, Country, LoginUrl, Platform, SourceIp, SessionLevel,  TlsProtocol, UserId,  ApiType, ApiVersion FROM LoginEvent
# ReportEvent
SELECT EventDate, Username, Name, DashboardId,  ReportId, EventSource, ColumnHeaders, Format, IsScheduled, NumberOfColumns, Operation, OwnerId, QueriedEntities, RowsProcessed, Scope, SessionLevel, SourceIp, UserId, DashboardName, Description FROM ReportEvent
```

# アクションの実行結果
　条件ビルダーのアクションで指定できる『ブロック』と『２要素認証』について、ログイン時と操作中の２つの操作で動作を確認しました。
　
<img width="500" alt="アプリケーションアクション一覧" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/fbbe18f1-a1dd-3d32-6041-9484a7a8c402.png">

×となっている結果について
Salesforceモバイルアプリケーションのログイン時に、 Salesforce Authenticatorを利用した二要素認証後、トランザクションセキュリティーポリシーによりブロックされ、ログイン画面が再表示する事象が発生したため、×としております。（エビデンスは最後に記載。）


## 実行結果確認（ログインイベント）
　ログイン時にログインイベントでブロックすると下記の画面が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/7827c8ed-c8c1-f9cf-98be-d36e76d4d7af.png)

## 実行結果確認（レポートイベント）
　レポート実行時にレポートイベントでブロックすると下記の画面が表示されます。また、２要素認証要求アクション選択時に、２要素認証を利用せずにログインした場合、レポートを実行すると下記の画面が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/ae9f76d4-9499-56f1-8765-b5dec8152c31.png)

## ログインイベントの二要素認証
　ログイン時に２要素認証でログインしてもホーム画面が表示されずに、ログイン画面が表示されます。
<img width="700" alt="ログインイベント二要素認証" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/d575c2de-0615-a55b-baec-20c743d9a662.png">

**ログインイベントの確認：ログイン履歴**
　『Salesforce Authenticator』で認証後、リモートサクセスする際にトランザクションセキュリティでブロックされていることを確認しました。　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/75354bb9-707c-49aa-bc88-6e07d1c5a5a5.png)
　MacOSのPCログインとIPhoneのSalesforceモバイルアプリケーションのログインイベントのレコード検索結果です。Salesforceモバイルアプリケーションの場合、一連のログインの流れの中で１回リクエストの回数が多いのが確認できます。
　別のアプリケーションで最後にアクセスしているものがトランザクションポリシーに抵触していると考えています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76270/b6849c5f-4253-6034-c639-60ef92af7d74.png)

# まとめ
　これまで機能概要や活用方法について説明しました。
　この機能はＵＩで簡単に設定することができ、ユーザの操作をリアルタイムに監視し制御することができます。
　Winter’20、そしてSpring’20と連続してアップデートがあったのは、こうしたユーザの監視や制御についてセキュリティーの要望が高まっているからではないでしょうか？
　これをきっかけに、このようなお客様からの要件が出てきた際には、選択肢の一つとして検討して頂けたらと考えております。
　では！