コンテナは今日のマイクロサービスを開発およびデプロイするための主要な手段であるため、それらを安全に保つことは非常に重要です。 しかし、どこから始めればよいのでしょうか。 堅実なコンテナセキュリティワークフローは、多くの場合、イメージの評価から始まります。 これらのイメージには、さまざまな脆弱性が含まれている可能性があります。 Sysdigの最新のレポートによると、画像の75%に、非常に深刻または非常に深刻と見なされる脆弱性があります。
しかし、良いニュースがあります—これらの脆弱性にパッチを適用することができます! また、調整と透明性が向上することで、ユーザーに影響を与える前に開発中のこれらの問題を把握できます。 これにより、強力なセキュリティを必要とする日常のユーザーと企業の顧客が保護されます。
SnykのFani BaharとHadar Mutaiは、 DockerConセッション中にこのコンテナセキュリティの議論に飛び込みました。 シフトレフトのアプローチを取り、主要なセキュリティ目標に向けてチームを結集することで、より強力なイメージセキュリティがはるかに達成可能になります。
Fani と Hadar の講演に飛び込んで、開発者と組織にとって重要なポイントを消化してみましょう。 態度、構造、ツールがコンテナのセキュリティにどのように大きな影響を与えるかを学びます。
セキュリティには、組織全体で適切な考え方が必要です
マインドセットは、より強力なコンテナセキュリティを実装する際に克服するのが最も難しいハードルの1つです。 チームはセキュリティを重要視していますが、実際には多くの場合、セキュリティが煩わしいと感じています。 これは、セキュリティが伝統的に正しい結果を得るために途方もない努力をしてきたためです。 Hadar氏によると、今日でも、コンテナのセキュリティは「ほとんどの開発者が避けがちなトピック」になっています。
また、チームは締め切りや発売日に間に合うようにスクランブルをかけますが、より高いレベルの脆弱性が発見されると遅延が発生する可能性があります。 セキュリティはすぐに友人ではなく敵になります。 では、スクリプトを反転するにはどうすればよいでしょうか。 理想的には、健全なコンテナセキュリティワークフローは次のことを行う必要があります。
- マイクロサービス開発で理解するようになったアジャイル開発の原則をサポートする
- 本番環境におけるアプリケーションセキュリティの向上を促進
- 相反する優先順位を作成するのではなく、共通のセキュリティ目標を中心にチームを統合
アプリケーションのセキュリティの向上には、開発者と DevSecOps という 2 つの主要なペルソナが投資されています。 これらの個別のペルソナには、非常によく似た目標があります。 開発者は、適切に実行される安全なアプリケーションを出荷したいと考えています。 一方、DevSecOps チームは、デプロイされたすべてのものをセキュリティで保護したいと考えています。
これらの目標を統一する秘訣は、すべての人に利益をもたらす効果的なコンテナセキュリティワークフローを作成することです。 さらに、このワークフローは、現在および将来のコンテナセキュリティに影響を与える最大の課題を克服する必要があります。 Hadarが強調した課題を分析してみましょう。
組織は一般的なコンテナセキュリティの課題に直面しています
セキュリティの背後にある謎を解き明かすのは困難なように思えますが、一般的な課題を理解することは戦略を立てるのに役立ちます。 組織は次のことに取り組んでいます。
- 脆弱性の過負荷 (コンテナー イメージによって 900 を超える可能性がある)
- セキュリティ修正を他の修正よりも優先する
- コンテナセキュリティが基本的にどのように機能するかを理解する(これは、チームが問題を修正できるかどうかに影響します)
- セキュリティの問題(およびテスト)に起因するより長い開発パイプライン
- 開発者がサポートする便利なセキュリティツールを既存のワークフローやシステムに統合
このことから、チームが協力してセキュリティを調整する必要があることがわかります。 これには、セキュリティの結果を特定し、役割と責任を定義しながら、中断を最小限に抑えることが含まれます。 コンテナのセキュリティは可能な限りシームレスである必要があります。
DevSecOps の成熟度と組織構造が重要
DevSecOpsは開発、セキュリティ、および運用の略ですが、それはどういう意味ですか? DevSecOpsシステムの下でのセキュリティは、ソフトウェア開発ライフサイクルのかなり早い段階で、責任の共有と優先事項になります。 一部の企業はこの概念を持っていますが、他の多くの企業はそれに不慣れです。 他の人は真ん中のどこかにあります。
Faniが述べたように、企業の開発プロセスとセキュリティの成熟度によって、それらがどのように分類されるかが決まります。 両極端があります。 一方では、企業はDevSecOpsを完全に「実現」している可能性があり、プロセスの拡張とセキュリティの強化に成功しています。 逆に、企業は 探索段階にある可能性があります。 彼らはDevSecOpsについて聞いたことがあり、それが欲しい(または必要である)ことを知っています。 しかし、彼らの開発プロセスは十分に定着しておらず、セキュリティ体制はそれほど強力ではありません。
探索段階にあるユーザーは、次の質問をしていることに気付くかもしれません。
- セキュリティを改善できますか?
- どの組織から学ぶことができますか?
- どのベストプラクティスに従うべきですか?
一方、他の企業はDevOpsが成熟している(ただしセキュリティは未成熟である)か、DevSecOpsに対応しています。 会社の所在地を知ることは、プロセスまたはセキュリティを拡張するための正しい次のステップを踏むのに役立ちます。
自律性と集中化がセキュリティに与える影響
通常、チームを編成するために使用される 2 つの方法論が表示されます。 1つは 自律性に焦点を当て、もう1つは 集中化を優先します。
自律的なアプローチ
自律型組織には、多かれ少なかれサイロ化された複数のチームが収容される場合があります。 それぞれが独自のアプリケーションで動作し、そのアプリケーションのセキュリティを監視します。 これには、ビルド、テスト、および検証が含まれます。 セキュリティの所有権は、これらの開発者とチーム内に統合された他のすべてのユーザーにあります。
しかし、それはDevSecOpsが完全にバックグラウンドにフェードインするということではありません! 代わりに、サポートとイネーブルメントの役割を果たします。 このDevSecOpsチームは、ケースバイケースで開発者と直接連携することも、便利な内部ツールを構築して生活を楽にすることもできます。
一元化されたアプローチ
そうしないと、個々の開発者が一元化されたDevOpsおよびAppSec(アプリケーションセキュリティ)チームの周りに集まる可能性があります。 このグループは、さまざまな開発チーム間で標準のテストと設定を担当します。 たとえば、DevAppSec は承認された基本イメージを定義し、厳格なセキュリティ プロトコルを満たすコンテナー設計のフレームワークをレイアウトします。 この計画は、組織全体の各アプリケーション チームと調和する必要があります。
なぜ承認された親画像を使用するのですか? これらのイメージは、目を見張るような脆弱性が存在しないことを確認するために厳格なテストを受けています。 また、さまざまなプロジェクトを対象とした基本的な機能セットも含まれています。 DevSecOpsは、継続的なエンジニアリング作業をサポートするために、機能とセキュリティの間の理想的な妥協点を見つける必要があります。
どちらの陣営に分類されても、基本的にあなたの計画がどれほど「断片的」であるかが決まります。 開発者が最適に作業する方法は、セキュリティ計画にも影響します。 たとえば、チームは独自の専用ツールセットを使用するのが最も幸せかもしれません。 この場合、集中化に移行すると、摩擦が発生したり、移行期間が開始されたりする可能性があります。
反対に、自律チームは、一元化されたポリシーに依存した後、強力なセキュリティを採用するための知識を持っていますか?
多くの企業が既存の構造を維持することは言及する価値があります。 ただし、上記のような構造上の変更は、短期的および長期的にコンテナのセキュリティに影響を与える可能性があります。
多様なツールがコンテナセキュリティワークフローを定義
次に、Faniは、コンテナセキュリティツール市場がいかに堅調であるかを示しました。 開発パイプラインの各ステップ、つまりワークフローには、ジョブ用の複数のツールがあります。 IDEから選択できます。 リポジトリとバージョン管理があります。 また、統合ツール、ストレージ、オーケストレーションもあります。
これらは、開発の次の側面の目的を果たします。
- 地域開発
- ギトオプス
- CI/CD
- 記帳
- 生産コンテナ管理
ありがたいことに、特定の仕事に最適なツールや「最悪の」ツールはありません。 ただし、組織は、中断を最小限に抑えて優れたコンテナセキュリティを提供するツールを選択する必要があります。 Docker Desktopのようなプラットフォームが、イメージ管理や ソフトウェア部品表(SBOM)機能などのツールを通じて、セキュリティワークフローに直接的または間接的にどのように貢献できるかを検討する必要があります。
ツールに対応するためにプロセスを再設計する必要はありません。 たとえば、Visual Studio Code の方が IntelliJ IDEA よりもチームに適している可能性があります。 Jenkins 対 CircleCI、または GitHub 対 Bitbucket についても同じことが言えます。 選択したツールは、既存のセキュリティプロセスに適合し、さらにそれらを強化する必要があります。 それだけでなく、これらのツールは、生産性のハードルを回避するためにうまく噛み合う必要があります。
コンテナセキュリティワークフローの例
セキュリティの背後にある理論は重要ですが、具体的な例も重要です。 Fani は、自律的なチームワークフローに飛び乗ることから、これらの例を開始しました。 ますます多くの組織が、個々のチームに力を与えるため、自律性を採用しています。
自律ワークフローの調査
最新のワークフローと同様に、開発とセキュリティはさまざまな程度の自動化に頼ります。 これは、Gitリポジトリへのコードプッシュで始まるFaniの例の場合です。 このアクションにより、一連のシーケンシャルなユーザー定義タスクである Jenkins ジョブが開始されます。 次に、Snykプラグインのようなものがビルド破壊の問題をスキャンします。
Snyk で問題が検出されない場合、Jenkins ジョブは成功したと見なされます。 Snykはそれ以降継続的に監視し、新しい問題についてチームに警告します。
問題が見つかると、コンテナー セキュリティ ツールは、それらのビルドの問題にフラグを付け、開発者に通知し、成果物へのアクセスを提供し、適切な修復手順を提供する場合があります。 そこから、サイクルが繰り返されます。 または、脆弱なコンポーネントまたは依存関係を代替に置き換える方が安全な場合があります。
共通基本ワークフローの調査
DevSecOps をセキュリティの舵取りに据えると、プロセスは少し違って見えることがあります。 Hadarは、DevOpsの重要な役割を強調するために、これらのユニークなコンテナセキュリティ段階について説明してくれました。 これは開発者のワークフローに隣接していますが、開発者のワークフローとは多少異なります。 ただし、共通のレジストリによって一元的にリンクされています。
DevOpsは、適切な基本イメージを選択し、カスタマイズし、最適化し、強力なセキュリティを確保するためにそのペースを試すことから始まります。 承認されたイメージは、共通の開発レジストリに移動します。 逆に、DevOpsは、そのイメージを内部で利用できるようにする前に、脆弱性を修正します。
次に、各開発者は、重要なカスタムソフトウェアパッケージを犠牲にすることなくスキャンに合格する、安全で精査されたイメージから始めます。 問題は修正して振り出しに戻す必要がありますが、成功とはコンテナアーティファクトをダウンストリームレジストリにプッシュすることを意味します。
将来を見据えたより安全な容器づくり
全体として、コンテナのセキュリティは多くの人が考えるほど複雑ではありません。 セキュリティを調整し、ツールと一緒にコアプロセスを開発することで、迅速な進歩を遂げることができます。 自動化は大きな役割を果たします。 また、コンテナセキュリティワークフローに取り組む方法はたくさんありますが、1つのアプローチで確実に機能するものはありません。
より安全なパブリックベースイメージとカスタムイメージは、安全なアプリケーションを構築する際の重要な要素です。 詳細については、ファニとハダルの完全な話 を見ることができます。また、 Docker Hub の Docker Desktop 用の Snyk Extension の詳細も読むことができます。