ゼロトラスト・ネットワークアーキテクチャ図テンプレート

「ゼロトラスト」と名付けられた図の多くは、タイトルを付け替えただけの境界型（ペリメーター）の図です。境界にファイアウォール、DMZ、そして信頼された内側。役に立つゼロトラストアーキテクチャ図は、ひと目で3つの問いに答えます。各アクセスの判断はどこで下されるのか、その判断にどのシグナルが入力されるのか、そしてどこで強制されるのか。これに答えられない図は、信頼ではなくネットワーク上の位置を描いているにすぎません。

この記事では、NIST SP 800-207の論理モデル、レビュアーが確認できる描画ルール、よくある間違い、そしてArchboardにコピーできる無料テンプレートを紹介します。

NIST SP 800-207のモデル

NIST SP 800-207は、ゼロトラストアーキテクチャ（ZTA）をひとつの考え方を軸に定義しています。ネットワーク上の位置や資産の所有者にもとづく暗黙の信頼は存在しない、という考え方です。各リソースへのアクセスはセッション単位で許可され、動的なポリシーによって判断され、主体がリソースに到達する前に強制されます。

3つの論理コンポーネント

PEとPAを合わせてPolicy Decision Point（PDP）と呼びます。実際のシステムでは、PEはアイデンティティ認識型プロキシやサービスメッシュのコントロールプレーンの中にあることが多く、PEPはゲートウェイ、サイドカー、エージェント、プロキシなどです。ひとつの製品が2つの役割を担う場合でも、図ではそれぞれの役割が見えるようにします。

判断を支えるデータソース

SP 800-207は、PEが使える入力を列挙しています。ほぼすべての図に載せるべきものは次のとおりです。

• アイデンティティプロバイダー / ID管理：ユーザー、サービスID、グループ、認証の強度。
• デバイスの状態（CDM）：継続的な診断と緩和のデータ。デバイスは既知か、管理されているか、パッチは当たっているか。
• 脅威インテリジェンス：新しい攻撃、侵害されたアカウント、脆弱性に関するフィード。
• アクティビティログとSIEM：収集・分析されたネットワークとシステムのアクティビティ。フィードバックループはここから始まります。
• エンタープライズPKI：ユーザー、デバイス、ワークロード向けの証明書。

標準ではデータアクセスポリシーやコンプライアンス要件も入力として挙げています。実際の判断に影響するなら、それらも描いてください。

ゼロトラストアーキテクチャ図の描き方

1. すべてのアクセス経路にPEPを置く

主体（ユーザー、デバイス、サービス）からリソースへ向かう矢印をすべてたどります。どの矢印も、まず強制ポイントを通過しなければなりません。PEPを迂回する矢印があれば、図が間違っているか、アーキテクチャに穴があるかのどちらかです。ユーザーの経路だけでなく、管理者、CI/CD、緊急時（break-glass）の経路も含めましょう。

2. アイデンティティとデバイスのシグナルが判断に流れ込む様子を示す

アイデンティティプロバイダー、デバイスの状態、脅威インテリジェンス、SIEMをノードとして描き、Policy Engineへエッジでつなぎます。エッジには流れる情報をラベルとして付けます。例：「ユーザー + グループ（OIDC）」「デバイスのコンプライアンス」「リスクシグナル」。

3. セッション単位の認証・認可を明示する

NISTはアクセスをセッション単位で許可するものとして説明していますが、多くの実装はリクエストごとに再評価します。どちらの場合でも、流れを示します。主体がアクセスを要求し、PEPがPDPに問い合わせ、PEが評価し、PAがPEPを設定し、PEPがセッションを許可またはブロックします。エッジに番号付きラベルを付ければ十分です。より詳しく示したい場合は、小さなシーケンス図を横に添えます。

4. コントロールプレーンとデータプレーンを分ける

PE、PA、データソースをひとつの領域に、主体、PEP、リソースを別の領域に配置します。2つの領域をまたぐのは、PAからPEPへの制御チャネル、シグナルの入力、ログの流れだけです。

5. マイクロセグメンテーションと東西トラフィックを示す

ゼロトラストは、ユーザーがアプリにアクセスする経路だけの話ではありません。サービス間のトラフィックについては次を描きます。

• ワークロードのアイデンティティ（たとえばservice accountにひも付いた証明書）
• サービス間のmTLSと、その証明書を発行するCAまたはPKI
• ワークロード間のセグメンテーションポリシー（KubernetesのNetworkPolicyなど）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

NetworkPolicyはレイヤー3と4で動作し、CNIプラグインが対応している場合にのみ効果があります。これはセグメンテーションであって認証ではないため、図ではmTLSおよびPEPでの認可と組み合わせて示します。

6. シークレットと証明書を独立した要素として描く

Vault（シークレットマネージャー）とPKIを別々のノードとして示します。どのワークロードがどのシークレットを、どのアイデンティティで取得するのかを描きます。NISTのモデルでは、セッション固有の認証情報はPAから発行されるので、判断のフローにつなげておきます。

7. WAFとファイアウォールは残し、正しい位置に置く

ゼロトラストでもWAFやファイアウォールはなくなりません。境界やセグメント間で引き続きフィルタリングを行いますが、信頼の判断を下すのは彼らではありません。信頼されたゾーンを囲む壁としてではなく、経路上のフィルターとして描きます。

8. ログでループを閉じる

すべてのPEPとファイアウォールはログをSIEMに送り、分析結果はPolicy Engineにフィードバックされるべきです。このエッジがないと、継続的検証の「継続的」の部分が図から抜け落ちます。

よくある間違い

• ラベルを変えただけの城と堀。 分厚い外側のファイアウォール、「信頼された社内ネットワーク」、そして社内サービス間には強制ポイントがない。
• ポリシー判断のフローがない。 IdPとゲートウェイはキャンバスにあるのに、どこで判断され、何を入力としているのかが示されていない。
• フィードバックループがない。 ログがどこにも流れていない、あるいはSIEMがポリシーに戻るエッジのない行き止まりになっている。
• 南北方向だけ。 ユーザーからアプリへの経路はあるが、サービス間や管理者からインフラへの経路がない。
• ゾーンを信頼として描いている。 セグメントをFrameで描くのはよいことですが、「信頼済み」ではなく、セグメントや強制ドメインとして名前を付けます。

Archboardで作る

組み込みのパックで必要な要素はそろいます。Securityパックには、アイデンティティプロバイダー、WAF、ファイアウォール、ゼロトラストゲートウェイ、Vault、証明書のノードがあります。Networkパックには、Internet、DNS、ロードバランサー、そしてフレームとして描くVPCとサブネットがあります。KubernetesパックはNamespace（フレームとして描画）、Service、Pod、NetworkPolicyを追加します。ノードにはポートがあるので、各エッジは図形の上に浮かぶのではなく、ノードの特定の辺に接続されます。

1. Frameでプレーンを配置する。 Coreパックの Frame を2つ追加し、「Control plane」と「Data plane」とします。データプレーンの中には、セグメントごとに Frame を追加します（例：「Edge」「App segment」「Data segment」）。Kubernetesのワークロードには Namespace ノードを使います。
2. 主体と境界を追加する。 ユーザー用にNetworkパックの Internet ノードを置き、次にSecurityパックの WAF ノード、そしてユーザーアクセスのPEPとしてゼロトラストゲートウェイのノードを置きます。
3. 判断とその入力を追加する。 コントロールプレーンのフレームに、アイデンティティプロバイダーのノードと、「Policy Engine」「Policy Administrator」「Device posture (CDM)」「Threat intel」「SIEM」とラベルを付けたCoreパックの Box ノードを置きます。
4. 判断のフローを配線する。 シグナルの入力元をPolicy Engineへ、Policy EngineをPolicy Administratorへ、Policy Administratorを各PEPへつなぎます。エッジにはラベルを付けます。
5. 東西の経路を追加する。 各 Namespace の中に Service と Pod のノード、そして NetworkPolicy ノードを追加します。mTLSの発行元として証明書ノード、シークレット用にVaultノードを追加し、それらを使うワークロードにエッジでつなぎます。
6. セグメント間にファイアウォールを置く。 トラフィックがセグメントのフレームをまたぐ箇所に、Securityパックのファイアウォールノードを使います。
7. ループを閉じる。 各PEPとファイアウォールからSIEMへ、SIEMからPolicy Engineへエッジを引きます。
8. 前提をキャンバスに書いておく。 ポリシールールやセッションの有効期間はMarkdownブロックに書き、NetworkPolicyはその中にフェンス付きのYAMLコードブロックとして書きます。

ここまで網羅した図は、Freeプランの「1図あたり15ダイアグラムノード」の上限を超えることがあります。メモとテキストは別枠でカウントされ、最大150件です。Freeでは概要図とKubernetesの詳細図に分けてください。Proではノード数の上限がなくなります。SVGやPNGでのエクスポート（Freeでは透かし入り）、公開リンクでの共有、構造化JSONのエクスポートができるので、インフラのコードと同じ場所に保管できます。

無料テンプレート

Zero Trust Perimeterのサンプルは、エッジのWAFから入ってくるユーザー、OIDCで接続されたIdP / SSOノード、ゼロトラストゲートウェイ、セグメントファイアウォール、シークレット用のVault、そしてプライベートアプリを囲むmTLS PKIを示しています。開いて、この事例を使うで自分のワークスペースにコピーしてください。そのうえで、この記事で紹介したコントロールプレーンのフレーム、シグナルの入力元、ログのループを加えて拡張します。下層のネットワークについては、データセンターネットワークのサンプルとネットワーク図のユースケースを参照してください。

チェックリストとFAQ

図を共有する前に、次を確認します。

• 主体からリソースへのすべての経路がPEPを通過している
• アイデンティティ、デバイス、脅威、ログのシグナルがPolicy Engineに流れ込んでいる
• コントロールプレーンとデータプレーンが目に見えて分かれている
• 東西トラフィックにmTLSとセグメンテーションが示されている
• シークレットとPKIについて、誰が何を取得するかが示されている
• PEPとファイアウォールのログがSIEMに送られ、ポリシーに戻っている

ゼロトラストアーキテクチャ図は、単なるネットワーク図ですか？ いいえ。ネットワーク図はパケットがどこへ行くかを示します。ZTA図はそれに加えて、アクセスがどこで、どのシグナルにもとづいて判断され、どこで強制されるかを示します。

ゼロトラストの設計でも、ファイアウォールはまだ必要ですか？ はい。ファイアウォールとWAFは引き続き攻撃対象領域を減らします。ただし、何かが信頼される理由ではなくなります。

KubernetesのNetworkPolicyだけでゼロトラストになりますか？ いいえ、それだけでは不十分です。NetworkPolicyが提供するのはL3/L4のセグメンテーションです。ワークロードのアイデンティティ、mTLS、PEPでの認可、そしてログが別途必要です。

無料で始める — 1シート、クレジットカード不要