本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第1弾として、セキュリティアーキテクチャの全体像について解説する記事です。
セキュリティは後から付け足せない設計領域。本記事ではCIA3要素、認証・認可・暗号化・ネットワーク・秘密情報管理・監査の主要領域、境界型防御からゼロトラストへの潮流、AI時代にセキュリティは委譲するというスタンスまで俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』・『安全なWebアプリケーションの作り方 第2版』も参考にしてみてください。
そもそもセキュリティアーキテクチャとは何か
家のセキュリティを想像してください。玄関の鍵・窓の防犯フィルム・監視カメラ・火災報知器──1つの対策だけでは守れず、複数の層で守るのが防犯の基本です。しかも、家を建てた後に基礎部分のセキュリティを追加するのは極めて困難です。
セキュリティアーキテクチャは、認証・認可・暗号化・ネットワーク防御・秘密情報管理・監査ログなどを多層的に設計する領域です。後から付け足すのではなく、設計の最初から組み込むことが必須です。
もしセキュリティアーキテクチャがなければ、たった1箇所の穴から全データが漏洩し、漏れたデータは二度と未公開には戻りません。謝罪では済まない損害が発生します。
一度漏れたデータは、二度と未公開には戻らない
従来は「ファイアウォールで境界を守る」境界型防御が中心でしたが、リモートワーク・クラウド・SaaSの普及で境界が曖昧になり、ゼロトラスト（全てを信用せず常に検証する）が本命の思想になりました。
セキュリティは後から付け足せない設計領域。漏れたデータは、謝罪しても戻ってきません。
なぜ独立したアーキテクチャとして扱うか
① 影響範囲が全システムに及ぶ
認証基盤・暗号化方式・権限モデルは、後から変えると全てのアプリケーションに影響が出ます。最上流で決めないと、あとで総入れ替えになります。
② 法規制・コンプライアンス対応が必須
GDPR（EU一般データ保護規則）・個人情報保護法・PCI DSS（クレカ情報取扱基準）・SOC2（クラウド事業者の内部統制基準）等、システムが扱うデータによって守るべき規制が決まります。規制違反は刑事罰・巨額賠償に直結します。
③ 専門性が高く兼務しにくい
暗号化・脆弱性診断・SOC運用などは専門家の領域で、片手間では扱えません。セキュリティ専任チーム（CSIRT、Computer Security Incident Response Team）を置く組織も増えています。
守るべき3要素（CIA）
セキュリティアーキテクチャで最もよく使われるフレームワークがCIAです。3要素のどれを最優先するかで、設計の軸が変わります。
| 要素 | 意味 | 代表的な対策 |
|---|---|---|
| Confidentiality（機密性） | 許可された人だけが見られる | 認証・認可・暗号化 |
| Integrity（完全性） | データが改ざんされない | ハッシュ・署名・監査ログ |
| Availability（可用性） | 必要な時に使える | DDoS対策・冗長化・バックアップ |
機密情報を扱う金融は機密性最優先、公共サービスは可用性最優先など、業務特性で比重が変わるのが重要ポイントです。
主要な領域の分類
| 領域 | 扱うもの |
|---|---|
| 認証（Authentication） | 誰であるかの確認 — ID/パスワード・Passkey（パスワード不要の生体認証）・MFA（多要素認証） |
| 認可（Authorization） | 何ができるかの制御 — RBAC（役割ベース権限）・ABAC（属性ベース権限）・IAM（ID権限管理） |
| 暗号化 | 盗聴・漏洩防止 — TLS（通信暗号化）・AES（共通鍵暗号規格）・KMS（鍵管理サービス） |
| ネットワーク | 境界防御・分離 — FW（ファイアウォール）・WAF・VPC（Virtual Private Cloud、仮想プライベート網） |
| 秘密情報管理 | APIキー・パスワードの保管 — Vault・Secrets Manager |
| 監査・検知 | 異常の記録と検知 — SIEM・CloudTrail・WAFログ |
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
認証・認可・セッション
| 項目 | 選択肢の例 |
|---|---|
| 認証方式 | パスワード＋MFA・Passkey・SSO・SAML（XML形式の認証連携標準）・OIDC |
| 認証基盤 | 自前実装・Auth0・Clerk・Cognito・Entra ID |
| 認可モデル | RBAC・ABAC・ReBAC（関係ベース権限）・ポリシー言語（OPA（Open Policy Agent、汎用ポリシーエンジン）） |
| セッション方式 | Cookie・JWT・Refresh Token |
| MFA方式 | TOTP（時間同期型ワンタイムパスワード）・WebAuthn（ブラウザ標準の生体・デバイス認証）・SMS |
| パスワードポリシー | 長さ・複雑性・ローテーション |
暗号化・鍵管理
| 項目 | 選択肢の例 |
|---|---|
| 通信暗号化 | TLS 1.3・mTLS（mutual TLS、双方向証明書認証） |
| 保存時暗号化 | AES-256・KMS / HSM |
| 秘密情報管理 | AWS Secrets Manager・HashiCorp Vault |
| 鍵管理 | クラウドKMS・顧客管理鍵（CMK、Customer Managed Key） |
| 公開鍵基盤 | 内部CA（Certificate Authority、証明書発行局）・Let’s Encrypt・ACM（AWS Certificate Manager） |
ネットワーク・監査・コンプライアンス
| 項目 | 選択肢の例 |
|---|---|
| ネットワーク分離 | VPC・サブネット・セキュリティグループ |
| 境界防御 | WAF・IDS/IPS（Intrusion Detection/Prevention System、侵入検知/防止）・DDoS対策 |
| ゼロトラスト | BeyondCorp・Zscaler・Cloudflare Access |
| 監査ログ | CloudTrail・監査証跡の保存期間 |
| 脆弱性管理 | SAST・DAST（Dynamic〜、動的解析）・依存ライブラリスキャン |
| コンプライアンス | SOC2・ISO 27001（情報セキュリティ国際規格）・PCI DSS |
セキュリティ思想の変遷
「境界型防御」から「ゼロトラスト」への移行は、クラウド時代で最も大きなパラダイムシフトです。境界型では社内ネットワークは安全という前提で設計していましたが、リモートワーク・SaaS利用・内部不正の増加により、この前提が成立しなくなりました。
ゼロトラストはネットワークの内も外も信用せず、全ての通信で認証・認可を検証する思想で、Googleが2010年代に実装した BeyondCorp が先駆けです。VPNに頼らず、ユーザー・デバイス・コンテキストを常に検証します。
| 境界型防御 | ゼロトラスト |
|---|---|
| 内側 = 信頼、外側 = 不信 | 全てを不信から始める |
| VPNで境界を守る | 全通信で認証・認可 |
| ネットワーク中心の設計 | IDベース（Identity-centric） |
| 社内ネットワークに強く依存 | 場所を問わず同じ扱い |
フェーズ別セキュリティ導入ロードマップ
セキュリティは「全部一気には非現実的」フェーズに応じて必須/推奨を切り分けます。
| フェーズ | 組織規模 | 必須導入 | 次に導入 | 月額コスト |
|---|---|---|---|---|
| ① MVP・個人 | 〜3人 | HTTPS + MFA + Dependabot + IAM Role | Secret Scanning | 0円 |
| ② 初期スタートアップ | 3〜30人 | + WAF + CloudTrail + 暗号化 | GuardDuty + SSO | 数万円 |
| ③ 中規模SaaS | 30〜300人 | + SIEM + 脆弱性スキャンCI | SOC2 + ISMS + Policy as Code | 数十万円 |
| ④ 大企業 | 300人〜 | + 24/7 SOC + DLP + ZTNA | Red Team演習・ペネトレ年次 | 数百万円 |
| ⑤ 規制業種 | 全規模 | 業界認定（FISC / HIPAA / ガバメントクラウド） | — | 変動 |
「MVPでもMFA・Dependabot・Secret Scanning・HTTPSの4つは必須」これを後回しにすると公開後数時間で IAMキー流出・依存ライブラリ経由侵入を食らいます。2021年 Log4Shell・2022年 Okta / LastPass 事件がその代償を示しました。
MVPでも最低4点セットは即日入れる。セキュリティに「後で」は存在しません。
このカテゴリの知識構造
このカテゴリは全8記事で構成されています。セキュリティの設計領域を「誰か」→「何ができるか」→「どう守るか」→「どう検知するか」の4段階で学ぶ構造です。
**ID（グループ1）**では、最初に「誰であるか」を確認する認証と、「何ができるか」を制御する認可を設計します。認証と認可は混同されがちですが、全く別の設計判断です。
**保護（グループ2）**では、IDが確定した前提で、通信の暗号化・ネットワーク境界・ゼロトラスト・秘密情報管理を設計します。この4記事は互いに独立性が高いため、必要なものから読んで問題ありません。
**検知（グループ3）**の脆弱性診断は、防御体制を敷いた上で穴を探し続ける仕組みを整える記事です。セキュリティは一度設計したら終わりではなく、継続的な検知が不可欠です。
やってはいけないこと
各論記事で触れた禁じ手のうち、セキュリティアーキテクチャレベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 認証を自前実装 | Clerk / Auth0 / Firebase Authへ委譲、自作は穴だらけ |
| JWTをlocalStorage保存 | XSS一発で全員分漏洩、httpOnly Cookie必須 |
| SMS MFAだけに依存 | SIMスワップで突破、TOTP / FIDO2必須 |
| Criticalパッチを2週間以上放置 | Equifax 2017年事件（7億ドル和解金）のパターン、72時間以内がSLA |
| 「社内は安全」の境界型防御 | 2021年Pulse Secure事件、ZTNAへ移行 |
| 永続API Keyを本番で運用 | OIDC + 短命トークンへ |
| 個人情報をマスキングせずログ出力 | GitHub 2018年平文パスワード事件のパターン |
| SBOMなし | Log4Shellで「自社に影響があるか不明」事態 |
| セキュリティ設定をGUI手作業 | 変更履歴なし、IaC + Policy as Codeへ |
| パスワードをSHA-256単独ハッシュ | Argon2id必須、GPU総当たり対策 |
| 「社内ネットワークは安全」と思い込む | 境界型防御の前提崩壊、ゼロトラストが標準 |
| 「認証は自前で作れる」と独自実装 | バグと脆弱性の温床、標準プロトコル＋SaaSに委譲 |
セキュリティは「書くな、借りろ、見張れ」の3点セット。独自実装が最大の事故源です。
AI判断軸
| AI時代に有利 | AI時代に不利 |
|---|---|
| 標準プロトコル（OIDC・OAuth・SAML） | 独自認証・独自暗号化 |
| 専用SaaS（Clerk・Auth0・Entra ID） | 手書き実装の認証システム |
| IaCで記述されたIAM・セキュリティ設定 | GUI設定の属人化した権限管理 |
| ポリシー言語（OPA・Cedar）での認可 | コード内にif文でベタ書きの権限判定 |
- 標準プロトコルと専用SaaSに委譲 — 認証・認可・暗号化は独自実装しない
- 多層防御を前提に設計 — 単発対策ではなく、ネットワーク・認証・暗号化を重ね合わせる
- ゼロトラストを出発点 — 「社内は安全」を捨て、全通信で認証・認可を検証する
- IaCで記述しレビュー可能に — GUI設定の属人化を避け、Git管理で証跡を残す
AI生成コードに混入する脆弱性パターン
AIが生成するコードには、セキュリティ上の問題が一定の確率で混入します。具体的に多いのは、SQLクエリの文字列結合（パラメータバインドの省略）、ユーザー入力のサニタイズ漏れ（XSS）、認可チェックの欠如（APIエンドポイントに認証だけで認可なし）です。
これらはAIが「動くコード」を優先した結果であり、意図的に脆弱なコードを書いているわけではありません。対策はCIパイプラインにSAST（Semgrep・CodeQL）を組み込み、AI生成コードを含むすべてのプッシュを自動検査することです。
セキュリティ設定を「委譲」するとAIの管理対象から外れる
認証をAuth0/Clerkに委譲し、WAFをCloudflareに委譲し、暗号化をKMSに委譲する――この「書くな、借りろ」の方針は、AI時代にもう一つのメリットがあります。委譲した領域はSaaS側が常に最新のセキュリティパッチを適用するため、自チームのコードベースにセキュリティ負債が蓄積しません。AIが管理すべきセキュリティ設定の範囲を最小化できるのです。
筆者メモ — 「防げたはずの一撃」が企業を傾けた事例
セキュリティ事故は派手な攻撃より基本の怠りで起きる、という話がよく聞かれます。
ある大手信用情報会社では、2017年に Apache Struts の既知脆弱性（CVE-2017-5638）への「パッチ適用が2か月遅れた」ことが原因で、約1.47億人分の個人情報が流出しました。この1社の事件は、最終的に和解金・罰金あわせて約7億ドル規模まで膨れ上がり、「パッチ遅延」という地味な怠りがいかに致命傷になるかを示す語り草になっています。
同じく2019年には、米大手金融サービスで「WAFの設定ミス」（サーバ側リクエスト偽造＝SSRF）を起点に、約1億人分の顧客情報がS3バケットから流出した事例があります。攻撃者は元クラウドエンジニアで、「設定の一行の甘さ」を突きました。同社は米当局から8,000万ドル規模の制裁金を受けています。
筆者も過去、些細な設定ミスがログに記録されていたのを半年後に気づく、というヒヤリ経験があります。どちらも高度なゼロデイではなく「基本の運用」が崩れた事例で、地味な基本こそが最強の防御であることを突きつけます。
セキュリティは派手な攻撃より基本の怠りで事故る。パッチ・MFA・設定レビューが最強の防御です。
まとめ
本記事はセキュリティアーキテクチャの全体像について、CIAの基本・主要領域・境界型からゼロトラストへの潮流・フェーズ別ロードマップ・AI時代の委譲スタンスまで含めて解説しました。如何だったでしょうか。
標準プロトコルと専用SaaSに委譲し、多層防御で設計し、ゼロトラストを出発点に置き、IaCでレビュー可能にする。これが2026年のセキュリティアーキテクチャの現実解です。
次回は認証設計（MFA・Passkey・SSO・IDaaS選定）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は OWASP Foundation も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（46/89）