本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第8弾として、インフラ層で張り巡らすセキュリティ基盤の全体地図について解説する記事です。
WAF・DDoS対策・IDS/IPS・IAM・暗号化・シークレット管理を多層で重ねるのが基本で、後から追加するとコストが跳ね上がる領域です。本記事ではシステムアーキテクチャ段階で組み込むべき機能の全体地図を扱い、個別領域の深掘り（認証方式・認可モデル・暗号アルゴリズム・脆弱性診断）は別カテゴリ「セキュリティアーキテクチャ」に委ねます。
このカテゴリの他の記事
「ウチは小さいから狙われない」が一番危ない
公開されたIPアドレスは、Botに24時間365日スキャンされています。小さな個人サービスでも、公開した瞬間からブルートフォース・脆弱性スキャン・ポート探索の対象になります。「まだ誰も知らないから大丈夫」という前提は、インターネットでは一度も成立したことがない発想です。
検証用に立てた小さなAPIサーバーが24時間後にはログに数千件のスキャンアクセスが記録されていた、という経験は珍しくありません。攻撃者は人間ではなくBotで、標的を選ばず全IPを順にスキャンしています。規模とは無関係に、「公開した瞬間に攻撃対象」と考えるのが正解です。
セキュリティは「後付け不可」最初からインフラに組み込むのが鉄則です。
本記事の守備範囲
本記事は「システムアーキテクチャ段階で、インフラ層にどんなセキュリティ機能を組み込むかの全体地図」を示すことに徹します。個別領域の深掘り（認証方式・認可モデル・暗号アルゴリズム・脆弱性診断手法など）は全て別カテゴリ「セキュリティアーキテクチャ」の各記事に集約しています。
| 個別領域 | 深掘り先 |
|---|---|
| 認証（MFA・Passkey・SSO） | 認証設計（別カテゴリ） |
| 認可・IAM（RBAC・最小権限） | 認可とIAM（別カテゴリ） |
| 暗号化（TLS・KMS・鍵管理） | 暗号化（別カテゴリ） |
| WAF・DDoS・IDS/IPS・VPN | ネットワークセキュリティ（別カテゴリ） |
| ゼロトラスト・ZTNA | ゼロトラスト（別カテゴリ） |
| シークレット管理 | 秘密情報管理（別カテゴリ） |
| 脆弱性診断・SBOM | 脆弱性診断（別カテゴリ） |
本記事の問いは「システムアーキテクチャのどこで何を組み込むか」具体の選定は別カテゴリの各記事で深掘りします。
多層防御（Defense in Depth）
多層防御は、攻撃を単一の防御ラインに頼らず複数の層で阻止する考え方です。一つの防御が破られても次の層で止められるように、入口から内側まで複数のゲートを設けます。
flowchart TB
NET([インターネット<br/>= 攻撃者を含む全世界]) --> WAF
WAF[WAF<br/>SQLi / XSS 遮断]
DDOS[CDN / DDoS対策<br/>大量リクエスト吸収]
ALB[ALB / SG / NACL<br/>ポート・IP・プロトコル制御]
AUTH[アプリ認証認可<br/>ユーザー・権限確認]
DB[(DB暗号化<br/>データ本体保護)]
WAF --> DDOS --> ALB --> AUTH --> DB
classDef threat fill:#fee2e2,stroke:#dc2626;
classDef edge fill:#fef3c7,stroke:#d97706;
classDef net fill:#f0f9ff,stroke:#0369a1;
classDef app fill:#dbeafe,stroke:#2563eb;
classDef data fill:#fae8ff,stroke:#a21caf;
class NET threat;
class WAF,DDOS edge;
class ALB net;
class AUTH app;
class DB data;入口で全部止めるのは非現実的です。「どこかで突破される前提」を置き、被害を最小化する設計に振ります。クラウドセキュリティの本命はこの多層防御＋ゼロトラストで、ここから外れる構成はもう選ばれません。
攻撃を単一の壁で止めない。破られても次で止まる設計が基本です。
セキュリティ基盤の主要ビルディングブロック
システムアーキテクチャ設計時に「ここに何を置くか」を決めるべき構成要素の一覧です。各要素の詳細（製品選定・設定値・運用ルール）は別カテゴリの記事で深掘りします。本記事では配置と抜け漏れの確認に使ってください。
| 層 | 組み込む機能 | 主な製品例 |
|---|---|---|
| 入口（L7） | WAF | AWS WAF / Cloudflare / Akamai |
| 入口（L3/L4） | DDoS対策・CDN | CloudFront / Cloudflare / Shield |
| NW内部 | IDS/IPS・マイクロセグメント | GuardDuty / Network Firewall |
| アクセス制御 | ZTNA（Zero Trust Network Access） | Cloudflare Access / Zscaler |
| Identity | SSO + IAM Role + MFA | Okta / Entra ID / IAM Identity Center |
| シークレット | 鍵管理・秘密情報 | Secrets Manager / Vault / KMS |
| データ | TLS・保存時暗号化・CMK | ACM / KMS / CloudHSM |
| 継続監査 | 脆弱性スキャン・SBOM・CSPM | Dependabot / Trivy / Security Hub |
システムアーキテクチャ設計時はこの表の全行に答えを置くのが最低ラインです。「あとで」は存在しません。
コンプライアンス要件は設計前に洗い出す
業界・地域・顧客要件によって、満たすべきセキュリティ基準が定められています。認証取得には時間とコストがかかるため、設計段階で洗い出しておかないと、後で大掛かりな作り直しになります。ここは別カテゴリの記事ではなく、システムアーキテクチャの最初に決める話なので本記事で扱います。
| 基準 | 対象 |
|---|---|
| PCI DSS | クレジットカード決済を扱うシステム |
| ISMS / ISO 27001 | 情報セキュリティ全般・企業認証 |
| 個人情報保護法 / GDPR | 個人データの取り扱い |
| SOC 2 | SaaS提供者のセキュリティ/可用性 |
| HIPAA | 医療情報（米国） |
| ガバメントクラウド | 日本の官公庁・自治体 |
SaaS事業者が SOC 2 Type II を取得すると、エンタープライズ顧客への営業が格段に通りやすくなります。日本の金融・官公庁向けSaaSは ISMS + FISC（金融情報システムセンターの安全対策基準）準拠が必須になることも多いです。SOC 2を運用開始後に決めると、ログ設計のやり直しで数ヶ月の遅延が発生します。
フェーズ別セキュリティ導入ロードマップ
セキュリティは「全部一気に」は現実的ではないので、フェーズごとに必須・推奨を切り分けます。下記は未導入だと事故る確率が高い順です。
| フェーズ | 最優先で入れる | 次に入れる | 月額コスト目安 |
|---|---|---|---|
| ① MVP・個人開発 | HTTPS（Let’s Encrypt）・MFA・IAM Role運用・Dependabot | WAF（Cloudflare無料枠）・Secret Scanning | 〜0円 |
| ② 小規模SaaS | + AWS WAF / Shield Standard・Secrets Manager・CloudTrail | + GuardDuty・Config・SSO（IdP連携） | 数万円 |
| ③ 中規模SaaS | + Security Hub・SIEM（ログ集約）・脆弱性スキャンCI組込 | + SOC 2 Type II取得・ISMS準備・Policy as Code | 数十万〜 |
| ④ エンタープライズ | + 24/7 SOC（Security Operation Center）・DLP・Zero Trust（ZTNA） | + Red Team演習・ペネトレーションテスト（年次） | 数百万〜 |
| ⑤ 規制業種（金融・医療・公共） | 業界認定（FISC / HIPAA / ガバメントクラウド）準拠は最初から必須 | ― | 変動 |
MFA・Dependabot・Secret Scanning・HTTPS の4つはMVPでも必須です。これを後回しにすると、公開後数時間でIAMキー流出・依存ライブラリ経由の侵入を食らいます。2021年12月の Log4Shell（Log4j の CVE-2021-44228）では、依存ライブラリ1個の脆弱性で世界中のシステムが連鎖的に攻撃された事例が生まれました。
MVPでも「MFA・Secret Scanning・Dependabot・HTTPS」は即日入れます。「後で」は存在しません。
システムアーキテクチャ段階の鬼門・禁じ手
個別製品の設定ミスは別カテゴリの各記事に集約し、本記事はシステムアーキテクチャ段階で決めると事故る典型に絞ります。アーキテクトが最初に避けるべき判断ミスです。
| 禁じ手 | なぜダメか |
|---|---|
| セキュリティ要件を設計後半で洗い出し | SOC 2 / FISC の要件はログ設計・ネットワーク分離に遡って影響。後半着手で数ヶ月の手戻り |
| 本番と開発を同一アカウント | 開発ミスが本番に伝播。AWS なら Organization 単位で最初から分離 |
| 踏み台サーバーをIP制限なしで公開 | ブルートフォース前提。SSM Session Manager や ZTNA で踏み台そのものを無くす |
| MFAを一部管理者のみに設定 | 1人でもMFA未設定の管理者がいれば、そこが侵入経路に |
| CloudTrail / 監査ログを本番アカウント内に保管 | 侵害時にログごと消される。別アカウント + Object Lock 必須 |
| IAMユーザー + 長期アクセスキーで運用 | キー1本の流出で全権限奪取。OIDC + IAM Role の短期トークンが現代の本命 |
| TLS 1.0 / 1.1 を有効のまま残す | 顧客監査・金融認定でNG。TLS 1.2 以上必須、理想は 1.3 |
| セキュリティ基盤をコード化せずGUI管理 | 変更履歴が残らず再現不能。Terraform / CDK + Policy as Code に寄せる |
2022年の Okta侵害（サポート業者経由で一部顧客の認証情報へアクセス）、LastPass流出（顧客暗号化ボルトのコピーが攻撃者の手に）は、セキュリティ専業企業ですら侵入されることを示しています。「うちは大丈夫」は成立しない前提で設計を組みます。
設計段階の判断ミスは運用開始後に数ヶ月の改修プロジェクトになります。最初の設計図で妥協しないことが死活的に重要です。
AI時代の視点
AI駆動開発が前提になると、セキュリティ基盤の設計軸は「Policy as Codeで表現できるか」が決定的になります。
WAFルール・IAMポリシー・ネットワークACL・暗号化ポリシーなどをコードで宣言し、「AIが生成 → 人間がレビュー → CIで静的解析」というワークフローが標準になります。GUIでポチポチ設定するセキュリティツールは、変更履歴が残らずAIでもレビューできず、もう時代遅れです。
| AI時代に有利 | AI時代に不利 |
|---|---|
| Policy as Code（OPA（Open Policy Agent）・Cedar（AWSの認可言語）・tfsec（Terraform静的解析）） | GUI設定の独自セキュリティ製品 |
| OIDC（標準認証プロトコル）連携・短期トークン運用 | 長期IAMキーをSecrets管理 |
| CSPM（Cloud Security Posture Management、クラウド設定ミスの自動検出） | 手動監査・Excel管理 |
| SBOM（Software Bill of Materials、使用ライブラリ一覧）・SLSA（サプライチェーン安全性基準）等の標準仕様で脆弱性管理 | 独自フォーマットの脆弱性台帳 |
一方、AIが生成するコードにはハルシネーションによる脆弱性（存在しないライブラリ呼び出し・古い認証APIの使用等）が混入するリスクがあります。自動 SAST（Static Application Security Testing、コード静的セキュリティ解析）・依存関係スキャン（Dependabot/Snyk）を必ずCIに組み込み、AI生成コードを無検証で本番に出さないガードが必須です。
AI時代は「セキュリティもコード」が前提です。GUIで触るだけのセキュリティ製品は選びません。
よくある勘違い
- 小さなサービスだから攻撃者の目に止まらない → 本当はこう：攻撃者は人間ではなくBotで、標的を選ばず全IPを順にスキャンします。規模とは無関係に「公開した瞬間に攻撃対象」と考える
- 社内LANの中なら安全 → 本当はこう：社内端末のマルウェア感染・内部不正・VPN漏洩を考えると、社内LANは「少し薄いインターネット」でしかない。ゼロトラストが前提
- WAFを入れればアプリ側の対策は不要 → 本当はこう：WAFは一次遮断です。アプリのSQLインジェクション対策・認可チェックを省く言い訳にしたら地雷を踏む
- セキュリティは運用フェーズで考える → 本当はこう：IAM・暗号化・ログ設計は初期アーキテクチャと不可分です。後付けは数ヶ月規模の改修になる甘い選択
publicリポジトリの数時間（業界事例）
新人エンジニアが動作確認用のスクリプトに AWS のアクセスキーを書いたまま誤って public リポジトリに push してしまい、数時間後には数十万円分の EC2 が勝手に立ち上げられて暗号通貨マイニングに使われていた。という事例は、残念ながら国内外で繰り返し報告されています。
GitHubに上がった瞬間から秒単位でBotが巡回しており、削除してもGit履歴に残ればそこから拾われます。
教訓は、「気づいてから削除するでは遅い」ということです。push する前のフックで検出するか、そもそも長期キーを発行しない（OIDC・一時認証で運用する）設計まで引き上げる必要があります。セキュリティの「気をつけます」は、人間の注意力に依存する時点で破綻しています。
個人の気合ではなく、仕組みで守る。これが鉄則です。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- コンプライアンス要件（SOC 2 / ISMS / PCI DSS など）
- 多層防御の層ごとの採用製品（WAF / DDoS / IDS/IPS）
- ZTNA採用有無（VPNからの移行時期）
- IAM戦略（SSO / Role / MFA必須範囲）
- シークレット管理基盤（Secrets Manager / Vault）
- 暗号化方針（転送時 / 保存時 / アプリ層）
- 監査ログの別アカウント保管とWORM化
- Policy as Code の導入範囲
各項目の具体選定は別カテゴリ「セキュリティアーキテクチャ」の各記事を参照してください。
最終的な判断の仕方
セキュリティ基盤は「後付けできない」という制約が選定の核です。運用開始後に認証方式を変える・全データを暗号化する・全APIにWAFをかける作業は数ヶ月の大工事になるため、設計時に組み込む前提で初期コストを惜しまないこと。
「ウチは小さいから狙われない」という楽観は通用せず、公開IPはBotに24時間365日スキャンされているという現実から逆算します。
基本は「多層防御 + 最小権限 + ゼロトラスト」の3点セットで、これ以外は選択の余地がありません。具体的にはWAF/CDN/SGで多層化し、IAMはSSO+Roleで長期キーを排除し、社内LAN前提のVPNはZTNAに置き換える流れです。
本記事の役目はビルディングブロックの全体地図を示すことで、各層の製品選定・設定値・運用は別カテゴリの専用記事に委ねます。AI駆動開発では、セキュリティポリシーをコードで表現（Policy as Code）できる構成が絶対条件。GUI設定のみの製品はレビュー・監査で破綻します。
選定の優先順位をまとめると次の通りです。
- コンプライアンス要件を最初に洗い出し設計に組み込む
- 多層防御の各層（入口・NW・Identity・データ）に「誰が責任を持つか」を置く
- IAM戦略はSSO+Role切替を基本とし、長期キー発行は例外扱い
- Policy as Code対応を全製品選定のチェック項目に加える
「設計で組み込む、運用でコード化する」セキュリティは後付けではなく、最初の1行目から存在するものです。
まとめ
本記事はシステムアーキテクチャ段階のセキュリティ基盤の全体地図について、多層防御・コンプライアンス要件・段階別ロードマップ・AI時代の視点まで解説しました。如何だったでしょうか。
セキュリティは後付け不可な領域なので、設計の最初の1行目から組み込む前提で進めます。MVPでも MFA・Dependabot・Secret Scanning・HTTPS の4つは即日必須、それ以上は規模と業種に合わせて段階的に積み上げます。
次回は「監視と運用」（Observabilityの3本柱・4ゴールデンシグナル）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（13/89）