Kubernetesにおけるゼロトラストの採用:基礎編 #aqua #コンテナ #セキュリティ #k8s

本ブログは「Aqua Security」社の技術ブログで2022年2月16日に公開された「 Adopting Zero Trust in Kubernetes: The Fundamentals 」の日本語翻訳です。

Kubernetesにおけるゼロトラストの採用:基礎編

---

2022年1月下旬、ホワイトハウスは、連邦政府機関向けにゼロトラストアーキテクチャを構築するための基礎となるメモを発表しました。米国政府からの新たな提言により、多くの組織がセキュリティ状態を改善するために、ゼロトラストネットワーキングが注目される分野となっています。そのため、これらの原則をクラウドネイティブ環境、特に Kubernetes クラスターへ適用することは理にかなっています。

ゼロトラストの歩み

ゼロトラストが Kubernetes へどのように適用されるかの具体的な説明をする前に、ネットワークシステムのセキュリティに対するこの種のアプローチの歴史を見ておくとよいでしょう。

2000年代初頭、英国の Jericho Forum 氏は、ネットワークリソースの非境界化という概念を提唱し、組織はアプリケーションやシステムを保護するためにネットワークファイアウォールのような境界型のコントロールに頼るべきではないことを示唆しました。その代わり、各システムは適切に保護され、直接アクセスできるようにすべきです。

2014年、Google は「BeyondCorp: A New Approach to Enterprise Security」を発表し、同様に企業がネットワーク境界型によるセキュリティから脱却し、ユーザやアプリケーションが発信者を適切に認証・認可していることを確認できるようにする方法について考察しています。

そして今年、ホワイトハウスが発表した「Moving the U.S. Government Towards Zero Trust Cybersecurity Principles」というメモでは、企業は重要なデータやシステムを保護するためにネットワークの境界型防御に頼るべきではない、と再び推奨しています。

このように、20年近く前から、組織は境界型セキュリティへの依存から脱却する必要があるというコンセンサスが得られているのです。なぜ私たちは皆、ゼロトラストネットワークを使用していないのでしょうか。これにはいくつか理由があります。

多くの場合、20年前よりも境界を取り払った方法で、物事へアクセスするようになっているからです。クラウドネイティブシステムの登場と SaaS への大きな依存により、従来の企業ネットワークとそれに関連する境界型ファイアウォールの重要性は本質的に低下しています。

しかし、新たな取り組みが次々と行われていることから、この変革はまだ終わりを迎えていないことは明らかです。それは、少なからずこのような環境に移行することは、見かけほど簡単ではないからです。このように使用するよう設計されていないシステムを適合させることは、限られたエンジニアリングとセキュリティのリソースを奪い合うことになり、時間のかかる作業です。Maya Kaczorowski 氏の最近の記事「BeyondCorp Is Dead, Long Live BeyondCorp」では、この移行が非常に困難である理由のいくつかを深く掘り下げています。

ゼロトラストへの移行は二者択一でありません。ネットワーク境界型制御への依存を捨て、サービスを「信頼できる」ネットワークへ接続することでセキュリティを重要視しない、という概念も検討できるはずです。

ゼロトラスト原則のKubernetesへの適用

ネットワーク境界型制御への依存度を下げるというゴールと、それを実装する上での課題を確立したところで、Kubernetes 環境にゼロトラストの概念を導入するために、組織はどのような実践的ステップを踏むことができるのでしょうか。

Service 間ネットワーキング

まず、わかりやすい例として、コンテナネットワークを見てみましょう。デフォルトでは、すべての Kubernetes クラスターは、すべてのコンテナが他のすべてのコンテナと何の制限もなく直接通信できるフラットネットワークを提供します。このコンテナネットワークは、その中で実行されるアプリケーションによって信頼できるネットワークとして扱われることが多く、そのネットワーク内から発信されたリクエストに対して、Service が認証を必要としないこともあります。

下の図では、さまざまな Serive がすべてクラスターネットワークに接続されています。これらのすべてが他の Service に直接通信する必要はありませんが、デフォルトではネットワークレベルで互いにアクセスできます。

セキュリティの観点から、これを改善するためのいくつかのアプローチがあります。1つ目は、Kubernetes の NetworkPolicy で、クラスター内の ingress と egress の両方のトラフィックに default deny ルールを適用することです。NetworkPolicy は論理的なパラメーター(例えば、デプロイされている Namespace やワークロードに適用されている Label)に基づいてワークロードに適用されるため、関連するワークロードだけが互いに通信できます。

したがって、以下の例では、外部ウェブサイトがデータベースサーバとロギングサービスにのみアクセスできるように制限できます。

このような制約があっても、ゼロトラストの Kubernetes コンテナは、必要なリソースだけが利用できるように、サービス間を認証・認可する必要があります。そのためには、ワークロード ID プロジェクト(SPIFFE など)とサービスメッシュプロジェクト(Linkerd など)を組み合わせて、サービス間通信のための完全なゼロトラスト環境を構築することが必要になると思われます。

ユーザ から Service へのアクセス

もちろん、ゼロトラストの Kubernetes には、ユーザからクラスターへの通信という別の側面も考慮する必要があります。Kubernetes 自体はプロダクショングレードの認証オプションを提供していないため、ゼロトラストのビジョンを完全に実現するためには、やはり外部のソリューションが必要になります。

1つのオプションは、サービスメッシュと同様のモデルを持つことで、ユーザアクセスは Kubernetes API を叩く前に効果的にある種のプロキシサービスを経由し、そのプロキシはデバイス状態やリクエスト頻度といったものに基づいた制御を適用することです。このアプローチの最近の例として、Kudelski Security Research が Cloudflare のサービスを活用し、SSH 経由 でクラスターへのトンネル接続する様子を紹介しています。

まとめ

---

多くの組織が、ネットワークセキュリティに対してよりゼロトラストアプローチを採用する方向に向かっていることは明らかです。ネットワーク境界だけを強化し、内部ネットワークには寛容にしていた古き良き時代は終わりを告げ、多くの組織がこのような新たなアプローチを採用することになるでしょう。

しかし、これには長い時間がかかるでしょう。マイクロセグメンテーションや、きめ細かな権限付与は、他のセキュリティ対策と同様に有効ですが、全体像の一部に過ぎません。マイクロセグメンテーションのみならず、他のエリアでも多角的に対処しなければならないからです。