Kubernetesのセキュリティ対策を整理する「脅威モデリング」のすすめ：特集：クラウドネイティブのセキュリティ対策とDevSecOpsの勘所（3）

クラウドへの移行が進み、Kubernetesなどコンテナ技術を活用するシーンが増えた昨今、管理者を悩ませるのはそのセキュリティ対策だ。GMOペパボのセキュリティエンジニアによる「Cloud Native Days Tokyo 2021」の講演から、脅威モデリングの基本やKubernetesクラスタを題材にした具体的なモデリング方法などを解説する。

[谷崎朋子，＠IT]

　クラウドへの移行が進み、Kubernetesなどコンテナ技術を活用するシーンが増えた昨今、管理者を悩ませるのはそのセキュリティ対策だ。従来の境界防御と勝手が違うので対策が分かりにくい、守るべき箇所が見えない、適切な設定が分からないといった悩みも聞かれる。

　そうした課題に、GMOペパボのセキュリティエンジニア、森田浩平氏が「Cloud Native Days Tokyo 2021」の講演「脅威モデリングで考える Kubernetes セキュリティ」で提案するのは、脅威モデリング手法だ。本稿では、脅威モデリングの基本やKubernetesクラスタを題材にした具体的なモデリング方法などを解説する。

リスクの洗い出しと対策を導き出す脅威モデリング

　新しいアーキテクチャには、その仕組みを前提とした攻撃手法が存在し、対策もそれに応じた新しいものが存在する。コンテナオーケストレーターのKubernetesもそうだ。しかも、コンテナやコンテナイメージ、クラスタ上で実行されるソフトウェア、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインなど、コンテナアーキテクチャの構成要素それぞれにリスクが存在し、見逃すことでアーキテクチャ全体の破綻を招く可能性もある。

　森田氏はこう指摘する。「大切なことは、どこを守るべきなのか、何から何を守るのかを整理し、対策を講じることだ。しかしKubernetesの場合、活用が進むほどにサービスや要素が複数絡み合い、複雑化する。そうなると、どこを守るべきかというシンプルな問いにも複数の答えが浮上し、判断も難しくなる。『Kubernetesやコンテナは難しい』と感じるのは、こうした背景もあるのではないだろうか」

　この“難しさ”をほどくにはどうすればよいのだろうか。

　「防御の基本は、システムがどのように攻撃されるかを理解すること。そのためには、システムのアーキテクチャやアーキテクチャ上で動くコンポーネントが何かを理解し、コンポーネント同士の通信方法や経路、重要データへのアクセス方法などを把握することが必要不可欠だ。全体を把握する方法はさまざまだが、リスクの特定も含めて整理するなら、脅威モデリングがお勧めだ」（森田氏）

　脅威モデリングは、システムの潜在的な脅威を予測するためのモデルを作成するプロセスのこと。システムを抽象化して全体像を俯瞰（ふかん）し、リスク要因の発見につなげるのが主な役割だ。

　脅威モデリングを実践するためのフレームワークには、有名なところで「STRIDE」「PASTA」「Trike」「RRA」などが挙げられる。STRIDEはMicrosoftが提唱するフレームワークで、システムの脅威をSpoofing（なりすまし）、Tampering（データ改ざん）、Repudiation（否認）、Information Disclosure（情報漏えい）、Denial of Service（サービス拒否）、Elevation of privilege（特権昇格）の6つに分類し、それぞれの頭文字を取ったものだ。脅威を抽象化、整理してシステムに該当箇所があるかどうかを探るのに役立つという。

脅威モデリングの流れ

　脅威モデリングは大まかに、フレームワークの決定、インフラなど保護対象の構成図の作成、脅威の特定、脅威の要因となる攻撃手法の列挙、対策優先度の決定を行う。

　まずは、保護対象のシステムやインフラの構成図を作成する。これは「DFD（Data Flow Diagram）」といい、対象となるコンポーネントを列挙してデータの流れやデータの扱われ方などを記載、整理する作業だ。

　「DFDを書くことでデータの流れが俯瞰でき、どのような脅威が発生し得るかを考える一助となる。作成するときは、システムのドメイン知識のある人に聞き取りしながらまとめると、より良いDFDが作成できる」（森田氏）

　DFDを図示する際の主な構成要素には、プロセス（WebサービスやOSプロセスなどデータの入出力）、データストア（永続的／一時的な記憶領域）、外部エンティティ（ユーザーや外部サービスなどの直接制御できないもの）、データフロー（プロセス、データストア、外部エンティティ間のデータの流れ）、信頼境界（ネットワークやホストなど制御が必要な境界）がある。特に信頼境界線を越えることはすなわち攻撃にさらされることを意味し、「アタックサーフェス（攻撃対象範囲）」となる。

KubernetesのDFD例（森田氏の講演資料から引用）

　DFDを作成したら、次は可能性のある脅威を特定する作業に入る。脅威の特定方法には、例えばSTRIDEをフレームワークに用いる場合は「STRIDE-per-Element」「STRIDE-per-Interaction」がある。STRIDE-per-Interactionでは信頼境界と交差するデータフローに着目して脅威を洗い出す、STRIDE-per-Elementでは全要素に対して注意すべき箇所は全て洗い出すといったように、それぞれアプローチが異なり、脅威の見つけやすさや時間などに違いがある。

　「システムの規模や複雑度によってアプローチが変わるので、私も何度か脅威モデリングをしているが、脅威の特定はなかなか難しいと感じる」と森田氏は明かす。

　脅威を特定したら、続いて具体的な攻撃方法を列挙する。例えば別のユーザーになりすます脅威が考えられる場合、なりすましの手法として不正ログインとリクエストの盗聴を列挙。さらに不正ログインをする方法として、総当たり攻撃やリスト型攻撃、あるいは弱いパスワードの設定などを列挙する。

　このように、目的と手段を木（ツリー）構造で表現したものを「Attack Tree（アタックツリー）」という。木構造で攻撃パターンを俯瞰し、攻撃を防ぐ条件を導出するのが目的だ。

Attack Tree（森田氏の講演資料から引用）

　もっとも、アタックツリーを作成するには攻撃手法に関する知識が必要で、その出来がツリー作成者の知識や経験に依存するという課題がある。そこで利用するのが、「Attack Library（アタックライブラリ）」だ。攻撃パターンをまとめたもので、「CAPEC」「ATT&CK」が有名だ。「KubernetesのATT&CKはMicrosoftが、コンテナのATT&CKはMITREが作成しており、Kubernetesの脅威モデリングで大変参考になる」（森田氏）

　脅威と具体的な攻撃手法を列挙したら、次は対策の優先度を付ける。これは、「CVSS」「DREAD」など、リスクのスコア評価用のフレームワークを活用する。

　そして最後は、対策の検討だ。対策には、「根本的に解決はしないが緩和は可能と」「リスクある機能を排除してしまう」「外部サービスに対策を任せる」「リスクを受け入れる」など、さまざまな選択肢がある。「利便性やビジネス目標など考慮しつつ、最も効果的かつ実装コストが低い対策を考えるのがよい」と森田氏は助言する。

　また、「対策後の検証も大切」と森田氏は付け加える。要件は満たされているのかどうか、脅威は検出できるようになったのかどうか、対策は実施されているのかどうかなどの観点で検証し、次の脅威モデリングにつなげていく。

　現在参考にできるKubernetesの脅威モデリングとして、Security Audit WGのRRA（Rapid Risk Assessment）、CNCFのFinancial User Groupが作成したSTRIDEベースの脅威モデリング、ソフトウェアの脅威モデリングの「GitLab Kubernetes Agent」を森田氏は挙げた。

　例えば、Security Audit WGが2019年に作成したRRAは、Mozilla Foundationで利用されているRRAテンプレートをカスタマイズした脅威分析手法で、システム構成に加えて、システムの機密性、完全性、可用性を保護する技術的な要素（Control Families）を抽出。「kube-apiserver」「Kubelet」などのコンポーネントごとに評価、分析するのが特徴だという。

Security Audit WGのRRA（森田氏の講演資料から引用）

架空のKubernetesクラスタで脅威モデリングの流れを理解する

　ここまで脅威モデリングの外観は何となく理解できたが、どのように作成すればいいのだろうか。森田氏は「脅威モデリングをイメージしやすいように」と、架空のKubernetesクラスタを題材とした事例を紹介した。

　まずは、KubernetesクラスタのDFDを作成する。KubernetesはMasterとNode、データストアは「etcd」を使用。アプリケーションのデプロイは「Argo CD」で行い、ソースコードリポジトリからWebフックを受け取る構成だ。また、コンテナイメージは「DockerHub」から取得し、その他にもコンテナとして「Grafana」などダッシュボード系のアプリケーションが動いているものと想定する。

　このDFDを基に、STRIDE-per-Interactionで脅威を特定する。

架空のKubernetesクラスタで脅威モデリングを体験する（森田氏の講演資料から引用）

　例えば、外部攻撃者とプロセスのデータフローに注目してみる。赤い丸は信頼境界との交差を示している。これをSTRIDE-per-Interactionで列挙したのが、図の右下にある表だ。kube-apiserverに対してリクエストを大量送信してDoS攻撃ができるリスク、ダッシュボードに不正ログインして任意のコンテナを実行できるリスクなどが挙げられる。こうして列挙すると、外部に露出している箇所の脅威が見えてくる。

　具体的な攻撃手法や脅威特定の補完材料には、ATT&CKも活用できる。ATT&CKは、攻撃のきっかけから実行、攻撃の永続化、権限昇格といった攻撃の一連の流れの中で使われる手法をマトリックスにしたものだ。

　例えば攻撃のきっかけである「Initial Access」欄を見ると、赤いマスに「Exposed Dashboard」と書かれているのが見つかる。これは、Argo CDやGrafanaなどのダッシュボードにアクセスできてしまうリスクが該当する。「KubernetesダッシュボードやArgo Workflowsを狙って任意のPodを作成し、コインマイニングをするという攻撃も観測されている」（森田氏）

　脅威を特定したら、その情報を基にアタックツリーを作成する。「前述のArgo CDダッシュボードへのアクセスなら、認証不備の可能性が考えられ、それは弱いパスワードを利用する、総当たり攻撃をすることで不正ログインした結果だ」といったように攻撃手法が列挙できる。ここまで作成できれば、攻撃のリスクが可視化され、最優先で守るべきところはどこなのかが分かり、対策の優先度も自然と決まってくるだろう。

架空事例でのアタックツリーの作成例（森田氏の講演資料から引用）

段階的に脅威モデリングを導入するのも一つの手

　「脅威モデリングは、見落としがちなリスクも明らかにしてくれる。以前、Webサービスの脅威モデリングを実施したとき、外部連携しているサービスのアカウントで多要素認証が適用されていないことが判明した。小さいことだが大事な見落としを発見できたのも、脅威モデリングをしたおかげだ」（森田氏）

　ただし、脅威モデリングが万能というわけではない。「どんなに完璧に実践できたと思っても、見落としがゼロになるわけではない。その上で、「セキュリティリスクに対する感度を高めるトレーニングも取り入れたい」と森田氏。そうした力を身に付けて、例えば設計段階でリスクを早期発見できれば、リリース後の改修や修正、対応といったコストを削減することにもつながる。

　もしも脅威モデリングが大変なら、ATT&CKを参照するだけでもいい。Kubernetesクラスタに対してどのような攻撃手法が存在するのか、そこを守ることができているのかどうか、改めて確認するきっかけになるだけでも有用だ。そして慣れてきたら、自社専用のATT&CKを作成したり、発見した脅威や対策をチェックリストにして次のサービスに生かしたりといったように、自分たちの環境に合わせて段階的に実践していくのも一つの手だ。

　「私自身も、まだ手探りの部分は多い。脅威モデリングを実施して難しかったところ、良かったところなどを今後多くの方と共有できれば幸いだ」（森田氏）

特集：クラウドネイティブのセキュリティ対策とDevSecOpsの勘所

素早く価値を生み出すためにビジネスとITサービス開発、運用を直結させる取り組みが不可欠となっている。そうした中、注目されているアプローチがスピーディーにアプリケーション＝ビジネスをデプロイし、その後も高度な変化適応力を持ちながら、安定的に運用する「クラウドネイティブ」だ。近年、ビジネスの要となるが故に攻撃者はクラウドを標的とする傾向を強く示している。特に、GitHub.comやDocker Hubといった、公開されているアプリケーション資産やサービス活用におけるプロセス、設定の脆弱性を突く攻撃と漏えい事件が世間を賑（にぎ）わせているのは、周知の通りだ。ITサービスを、いかに脆弱性を減らしてリリースし、安全に運用していくのか。本特集では、そのカギとなる「DevSecOps」の取り組みを中心に、クラウドネイティブにおけるセキュリティ対策の勘所を探る。

特集：クラウドネイティブのセキュリティ対策とDevSecOpsの勘所