本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第8弾として、インフラ層で張り巡らすセキュリティ基盤の全体地図について解説する記事です。
WAF・DDoS対策・IDS/IPS・IAM・暗号化・シークレット管理を多層で重ねるのが基本で、後から追加するとコストが大幅に増える領域です。本記事の問いは「システムアーキテクチャのどこで何を組み込むか」です。個別領域の深掘り（認証方式・認可モデル・暗号アルゴリズム・脆弱性診断）は別カテゴリ「セキュリティアーキテクチャ」の各記事に委ねます。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』も参考にしてみてください。
この記事の結論
- セキュリティは設計の1行目から組み込む（後付け不可）
- MVPでもMFA・Dependabot・Secret Scanning・HTTPSは即日必須
- コンプライアンス要件（SOC 2 / FISC等）は設計前に洗い出す
- それ以上は規模と業種に合わせて段階的に積み上げる
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもセキュリティ基盤とは何か
セキュリティ基盤とは、ざっくり言えば「システムを外部の攻撃や内部の事故から守るための防御装置一式」です。
ビルのセキュリティを想像してください。入口にはゲート（ファイアウォール）、各フロアにはカードキー（認証・認可）、金庫室には暗証番号（暗号化）、そして防犯カメラ（監視）が設置されています。どれか一つだけでは不十分で、複数の防御を重ねることで侵入者を止めます。インフラのセキュリティ基盤もこれと同じ「多層防御」の考え方で、WAF・DDoS対策・IAM・暗号化・シークレット管理を組み合わせます。
なぜセキュリティ基盤の設計が重要なのか
もしセキュリティを後回しにしたらどうなるか。公開されたIPアドレスはBotに24時間365日スキャンされています。検証用に立てた小さなAPIサーバーでも、24時間後にはログに数千件のスキャンアクセスが記録されていた、という経験は珍しくありません。
「まだ誰も知らないから大丈夫」という前提は、インターネットでは一度も成立したことがない発想です。攻撃者は人間ではなくBotで、標的を選ばず全IPを順にスキャンしています。セキュリティは後付け不可であり、最初からインフラに組み込むのが鉄則です。
多層防御（Defense in Depth）
多層防御は、攻撃を単一の防御ラインに頼らず複数の層で阻止する考え方です。一つの防御が破られても次の層で止められるように、入口から内側まで複数のゲートを設けます。入口で全部止めるのは非現実的なので、「どこかで突破される前提」を置き、被害を最小化する設計に振ります。クラウドセキュリティの本命はこの多層防御＋ゼロトラストで、ここから外れる構成はもう選ばれません。
セキュリティ基盤の主要ビルディングブロック
システムアーキテクチャ設計時に「ここに何を置くか」を決めるべき構成要素の一覧です。各要素の詳細な選定は別カテゴリの記事で深掘りするので、本記事では配置と抜け漏れの確認に使ってください。
| 層 | 組み込む機能 | 主な製品例 |
|---|---|---|
| 入口（L7） | WAF | AWS WAF / Cloudflare / Akamai |
| 入口（L3/L4） | DDoS対策・CDN | CloudFront / Cloudflare / Shield |
| NW内部 | IDS/IPS・マイクロセグメント | GuardDuty / Network Firewall |
| アクセス制御 | ZTNA | 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、個人データを扱うなら個人情報保護法 / GDPR、SaaS提供者ならSOC 2、医療情報（米国）ならHIPAA、日本の官公庁・自治体ならガバメントクラウド、企業としての包括認証ならISMS / ISO 27001です。
認証取得には時間とコストがかかるため、設計段階で洗い出しておかないと、後で大掛かりな作り直しになります。SaaS事業者がSOC 2 Type IIを取得するとエンタープライズ顧客への営業が格段に通りやすくなりますが、運用開始後に取得を決めるとログ設計のやり直しで数ヶ月の遅延が発生します。日本の金融・官公庁向けSaaSはISMS+FISC（金融情報システムセンターの安全対策基準）準拠が必須になることも多いです。
フェーズ別セキュリティ導入ロードマップ
セキュリティは「全部一気に」は現実的ではないので、フェーズごとに必須・推奨を切り分けます。下記は未導入だと事故る確率が高い順です。
| フェーズ | 最優先で入れる | 次に入れる |
|---|---|---|
| ① MVP・個人開発 | HTTPS・MFA・IAM Role運用・Dependabot | WAF（Cloudflare無料枠）・Secret Scanning |
| ② 小規模SaaS | +AWS WAF・Secrets Manager・CloudTrail | +GuardDuty・Config・SSO（IdP連携） |
| ③ 中規模SaaS | +Security Hub・SIEM・脆弱性スキャンCI組込 | +SOC 2 Type II取得・Policy as Code |
| ④ エンタープライズ | +24/7 SOC・DLP・ZTNA | +Red Team演習・年次ペネトレーションテスト |
| ⑤ 規制業種 | 業界認定（FISC / HIPAA / ガバクラ）準拠を最初から | ― |
MFA・Dependabot・Secret Scanning・HTTPSの4つはMVPでも必須です。これを後回しにすると、公開後数時間でIAMキー流出・依存ライブラリ経由の侵入を食らいます。2021年12月のLog4Shell（Log4jのCVE-2021-44228）では、依存ライブラリ1個の脆弱性で世界中のシステムが連鎖的に攻撃されました。
3つのシナリオで考える
個人開発・スタートアップの場合
HTTPS・MFA・IAM Role運用・Dependabotの4点が、MVPであっても必須の最低装備だと考えてください。これを後回しにしてしまうと、公開後わずか数時間でIAMキーの流出や依存ライブラリ経由の侵入を食らうことになります。WAFについてはCloudflareの無料枠で足りてしまいます。
中小SaaSの場合
AWS WAFにSecrets Manager、CloudTrail、GuardDuty、SSO（IdP連携）へと段階的に増強していく時期です。B2B契約が視野に入ってきたら、SOC 2 Type IIの取得とSecurity HubやSIEMの整備が、そのまま営業上の強みになってくれます。
大企業・規制業種の場合
24/7のSOCにDLP、ZTNA、Red Team演習まで含めたフル装備となります。金融のFISC、医療のHIPAA、公共のガバメントクラウドといった業界認定への準拠は、後付けではなく最初から設計条件に組み込んでおく必要があります。
AI判断軸 ― Policy as Codeで表現できるか
AI駆動開発が前提になると、セキュリティ基盤は「Policy as Codeで全て表現できるか」が選定の決定的な軸になります。WAFルール・IAMポリシー・暗号化ポリシーをコードで宣言し、「AIが生成 → 人間がレビュー → CIで静的解析」というワークフローが標準になります。GUIでポチポチ設定するセキュリティツールは変更履歴が残らず、AIでもレビューできません。
AI生成コードのセキュリティリスクと自動検査
AIが生成するインフラコードには、セキュリティ設定の抜け漏れが混入しやすいです。セキュリティグループで 0.0.0.0/0 を開放する、S3バケットのパブリックアクセスブロックを設定しない、IAMポリシーで * リソースを許可する──これらはAIが「動くこと」を優先した結果として書きがちなパターンです。対策はCIパイプラインにtfsec・Checkov・AWS Config Rulesを組み込み、AI生成コードを含む全てのインフラ変更を自動検査することです。
Policy as CodeがAI時代のガードレールになる
OPA（Open Policy Agent）・Cedar・tfsecのようなPolicy as Codeツールは、「パブリックサブネットにDBを置いてはならない」「IAMポリシーのActionに * を使ってはならない」といったルールをコードで宣言し、違反を自動検出します。AIが書くコード量が増えるほど人間のレビュー負荷は上がるため、自動チェックできる範囲を広げることが、AI時代のセキュリティ運用のスケーラビリティを確保する鍵です。
やってはいけないこと
個別製品の設定ミスは別カテゴリに譲り、システムアーキテクチャ段階で決めると事故る典型に絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| セキュリティ要件を設計後半で洗い出す | SOC 2 / FISCの要件はログ設計・NW分離に遡って影響する → 設計前に確認する |
| 本番と開発を同一アカウントにする | 開発ミスが本番に伝播する → Organization単位で最初から分離する |
| IAMユーザー+長期アクセスキーで運用 | キー1本の流出で全権限を奪われる → OIDC+IAM Roleの短期トークンにする |
| MFAを一部管理者のみに設定 | 1人でも未設定ならそこが侵入経路になる → 全管理者に強制する |
| 監査ログを本番アカウント内に保管 | 侵害時にログごと消される → 別アカウント+Object Lockで保管する |
| 社内ネットワークを信頼前提にする | 社内LANは「少し薄いインターネット」 → ゼロトラストを前提にする |
なおWAFは一次遮断にすぎません。アプリ側のSQLインジェクション対策・認可チェックを省く言い訳にすると地雷を踏みます。2022年のOkta侵害・LastPass流出は、セキュリティ専業企業ですら侵入されることを示しました。「うちは大丈夫」は成立しない前提で設計を組みます。
筆者メモ ― 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化
各項目の具体選定は別カテゴリ「セキュリティアーキテクチャ」の各記事を参照してください。
この記事に関連する記事
まとめ
本記事はシステムアーキテクチャ段階のセキュリティ基盤の全体地図について、多層防御・コンプライアンス要件・段階別ロードマップ・AI時代の視点まで解説しました。如何だったでしょうか。
セキュリティは後付け不可な領域なので、設計の最初の1行目から組み込む前提で進めます。MVPでもMFA・Dependabot・Secret Scanning・HTTPSの4つは即日必須、それ以上は規模と業種に合わせて段階的に積み上げます。
次回は「監視と運用」（Observabilityの3本柱・4ゴールデンシグナル）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS セキュリティ も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（19/95）