プロンプトと適用コンテキスト
URLプレビューAPIの安全なフェッチパスを設計してください。認証されたユーザーが任意のパブリックなHTTPまたはHTTPSのURLを送信します。バックグラウンドワーカーがドキュメントを取得し、サニタイズされたページタイトルのみを返します。パブリックなWebサイトが想定される入力であるため、製品側で固定のドメイン許可リストを維持することはできません。
この面接では、デフォルトのポート80および443のみを許可し、リダイレクトの追跡は最大3回までとし、合計3秒のタイムアウトを適用し、解凍後に最大2 MiBまで読み込むものとします。これらの数値は普遍的なセキュリティ設定ではなく、面接用の前提条件です。本サービスは、IPv4またはIPv6を介して、ループバック、プライベート、共有、リンクローカル、マルチキャスト、予約済み、ドキュメント用、またはクラウドメタデータの宛先に到達してはなりません。また、代替IP表記、混在したDNS応答、DNSリバインディング、内部アドレスにリダイレクトするパブリックURL、過大なレスポンス、低速なサーバーに対しても耐性を持つ必要があります。
MITREはCWE-918を、サーバーがURLを受信してそれを取得する際に、リクエストが期待される宛先に到達することを十分に保証しない状態と定義しています。この捉え方は有用です。本質的な問題は「送信認可（outbound authorization）」にあります。入力検証、DNSの挙動、ネットワークルート、そして実際のソケットの宛先が、単一のポリシーを適用しなければなりません。2026年の公開Webセキュリティ面接の議論では、SSRFがXSS、SQLインジェクション、IDORと並んで候補者が説明できるように準備すべきトピックとして挙げられています。これは現在の面接における関連性を裏付けるものですが、特定の企業における必須の質問や出題頻度の主張を確定するものではありません。OWASP Top 10:2025はCWE-918を「Broken Access Control（不備のあるアクセス制御）」にマッピングしており、認可モデルの重要性を補強しています。
既存の質問バンクでは、クローラーやURL短縮サービスにおける境界の1つとしてSSRFに言及しています。本問はフェッチパスそのものを切り離して扱います。すなわち、パース、名前解決、宛先の分類、接続バインディング、リダイレクト、egress制御、そしてポリシーがチェック時と使用時の競合（time-of-check/time-of-use）に耐えうる証明です。
面接官が評価するポイント
第1のシグナルは、候補者が宛先を「認可の決定」としてモデル化しているかどうかです。文字列localhostや127.0.0.1のチェックだけでは不完全です。宛先はIPv6リテラル、IPv4マップドIPv6アドレス、代替の数値表現、安全な応答と安全でない応答の両方を含むホスト名、リダイレクト先、あるいは検証と接続の間でDNS応答が変わる名前である可能性があります。
第2のシグナルは、パーサーの規律です。正規表現や部分文字列チェックはURLのセマンティクスを定義しません。優れた回答では、標準準拠のパーサーを1つ使用し、パース失敗や埋め込まれた認証情報を拒否し、明示的なHTTPスキームと期待されるポートのみを許可し、パーサーの正規化されたフィールドからすべてのポリシー決定を行います。ソケットが審査済みのIPアドレスに固定されている場合でも、TLS検証には元の正規化されたホスト名を使用し続けます。
第3のシグナルは、DNSリバインディングのギャップを塞ぐことです。HTTPライブラリがソケットを開く前にもう一度DNSルックアップを実行する場合、IPを解決して承認しても意味がありません。フェッチャーは特定の承認済みアドレスに接続するか、それを実行するポリシー対応のegressプロキシ経由でリクエストを送信する必要があります。すべてのリダイレクトとリトライは、新たな認可イベントとなります。
第4のシグナルは、多層防御（defense in depth）です。アプリケーションのバグがあっても、内部サブネットやメタデータエンドポイントにルーティングできないネットワーク境界で阻止されるべきです。ワーカーには最小限のID権限のみを付与し、アンビエントなユーザーCookieや認可ヘッダーを持たせず、境界が定められたパーサーを使用し、ページスクリプトの実行やサブリソースの取得を行えないようにします。
最後のシグナルは、反証可能な検証です。候補者は、代替アドレス形式、混在するAおよびAAAAレコード、再解決の競合、リダイレクト、解凍制限、egressファイアウォールルールを検証するテストを提案する必要があります。任意のパブリックドメインが製品要件であるため、「許可リストを使用する」と言うだけではこのプロンプトの解決にはなりません。それはパートナー限定の異なるスコープにのみ適したアプローチです。
回答前に確認すべき質問
- 宛先は任意のパブリックサイトですか、それとも既知のパートナーですか？ 既知のパートナーであれば、スキーム、ホスト、ポートの完全一致による許可リストが可能です。任意のプレビューには、保守的なパブリックアドレスポリシーとネットワークで強制されるegress境界が必要です。
- どのプロトコル、ポート、メソッド、ヘッダーが必要ですか？ このプロンプトでは、ポート80のHTTPまたはポート443のHTTPSでのGETのみを許可します。呼び出し元が選択したメソッド、リクエストボディ、プロキシ、Cookie、認可ヘッダー、任意のヘッダーは受け入れません。
- リダイレクトは必要ですか？ 最大3ホップまで必要です。サービスは自動リダイレクトを無効にし、フォローする前に各
Locationターゲットを個別に認可します。 - どのような出力が必要ですか？ サニタイズされたタイトルのみです。ワーカーは生のHTMLを返さず、JavaScriptを実行せず、XML外部実体を処理せず、画像をレンダリングせず、スタイルシート、フォント、スクリプトを取得しません。
- ワーカーから到達可能なアドレス空間はどれですか？ 回答には、IPv4、IPv6、コンテナおよびサービスネットワークのルート、企業ネットワーク、プロバイダーのメタデータエンドポイントが含まれている必要があります。egressポリシーをテストする前にインベントリが必要です。
- キャッシュとリトライはどのように動作すべきですか？ キャッシュされたプレビューは重複フェッチを減らせますが、キャッシュミス時は安全なパスを経由します。この設計では自動リトライは行いません。明示的なリトライは、DNS解決、認可、接続ピニングをはじめからやり直します。
- 許容される可用性のトレードオフは何ですか？ 返されたアドレスのいずれかが安全でない場合にホスト名を拒否すると、設定ミスのあるパブリックサイトがブロックされる可能性があります。このプロンプトでは部分的な到達可能性よりもセキュリティを選択します。拒否は可観測であり、別のアドレスを暗黙的に選択することはありません。
30秒で答えるフレームワーク
「標準準拠のURLパーサーでパースし、ポート80のHTTPまたはポート443のHTTPSのみを許可し、認証情報は拒否します。信頼できるリゾルバーを通じてすべてのAおよびAAAA応答を解決し、IPv4マップドIPv6を正規化し、いずれかのアドレスが管理対象のパブリックアドレスポリシーから外れている場合は宛先を拒否します。ワーカーは承認された1つのIPに直接接続しますが、Host、TLS SNI、証明書検証のためにホスト名を保持し、DNSリバインディングのギャップを塞ぎます。自動リダイレクトとリトライは無効のままとし、各リダイレクトで完全なチェックを繰り返します。分離されたegressファイアウォールが内部およびメタデータルートをブロックします。さらに3秒、2 MiB、3ホップの制限を適用し、サブリソースを読み込まず、リバインディングとメタデータへのリダイレクトをエンドツーエンドでテストします。」
ステップごとの詳細解説
ステップ1：要件を単一の宛先ポリシーに変換する
API、ワーカー、HTTPクライアントに文字列チェックを分散させるのではなく、ポリシーを明示的に表現します：
DestinationPolicy
schemes: http, https
origin_pairs: http:80, https:443
userinfo: forbidden
address_requirement: globally reachable public unicast
redirects: at most 3, authorize every hop
method: GET
caller_headers: none
total_deadline: 3 seconds
decompressed_body_limit: 2 MiBAPIは呼び出し元を認証し、アカウントおよびテナントのクォータを適用し、送信された文字列を信頼できないデータとして保存し、ジョブをキューに入れます。後続のワーカーに渡すための『セキュリティチェック』を行って信頼済みフラグを付与することはありません。ジョブが実行される前にDNSやルートが変更される可能性があるためです。ワーカーが接続を開くコンポーネントであるため、接続直前に最終決定を下します。
パートナー統合の場合、最も強力なポリシーは、正規化されたスキーム、ホスト名、ポート、および必要に応じて期待されるパスの完全な許可リストです。このプレビュー製品は、意図的に任意のパブリックホストを受け入れます。したがって、そのポリシーはパブリックかつグローバルに到達可能と分類された宛先のみを許可します。信頼できるアドレスレジストリと組織独自のネットワークインベントリから分類器を保守します。RFC 1918の範囲のみを含む手書きのリストでは、ループバック、リンクローカル、共有、マルチキャスト、予約済み、ドキュメント用、IPv6ユニークローカル、IPv4マップド形式、およびプロバイダー固有のメタデータエンドポイントを見逃してしまいます。
ステップ2：最初にパースし、パースされたフィールドからポリシー決定を行う
プラットフォームのWHATWG互換または同等に十分にテストされたURLパーサーを使用します。絶対URLを要求します。パースエラー、ユーザー名またはパスワードのコンポーネント、製品側で保持する理由のないフラグメント、HTTP以外のスキーム、および明示的なポリシー外のポートを拒否します。国際化ドメイン名を含め、パーサーを通じてホスト名を正規化し、生の文字列を正規表現で個別に再解釈することは絶対に避けます。
https://expected.example@evil.example/などの例は、前方一致（プレフィックスマッチ）が安全でない理由を示しています。ネットワークホストはevil.exampleです。フラグメントはネットワークの宛先を選択するものではなく、エンコーディングや代替の数値形式によってバリデーターとHTTPクライアントの間で解釈の不一致が生じる可能性があります。単一のパーサーが、以降のすべてのステップで使用されるスキーム、正規ホスト、実効ポート、リクエストパスを提供する必要があります。
ホストがIPリテラルの場合は、直ちに正規化して分類します。両ファミリーのポリシーを適用する前に、IPv4マップドIPv6を埋め込まれたIPv4値に変換します。句読点、文字列の長さ、またはホストがドメインに『見える』かどうかから安全性を推測してはなりません。
ステップ3：すべてのアドレスを解決し、承認された結果に接続をバインドする
ホスト名の場合は、管理下にあるリゾルバーを使用してAレコードとAAAAレコードの両方を解決します。リゾルバーの通常のCNAME処理に従い、最終的なアドレスを収集します。このプロンプトでは、いずれかの応答が許可されていない場合、宛先を拒否します。各アドレスはIPリテラルと同じ分類器を通過します。拒否の際は、クエリを含むURL全体ではなく、理由コードを記録します。
重要な不変条件は以下のとおりです：
the IP authorized by policy == the IP used by connect()承認されたアドレスを1つ選択し、その正確なアドレスをソケット層に渡します。HTTPのHostヘッダー、およびHTTPSの場合はTLS SNIと証明書のホスト名検証のために、正規化されたホスト名を保持します。数値IPに対して有効な証明書は代替にはなりません。HTTPクライアントの独立したDNSルックアップを無効にします。そうしないと、攻撃者は検証中にパブリックアドレスを返し、接続中にプライベートアドレスを返すことができてしまいます。
各ワーカーの代わりに、ポリシー対応のegressプロキシが解決、分類、接続ピニングを担当することもできます。ワーカーは、攻撃者が選択したプロキシのアドレスではなく、正規化されたURLと固定のリクエストポリシーをそのプロキシに送信します。同じコンポーネントが認可とソケットの決定を行うか、厳密に制御された境界を越えて改ざん防止された承認済みアドレス結果を渡す必要があります。
DNSの応答は正当に入れ替わることがあるため、ピニングの有効期間は1回のフェッチホップのみであり、永続的ではありません。後続のジョブ、リダイレクト、または明示的なリトライでは、再度解決と認可を行います。コネクションプーリングは、認可されたオリジンとポリシーをキーにする必要があります。信頼できないURL文字列が似ているように見えるという理由だけでソケットを再利用してはなりません。
ステップ4：すべてのリダイレクトを新しい送信リクエストとして扱う
自動リダイレクト追跡をオフにします。リダイレクトステータスを持つ各レスポンスについて、同じパーサーを使用して現在のURLに対してLocationを解決し、ホップ数をインクリメントし、スキーム、ポート、ユーザー情報、DNS、アドレス、および接続のチェックを最初からやり直します。欠落または不正なロケーション、ループ、4回目のリダイレクト、および許可されていないアドレスに解決されるホップを拒否します。
呼び出し元のCookie、認可ヘッダー、または任意のヘッダーを最初のホストに転送しないでください。レスポンスで設定された認証情報を別のオリジンに転送しないでください。フェッチャーは固定のUser-Agentと小さな固定ヘッダーセットを使用します。製品に必要なのはタイトルのみであるためGETで十分です。リダイレクトによって、呼び出し元が制御するボディ付きのPOSTに操作が変更されてはなりません。
これにより、一般的なバイパスが塞がれます。攻撃者が制御するパブリックURLが、http://169.254.169.254/、http://127.0.0.1/、または内部サービスへのリダイレクトを返す手法です。最初のURLのみを承認すると、実際に接続される宛先とは異なる最終宛先を認可してしまうことになります。
ステップ5：アプリケーションコードが見逃したものをネットワークで拒否する
専用のネットワークセグメントまたはネームスペースでフェッチワーカーを実行します。そのegressファイアウォールは、制御されたリゾルバーへのDNSと、ポリシー対応プロキシまたは承認されたパブリックルート経由のHTTP/HTTPSのみを許可します。両方のIPファミリーについて、ループバックエスケープ、内部サービス範囲、クラスターネットワーク、企業ネットワーク、リンクローカル空間、およびクラウドメタデータエンドポイントを拒否します。書かれたルールだけでなく、有効なルートを検証してください。
ワーカーのサービスIDには、プレビュージョブの読み取りと完了に必要な権限のみが付与されます。その環境に広範なクラウド認証情報を配置することは避けてください。EC2では、使用していないときにインスタンスメタデータを無効にするか、IMDSv2を要求することで露出を減らすことができます。AWSはIPv4メタデータエンドポイント169.254.169.254とオプションのIPv6エンドポイントの両方をドキュメント化しています。これらの制御は多層防御を追加するものであり、URLポリシーを省略可能にするものではありません。
内部のWebhookや管理用クライアントとは別のワーカープールを使用してください。プライベートサービスに到達できる汎用のHTTPヘルパーで、信頼できないURLも処理するようなことは避けるべきです。メタデータの宛先を含むネットワーク拒否された試行は、呼び出し元に内部トポロジを公開することなく、メトリクスとアラートを生成する必要があります。
ステップ6：フェッチを制限し、約束されたアーティファクトのみをパースする
DNS、接続、ファーストバイト、アイドル読み取り、および3秒の合計タイムアウトを個別に適用します。レスポンスをストリーミングし、解凍後のコンテンツが2 MiBを超えたら停止します。圧縮ボディの制限だけでは、解凍爆弾（decompression bomb）を許してしまいます。HTMLタイトルに必要なコンテンツタイプのみを受け入れます。多くの中断した低速なパブリックサーバーがすべてのワーカーを消費しないように、アカウントごとおよびグローバルで並行性を制限します。
自動リトライは行わないでください。リトライは別の送信認可を作成し、負荷を増大させる可能性があります。後で製品要件によってリトライが追加される場合、各試行はパースと解決からやり直し、ジョブの合計バジェット内に留まる必要があります。
パーサーはボディを敵対的なものとして扱います。JavaScriptを実行せず、XML外部実体を解決せず、画像、スタイルシート、フォント、iframe、スクリプトを読み込まず、メタデータのリフレッシュ指示に従いません。境界が定められたストリーミングパーサーまたは分離されたパーサーでタイトルを抽出し、テキストとして正規化し、長さを制限して、その値のみを返します。生のHTMLをAPIレスポンスから除外し、最終的なレンダリング先でタイトルをエスケープします。
ステップ7：決定を監視し、ソケットレベルの不変条件をテストする
ジョブの結果、正規化されたホストまたはプライバシーを保護するホストキー、スキーム、実効ポート、選択されたアドレスクラス、リダイレクト数、バイト数、所要時間、および安定した拒否理由を記録します。URLにはシークレットが含まれる可能性があるため、完全なURL、クエリ文字列、ユーザー情報、レスポンスボディ、DNSペイロードはログに記録しないでください。プライベート、リンクローカル、メタデータ、スキーム、ポート、リダイレクト、サイズ、タイムアウト、コンテンツタイプの各ルールの拒否率を追跡します。
実際のリゾルバー、プロキシ、ファイアウォール、HTTPクライアントを通じてテストします。以下を含めます：
127.1、IPv6の::1、IPv4マップドIPv6などのループバックバリアント- プライベート、共有、リンクローカル、マルチキャスト、予約済み、ドキュメント用、メタデータのアドレス
- パブリックとプライベートの応答が1つずつあるドメイン、およびAレコードとAAAAレコードの両方
- 検証時にはパブリックを返し、次のルックアップでプライベートを返すリゾルバー
- 拒否された各アドレスファミリーにリダイレクトするパブリックエンドポイントと、4回ループするエンドポイント
- 埋め込み認証情報、エンコードされたホスト、HTTP以外のスキーム、禁止されたポート、不正なURL
- 低速なヘッダー、停止したボディ、過大な解凍ボディ、圧縮爆弾
- スクリプトまたは画像が内部ホストを指しているHTMLページ
- TLSが元のホスト名を検証する一方でソケットが固定されている有効なパブリックHTTPSページ
- アプリケーションポリシーを意図的にバイパスしても、egressファイアウォールによってブロックされること
クライアントが2回目のルックアップを実行した場合、DNSリバインディングテストは失敗しなければなりません。証明書検証が誤って数値IPを対象にした場合、ポジティブなTLSテストは失敗しなければなりません。これらが揃って初めて、検証と接続が意図したIDを使用していることが証明されます。
質の高い回答例
「私はSSRF防御を、ソケットを開くコンポーネントによって実行される送信認可としてモデル化します。APIは呼び出し元を認証およびレート制限し、URLを信頼できない入力として保存し、ジョブをキューに入れます。フェッチワーカーは標準準拠のパーサーでURLをパースし、ユーザー情報、HTTP以外のスキーム、80および443以外のポートを拒否し、そのパーサーからのみ正規ホストとパスを取得します。
IPリテラルの場合、正規化し、IPv4マップドIPv6を展開し、管理対象のパブリックアドレス分類器を適用します。ホスト名の場合、制御されたリゾルバーを通じてすべてのAおよびAAAA応答を解決し、いずれかの結果がプライベート、ループバック、共有、リンクローカル、マルチキャスト、予約済み、ドキュメント用、メタデータ、またはポリシー外である場合は宛先全体を拒否します。次に、Host、TLS SNI、証明書検証のために元のホスト名を保持しながら、承認された1つのIPに直接接続します。これにより、リバインディング攻撃で使用される2回目のDNSルックアップの隙間がなくなります。
自動リダイレクトとリトライは無効にします。最大3回のリダイレクトについて、新しいロケーションをパースし、別のソケットを開く前に完全な認可を繰り返します。固定ヘッダーを使用し、呼び出し元のCookieや認証情報を含めずにGETのみを送信します。専用のegressプロキシまたはファイアウォールが、IPv4およびIPv6にわたる内部、クラスター、企業、リンクローカル、メタデータのすべてのルートを個別に拒否します。ワーカーは最小限のサービスIDを持ち、汎用の内部HTTPクライアントを使用することはできません。
各ジョブには3秒の合計タイムアウトと2 MiBの解凍ボディ上限があります。パーサーはスクリプトを実行せず、サブリソースも読み込まず、長さが制限されたサニタイズ済みのタイトルのみを返します。完全なURLを含めずに、理由コード、アドレスクラス、リダイレクト数、バイト数、レイテンシをログに記録します。私の受け入れテストスイートには、混在したDNS応答、チェックと接続の間のリバインディング、IPv4マップドIPv6、メタデータへのリダイレクト、gzip爆弾、低速ボディ、ソケット固定TLS、そしてネットワークによって阻止されなければならないポリシーバイパステストが含まれます。」
よくある間違い
localhostとRFC 1918のみをブロックする → 代替のIPv4形式、IPv6、リンクローカル、共有、予約済み、メタデータアドレスに依然として到達可能 → 保守されたパブリック宛先ポリシーを使用して、両方のアドレスファミリーを正規化および分類する。- 正規表現で検証する → バリデーターとHTTPパーサーの間で、認証情報、エンコーディング、ホスト、ポートに関する解釈の不一致が生じる可能性がある → 単一の標準準拠パーサーを使用し、その正規フィールドのみを利用する。
- 解決、チェックした後にクライアントに再度解決させる → DNSリバインディングにより、承認後にソケットの宛先が変更される → ホスト名に対してTLSを検証しながら、審査済みのIPに接続を固定する。
- 最初のURLのみを承認する → 許可されたパブリックホストが内部サービスにリダイレクトする可能性がある → 自動リダイレクトを無効にし、すべてのホップを再認可する。
- 混在したDNS結果から安全な応答を選択する → アドレス選択の変更により、後から安全でない応答に到達する可能性がある → 返されたアドレスのいずれかが本プロンプトのポリシーに違反している場合は、ホスト名を拒否する。
- 呼び出し元ヘッダーを転送する → Cookieや認可値が攻撃者の選択したホストに漏洩する → アンビエントな認証情報を持たない固定の送信リクエストを構築する。
- IMDSv2やクラウド設定のみに依存する → 内部サービスやその他のアドレス範囲が露出したままになる → アプリケーション認可、最小限のID、メタデータの堅牢化、egress拒否を組み合わせる。
- 圧縮バイト数のみを制限する → 小さなボディが展開されてメモリやCPUを枯渇させる可能性がある → 解凍バイト数、パース処理量、時間、並行性を制限する。
- ブラウザのようにページをパースする → スクリプトやサブリソースが新たな未レビューの送信リクエストを作成する → アクティブコンテンツと外部実体解決を無効にして、約束されたアーティファクトのみを抽出する。
- デバッグのために完全なURLをログに記録する → クエリ内のシークレットや認証情報がオブザーバビリティシステムに流出する → 制限された正規フィールドと安定した理由コードをログに記録する。
フォローアップの質問
すべての宛先が既知のパートナーである場合、何が変わりますか？
正規化されたスキーム、ホスト名、ポートの完全一致の許可リストを使用し、レビュー済みの設定を通じてプロビジョニングします。それでもアドレスの解決と分類は行います。侵害されたDNSレコードや設定ミスによって、信頼できる名前が内部ルートに変わってしまってはならないためです。パートナーのプライベートエンドポイントは、パブリックプレビューワーカーではなく、明示的なネットワークパスを持つ別の認証済み統合に属します。
サービスはドメインをまたぐリダイレクトを安全にサポートできますか？
はい。クロスドメインリダイレクトが製品要件であり、各ホップでポリシー全体を繰り返すのであれば可能です。認証情報やオリジン固有の状態を削除し、新しいホスト名を解決し、すべての結果を分類し、新しい接続を固定して、ホップをカウントします。よりシンプルなポリシーとして同一オリジンを要求することもできますが、一般的なパブリックリダイレクターを拒否することになります。面接官にはその製品のトレードオフを明示的に伝える必要があります。
なぜDNS応答の1つがパブリックで、もう1つがプライベートの場合にホスト名を拒否するのですか？
フェイルクローズ（安全側に倒す）の安定した契約を作成するためです。アドレスの順序は、リゾルバー、IPファミリー、リトライによって異なります。検証中に1つのパブリックな応答を選択し、後から別のコンポーネントがプライベートな応答を選択すると、再び脆弱性の隙間が生まれます。部分的な受け入れを望む製品では、同じコンポーネントがすべての接続で承認されたアドレスのみを固定する必要があり、フェイルオーバーを慎重にテストしなければなりません。本プロンプトでは、よりシンプルで保守的なポリシーを採用しています。
製品にスクリーンショットやJavaScriptでレンダリングされたプレビューが必要な場合はどうなりますか？
レンダリングを、同一のegressポリシーを持つより隔離された層に配置します。ブラウザは多くのセカンダリリクエストを作成するため、すべてのナビゲーション、リダイレクト、ワーカー、WebSocket、サブリソースをインターセプトして認可します。ローカルファイルアクセスと不要なブラウザ機能を無効にし、CPU、メモリ、時間、ダウンロードを制限し、ジョブごとにサンドボックスを破棄します。レンダリングは、初期ページのURLから信頼を引き継ぎません。
デプロイ後にファイアウォールが有効であることをどのように証明しますか？
実際のワーカーのIDとネームスペースから、拒否対象のIPv4、IPv6、クラスター、企業、メタデータの宛先に対して制御されたカナリアテストを実行し、接続の失敗と期待されるネットワークテレメトリの両方を確認します。ルート、コンテナ、プロキシ、またはクラウドネットワークの変更後にこれを繰り返します。設定レビューは意図を示すものですが、カナリアテストとフローログが実際の有効なパスを証明します。