はじめに
こんにちは、セキュリティチームのむろです。
先日、Netskopeから、ステアリング構成とプロキシ処理を分離する「Decoupled Proxy」への移行通知が届きました。
「通知メールには自動移行と書いてあるけど、管理者は何を確認すれば良いの？」という方向けに、通知メールと公式ドキュメントをもとに対応のポイントを整理します。
通知を受けて「まず何をすれば良いか」を確認したい方は、右の目次を参照し、「管理者がやらなければいけないこと」から読んでみてください。
今回の方式移行（変更）について詳しく知りたい方は、最初の概要から順にご覧ください。
本ブログの参照元
- Netskope公式ドキュメント：Decoupling Steering Configuration from Proxy Processing
- 通知メール：「重要：今後の移行：プロキシ処理からのステアリング構成の分離」の内容
仕様は変更される可能性があるため、対象テナントへの最新の案内もご確認ください。
はじめにまとめ
- 「Exceptions」に登録したDomainやCategoryなどの既存の除外設定は、Netskopeが自動でSSLポリシーとRTP（Real-time Protection）ポリシーに複製します。管理者が手動で作り直す必要はありません。
- 通知メールで対象テナントと移行日を確認します。
To be updatedなら、日程確定の連絡を待ちます。
- 未適用の設定変更（Pending）が残っていると移行されません。移行前に変更内容を確認し、通常の承認手続きを経て適用します。
- 非標準ポート（TCP 80・443以外のポート）の通信であることを理由にした暗黙的なブロックはなくなり、移行後はRTPポリシーで許可・ブロックを判断します。
- ログの
unallowed-custom-portを確認し、遮断を続けたい通信には移行前にブロック設定を用意します。
- ログの
今回の移行で起きること
a）具体的に移行前と移行後で何が変わるのか
今回の移行前の方式が「Coupled Proxy（従来の方式）」、移行後の方式が「Decoupled Proxy（移行後の方式）」と呼ばれています。
この方式の移行によって、Steering Configurationの「Exceptions」の扱われ方が変更になります。
| 比較項目 | Coupled Proxy（従来の方式） | Decoupled Proxy（移行後の方式） |
|---|---|---|
| Client側の通信除外 | 「Exceptions」に一致すると、Netskopeを経由せず直接通信する | 「Exceptions」に一致すると、Netskopeを経由せず直接通信する |
| Proxy側のSSL復号 | 「Exceptions」に登録したDomainやCategoryなどの例外に一致すると、SSL Decryptionポリシーの評価が省略され、復号しない | 「Exceptions」は参照せず、SSL Decryptionポリシーで復号の要否を判断する |
| Proxy側のアクセス制御（RTP） | 「Exceptions」に登録したDomainやCategoryなどの例外に一致すると、RTPポリシーの評価が省略され、アクセス制御を行わない | 「Exceptions」は参照せず、RTPポリシーで許可・ブロックを判断する |
Coupled Proxy（従来の方式）
従来は、「Exceptions」に登録した一部の例外が、Client側の通信除外とProxy側の検査省略の両方に使われていました。この2種類の除外の管理が一部混在していた状態が Coupled です。
たとえば、「Exceptions」でDomain例外に example.com を登録した場合を考えてみます。
Clientが通信先を example.com と判別できれば、Domain例外に一致すると判断し、Netskopeを経由せず直接通信します。
一方、Clientが宛先ドメインを判別できなければ、Domain例外に一致すると判断できず、通信をNetskope Proxyへ送る場合があります。その通信を受けたProxyも「Exceptions」を参照し、宛先ドメインが example.com に一致すれば、SSL復号とReal-time Protection（RTP）のアクセス制御を省略します。
公式ガイドでも、Clientが宛先ドメインを識別できないために通信をProxyへ送るケースが挙げられています。
Decoupled Proxy（移行後の方式）
移行後は、Client側の通信除外とProxy側の処理を、それぞれ別の設定で管理します。この管理場所の明示的な分離が Decoupled です。
先ほどの example.com の例で、ClientがDomain例外に一致すると判断した場合は、引き続きNetskopeを経由せず直接通信します。
一方、通信がProxyへ届いた場合は、「Exceptionsに登録されているから検査を省略する」とは判断しません。
「Exceptions」は参照せず、「SSL Decryption」で復号の要否を、「Real-time Protection」で通信の許可・ブロックを判断します。
今回の自動移行では、従来のプロキシバイパスを再現するため、Domain例外に対応する次のポリシーが自動生成されます。
- SSL Decryption：
Do Not Decryptで復号を除外する。 - Real-time Protection：
Allowで通信を許可する。
移行後に除外を追加・変更するときも、Client側で直接通信させたいのか、Proxyへ届いた通信の復号やアクセス制御を変更したいのかを分けて設定することになります。
b）既存の除外設定で移行が必要なものは、自動でポリシーに複製される
この方式への移行は、Netskope社によって自動で実施されます。
従来のプロキシバイパスを維持するため、既存の対象例外がSSL DecryptionのDo Not DecryptとRTPのAllowなどへ複製されます。
移行前に管理者が手動で作り直す必要はありません。
生成される設定名には ns-migrate という接頭辞が付きます。移行後に除外を追加・変更するときは、目的に応じて「Exceptions」「SSL Decryption」「Real-time Protection」で設定します。
対象はDomain、Category、Destination Location、Source Location、Source Countryの5種類です。
ただし、既定のDestination Location例外であるBogon NetworksとLocal IP address rangeは複製対象から除外されます。
Certificate Pinned Applications、Applications、Service & Destination Profileは今回のプロキシバイパス複製の対象ではありません。証明書ピンニングアプリケーションのTunnel + Bypassも変更されません。
c）非標準ポートの暗黙ブロックはなくなる
ここでの非標準ポートは、TCP 80と443以外のポートを指します。
従来、必要な非標準ポート設定がない状態でプロキシへ届いた非標準ポートの通信は、暗黙的にブロックされていました。この場合、Transaction Eventに unallowed-custom-port が記録されます。
移行後は、この暗黙ブロックがなくなり、設定されたRTPポリシーに従って処理されます。
このブロック動作は、自動移行で再現されません。
「非標準ポートの通信がすべて無条件に通る」という意味ではなく、ポート番号を理由にした暗黙ブロックがなくなる、という変更です。Client側の非標準ポートの構成要件は変わりません。
管理者がやらなければいけないこと
1）通知が届いたら、まずやること
既存の例外を手動で作り直すことから始める必要はありません。
まずは、日程の確認、非標準ポートの対応判断、確認する通信の選定を進めましょう。
Pendingの解消など、移行前に完了させる作業は次の「移行日前までにやっておくこと」にまとめます。
1-1）対象テナントと移行予定日を確認する
通知メールに記載されたテナントURLと移行予定日を確認します。
複数テナントを管理している場合は、どのテナントの案内なのかも確認してください。
通知に記載された日程を管理者間で共有し、移行後の確認担当者を決めておきましょう。
なお、2026年10月のメール通知では、コンソールバナーの「136.0.0」は誤記で、段階的なロールアウトは2026年11月初旬のリリース143から開始すると案内されています。
具体的な移行日は、対象テナントへの最新のメール通知で確認してください。
Migration dateが「To be updated」だったら？
通知メールに、次のように記載されている場合もあります。
Tenant URL: https://XXXX.goskope.com
Migration date: To be updatedこれは、この通知では対象テナントの移行日がまだ確定していない、という案内です。
通知メール本文では、日程が確定したらあらためて連絡すると説明されています。
- Pendingな変更の棚卸し、
unallowed-custom-portの確認、遮断を維持する必要があるかの判断、確認担当者の選定などは進めておけます。 - Pendingは通常の変更手続きで解消し、日程確定後に移行直前の状態をあらためて確認しましょう。
- 要するに、「日程自体は続報待ち、準備は先に進める」で良いと思います。
1-2）非標準ポートの遮断を維持する必要があるか判断する
Skope ITのEvents & AlertsからTransaction Eventsを開き、ログの保持期間内の通信を次の条件で確認します。
Action Reason = unallowed-custom-port
該当する通信があれば、アクセス方式、宛先、ポートを確認し、移行後に許可されても良いか判断してください。
- 許可されても良い場合
- この暗黙ブロックを維持するための追加設定は不要です。
- 移行後はRTPポリシーに従って処理されます。
- 遮断を続けたい場合
- 移行前に明示的な制御が必要です。
- 準備については、次の「移行日前までにやっておくこと」で説明します。
- 該当する通信がない場合
- 確認した期間では暗黙ブロックの利用を確認できなかった、という結果です。
1-3）移行後に確認する通信を決めておく
移行後に同じサイトへ同じ経路でアクセスして確認できるよう、移行前にプロキシバイパスされている業務サイトをいくつか選び、宛先とアクセス方式を控えておきます。全通信を一覧化する必要はありません。
公式ガイドでは、ステアリング例外によるプロキシバイパスをTransaction Eventsで識別する方法が案内されています。
SSL Bypass = Yes
SSL Bypass Reason = Steering Exception - [構成名][構成名]には、対象のSteering Configurationの名前が入ります。たとえば構成名が Default Tenant config なら、Steering Exception - Default Tenant config と表示されます。検索するときは、実際の構成名に置き換えてください。
Skope ITで確認できるのはプロキシ側のバイパスです。端末が直接宛先へ送ったステアリングバイパスは、このイベントには出てきません。
移行後は、選んだサイトをこれまでどおり利用できるか、新しいログで ns-migrate のSSL・RTPポリシーが適用されているかを確認します。手順は「4-3）除外設定している通信先が、期待どおりに動作するか確認する」で説明します。
1-4）まずやることのチェックリスト
- 通知メールで対象テナントと移行予定日を確認し、管理者間で共有する。
To be updatedの場合は続報を待ちつつ、事前準備を進める。 unallowed-custom-portを確認し、遮断を維持する必要があるか判断する。- 移行後の確認担当者と、確認する代表的な通信を決める。（必須ではなく推奨事項）
2）移行日前までにやっておくこと
通知を受けて確認・判断した内容をもとに、移行前に必要な作業を完了させます。
2-1）Pendingな設定変更を解消する
全テナント共通の前提条件は、未適用の設定変更がないことです。
Pendingが残っているテナントは移行されません。
未適用の変更を確認し、通常の承認・変更手続きを経てApplyします。内容を確認せず、Pendingをなくすためだけに適用するのは避けましょう。
非標準ポートの制御など、事前に設定を追加した場合も、未適用のまま残さないようにします。
〜 参照元 〜
2-2）非標準ポートの遮断を維持する場合は、明示的な制御を準備する
前のセクションで「遮断を続ける」と判断した場合は、移行前に明示的なブロック設定を準備します。
公式ガイドの「Non-Standard Port Management」ではService Profileによるポート単位の制御が案内されています。
移行後に自動生成されるRTP AllowはHeader Policiesの先頭に配置されるため、ブロック設定と条件が重なる場合は、移行後にも適用ポリシーと配置を確認してください。
〜 参照元 〜
2-3）直前の設定変更と、当日の確認体制を整える
移行直前から完了確認まで設定変更を控える時間帯を決め、管理者間で共有しておくことをおすすめします。
意図的に除外設定をしているシステムやURLのうち、当日に動作確認する対象を整理しておきましょう。
任意の備えとして設定保存やスクリーンショットを残す場合は、直前の状態を記録します。
具体的な方法はAppendixにまとめています。
3）移行日の当日になるとどうなるか
3-1）Netskope側で設定が自動作成・適用され、Decoupled Proxyモードへ切り替わる
公式ガイドでは、移行当日はNetskope側で次の処理が自動実行されると説明されています。
- 対象の既存バイパスを、SSL Do Not Decryptポリシーへ複製する。
- 対象の既存バイパスを、RTP Allowポリシーへ複製する。
- 設定を適用する。
- Decoupled Proxyモードを有効にする。
あわせて、例外の種類に応じたDestination ProfileやCustom Categoryが作成されます。
SSLポリシーは既存のSSL Decryptionポリシーの先頭、RTPポリシーはHeader Policiesの先頭に配置されます。
ステアリング構成は一覧の上から評価され、最初にグループ／OU条件に一致した構成が適用されます。
どの構成にも一致しない場合は、Defaultの構成が適用されます。
この適用順を再現するため、生成ポリシーに除外条件が付く場合があります。
4）移行された直後に何を確認するのか
移行後は、設定が作成・適用されたことと、通信が想定どおりに処理されることを確認します。
以下は公式ガイドをもとにした確認ポイントです。
4-1）Audit Logで、設定の作成・適用を確認する
Audit Logで、移行による設定の作成・適用を確認します。これは設定変更の記録です。通信の処理結果は、後述のTransaction Eventsで確認します。
4-2）自動生成されたポリシーを確認する
「SSL Decryption」と「Real-time Protection」のポリシー一覧で、ns-migrate で始まるポリシーを確認します。
- 対象条件が、移行前の対象例外に対応しているか。
- SSL側のアクションがDo Not Decrypt、RTP側がAllowになっているか。
- SSLポリシーは既存一覧の先頭、RTPポリシーはHeader Policiesの先頭に配置されているか。
グループ／OU条件には、「3-1」で説明した構成の適用順を再現するための除外条件が付く場合があります。
ただし、Enhanced OU/Group Exceptionsが無効なテナントでは、従来のバイパス動作を再現するため、自動生成ポリシーにグループ／OU条件は設定されません。
4-3）除外設定している通信先が、期待どおりに動作するか確認する
意図的に除外設定している通信先へ、普段と同じ端末・アクセス方法で接続し、移行後も期待どおりの除外動作になっているかを確認します。
- Netskopeを経由せず直接通信する想定なら、その通信経路が維持されているか。
- Proxyを経由し、SSL復号やアクセス制御を除外する想定なら、復号されず、通信が許可されているか。
- 業務サイトやアプリケーションを、これまでどおり利用できるか。
Proxyを経由する通信は、ログで除外動作を裏付ける
接続できたことだけでは、期待した除外動作になっているとは限らないため、細かな除外挙動まで確認したい場合はログを確認します。
Proxyを経由する通信は、Skope IT › Events & Alerts › Transaction Eventsで、動作確認時に新しく記録されたイベントのSSL Bypass Reason、SSL Policy、Real-time Protection Policy、RTP Actionを確認します。
端末から宛先へ直接通信するステアリングバイパスは、Transaction Eventsには出てきません。ログがないことだけで直接通信できていると判断せず、端末側で通信経路を確認してください。
以下は、公式ガイドに示されている、従来のステアリング例外によるプロキシバイパスを自動生成ポリシーで再現した場合のログ例です。
過去のログが書き換わるのではなく、移行後の通信では適用される設定とログの表示が変わります。
移行前
SSL Bypass Reason: Steering Exception - [構成名]
RTP Action: NotChecked移行後
SSL Bypass Reason: SSL Do Not Decrypt Bypass Policy Matched
SSL Policy: ns-migrateで始まるポリシー名
Real-time Protection Policy: ns-migrateで始まるポリシー名
RTP Action: AllowSSL側のDo Not DecryptとRTP側のAllowが適用されていることを確認し、期待したプロキシ側の除外動作が維持されているかを裏付けます。
なお、移行前を含む期間で検索すれば古いイベントも残るため、過去の Steering Exception のログがあるだけで移行失敗とは判断しないように注意します。
4-4）非標準ポートの遮断を維持する設定をした場合は、ブロックを確認する
事前にブロック設定を追加した場合は、対象通信が意図したポリシーで遮断されるかを確認します。
自動生成されたRTP Allowと条件が重なる場合は、ポリシーの配置と実際の適用結果も確認してください。
4-5）もしも、切り戻しが必要になったら
確認した結果、ポリシーの調整が困難で切り戻しの判断をするケースも考えられます。
公式ガイドでは、次の切り戻し手順が案内されています。
- 契約しているNetskope向けのサポート窓口へ、Coupled Proxyモードへの切り戻しを依頼する。
- モードが戻ったことを確認してから、自動作成されたSSL DecryptionとRTPポリシーを無効化する。
先に ns-migrate ポリシーだけを無効化するのは、元の動作に戻すこととは違います。
順序を間違えないよう、サポートと連携してください。
〜 参照元 〜
5）今回の移行日以降はどう運用するのか
5-1）新しい除外設定は、Client側とProxy側を分けて設定する
移行後も、Clientが通信をNetskopeへ送るかどうかはステアリング構成で管理します。
ただし、新しいステアリング例外を追加しただけでは、プロキシ側のバイパス設定にはなりません。
Proxyへ届く通信を従来のバイパス相当にしたい場合は、SSL DecryptionとRTPポリシーを別途検討する運用になります。
「Netskopeへ送らない」のか、「送るけど復号しない」のか、「アクセス制御も含めてバイパスしたい」のかを分けて登録する必要があります。
Source LocationとSource Countryは、ステアリング例外の選択肢からなくなります。
この2種類はもともとClientでは評価されず、Proxy側でのみ使われていたためです。
既存の動作は生成されたポリシーで再現されるので、今後の変更手順もポリシー側に合わせて更新します。
5-2）自動生成ポリシーは、段階的に見直す
ns-migrate は、従来のバイパス動作を維持するための設定です。
整理したくなっても、確認せずに削除・無効化するのは避けましょう。
Netskopeは、不要と判断したポリシーについて、削除する前に数日から数週間無効化して様子を見ることを推奨しています。
Decoupled Proxy（移行後の方式）になると何が嬉しいのか
管理者にとっては、「Proxyでなぜ検査が省略されるのか」を、ポリシー一覧と通信ログで追いやすくなるのが大きなポイントです。
公式ガイドに記載された変更を、運用の観点で整理すると次のようになります。
a）「なぜ検査されないのか」が、ポリシーで分かる
従来は、「SSL Decryption」に復号するポリシーを設定していても、その前にDomainやCategoryなど、Proxyが評価する例外に一致すると、復号もRTPのアクセス制御も省略されていました。
そのため、SSL・RTPポリシーだけを見ても、検査されない理由が分かりにくい場合がありました。
移行後は、Proxy側の検査省略も「SSL Decryption」のDo Not Decryptと「Real-time Protection」のAllowなど、明示的なポリシーで管理されます。
b）「復号しない」と「アクセスを許可する」を別々に決められる
たとえば、「このサイトはSSL復号をしないが、通信の許可・ブロックはRTPポリシーで判断したい」という場合です。
移行後は、「SSL Decryption」でDo Not Decryptを設定し、「Real-time Protection」では必要なアクセス制御を設定する、というように目的を分けて管理できます。
復号の除外を設定することと、RTPでAllowにすることを、ひとまとめに考える必要がなくなります。
なお、今回の自動移行では従来のバイパスを再現するため、対象例外からDo Not DecryptとAllowが生成されます。この例は、移行後に設定を追加・見直す際の考え方です。
c）通信ログから、適用されたポリシーをたどれる
従来のバイパスでは、Transaction Eventsに Steering Exception - [構成名] と記録され、RTP Actionは NotChecked でした。
公式ガイドの移行後の例では、SSL PolicyとReal-time Protection Policyに自動生成されたポリシー名が記録されます。
「どの設定で復号が除外され、どの設定で通信が許可されたか」を、ログから対応するポリシーへたどりやすくなります。
ざっくりいうと、筆者は除外の方式と設定場所が明確になり、より細かい除外設定が可能になると理解しています。
Appendix：保険でやっておくと良さそうなこと
ここからは、公式の移行手順・確認方法とは別に、筆者が保険として個人的に移行前に取得しておくと安心できる情報をまとめます。
APIによる設定保存、設定箇所のスクリーンショット、必要に応じたNAA（Netskope Advanced Analytics）の定期配信などです。
公式の移行要件ではないため、必要と判断された場合のみ実施すると良いと思います。
正直な話、筆者自身も取得したものの、使わないだろうなと思っていますが、心配性なので一応取っておこうかなという位置付けです。
REST API v1で、移行前の設定を保存しておく
画面だけでなく、APIで取得したJSONも残しておくと、移行前後の照合に使えます。REST API v1で保存する場合は、次のエンドポイントを利用します。
/api/v1/steeringconfiglist：ステアリング構成の名前とIDの一覧を保存する。/api/v1/steeringconfig：ステアリング構成の設定を保存する。
取得する際は、Settings › Tools › REST API v1で利用するトークンを確認します。
トークンはコマンドへ直接書かず、シェル変数から渡します。
コマンドにトークンを直接書くと、その値がシェルのコマンド履歴に残るためです。
以下の手順では、入力内容を表示しない read -rs でトークンを読み込み、履歴にトークンの値を残さないようにします。
保存したレスポンスは、status が success であること、構成名と構成数が一覧と対応していることを確認します。
ファイル名に取得日時を付け、アクセス権を絞った場所に保管すると良いでしょう。移行前後の比較に使う最終版は、設定変更を控える時間帯に入ってから取得するのがおすすめです。
ここでは、Netskope公式のAPIリファレンスに掲載されているREST API v1の steeringconfiglist と steeringconfig を使用します。
取得手順
- Netskope管理コンソール内のSettings › Tools › REST API v1 でトークンを確認する。
- 既存のトークンがある場合は安易に再発行しないこと。（既存の連携が止まるおそれがあるため）
- 管理者端末で、トークンをシェル変数に読み込み、ファイル名用の日付を設定する。
read -rs NS_TOKEN- 補足：上記を実行後に、ターミナルへREST API v1のトークンを貼り付け（入力内容は非表示）、Enterキーを押す。
DATE=$(date +%Y%m%d)
TENANT="<tenant>.goskope.com"- POSTで構成名とIDの一覧を保存する。
公式リファレンスではGETの例が掲載されていますが、ここではトークンをURLに含めないため、弊社環境で動作確認したPOSTで取得します。
ただし、以下のコマンドでは実行中のプロセス引数にトークンが含まれるため、POSTでもトークンの露出を完全に防げるわけではない点にご留意ください。
curl -sS --fail -X POST "https://${TENANT}/api/v1/steeringconfiglist" \
--data-urlencode "token=${NS_TOKEN}" -o "steeringconfiglist_${DATE}.json"- POSTで全構成の設定詳細を保存し、整形版も作る。
curl -sS -X POST "https://${TENANT}/api/v1/steeringconfig" \
--data-urlencode "token=${NS_TOKEN}" -o "steeringconfig_${DATE}.json"
jq . "steeringconfig_${DATE}.json" > "steeringconfig_${DATE}_pretty.json"statusがsuccessか、構成の数が一覧と一致するかを確認する。unset NS_TOKENでトークンを消し、JSONをアクセス権を絞った場所に保管する。
unset NS_TOKEN〜 参考資料 〜
APIだけでは不足しやすい箇所は、スクリーンショットで残す
APIのJSONだけで全項目を保存できるわけではありません。
不足する情報はスクリーンショットで補っておくと安心です。
特に、次の画面を移行前に記録しておくと良いと思います。
- Steering Configurationの一覧画面
構成名、適用先のグループ／OU、並び順が分かるように撮影します。
APIのJSONに適用先の情報が含まれているかも照合してください。
- 各構成のExceptionsタブにあるCategory例外
Exception TypeをCategoryに絞り、例外にマウスを合わせて表示されるツールチップも撮影します。表示される全カテゴリを記録するためです。
特に
traffic_type: allの構成では、Category例外がAPIのJSONに含まれているか確認し、画面の記録も残しておきましょう。 - 例外が参照するNetwork Locationの詳細画面
IDだけでなく、名前とIP範囲も記録します。APIに参照IDしか含まれていない場合も、画面の情報と対応づけて内容を確認できるようにしておきます。
- SSL Decryptionポリシーの一覧と、比較に必要な条件の画面
ポリシー名、順序、アクション、対象条件が分かるように残します。
保持期間が短い場合は、NAAの定期配信でログを残す
保持期間が短く、確認するころには移行前のログが参照できなくなる場合は、NAAのExploreでレポートを作り、ScheduleでCSVを定期配信する方法が保険になります。
長期間参照できる環境でも、担当者へ定期的に利用状況を届けたい場合は、任意で配信して構いません。
以下は、定期配信が必要な場合の設定例です。
フィールド名や利用できる機能は、実際のテナント画面でも確認してください。
- Advanced Analytics › Exploreで、Data CollectionをTransaction Eventsにする。
- Event Dateで取得期間を指定し、Bypass Reasonを
starts with Steering Exceptionで絞る。 - ディメンションにBypass Reason、Domain、Access Methodを選ぶ。必要に応じてCategoryも追加する。
- メジャーに
# Eventsと# Usersを選び、イベント件数の降順で結果を確認する。 - Row Limitを、Exploreの上限である
5000に設定する。 - レポートを保存し、Scheduleで担当者へCSVを定期配信する。
- Schedule設定時はSend Testで通知テストを行う。
設定したら、最初の配信で次の点を確認しておきます。
- 指定した担当者へメールが届き、CSVを開けるか。
- 同じ条件でExploreを実行した結果と、配信されたCSVの件数・集計値が対応しているか。
- 想定した期間にデータが存在するか。必要ならEvent Dateを日単位の集計に追加し、各日の結果を確認する。
- 配信に失敗した場合、誰が気づいて、保持期間内に手動で再取得するか。
このレポートはDomainやBypass Reasonなどでまとめた集計結果で、生のTransaction Eventを1件ずつ保存するものではありません。
この検索条件は移行前のプロキシバイパスを記録するためのものです。
移行後の確認では、自動生成されたSSL・RTPポリシー名などを使い、検索条件を切り替えてください。
おわりに
現時点では、通知と公式ドキュメントから整理した仕様・確認ポイントに留まりますが、筆者自身も最初にどういうことか読み解くのに少し苦労したので、ブログでまとめてみました。
クラウドネイティブのテナントも、執筆時点ではまだ移行前です。
実際に生成されたポリシーやログ、通信への影響、運用上気になった点があれば、弊社テナントの移行後に別のブログでお伝えしたいと思います！
以上、むろでした。
