Security

セキュリティ(防御)

目的

自動スキャンを含む攻撃は規模・知名度に関係なくすべてのサービスに到達する。このスキルは設計から運用まで一貫した防御層を構築し、侵害の発生確率と被害範囲を最小化することを目的とする。

使うタイミング

• 認証・認可・入力検証など、セキュリティに関わる機能を設計・実装するとき
• 既存コードのセキュリティを棚卸しし、リスクを整理したいとき
• リリース前に脆弱性の最終確認を行うとき
• インシデント発生後に類似の穴を潰す対策を検討するとき

設計原則

原則	内容
多層防御	1つの対策が破られても次の層で止める。単一の防御ラインに依存しない
最小権限	処理に必要な権限だけを付与。不要なアクセス権は持たせない
フェイルセキュア	エラー時はアクセスを拒否する方向に倒す。「失敗したら通す」は禁止
自作しない	認証・暗号化はフレームワークと実績あるライブラリの標準機構を使う。自作は必ず脆弱になる

領域別の対策

認証

• パスワードは bcrypt または argon2 でハッシュ保存。平文保存・MD5/SHA1での保存・自作ハッシュは禁止
• セッション/JWTには有効期限を設定し、ログアウト時の失効処理を実装する
• ブルートフォース対策: レート制限(例: 5回失敗で一定時間ロック)を必ず実装
• 多要素認証(MFA)はリスクに応じて検討。管理画面・特権操作には特に有効
• パスワードリセットはトークンに有効期限を設け、使用済みトークンは即廃棄

認可

実害が最も多い脆弱性カテゴリ。クライアント側の表示制御は防御ではない。

• すべてのAPIエンドポイントで「このユーザーがこのリソースにアクセスしてよいか」をサーバー側で検証
• IDOR(Insecure Direct Object Reference)対策: URLやパラメータのIDを書き換えられても他人のデータが見えないか確認
• 権限チェックのロジックは一箇所に集約し、分散させない(チェック漏れの温床になる)
• 水平権限昇格(同一権限レベルの他人のリソース)と垂直権限昇格(管理者権限への昇格)の両方を対策

入力検証とインジェクション対策

• SQL: プレースホルダ(パラメータバインド)を必ず使う。文字列結合によるクエリ組み立て禁止
• XSS: フレームワークの自動エスケープを活用。innerHTMLへの直接挿入禁止。Content Security Policy(CSP)ヘッダを設定
• コマンドインジェクション: ユーザー入力をシェルコマンドに渡さない。必要な場合は引数を厳密にバリデート
• パストラバーサル: ファイルパスにユーザー入力を使う場合は正規化後にベースディレクトリ内に収まるか検証
• バリデーションはサーバー側で必ず行う。クライアント側バリデーションのみは防御として機能しない

CSRF・CORS・セキュリティヘッダ

• CSRF: 状態変更を伴うリクエストにCSRFトークンを要求(フレームワークのCSRF保護機能を有効化)
• CORS: Access-Control-Allow-Origin: * と credentials: true の組み合わせは禁止。オリジンは明示的に許可リスト管理
• セキュリティヘッダ: 最低限 Content-Security-Policy、X-Frame-Options、X-Content-Type-Options、Strict-Transport-Security を設定

秘密情報管理

• APIキー・DBパスワード・秘密鍵は 環境変数またはシークレットマネージャ で管理
• リポジトリへのコミット禁止。.gitignore に .env を含める。万一コミットしたら即ローテーション
• ログへの出力禁止。エラーログにも認証情報が混入しないようフィルタを設ける
• .env.example に変数名のみを記載し、値は含めない

依存関係の管理

• npm audit / pip-audit / bundler-audit / Dependabot 等で脆弱性を継続監視
• CIパイプラインに脆弱性スキャンを組み込み、Critical/High は自動でブロック
• 不要な依存は増やさない。依存を追加するたびにメンテナンス状況を確認する
• 依存のトランジティブチェーン(間接依存)も対象に含める

データ保護

• PII(個人情報)は業務上必要な最小限だけ収集・保持する
• 通信は TLS(HTTPS)必須。HTTP へのフォールバックを許可しない
• 保存時の暗号化: 特に機密性の高いデータ(クレカ番号、マイナンバー等)は保存自体を避けるか暗号化
• 本番環境でエラーのスタックトレース・内部パスをユーザーに見せない。ログには残し、レスポンスには汎用メッセージのみ返す

監査ログ

• 認証イベント(ログイン成功・失敗・ログアウト)を必ず記録
• 権限変更・重要なデータ操作(削除・エクスポート等)のログを残す
• ログには「誰が・いつ・何を・成功/失敗」の4要素を含める
• 詳細は [[monitoring-operations]] を参照

進め方

1. 脅威モデリング: 「何を守るか(資産)」「誰が攻撃者か」「どう攻撃されるか」を一覧化。STRIDE(Spoofing/Tampering/Repudiation/Information Disclosure/Denial of Service/Elevation of Privilege)フレームワークを使うと抜け漏れが減る
2. OWASP Top 10 との照合: 自サービスがどのリスクカテゴリに該当するか確認し、対策優先度を決める
3. 設計フェーズの対策: 認証・認可・データフローを設計段階で決定。後付けが最もコストが高い
4. 実装フェーズの対策: 領域別対策を実装しながらコードレビューで確認(下記チェックリスト使用)
5. リリース前の確認: セキュリティチェックリストの「リリース前」段階をすべてパスしてからリリース
6. 継続監視: 依存脆弱性スキャン・ログ監視・インシデント対応手順の整備

成果物テンプレート

# セキュリティチェックリスト

## 設計時
- [ ] 脅威モデリングを実施し、主要な脅威を一覧化した
- [ ] 認証方式(セッション/JWT)と有効期限・失効ポリシーを決定した
- [ ] 認可モデルを定義し、全エンドポイントの権限要件を明示した
- [ ] 機密データの範囲を特定し、暗号化・最小収集の方針を決めた
- [ ] 秘密情報(APIキー等)の管理方法を決定した

## 実装時
- [ ] パスワードはbcrypt/argon2でハッシュ保存している
- [ ] ブルートフォース対策(レート制限・ロックアウト)を実装した
- [ ] 全APIエンドポイントでサーバー側の認可チェックを実装した
- [ ] IDORを検証した(URLのIDを書き換えても他人のデータにアクセスできないか)
- [ ] SQLはプレースホルダを使用し、文字列結合クエリが存在しない
- [ ] 出力エスケープ・CSPヘッダでXSSを対策した
- [ ] CSRFトークンを実装した(状態変更を伴う操作)
- [ ] CORSの許可オリジンを明示的に設定した
- [ ] セキュリティヘッダ(CSP/X-Frame-Options/HSTS等)を設定した
- [ ] .envをgitignoreに追加し、秘密情報をリポジトリに含めていない
- [ ] ログに認証情報・個人情報が出力されないことを確認した
- [ ] 本番エラーレスポンスにスタックトレースが含まれない
- [ ] 認証イベント・重要操作の監査ログを実装した

## リリース前
- [ ] npm audit / pip-audit 等でCritical/High脆弱性がゼロ
- [ ] OWASP Top 10 の各項目と自サービスの対策を照合した
- [ ] HTTPS(TLS)のみで動作し、HTTP→HTTPSリダイレクトが機能する
- [ ] 管理画面への認証・認可が正しく機能することを確認した
- [ ] CI/CDパイプラインに脆弱性スキャンを組み込んだ
- [ ] インシデント発生時の対応手順(連絡先・ログ確認方法等)を用意した

チェックリスト

• 自作認証・自作暗号化を使っていないか確認した
• クライアント側バリデーションのみに依存している箇所がないか確認した
• すべてのAPIエンドポイントにサーバー側認可チェックを実装した
• 依存脆弱性スキャンをCIに組み込んだ
• 秘密情報がリポジトリやログに漏れていないか確認した
• 本番エラーレスポンスが内部情報を露出していないか確認した
• セキュリティヘッダを設定した

アンチパターン

• 自作認証・自作暗号: 「シンプルな方が安全」という誤解から自前実装する。必ず既知の脆弱性を持つ
• クライアント側バリデーションのみ: ブラウザの検証はUXのためのもの。攻撃者はAPIを直接呼ぶ
• エラーで内部情報を露出: スタックトレース・DB構造・ファイルパスをレスポンスに含める。攻撃の足がかりになる
• 管理画面をURLの隠蔽だけで保護: /admin-secret-path は認証の代替にならない。認証・認可を必ず実装する
• 「個人開発だから狙われない」という思い込み: 自動スキャンツールは無差別にすべてのIPに届く。公開した瞬間から標的になる
• セキュリティを後回し: リリース直前に「セキュリティ対策してない」と気づく。設計フェーズで組み込む
• ワイルドカードCORSと認証情報の併用: Access-Control-Allow-Origin: * + credentials: true はブラウザが拒否するだけでなく設定ミスが致命的になる
• 依存パッケージの放置: 一度インストールしたライブラリを更新しない。脆弱性が積み上がる

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当作業	具体的な使い方
司令塔(メインモデル)	脅威モデリング・リスク受容の判断・対策優先度の決定	STRIDEフレームワークを使って脅威を一覧化し、どのリスクをいつまでに対策するか判断する。サブエージェントの成果物を統合してセキュリティ設計書に仕上げる
Opus相当	認証認可設計のレビュー・脆弱性の精査	「この認可ロジックにIDORが残っていないか」「JWTの失効設計は正しいか」等、判断が難しい脆弱性を深く分析させる
Sonnet相当	チェックリストに沿った監査・対策実装	セキュリティチェックリストを渡して「この実装のどの項目が未対応か報告せよ」と指示する。CSPヘッダ設定・CSRFトークン実装などの定型対策の実装も担当
Haiku相当	依存脆弱性スキャン結果の収集・ログの一次調査	npm audit --json の出力を渡して「Critical/Highの一覧と影響パッケージを抽出せよ」と指示する。ログファイルからエラーパターンを収集する軽作業も適任

関連スキル

• [[orchestration]] — 多エージェント並列実行の共通原則
• [[code-review]] — セキュリティ観点を含むコードレビュー
• [[non-functional-requirements]] — セキュリティ要件の定義・文書化
• [[architecture-design]] — セキュリティを考慮したアーキテクチャ設計
• [[api-design]] — APIエンドポイントの認証・認可設計
• [[monitoring-operations]] — 監査ログ・インシデント対応の運用
• [[database-design]] — DBアクセス権限・暗号化の設計
• [[cicd-deployment]] — CIへの脆弱性スキャン組み込み
• [[legal-compliance]] — 個人情報保護法・GDPR等の法的要件との整合