4アイズレビューは、解決が有効になる前に、独立した2人目の承認を追加します。リスクの高い調査に対する職務分掌の標準的な統制です。
設定方法
メーカーブループリントで、4アイズレビューにチェッカーブループリントを設定します。このフィールドを設定すると、そのメーカーブループリントで4アイズレビューが有効になります。別途トグルはありません。
仕組み
- メーカーブループリントの担当者が、通常どおりケースを解決します（誤検知または実際の脅威を選択し、必要に応じてメモを追加します）。
- ケースはクローズされず、ステータスはオープンのままです。提案された解決内容は保留され、ケースはチェッカーブループリントのキューに移動します。ケースのタイムラインには
Submitted for approvalが記録されます。
- チェッカーはケースの概要タブを確認します。概要タブには、承認と却下のアクションを含む二重統制のバナーが表示されます。
- 承認すると、保留中の解決内容が適用されます。ケースは元の解決内容とメモのまま解決済みになり、解決内容を提出した担当者の対応として記録されます。タイムラインには
Approval granted、続いてResolvedが記録されます。
- 却下すると、保留中の解決内容は取り消され、ケースはメーカーブループリントに戻ります。タイムラインには
Approval rejectedが記録され、メーカーブループリントの担当者に通知が送られます。
解決内容を提出した担当者本人は、その解決内容を承認または却下できません。この制限はサーバー側で適用されます。承認または却下しようとすると403が返されます。（承認待ちの解決内容がないケースを承認または却下しようとすると409が返されます。）
チェッカーの指名
ケースを解決する担当者は、ケース解決APIのcheckerフィールドで、解決内容を承認する必要があるメンバーを指名できます。
指名後は、そのメンバーのみが解決内容を承認または却下できます。それ以外のユーザーは、APIキーを含めて403を受け取ります。
ケースのcheckerフィールドには、解決内容が承認、却下、または新しいレビューのために差し戻されるまで、指名されたメンバーが表示されます。
チェッカーが指名されていない場合、解決内容は前述のとおりチェッカーブループリントのキューで待機します。
指名されるチェッカーは、そのアプリケーションのケースへのアクセス権を持っている必要があり、解決内容を提出した担当者本人であってはなりません。
エビデンスが変更された場合
チェックリストの回答を変更した場合、またはリンクされた認証や取引を追加または削除した場合、保留中の判定は取り消され、ケースは元のレビューポリシーに戻ります。
アクティビティのタイムラインには新しいレビュー判定が必要であることが記録され、以前の提案は監査イベントに保存されます。
2人目の担当者が承認できるようにするには、レビュアーが更新されたエビデンスを確認し、新しい判定を提出する必要があります。
チェックリストに同じ回答を繰り返し入力しても、保留中のレビューは取り消されません。
承認時には、リンクされたソースエビデンスとレビューのために提出された内容との照合も行われます。
認証ステータスの変更、書類フィールドの修正、取引エビデンスの変更、またはソースを利用できない場合は、409で承認がブロックされます。
Fraud Checkを通じてリンクされたグローバルネットワークのエビデンスへのアクセスを失った場合も、新しいレビューが必要です。
Rejectを使用してケースを作成者に戻し、更新されたエビデンスを確認してから新しい判定を提出してください。
ソースレコードを開くことや、ケースに内部メモを追加することだけでは、変更のないレビューはブロックされません。
提出されたエビデンスを検証できない場合は、承認の前に新しいレビューが必要です。
注意事項
- レビュー要件はケースがオープンされた時点で保存されます。
チェッカーのキューに移動しても、その後のポリシー編集によってこれらの要件が置き換えられることはありません。
- 1つのケースで同時に承認待ちにできる解決内容は1件のみです。解決内容が承認待ちの間は、追加情報の要求（ユーザー待ち）はブロックされます。
- 4アイズレビューは解決メモの必須化と組み合わせて使用できます。最もリスクの高いブループリントで両方を有効にすると、根拠の記録と2人目のレビュアーの両方を必須にできます。
はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴