セキュリティアーキテクチャの設計：ゼロトラスト・最小権限・多層防御を構成に落とす

2026年10月26日 · 約12分で読めます

WAFや非公開サブネットを置いた先に、何を設計すればよいのか。外部URLからファイルを取り込むSaaSを例に、信頼境界、通信経路、ワークロードID、KMS、管理者権限、監査ログを組み合わせ、侵害時の被害範囲と検証方法まで考えます。

セキュリティアーキテクチャとは？3つの原則を区別する

WAF、ファイアウォール、暗号化を導入しても、それらが同じ侵害経路を止められるとは限りません。セキュリティアーキテクチャでは、守るデータと業務を起点に、アクセスを判断する場所、許す操作、記録、侵害時の封じ込めをつなぎます。設計判断を「なぜこの境界を置くのか」まで説明できることが重要です。

原則	設計で問うこと	この例での適用
ゼロトラスト	社内や同じVPCという理由だけで許可していないか	内部APIでも呼び出すサービスのIDと対象への権限を確認
最小権限	必要な対象・操作・期間に限定できているか	取得処理には指定された一時ファイルへの書き込みだけを許す
多層防御	一つの対策が破られた後、別の境界で止まるか	URL検証、送信先の制限、DB権限の分離、監査を組み合わせる

NIST SP 800-207の公開概要は、ネットワーク上の場所や所有者だけで暗黙の信頼を与えず、資源へのアクセス前に認証・認可する考え方を説明しています。ネットワーク分離を捨てるという意味ではありません。また、WAFで入力を検査することと、請求書を読める人かを判断することは別の制御です。

守る資産と、最初に侵害される場所を決める

脅威モデリングでは「URLの文字列が安全か」だけでなく、入力からどの資源へ進めるかを追います。SSRFは、サーバーに意図しない宛先への通信を行わせる攻撃です。取得先の内容が細工されて処理系が侵害された場合も、同じサーバーが顧客DBと復号権限を持てば被害が広がります。

想定する悪用	守りたい条件	担当する境界
取込URLで内部APIやメタデータへ誘導	指定URLから内部資源へ接続できない	取得クライアントと外向き通信の制御
取得プロセスを侵害し認証情報を利用	顧客DBの参照・本番ファイルの復号はできない	実行環境・ネットワーク・サービスIDの分離
管理者アカウントの侵害や誤操作	常時の強い権限と証拠の削除を制限	期間付きの権限と別管理の監査保管先

構成例：取得・検証・業務データの境界を分ける

独自の設計案の主なデータフロー。取得処理には顧客DB・本番ファイルの復号権限を与えない

利用者 → 公開入口（TLS・WAF・要求量の制御）→ 業務API（認証・認可） → 業務API → 顧客DB／取込制御（検証済みの依頼情報） → 取込制御 → 隔離したURL取得処理 → 隔離用ストレージ → 隔離用ストレージ → 検証・変換処理 → 非公開の本番ファイル保管先 → 認可する配信処理 → 許可された本番ファイルを取得・復号 → 各境界の監査イベント → 通常の実行ロールで消せない保管先 → 当番への通知

取得処理には、保護した制御経路からURLと一時的な書き込み先を渡します。書き込み権限はその依頼の一時オブジェクトに限定し、ストレージの一覧・読み取り・公開設定の変更は許しません。取得しただけのファイルは隔離領域に置き、形式・サイズ・悪性コンテンツ等を検査してから本番へ移します。

検証・変換処理も未信頼のバイト列を扱うため、万能な防壁とは考えません。実行時間・メモリ・展開後サイズを制限し、通常は外部への通信を許さず、必要な入力と出力先だけへ接続させます。取り込みの成功通知だけで公開せず、依頼と成果物の対応、検査結果、取得権限を確認します。

ネットワーク設計：公開入口と外向きの出口を両方絞る

業務APIの公開入口を限定し、DBには必要なアプリの経路からだけ接続させます。URL取得処理は、固定した制御・保存先への経路と、利用者指定URLへの経路を区別します。後者からは内部API、ループバック、リンクローカル、メタデータサービスなどへ届かないようにします。サブネットを分けるだけで通信が拒否されるわけではありません。

登録済みの取引先ホストとHTTPSに取得先を限定し、URLは保守されたパーサーで検証する。自動リダイレクトは無効にする。
IPv4・IPv6の解決結果と実際の接続先を照合し、DNSの変化によるすり抜けを防ぐ。TLSのホスト名検証も保つ。取得時間と受信量に上限を設ける。
直接通信や別プロキシで迂回できないように出口を強制する。ネットワーク側でも必要な宛先だけを許し、固定の保存先への例外を利用者指定URLに流用させない。

プライベートエンドポイントを使う場合も、名前解決、通信経路、公開側の設定、IAMをセットで確かめます。たとえばAzure Storageでは、Private Endpointを作っただけでは公開エンドポイントへの接続は自動で止まりません。非公開経路の用意と、不要な公開経路の閉鎖は別の設定です。

最小権限：サービスIDを処理の役割ごとに分ける

API、取得処理、検証処理、配信処理、CIで管理者キーを共有すると、取得処理の侵害が配備や鍵管理へ広がります。ワークロードIDは「どの処理か」を表す身元です。そのIDごとに対象・操作・条件を絞り、別の強いロールを引き受ける権限も確認します。利用者の業務上の認可は、サービスIDの認証とは別に必要です。

主体	許可する範囲の例	許可しない操作の例
URL取得処理	指定された一時オブジェクトへの期限付き書き込み	顧客DB参照、本番ファイル取得、KMSでの復号
検証・変換処理	対象の隔離ファイル取得、検証後の出力保存	顧客DBの全件取得、IAM変更、任意の外部通信
配信処理	認可済み対象の取得と必要な復号	鍵の管理、公開設定の変更、配備
CIの配備ID	指定環境の承認された版の配備	日常的な顧客ファイル取得、監査ログ削除

実行環境にはロール等で短期の認証情報を渡し、CIではOIDCの発行元・対象・リポジトリ・環境などの信頼条件を絞ります。AWS STSのように、交換して得た認証情報には独自のセッション期限があります。元のOIDCトークンの期限やCIジョブ終了と、クラウド認証情報の失効を同一視しません。

暗号化：データを読む権限と鍵を管理する権限を分ける

保存時暗号化は重要ですが、読み取りAPIが自動で復号して返す構成では、読み取りを許された侵害済みの処理も平文を得られます。暗号化の設計では、誰が暗号文を取れるか、誰が復号できるか、誰が鍵のポリシーを変えられるかを別々に確認します。

アプリ側のエンベロープ暗号化を採用する場合。KMSへファイル全文を送る構成ではない

暗号ライブラリでデータキー（DEK）を生成 → DEKでファイルを認証付き暗号化 → KMSの鍵暗号化キー（KEK）でDEKを包む → 暗号文・包んだDEK・必要な暗号化メタデータを保存 → 許可された読み取り処理だけがDEKを開いて復号

マネージドストレージの暗号化で要件を満たすなら、その機能を使います。アプリ側で暗号化を追加する場合は、暗号方式を自作せず、保守されたライブラリと鍵管理を使います。KMSの往復、上限、停止時の応答、平文キーのキャッシュ、バックアップからの復元も設計対象です。鍵管理者にデータの復号を直接許さなくても、自分へ権限を付けられるなら承認等の統制が必要です。

管理経路：常時の強い権限と緊急用アクセスを設計する

本番の設定を変える経路は、利用者がファイルを読む経路より強い権限を持ちます。個人を識別できるSSOとMFAを使い、必要時だけ対象と期間を限定して昇格します。Microsoft Entra PIMは、期間付き・承認付きのロール有効化、MFA、通知等を構成できる製品例です。これらは採用先の機能と適用範囲を確認して設計します。

通常の認証基盤が停止したときの緊急用アクセスも用意し、保管・利用通知・定期点検の担当を決めます。SSOを停止しても、各サービスの既存セッションやAPIキーまで止まるかは別に確認します。緊急経路が日常の共有管理者アカウントにならないようにします。

監査と検知：侵害された処理に証拠を消させない

取得先の拒否、ロールの変更、鍵の利用、重要ファイルの取得、監査設定の変更を、主体・対象・操作・結果・時刻と結び付けて記録します。通常の実行IDにはログの削除や収集設定の変更を許さず、必要に応じて別アカウント等の管理境界に保管します。秘密値やファイル本文を監査ログへ複製しません。

AWS CloudTrailでは、S3のGetObject等はデータイベントで、証跡やイベントデータストアは既定では記録しません。管理操作のログがあるだけで、顧客ファイルの取得まで追えると考えないようにします。必要な対象を設定し、収集範囲・保持・費用を確認します。

まず検証用ファイルの取得が記録されることを確認し、次に設定した大量取得ルール等の条件を満たす操作を発生させ、当番への通知と調査開始まで追います。通知のサンプルを注入する試験は通知経路の確認には使えますが、実イベントの収集や検知条件の正しさを丸ごと検証するものではありません。収集停止の検知も設けます。

導入順序と検証：境界を置いたら、越えられないか試す

管理する検証環境で試すこと	期待する結果	確認する証拠
取得処理から内部の検証用宛先へ通信	利用者指定の取得経路では拒否	接続先の記録とネットワーク制御の結果
取得処理のIDで顧客DB参照・本番復号	通信または権限の境界で拒否	実際のIDでの拒否と顧客データが返らないこと
未承認のCI環境から本番ロールを取得	信頼条件で拒否	トークンの秘密値を含まない監査記録
公開経路から非公開ファイルを取得	不要な公開経路と未認可取得を拒否	名前解決・公開設定・データ応答
通常の実行IDで監査ログを削除	削除を拒否し、収集停止も検知	残った記録と通知の到達
KMSやSSOが停止する想定で手順を実行	制御を迂回せず、規定の保留・拒否・緊急手順へ	復旧所要時間、復元可能なデータ、残る制約

守る資産と悪用経路を図にし、DBの公開や共有管理者キーなど、影響の大きい経路から閉じる。
処理ごとのIDと権限を分け、外部入力を扱う取得・変換処理の通信と保存先を制限する。正常な取り込みと取得も併せて試す。
鍵・管理者・監査の管理境界を整え、担当、封じ込め、復旧を含む試験を繰り返せるようにする。

境界を増やすほど、ID・ポリシー・名前解決・監視を維持する仕事も増えます。小さなチームなら、管理された認証・鍵・ストレージ・ログの機能を活用し、守る条件を満たす範囲で構成を絞ります。機能追加で新しい通信や管理経路が生まれたら、図と権限表と検証を一緒に更新します。