コンテナセキュリティ

コンテナセキュリティの概要

現代のアプリ開発の核はマイクロサービスにあります。この手法は、十分に完結し独立したマイクロサービスを用いて複雑なアプリを作ることを意味します。各開発は分散して行われ、後に統合されてアプリが完成します。コンテナはこの開発手法において欠かせない存在です。

これらは小規模ながら重要なソフトウェアユニットであり、開発者がマイクロサービスを独立し完全に隔離された環境で展開するための前提条件となります。

高速な処理と軽量な仕組みにより、VMよりもコンテナが好まれます。使用する際は、関連するベストなセキュリティ対策を講じることが強く推奨されます。基本的には、コンテナやそれに関連するインフラ、ランタイム、アプリ、展開環境を確実に守ることが求められます。

実際、従来の資源セキュリティ対策よりもはるかに複雑です。理由は、コンテナセキュリティがオーケストレータとクラスターという2段階の対策を必要とし、片方だけでは十分ではないからです。

その範囲の広さから、徹底したセキュリティを維持することはDevOpsチームにとって大きな課題となっています。多くの専門家は、最新のセキュリティソリューションや適切な手法、最新のセキュリティポリシーを組み合わせ、一つの実行可能な対策を構築することを推奨しています。

‍

なぜ重要なのか？

コンテナセキュリティの重要性について語る際、必ず触れるべき事実があります。コンテナおよびその関連技術は、初期状態で強固なセキュリティが備わっていません。

実際、提供されるのはごく基本的なセキュリティ対策のみで、サイバー攻撃を完全に防ぐには不十分です。例えば、KubernetesではRBACが採用されておらず、Dockerにも欠点があり、誰でもDocker Hubにコンテナイメージを登録できる状況です。

十分な対策が講じられなければ、開発者は欠陥のあるコンテナを使用するリスクがあり、データ、インフラ、アプリが危険にさらされる恐れがあります。

次に、セキュリティ対策を採用すべき理由は、コンテナイメージが開発プロセス全体に深く浸透していることにあります。分散型のアプリやプロジェクトでは、コンテナはコンテナイメージから作られるため、イメージが守られていなければ全体の開発プロセスが危険に晒されます。

また、多くのコンテナ同士が連携しているため、各要素の保護は非常に骨の折れる作業です。このような密な環境では、脆弱性が部分から部分へと容易に広がり、長期間放置すればシステム全体やプロジェクトに大きな影響を与える可能性があります。

‍

コンテナセキュリティの構成要素

1. IDEとソースコード

デジタルソリューション構築において極めて重要な役割を果たすため、これらに脆弱性があるとアプリにその影響が波及します。貴社は、コード生成に暗号化された隔離環境を使用し、IDEも十分に守られていることを確認する必要があります。

2. コンテナランタイム 

コンテナが動作する期間を指します。したがって、コンテナランタイムのセキュリティに対して妥協することはできません。

対策が不十分な場合、不正アクセス、サイバー攻撃、脆弱性の混入といった問題が容易に発生し、攻撃者が悪意あるリソースを速やかに導入してシステム全体を破壊する恐れがあります。また、ランタイムで使用される全リソースを監視し、検証済みのものだけを利用することが求められます。

そのため、検証・承認済みのランタイムリソースのみを使用するようにしなければなりません。

3. CI/CD

CI/CD基盤は分散型ソリューションの開発に広く利用されています。古いイメージが混入しないよう、自動テストを用いて除去することが望まれます。

4. コンテナレジストリ

貴社には、チームが容易にアクセスできるコンテナイメージ保管庫が必要です。これがコンテナレジストリであり、必ず守られるべき資産です。

保護されていないレジストリは脆弱性の入り口となり、侵入された場合、保存された全てのイメージに脅威が拡大する可能性があります。したがって、認証やID管理を徹底することが推奨されます。

5. コンテナオーケストレーションプラットフォーム 

主要なオーケストレーターにはDockerとKubernetesがあり、これらはコンテナベースのアプリ開発において、コンテナの管理や迅速なスケーリングに大いに役立っています。

その人気の高さから、攻撃者はこれらを標的にし始めているため、セキュリティ対策なしでの利用は推奨されません。検証済みであっても、十分な予防措置を講じる必要があります。

6. コンテナ用インフラ

最後に、コンテナの作成プロセス全体を管理するネットワークやサーバインフラの保護について述べます。コンテナ用インフラに脆弱性があると、システム全体に影響を及ぼす可能性があるため、AppSecチームは十分で実用的なセキュリティ対策を用いてインフラを守ることに注力する必要があります。

‍

コンテナセキュリティ展開向上に伴う課題とリスク

クラウドコンテナセキュリティは妥協できない一方、その複雑さは無視できません。開発過程では常にいくつかの困難や危険に直面する可能性があります。例えば：

• 対象コンポーネントが広範に分散している。 監視対象すべてに一元的にアクセスすることはできないため、各要素に細心の注意を払う必要があります。コンテナイメージ向けの対策がそのままコンテナインフラに適用できるとは限らず、対応が非常に複雑かつ広範になる場合があります。
• ‍コンテナは動的なIPアドレスを使用するため、ネットワークセキュリティが常に脅かされる。 動的に更新されるため、保護が難しい状況です。
• ‍コンポーネントの相互連携。 分散していても各要素は密接に連携しており、一部のコンテナイメージのエラーがランタイムに影響するなど、AppSec担当者が全要素を守るのは非常に困難です。
• ‍求められるコンプライアンスが多すぎる。 例えば、SOC-2、GDPR、HIPAA、PCI DSSなどがあり、各基準は求めるセキュリティレベルが異なるため、全てを満たすのは容易ではありません。

コンテナセキュリティソリューションの種類

• モニタリング支援ツール

機能豊富なコンテナセキュリティツールは、AppSecチームがアプリの性能をプロセス全体で監視するのに役立ちます。コンテナは一時的なため管理が複雑で、監視には多くの時間と労力が必要です。

自動化ツールを用いることで、大規模な即時の性能データを収集し、正確に分析することが可能となります。これらのツールは、クラスターやワークロードの拡大・縮小にも柔軟に対応できます。

このようなツールは、コンテナベースのアプリやインフラが最適に動作しているかを確認するため、非常に重要です。高度なモニタリングは、CPU使用率や過去データを追跡し、問題の原因を見極める手助けとなります。

• コンテナスキャナー

複数のソースから得られるコンテナイメージが、検証済みかつ信頼できるものであるかを確認するため、セキュリティスキャナーの利用が推奨されます。最新のコンテナスキャナーは、クラスター、IaCテンプレート、コンテナ内の脆弱性を同時に検出することが可能です。

• コンテナネットワーキング

コンテナ特有のネットワーキングツールは、各コンテナ間の最適かつ仮想化された接続の構築に広く利用されています。この手法は、複数のコンテナベースのアプリを一つの高セキュリティ環境に統合する役割を果たします。

貴社のニーズや使用するツールの能力に応じ、複数のネットワークを同時に統合することが可能です。複数のネットワークが存在する場合でも、各ネットワークは完全に隔離されます。

これらのツールは、データのセキュリティや完全性を損なわずに容易なアクセスを可能にするため、マイクロサービスや分散型アプリの連携に大いに寄与しています。

‍

コンテナセキュリティのベストプラクティス

イメージの保護

コンテナイメージの保護ができていなければ、全ての努力が水泡に帰すことになります。イメージが守られていないと、作成されるコンテナに欠陥が生じるため、イメージの保護はセキュリティチームの最優先事項です。

また、コンテナイメージの全ての要素―依存関係、アプリのコード、ツール、ライブラリ―を守る必要があります。中でも、ツールとライブラリはセキュリティ上最も大きな脅威となり得ます。

特にサードパーティ製のツールは、検証されず脆弱性を含む可能性が高いため、十分な検証やスキャンを行わずに利用すると、既知の脆弱性がコンテナ、イメージ、ランタイム、そして最終的にはアプリに影響を及ぼします。

オープンソースのライブラリは誰でもアクセスでき、開発者によって変更されるため、十分に管理されていません。したがって、事前の入念な確認と検証なしで使用すべきではありません。

イメージ生成にはベースイメージが使用されるため、セキュリティ戦略の下で管理されるべきです。検証済みのベースイメージプロバイダーのみの利用を強く推奨します。公式かつ検証されたイメージは専門家が管理し、脆弱性スキャンも実施されているため、信頼性が高いです。たとえ信頼できるベースイメージを使用していても、使用前のスキャンが望ましいです。

最後に、コンテナイメージが対象コンテナに対してroot権限を持たないようにする必要があります。専用のユーザーアカウントでシステムに導入するようDockerfileで設定し、常に同じアカウントでアクセスするようにしてください。

レジストリの保護

レジストリはコンテナの重要な部分であり、貴社では有用なコンテナイメージを保管するために、極めてプライベートなレジストリが運用されます。つまり、レジストリはコンテナイメージのデータベースであり、そのセキュリティは絶対に守る必要があります。

保存されたコンテナイメージが改ざんされず、開発に利用されるその瞬間までオリジナルの状態を維持できるよう、最適なセキュリティ対策について学ぶ必要があります。

レジストリのセキュリティを最高水準に保つため、開発者は以下を実施する必要があります：

・レジストリに対する厳格なアクセス制御を実施し、誰がどの目的で直接アクセスできるか、誰がどの範囲でイメージを変更できるか、またアクセス権の委譲が可能かを明確にする。

・イメージにデジタル署名を行い、使用状況の追跡を容易にする。署名されたイメージの管理者権限は署名者に留まり、他者による改ざんができなくなるため、改ざんの可能性が大幅に低減される。署名にはオープンソースのツール Notary を利用できる。

・イメージは必ずスキャンを実施する。出所に関わらず、使用前にスキャンを行い、深く根付いた脆弱性を検出するため、毎回の使用時に検査することが求められる。

展開の保護

展開中に発生する既知・未知の脅威は、全ての努力を水泡に帰す可能性があります。展開プロセスを守るための方法は以下の通りです：

• 対象環境が完全に守られていることを確認。ホスティングデバイスのOSを強化し、ファイアウォールやVPCルールを適用する。
• 適切なオーケストレーションツールを用いて、APIエンドポイントの保護とRBACの適用を実施。不正アクセスのリスクを低減する。
• できる限り展開プロセスを不変に保つ。初期段階で生成したインスタンスイメージを用い、その後のイメージ作成に活用する。
• プロジェクトの更新に伴い、新たなイメージを生成し古いものを廃棄する。

ランタイムの保護

十分に保護されていないコンテナランタイムは、攻撃者がアプリ、イメージ、インフラを狙うための触媒となります。ランタイムの保護方法としては、以下が推奨されます：

• 各コンテナごとに独立した仮想ネットワークを構築し、攻撃対象を最小限に抑える。
• 必要最小限の権限のみを許可することで、不要な接続を排除する。
• 全ポートを開放せず、SSHベースのポートのみを使用する。
• ランタイム内の全通信にTLS暗号化を適用し、認証済みのエンドポイントのみ許可する。
• バインドマウントされたストレージボリュームが使用されないようにし、ボリュームは読み取り専用に設定する。
• Docker Imageポリシープラグインを利用し、未検証のイメージがランタイムで使用されないよう管理する。

シークレットの管理

シークレットはコンテナ利用において重要な要素であり、平文で保存してはなりません。適切な保管方法により、各コンテナが使用するシークレットを確実に管理する必要があります。

シークレットは、組み込みの管理機能やクラウドベース、オープンソースのツールによっても管理され、自動スキャンや脅威対策が施されています。これらのツールは構成時に暗号化を行い、非常に安全な状態を保ちます。

全てのシークレットに同じキーを使用せず、定期的なキーのローテーションを行い、古いキーは廃棄することで攻撃リスクを下げることが可能です。

また、ボリュームマウント方式を用い、認証された特定の場所でのみコードを使ってシークレット値を取り出す方法も有効です。これにより、不正なリソースがシークレットにアクセスできなくなり、ほとんどのオーケストレーターがこの方法をサポートしています。

Kubernetesの保護

現代の開発者が利用するコンテナ化ツールの代表であるKubernetesは、コンテナの作成から運用までを担うため、その保護は欠かせません。Kubernetesを守るため、AppSecチームは以下を実施すべきです：

• 全通信にTLS暗号化を適用し、自動化する。
• サービスメッシュアーキテクチャを採用し、サイドカープロキシが安全な環境で動作するようにする。これにより、ポリシー適用、トラフィック監視、全体管理が容易になる。
• OPA（Open Policy Agent）を使用し、Kubernetes全体にカスタマーポリシーを適用する。
• Kubernetesのデフォルトネットワークポリシーは全ポッドに暗号化を適用しないため、独自のポリシーを全体に適用する。
• Kubernetes処理用にプライベートネットワークを構築し、マスターノードとワーカーを安全なサブネット内に配置する。
• 機能豊富なファイアウォールを用いてetcdクラスターを分離し、データを保護する。
• 暗号鍵や証明書は定期的にローテーションし、攻撃対象を減少させる。
• YAMLは静的解析を実施し、不正なAPIサーバアクセスを防ぐ。
• コードを常に監視し、静的解析で検証済みのものだけを開発に取り入れる。
• RBACまたは最小特権の原則を採用し、Kubernetesへのアクセスを厳格に制御する。
• APIサーバはサードパーティの認証で保護し、脆弱性の入口を排除する。

ゼロトラストの原則

ゼロトラストモデルでは「誰も信頼せず、皆を検証する」とされ、この実践により、コンテナや関連リソースにアクセスするたびに利用者が確認されるため、セキュリティが向上します。

コンテナ活動の監視

どんな対策を講じても、コンテナの活動を監視し続けることは重要です。コンテナイメージは動的で複数の実行環境に支えられ、新たなイメージが常に追加されるため、既存のセキュリティ対策だけでは全てを守りきれない恐れがあります。

継続的な監視により、DevOpsチームは早期に脆弱性を発見しやすくなります。

‍

Wallarmによるコンテナセキュリティ

Wallarmは、自動化された機能豊富なセキュリティソリューションを提供する実績あるサイバーセキュリティ企業です。最初の製品は、主要クラウド環境の全APIやマイクロサービスを守る最先端のクラウドベースWAFです。

マイクロサービスの分散性にも柔軟に対応するWallarmのCloud WAFは、誤検知がほぼなく、ブロックモードで動作するため、その存在を察知されにくいです。

また、KubernetesのAPIを完全に保護する、高機能なAPI脅威対策プラットフォームも提供されています。このプラットフォームは、OWASP Top 10の脅威、アカウント乗っ取り、ボット攻撃などからAPIを守ります。

脅威検出から将来的な対策まで、WallarmのAPI脅威対策プラットフォームが総合的に対応します。CI/CDパイプラインでのAPIテストやスキャンの自動化により、インフラ全体やアプリを守るのが容易です。

さらに、クラウドの種類に関係なく、Kubernetesを利用するAPI、ウェブサイト、マイクロサービスを守る専用のセキュリティプラットフォームも提供されています。

このツールはKubernetesインフラに容易に統合され、ブロックモードで動作します。運用負荷の低いセキュリティルールにより管理が簡単で、これらの対策により、どの段階のコンテナもどのクラウド環境のアプリも守りやすくなります。