DevOpsは、アプリケーションを開発して公開し、サポートからのフィードバックを反映していく方法として主流になりつつあります。しかし、DevOpsを成功に導くには、組織面での複雑さやマシンデータの収集といった課題を克服する必要があります。
コンテナセキュリティとは、組織のインフラを攻撃から守ると同時に、コンテナを脅威から守り、セキュアな環境で運用するためのツール活用とポリシー設定のプロセスを指します。
コンテナを保護することが重要である理由は、ネットワークやアプリケーションを保護することが重要である理由と同じです。コンテナが攻撃を受けると、コンテナで実行されているプロセスやタスクが被害を受けるだけでなく、そこが起点となって攻撃が組織のネットワーク全体に広がる可能性があるためです。
コンテナ環境は一般的に複雑であるため、コンテナセキュリティも必然的に複雑になります。組織のコンテナセキュリティ戦略では、コンテナだけでなく、コンテナ内で実行されるコード、コンテナの依存サービスとライブラリ、コンテナの導入環境、アプリケーション開発プラットフォーム、DevOpsプラットフォーム、オーケストレーションプラットフォーム、さらには、これらのテクノロジーの運用基盤であるインフラ全体の保護対策を検討する必要があります。
組織全体を保護するには、コンテナセキュリティを開発プロセスの必須要素として組み込むことが不可欠です。その一番の理由は、コンテナ環境のデプロイ後にコンテナセキュリティを実装することはさらに困難になるためです。この記事では、コンテナとコンテナ化アプリケーションを保護するためのベストプラクティスについて深く掘り下げ、主要なコンテナプラットフォームを保護するうえでの課題について考察します。
コンテナの概要
コンテナは、標準化された小規模かつ軽量なコードであり、モジュール式でポータビリティが高い設計であるため、あらゆるコンピューティング環境に簡単にデプロイできます。アプリケーションのコードとその実行に必要な依存コンポーネント(システムライブラリや各種設定など)をまとめて格納できることから「コンテナ」という名前が付けられました。コンテナにはオペレーティングシステムのコードは含まれず、共有のOS環境上で実行され、サイズが小さく動作が高速です。一般的に、コンテナのサイズは数百MBほどに収まります。これに対して、オペレーティングシステムのコードを含む仮想マシンは通常80 GB以上になります。
コンテナは、マイクロサービス開発で重要な役割を果たします。マイクロサービスは、コードを個々の機能に分割してモジュール化し、それらを疎結合して個別にデプロイできるようにするための技術です。理論的には、複雑なアプリケーションでもマイクロサービス化すれば開発スピードが上がり、管理が容易になります。IDCの最近の予測では、2023年までに開発される新しい論理アプリケーションの数は、過去40年間に開発されたアプリケーション数に匹敵する5億以上に達し、その中でコンテナが重要な役割を果たすと見込まれています。
コンテナテクノロジーの主要プラットフォームはDockerとKubernetesの2つに集約されつつあります。また、大手クラウドサービスプロバイダーはいずれも、コンテナの開発、デプロイ、管理を効率化するための一連のツールを提供しています。
コンテナセキュリティの課題
コンテナがアプリケーションのデプロイ環境として一般的になるにつれて、コンテナのセキュリティニーズも拡大しています。コンテナのメリットの1つとして従来のアプリケーションよりも安全性が高いことがよく挙げられますが、実際には他のアプリケーションと大差ありません。
コンテナセキュリティの最大の問題は、コンテナの性質に関係します。コンテナではコードが高速で実行されますが、実行時にその内部処理を把握することは困難です。そのため、運用チームやセキュリティチームが、脅威やアクセス制御の不備などのセキュリティに関する問題を見落としたり、コンテナの開発者が、問題につながる危険のあるコードに気づかなかったりすることが、大きなセキュリティリスクになります。
コンテナセキュリティの影響は、コンテナの実行環境だけでなく、開発、ビルド、オーケストレーション環境や関連するセキュリティポリシーにも及ぶため、より複雑です。コンテナのセキュリティを確保するには、悪質なコードの侵入を阻止するだけでなく、より幅広いエコシステムの観点で攻撃に対処する必要があります。
コンテナセキュリティの重要性
コンテナへの移行が進むにつれて、コンテナセキュリティの重要性が高まっています。前述のとおり、コンテナの内部処理は把握しづらいため、開発の初期段階でセキュリティに対応し、適切なセキュリティツールを導入することが欠かせません。また、コンテナとコンテナを保護するための技術は比較的新しいものであるため、大規模なインシデントに発展する前の段階で適切なコンテナセキュリティを実装しておくことが大切です。
コンテナの開発とデプロイに関わる担当者にとって、セキュリティは(1番でなくとも)常に大きな懸念事項です。多くの関係者が、コンテナセキュリティはすでに後れを取っており、今、業界全体でその遅れを取り戻す必要があると考えています。また、セキュリティ態勢の強化につながるセキュリティツールはすでに数多く出回っている一方で、ほとんどの組織は実効性のあるコンテナセキュリティ戦略を打ち出せていません。
コンテナセキュリティの重要な要素
コンテナセキュリティの重要な領域には、コンテナ開発、コンテナレジストリ、コンテナ実行環境、コンテナオーケストレーション、基盤ネットワーク/アーキテクチャの5つがあります。
- コンテナ開発/ビルド環境:どの開発プロジェクトでもそうであるように、悪質なコードや質の低いコードが紛れ込んだ状態でアプリケーションが本番環境にリリースされると、組織全体が攻撃の危険にさらされます。また、ビルド環境では、古いバージョンのシステムライブラリや安全性の低いライブラリが使用されて脅威につながることがよくあります。多くの場合、こうした問題は古いプロジェクトで使用したコンポーネントをコピーして再利用したり、セキュリティの低いWebサイトからライブラリをダウンロードしたりすることで起こります。
- コンテナレジストリ:コンテナレジストリは、コンテナセキュリティの重要な要素の1つであり、コンテナイメージを格納した多数のリポジトリで構成されます。開発者が、作成したイメージを保存、保護できるほか、脆弱性スキャンを実行することもできます。コンテナイメージをアーティファクトとして扱うことで、不変性を維持するとともに、まだテストしていない設定変更が本番環境に入り込むのを防止してサービスを保護することができます。また、リスクの高いコンテナを効率的にロールバックしたり、パッチ適用済みのコンテナや更新したコンテナに置き換えたりできるメリットもあります。
- コンテナ実行環境:コンテナを実行環境にリリースした後は、新たなタイプのセキュリティリスクに直面します。コンテナ実行環境のセキュリティを維持するには、違反の発生時に管理者にアラートを送るなど、実行中のコンテナの動作に関するセキュリティポリシーを確立することが重要です。また、スタック全体を攻撃から守るには、コンテナが使用するリソースを管理および監視する必要もあります。
- コンテナオーケストレーション環境:コンテナセキュリティで特に重要な要素の1つが、オーケストレーション環境(多くの場合はKubernetes)です。コンテナ環境は複雑であるため、環境を適切に運用、スケーリングするには、オーケストレーションツールが欠かせません。複雑な環境では設定とアクセス権の管理が問題になることが多く、それがセキュリティ攻撃の格好の標的になります。また、コンテナ環境は複数のノードに分散されることもあり、その場合、各ノードが標的になるためリスクがさらに高まります。
- 基盤ネットワーク/サーバーインフラ:最後の要素は、上記すべての要素を運用するインフラです。コンテナは、サーバーのオペレーティングシステムまたは仮想マシンに依存するため、そこを起点に攻撃される恐れがあります。セキュリティの脆弱性につながる基盤インフラには、WindowsサーバーやLinuxサーバー、仮想オペレーティングシステムのインスタンス、クラウドサービスプロバイダー、ネットワークデバイス、コンテナ環境を管理するためのデバイスなどが含まれます。攻撃者にとっては、組織の基盤インフラに侵入できれば、そこで実行されるコンテナプラットフォームを停止するのは簡単です。
クラウドコンテナの安全性
基本的にコンテナ自体の安全性はコンテナ以外の環境とあまり変わりませんが、環境の複雑さゆえに対応が難しいセキュリティの課題がいくつかあります。その問題の多くは設定ミスに起因するもので、Security Boulevard社の最近の調査では、回答者の67%が過去12カ月間でコンテナまたはKubernetes環境で深刻な設定ミスが発生したと回答し、90%が過去12カ月間でコンテナまたはKubernetes環境でセキュリティインシデントが発生したと回答しています。
クラウドネイティブ環境のコンテナにも、他のタイプのコンピューティングインフラと同様の高いセキュリティが求められますが、他のクラウドセキュリティ関連技術と同様に、セキュアな環境の実現はまだ発展途上にあります。
コンテナセキュリティの脅威
コンテナ環境にはさまざまな脅威が存在します。その中で特に一般的な攻撃や脆弱性には以下のものがあります。
- コンテナイメージの脆弱性:コンテナイメージ、特にオンラインリポジトリで公開されているイメージに、マルウェアが埋め込まれる危険性があります。近年大きな話題になったインシデントでは、一般に公開されている17個のDockerイメージがハッキングされ、仮想通貨のマイニングソフトウェアが密かに埋め込まれていたことが明らかになりました。攻撃者がベースイメージを通じてコンテナ環境を乗っ取り、DoS攻撃を行うゾンビネットワークに参加させる手口もよくあります。
- 認証の脆弱性:コンテナ環境に対する一般的でありながら厄介な脅威の1つが、オーケストレーターへの直接攻撃です。Kubernetes環境を適切に保護しないと、攻撃者に管理者アカウントとパスワードを盗まれて、組織のネットワーク内に簡単に侵入されてしまいます。そこからさらに運用環境内のコンテナに侵入され、機密情報にアクセスされたり悪質なコードや脆弱性を埋め込まれたりする可能性があります。
- アプリケーションの脆弱性:前述のとおり、コンテナといっても実体はコードです。開発段階で悪質なコードが混入するなど、プログラミング環境やアプリケーション開発環境に不備があると、コンテナ環境にとっても重大なセキュリティリスクになります。
- ネットワークの脆弱性:コンテナはネットワークを経由して相互に通信したりオーケストレーション環境と通信したりできるため、SQLインジェクションやXSS攻撃のようなネットワークサービスを標的とする攻撃は、他の環境と同じくらいコンテナ環境でも危険です。
IT環境におけるコンテナセキュリティ脅威とサイバーセキュリティ脅威の違い、およびコンテナセキュリティとサイバーセキュリティの違い
コンテナセキュリティおよびそのソリューションと、サイバーセキュリティは、そもそも別の領域で、求められるスキルセットも異なります。その大きな理由は、コンテナの開発、管理、オーケストレーションに使用するツールが、ネットワークの管理に使用するツールと異なるためです。どちらの環境もコンテナ運用の基盤を構成しますが、Kubernetesのセキュリティは、オープンソースのLinuxサーバーやアマゾン ウェブ サービス(AWS)環境のセキュリティとは大きく異なります。
ただし、企業のネットワーク環境に影響を及ぼす脅威の多くは、コンテナ環境にとっても脅威になります。また、コンテナのセキュリティを維持するには、その基盤インフラのセキュリティを維持することも欠かせません。
Dockerコンテナの安全性
Dockerは、セキュリティに関する重要な検討項目として、カーネル固有のセキュリティ、Dockerデーモンへの攻撃、コンテナの設定ミスや抜け穴、カーネルハードニングセキュリティ機能の4つを挙げています。これらの問題に適切に対処すれば、Dockerコンテナは他のタイプのコードと同じくらい安全と言えます。
Kubernetesの安全性
Kubernetesは管理とオーケストレーションのためのツールであるため、そのセキュリティはDocker環境のセキュリティとは意味合いが異なります。Kubernetesを保護するには、Kubernetesクラスターを実行するサーバー、クラスターのインフラ、クラスター自体のコンポーネントと設定のセキュリティを確保する必要があります。その点で、コードの開発時点で組み込むセキュリティよりも、ネットワークベースのサイバーセキュリティに近いと言えるでしょう。Kubernetesは一般的にコンテナ環境のセキュリティを高めるツールとして知られていますが、その安全性は当然、管理者がポリシーや原則に適切に従うことが前提となります。
コンテナセキュリティのベストプラクティス
以下のコンテナセキュリティのベストプラクティスは、コンテナ保護戦略のための堅固な基盤を築くために役立ちます。
- ダウンロードするコンテナイメージファイルの信頼性と安全性を確認する:コンテナイメージをオンラインで入手するときは、信頼できるソースからのみダウンロードすること、最新バージョンであることを確認すること、安全性の低い古いコンポーネントが含まれていないかをチェックすることが重要です。マルウェアに感染していない安全なコンテナを入手する方法の1つとして、Dockerのコンテントトラストシステムを活用することをお勧めします。
- コンテナのサイズをできるだけ小さくして寿命を短くする:コンテナは必要なときにのみ起動し、目的を終えたらすぐに停止します。実行されていないコンテナには攻撃者もアクセスできないため、セキュリティの観点からも、組織の設計と運用の標準規則としてコンテナの寿命を短くすることをお勧めします。
- コンテナプラットフォームを常に最新の状態に保つ:プラットフォームのアップデートやパッチ適用はできるだけ早急に行うことが大切です。Docker Engineなどのコアコンポーネントは週1回のペースで更新してください。
- コンテナのライフサイクルを可視化する:把握できない問題は解決できません。そのため、コンテナの定義から稼働まで、ライフサイクル全体を可視化することが重要です。また、脆弱性スキャンやパイプライン分析を自動化することもお勧めします。
- 環境を頻繁に監査する:Docker Bench for SecurityやKubernetes Auditingなどのコンテナセキュリティツールを使用すれば、ユーザーのアクティビティやアプリケーションのトランザクションの監査など、さまざまな機能を簡単に実行できます。
- コンテナの権限を慎重に定義する:アクセス制御とコンテナの権限を定義する際に、信頼できるソースにのみアクセス権を付与すれば、権限昇格攻撃を軽減または防止できます。
- 専用のホスト環境を用意する:ホストのオペレーティングシステムを含め、コンテナのホスト環境はコンテナの実行にのみ使用し、脆弱性を生む可能性のある印刷サービスなどの不要なサービスは実行しないようにします。ホストOSで不要なサービスを手動で無効にしたり、コンテナ環境用の軽量ディストリビューションを使用したりすることもできます。
- ネットワークをリアルタイムで監視する:さまざまな対策をしても攻撃者がそれをすり抜ける可能性があるため、ネットワークアクティビティをリアルタイムで監視して、不審な動作をすばやく検知することが重要です。特に、コンテナ環境のAPIの脆弱性を突く攻撃には注意が必要です。コンテナセキュリティに監視は欠かせません。
コンテナセキュリティの最重要課題
コンテナセキュリティに関する最重要課題は、セキュリティをコンテナ環境の必須要素として組み込むことです。そのためには、運用、サプライチェーン、管理の各段階で以下のプラクティスを取り入れる必要があります。
- コンポーネントを再利用する際はその安全性を検証し、コンポーネントを社内開発する際はセキュリティプラクティスに従うことで、コンテナイメージの安全性を確保する
- コンテナ間の通信とワークフローを管理して、ネットワークの動作やファイアウォールルールが適切であることを確認する
- コンテナの機能を必要最小限に絞って、不正なプロセスを実行されないようにする
- すべてのプラットフォームと管理アプリケーションをアップデートして、攻撃に対する防御力を高める
- 開発者と運用担当者がコンテナの保護方法を理解し、攻撃を検出できるように、組織内でソフトウェア開発スキルを徹底教育する
開発段階でのコンテナセキュリティの強化
コンテナへの移行が進んだことで、そのセキュリティに対する開発者の責任が大きくなっています。そのため、開発者はある程度時間を割いて、信頼できるコンテナイメージを開発するには具体的に何が必要か、コードのセキュリティを適切に検証するにはどうすべきか、そして、継続的なセキュリティ評価戦術を導入し、不要なコンポーネントを排除してコンテナ全体の攻撃対象を最小限に抑えるには何をすべきかを理解する必要があります。コンテナセキュリティを継続的に維持するには、コンテナ環境全体をエンドツーエンドで可視化することも重要です。そうすることで、開発者はマルウェアやその他のセキュリティ脅威をすばやく検出、阻止し、深刻な被害を防ぐことができます。また、管理者がセキュリティに関する基本的なベストプラクティスやベンチマークに慎重な配慮を怠らないようにすることで、コンテナでも他のタイプのコードと同じレベルのセキュリティを実現できます。
コンテナテクノロジーの導入が進む今日、コンテナのセキュリティに目を向けて対策を立てることの重要性がますます高まっています。コンピューティング環境が進化すれば、新たな脅威と脆弱性が生まれます。そのため今後は、セキュリティチームのベストプラクティスやセキュリティ態勢にコンテナセキュリティを含めることが不可欠です。コンテナ環境を保護することは、組織全体とそのインフラ、そして顧客を守るための第一歩なのです。
DevOps 5つのプラクティス
DevOpsチームの明暗を分ける5つのプラクティスについてご紹介します。