設問と適用範囲
認証付きAPIがHTTPとHTTPSの両方でリッスンしており、HTTPリクエストに対してHTTPSへの301リダイレクトを返しています。このリスク、サーバーおよびクライアントの変更点、そしてレガシークライアント向けの移行計画を説明してください。この設問はHTTPAPIワーキンググループの2026年5月のInternet-Draftに基づいています。これは策定中の仕様であり、最終的なRFCではありません。
面接官が評価しているポイント
- リダイレクトが発生する前に、認証情報がすでに平文ネットワークを通過していることを認識しているか。
- HSTS、HTTPS DNSレコード、接続遮断、Secure属性付きCookieを適切に組み合わせられるか。
- 共有ホスト、レガシークライアント、プロキシ、および認証情報の失効処理に対応できるか。
- 単に「HTTPSを使用する」と述べるだけでなく、測定可能なシグナルを用いてリスク低減を実証できるか。
回答前に確認すべき質問
- HTTPとHTTPSは同じホスト名およびリスナーを使用していますか？
- 認証情報はBearerトークン、Cookie、APIキー、またはリクエスト署名のいずれですか？
- すぐにアップグレードできないレガシークライアント、エンタープライズプロキシ、または内部の呼び出し元は存在しますか？
- HTTPエントリポイントは未認証のリソースも配信していますか？
- すでにHSTS、HTTPS DNSレコード、キーローテーション、および監査ログを使用していますか？
30秒回答フレームワーク
リダイレクトを行っても、平文ですでに送信された認証情報を回収することはできません。受動的な傍受者がBearerトークンやCookieを盗用する可能性があります。認証接続の前にHTTPエントリを失敗させる設計を優先し、HTTPS DNSレコードとHSTSを使用して初回利用時および再発時の設定ミスを減らし、CookieにSecureを設定し、クライアントがデフォルトで安全でないURLを拒否するようにします。即時の遮断が不可能な場合は、認証情報を含むすべての平文リクエストに対して同一の403を返し、漏洩した可能性のある認証情報を失効させます。メトリクス、移行期間、ロールバック体制を整えて移行を実施します。
ステップごとの詳細解説
1. 漏洩が発生するタイミングを説明する
クライアントは最初にHTTPリクエストを送信し、そのリクエストにAuthorization、Cookie、またはAPIキーが含まれている可能性があります。後から301を返しても、ネットワーク上を流れてしまったデータを消去することはできません。攻撃者はBearerトークンやCookieをリプレイできます。また、HTTPSでの再試行が成功することにより、クライアントの設定ミスが長期間見逃される原因にもなります。
2. サーバーのエントリポイントを設計する
認証が必要なエンドポイントについては、まずパブリックな平文でのリッスンを無効化するか、ポート80を明示的に信頼されたネットワークのみに制限します。301をセキュリティ対策とみなしてはいけません。共有ホストでHTTPを維持する必要がある場合、ゲートウェイは認証情報を含むリクエストを検知し、認証情報の有効・無効を明かさずに同一の403を返すべきです。
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0有効な認証情報と無効な認証情報でレスポンスに差をつけてはいけません。差があると、攻撃者に盗んだ値のテストオラクルを与えてしまいます。
3. 初回利用時のクライアント側のミスを減らす
HTTPS DNSレコードは、接続確立時に安全な接続を使用するようクライアントに指示できます。HSTSは、一度HTTPS接続が成功した後の以降の接続をアップグレードします。どちらも完全ではありません。HSTSはその事前の接続とクライアントのキャッシュ保持に依存し、DNSレコードはブロックされる可能性があります。SDK、CLI、および設定バリデーションは、デフォルトでhttpを拒否し、実行可能な対処手順のメッセージを提供する必要があります。
4. 認証情報の利用を制限する
CookieにはSecure属性を付与する必要があります。トークンはセキュアコンテキストのみに制限し、必要に応じてリクエストや接続にバインドされた署名を使用します。失効処理は認証情報の種類によって異なります。リプレイ可能なAPIキー、Bearerトークン、Cookieは通常即座の失効が必要ですが、偽造不可能な派生署名では失効が不要な場合もあります。
5. 漏洩した認証情報を処理する
平文で受信された認証情報は、すべて侵害された可能性があるものとして扱います。サーバーはまず一律に403を返し、次の安全な通信時に「認証情報が失効した」旨を説明できます。失効を監査ログに記録し、所有者にローテーションを行うよう通知し、ログ、キャッシュ、エラー本文に機密情報を決して含めないようにします。
6. 安全に移行する
まずはSDKやテスト環境でHTTPを拒否し、次に新規テナント向けに平文エントリポイントを無効化し、最後にレガシーテナントをバッチ単位で移行します。古いプロキシを必要とするクライアントには、認証情報を一切受け付けない短い移行用エンドポイントを提供します。期限を設定し、403の発生率とローテーションの完了状況を監視し、パブリックリソースで依然としてHTTPが必要な場合は認証付きAPIを別のホスト名またはゲートウェイポリシーに分離します。
7. 対策を検証する
パケットキャプチャを使用して、Authorization、Cookie、APIキーが平文で流れていないことを確認します。接続の切断と403の挙動を検証し、HSTSのキャッシュ、初回アクセス、プロキシ、再試行、およびロールバックをテストします。平文リクエスト数、認証情報を含む平文リクエスト数、自動失効数、403の誤検知、レガシークライアントの割合、および移行の完了状況を追跡します。
質の高い回答例
私は、301リダイレクトを認証付きAPIのセキュリティソリューションとはみなしません。リダイレクトが発生する前に、認証情報はすでに平文ネットワークを通過してしまっているからです。受動的な傍受者がBearerトークンやCookieをコピーできる上、HTTPSでの再試行が成功するとクライアント側の設定ミスが隠蔽されてしまいます。
サーバーはまず、認証が必要なエンドポイントでパブリックなHTTPを無効化すべきです。共有ホストの都合ですぐにそれができない場合、ゲートウェイは認証情報を含むすべてのHTTPリクエストに対して同一の403を返し、認証情報の有効性を明かさず、その認証情報を漏洩の可能性があるものとしてマークします。リプレイ可能なトークン、APIキー、Cookieは失効させてローテーションします。SDK、CLI、設定チェックはデフォルトでhttpを拒否し、HTTPS DNSレコードとHSTSによって初回および再発時のミスを減らし、CookieにはSecureを付与します。
テスト環境、新規テナント、レガシーテナントの順に段階的に移行します。エンタープライズプロキシには、認証情報を受け付けない短い移行パスを提供します。パケットキャプチャで検証し、平文リクエスト、認証情報を含む平文リクエスト、失効およびローテーションの完了状況、403の誤検知、レガシークライアントの割合を測定します。なお、IETFのドキュメントはまだドラフト段階であるため、導入計画は柔軟に調整できるようにしておきます。
よくある間違い
- HTTPSへのリダイレクトによって、すでに送信されたAuthorizationヘッダーやCookieが保護されると思い込むこと。
- HSTSのみを設定し、初回利用、レガシークライアント、ブラウザ以外のSDKを無視すること。
- 有効な認証情報と無効な認証情報で異なる平文レスポンスを返すこと。
- すべての認証情報を同一視し、派生署名とリプレイ可能なトークンの違いを無視すること。
- 移行、監視、失効、ロールバックの計画なしにHTTPを廃止すること。
フォローアップの質問と回答
HTTPエントリポイントがパブリックリソースも配信している場合はどうしますか？
認証付きAPIを別のホスト名に移動するか、ゲートウェイでパスと認証情報ヘッダーを分離します。パブリックリソースには自身のリダイレクトポリシーを適用できますが、認証付きエンドポイントは認証情報を含む平文リクエストを拒否しなければなりません。
HSTSで初回アクセス問題は解決しますか？
完全には解決しません。HSTSには過去のHTTPS接続の成功とクライアント側でのキャッシュ保持が必要です。SDK、設定チェック、HTTPS DNSレコード、デプロイメントチェックによって、初回接続もカバーする必要があります。
認証情報はいつ失効させるべきですか？
平文で確認された認証情報は、漏洩した可能性があるものとして扱います。リプレイ可能なトークン、APIキー、Cookieは失効させてローテーションします。偽造不可能な派生署名については、脅威モデルに基づいて失効が必要かどうかを判断します。
サービス停止や混乱を伴わない移行はどのように進めますか？
まずテスト環境と新規テナントで拒否を有効にし、レガシークライアントと403の誤検知を観察してから、バッチ単位で移行します。認証情報を受け付けない移行用のエンドポイントを一時的に維持し、明確な期限を設定した後に削除します。