spring-security-configurator-auditor

Spring Security Configurator Auditor

ソースマッピング：Kotlin_Spring_Developer_Pipeline.md（SK-13）から派生した、Tier 2 の高価値スキルです。

ミッション

明示的で、最小限かつテスト可能なセキュリティモデルを作成します。 設定を最短にすることではなく、最小権限と適切な失敗時の動作を優先します。

最初に確認する項目

• 現在の SecurityFilterChain またはチェーン。
• エンドポイント一覧。actuator、ドキュメント、内部管理者用ルートを含みます。
• 認証モデル：セッション、JWT、OAuth2 リソースサーバー、API キー、mTLS、またはそれらの混在。
• 認可モデル：ロール、スコープ、クレーム、メソッドセキュリティ、テナント境界。
• CORS、CSRF、セキュリティ関連のテスト。

設計手順

1. クライアントが誰なのかを定義します：ブラウザー、内部サービス、公開 API の利用者、ジョブ、または運用担当者。
2. 認証方式とトークンの信頼境界を定義します。
3. 公開エンドポイントを明示的に列挙します。
4. URL レベルとメソッドレベルで認可を定義します。
5. 401 と 403 の動作を定義します。
6. 重要な許可パスと拒否パスのテストを追加します。

セキュリティの基本ルール

• 公開エンドポイントには、明示的な許可リストを優先します。
• JWT の発行者、オーディエンス、有効期限、署名、クロックスキューに関する前提を意図的に検証します。
• 文書化されたルールに従ってクレームを権限にマッピングします。ID プロバイダーに対して、デフォルトのクレームマッピングが適切だと決めつけないでください。
• メソッドセキュリティとリクエストセキュリティの整合性を保ちます。一方がもう一方を暗黙に補うような設計にしないでください。
• CORS を、ブラウザーの厄介事ではなく、ポリシーの適用範囲として扱います。

高度なセキュリティ上の落とし穴

• 複数のフィルターチェーンには順序があります。誤ったチェーンに広範なマッチャーを配置すると、より具体的で安全なチェーンが隠れてしまうことがあります。
• マッチャーが広すぎると、ドキュメントや actuator エンドポイントへの permitAll が意図以上に広範囲を許可することがあります。
• アプリのどこかでトークンを使っているからといって、CSRF が自動的に無関係になるわけではありません。ブラウザーベースのフローや Cookie による認証がある場合、判断は変わります。
• 非同期実行、スケジューラー、メッセージリスナーでは、リクエストスレッドと同じセキュリティコンテキストが引き継がれないことがあります。
• 内部ヘルパーメソッドにメソッドセキュリティを設定しても、呼び出しがプロキシ境界を越えなければ役に立ちません。
• 発行者やオーディエンスを検証しない JWT 検証は、多くのチームが考える以上に脆弱です。
• CORS のプリフライトリクエストの失敗は、バックエンドのロジックが正しくても認証エラーのように見えることがあります。
• サーブレットスタックとリアクティブスタックではセキュリティの動作が異なります。設定をそのまま移植しないでください。

高度な認可とトークンに関する注意点

• パスベースの認可は必要な場合が多いものの、それだけで十分なことはまれです。テナント、所有権、リソースの状態に関するチェックは、メソッドレベルまたはドメインレベルの認可に含める必要がある場合があります。
• JWT の鍵ローテーション、JWKS キャッシュ、クロックスキューのポリシーは、セキュリティ上の懸念であると同時に運用上の懸念でもあります。鍵のロールオーバー中もトークン検証が機能するようにする必要があります。
• 不透明トークンのイントロスペクション、JWT の検証、ゲートウェイで終端する認証では、失敗時の動作も信頼境界も異なります。どのレイヤーが何を担うかを明確にしてください。
• カスタムクレームマッピングでは、マッピングルールが寛容すぎると、スコープが誤って失われたり、権限が昇格したりすることがあります。
• セキュリティヘッダー、セッション作成ポリシー、ステートレスであるという前提は、定型設定をそのままコピーするのではなく、実際のクライアントモデルに合わせてください。

エキスパート向けヒューリスティクス

• マッチャーのコードを書く前に、「どのテナントまたはコンテキストにおいて、誰が、どのリソースに、何を実行できるか」をモデル化します。
• デフォルトで拒否する設計を優先します。新しいエンドポイントは、明示的に公開されるまでは閉じた状態にします。
• ブラウザーのクライアントとマシンクライアントが共存する場合は、1 つのサービス内であっても、別々のセキュリティ適用範囲として扱います。
• 運用上機微なエンドポイントが「内部」向けであっても、明示的に保護します。内部向けだから安全とは限りません。

出力仕様

以下のセクションを返します。

• 脅威対象領域：何を、誰から保護する必要があるか。
• 認証モデル：ID をどのように確立し、検証するか。
• 認可モデル：アクセスの可否をどのように判断するか。
• 重大な指摘事項またはリスク：安全でないデフォルト設定、過度に広いルール、チェックの不足、テストの不足。
• 最小限の安全な設定計画：最小限で安全な設定またはパッチ。
• 検証：許可されるアクセスと拒否されるアクセスの両方に対するセキュリティテスト。

ガードレール

• 信頼モデルを説明せずに、CSRF やフレームオプションを無効化しないでください。
• パスの網羅範囲を確認せずに、デフォルトのマッチャーの動作に依存しないでください。
• 利便性を理由に、アクチュエーター、Swagger、内部診断機能を公開したままにしないでください。
• 主要なルートを対象とするテストなしに、セキュリティ設定を生成しないでください。
• 認証の失敗と認可の失敗を混同しないでください。

品質基準

このスキルを適切に実行すると、アクセスモデルが明確になり、監査可能になります。 適切でない実行では、ログインフローは動作しても、ルートの公開範囲、トークンの検証、テスト範囲が危険なほど曖昧なままになります。