[コンテナセキュリティ]

[コンテナのセキュリティを強化するために実行できる 5 つのステップ]

[1。オペレーティング・システムから余分な部分を取り除く]

[コンテナーを実行するオペレーティングシステムから、必要な機能や不要なアセットをすべて削除する必要があります。これは警戒すべきアプローチのように思えるかもしれませんが、実際のところ、サイバー犯罪者はオペレーティングシステムによって実行されるさまざまなサービスのそれぞれを攻撃対象として利用しています。プライベートクラウドまたはパブリッククラウド経由でシステムをホストしている場合でも、余分なもの (以外) をすべて削除します。 クラウドセキュリティ féát~úrés~) は重大なセキュリティ問題を防ぐことができます。]

[そのため、次のことを試してください。]

1. [コンテナをサポートする必要のあるシステムを特定してください]
2. [それ以外はすべて破棄してください]
3. [最初の削除後にコンテナをテストしてください]
4. [最初に見落としていた不要な機能を探し、それらは破棄してください。]
5. [コンテナを再度テストしてください]

[コンテナの ÓS から余分な機能を削除する必要がある理由]

[このアプローチを正当化する理由は比較的単純です。各ワークロードには独自の要件があります。たとえば、コンテナ・ワークロードには、更新サイクル、スタック・アーキテクチャ、アクセス制御パラメータ、セキュリティ・ツール、およびÓSが管理しなければならないDé~vÓps~プロセスのその他の重要な機能があります。これは、仮想マシンを使用するか従来の環境を使用するかにかかわらず当てはまります。]

[これらの各機能には、そのニーズを満たすのに適したセキュリティプロトコルがあります。同時に、ホスト ÓS 上で動作する別のアプリには独自のインフラストラクチャー要件があります。これらの無関係なアプリが ÓS~ のリソースを DévÓ~ps チームから奪うだけでなく、その都度、意図せず攻撃対象領域を増やしてしまいます。これは、コンテナのセキュリティ対策には、他のプログラムを保護するために設計されたものとは異なるリソースが必ず必要になるためです。お使いの ÓS~ は補助アプリケーションコードを保護できるかもしれませんが、コンテナは公開されたままになる可能性があります。]

[2。コンテナに付属していたソフトウェアを信用しない]

[覚えておくべき重要なことは、プロバイダーの主張以外は、コンテナーのセキュリティ対策がどれほど強力であるかはわからないということです。どのように機能するかは関係ありません。重要な質問には次のようなものがあります。]

• [プロバイダーは必要な脆弱性スキャンを実行しましたか¿]
• [彼らはどのような侵入防止システムを導入しましたか？]
• [コンテナ化されたアプリケーションと組み合わせた場合、環境によって予期しないリスクにさらされることはありませんか¿]

[コンテナにバンドルされているセキュリティツールの詳細がわからないため、潜在的な脆弱性を確認したり予測したりすることはできません。したがって、コンテナパッケージに付属する保護機能を信頼する前に、以下のセキュリティベストプラクティスを実装してみてください。]

• [コンテナの中身を再確認してください]
• [古いソフトウェアがインストールされているコンテナを実行しないでください]
• [ソフトウェアに慣れていない場合は、展開する前にその仕組みを理解しておいてください]
• [各プログラムとライブラリをチェックして、それらが実際に最新かつ最高の保護を提供しているかどうかを確認してください。]

[3。コンテナのランタイムを検査する]

[ランタイムはコンテナの起動と管理を行うため、セキュリティパッチを注意深く追跡する必要があります。ランタイムには明らかな脆弱性があることが知られています。これは必ずしも一般的なことではありませんが、潜在的な影響は重大です。]

[たとえば、場合によっては、ランタイム構成により、コンテナがホストのデバイスとそのディレクトリへのフルアクセスが可能になることがあります。その場合、コンテナがマルウェアに感染すると、ホストへの攻撃に使用される可能性があります。さらに、適切に実装していなければ ネットワークセグメンテーション、ネットワーク通信の影響を受ける他のコンテナやエリアも感染する可能性があります。]

[脆弱性は、古いランタイムプログラムでより顕著になる場合があります。このプログラムは最初にコーディングされたときには問題なかったかもしれませんが、サイバー犯罪者は当初から新しい攻撃方法を設計してきました。そのため、従来のランタイムプログラムで脆弱性が悪用される可能性は月ごとに高まっています。また、オープンソース環境では、信頼できるソースと疑わしいソースを区別するのが難しい場合があるため、注意が必要であることがさらに明確になります。]

[4。完全な可視性を確保]

[コンテナの採用により、ベアメタル仮想マシンのワークロードで実行されるシステムの数は指数関数的に増加する可能性があります。コンテナはカプセル化されているため、コンテナをホストしているワークロードを可視化しても、コンテナ自体を十分に可視化できるとは考えられません。各コンテナを独自のエンティティと見なし、それに応じて可視化対策を講じることが重要です。完全な可視性を確保するには、次のことを行う必要があります。]

• [各コンテナの場所の詳細]
• [各コンテナが何をしているのかを概説する]
• [コンテナに出入りするデータの流れをマッピングする]
• [アプリケーション、ファイル、オペレーティングシステムのリソースなど、各コンテナが消費できるリソースの概要を説明する]

[この最後の対策は非常に重要です。なぜなら、コンテナ自体は安全かもしれませんが、他の場所からリソースを引き出すからです。そのため、意図せず他の場所で脆弱性を引き起こす可能性があります。さらに、業界によっては、各コンテナのデータに適用される必要なコンプライアンス基準を確立する必要がある場合があります。]

[5。ネットワークセグメンテーションを使用する]

[ネットワークを慎重にセグメント化すると、セグメントごとにカスタム設計されたセキュリティソリューションと、それぞれの保護対象領域を最小限に抑えることによる制御の強化というメリットが得られます。]

[ネットワークセグメンテーションがコンテナを保護する方法]

[セグメント化されていないネットワークは、壁のないアパートのようなものです。仮に害虫が侵入した場合、害虫は自由に支配し、すべての生活空間に蔓延します。セグメンテーションのないネットワークにも、同じようなコア脆弱性があります。コンテナは、その名前とは裏腹に、本質的に「封じ込め」ておらず、マルウェア、ウイルス、その他のサイバー害虫から保護されているわけでもありません。]

[使用する場合 ネットワークセグメンテーション コンテナが独自のセグメントを持つようにネットワークを構築するには、あるセグメントへの脅威が他のセグメントに影響を与えません。つまり、害虫に強い壁を作っているのです。サイバー脅威が内部に侵入できたとしても、その一区分の内部にとどまってしまいます。これにより、サイバー攻撃がネットワークの一部に侵入したとしても、横方向、つまり東西の汚染が防止され、チームが自由に生産性を維持できるようになります。]

[ネットワークセグメンテーションを利用し、コンテナのセキュリティをトリプルチェックし、ランタイムプログラムを検査し、ÓSから余分なアプリを削除し、完全な可視性を確保することで、Dé~vÓps~チームにとってより安全で生産的な環境を構築できます。]

[さらに詳しく]

[その方法をご覧ください ゼロトラストセグメンテーション Kúbé~rñét~és や Ré~dHát~ Ópéñ~Shíf~t プラットフォームを含むコンテナデプロイメントを保護します。]