【ITニュース解説】Decoupled Security: Securing the Auth Flow Without Touching the Implementation
2026年09月14日に「Dev.to」が公開したITニュース「Decoupled Security: Securing the Auth Flow Without Touching the Implementation」について初心者にもわかりやすく解説しています。
ITニュース概要
既存認証システムへセキュリティ機能を追加する際、Caddyプラグインでアプリのコード変更を不要にした。リバースプロキシで漏洩パスワードチェックを非同期で行い、ログイン処理に遅延を与えない。4万リクエストの負荷テストで、外部障害時もログインが中断しない高い安定性を示した。
ITニュース解説
現在の認証システムに新しいセキュリティ対策を追加することは、システムエンジニアにとって大きな課題の一つである。認証プロセスはユーザーがサービスを利用するための入り口であり、その安定性は極めて重要だからだ。既存の認証コードに少しでも変更を加えると、予期せぬエラーやシステム全体の停止につながるリスクがある。例えば、漏洩したパスワードを検知するような新しい検証メカニズムを導入しようとすると、通常は既存のバックエンドコードを大幅に修正(リファクタリング)したり、新しい外部サービスへの依存関係を管理したりする必要が生じる。しかし、どんな状況であっても、外部サービスの遅延や障害によってユーザーがログインできなくなる事態は避けなければならないという、譲れない要件が存在する。
このような課題に対し、アプリケーションのバックエンドコード(Node.js、PHP、Go、Javaなど)を修正することなく、セキュリティ対策を強化する新しいアプローチが提案されている。これは、セキュリティの層をインフラストラクチャ(基盤)の側へ移動させるという考え方だ。具体的には、Caddyというリバースプロキシのための公式プラグイン「caddy-hansestack」を用いることで、セキュリティに関する品質保証(QA)の層をアプリケーションから完全に分離(デカップリング)する。このプラグインは「enrich_response」モードで動作する。
その仕組みは次のようになる。まず、Caddyプラグインは「ミドルウェア」として機能し、ユーザーからのログインリクエストを最初に受け取る。この際、リクエストに含まれるパスワードを、特定の個人を特定できないように安全な方法(k-anonymityという技術)で抽出し、同時に元のログインリクエストを、一切変更せずにバックエンドのアプリケーションサーバーへ並行して転送する。つまり、バックエンドは普段通りにログイン処理を行い、その実装に手を加える必要はない。Caddyはバックエンドが処理を進める間に、抽出したパスワードを使って漏洩チェックを行う外部APIの結果を待つ。そして、外部APIからの非同期的な結果が得られ次第、その結果を示すHTTPヘッダー(例えば「X-Hansestack-Leaked: true」)を、バックエンドからの応答に挿入してから、最終的にクライアント(ユーザーのブラウザなど)に返信する。この方法により、バックエンドのコードを変更することなく、また主要なログインプロセスに遅延を追加することなく、セキュリティチェックを組み込むことが可能となる。
このアーキテクチャの信頼性を検証するため、開発チームはシステムを極限状態での負荷テストにかけた。隔離されたデモ環境で、bashスクリプトを使って40,000件の同時ログイン試行(1,000個のバックグラウンドプロセスを40ブロックで実行)をローカルのCaddyサーバーに対してシミュレートした。このテストの主な目的は、意図的にシステムを過負荷状態にし、統合された「サーキットブレーカー」という耐障害性メカニズムがどのように機能するかを測定することだった。
負荷テストの結果、システムの驚くべき耐障害性(レジリエンス)が明らかになった。まず、最初の1,307件のリクエストは通常通りHansestackの外部APIによって処理され、テスト用のパスワードが実際に漏洩していると正しく識別された。しかし、大量の同時接続が発生したため、外部APIの保護メカニズムが作動し、1,924件のリクエストが「レート制限」によって処理を一時的に制限された。さらに、ローカルネットワークの混雑により6件のリクエストがスキップされた。これらの連続する失敗をCaddyプラグインが「エッジ」で検知し、設定された5回の連続エラーの後、サーキットブレーカーが作動した。
サーキットブレーカーが作動すると、システムは「フェイルオープン」モードに移行する。このモードでは、残りの36,715件のリクエストは、外部APIへの呼び出しをスキップし、ローカルでそのまま通過させられる。これは、外部インターフェースの過負荷を防ぎ、認証フローが滞ることを避けるための重要な動作だ。この場合、漏洩チェックは正式には行われない(漏洩していないと評価される)が、ユーザーのログインプロセス自体は継続される。テスト全体を通じて、クライアント側で発生したエラーはゼロだった。バックエンドへのリクエストの配送も途切れることなく維持された。測定された遅延(レイテンシ)は、システムの安定性を示していた。中央値(p50)は2.73ミリ秒、95パーセンタイル(p95)は150ミリ秒、99パーセンタイル(p99)でも345ミリ秒と、設定されたタイムアウト(500ミリ秒)を大幅に下回った。つまり、セキュリティ層が過負荷状態を管理している間も、ログインプロセスは完全に高いパフォーマンスを維持していたのである。
この結果から、認証フローにセキュリティ強化のための追加検証メカニズムを導入する際も、システムの安定性を損なうべきではないという結論が裏付けられた。k-anonymityによるパスワード漏洩チェック機能を、リバースプロキシの「enrich_response」ミドルウェアとして組み込み、さらにサーキットブレーカーで保護するこのアプローチは、実装にかかる労力を最小限に抑えながら、信頼性の高いセキュリティ指標を提供し、同時にビジネスの核となる認証プロセスを確実に保護できる。この仕組みによって、セキュリティとシステム安定性の両立が可能となるのだ。