あなたのチームで運用しているコンテナは安全性を確保されていますか？
Takao Shimizu
Sysdig - Japan Regional Management Technical Officer | Falco.org Website contributor
本文の内容は、2020年12月3日にSysdig CEO Suresh Vasudevanが投稿したブログ(https://sysdig.com/blog/your-team-is-running-containers-but-are-they-secure/)を元に日本語に翻訳・再構成した内容となっております。
組織は、IT インフラストラクチャーの近代化、チームの再編、コンテナと Kubernetes を使ったアプリケーション配信の加速化を行っています。どのようなテクノロジーでもそうですが、組織はその道のりの中で様々な場所にいます。しかし、ガートナーによると、2022年までに世界の組織の75%以上がコンテナ化されたアプリケーションを本番で実行しているとのことです。
あなたのチームがいくつかのアプリケーションでコンテナを使用している可能性があります。ソフトウェアをベースに構築された企業で、DevOpsアプローチとコンテナを使用して低リスクのアプリケーションをクラウドにデプロイしていない企業を見つけるのは難しいでしょう。他の企業はさらに進んで、ビジネスクリティカルなアプリケーションをクラウドに移行しています。
どのフェーズにいても、コンテナの運用の仕方は異なります。コンテナは不変であるため、レガシーなパッチ適用アプローチは無効となります。また、一時的なものであるため、インシデント対応やフォレンジックは悪夢のようなものです。可視性は、脅威検出のための別のアプローチを必要とする課題です。マイクロサービスでは、管理するサービスの量が多くなります。
チームが効果的なセキュリティとコンプライアンスの管理を行っていることをどのようにして把握されていますか？彼らの戦略を理解するために積極的に関与しているのか、それとも今までのレガシーなコントロールで十分だと思い込んでいませんか？
2019年のDORAとGoogle Cloudの調査（ダウンロードが必要）によると、ほとんどのチームは、パフォーマンスの高いエリートDevOpsチームであっても、自動セキュリティテストの統合を遅らせています。セキュリティテストをDevOpsのツールチェーンに統合したチームは3分の1以下でした。
コンテナやKubernetesのセキュリティ、コンプライアンス、監視製品を提供する企業のCEOとして、セキュリティ対策を先延ばしにすることは、不快なサプライズにつながる可能性があるため、これは大きな間違いだと思います。
ベンジャミン・フランクリンは「準備を怠ることは、失敗する準備をしていることになる」と述べています。
セキュリティに取り組む必要があります。
セキュリティに取り組む理由は数え切れないほどあります。セキュリティ違反や機密データの漏洩を避けることが主なものです。
ブランドへの影響、顧客の信頼の喪失、被害を修復するための内部コストは、一般的にプライバシー規制に違反したことによる罰金の影響よりもはるかに大きい。IBM（要ダウンロード）によると、米国の平均的なデータ侵害には800万ドル以上の費用がかかるといいます。
セキュリティ採用者には、3つのカテゴリーに分類される傾向があります。
- アーリーアダプター：これらはセキュリティチームが主導し、Kubernetesやコンテナ導入のためのポリシーガイドラインを定義しています。
- 顧客主導型：B2B企業の中には、顧客がセキュリティ対策を評価し、収益を保留した後に、セキュリティとコンプライアンスを優先する企業もあります。
- コンプライアンス重視：その他のB2B企業では、コンプライアンス監査に合格することが緊急性の原動力となっています。
コンテナ化されたアプリは本質的に安全であるという誤った感覚があります。
Kubernetesは、開発者のために、摩擦のないコードデプロイの哲学を持って作られました。開発者の生活を楽にすることは、プラットフォームやDevOpsチームの複雑さにつながります。例えば、Kubernetesは「デフォルトではオープン」であり、セキュリティガードレールを明示的に定義する必要があります。
すべての環境には、攻撃者のための穴が残されています。Kubernetesでは新たな脆弱性が継続的に確認されており、異常なイベントに対してフラグを立てて警告する必要性が強調されています。
私の会社の調査では、イメージの58%がrootで実行されていることがわかりました。イメージが侵害されると、攻撃者が環境への広範なアクセスを可能にしてしまう可能性があります。
開発者は、ゼロからコードを書くのではなく、コードを組み立てることが多いですが、他のソースからのイメージに脆弱性があるかどうかを知るのは難しいです。チームではOSのイメージをスキャンすることができるので、最も影響が大きいかもしれません。しかし、私の会社の調査では、OS以外のイメージの半数以上に「高」から「重要」な脆弱性が含まれていることがわかりました。セキュリティチームは、コンテナに関連する脆弱性やリスクの高い設定を管理するための具体的なポリシーを設定していることを確認しましょう。
もう一つの課題は、寿命の短さです。私の会社の調査によると、半数以上のコンテナの寿命は5分未満だそうです。コンテナがデータと一緒になくなったらどうなるのでしょうか？既存のツールでは、効果的な調査に必要なコンテナの活動の軌跡を捉えることができないかもしれません。コンテナ環境では、より頻繁にデータをキャプチャする必要があります。
コンテナのセキュリティには新しいアプローチが必要です。
クラウドチームはセキュリティ対策が重要であることを知っています。一般的な理由の1つは、セキュリティとコンプライアンスの導入が遅れるのではないかという懸念です。プラットフォームチームは、開発チームの要求に応えるために、Kubernetesとコンテナインフラストラクチャーを立ち上げなければならないというプレッシャーを感じています。開発チームはリリーススケジュールを守らなければならないというプレッシャーを感じています。彼らは最終的にはセキュリティ問題に対処することを知っているが、できるだけ遅らせることを好むかもしれません。
セキュリティとコンプライアンスの導入が難しい理由を理解する。
セキュリティチームは、このような環境でのセキュリティとコンプライアンスのベストプラクティスとツールの理解において、クラウドチームに遅れをとっていることが多いです。クラウドチームは、組織の惰性と戦ったり、他のチームを教育するために時間を割いたりしたくないのかもしれません。
従来のセキュリティ・プロセスはマニュアル化されており、自動化されたDevOpsプロセスに統合されていません。また、効果的なセキュリティに必要なコンテナの可視性のレベルもありません。しかし、チームはコンテナを「使ってみる」ことを求められるかもしれません。
クラウドチームは、コンテナとKubernetesの世界でセキュリティについてスピードアップするための時間が必要かもしれません。多くの企業は、この急速に進化する空間でまだ学んでいます。
一部の企業にとっては、最新のソフトウェア開発アプローチへの移行はミッションクリティカルではない。彼らは、機密データを含むワークロードを移行するまでコンテナセキュリティを遅らせることができると考えています。しかし、これは間違った考え方です。ビジネスに不可欠なアプリケーションをコンテナに移行することを期待している組織は、本番環境に移行する前に、セキュリティとコンプライアンスのポリシー、ツール、プロセスを検討する必要があります。
セキュリティとコンプライアンス対策で開発を遅らせる必要はありません。
経営陣からの明確な指示があれば、縄張り争いを減らし、抵抗を最小限に抑えることができます。セキュリティとコンプライアンスを DevOps ワークフローの一部として組み込み、自動化することで合意が得られれば、導入は簡単です。
イメージスキャンをレジストリや CI/CD ツールチェーンに統合することで、スキャンが自動的に実行されるようにすることができます。また、手動のステップを追加することなく、セキュリティポリシーを強制し、潜在的な脅威に対するアラートを取得することができます。ルールに基づいて、インシデント対応やフォレンジック調査のためにキャプチャファイルをトリガーすることができます。アラートやイベントデータを、一般的に使用されているツールに直接フィードすることができます。
これらの戦略により、チームは既存のワークフローを中断することなく、セキュリティとコンプライアンスを効率的に管理することができます。これらを正しく実装すれば、セキュリティとコンプライアンスの管理により、デリバリーを遅らせることなくコンテナ環境のリスクを管理することができます。
ほとんどのビジネスはソフトウェアで運営されており、機能提供のスピードは競争力の鍵となります。クラウド、コンテナ、DevOpsは急速に主流になりつつあります。あなたのチームは、この新しいアプローチを使用したアプリケーションの開発、デプロイ、セキュリティ保護に熟練していなければ、取り残されてしまう可能性があります。