クラウドネイティブな環境を考慮したセキュリティの仕組みとは？

昨今、日本においてもKubernetesを利用していわゆるクラウドネイティブな仕組みを用いてインフラ環境を検討、試行、本番環境の構築と運用を進めている先端的な企業、組織が飛躍的に増加しているのではないでしょうか？しかし、検討、試行段階では、あまりセキュリティ対策に関しての議論が土台に上がらない事が往々にして散見されました。2019年に入ってからは、風向きが変わってきたように思われます。日本においてもKunernetes環境におけるセキュリティ対策を真剣に検討、試行、本番環境の構築と運用を推進する組織、企業の取り組みが増加してきている肌感があります。さらに2019年の後半に入ってからはさらに加速しているのではないでしょうか？ただ、そもそもKubernetes環境におけるセキュリティ対策とは何に取り組めばいいのでしょうか？

クラウドネイティブな環境に対して多層防御が効果的に機能しない

FW、IPS/IDS、WAFなどで多層防御構成をKubernetes用に立てれば済むのでしょうか？実は、ここに大きな落とし穴があります。Kubernetes、マイクロサービス、クラウドなどの仕組みを用いてクラウドネイティブな仕組みにシフトするとクラウドネイティブな仕組みならではの新たなセキュリティの課題に取り組む必要があるため多層防御が効果的に機能しない状況に陥ります。理由としては、大きく以下の3つの事象が起因しています。

1. クラウドネイティブな環境は、識別対象を抽象化する
2. マイクロサービスでは、保護するために理解すべき要素が膨大に膨れる
3. マルチクラウド環境に於いては一貫したセキュリティ＋モニタリングも課題となる

具体的にはどのようなことなのでしょうか？IDSを例にして考えてみましょう。IDSは、シグネチャー、もしくは、Snortのようにルールベースで外部からのセキュリティ侵害を検知する仕組みです。例えば、IDSで挙がってくる検知されたセキュリティイベントは、「2019年12月1日5時20分10秒、脆弱性番号XXXXを用いた攻撃を検知しました。ソースIPアドレスは、XXX.XXX.XXX.XXX、デストネーションIPアドレスは、10.10.10.1」のような情報です。しかし、このような情報では、どのKubernetesクラスターのどのNamescape、どのPod、コンテナに対して攻撃が行われたのかを把握するのは非常に困難です。さらに、KuberntesクラスターのNode、Podに対して負荷分散が往々にして行われますので、把握をさらに困難にします。さらに、2019年12月1日5時20分10秒に稼働していたPodは、調査を始めた段階において他のNodeに移動していたり、無くなっている可能性も大いにあります。そして、マルチクラウドでKubernetes環境を構築しているとネットワーク外部との境界が複数存在する、あるいは境界が無い状態となる為、セキュリティインシデント対応が必要な状況が発生した場合は、途方に暮れてしまうのではないでしょうか？このように従来の多層防御構成のみではクラウドネイティブなアーキテクチャーにおいては状況の把握すら困難となってしまいます。話が始めに戻りますが、では、Kubernetes環境におけるセキュリティ対策とは何に取り組めばいいのでしょうか？

Kubernetes環境におけるセキュリティ対策への取り組み

セキュリティ対策をシンプルに考える上で下記のような技術アーキテクチャーモデルを想定してみたいと思います。アプリケーションがデプロイメントされるまでには、CI/CDパイプラインのプロセスを経て、イメージリポジトリ上にイメージがビルド、プッシュされた後にKubernetesクラスター上にデプロイメントされる工程が考えられます。この中でセキュリティリスク低減を実現するために考慮すべきポイントどのように考える事ができるのでしょうか？

現在の所、Sysdig Secure DevOpsプラットフォームではセキュリティリスクを逓減させるために大きく分けて以下、3つの要素が考慮されています。

(A) イメージ内の脆弱性を識別

イメージ内に介在する脆弱性を逐次把握し、脆弱性を出来る限り無くす取り組みを実現する事でセキュリティリスクを逓減させる。

(B) CISセキュリティベンチマークでセキュアな状態を維持

CISセキュリティベンチマークで評価を行い、すべての項目でパスできるようなスキームを通じてセキュリティリスクを逓減させる。

(C) サイバーセキュリティ攻撃を検知・防御

Kubernetersクラスターと構成する要素に対してサイバーセキュリティ攻撃を検知・防御を通じてセキュリティリスクを逓減させる。

そして、このようなクラウドネイティブな仕組みに対してセキュリティを担保する上で重要な事は、膨大な量で抽象化されている要素の情報を如何にリアルタイムで取り出して、セキュリティインシデント対応を迅速に行えるようにするために人間が簡単に把握できるようにできる仕組みが必須となります。とても技術的に困難な仕組みのように思えますがどのように実現できるのでしょうか？

クラウドネイティブな環境を即座に把握できるようにする

クラウドネイティブな環境から抽象化された膨大な要素の情報を如何にリアルタイムで取り出して識別・把握できる出来るようにする事は、クラウドネイティブな仕組みに対してセキュリティを担保する上で重要で必須の基礎情報となります。Sysdigは、CONTAINERVISION™、および、SERVICEVISION™と名付けた仕組みで実現しました。これらの基礎技術は、Sysdig CTO& FOUNDERである Loris Degioanniの発明でありパテント化されています。Lorisは、WireSharkの共同創作者としても著名です。まずは、情報を取り出す仕組みであるSysdig CONTAINERVISION™を説明して行きたいと思います。ホストOS上で稼働するすべてのコンテナ、アプリケーション、マイクロサービス、ファイルアクセス、プロセスであれすべてがOSに対してシステムコールでアクセスしています。Lorisは、まずこの点から発想を得て、すべてのシステムコールを取り出す仕組みを作って人間が把握できるようにしようと作ったのがSysdig CONTAINERVISION™です。オープンソースのSysdigやFalcoも同様の技術を使用してます。

次に、実際の仕組みに対してどのようにデプロイして利用するのかについて説明して行きたいと思います。情報を取り出す仕組みとして、Sysdig Agentをコンテナとしてデプロイします（Kubernetesでは、DaemonSetとしてデプロイします）。同じホスト上で稼働しているコンテナは、すべてOSに対してシステムコールでアクセスしていますので、このシステムコールから要素の情報とメトリクス情報を抽出します。そして、同時にSysdig Agentは要素の情報とメトリクス情報を蓄積する仕組みへ送出します。さらに、Sysdig Agentは、振る舞いを検知する仕組みとしても稼働してます。Sysdig Agentの中には、振る舞いを捉えるセキュリティポリシー(実際にはFalcoルール)が自動的にダウンロードされ、セキュリティポリシーに合致するとトリガー/通知します。また、トリガーした際にはコンテナをポーズさせたり、ストップさせる事もできます。

Sysdig Agentで要素の情報とメトリクス情報が抽出されれば十分だと思いがちですが、実は、クラウドネイティブな仕組みを人間が簡単に把握できるようにする為には、不十分です。次に、これを実現する為の仕組みである、Sysdig SERVICEVISION™を説明して行きたいと思います。例えば、Kubernetesは、コンテナを複数のホストに対してデプロイします。ホストの視点から見ると、ホスト内にどのようなコンテナがどのようにデプロイメントされているのかを把握するのは困難です。Kubernetesの視点から見ると、例えば、設定したNamespace上にPodをDeploymentとしてデプロイされているので、このような視点で要素の情報、メトリクス情報にKubernetesのメタ情報が紐づいていれば、人間が把握する際にも容易になります。この紐づけられている情報があるか無いかでは、セキュリティインシデント対応を迅速に行う上では非常に重要であると言えます。Sysdig SERVICEVISION™は、自動的にKubernetesのメタ情報と要素の情報とメトリクス情報を紐付けてくれる画期的な仕組みです。しかも、人間が把握したい視点でスライス＆ダイス的に視点を色々な角度で切り替えて情報を把握する事も考慮されています。

以上のように、Sysdig CONTAINERVISION™とSysdig SERVICEVISION™を利用する事でクラウドネイティブな環境から抽象化された膨大な要素の情報を取り出して識別・把握できるようにする事が可能です。そして、クラウドネイティブな仕組みに対してセキュリティを担保する上で重要な基礎情報となります。でも、実は、セキュリティインシデント対応を行う上で欠けている仕組みがあります。その仕組みとはなんでしょうか？

サイバーセキュリティにおけるフル-フォレンジック

Wikipediaにおけるサイバーセキュリティの説明の中で「検知フェーズで発見したセキュリティイベントにタイムリーに対応できるよう対応計画を事前に定めておき、法執行機関の支援が得られるよう情報共有や利害調整を行う。そして対応計画にしたがってインシデント分類し、フォレンジックを行うなどしてセキュリティイベントを調査し、その影響範囲を把握し、事前に定めた基準に従ってインシデントの封じ込めないし低減を行う。インシデント対応の結果学んだ教訓を生かして対応計画を更新する」とあるようにフォレンジックの仕組みが必要となります。Sysdig Agentは、フル-フォレンジックを行うことのできる情報としてシステムコールをキャプチャーし、scapファイルを取得する事が可能です。フォレンジックを行う上では最も粒度の細かい情報の１つと言えるのではないでしょうか。そして、Sysdig Agentで生成したscapファイルをSysdig インスペクトで解析を行う事で効果的にフォレンジックを行う事ができます。

まとめ

ここまで、お読み頂くとSysdig Secure DevOpsプラットフォームが、如何にクラウドネイティブな環境を考慮してセキュリティリスクを逓減させる事に取り組める仕組みであるかの概要をご理解頂けたと思います。では、具体的にイメージの脆弱性を検出するポリシーはどのように考えればいいのでしょうか？振る舞いを捕まえてセキュリティ侵害を識別するにはどのように考えればいいのでしょうか？そのセキュリティポリシーの組み立て方はどのように考えられるのか？あるいは、チューニングはどのように行えばいいのでしょうか？PCIDSS要件に即したセキュリティポリシーはどのように組むべきか？NIST800-190の要件に対しては？迅速なセキュリティインシデント対応を行うためには？色々とKubernetes環境におけるセキュリティ対策は考えるべき事がまだまだあります。次回以降のブログでは順次触れていきたいと思います。

試されたい方は、https://sysdig.com/ 内のProduct->Free Trialをクリックすると14日間のトライアルライセンスが発行されます。Sysdig Secureも試されたい方は、http://www.scsk.jp/sp/sysdig/index.htmlからお問い合わせいただければと存じます。