コンテナの使用は増加し続けています。 サーバーレス、クラウドネイティブ アプリ、またはモノリスの最新化の要望など、コンテナーはアプリを展開するための推奨プラットフォームとして急速に普及しつつあります。
Sysdig は最近、パブリック クラウドおよびオンプレミス サービスの顧客から収集したデータに基づいて、2019 年のコンテナ使用状況レポートを発表しました。 データは 200 万個を超えるコンテナをカバーしています。
これらのコンテナの 60% が NGINX を実行しているという非常に興味深い発見 (私にとっては) とは別に、Sysdig はかなり厄介なセキュリティ統計を明らかにしました。
次の例を考えてみましょう: コンテナの 54% は 5 分未満しか存続しませんでした。 2018 年には、その割合はわずか 20% でした。
なぜこれが問題なのでしょうか? もちろんセキュリティです。 アクセスを保護し (保護する必要があります)、そのコンテナで実行されているアプリまたは API を保護しようとする場合は、セキュリティ サービスがクラスターの現在の状態に合わせてポリシーを常に調整していることを確認する必要があります。 つまり、コンテナが起動されたときにポリシーを適用し、コンテナが廃止されたときにポリシーを削除する必要があります。 多くの変化が起こっており、それは運用上のオーバーヘッドが大きくなることを意味します。 比較的静的なアプリケーションでセキュリティを適切に確保するのは十分に困難です。 非常に不安定なものを高速で実行するのは本当に困難です。
それが気にならないのであれば、次の統計を試してみてください。コンテナ イメージの 60% がプライベート レジストリから取得されているにもかかわらず (素晴らしいことです!)、そのうち 52% がイメージ スキャンに失敗しています。 つまり、重大度が「高」以上の既知の脆弱性があったということです。
うーん。 無理です。
多くの人がコンテナをルートとして実行していることがわかりました(ホストあたりの中央値: 21)または特権モード(ホストあたりの中央値: 4)。 その他には制限された権限はありません (ホストあたりの平均 28)。 Docker (最も一般的なコンテナ ランタイム) はデフォルトで制限された機能セットで起動するため、これは特にイライラさせられます。 つまり、誰かが意図的にデフォルトのセキュリティ設定を変更したことになります。 制限なしで実行すると、権限を昇格したり、コンテナをブレイクアウトしたり(システムへのアクセスを許可したり)できるようになります。
ここで、コンテナ セキュリティの基本についてもう一度確認してみましょう。
適切なコンテナ セキュリティ プラクティスを実際に実践することは、アプリのセキュリティ、ひいてはビジネスのセキュリティにとって極めて重要です。 近日公開予定の「2020 年アプリケーション サービスの現状」レポートによると、クラウド ネイティブ/マイクロサービスはエンタープライズ アプリ ポートフォリオの平均 15% を占めています。 この割合は、新規申請のバックログが長期化していることを示す調査結果にもかかわらず出ている。 つまり、コンテナ化されたアプリは今後も増え続けるということです。 そして、ごく一部のアプリを保護できないのであれば、どうやって大規模に拡張してかなりの割合のアプリを保護できると期待できるでしょうか?
安全なコンテナ化を実践しましょう。
コンテナ セキュリティの基礎を復習したい場合は、F5 の同僚 Jordan Zebor の専門知識に基づいたこのシリーズをご覧ください。