一時的な IP 許可リストのリンク：その許可が実際に通すもの

一回のクリックを一時的なファイアウォール規則に変えるのは便利であり、同時に、誰がサービスに到達できるかを決める認可の仕組みを築くことでもあります。発行されるのは人ではなくアドレスであり、その違いは二人が一つの NAT を共有した瞬間から意味を持ちます。許可の範囲を限定し、意図的に確認し、リンクを作る前に失効に意味を持たせてください。目の前の判断は、境界をどこに置くかであり、境界があるべきかどうかではありません。

許可がどの問いに答えるのかを決める

要件から始めます。名前のある人物がサービスに到達する必要があり、アプリケーションがすでにその人物を認証しているなら、認証済みのゲートウェイは執行点で身元を保ち、アドレスの受け入れはまったく不要です。対象がビルドエージェント、管理用のジャンプポート、あるいは利用者ログインに関与できない機器であるなら、範囲を絞ったアドレス許可が唯一の実用的な統制になるかもしれません。

利用者向けのアプリケーションにアドレス受け入れを選ぶと、本当の認可の問題は別の場所へ移り、ポータルは自分が閉じなかった隙間の責任を引き継ぐことになります。

サーバー側で要求の範囲を限定する

ブラウザーに宛先、ポート、プレフィックスを選ばせてはいけません。ポータルは自らの記録からサービスを解決し、サーバー側のテストで権利を確認します。これは、OWASP の認可ガイド がすべての要求に適用しているのと同じ原則です。アドレスの導出も保護された境界に属します。リバースプロキシがクライアントのアドレスを報告するときは、設定されたプロキシ経路とその文書化されたヘッダー処理だけを受け入れてください。訪問者が提供する転送ヘッダーは出所についての主張であり、その証拠ではありません。

次に、ポータルとサービスが同じ送信元を見ていることを確認します。分割トンネル、プロキシの一ホップ、IPv4 と IPv6 の違いによって、二つの宛先に二つの異なるアドレスが渡ることがあるため、一方の経路で有効にした許可が続く要求を覆わない可能性があります。

導入する前に許可を提示する

リンクを開いたときは、提案されたサービス、観測された送信元、期間を表示し、まだ何も変更しないようにします。その一ステップが、メールで届いたリンクを行為から提案へ変え、プレビュー用ボットやメールスキャナーが取得するだけでアクセスを与えてしまうのを防ぎます。

確認は、通常のクロスサイトと生成元の防御を備えた状態変更の要求であるべきです。トークンは単回使用とし、規則の導入まさにその瞬間に原子的に消費してください。記録には所有者、サービス、アドレス、許可の識別子、失効を残し、生のトークンは決して記録しないようにします。

トークンの配布には、規則そのものと同じ注意が必要です。失効した、あるいはすでに消費されたリンクがなお規則を作り出すのは、同じ鍵で取り付けた二つ目の扉です。

許可が生きている間もアドレスは共有される

オフィスの NAT、キャリア NAT、共有の VPN 出口は、いずれも複数の人を一つのアドレスの後ろに置きます。 そのアドレスを通すことは、その後ろにいる全員を通すことです サービス側の次の境界に関する限りそうであり、サービスが期待するアカウントを誰が持っているかは何も証明しません。

規則を外すことも、万能な切断ではありません。確立済みの接続、キャッシュされたアプリケーションのトークン、長寿命のセッションは、規則より数分あるいはるかに長く生き残ることがあるため、選ぶ寿命は規則がどれだけ存在するかではなく、受け入れ後にサービスが何をするかを反映すべきです。

四つの場合と、両方のアドレスファミリーを試す

許可は、それが耐える四つの場合と同じだけの価値しかありません。新しく許可された要求、承認されていない要求元、同じリンクの再再生、失効後の同じ要求です。

その後、それぞれのファミリーを別々に試してください。サービスが観測する送信元アドレスは、両者で異なることがあるためです。

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

有用な結果は、通常の利用者認可の下に置かれた一時的で監査可能な受け入れ判断であり、最初にクリックした人の名前を背負った恒久的な開口ではありません。