[登壇レポートと勉強会感想]「サーバーのセキュリティ対策とコンテナのセキュリティ対策の違い」というタイトルで登壇しました #hibiyatech

コーヒーが好きな emi です。

クラスメソッド日比谷オフィスでのオフラインイベント「Hibiya.Tech #3 どうする？コンテナセキュリティ」で「サーバーのセキュリティ対策とコンテナのセキュリティ対策の違い」というタイトルで登壇しましたので、資料を共有します。
また、本イベントにはコンテナに詳しい方もセキュリテイに詳しい方も参加くださり、大変盛り上がりました。勉強会で学んだことも後半で記載します。

登壇資料

補足と抜粋

仮想サーバーでもコンテナでも、基本的なセキュリティの考えは同じです。以下のような観点でセキュリティ対策を実施する必要があります。

• ネットワーク分離
• ネットワークの暗号化
• データの暗号化
• シークレットの保護
• ソフトウェアを最新版にする
• 脆弱性を含むコードを是正する
• アクセス制限
• 侵入検知
• 改ざん検知 etc…

では、仮想サーバーとコンテナのセキュリテイ対策で違う部分って何だろう？と思い、今回は仮想サーバーとコンテナの違いに注目して資料を作成しました。

さて、コンテナが得意な皆様にとっては親の顔より見た仮想サーバーとコンテナの違いについての図です。

改めて、仮想サーバーとコンテナの決定的な違いは「何が分離を担っているか」です。

コンテナは Linux カーネルの機能を利用してプロセスの実行空間を分離したものです。コンテナ管理ソフトウェアである Docker は、内部的には Linux カーネルの機能を使ってホスト OS とコンテナのプロセスを分離してくれています。

つまり、仮想サーバーとコンテナの分離の違いは、ハイパーバイザーで分離されているか、カーネルで分離されているか、と言えます。

ここで「分離」と言うのは「セキュリティ境界」とほぼ同義と思ってください。一般的に、攻撃者とターゲットの間にセキュリティ境界が多ければ多いほど侵入が難しくなります。ですので、セキュリテイの文脈では多層防御が重要だと言われるわけです。

登壇資料に詳しく詳細をのせましたが、カーネルは現在も更新され続け多くの機能を持っており、Linux カーネルは 2,000万行以上のコードで構成されています。
それに比べ、ハイパーバイザーはごくシンプルな機能のみで実装され、Xen ハイパーバイザーは 5万行ほどのコードで構成されています。
コードはシンプルな方が、セキュリテイの文脈では優秀です。

コンテナはカーネルの膨大な機能によってコンテナ間のプロセスが互いに見えてしまったり、メモリを共有できてしまう可能性があります。それに比べ、シンプルな機能のハイパーバイザーの方が分離性は高いと言えます。

また、コンテナ初心者の私にとっては「コンテナのセキュリテイ対策と言えばイメージスキャンでしょ！」という印象がありましたので、イメージスキャンについても少し触れました。

コンテナが常にイミュータブル（不変）であることが前提であれば、コンテナをデプロイする前にイメージをスキャンしてセキュリテイ担保しておく方が効率がよいです。

コンテナイメージのスキャンやデプロイは CI/CD 技術を用いて自動化も実施しやすく、ぜひパイプラインを実装して組み込むべきです。

ちなみに、仮想サーバーでもゴールデンイメージを作成してイメージスキャンをするという構成を組むことが可能です。 あまり見かけないのは、やはりコンテナの方が軽量で起動が早く、CI/CD デプロイに組み込むのが容易だからなのかなと思っています。

勉強会での雑感

外部登壇枠

実際に製品の運用で SRE に取り組んでおられる 山口隆史さん にもご登壇いただき、非常に勉強になりましたのでここに記載させてください。

以下は勉強会を通しての私のメモです。

コンテナをデプロイするまでのすべてのプロセスでセキュリティ対策を実施すべき

コンテナデプロイまでにはいくつかフローがあり、それぞれのフローでセキュリティ対策をすべきです。

100% を目指さない

攻撃者はどんどん新しい攻撃手法を編み出しており、セキュリテイ対策に終わりはありません。常に対策をして 100% を目指すのは非常にストレスです。

セキュリテイで 100% を目指すのは難しいので 99% を目指しましょう、という話は色々な方が繰り返しお話されている印象です。 手前味噌ですが、私も以下の資料で言及しておりますのでお時間があれば覗いてみてください。
IAM ロールはエクスカリバー～イメージでつかむ IAM ロールの世界～ #devio2023

Shift-left の考え方

セキュリティにおける「Shift-Left」とは、セキュリティ対策をソフトウェア開発プロセスの初期段階に組み込むことを指します。
従来、セキュリティは開発プロセスの後半やリリース後に重点を置いて対処されることが多く、問題が発見された場合には修正に多大な時間とコストがかかりました。Shift-Left はこのアプローチを変え、開発サイクルの早い段階でセキュリティを考慮することで、脆弱性を早期に発見し、修正コストを削減し、最終的な製品のセキュリティを向上させることを目指します。

しかし、いくら早期にセキュリティ対策をしても、本番環境のセキュリテイ対策を怠っていい理由にはなりません。

セキュリティ事故は現場で起きているんだ！

本番環境のセキュリテイ対策も重要であると再認識しました。

コンテナ環境におけるフォレンジック調査

「フォレンジック」とは元々、犯罪捜査における分析や鑑識を意味する言葉です。
サイバーセキュリティの分野でにおける「フォレンジック」とは、セキュリティ事故が起きた際、端末やネットワーク内の情報を収集し、被害状況の解明や犯罪捜査に必要な法的証拠を明らかにする取り組みのことを言います。

コンテナは基本使い捨てでどんどん新しいものをデプロイするために実機が残らないという特徴があります。

コンテナ環境で何かセキュリテイ事故が起こった際、調査が難しいというのはセキュリテイにおける課題かもしれません。対策としてはとにかくログを別に管理しておくのが第一歩のようです。

レッドチーム ブルーチーム

レッドチームとブルーチームは、サイバーセキュリティの分野で使われる用語で、組織のセキュリティ対策を評価、強化するための模擬攻撃（Red Teaming）と防御（Blue Teaming）の役割を指します。

参考：レッドチーム vs. ブルーチーム あなたはどっち？（CompTIA米国本部サイトより）｜CompTIA JAPAN (コンプティア 日本支局)

組織内にレッドチームとブルーチームがある企業から参加してくださった方もおり、大変勉強になりました。

参考書籍

参加された方の中にも何人か「読んだよ！」という方がいらっしゃいました。私も参考にさせていただきました。

終わりに

私はコンテナについて全然詳しくないのですが、今日の登壇のためにコンテナセキュリティを勉強してきました。登壇駆動で勉強したおかげで少しコンテナについてわかってきて、更に登壇者の方の話も少し理解が及ぶようになったのでとっても嬉しいです。
また、今日のテーマはコンテナとセキュリティだったので、コンテナに詳しい方もセキュリテイに詳しい方も多く参加してくださいました。いろいろな現場の話ができて本当に面白かったです。