【入門編】Kubernetes NetworkPolicyによるマイクロセグメンテーションの実装 – アプリケーションセキュリティ & 安全な開発防御ガイド

Kubernetes NetworkPolicyで、マイクロセグメンテーションの「鍵」を握ろう!~XSSの恐怖から学ぶ、守りの第一歩~

皆さん、こんにちは!サイバーセキュリティの世界へようこそ。今回は、新人のIT担当者さんや、これからセキュリティを学び始める開発者の皆さんに、ちょっとワクワクするような、でもとっても大切な「マイクロセグメンテーション」について、身近な例え話を交えながら、わかりやすく解説していきますね。

「マイクロセグメンテーション」って聞くと、なんだか難しそう…と感じるかもしれませんが、実はこれ、皆さんの「お家」を守る防犯対策と、とっても似ているんです。

XSSって、一体何が怖いんだろう? ~泥棒さんが狙う「隙間」~

まず、今回のテーマに入る前に、皆さんがよく耳にするかもしれない「XSS(クロスサイトスクリプティング)」という攻撃について、少しだけ触れておきましょう。

XSSは、Webサイトの脆弱性を突いて、悪意のあるスクリプト(プログラム)をユーザーのブラウザ上で実行させる攻撃です。例えば、皆さんが普段使っているSNSに、誰かが悪意のあるリンクを投稿したとします。そのリンクをクリックしてしまうと、皆さんのブラウザ上で、その悪意のあるスクリプトが勝手に実行されてしまい、クッキー(ログイン情報などを一時的に保存するもの)が盗まれたり、偽のログインページに飛ばされたり…なんていう、怖いことが起こりうるんです。

これは、例えるなら、お家に泥棒が入るようなものです。泥棒さんは、家の鍵がかかっていない「隙間」や、窓の鍵が甘いところを狙って侵入してきますよね。XSSも、Webアプリケーションの「隙間」を狙って、悪意のあるプログラムを送り込もうとするんです。

マイクロセグメンテーションは、お家の「部屋ごと」に鍵をかけるイメージ

さて、ここで「マイクロセグメンテーション」の話に戻りましょう。
マイクロセグメンテーションとは、ネットワークを細かく分割し、それぞれの区画(セグメント)ごとに通信を制限するセキュリティ対策のことです。

これを、皆さんの「お家」に例えてみましょう。

  • 従来のネットワークセキュリティ: これは、お家の「玄関」にしっかり鍵をかけるイメージです。外からの侵入は防げますが、一度泥棒が玄関から入ってきてしまったら、家の中のどこへでも自由に行けてしまいます。
  • マイクロセグメンテーション: これは、お家の「部屋ごと」に鍵をかけるイメージです。玄関の鍵は当然として、リビング、寝室、キッチン…それぞれの部屋に鍵がかかっています。たとえ泥棒が玄関から侵入できたとしても、勝手に寝室に入られたり、大事なものを置いている部屋に侵入されたりするのを防ぐことができます。

つまり、マイクロセグメンテーションを導入することで、たとえシステムの一部に攻撃者が侵入できたとしても、その影響範囲を限定し、他の重要な部分への被害拡大を防ぐことができるんです。

Kubernetes NetworkPolicyって、一体何者?

では、このマイクロセグメンテーションを、皆さんがよく利用するであろう「Kubernetes」というプラットフォームで実現するにはどうすれば良いのでしょうか?そこで登場するのが、「NetworkPolicy」という仕組みなんです。

KubernetesにおけるNetworkPolicyは、Pod(Kubernetesでアプリケーションを動かす最小単位)間の通信を制御するための「ネットワークのルール」のようなものです。

攻撃者の視点:隙間だらけのネットワーク

もし、Kubernetesクラスター内のPodたちが、誰でもどこへでも自由に通信できる状態だとしましょう。これは、お家で例えるなら、全ての部屋のドアが開けっ放しになっているようなものです。

もし、あるPodに脆弱性が見つかり、攻撃者がそのPodに侵入できたとします。そのPodが他のPodに自由にアクセスできる状態だと、攻撃者は簡単に他のPodに移動し、機密情報にアクセスしたり、さらに多くのPodを乗っ取ったりする可能性があります。これは、泥棒が玄関から入って、家の中を好き放題に歩き回るのと一緒ですよね。

防御の視点:最小権限の原則で、鍵をかける!

そこで、NetworkPolicyの出番です。NetworkPolicyでは、「最小権限の原則」に基づいて、Pod間の通信を「必要なものだけ」許可するように設定します。

これは、お家の部屋ごとに鍵をかけるように、Podごとに「このPodは、あのPodとだけ通信を許可する」というルールを細かく設定していくイメージです。デフォルトでは全ての通信を拒否しておいて、必要な通信だけを明示的に許可することで、意図しない通信をシャットアウトします。

NetworkPolicyの「ラベル」という名の「鍵」

NetworkPolicyで通信を制御する際に、とても便利なのが「ラベル」という仕組みです。ラベルは、Podに付けられた「タグ」のようなもので、そのPodがどのような役割を持っているのかを示すことができます。

例えば、

  • app: frontend (Webサイトの表示を担当するPod)
  • app: backend (裏側でデータ処理をするPod)
  • app: database (データベースを管理するPod)

のように、ラベルを付けることができます。

NetworkPolicyでは、このラベルを使って、「app: frontend のPodは、app: backend のPodとだけ通信を許可する」といったルールを定義できるんです。これは、お家で例えるなら、「リビングの鍵は、家族しか持っていない」とか、「寝室の鍵は、寝室の住人しか持っていない」といった、特定の住人(ラベル)だけがアクセスできるようなイメージですね。

実際にNetworkPolicyを使ってみよう!

では、具体的なNetworkPolicyの設定例を見ていきましょう。

ここでは、

1. デフォルトで全てのPod間の通信を拒否する
2. WebフロントエンドPod (app: frontend) から、バックエンドAPI Pod (app: backend) への通信のみを許可する

というルールを定義してみます。

1. デフォルトで全ての通信を拒否するポリシー

まず、クラスター全体で、どのPodも他のPodと通信できないように、デフォルトで通信を拒否するNetworkPolicyを作成します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all # このポリシーの名前
namespace: default # このポリシーが適用されるnamespace (必要に応じて変更してください)
spec:
podSelector: {} # 空のpodSelectorは、namespace内の全てのPodに適用されることを意味します
policyTypes:

  • Ingress # 受信通信を制限します
  • Egress # 送信通信を制限します
  • podSelector: {}: これは、このポリシーがnamespace内の「全てのPod」に適用されることを意味します。
  • policyTypes: [Ingress, Egress]: Ingress(Podに入ってくる通信)とEgress(Podから出ていく通信)の両方を制限します。

このポリシーを適用すると、Podたちはデフォルトで「誰とも通信できない」状態になります。まるで、お家中のドアに鍵がかかった状態ですね!

2. フロントエンドからバックエンドへの通信を許可するポリシー

次に、WebフロントエンドPod (app: frontend) が、バックエンドAPI Pod (app: backend) と通信できるように、許可するルールを定義します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-to-backend-allow # このポリシーの名前
namespace: default # このポリシーが適用されるnamespace (必要に応じて変更してください)
spec:
podSelector:
matchLabels:
app: frontend # このポリシーが適用されるPod (ここではフロントエンドPod)
policyTypes:

  • Egress # 送信通信を許可します

egress:

  • to:
  • podSelector:

matchLabels:
app: backend # 送信先Podのラベルを指定 (ここではバックエンドPod)
ports:

  • protocol: TCP # 使用するプロトコル (ここではTCP)

port: 8080 # 送信先のポート番号 (バックエンドAPIが待ち受けているポート)

  • podSelector: matchLabels: app: frontend: このポリシーは、app: frontend というラベルを持つPodに適用されます。つまり、フロントエンドPodからの「送信」通信を制御します。
  • policyTypes: [Egress]: ここでは、Egress(送信通信)のみを許可します。
  • to: - podSelector: matchLabels: app: backend: 送信先として、app: backend というラベルを持つPodを指定しています。
  • ports: - protocol: TCP, port: 8080: 送信先のポート番号を8080 (TCP) に限定しています。

このポリシーを適用すると、app: frontend のPodは、app: backend のPodの8080番ポートに対してのみ、TCP通信を送信できるようになります。他のPodや、他のポートへの通信は、デフォルトで拒否されているため、ブロックされます。

これで、お家のリビング(フロントエンドPod)から、書斎(バックエンドPod)へ、指定された鍵(ラベルとポート)を使ってのみアクセスできる、という状態が作られました。

まとめ:マイクロセグメンテーションで、より安全なシステムを!

いかがでしたでしょうか? Kubernetes NetworkPolicyを使ったマイクロセグメンテーションは、まるで「部屋ごとに鍵をかける」ような、きめ細やかなネットワークセキュリティを実現する強力な手段です。

XSSのような、アプリケーションの脆弱性を突く攻撃からシステムを守るためには、ネットワークレベルでの防御も非常に重要です。NetworkPolicyを適切に設定することで、万が一、一部のPodが攻撃されたとしても、被害を最小限に抑えることができます。

最初は少し難しく感じるかもしれませんが、今回ご紹介したような身近な例えを思い出しながら、一つずつ設定を学んでいくことで、きっと皆さんのシステムをより安全に守れるようになるはずです。

「一歩ずつ対策を学んでいきましょう!」

ぜひ、皆さんのKubernetes環境でも、NetworkPolicyを試してみてくださいね!

コメント

タイトルとURLをコピーしました