今回は、前回に続き、サービスベースへと進化するネットワークのフローとして、「サービスの発見」「ネットワークの保護」「ネットワークタスクの自動化」「アクセスの制御」について説明しました。

ネットワークをサービスIDベースに移行するとワークフローが変化し、セキュリティに影響を与えます。今回は、「どのようなワークフローに変更するか」「セキュリティポリシーをレイヤー3からレイヤー7へ移動するとはどういうことか」について解説します。

チケットベースのボトルネックを解消

インフラの最新化を進めるためにも、手作業をなくし、自動化を進めていきましょう。自動化を進めていく具体的な手順を知りたければ、インフラストラクチャプロビジョニングを自動化するワークフローが参考になります。例えば、AWS CloudFormationやHashiCorp Terraformなどは、インフラストラクチャの構成をコードで管理することで、手動のプロセスを自動化していきます。

ここで、問題になるのがセキュリティです。セキュリティの自動化が話題になると、ソリューションによってもたらされる将来の状態に目が向きがちです。しかし、これまで築き上げてきた既存の環境への投資はどうでしょう。放棄しようとしていませんか。だとしたら、それは賢明ではないでしょう。

サービスベースのネットワーク環境であろうとも、セキュリティを徹底的に構築することは重要です。ファイアウォールは依然として最新のデータセンターで重要な役割を果たしており、更新やポリシーの適用の自動化も可能です。ファイアウォールポリシーの変更を、チケットではなくイベントに基づいたトリガーにする必要があるだけです。

サービスの変更が動的に行われるため、後続のタスクを持つイベントとして扱うことが合理的です。この概念は構成管理または「Day 2 管理」と呼ばれています。

レイヤー3からレイヤー7へのセキュリティポリシーの移動

ネットワークのユーザーが新しいクラウドベースの環境にサービスをより多くプッシュするようになるにつれ、他のセキュリティアプローチを検討する可能性がでてきます。前回に述べた通り、セキュリティポリシーをレイヤー3 からレイヤー7に移行することが必要になります。これは、基本的に次のことを意味します。

  • サービスIDに基づくトラフィック管理ポリシーの適用
  • 相互認証の要求
  • 転送中の通信の暗号化

これらにどこか見覚えがあるとすれば、恐らくサービスメッシュでしょう。実は、サービスメッシュも同じようなことを行います。サービスメッシュは、ネットワーク層でゼロトラストセキュリティを構築するための一般的なパターンになりつつあります。

なぜなら、ネットワーク内のトラフィックはデフォルトでは信頼されておらず、サービスへの接続をそれぞれ検証する必要があるからです。これこそ、サービスメッシュが爆発的に増加した理由とも言えます。

自動化を有効にする

サービスベースのネットワーク環境における、次の主要なワークフローは自動化を有効化にします。昨今のクラウドをベースとしたインフラストラクチャでは、環境を反復的に構築できるようにするためにテンプレートとなるコードを作成して管理します。これはIaC（Infrastructure-as-Code）とも呼ばれます。

今や、この概念はクラウドコンピューティングの範囲を超えて利用されています。最近では、ピザの注文からSpotifyのプレイリストの作成ですら可能です。

しかし、自動化は完全なのでしょうか。環境をテンプレート化して再現可能とすることは素晴らしいですが、最終的には誰かが反対側にいて、変更をトリガーにしています。継続的な管理はどうでしょう。先ほどの「Day 2 管理」はどうですか。

アプリケーションは組織のニーズに応じて、常に追加または削除されるため、モダンなネットワークでは稼働中の環境を管理し続けることになります。そうであるなら、サービスベースのネットワークに自動化をどのように適用していけばよいでしょうか。

上述したソリューションに合わせて、いくつかの選択肢があります。まず、サービス間の接続を規制するために使用される主要なネットワーク機器に、自動化の原則を適用することです。伝統的な環境では、アプリケーション デリバリ コントローラー (ADC) のようなものを使い、サービスがどのように対話するかに関するルールを管理することができます。

ただし、これらのシステムはIPアドレスに依存しており、多くの場合は手動で構成します。プロビジョニングツールを使用することもできますが、そのソリューションでは変更を適用する方法が変わるだけです。インタラクション部分を取り除くことはできません。

その代わりに、サービスの変化に合わせて動的に変化できるシステムの導入を目標にしましょう。アプリケーションの追加または削除を追跡しているのですから、これらのイベントをプロビジョニング変更のトリガーにすればよいのです。この概念は「ネットワーク インフラストラクチャ オートメーション (NIA)」とも呼ばれています。

より新しい環境に移行していくにつれ、組織はトラフィック管理ポリシーの適用や、IDをベースとしたサービス間接続の自動化を進めたくなることでしょう。そうなると、どのサービスが相互に通信できるかを示すルールを設定しておくことが理想的です。

各サービスのインスタンスの数に関係なく、サービスIDで定義されたルールに従うようにします。これもどこかで見覚えがあるのではないでしょうか。これもまたサービスメッシュが実現するものと同じです。

ここまでくると、「だからサービスメッシュがあれば、すべてを解決できるのです！」と主張しないのが不思議に見えるかもしれません。しかしサービスメッシュとは、より広範なソリューションにおける一部の要素に過ぎません。

サービスベースのネットワークへの移行はサービスメッシュの中心的な動きに似ていますが、サービスメッシュをあらゆる環境に適用できるわけではないのです。ワークフローに真に適したソリューションを形作るには、マイクロサービスやコンテナだけでなく、サービスベースのネットワークが適用されるすべての環境とアプリケーションのタイプを精査する必要があります。