コンテナセキュリティの始め方 - Runフェーズのセキュリティ
-
│
はじめに
前回の記事までに、コンテナのライフサイクルである"Build - Ship - Run"のBuildフェーズとShipフェーズの
セキュリティ課題とセキュリティ対策について解説しました。
今回は最後のフェーズであるRunフェーズのセキュリティに関して、コンテナ実行基盤へのアクセス管理、ネットワークセキュリティ、
ランタイムの保護に関しての課題と対策のためのセキュリティアプローチを解説します。
3行でわかる本記事のサマリ
- Docker APIのセキュリティ脅威に対応するには、Firewallを活用し、接続元のDockerクライアントをホワイトリストで限定する運用が比較的簡単である。
- 人力でのFirewallルールの適用が大きな運用負荷になっている場合、機械学習によってFirewallルールを自動生成するソリューションの検討が必要。
- 各コンテナの提供サービスに必要な実行プロセスは限定的である特性を利用し、プロセスの実行に必要なシステムコールの呼び出しを制限し不要なプロセス実行を抑制できる。
目次
- コンテナへの攻撃
- コンテナ外部から - 外部公開サービスの脆弱性を狙ったアクセス -
- コンテナ内部に侵入後 - 他のコンテナへの水平展開 -
- コンテナ内部に侵入後 - プロセスの不正実行 -
- 可視性の確保
- まとめ
コンテナへの攻撃
コンテナのビジネス活用が増加するに比例して、国内でも稼働中のコンテナへの攻撃による様々な被害が報告されています。
ただし、その大部分は適切なセキュリティ対策を実装することで、抑制または緩和策を講じることが可能です。
攻撃の代表例としては、下記の挙動が確認されています。
コンテナ外部から
コンテナの実行環境に対しての外部からの攻撃は、攻撃者の立場からすると、アタックサーフェスを見つけるための最も基本的で重要な攻撃プロセスとなります。
攻撃者に攻撃の起点を作らせないための適切な対策を講じる必要があり、
この部分のセキュリティレベルが低い状態は、大きなセキュリティリスクを抱えたコンテナ運用を実行することに繋がります。
- 外部公開サービスの脆弱性を狙ったアクセス
- 既に侵害されたオブジェクトからコンテナに対する侵入試行(シェル実行)
コンテナ内部に侵入後
何らかの要因により稼働中のコンテナが侵害された場合、該当のコンテナを起点として、様々な攻撃が実行される危険性が生じます。
下記に代表される様々な挙動が確認されており、重大なセキュリティインシデントを引き起こした事例が多数報告されています。
- 権限昇格の試行
- プロセスの不正実行
- ファイルシステムのクローリング
- 他のコンテナへの水平展開
- コンテナ実行基盤へのAPI実行
上記は数ある攻撃パターンの内の抜粋ですが、従来から認知されている既知の攻撃から
コンテナ運用の特性を巧みに利用したハイレベルな攻撃まで、多種多様なバリエーションの攻撃が確認されています。
コンテナ外部から - 外部公開サービスの脆弱性を狙ったアクセス -
Docker APIを狙った攻撃
コンテナ運用を狙った攻撃の中で多くの検出件数が記録されている脅威として、不用意に外部公開されたDocker APIをアタックサーフェスとした攻撃パターンがあります。
Docker APIとは、管理者がコンテナのオペレーションを実行するためのアクセスを待ち受ける管理インターフェースです。
Docker ServerとDocker Client間でUNIXソケットではなく、TCPソケットでAPIコネクションを確立する状態を狙った外部からの攻撃による被害が、多数報告されています。
セキュリティ課題
Docker APIに外部からのアクセスが必要な運用シーンにおいて、コネクションの実現のみに意識が向いていると、
セキュリティが考慮されていない状態でコンテナ運用を実行してしまうケースが危惧されます。
- コンテナ運用に対するスキルセットが不足しており、管理アクセスの仕組みを十分に理解できていない
- ホストOSにはFirewallが適切に設定されておらず、Docker APIはグローバルに公開された状態となる
本来Docker APIは限定されたクライアントのみがアクセスできる状態であるべきですが、
グローバルに公開されてしまっている状態は非常にリスクの高い運用であることが想像できます。
本記事執筆時点でも、研究目的以外と見られるDocker APIがグローバルに公開されてしまっている事例を多数確認することができます。
該当のDocker APIに対して調査のために稼働中のコンテナの一覧を取得するAPIリクエストを実行したところ、下記の通りレスポンスが返されました。
本来であれば、アクセス不可を理由とするエラーレスポンスが返されるべきですが、インターネットを介して認証が求められることなく管理APIにアクセスできる脆弱な状態が確認できます。
セキュリティ実装
Docker APIのセキュリティ脅威に対応するには、Firewallを活用し、接続元のDockerクライアントをホワイトリストで限定する運用が比較的簡単です。
同様に、コンテナによって外部公開されているサービスの内、接続元のクライアントを限定する必要があるものに対しても、Firewallルールを適用することでセキュリティ対策ができます。
Docker APIや外部向けサービスの場合は、あらかじめ決められたポートが公開されるため、一度定義したFirewallルールがセキュリティ対策として永続的に有効に働きます。
コンテナ内部に侵入後 - 他のコンテナへの水平展開 -
侵害されたコンテナから他のコンテナへ拡散する脅威
セキュリティ対策が施されていない状態のコンテナ運用では、同一ノードまたは同一クラスタ上で稼働するコンテナ同士がIPアドレスベースで容易に通信できます。
この特性により、既に侵害されたコンテナから通信可能な他のコンテナに対する脅威の拡散事例が数多く報告されています。
セキュリティ課題
ポート番号が断定できる外部向けサービスへの攻撃は、ランダムなポート番号が割り当てられるコンテナが「生成」と「削除」を繰り返す内部向けサービス（コンテナ間通信を伴うもの）では、
人力でのFirewallルールの適用が大きな運用負荷になるという運用課題が生じます。
Firewallルールの適用漏れが生じた場合、侵害されたコンテナから発生する他のコンテナへのコネクション試行によって、攻撃の水平展開に発展してしまう恐れがあります。
セキュリティ実装
人力でのFirewallルール適用が運用負荷となるコンテナ間通信の制御は、機械学習によってFirewallルールを自動生成するソリューションが提供されています。
このソリューションは、コンテナがデプロイされてから一定時間内に発生したコンテナ間通信の学習モデルを正規の通信としてホワイトリストに登録し、
学習後に発生したホワイトリストに含まれない通信をブロックすることでFirewallの自動適用を実現しています。
コンテナ内部に侵入後 - プロセスの不正実行 -
侵害されたコンテナで実行されるプロセスによる攻撃
攻撃者はコンテナへのアクセスに成功した後、目的を達成するためにコンテナ内部でプロセスを実行します。
実行されるプロセスは、権限昇格やホストへのAPIリクエスト、マイニングの実行等様々な目的のものが確認されています。
セキュリティ課題
稼働中のコンテナのシェルに管理者がアクセスをしてオペレーションを実行する機会が少ないコンテナ運用では、
デプロイした後のコンテナ内部で何が起こっているかを把握することは困難です。
特に、大量のコンテナがデプロイされる環境では、モニタリングツールを駆使したとしても、異常動作を正確に把握する運用は難しいでしょう。
セキュリティ実装
各コンテナの提供サービスに必要な実行プロセスは限定的であるケースがほとんどで、これはコンテナの運用特性です。
この特性を利用し、プロセスの実行に必要なシステムコールの呼び出しを制限することで、本来のサービス実行に不必要なプロセスの実行を抑制できます。
具体的には、seccompを使用することで、システムコールの呼び出しを制限でき、
Dockerによるコンテナ実行時やKubernetesのマニフェストに対して、seccompプロファイルを指定することで実装できます。
seccompはLinuxカーネルに実装されているシステムコールの呼び出しを制限するためのセキュリティ機能です。
制御内容を記述したseccompプロファイルを適用することで制御を働かせますが、コンテナテクノロジーにも適用できます。
下記にseccompプロファイルを指定したDockerコンテナの実行例を示します。
seccompプロファイルを作成するためには、対象のコンテナ内部でstraceコマンドを実行し、
必要なシステムコールを把握するという手数を要するオペレーションが必要でした。
Buildフェーズで紹介したdocker-slimを活用することで、下記の通りseccompプロファイルの自動生成が可能です。
また、コンテナセキュリティツールによるプロセスの実行管理ソリューションも選択できます。
下記の例は、PaloAlto社が提供するPrisma Cloudを用いたプロセス実行制御です。
コンテナ内部で本来のサービス提供に不必要なプロセスが試行された場合に、実行を阻止している様子が確認できます。
可視性の確保
ここまで、Runフェーズで発生しうる脅威について解説してきましたが、Runフェーズのセキュリティを考察する中で最も重要な要素は可視性の確保です。
従来からのコンピューティング手法と比較して、コンテナ運用では管理者が稼働中のコンテナのシェルにアクセスしてオペレーションを実行する機会が少ないこと、
コンテナ内部で起こっているイベントを直接把握する機会が少ないことによる異常動作の検知遅れが課題となります。
ビジネス向けのサービスを実行しているコンテナ運用シーンでは、この課題に対してモニタリングツールを導入することで可視性を確保することが求められます。
モニタリングツールによって異常動作にいち早く気付くことができ、インシデントに対するレスポンス速度の向上が期待できます。
また、頻繁に生成/削除を繰り返す可能性があるコンテナ運用の場合、
コンテナ内部で発生するイベントをフォレンジックデータとして蓄積できることは、インシデントの詳細把握を実現するための大きな価値を提供します。
下記の例では、PaloAlto社が提供するPrisma Cloudを用いて稼働中のコンテナのモニタリングを実現しています。
単一のモニタリングダッシュボードからコンテナ間通信に用いられるポート、コンテナが持つ脆弱性の状態やコンプライアンス準拠状況、
コンテナ内部で発生するイベント等のコンテナのセキュリティ運用に不可欠な情報をリアルタイムに取得し、表示できます。
稼働中のコンテナのマッピング
コンテナ間通信に使用されているポート
個々のコンテナのセキュリティ状態
フォレンジック情報
まとめ
【コンテナセキュリティの始め方】最終章の今回は、コンテナ運用のライフサイクルのRunフェーズでのセキュリティ課題とセキュリティ実装について紹介しました。
BuildフェーズとShipフェーズで適切なセキュリティ対策を実装できている場合であっても、
Runフェーズではコンテナの実行に伴う様々なセキュリティ課題が生じることをご認識いただけたかと思います。
特に、Runフェーズで生じるセキュリティリスクは、ビジネスインパクトの強いセキュリティインシデントに直結するものが多く、
Runフェーズでのセキュリティ実装の重要度を正しく理解しておく必要があります。
本記事で紹介したセキュリティ課題は、多種多様なバリエーションが存在する中からの抜粋ですが、
多数の脅威事例のトリガーとして抑えておくべき基本的かつ重要な例を厳選して解説しています。
Runフェーズのコンテナセキュリティ運用の最低限としてご活用いただき、少しでもセキュリティレベルの向上に貢献し、
自社のコンテナ運用の特性に最適化された更なるセキュリティ実装の考察のきっかけになることを願っています。
シリーズ記事のご紹介 【コンテナセキュリティの始め方】
関連資料のご紹介
『コンテナ環境をプラットフォームまるごと保護！今話題のCNAPPとは？』
コンテナセキュリティのベストプラクティスにあわせ、それらをホストするクラウドのセキュリティを、
ガートナー社が提唱する「CNAPP」の観点を用いてデモを交えて解説します。
『後悔しないクラウドセキュリティ選び「6つの視点」～クラウド環境のセキュリティ、どんな論点で考えるべき！？～』
