ポリシーとサービスに関する議論は、常に、要件の基となるビジネスの促進要因から始め ます。これまで、エンタープライズ ネットワークの唯一のビジネス要件は、可用性の高い 高速接続（アクセス）を提供することでした。ここ数年のコンピューティングとネット ワーキングの動向に伴い、サービスとポリシーは進化しています。現在のエンタープライ ズ ネットワーク ポリシーは、俊敏性、柔軟性、セキュリティの大幅な向上に対応するため の新しい要件を満たす必要があります。
次のセクションでは、SD-Access のポリシーがエンタープライズ ネットワークにおける現 在の課題にどのように対処できるかを示す例として、セキュリティに焦点を当てます。SD-Access セキュリティ ポリシーには、VN ポリシーとグループベース ポリシーの 2 つのタイ プがあります。Quality of Service（QoS）、パケット キャプチャ、トラフィック エンジニ アリングなど、他のネットワーク サービスやポリシーにも同様の要件と課題が存在するこ と、そして、SD-Access はそれらについても同じように対処できることを認識してください。
ビジネスの促進要因
SD-Access の導入を推進する一般的なビジネス要件には、業界固有の基準（Payment Card
Industry（PCI）、Health Insurance Portability and Accountability Act（HIPAA）など）ま たは企業コンプライアンス（リスクの軽減など）に基づく規制の遵守があります。1 つの組 織内に複数の要件が存在する場合もあります。たとえば、医療機関によっては、国の規制
（米国の HIPAA など）を遵守する必要があるだけでなく、PCI コンプライアンス要件を満 たす必要もあり、さらに医療機器を分離して患者ケアのリスクを軽減することが必要な場 合もあります。
ポリシーのシナリオ
一般的な医療機関ネットワークの要件例を以下に示します。これらの例に基づいて、SD-Access がどのように要件を満たしながら、ビジネスの俊敏性や柔軟性の向上、運用コスト
の削減を実現するかについて説明します。
前述のとおり、ビジネスの促進要因と要件を評価することから始めます。次に例を示します。
• 患者ケアのセキュリティ：承認された医療ユーザおよび医療機器のみが医療ネット ワークにアクセスできるようにする。
• ビジネス クリティカルなアプリケーションの保護：エンタープライズ ネットワー クへのアクセス時にすべてのユーザ エンドポイントを識別し、承認されたユーザお よび機器のみがアクセスできるようにする。
• 法規制の遵守に関する要件：承認されたユーザまたは機器のみが PCI コンプライア ンスの対象となるエンドポイント、サーバ、アプリケーションにアクセスできるよ うにする。
• 患者ケアの実現：ゲスト ネットワークをエンタープライズ医療ネットワークから分 離する。
次のステップは、上記の主なリソースがそれぞれどこにあるかを把握できるようにネット ワークを評価することです。
次に例を示します。
• 医療機器はネットワーク内のどこに存在しているか。
• PCI の対象となるサーバおよびアプリケーションはどこにあるか。
• 医療ユーザはネットワーク内のどこに存在しているか。
そして、すべての評価対象のリソースを IP アドレスのサブネットに明確に関連付けます。
これにより、サブネットに人間がわかる名前を付けたネットワーク オブジェクトを構築で きます。ただし、ネットワークの拡大によって時間とともに、特定の目的に関連付けられ ないサブネットが不規則に発生する可能性が高くなります。
次に例を示します。
• 192.0.2.0/24 = MRI_Devices
• 10.1.1.0/24 = Imaging_Servers
• 198.51.100.0/24 = PCI_Apps
• 10.1.100.0/24 = Staff
• 10.1.200.0/24 = Guests
ポリシーの構築
次にネットワーク アーキテクトは、環境内のすべてのサブネットに対して、これらのネット ワーク オブジェクトとアクセス権限の関係（アクセス コントロール ポリシー）を構築する必要 があります。通常これは、セキュリティ管理システムを使用して行います。セキュリティ管理 システム（ファイアウォールや ACL 管理システムなど）により、IP プレフィックスと「ネット ワーク オブジェクト」の関係をわかりやすく抽象化してマッピングすることができます。
その後、ネットワーク アーキテクトは、特定のプロトコル（IP、TCP、UDP など）やポー ト（http、https など）に対するネットワーク オブジェクト間のアクセス コントロール ルールを作成して、オブジェクト間のアクセス権限（許可または拒否）を設定します。
図 ポリシーの構築例
ポリシーを確実に適用するために、ネットワーク管理者は、（各サブネットの）関連トラ フィックが、対応するポリシー適用ポイント（ACL を使用する配信スイッチ、キャンパス ファイアウォールなど）に送信されるようにネットワークを設計する必要があります。そ の後、管理システムにより、ネットワーク オブジェクトを使用して、IP アドレスがポリ シー適用ポイントにプログラムされます。
ほとんどの場合、アクセス コントロール セキュリティ ポリシーの適用結果であるすべての テレメトリは、ログ、フロー データ、ヒット カウンタなどにおいてすべて IP アドレスで 表されます。これは、ポリシー適用ポイントで生成されるすべての情報は、ポリシー コン ストラクトではなく、ネットワーク コンストラクトのみに基づいて生成されることを意味 します。また、すべてのセキュリティ管理製品またはアシュアランス製品では、エンター プライズ内の複数の適用ポイントにおいてネットワーク コンストラクトをポリシー コンス トラクトに変換し直す必要があるということでもあります。
この処理は通常、テレメトリのさまざまな形式やデータのさまざまな側面への対応を必要 とするため、非常に複雑な作業になります。比較的簡単なタスクを実行する際にもこの複 雑な関連付けが必要になります。たとえば、「このログは、IP アドレス 1（ネットワーク オブジェクト A のアドレス）が IP アドレス 2（ネットワーク オブジェクト B のアドレス）
と現在通信していることを示しており、これはセキュリティ ポリシー X に違反している」
などです（この文からわかるとおり、タスクとしては単純です）。
ポリシーの実装
上記の内容は、デバイスをサブネットに接続するとサブネットのすべてのセキュリティ アクセスが継承される、ということが前提になっています。エンタープライズ ネットワー クの従来の目的は、可用性の高い高速アクセスを実現することです。
これには、ポリシーに関する重要な意味が含まれています。
たとえば上記のネットワークオブジェクトを使用する場合、
まとめ 従来すべてのポリシーは VLAN または IP サブネットに基づいているため、ポリシーオ ブジェクトにマッピングして関連性を維持することが非常に複雑になっています。
• SecOps は、IP サブネット 192.0.2.0/24 および VLAN 100 に関連付けられた
「MRI_Devices」というオブジェクトを作成しています。
• NetOps は、ポート 1 ～ 12 を、すべてのアクセス スイッチで VLAN 100 に割り当 てています。
• 壁面の適切なポートに機器を差し込むと、セキュリティ システムによって MRI 機 器として分類されます。
この場合、ワイヤレス LAN を導入してもデバイスや ID に関する新たな課題は発生しまし たが、セキュリティのために IP サブネットをネットワーク オブジェクトにマッピングす るという従来の方法は変わっていません。また、ワイヤレス化によってユーザおよびデバ イスのモビリティがもたらされましたが、その結果、ユーザやデバイスがネットワークの あらゆる部分に出現する可能性があるため、ネットワーク トポロジとセキュリティ ポリ シーを密接に結び付けることが難しくなりました。
さらに、IPv6 アドレスをネットワークに追加する場合は、上記の作業をすべてもう一度行 う必要があるうえに、次のような新たな課題も生じます。
• IPv6 では、ネットワーク スコープや集約サブネットが増え、各ユーザおよびデバ
イスが複数の IPv6 アドレスを使用する場合があります。
• IPv6 アドレスは IPv4 よりも長く、16 進数（英数字）を含んでいるため、多くの場
合読みにくく、思い出すのも困難です。
• セキュリティ管理ツールによっては、IPv6 ネットワーク オブジェクトを別に作成 したり、ソフトウェアをアップグレードしたりすることが必要な場合があります。
現在ポリシーを作成して適用した場合に、ポリシーの作成に使用した管理ツールから移行 できなくなることがよくあります。ソフトウェア定義型ネットワーキングにより、ネット ワークやアプリケーションは自動的に作成されるようになりますが、セキュリティ ポリ シーまで自動化することは容易ではありません。多くの場合、不完全な自動化に終わるか
（ワークロードのみで、ブランチ内のユーザやデバイスには未対応であるなど）、もしく はベンダー固有の自動化になってしまいます。
通常、ネットワーク オブジェクトおよびポリシーは、タイプの異なる適用ポイント（ファ イアウォール、スイッチ、ルータなど）には拡張されません。適用ポイントのタイプに応 じて異なる管理システムで管理されていることが多く、システム間でポリシーを手作業で 同期する必要があります。マルチプラットフォームやマルチベンダーの管理に焦点を当て たサードパーティ製ツールもありますが、一般的な構造に限られており、別のレベルで運 用がより複雑になることもあります。