複数プロトコルの連携ゲートウェイを、権限チェックを壊さず開発・レビューする

## 近くの指示を探し、食い違う時は動いているコードを優先する 最初にリポジトリ全体のガイドを読み、次に変更対象ファイルへ最も近い分野別の指示を探す。テスト、プラグイン、デプロイ用チャート、文書、プロトコルサーバー、高性能ランタイムには、それぞれ異なるワークフローがあり得る。根拠なしに、ある分野の規則を別の分野へ適用しない。 コードを変更するコントリビューター向けガイドと、エンドユーザー向けランタイム指示を区別する。デプロイ済みシステムを使うモデルやクライアント向けの資料が、コードベースを変更するエージェントを自動的に統制するわけではない。 編集前にシステムの構成を把握する。 - アプリケーションのエントリーポイントと環境設定。 - 検証スキーマ、永続化モデル、マイグレーション。 - 業務サービス、ルート、ミドルウェア、プロトコル転送方式。 - 認証、認可、プラグイン、連携境界。 - テスト、文書、デプロイ資産、管理インターフェース。 情報源が食い違う場合は、稼働中のコードと正式な設定、対応済みのビルドターゲットと依存関係、環境設定例、文書やコメントの順で優先する。古くなり得る件数や運用上限を記載する前に、現在の実装を確認する。 最初に有効なソースパスを調べる。依頼に明記されていない限り、一時作業場所、ログ、カバレッジ成果物、生成物、保留タスク用フォルダは対象外にする。 ## 変更のたびに、プロジェクトの検査と秘密情報のスキャンを通す 下位ツールをその場限りのフラグで直接呼ばず、リポジトリが対応するタスクランナーとバージョン固定済みのツールチェーンを使う。正式な例と照合して開発環境を検証し、必要な準備またはインターフェース生成の工程を実行して、タスクに合うローカルサーバーやテストモードを選ぶ。 コード変更後は次を行う。 1. 変更した言語とファイルを直接対象にする、整形、lint、型、安全性、文書の検査を実行する。 2. 反復中は範囲を絞った検査を使い、完了を提案する前にリポジトリ所定の総合品質ゲートを実行する。 3. 補助的なシステム言語や高性能ランタイムでは、整形検査、警告をエラーとして扱うlint、クレートまたはパッケージのテストを実行する。 4. 生成型の管理資産やクライアント資産の元データを変更した場合は、それらを再ビルドする。 5. 外部から観測できるすべての変更に、挙動テストを含める。 機密情報検出を品質ゲートとして使う。誤検出と確認できた場合、テストや例の挙動を変えない場所でのみ、プロジェクトが認めるインライン抑制を使う。それ以外では、承認済みベースラインを再生成して監査する。本物の認証情報を抑制せず、コミット対象の設定へ機密情報を置かない。 既存の言語、ビルド、自動化の仕組みを拡張する方法を優先する。プロジェクトがすでに備える手段では具体的な要件を安全に満たせない場合に限り、依存関係や新しいツールチェーンを追加する。 ## 見える範囲とできる操作を別々に確かめ、決まりの無い経路は拒否する 保護対象となるすべての経路で、独立した2つのセキュリティ層を維持する。 - スコープフィルタリングは、ある主体に見えるリソースを決める。 - ロールベース認可は、その主体が実行できる操作を決める。 一方の層を通過しても、もう一方の代わりにはならない。プラットフォーム公開スコープはプラットフォーム内での可視性であり、インターネットからの匿名アクセスを許すものではない。 各種の資格情報は、1つの正式なポリシー関数で正規化する。自己完結型または旧式APIの資格情報では、チームスコープが欠けているか空なら、失敗時に閉じる原則に従い、プラットフォーム内の公開範囲だけが見える状態にする。管理者による制約回避には、明示的な回避状態と確認済みの管理者資格の両方が必要になる。セッションに紐づく主体では、サーバー側に保存された所属情報と管理者状態を正本とし、資格情報内のクレームはアクセス範囲を狭めるためだけに使う。共通範囲が空なら、失敗時に閉じる。信頼済みの外部サインインから登録された主体も、外部の権限クレームを信頼せず、保存済みのローカル認可状態を使う。 次の不変条件を適用する。 - 転送セッションを確立したりメッセージを転送したりする前に認証し、操作を処理する前に操作権限を検査する。 - 明示的な認可マッピングがない保護対象ルートは、既定で拒否する。 - 所有者、チーム、セッション主体は、認証済みのサーバー側状態から導出する。クライアントが渡した所有者フィールドを信頼しない。 - 入ってくるクライアント資格情報をURLクエリパラメータから受け付けない。 - 高リスクな転送方式と無制限のクロスドメインルーティングは、既定で無効にする。 - ゲートウェイ間通信には、明示的なドメイン許可リストを必須とする。空の許可リストはすべての宛先を遮断する。 - 通信するゲートウェイ同士が同じ発行者を信頼するようにし、遠隔側の認可に必要な資格情報だけを伝える。 委任型の資格情報交換では、ユーザーから受け取った資格情報を下流サービスへ転送しない。信頼済み認可サーバーを介して交換し、交換済みの資格情報だけを転送する。設定された交換先をSSRFおよび外向き通信の境界として扱い、設定保存時に検証し、設定変更を特権主体へ限定し、相関識別子を記録する。受信した生の資格情報や交換後の資格情報をログへ記録しない。 セキュリティに影響する変更には、未認証、誤ったスコープ、権限不足、機能無効、許可されていない宛先、その他の拒否経路に対する回帰テストを含める。 ## トレースと監査ログの書き込みを、本体のトランザクションと分ける 永続化コードを変更する前に、意図されたトランザクション境界を理解する。リクエストデータ、可観測性記録、監査記録は、意図的に異なるセッションと原子性保証を使う場合がある。 ベストエフォートの可観測性書き込みでは、即時コミットする短命な独立セッションを使える。これにより主リクエストが失敗してもトレースとイベントは残るが、テレメトリはリクエストと原子的ではなく、部分状態や処理中の状態を示す場合がある。クエリ操作では、可視性と認可のフィルタを適用できるよう、引き続きリクエストスコープのセッションを使う。 監査ログも独自のセッションを持ち、自身の失敗を隔離できる。利便性だけを理由に、リクエスト側でコミット済みのセッションを独立した監査書き込み処理へ渡さない。2回目のコミットやロールバックによって共有トランザクションが無効になり、主要リソースが永続化された後でエラーが表面化する場合がある。監査記録を主要な書き込みと原子的にする必要があるなら、レビュー、新しい失敗時の意味、テストを必要とする明示的な設計変更として扱う。 独立したトレース処理は、1リクエストにつき複数のデータベースセッションを作ることがある。固定的な容量値を流用せず、並行数を測定し、プール枯渇の兆候を監視して、実際のデータベースと負荷に合わせてプール容量を決める。 根拠がないまま、非同期ハンドラー内で意図的に採用された同期永続化方式を、個別の不具合と判断しない。一部の呼び出し箇所だけを変換すると意味が混在し得るため、ドライバーとトランザクションを一体で移行する案を提示する。 ## 今のheadを確かめてから、データベースのマイグレーションを足す マイグレーションを作る前に、現在のマイグレーションheadを照会する。新しいリビジョンの親は、確認済みのheadを参照しなければならない。推測したり、古いファイルから親識別子をコピーしたりしない。作成後、履歴に意図したheadが正確に1つだけあることを確認する。 導入状態が異なる可能性がある場合は、冪等なマイグレーション手順を書く。変更前に現在のスキーマを検査し、任意のテーブルが存在しない場合は安全にスキップし、すでに存在する列やオブジェクトを追加しない。新規データベースの作成経路とアップグレード経路を一致させる。 ダウングレードがランタイム設定に依存する場合は、環境に依存せず再現できるようにする。 1. アップグレード中に、必要な各設定値をリビジョンをキーとするマイグレーション専用メタデータへ保存する。 2. ダウングレード中は、現在の環境ではなく保存済みスナップショットを読む。 3. スナップショット方式の導入前にアップグレードされたデータベースに限り、現在の設定を文書化済みの互換性用フォールバックとして使う。 4. ダウングレードが完了したらスナップショットを取り除く。 アップグレード用の初期データを入れるためだけに設定を読むマイグレーションは、ダウングレードもその値に依存するのでなければ、ダウングレード用スナップショットを必要としない。 編集後にheadを再確認し、関連するマイグレーションテストとアプリケーションテストを実行する。対象データベースが遅れている場合は、新しいリビジョンを生成する前に、管理された開発用またはテスト用データベースを想定headまで進める。明示的な許可とレビュー済み計画なしに、この是正アップグレードを本番環境へ実行しない。 ## 実際の検査結果を確かめ、pushの前に許可をもらう 元の依頼、最も近い分野別ガイド、上記のセキュリティ不変条件と照合して最終差分をレビューする。該当するlint、型検査、セキュリティスキャン、テスト、マイグレーション、生成資産、文書について、実際の結果を確認する。目視だけで成功と判断しない。 リポジトリ所定のコミット規約、署名ポリシー、issueへのリンク、プルリクエスト用テンプレートを使う。明示的な許可を得るまで、push、force-push、コントリビューターのブランチ変更、プロジェクト外部の状態変更を行わない。 公開レビューやissueコメントでは、次を守る。 - 懸念を挙げる前に、正常に機能している点を示す。 - ブロッカー、提案、軽微な注記を分ける。 - 不要な命令を出す代わりに、リスクを説明して質問や選択肢を示す。 - 厳しくも機械的にもならず、問題は率直に伝える。 製品差分や公開メッセージへ、内部アシスタントの署名、隠れた運用コメント、認証情報、推測に基づく工数表現を加えない。変更に本当に必要な場合に限り、新しいファイルや文書を作る。 作業をトリアージする際は、報告者からの情報待ち、依存関係によるブロック、承認済みだが延期された項目を区別する。問題を解決する変更がマージされた後にだけ、issueを解決済みとする。ローカルで実装しただけでは解決済みにしない。 完了前に、機密値がバージョン管理の対象外に保たれ、セキュリティの拒否経路にテストがあり、正本の優先順位が守られ、無関係な一時コンテンツが差分へ入っていないことを確認する。