コンテナセキュリティベストプラクティスのための4つのステップ：コンテナのリスク

コンテナには特有のリスクがある。これを正しく認識して対策を講じるにはどうすればいいのか。コンテナを安全に活用するための4つのステップを紹介する。

[Alan Taberham and Niall Quinn，Computer Weekly]

　コンテナの概念は「Linux」から始まり、2013年に「Docker」が主流に押し上げた。オーケストレーションレイヤーの進化によってコンテナの機能は成熟と拡大を続け、NetflixやPayPal Holdingsなど、特にハイパースケールクラウドサプライヤーのプラットフォームやマイクロサービスアーキテクチャではその傾向が強い。

関連記事

• 企業が絶対知っておくべきコンテナセキュリティの弱点
• コンテナとDevOpsに求められるセキュリティ
• コンテナセキュリティにゼロトラストを適用すべき理由
• 実はリスクが多いコンテナのセキュリティを確保する方法
• コンテキストベースセキュリティへの期待と残念な欠落点

　業務でコンテナの安全な導入と継続的な利用を支えるCISO（最高情報セキュリティ責任者）は、コンテナがもたらす脅威とリスクに対処できることを確認しておかなければならない。IT資産の成長に伴って複雑さやサイズが増していくことはコンテナに限ったことではない。だが、コンテナにはCISOが検討すべき4つの分野がある。

1．ペースを維持し、手作業による再構築に圧倒されないように、DevSecOpsを使ってセキュリティチーム内のコードパイプラインに関するメンタリティーを確保する

　コンテナ化したアプリケーションのコードへのパッチ適用には、コンテナのベースイメージの更新とコンテナの再構築・再デプロイが必要だ。コンテナは最新状態にしておかなければならない。その課題を乗り越えるには、セキュリティの専門家が開発者チームの一員になることが重要だ。

　全てのDevSecOpsパイプラインと同様、コンテナイメージに埋め込まれる形でハードコードした資格情報の漏えい、脆弱（ぜいじゃく）性のスキャン、そのソフトウェアにパッケージされる依存関係の信頼度の決定についても予防措置を講じる必要がある。脆弱性検出の改善に役立つこうしたアクティビティーは、全てコストの削減につながる。パッチを適用するには、コンテナを停止して置き換え、再起動できる必要があることを忘れてはならない。

2．スケールに対応できる構成管理とセキュリティツールを導入する

　効果的な構成管理は不可欠だ。この構成管理の課題をサポートするのがオーケストレーションサービス（「Kubernetes」「Amazon Elastic Container Service」「Azure Container Service」）、Micro Focus Internationalの「Configuration Management」などのCMDB（コンテナネイティブ構成管理データベース）やコンテナのラベル付け／タグ付けのポリシーだ。これらと並行して、ネットワークのセキュリティ、ログ、ホストOS、コンテナセキュリティを管理するアプローチも必要だ。

　コンテナエコシステムの内外の脅威からコンテナを保護する方法が必要だ。マクロレベルの方法としては、リスクゾーン（Dockerの用語では「ポッド」）を導入する。コンテナはこのゾーン内なら自由に相互通信できる。だが、ゾーンの境界をまたぐとファイアウォールのルールが適用される。マイクロレベルの方法としては、コンテナイメージを備えたエージェントを導入する。これにより、動的に更新するかCI/CDパイプラインにファイアウォールのルールを組み込むことができる。どちらの方法にも、IT資産全体にわたって標準化したアプローチに自動コンプライアンスレポートを組み合わせる必要がある。

3．コンテナのリソース管理とホストの影響が及ぶ範囲の保護を実装する

　コンテナ技術を採用する2つの理由は、可用性とスケーラビリティだ。これにはガバナンスの課題があり、効果的なリソース管理が必要になる。ホストにリソース制限を適用するとコンテナのキャパシティーが増加しパフォーマンスの向上が可能になり、結果としてランニングコストが下がり、セキュリティのリスクが少なくなる。

　任意のコンテナアーキテクチャにホスト保護リソース管理を埋め込むと構成の脆弱性が減り、カーネルパニックなどの重大なリスクが軽減される。カーネルパニックはホストのクラッシュを引き起こし、その後コンテナのクラッシュにつながる恐れがある。

　コンテナをクラウドにデプロイすると、セキュリティの課題の多くは簡素化される。クラウドにデプロイしないとホスト管理、容易なセキュリティメカニズム、自動化、スケーリングなどの多くに手動のプロセスが必要になる。開発者と必要なセキュリティチームへの自動化されたアクションとアラートにより、セキュリティインシデントの影響が及ぶ範囲と対応時間全体を大幅に削減できる。

　コンテナホスト型のアプリケーションをデプロイする場合の懸念は、攻撃者が脆弱なアプリケーションを使って基盤となるコンテナインフラにアクセスできるようになるリスクだ。こうしたリスクを緩和し、アプリケーションが悪用されてもroot（管理者）レベルのアクセスを防ぐためには、最小権限の原則に関するポリシーをコンテナに適用することが、シンプルだが効果的な手法になる。

　コンテナ化した環境を有する全ての組織にとって重要なのは、可能性のある全てのセキュリティリスクを網羅する最新のリスク登録簿を管理することだ。これにより、セキュリティチームはセキュリティ違反につながる根本的な問題を監視し、明らかにすることができる。

4．サイバーセキュリティガイドのベストプラクティスを適用する

　攻撃とインシデントの最も可能性の高いルートは、根本的かつ基本的な原則に従っていないところだ。災害復旧とフェイルオーバーの計画が最新ではないか、全く用意されていないことに起因することが多い。これはインシデントの管理が不十分で、時間との勝負になるインシデントでは試行済みで検証済みの手続きが貴重なリソースになることを認識していないことを意味する。

　NIST 800-190（Application Container Security Guide）は、以下のような最も一般的な脅威に対処するためのベストプラクティスを示している。

• コンテナ技術のコアコンポーネントの主なリスク
• 主なリスクへの対策
• コンテナ脅威シナリオの例
• コンテナ技術のライフサイクルのセキュリティに関する考慮事項

　可能な限り自動化し、サイバーセキュリティに関する強力な文化を育むことで、コンテナは業務の進化に対応し、増え続ける規制の負担に耐えられるセキュリティアーキテクチャを開発する機能を提供する。本稿で紹介した4つの分野を検討することで、ビジネスとセキュリティをサポートするために必要な安全対策を講じ、コンテナを最大限に活用できるようになる。