Linuxコンテナのセキュリティを強化する10の側面

コンテナセキュリティソリューションでは、さまざまなテクノロジースタックとコンテナライフサイクルのさまざまな段階を考慮する必要があります。 - 1. コンテナ オペレーティング システムとマルチテナント - 2. コンテナ コンテンツ (信頼できるソースを使用) - 3. コンテナの登録 (コンテナ イメージへの暗号化されたアクセス) - 4. 構築プロセスのセキュリティ - 5. クラスタにデプロイできる内容の制御 - 6. コンテナ オーケストレーション: コンテナ プラットフォームのセキュリティの強化 - 7. ネットワークの分離 - 8. ストレージ - 9. API 管理、エンドポイント セキュリティ、シングル サインオン (SSO) - 10. ロールとアクセス制御の管理

コンテナは、アプリケーションをパッケージ化し、開発環境やテスト環境から運用環境までシームレスにデプロイするための簡単な方法を提供します。物理サーバー、仮想マシン (VM)、プライベート クラウドやパブリック クラウドなど、さまざまな環境全体で一貫性を確保するのに役立ちます。主要な組織は、ビジネス価値を高めるアプリケーションの開発と管理を容易にするために、これらの利点に基づいてコンテナを急速に導入しています。

エンタープライズ アプリケーションには強力なセキュリティが必要です。コンテナで基本的なサービスを実行している人は誰でも、「コンテナは安全ですか?」、「アプリケーションはコンテナを信頼できますか?」と疑問に思うでしょう。

コンテナの保護は、実行中のプロセスの保護と非常によく似ています。コンテナーをデプロイして実行する前に、ソリューション テクノロジー スタック全体のセキュリティを考慮する必要があります。また、アプリケーションとコンテナーのライフサイクル全体を通じてセキュリティを考慮する必要もあります。

これら 10 の側面において、さまざまなレベル、さまざまなテクノロジースタック、さまざまなライフサイクルステージでコンテナのセキュリティを強化するようにしてください。

1. コンテナオペレーティングシステムとマルチテナンシー

開発者にとって、コンテナーを使用すると、アプリケーションの構築とアップグレードが容易になり、アプリケーションの単位として信頼できるため、マルチテナント対応のアプリケーションを共有ホストにデプロイすることでサーバー リソースの使用率が最大化されます。コンテナーを使用すると、単一ホスト上に複数のアプリケーションをデプロイし、必要に応じて個々のコンテナーをオンまたはオフにすることが簡単になります。このパッケージ化および展開テクノロジを最大限に活用するには、運用チームが適切に実行されているコンテナ環境を必要とします。オペレーターには、境界でコンテナを保護し、ホスト カーネルをコンテナから分離し、コンテナを相互に安全に保つことができるオペレーティング システムが必要です。

コンテナは、リソースを分離して制限する Linux プロセスであり、共有ホスト カーネル内でサンドボックス アプリケーションを実行できるようにします。 Linux で実行中のプロセスを保護するのと同じ方法でコンテナを保護する必要があります。特権を放棄することは重要であり、引き続きベスト プラクティスです。より良いアプローチは、できるだけ少ない権限でコンテナを作成することです。コンテナは root ではなく通常のユーザーとして実行する必要があります。次に、Linux で利用可能な複数レベルのセキュリティ機能 (Linux 名前空間、Security Enhanced Linux (SELinux)、cgroup、機能、および Secure Compute Mode (seccomp)) を利用してコンテナーを保護します。

2. コンテナのコンテンツ (信頼できるソースを使用)

セキュリティに関して、コンテナの中身は何を意味しますか? 。しばらくの間、アプリケーションとインフラストラクチャは既製のコンポーネントで構成されてきました。その多くは、Linux オペレーティング システム、Apache Web サーバー、Red Hat JBoss Enterprise Application Platform、PostgreSQL、Node.js などのオープンソース ソフトウェアから提供されています。さまざまなコンテナベースのパッケージのバージョンがすぐに入手できるようになったので、独自のパッケージを構築する必要はありません。ただし、外部ソースからダウンロードしたコードと同様に、パッケージの出所、作成者、パッケージ内に悪意のあるコードが含まれているかどうかを知る必要があります。

3. コンテナの登録 (コンテナイメージの暗号化アクセス)

チームは、ダウンロードしたパブリック コンテナ イメージに基づいてコンテナを構築するため、アクセス管理と更新ダウンロードが管理の鍵となります。コンテナ イメージ、組み込みイメージ、その他の種類のバイナリも同じ方法で管理する必要があります。多くのプライベート リポジトリ レジストリは、コンテナ イメージの保存をサポートしています。使用されるコンテナー イメージ自動化ポリシーを保存するプライベート登録サーバーを選択します。

4. 建設プロセスは安全です

コンテナ化された環境では、ソフトウェア構築はライフサイクル全体の 1 段階であり、アプリケーション コードはランタイムと統合される必要があります。このビルド プロセスを管理することは、ソフトウェア スタックのセキュリティを確保するための鍵となります。 「一度ビルドすれば、どこにでもデプロイできる」という概念を遵守し、ビルド プロセスの製品が本番環境にデプロイされた製品とまったく同じであることを保証します。これは、コンテナーの継続的な安定性を維持するためにも非常に重要です。つまり、実行中のコンテナーにパッチを適用するのではなく、コンテナーを再構築して再デプロイします。 高度に規制された業界で働いている場合でも、単にチームの作業を最適化したい場合でも、コンテナ イメージ管理を設計し、コンテナ レイヤーを活用して制御の分離を実現するプロセスを構築する必要があります。これにより、次のことが可能になります。

運用保守チームが基本イメージを管理

アーキテクチャチームはミドルウェア、ランタイム、データベース、その他のソリューションを管理します

開発チームはアプリケーション層とコードのみに焦点を当てます

最後に、カスタム コンテナに署名して、ビルドとデプロイメントの間にコンテナが改ざんされていないことを確認します。

5. クラスターにデプロイできるものを制御する

ビルド プロセス中に問題が発生した場合、またはイメージの展開後に脆弱性が発見された場合には、自動化されたポリシーベースの展開を使用して、別のセキュリティ層を追加する必要があります。

アプリケーションの構築に使用される 3 つのコンテナー イメージ レイヤー (コア、ミドルウェア、アプリケーション) を見てみましょう。コア イメージに問題が発見された場合、イメージは再構築されます。ビルドが完了すると、イメージがコンテナー プラットフォーム登録サーバーにプッシュされます。プラットフォームはイメージへの変更を検出できます。このイメージに依存し、トリガーが定義されているビルドの場合、プラットフォームはアプリケーションを自動的に再構築し、修正されたライブラリを統合します。

ビルドが完了すると、イメージがコンテナ プラットフォームの内部登録サーバーにプッシュされます。内部登録サーバー内のイメージへの変更はすぐに検出され、更新されたイメージはアプリケーションで定義されたトリガーを通じて自動的にデプロイされ、運用環境で実行されるコードが常に最新の更新されたイメージと同じであることが保証されます。これらすべての機能が連携して、セキュリティ機能を継続的インテグレーションおよび継続的デプロイ (CI/CD) プロセスに統合します。

6. コンテナオーケストレーション: コンテナプラットフォームのセキュリティの強化

もちろん、アプリケーションが単一のコンテナーで配信されることはほとんどありません。単純なアプリケーションであっても、通常はフロントエンド、バックエンド、データベースがあります。最新のマイクロサービス アプリケーションをコンテナーにデプロイすることは、図に示すように、複数のコンテナーを同じホスト上にデプロイすることもあれば、複数のホストまたはノードに分散することもあるということを意味します。

大規模なコンテナーのデプロイメントを管理する場合は、次の点を考慮する必要があります:

どのコンテナをどのホストにデプロイする必要がありますか?

どのホストの容量が大きいですか?

どのコンテナが相互にアクセスする必要がありますか?彼らはどうやってお互いを発見するのでしょうか？

ネットワークやストレージなどの共有リソースへのアクセスと管理を制御するにはどうすればよいですか?

コンテナの健全性ステータスを監視するにはどうすればよいですか?

需要に応じてアプリケーションの機能を自動的に拡張するにはどうすればよいですか?

開発者がセルフサービスでセキュリティのニーズを満たせるようにするにはどうすればよいですか?

開発者とオペレーターが持つ幅広い機能を考慮すると、強力なロールベースのアクセス制御がコンテナ プラットフォームの重要な要素となります。たとえば、オーケストレーション管理サーバーはアクセスの中心点であり、最高レベルのセキュリティ チェックを受ける必要があります。 API は、大規模な自動コンテナ管理の鍵であり、コンテナ、サービス、レプリケーション コントローラのデータを検証および構成するために使用され、受信リクエストに対してプロジェクトの検証を実行し、他の主要なシステム コンポーネントに対してトリガーを呼び出します。

7. ネットワークの分離

最新のマイクロサービス アプリケーションをコンテナーにデプロイすることは、多くの場合、複数のノードに分散された複数のコンテナーをデプロイすることを意味します。ネットワーク防御を念頭に置いて、クラスター内でアプリケーションを分離する方法が必要です。

Google Container Engine (GKE)、Azure Container Services、Amazon Web Services (AWS) Container Service などの一般的なパブリック クラウド サービスは、シングルテナント サービスです。これにより、起動した VM のクラスター上でコンテナーを実行できるようになります。マルチテナント コンテナのセキュリティを実現するには、単一のクラスタを選択してトラフィックをセグメント化し、そのクラスタ内のさまざまなユーザー、チーム、アプリケーション、環境を分離できるコンテナ プラットフォームが必要です。

ネットワーク名前空間を使用すると、コンテナーの各コレクション (「POD」と呼ばれます) が独自の IP およびポート バインド範囲を取得し、それによってノード上の POD ネットワークが分離されます。

デフォルトでは、以下で説明するオプションを使用しない限り、異なる名前空間 (プロジェクト) の POD は、異なるプロジェクトの POD またはサービスとパケットを送受信できません。これらの機能を使用して、開発環境、テスト環境、実稼働環境をクラスター内に分離できますが、IP アドレスとポートの拡張によりネットワークがより複雑になります。この複雑さを処理するツールに投資してください。推奨されるツールは、ソフトウェア定義ネットワーク (SDN) コンテナー プラットフォームを使用することです。これは、クラスター全体のコンテナー間の通信を確保するための統合クラスター ネットワークを提供します。

8. ストレージ

コンテナは、ステートフル アプリケーションとステートレス アプリケーションの両方に非常に役立ちます。 ストレージの保護は、ステートフル サービスを確保するための重要な要素です。コンテナ プラットフォームは、ネットワーク ファイル システム (NFS)、AWS Elastic Block Store (EBS、エラスティック ブロック ストレージ)、GCE 永続ディスク、GlusterFS、iSCSI、RADOS (CEPH)、Cinder など、さまざまなストレージ プラグインを提供する必要があります。

永続ボリューム (PV) は、リソースプロバイダーがサポートする任意のホストにマウントできます。プロバイダーにはさまざまな機能があり、各 PV のアクセス モードは、特定のボリュームでサポートされる特定のモードに設定できます。たとえば、NFS は複数の読み取り/書き込みクライアントをサポートできますが、特定の NFS PV はサーバー上で読み取り専用としてのみエクスポートできます。各 PV には、ReadWriteOnce、ReadOnlyMany、ReadWriteMany など、PV 固有のパフォーマンス メトリックを定義する独自のアクセス モードのセットがあります。

9. API 管理、エンドポイント セキュリティ、シングル サインオン (SSO)

アプリケーションの保護には、アプリケーションと API の認証と認可の管理が含まれます。 Web SSO 機能は、最新のアプリケーションの重要な部分です。開発者が独自のアプリケーションを構築する場合、コンテナ プラットフォームは開発者が使用できるさまざまなコンテナ サービスを提供できます。

API はマイクロサービス アプリケーションの重要なコンポーネントです。マイクロサービス アプリケーションには複数の独立した API サービスがあるため、サービス エンドポイントが急増し、より多くのガバナンス ツールが必要になります。 API 管理ツールを使用することをお勧めします。すべての API プラットフォームは、API 認証とセキュリティのためのさまざまな標準オプションを提供する必要があります。これらのオプションは、証明書の発行やアクセスの制御に単独または組み合わせて使用​​できます。これらのオプションには、標準 API キー、アプリ ID、キー ペア、OAuth 2.0 が含まれます。

10. ロールとアクセス制御の管理 (クラスターフェデレーション)

2016 年 7 月、Kubernetes 1.3 で Kubernetes Federated Cluster が導入されました。これは、現在 Kubernetes 1.6 ベータ版に含まれるエキサイティングな新機能です。

パブリック クラウドまたはエンタープライズ データ センターのシナリオでは、フェデレーションはクラスター間でアプリケーション サービスを展開してアクセスするのに役立ちます。マルチクラスターにより、複数のリージョン、複数のクラウド プロバイダー (AWS、Google Cloud、Azure など) などのアプリケーションの高可用性が可能になり、デプロイメントまたは移行の共通管理を実現できます。

クラスターフェデレーションを管理するときは、オーケストレーションツールがさまざまなデプロイメントプラットフォームインスタンス間で必要なセキュリティを提供していることを確認する必要があります。いつものように、認証と認可はセキュリティの鍵です。アプリケーションがどこで実行されているかに関係なく、アプリケーションに安全にデータを渡すことができ、クラスタ内のアプリケーションのマルチテナンシーを管理できます。

Kubernetes はクラスター フェデレーションを拡張し、フェデレーション暗号化、フェデレーテッド ネームスペース、オブジェクト エントリのサポートを含めます。

以上がLinuxコンテナのセキュリティを強化する10の側面の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。