アメリカのバイデン政権は、2021年5月、国家のセキュリティ技術の改善を義務付ける大統領令を発し、特にゼロトラスト（ZT）セキュリティモデルの必要性を呼びかけました。
米国標準技術局（NIST）は8月にZero Trust Architecture（ZTA）を定義し、「ゼロトラストが企業の情報技術セキュリティ体制全体を改善できる展開モデルと使用例」を調査し、ホワイトペーパーrを発表しています。Cybersecurity and Infrastructure Security Agency (CISA) や Office of Management and Budget など、さまざまな政府機関が、ゼロトラストの完全導入までの道のりを実装者が理解するための成熟度モデルなど、ゼロトラストの導入を導く文書を発表しています。
Kubernetesコミュニティは、エンドツーエンドの暗号化戦略の重要なコンポーネントとして、何年も前からゼロトラストについて議論してきました。Service Meshプロバイダーは、ゼロトラストの実装を容易にするために、いくつかの重要なプラクティス（mTLSや証明書のキーローテーションなど）を組み込んできましたが、アプリケーションに堅牢なゼロトラストアーキテクチャを大規模に実装するにはまだ日が浅いのです。Kubernetesにとってゼロトラストとは何か、ベストプラクティスは何かについては、まだ議論が残っています。Kubernetes のネットワーキングとセキュリティが従来の IT およびインフラストラクチャ システムとどのように異なるかについて教育を受けていないチームにとって、Kubernetes はすぐにでも重大なセキュリティ上の課題をもたらします。
ゼロトラストとは何か、なぜそれが重要なのか？
従来のセキュリティモデルは、導入環境の周囲に強固な境界線を設け、中央の門番がユーザーの身元を確認し、承認されたユーザーのみが内部のインフラにアクセスできるようにするものでした。マイクロサービス、クラウド、分散配置の採用により、境界がどこにあるのか、あるいは境界が存在するのかがますます不明確になり、このモデルはもはや選択肢ではなくなりました。そこで登場したのがゼロトラストです。
ゼロトラストモデルでは、ユーザー、アプリケーション、ネットワーク、サーバー、サービス、APIなど、文字通り何も、そして誰も信頼できません。あらゆるレイヤーのあらゆる要素が認証され、認可のためにテストされなければなりません。テクノロジー資産、アプリケーション、サービスが接続してデータを交換するとき、すべての通信は、すべての関係者を認証し、アクセスポリシーに基づいて権限を付与する特定のエージェントを介してルーティングされます。重要なのは、ゼロトラストシステムはすべてのレベルにおいて最小限の権限で運用され、特定のリソースに対して明示的に許可された者以外のアクセスを拒否することです。
ゼロトラストのメリットは数多く、次のような形でセキュリティ姿勢を向上させることができます。
- 不正な活動を自動的に防止します。
- アクセスコントロールにより、攻撃対象となるアクセス可能な領域を減少させます。
- 行動の異常や侵害の指標を迅速に検出します。
- リアルタイムで最小権限のポリシー管理により、アクセス時間の制限を設けます。
- 環境や地域など、他のすべての変数に依存しないセキュリティの実現をします。
- 常時認証と本人確認により、継続的な攻撃をブロックします。
ゼロトラストは、クラウド・ネイティブ・アプリケーションやインフラにとって特に重要です。疎結合でポータブルなクラウドネイティブアプリは、コンテナで実行され、必要に応じて場所や状態を変更するように設計されています。コードや設定、そしてクラウドネイティブアプリを外部や内部のサービスに接続するためのIPアドレスなど、ごく一部の必要な要素を除いて、すべてが一時的な要素として扱われます。East-Westトラフィック（環境内部）とNorth-Southトラフィック（環境への出入り）は、ますます類似してきています。アプリ環境内と外部クライアントの両方において、すべての通信をAPIが仲介します。特権とアイデンティティを常に検証することは、便利なだけでなく、最終的にはセキュリティ上必要なこととなるのです。
Kubernetes環境でゼロトラストを導入するための7つのガイドライン
Kubernetesを利用したインフラやアプリケーションにゼロトラストを導入することは難しいため、ここでは一連のガイドラインを提供します。これらは当たり前のように見えますが、ゼロから実装するのは意外と難しいものです。
ガイドライン#1: Kubernetesのアーキテクチャに複雑さを加えないようにする
ゼロトラストフレームワークなしでKubernetesを実行することは困難であり、ゼロトラストを追加するとさらに複雑になる可能性があります。多くのベンダーが、追加のサービスや機能を提供するため標準として利用する方法は、新しいサイドカーまたはKubernetesカスタムリソース定義（CRD）を使用することです。残念ながら、そのような追加を行うたびに複雑さが増していきます。たとえば、観測に必要なデータを送信するために新しいサイドカーを追加した時、Kubernetesは1つ、場合によっては2つのネットワーク接続を維持しなければなりません。複雑さが増すと、アプリケーションの速度が低下し、アプリケーションのニーズに対応するために大きなPodが必要になるため、インフラストラクチャのコストが肥大化する可能性があります。哲学で使われる「オッカムの剃刀」がここで適用されます。サイドカーやCRDを最小にし、ゼロトラストへの道を最もシンプルにすることこそが、一般的に最良のものとなるのです。
ガイドライン２：開発者とエンドユーザーに最小限のオーバーヘッドを追加すること
開発者はゼロトラストのことを考えたくないですし、作る理由もありません。ゼロトラストを導入することで、開発者が行動やワークフローを変えざるを得ない場合、開発者はセキュリティが足かせになると考え、反発する可能性が高いです。行動やワークフローを変更することは、ヒューマンエラーの可能性を著しく高めます。「ウェットウェア(情報システムに対比した人の脳)」は、常にセキュリティチェーンの弱い部分です。もし、ゼロトラストのメカニズムについて開発者さえそこにあることを知らず、同様にユーザーや顧客にとっても同様の状態でありゼロトラストの仕組みが透明である場合、あなたはNetOpsやSecOpsのエンジニアとして成功していると言えるでしょう。実際、セキュリティ・ポリシーをより強力に、よりきれいに自動化することで、ゼロトラストは理論上、多要素認証の醜い側面や多くのセキュリティ・プロセスの後付け感を取り除き、エンドユーザーの体験を改善することさえ可能です。
ガイドライン３：データプレーンとコントロールプレーンの両方にゼロトラストルールを適用すること
データプレーンはアプリケーションにとって「データを処理する場所」になりますが、コントロールプレーンはしばしばサプライチェーン攻撃やその他の侵害に対して同じように（場合によってはそれ以上に）脆弱になります。ポリシーエンジン、テレメトリとトレース用のデータ収集システムなどの複雑な要素があるため、データプレーンよりもコントロールプレーンで ゼロトラストのコンプライアンスを実施する方がより多くの作業が求められます。データプレーンをゼロトラスト化し、複雑に動き続けるパーツの多いコントロールプレーンの心配を減らすことは魅力的かもしれませんが、ゼロトラスト の影響を最大化するためには、両方が準拠していることを確認する必要があります。
ガイドライン４：East-West・North-Southのトラフィックに対応したゼロトラストを実施すること
多くの組織では、当初、ゼロトラストをNorth-Southトラフィックにのみ適用することを選択しています。これは、環境外のトラフィックは内部トラフィックよりも信頼性が低いと思われるためです。このアプローチは間違いです。Kubernetesでは、East-WestトラフィックはNorth-Southトラフィックと同じように見え、同じように振る舞います。Kubernetesのサービス、ノード、Podはすべて、HTTPまたはHTTPS上のAPIを介して通信します。すべてのトラフィックに同じゼロトラストポリシーとプロセスを適用する方が圧倒的に安全であり、そうすることでそれほど多くのオーバーヘッドが発生するわけではありません。また、最初からあらゆる場所にゼロトラストを適用することで、North-Southトラフィックの ゼロトラストの実践が進化した後にEast-Westトラフィックのゼロトラストをボルトで固定しようとするリスクや頭痛を解消することができます。
ガイドライン５：Ingress ControllerとService Meshを併用すること
Ingress ControllerやService Meshがなくても、Kubernetesでアプリケーションを構築して実行することは十分可能です。しかし、インフラ内のすべての要素でゼロトラストを簡単にデフォルト設定にしたいのであれば、両方が必要です。Ingress Controllerは、APIゲートウェイとロードバランサーのより便利な機能のいくつかを組み込んでいます。また、トラフィックを特定のKubernetes Podにルーティングできる（従来のロードバランサーとは異なる）、真のリバースプロキシのような動作をするという強力な利点もあります。Service Meshは、East-Westトラフィックに対するゼロトラストの実施と、監査や検証のための観測と通知の両方を根本的に簡素化します。したがって、より簡単でクリーンなゼロトラストへの道を歩みたいのであれば、Ingress ControllerとService Meshの両方を同時に設計することです。
ガイドライン６：Ingress ControllerとService Meshを統合すること
これは、ガイドライン5と密接に関連することです。すべての Ingress Controllerが、すべてのService Meshと緊密に統合できるわけではありません。例えば、IstioベースのService Meshは、NGINX Ingress Controllerとは異なるタイプの証明書管理システムを使用します。設計段階で、2つのツールが最小限の労力で緊密に統合できることを確認しておくと、後でかなりの複雑化や構成のハッキングを避けることができます。North-SouthとEast-Westの統合ソリューションの例については、F5のブログ「Kubernetes Ingress and Egress Traffic Managementを簡素化する方法」をご覧ください。
ガイドライン７：証明書の適切な取り扱いを自動化すること
他のほとんどのセキュアな接続形態と同様に、証明書のメンテナンスは、Kubernetesで暗号化のための公開鍵基盤（PKI）コンポーネントを実行するために非常に重要です。ゼロトラスト準拠のためには、証明書管理は自動化され、動的でなければなりません。つまり、証明書は定期的に失効し、ローテーションアウトして、継続的な認証を保証する必要があります。Service MeshとIngress Controllerの両方が、証明書の発行、ローテーション、有効期限を自動化する必要があります。Ingress ControllerやService Meshのためのネイティブまたは最良の統合証明書管理ツールがこれを行えない場合、他の選択肢を見つけるか、この実装を諦める他ありません。
NGINXによるゼロトラスト：不可視、偏在的、そして容易さ
私たちはゼロトラストの初期段階にいます。Kubernetesの採用パートナーが示すように、学習曲線は私たちが望むより少し急です。とはいえ、クラウドネイティブアプリやクラウドホストアプリへのトレンド、そして継続的なサイバーセキュリティの脅威を考えると、早急にゼロトラストへ移行することが不可欠です。ゼロトラストのために導入するシステムを常識的な範囲で賢く選択することで、より早く、よりスムーズに、ゼロトラストの価値を高めるだけでなく、不可視、偏在的、そして容易さという最終目標に向かって移行することができるのです。
Kubernetesでゼロトラストを実現するのは簡単なことではありませんが、ゼロトラストアーキテクチャの機能をあらかじめ搭載したIngress ControllerとService Meshを使用すれば、時間と頭痛の種を減らすことができます。私たちのKubernetesソリューション、F5 NGINX Ingress ControllerとF5 NGINX Service Meshを使えば、今すぐにでも始めることができます。このソリューションでは、CLIコマンドを使用して簡単な設定を変更するだけで、ゼロトラストに必要なほとんどのことが可能になります。
NGINX Ingress Controllerの30日間無料トライアルとNGINX Service Meshの常時無料ダウンロードで、NGINXを始めましょう。NGINX Service Meshを使ったNGINX Ingress Controllerのデプロイに関するチュートリアルは、F5のブログ「How to Simplify Kubernetes Ingress and Egress Traffic Management」をご覧ください。
