reviewing-security-architecture

認証アーキテクチャ

トークンの取り扱い

トークンベース認証について、次の点を確認してください。

項目	セキュアなパターン	アンチパターン
発行	リフレッシュ機構を備えた有効期間の短いトークン	期限切れにならない有効期間の長いトークン
検証	すべてのリクエストで署名、発行者、オーディエンス、有効期限を検証する	署名のみを検証する、または「内部」呼び出しでは検証を省略する
保存（サーバー）	ステートレスな JWT またはサーバー側のセッションストア	トークンをクエリ文字列または URL に保存する
保存（クライアント）	HttpOnly Secure Cookie または安全なプラットフォームストレージ	localStorage、sessionStorage、または HttpOnly／Secure フラグのない Cookie
更新	リフレッシュトークンのローテーション（使用時に古いリフレッシュトークンを無効化する）	ローテーションを行わず再利用可能なリフレッシュトークン
失効	トークンのブロックリスト、または短い有効期限とリフレッシュトークンのローテーション	漏えいしたトークンを失効させる仕組みがない

セッション管理

• サーバー側のセッションには、絶対タイムアウト（セッションの最大継続時間）とアイドルタイムアウトを設定する必要があります
• セッション識別子は、暗号学的にランダムで、十分な長さ（128 ビット以上のエントロピー）を持つ必要があります
• 認証状態が変化した後（ログイン、権限昇格時など）は、セッション ID を再生成してください
• 可能であれば、異常検知のためにセッションをクライアントの特性（IP 範囲、ユーザーエージェント）に紐付けてください

認証情報の保存

• パスワードは、最新の KDF（推奨は Argon2id、または bcrypt、もしくは高い反復回数と一意のソルトを使用した PBKDF2）でハッシュ化する必要があります
• パスワードのハッシュ化に、暗号学的ハッシュ関数のみを単独で使用しないでください（処理が速すぎ、デフォルトではソルトもありません）
• 総当たり攻撃をレインボーテーブルで高速化されないよう、認証情報ごとに一意のソルトを使用してください

認可パターン

ロールベースアクセス制御（RBAC）

// CORRECT — explicit role check at the API layer
[Authorize(Roles = "Admin")]
public async Task<IActionResult> DeleteUser(Guid userId)

// WRONG — checking role in business logic with string comparison
if (currentUser.Role == "admin") // Fragile, case-sensitive, easy to bypass

オブジェクトレベルの認可

// WRONG — trusts the userId from the route, no ownership check
public async Task<Cipher> GetCipher(Guid cipherId) {
    return await _cipherRepository.GetByIdAsync(cipherId);
}

// CORRECT — verify the requesting user owns the resource
public async Task<Cipher> GetCipher(Guid cipherId) {
    var cipher = await _cipherRepository.GetByIdAsync(cipherId);
    if (cipher.UserId != _currentContext.UserId)
        throw new NotFoundException();
    return cipher;
}

認可の原則

• すべての層で確認する。 API コントローラー、サービス層、データアクセス層のすべてで認可を適用してください。単一の確認ポイントだけに依存しないでください。
• 最小権限。 必要最小限の権限を付与してください。デフォルトでは拒否してください。
• フェイルクローズ。 認可チェックに失敗した場合や例外が発生した場合は、アクセスを拒否してください。フェイルオープンにしてはいけません。
• クライアント側の認可を信頼しない。 UI の表示制御は UX のためのものであり、セキュリティ対策ではありません。必ずサーバー側で適用してください。

データ保護

保存データの暗号化

• すべての機密データは、AES-256 または同等の方式を使用して保存時に暗号化する必要があります
• 暗号鍵は、別の鍵でラップされていない状態で、データベース内に直接アクセス可能な形で保存してはなりません
• エンベロープ暗号化を使用してください。データをデータ暗号化鍵（DEK）で暗号化し、DEK を鍵管理システム内の鍵暗号化鍵（KEK）で暗号化します
• Bitwarden のエンドツーエンド暗号化により、保管庫のデータはクライアントを離れる前に暗号化されます

通信時の暗号化

• TLS 1.2 以上を使用し、TLS 1.3 を推奨します
• 古いプロトコル（SSL 3.0、TLS 1.0、TLS 1.1）を無効にしてください
• 強力な暗号スイート（鍵交換に ECDHE、暗号化に AES-GCM）を使用してください
• 適切な場合は、モバイルアプリで証明書ピンニングを使用してください
• 内部のサービス間通信にも TLS を使用してください

データの分類

アーキテクチャをレビューする際は、データを次の分類に従って特定します。

分類	例	必要な保護
重要	暗号化キー、マスターパスワード、保管庫データ	エンドツーエンド暗号化、HSM でのキー保管
機密	PII、メールアドレス、請求情報	保存時および転送時の暗号化、アクセスログ
内部	組織の設定、機能フラグ	転送時の暗号化、ロールベースのアクセス制御
公開	マーケティングコンテンツ、公開 API ドキュメント	完全性の保護

信頼境界

信頼レベルの異なるコンポーネント間でデータがやり取りされる箇所には、信頼境界が存在します。境界を越えるたびに、必ず検証してください。

一般的な信頼境界

Client ←→ API Gateway         (user-controlled → server-controlled)
API Gateway ←→ Backend Service (internet-facing → internal)
Backend Service ←→ Database    (application → data store)
Service ←→ External API        (internal → third-party)
Browser ←→ Browser Extension   (page context → extension context)
Main Thread ←→ Web Worker      (different execution contexts)

信頼境界での検証

境界を越えるたびに、次のことを行います。

1. すべての入力を検証する — 型、形式、範囲、長さを確認します。上流での検証を信用しないでください。
2. 呼び出し元を認証する — リクエストを処理する前に、ID を確認します。
3. 操作を認可する — 呼び出し元にその特定の操作を実行する権限があることを確認します。
4. 出力をサニタイズする — 出力先のコンテキストに適した方法で、データをエンコードまたはエスケープします。
5. 境界の通過を記録する — セキュリティ上重要な境界の通過は、監査可能な状態にします。

ゼロトラストの原則

• 内部ネットワーク上にあることを、認証の代わりとして信用しないでください。
• サービス間のすべての呼び出しで、認証と認可を行ってください。
• ネットワークは侵害されているものと想定し、内部通信をすべて暗号化してください。
• 内部サービスからのデータも、外部入力と同じ厳格さで検証してください。

アーキテクチャ上の意思決定との整合性

設計を評価する前に、レビュー対象のコンポーネントに関係する既存の決定がないか、Bitwarden の Architecture Decision Records を確認してください。基本ルールについては ${CLAUDE_PLUGIN_ROOT}/references/adr-alignment.md を参照してください（矛盾は指摘事項、文書化されていない重要な決定はギャップです。引用する前にステータスを確認してください）。特にアーキテクチャレビューを実施する際は、次の点に留意してください。

• 指摘するだけでなく、引用してください。 設計が承認済みの ADR と矛盾する場合は、ADR の名前を挙げ、実装を変更すべきか、例外を正当化する独自の ADR が必要かを明記してください。
• 次のギャップのきっかけに注意してください。 新たな信頼境界、新たな認証パターン、新たなデータストア、またはその他の重要な選択に対応する ADR がない場合は、実装するだけでなく記録に残すべき重要な決定として指摘してください。

参考資料

詳細な参照表やコード例については、次を参照してください。

• references/crypto-algorithms.md — アルゴリズムの選択表（推奨と非推奨）および一般的な暗号処理のアンチパターンのコード例
• references/architectural-anti-patterns.md — 一般的なセキュリティアーキテクチャのアンチパターン（暗黙の信頼、単一障害点、安全でないデフォルト設定、モノリシックな認証）とその修正方法

脅威モデリングとの関連

アーキテクチャのセキュリティレビューは、脅威モデリングのプロセスに直接反映されます。

• 信頼境界の特定は、データフロー図に境界を引く位置の判断に役立ちます。
• アーキテクチャ上の弱点は、脅威カタログにおける脅威になります。
• セキュリティプロパティ（認証、暗号化、アクセス制御）は、セキュリティ定義におけるセキュリティ目標に対応します。
• 発見されたアンチパターンは、Bitwarden のエンゲージメントモデルのフェーズ 1「初期セキュリティ評価」の候補になります。

アーキテクチャレビューを実施する際は、調査結果を踏まえて AppSec チーム（#team-eng-appsec）に依頼し、脅威モデリングのセッションを実施する必要があるかどうかを検討してください。