ポリシー設計

プライベートネットワークアクセスのポリシーは、主に Gateway DNS と Gateway Network のポリシービルダーで作成します。多くの場合、DNS 解決、SNI ホスト名、IP アドレスのグループを組み合わせて、特定のアプリケーション向けポリシーの基準にします。

ポリシーを作る前に、次の点を確認するとよいです。

• すべてのユーザーとサービスが、接続済みのすべてのサブネットに到達できてよいですか。明示的な例外はありますか。
• すべてのアプリケーションは、ひとつの主要なネットワーク範囲にありますか。ホストと IP アドレスは静的ですか、動的ですか。
• 完全に一時的な IP やサブドメインに依存する DevOps ワークフローはありますか。
• ポリシーで使うアイデンティティとデバイスポスチャの信頼できる情報源はありますか。
• すぐにデフォルト拒否モデルを導入しますか。つまり、明示的な Allow ポリシーに一致するユーザー以外をすべてブロックしますか。

Zero Trust Network Access のポリシーを計画するときは、次の進め方を推奨します。

ユーザーのメール、ユーザーグループ、その他の アイデンティティ属性 の信頼できる情報源として、どの ID プロバイダーを使うかを決めます。

グループ所属に基づいてサービスへのアクセスを許可する場合は、ユーザーレジストリを確認 し、対象ユーザーの User Registry にそのグループ値が入っていることを確認します。

多くのお客様は、会社支給デバイスの利用を条件としたポリシーも作成します。たとえば、会社支給デバイスのユーザーは *.jira.internal.com にアクセスでき、個人デバイスのユーザーは dev.internal.jira.com だけにアクセスできる、といった設定です。これを効果的にするには、会社支給デバイスの信頼できる情報源を定義することを推奨します。具体例としては、特定の 発行済み証明書 の有無、ハッシュが一致するプロセス の有無、Crowdstrike や SentinelOne など対応している サードパーティのエンドポイントセキュリティプロバイダー との API 連携があります。

ほぼすべての企業には、物理または仮想の相互接続されたネットワークがあります。ユーザーが現在、ローカルまたは VPN 経由でアクセスしている、関連するネットワーク、サブネット、セグメントをすべてリストアップします。例:

次に、ポリシー要件が異なる社内アプリケーション（ユーザーのアイデンティティやデバイスポスチャの要件が異なるものなど）をすべてリストアップします。各アプリケーションは、IP リスト、ホスト名 / ドメインリスト、またはその両方で定義します。

たとえば、a.internal.com が静的 IP のロードバランサーを指し、そのロードバランサーが a.internal.com を提供する動的ホスト群を分散している場合があります。アプリケーションホストの IP が動的な場合は、ロードバランサー IP 向けのネットワークポリシーと、アプリケーションホスト名向けの DNS ポリシーの 2 つを作るのがベストプラクティスです。

一方、ロードバランサー配下の IP が静的、または半動的であれば、ネットワークポリシーにアプリケーション IP を直接使う方がよい場合があります。インフラプロバイダーでホストが変わったときに、Cloudflare API 呼び出しでアプリケーション IP リストを更新するワークフローを作れます。

VPN プロバイダーから Zero Trust へ移行したい、既存のセキュリティポリシーやブロックリストを集めます。