セキュリティ設計原則

セキュリティ設計原則とは、システムを設計する段階からセキュリティを組み込む「Security by Design」の考え方に基づく基本的な指針群である。セキュリティを後付けで追加しようとすると根本的な設計変更を要することが多く、コストが大幅に増大する。一方、設計の初期段階でセキュリティを考慮することで、脆弱性を構造的に排除できる。

最小権限の原則（Principle of Least Privilege）は、ユーザーやプロセスが必要最低限の権限のみを持つべきという考え方である。データベースのサービスアカウントに管理者権限を与えるといった過剰付与は、侵害時の被害範囲を広げる。多層防御（Defense in Depth）は複数の防御層を重ね、一つの防御が突破されても他の層が守るという設計思想であり、ネットワーク・アプリケーション・データの各層で独立した防御策を設ける。

ゼロトラストアーキテクチャは「何も信頼しない」を原則とし、社内ネットワークからのアクセスであっても認証と認可を省略しないという現代的なアプローチである。従来の「城壁型（境界型）セキュリティ」は内部ネットワークを信頼するため、一度侵入されると内部での横移動（Lateral Movement）を許してしまう。ゼロトラストはこの課題に対応するための設計思想として急速に普及している。

コードレビューで着目するポイント

サービスアカウントやIAMロールに過剰な権限が付与されていないか（必要なリソースのみにスコープが絞られているか）
認証と認可が異なる層に分離して実装されているか（認証済み = 全権限ではない設計か）
フェイルセーフ設計になっているか（エラー発生時にデフォルトで拒否する設計か、許可する設計か）
攻撃面積（Attack Surface）を最小化するために、不要なエンドポイント・ポート・機能が無効化されているか
秘密情報（APIキー・パスワード）がコードや設定ファイルにハードコードされていないか
依存ライブラリに既知の脆弱性がないか（Dependabot・npm audit等で定期的にスキャンされているか）
セキュリティイベント（認証失敗・権限エラー・不審なアクセス）が適切にログに記録されているか

典型的なアンチパターン

フェイルオープン設計: エラーや例外が発生したときに、アクセスを拒否するのではなく許可してしまう設計。たとえば認証チェックが例外を投げた場合に catch ブロックで認証済みとして処理を続行するコードは重大な脆弱性になる。

過剰なIAM権限: 「とりあえず管理者権限を与えておけば動く」という開発の利便性を優先した権限設定が本番環境にそのまま持ち込まれるケース。侵害時の被害範囲を最小化するために、最小権限の設計をプロジェクト初期から組み込む必要がある。

境界型セキュリティへの過信: VPN内や社内ネットワーク内のトラフィックを無条件に信頼する設計は、内部からの脅威や侵入後の横移動に対して無防備になる。サービス間通信にもmTLS等での認証を適用するゼロトラスト設計が現代のスタンダードである。

参考リソース

標準: OWASP Top 10 - Webアプリケーションの最重要セキュリティリスクの定期的な更新リスト
標準: NIST Zero Trust Architecture（SP 800-207） - ゼロトラストアーキテクチャの公式仕様
書籍: 「The Web Application Hacker’s Handbook」（Stuttard, Pinto） - 攻撃者の視点からセキュリティ設計を学ぶ実践書
ツール: Dependabot - 依存ライブラリの脆弱性を自動検出するGitHub標準ツール
ツール: Trivy - コンテナイメージ・IaCの脆弱性スキャンツール