クラウドネイティブとは何を意味するのでしょうか。Linux Foundationによるプロジェクト傘下でコンテナ技術推進などを目的に2015年に創設された財団「The Cloud Native Computing Foundation（CNCF）」によると、クラウドネイティブのテクノロジーとは、企業や組織がクラウド環境やオンプレミスアーキテクチャを駆使することで、ソリューションを発展させるのに役立つ技術と定義しています。
現在のビジネス環境では、特にコロナによるパンデミックがデジタルトランスフォーメーションを加速させている中、企業や組織は、コンテナおよび「コードとしてのインフラ（Infrastructure as Code）」を含むクラウドネイティブテクノロジーを迅速に導入しています。こうした中、クラウドネイティブ環境でのセキュリティ対策は、クラウドアプリケーションを利用したプロジェクトが世界中のさまざまな企業や組織で使用されていることから大きな懸案の1つとなっています。これらのアプリケーションを使用している企業や組織は、アプリケーションにおける相互依存関係に脆弱性が存在するだけで、システム全体に影響を及ぼし、場合によってはアプリケーションが関わるクラスター全体が危険にさらされる可能性があることを認識する必要があります。
その他、例えば、クラウドネイティブプロジェクトのほとんどは、オープンソースのソフトウェアである各種ライブラリおよびそれらの関係性に依存しています。これらのライブラリは、通常、開発ライフサイクルの中で組み込まれ、アップデートや既知の脆弱性のチェックが行われることはほとんどありません。こうした現状も、クラウド資産へのセキュリティ侵害につながる可能性があります。
本稿では、クラウドネイティブアプリケーションへのセキュリティ対策における脆弱性を整理し、企業や組織が時間とリソースを割いてセキュリティ対策を講じるべき懸念事項がいかに拡大しているかを示します。
■ クラウドネイティブアプリケーションがもつ脆弱性の範囲と深刻度を把握する
CNCFには、Security TAG（STAG）というチームが編成されており、クラウドネイティブのエコシステム全体におけるセキュリティリソースの制御および作成を担当しています。このチームの任務の1つは、クラウドネイティブプロジェクトに対し、独立したセキュリティ監査の依頼や調整を実施することです。
なお、実際のクラウドネイティブプロジェクトで実施された2018年から2020年のセキュリティ監査の一覧は、巻末のリンク先のレポートを参照ください。また、これらのプロジェクトに関する報告書や評価は、GitHubのプロジェクト上にも掲載されており、今後も更新されていく予定です。
CNCFは、2018年以降、こうしたクラウドネイティブプロジェクトの分析に際し、Cure53社、Trail of Bits社、Atredis Partners社、AdaLogics社などの独立系セキュリティコンサルティング企業4社に委託しています。トレンドマイクロは、これらサードパーティのコンサルティング会社の報告書からそれぞれの分析結果を精査しました。また、同書のセキュリティ監査の内容もチェックし、脆弱性の種類や深刻度などを比較しました。
これらのプロジェクトでは、クラウドネイティブのアプリケーションを対象にした分析活動を介して脆弱性の件数が調査されていました。下図のとおり、Kubernetesで確認された脆化性の件数がトップになったことは驚くべきことではないでしょう。Kubernetesは、調査が実施されたプロジェクトにおけるアプリケーションの中では、最も多く実装されており、規模が大きくコード数も多いため、脆弱性が発見される可能性が高くなっています。以下、第2位は、etcd、第3位は、Helmといったアプリケーションのプロジェクトが続いています。
図1：CNCFが公開しているセキュリティ監査報告書に基づくクラウドネイティブアプリケーションのプロジェクトごとの脆弱性件数
また調査に際しては、脆弱性のタイプおよび発生状況が分類されていました。例えば、Trail of Bits社による調査の場合、脆弱性がさまざまなクラスやカテゴリーに分類され、データ検証、サービス拒否、認証、その他のタイプの問題として扱われていました。それぞれの主な項目は、下表の通りとなります。
| 脆弱性タイプ | 詳細 |
| アクセスコントロール | ユーザの認可と権限の評価に関すること |
| 監査とロギング | アクションの監査や問題の記録に関すること |
| 認証 | ユーザの識別に関すること |
| 環境設定 | サーバ、デバイス、ソフトウェアのセキュリティ設定に関すること |
| 暗号技術 | データのプライバシー又は完全性の保護に関すること |
| データの公開 | 機密情報の意図しない露出に関すること |
| データ検証 | データの構造や値への不適切な依存に関すること |
| サービス拒否 | システム障害の発生に関すること |
| エラー報告 | 安全な方法でエラー状態を報告することに関すること |
| 修正パッチ | ソフトウェアを最新の状態に保つことに関すること |
| セッション管理 | 認証されたユーザの識別に関すること |
| タイミング | レースコンディション、ロック、操作順序に関するもの |
| 未定義の動作 | プログラムによって引き起こされる未定義の動作に関するもの |
表1：Trail of Bits社の分類法に基づくそれぞれの脆弱性タイプの詳細
なお、調査全体としては、脆弱性のタイプが特定されていない報告書もいくつか存在したため、それらに関しては、脆弱性の説明および影響に基づいてトレンドマイクロ側で分類しました。こうしてトレンドマイクロが各報告書を分析した結果に基づく脆弱性タイプ別内訳は、以下の通りとなります。
図2：Trail of Bits社の脆弱性分類による脆弱性タイプ別件数の推移（トレンドマイクロで整理）
「データ検証」に分類されるタイプの脆弱性件数は、60件近くに及び、脆弱性タイプのトップに位置しているため、特に懸念すべき対象の一つとなっています。「データ検証」という脆弱性タイプは、主にデータ入力の検証動作と関係があるものが対象となり、その他、スタックベースのバッファオーバーフローや、ヒープオーバーフロー、整数オーバーフローなどのデータ検証関連の動作を引き起こす脆弱性も含まれています。信頼されていないデータを検証せずに使用することは深刻な問題であり、こうした動作を引き起こすあらゆる種類の脆弱性がこのタイプに分類されます。
例えば、Atredis Partners社が2019年5月にTrail of Bits社と共同で実施したセキュリティ監査で明らかになった脆弱性「kubectl cpにおけるディレクトリトラバーサルの不適切な修正パッチ適用」の事例をあげてみます。なお、この脆弱性は、Kubernetes v1.13.5で見つかったものであり、現在はすでに修正パッチにより対応されています。
図3：Atredis Partners社およびTrail of Bits社の監査で明らかにされたKubernetesの脆弱性
報告書によると、Kubernetesの脆弱性は、特権ユーザがkubectlcpコマンドを使用してコンテナ間でデータをコピーできると記載されています。この場合、Kubectlがテープアーカイブ（tar）ファイルを使用して1つのコンテナを消費し、それらを別のコンテナに転送して実装します。その際、kubectlは、処理中にtarファイルの構造を完全に検証しないため、攻撃者は、目的のコンテナに任意のファイルを書き込むことが可能となります。
図4：Kubernetesのv1.13.5およびv1.14.0に存在する誤った検出ロジック
この脆弱性の回避策は、本来、「リンクによって参照されるパスが絶対パスであるかどうか」または「ファイルにパスを示すショートカットが含まれているかどうか」を検証することになります。、しかしながら、誤った検出ロジックでは「リンクされたパスが絶対であるかどうか」のチェックのみにとどまります。このため、エラーや相対パスの有無が確認されず、エラーを引き起こさない有効な相対パスが実行されてしまいます（詳細については報告書を参照ください）。短期的な対応としては、tarファイルの内容を正しく検証することが推奨されます。
「データ検証」に関するタイプの脆弱性に続く第2位は、「環境設定」に関するタイプの脆弱性です。この場合も、適切なセキュリティの環境設定を行っていれば防ぐことができるケースがほとんどです。2021年の初めにも述べたように、クラウドのセキュリティ上の問題の主な原因は「設定ミス」であり、クラウドネイティブアプリケーションに同様の問題が存在していても不思議ではありません。
一例として「CoreDNSの環境設定への深刻な影響」に関する脆弱性を挙げてみます。この脆弱性は、報告書に記載されている脆弱性の中でも深刻度の高い数少ないものの1つです。Cure53社は、2018年3月に公開したセキュリティ監査結果の中でこれを報告しています。この脆弱性は「不正なレスポンスによるDNSキャッシュポイズニング」であり、ローカルのDNSインスタンスのファイル「python_dns.py」に影響を与えます。詳細については、同社の報告書をご参照ください。
そして第3位の脆弱性タイプは「サービス拒否（DoS）」に関するものであり、このタイプの場合、該当のプロジェクトもしくはシステム全体へのDoS攻撃が可能な脆弱性が20件あげられています。DoS攻撃関連の脆弱性は、データの検証が適切に行われていない場合にも発生します。攻撃に際して、想定よりも大きなデータや、短時間に多くのリクエストなどが送信されるからです。
さらにTrail of Bits社が2020年2月に公開したセキュリティ監査報告書では、Kubernetesのコンポーネントであるetcdに深刻度の高いサービス拒否攻撃関連の脆弱性が存在したことが報告されています。これは「ゲートウェイが自身をエンドポイントとして含めるためにリソースの枯渇を招く問題」として認識されており、etcdのバージョン3.4.3のファイルgateway.goに影響を与えます。
図5：etcd上で検出されたDoS攻撃関連の深刻度の高い脆弱性
当該脆弱性の評価としてTrail of Bits社は、報告書の中で以下のように述べています。
「etcdのゲートウェイは、基本的なサービスの発見やアクセスを可能にするシンプルなTCPプロキシです。しかし、このゲートウェイのアドレスをエンドポイントに含めることも可能であるため、ゲートウェイで接続を受け付ける利用可能なファイルの記述子がなくなるまでエンドポイントが自分自身を要求するというループに陥るため、サービス拒否攻撃を引き起こすことが可能となります。」
図6：監査報告書に記載された「etcd上のDoS攻撃関連の脆弱性」に関する記述
次に報告書に記載された脆弱性の深刻度について見てみます。報告書に記載された深刻度に関する説明はどの程度信頼に足るものでしょうか。ほとんどの脆弱性タイプへの対応は堅牢なオープンソースプロジェクトであるといえます。CNCFによる支援のおかげで、これらのプロジェクトは適切に実施され、セキュリティ対策が常に優先されています。実際、報告された脆弱性タイプの中では、深刻度が低い「注意」が最も多く、次に中程度の「警告」が続いています。幸い、ユーザを危険にさらす深刻度が「緊急」のものはわずかとなっていました。深刻度ごとの脆弱性の数の内訳は、以下の通りとなります。
図7：CNCFが公開しているセキュリティ監査報告書に基づく深刻度ごとの脆弱性件数の内訳
脆弱性の深刻度は、深刻度が低レベルの「注意」に分類される脆弱性は、CVSS 3.0のスコアが0.1～3.9であるのに対し、中レベルの「警告」は4.0～6.9です。これらは、高レベルの「重要」や「緊急」に分類される深刻な脆弱性に比べて悪用されにくく、システムへの影響が少ない脆弱性と認識されています。そしてこのように、セキュリティ監査と脆弱性の発見能力に優れたサードパーティのコンサルティング会社による報告書からでも、深刻な脆弱性が存在するプロジェクトが少ないことがわかります。検証したすべてのプロジェクトにおいて「重要」に分類された脆弱性はわずか17件、「緊急」は7件でした。
■ オープンソースセキュリティと脆弱性の増加について
このセクションでは、上述の脆弱性関連プロジェクトの依存関係を分析し、コードを使用している可能性のある旧来型の脆弱なライブラリやライセンスにおけるリスクを説明します。この分析に際しては「Trend Micro Cloud One – Open Source Security」でスキャンを実行することで、以下のようなソフトウェア構成の分析結果を得ることができました。
図8：Cloud One Open Source Security（powered by Snyk）で検出されたクラウドネイティブアプリケーションのプロジェクトの中で、サードパーティと依存関係にある脆弱性件数を深刻度別に分類した一覧
「大きな力には大きな責任が伴う」だけでなく「より多くの脆弱性が存在している」という可能性があります。事実、本稿執筆時点で460万行以上のコードを含む大規模プロジェクトの対象アプリケーションであるKubernetesは、サードパーティとの依存関係にある脆弱性が最も多いものとして筆頭に挙げられます。Kubernetesにおける脆弱性の依存関係には、500件以上に及ぶ深刻度中・高レベルの脆弱性と合わせ、ライセンス上の問題も含まれています。第2位のHarborを対象にしたプロジェクトでは脆弱性は157件しかなく、第3位のVitessは144件となっています。Notaryを対象にしたプロジェクトは、依存関係に致命的な脆弱性がある唯一のものですが、全体の脆弱性件数は最も少ないプロジェクトとなっています。下図のとおり、Notaryの最新バージョンには、ライブラリgormの1つに致命的な脆弱性が存在しています。これはSQLインジェクションの脆弱性で、CVSSスコアは9.8（10点満点中）の高レベルで「緊急」に分類されます。幸い、報告書の分析結果によると、この脆弱性を悪用する脆弱性悪用ツール（エクスプロイト）はまだ確認されていません。ただし、もちろんそれをもって脆弱性の修正が不要であるという理由にはなりません。
図9：Notaryのライブラリ上で確認された深刻度が「緊急（CVSS 9.8）」の脆弱性
図10からは、時間の経過とともに脆弱性件数が増加していることがわかり、毎日のように新たな脆弱性が確認されている状況が示されています。また、プロジェクトが進むにつれて、新規モジュールのコミットのたびに新たなコードが追加され、それに伴い新たな脆弱性も生まれることも増加の原因となっています。通常、業界平均で1000行のコードにつき、5から50件の潜在的な脆弱性が存在していると言われています。こうした状況も、サードパーティに依存するリスクを優先的に扱うべき根拠となっています。
図10：CNCF管轄の各種プロジェクトにおいて検出された脆弱性件数の推移
■ セキュリティに関する提言およびプロセスの改善案
クラウドネイティブアプリケーション対象のプロジェクトで確認された脆弱性の詳細に基づき、このセクションでは、これらの脆弱性へ適切に対処してアプリケーションの更新を続けている限り、セキュリティを確保できるということについて提言や改善案を説明します。また、CNCFによるセキュリティ監査プロセス合理化の必要性を強調することで、今後、より多くのセキュリティ専門家やリサーチャーの参加や協力が得られることも期待しています。
エンドユーザーとセキュリティ専門家への提言および改善案
ありきたりなアドバイスかもしれませんが、クラウドネイティブのアプリケーションを対象にした脆弱性監査に際しては、何よりもまず最新バージョンのアプリケーションを使用することが安全性を保つ上での最善策となります。通常、報告書に記載された脆弱性のほとんどは、報告書が公開された時点ですでに解決されています。CNCFの責任において各プロジェクトにおいて問題を解決済みとしておくことが必須となっているからです。また、脆弱性の問題が解決済みかどうかを確認したい場合も、それぞれのプロジェクトに関する「公開された課題（ラベル：security）」からもチェックすることができます。下図はKubernetesの例を挙げています。このように各プロジェクトにおいて誰でも公開の状態にしておくことが可能であるため、このステップを必須条件しておくことも効果的な対応策といえます。
図11：Kubernetesに関してGitHubリポジトリで「area: security」として公開されている脆弱性関連問題の一覧
また、セキュリティ監査では、以下の2つの方法で確認することが可能です。まず、CNCF管轄の特定プロジェクトに注目し、そのプロジェクトに関するGitHub上のリポジトリでRFPやセキュリティ監査報告書が公開されていることを確認します。そしてさらにGitHub上のTOC（Technical Oversight Committee）のリポジトリを見て、新しい監査が発表された際の更新内容を確認することです。
図12： TOCのGitHubリポジトリに掲載されたCNCF管轄プロジェクトのセキュリティ監査の一覧
さらに企業や組織は、継続的な統合と配信（CI/CD、Continuous Integration & Continuous Delivery）およびそれらの関連アプリケーションを保護することで、クラウドネイティブのシステムを防御するTrend Micro Cloud One
のプラットフォームなどのセキュリティソリューションの利用も検討すべきでしょう。このプラットフォームは、以下の機能を備えています。。
- Workload Security：データセンター、クラウド、 コンテナを保護する多層防御・脆弱性対策を提供するクラウド型セキュリティ
- Container Security：コンテナイメージのスキャン、アドミッションコントロール、コンテナの実行時保護をまとめて実現
- File Storage Security：クラウドファイル/オブジェクトストレージのためのセキュリティ
- Network Security：マルチクラウド環境のための強力なネットワークレイヤのセキュリティ
- Application Security：コンテナ、サーバレスなどに構築された最新のアプリケーションおよびAPI向けセキュリティ
- Conformity：クラウドインフラストラクチャの継続的なセキュリティ、コンプライアンス対応状況の確認および可視化
クラウドネイティブのセキュリティ評価機関による取り組み
CNCF配下のSecurity TAG（STAG）チームは、CNCF管轄プロジェクトのセキュリティ評価を改善し、その頻度を高める努力を続けています。こうした取り組みは優先されるべきであり、CNCFでは、定期的な実施による評価システムを確立し、今後も実行していくべきでしょう。さらには、Kubernetes、etcd、Helmなどの人気のあるアプリケーションのプロジェクトに優先順位をつけ、セキュリティ監査のためのRFPを推進し、多様なコンサルティング会社に委託することも有益でしょう。
もう1つの推奨事項は、CNCF管轄のすべてのプロジェクトを対象とした独自の脆弱性開示プログラムを確立し、可能であれば、バグバウンティ（脆弱性に関する報告を外部の専門家や研究者から受け、その対価として報奨金を支払う制度）も導入することです。実際、CNCF管轄のプロジェクトでは、セキュリティ専門家やバグバウンティハンター（脆弱性を発見する人）が、さまざまなサイトやアプリケーションから脆弱性を探してきています。KubernetesなどのCNCF管轄プロジェクトの中には、こうして発見された脆弱性に対して、その深刻度に応じて100ドルから1万ドルの報奨金を支払うバグバウンティプログラムが存在しています。
そしてほとんどのプロジェクトで「SECURITY.md」（GitHubのリポジトリにセキュリティポリシーを記載したマークダウン文書を配置）や、その他、脆弱性を報告するための何らかの手段がすでに用意されています。ただ残念ながら、現状、すべてのプロジェクトでこうした手順が完全に標準化されているわけではありません。また、何が開示されて何が修正されたかの詳細についてもはっきりしていないケースが多く存在しています。確認された脆弱性は追跡されて対処されるべきであり、問題が確認された場合には、可能であればCVE番号が割り当てられるべきでしょう。
そして最後になりますが、サードパーティ製コンポーネントの問題については、優先順位をつけた適切な調査を実施し、サプライチェーン攻撃からコンポーネントを防御する必要があります。「Supply Chain Security Whitepaper」などのリサーチペーパーの発行は、Security TAGチームによる素晴らしい貢献だといえるでしょう。そしてこうした変化をさらに推し進めるためには、セキュリティのコミュニティとして、こうした改善案を実践し、リサーチペーパーで提供された推奨事項やベストプラクティスをCNCFプロジェクトに適用することで、全体に向けての模範となるべきでしょう。
CNCFによるセキュリティ監査の詳細については、こちらをご覧ください。
参考記事：
翻訳：与那城 務（Core Technology Marketing, Trend Micro Research）
The post クラウドネイティブアプリケーションにおける脆弱性の現状について解説 first appeared on トレンドマイクロ セキュリティブログ.