本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第8弾として、インフラ層で張り巡らすセキュリティ基盤の全体地図について解説する記事です。
WAF・DDoS対策・IDS/IPS・IAM・暗号化・シークレット管理を多層で重ねるのが基本で、後から追加するとコストが大幅に増える領域です。本記事ではシステムアーキテクチャ段階で組み込むべき機能の全体地図を扱い、個別領域の深掘り（認証方式・認可モデル・暗号アルゴリズム・脆弱性診断）は別カテゴリ「セキュリティアーキテクチャ」に委ねます。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』も参考にしてみてください。
そもそもセキュリティ基盤とは何か
セキュリティ基盤とは、ざっくり言えば「システムを外部の攻撃や内部の事故から守るための防御装置一式」です。
ビルのセキュリティを想像してください。入口にはゲート（ファイアウォール）、各フロアにはカードキー（認証・認可）、金庫室には暗証番号（暗号化）、そして防犯カメラ（監視）が設置されています。どれか一つだけでは不十分で、複数の防御を重ねることで侵入者を止めます。インフラのセキュリティ基盤もこれと同じ「多層防御」の考え方で、WAF・DDoS対策・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）
多層防御は、攻撃を単一の防御ラインに頼らず複数の層で阻止する考え方です。一つの防御が破られても次の層で止められるように、入口から内側まで複数のゲートを設けます。
入口で全部止めるのは非現実的です。「どこかで突破される前提」を置き、被害を最小化する設計に振ります。クラウドセキュリティの本命はこの多層防御＋ゼロトラストで、ここから外れる構成はもう選ばれません。
攻撃を単一の壁で止めない。破られても次で止まる設計が基本です。
セキュリティ基盤の主要ビルディングブロック
システムアーキテクチャ設計時に「ここに何を置くか」を決めるべき構成要素の一覧です。各要素の詳細（製品選定・設定値・運用ルール）は別カテゴリの記事で深掘りします。本記事では配置と抜け漏れの確認に使ってください。
| 層 | 組み込む機能 | 主な製品例 |
|---|---|---|
| 入口（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 | クレジットカード決済を扱うシステム |
| 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・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」は即日入れます。「後で」は存在しません。
AI判断軸 ― Policy as Codeで表現できるか
AI駆動開発が前提になると、セキュリティ基盤は「Policy as Codeで全て表現できるか」が選定の決定的な軸になります。WAFルール・IAMポリシー・暗号化ポリシーをコードで宣言し、「AIが生成 → 人間がレビュー → CIで静的解析」というワークフローが標準化します。GUIでポチポチ設定するセキュリティツールは変更履歴が残らずAIでもレビューできないため、もう時代遅れです。
| AI時代に有利 | AI時代に不利 |
|---|---|
| Policy as Code（OPA・Cedar・tfsec） | GUI設定の独自セキュリティ製品 |
| OIDC連携・短期トークン運用 | 長期IAMキーをSecrets管理 |
| CSPMでクラウド設定ミスの自動検出 | 手動監査・Excel管理 |
| SBOM・SLSA等の標準仕様で脆弱性管理 | 独自フォーマットの脆弱性台帳 |
一方、AIが生成するコードにはハルシネーションによる脆弱性が混入するリスクがあり、自動SAST・依存関係スキャンを必ずCIに組み込み、AI生成コードを無検証で本番に出さないガードが必須です。
選定の優先順位をまとめると次の通りです。
- コンプライアンス要件を最初に洗い出し設計に組み込む
- 多層防御の各層に「誰が責任を持つか」を置く
- IAM戦略はSSO+Role切替を基本とし、長期キー発行は例外扱い
- Policy as Code対応を全製品選定のチェック項目に加える
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ツールは、セキュリティポリシーをコードで宣言し、違反を自動検出する仕組みです。AIが生成したTerraformコードに対して「パブリックサブネットにDBを置いてはならない」「IAMポリシーのActionに*を使ってはならない」といったルールを適用できます。
AIが書くコード量が増えるほど、人間のレビュー負荷は上がります。Policy as Codeで自動チェックできる範囲を広げることが、AI時代のセキュリティ運用のスケーラビリティを確保する鍵です。
やってはいけないこと
個別製品の設定ミスは別カテゴリの各記事に集約し、本記事はシステムアーキテクチャ段階で決めると事故る典型に絞ります。アーキテクトが最初に避けるべき判断ミスです。
| 禁じ手 | なぜダメか |
|---|---|
| セキュリティ要件を設計後半で洗い出し | 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 に寄せる |
| 規模が小さいから攻撃対象にならない前提で設計 | Botは全IPを順にスキャンする。規模とは無関係に「公開した瞬間に攻撃対象」が現実 |
| 社内ネットワークを信頼前提でアクセス制御を緩くする | 社内端末のマルウェア感染・内部不正・VPN漏洩を考えると、社内LANは「少し薄いインターネット」ゼロトラストが前提 |
| WAF導入をアプリ層セキュリティの代替にする | 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化
- Policy as Code の導入範囲
各項目の具体選定は別カテゴリ「セキュリティアーキテクチャ」の各記事を参照してください。
この記事に関連する記事
https://senkohome.com/arch-intro-system-cloud-vendor/ https://senkohome.com/arch-intro-system-application-types/ https://senkohome.com/arch-intro-system-bcp/
まとめ
本記事はシステムアーキテクチャ段階のセキュリティ基盤の全体地図について、多層防御・コンプライアンス要件・段階別ロードマップ・AI時代の視点まで解説しました。如何だったでしょうか。
セキュリティは後付け不可な領域なので、設計の最初の1行目から組み込む前提で進めます。MVPでも MFA・Dependabot・Secret Scanning・HTTPS の4つは即日必須、それ以上は規模と業種に合わせて段階的に積み上げます。
次回は「監視と運用」（Observabilityの3本柱・4ゴールデンシグナル）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS セキュリティ も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（13/89）