要旨本書は Docker テクノロジーについて概説し Docker の導入に伴ういくつかのセキュリティリスクについて説明します Docker 導入のセキュリティを確保するための措置を提示し 本番環境における Docker アプリケーションのセキュリティ確保に Black Duck Hub の導入がい

Transcription

1 Docker のセキュリティ確保 : 知っておくべきこと

2 要旨本書は Docker テクノロジーについて概説し Docker の導入に伴ういくつかのセキュリティリスクについて説明します Docker 導入のセキュリティを確保するための措置を提示し 本番環境における Docker アプリケーションのセキュリティ確保に Black Duck Hub の導入がいかに役立つかを見ていきます はじめにアプリケーションコンテナの仮想化プラットフォームである Docker の業界の受け入れ状況は 驚くべきと言わざるを得ません つい 2014 年まで Docker のコンテナは目新しいものであり ホストやサーバー デスクトップのような主流の仮想化に対してほとんど注目されない存在でした しかし 2015 年の半ばまでに 従来の仮想化ツールから Docker やその他の仮想コンテナへの移行が急速に進みました その証拠として 2015 年 8 月に SaaS の監視プラットフォームを提供する Datadog がアプリケーションホスティングサービスの顧客 7,000 社を対象に調査したところ Docker の利用が過去 12 か月の間で 5 倍に増えていることがわかりました 同様に興味深いことには より大きな企業の方が Dockerを試して採用している傾向にあることがわかりました Datadog の調査によると Docker は幅広いアプリケーションを対象としたホスティングサービスに使用されており これには MongoDB Elasticsearch また MySQL や Postgres のようなオープンソースリレーショナルデータベースも含まれていました OSS 大手の Red Hat, Inc.( 以下 Red Hat) が 2015 年に 383 名の IT 担当者を対象に調査したところ 回答者の 67% が今後 2 年間の間にクラウド (50%) やウェブおよび E コマースのソフトウェア (56%) で Docker の本番環境への展開を計画していることがわかりました Black Duck Hub で Docker のセキュリティを確保しかし Docker やその他のアプリケーションコンテナの利用にはリスクが伴います その主なものとして Docker コンテナの中にインストールされているアプリケーションやアプリケーションコンポーネントに潜む 悪用可能なソフトウェアの脆弱性があります Docker アプリケーションのコンテンツや導入のセキュリティを管理する新たなツールなしには 組織は機密情報を含むアプリケーションやデータを攻撃に晒す危険性があります Black Duck Software, Inc.( 以下 Black Duck) の脆弱性をスキャンしてマッピングするプラットフォーム Black Duck Hub は Docker コンテナ内のアプリケーションソースコードを追跡して分析できるようになり ダイナミックな IT 環境でのセキュリティやリスク評価を容易にします Docker の概要 Docker について 簡単に説明すると アプリケーション開発者やシステム管理者が分散アプリケーションを構築し 出荷し 実行することができるオープンプラットフォームです Docker を利用することでアプリケーションを素早く組み立て 確実に導入することができます 2

3 コンテナ Docker コンテナは ファイルシステム ネットワークスタック プロセススペース そしてシステムツールやシステムライブラリなど その他にアプリケーションを実行するのに必要なものから構成されています 各 Docker コンテナには指定のアプリケーションとその依存関係が含まれており これらはアプリケーションごとに異なりますが 同コンテナを複数コピーした場合は一致します Docker Engine アプリケーションの下には Docker Engine という あらゆるコンテナ内のホスト OS 上で動作するソフトウェアのレイヤーがあります アプリケーションが導入環境に関係なく 安定し たオペレーティング環境で動作することを保証するコンポーネントです オペレーティングシステム Docker コンテナは通常 一般的な OS のバージョンを利用します これには Microsoft の Windows OS の最近のバージョンだけでなく Red Hat Enterprise Linux や Ubuntu のような Linux ディストリビューションが挙げられます コンテナはホスト OS のユーザースペース内で独立したプロセスとして動作し カーネルリソースは他のコンテナと共有します ホスト環境 OS の下にはホストインフラストラクチャがあります これは開発者のノートパソコンやデスクトップパソコンのローカル環境 仮想マシン または AWS や OpenStack のような本番ホスト環境で動作しているベアメタルハイパーバイザであることがあります Docker Hub 最後に Docker Hub があります これはアプリケーションを共有して Docker のワークフローを自動化する クラウドベースのレジストリサービスです Docker Hub はパブリックな Docker イメージをホストし 開発者が Docker 環境を構築して管理するのを支援するサービスを提供します この SaaS アプリケーションは パブリックとプライベートの両 Docker ライブラリからイメージを見付けて管理し GitHub や Bitbucket と統合して Docker イメージの新規構築を自動化し イメージリポジトリへのユーザーのアクセスを管理するのに必要な様々な機能を提供します なぜ Docker か? Docker や同様のアプリケーションコンテナテクノロジーは 物理的なシングルテナントのコンピューティングリソースから 従来の IT 環境やクラウドでも動作する より効率的で仮想化されたマルチテナントのインフラストラクチャへの移行における次のステップになります Docker のその他のメリットとしては 開発業務を加速し 開発から本番環境への道のりの効率化を目指す いわゆる CI/CD ( 継続的インテグレーション / 継続的デリバリ ) 環境にも理想的に適していることが挙げられます Docker を利用することで ソフトウェア開発者は従来の IT や さらにはその他の仮想化テクノロジーに比べても 大幅な効率化を実現することができます 典型的なサーバーは 1000 以上の Docker コンテナをネイティブスピードで動かすことができます Docker 環境内のアプリケーションプロセスはホスト上で直接動作しますが 他のプロセスからは隔離されています 3

4 Docker コンテナ内の CPU やメモリ ネットワーク ディスク I/O パフォーマンスは 開発者がアプリケーションをネイティブ環境で実行した場合とほぼ同一です Docker の導入 : 検討すべきことコンテナには様々なメリットがあることは明らかですが 複雑さを増すという側面もあります コンテナはアプリケーションスタック内の新たなレイヤーであり アプリケーションオーナーやホスト企業にとっては悪用される可能性がある脆弱性やリスクのもとになります Docker コンテナは簡単に素早く設定して導入できるため間違いが増幅される可能性があり ダイナミックなIT 環境で導入したアプリケーションを追跡 管理するのが難しくなります Docker やその他のアプリケーションコンテナテクノロジーが提供するメリットを活用するためには 組織はコンテナに伴う可能性があるリスクを理解しなければなりません 具体的に言うと Docker やアプリケーションコンテナの導入は セキュリティや可視性を犠牲にして進めてはなりません コンテナ導入の際に検討すべき事項を以下に示します : コンテナの認定と由来 Docker コンテナの由来と健全性は このプラットフォームへ移行する組織にとって重大な懸案事項です Red Hat が調査した IT 担当者の 60% が Docker プラットフォームの採用にあたりコンテナの認定がないことが課題であると答えました 基本的に Docker は発行者とコンテナのホストの間の 信頼関係 に依存しており イメージが DockerHub や Red Hat の OpenShift のようなレジストリサーバーからコンテナホストに運ばれた時に信頼できるかが決められます コンテナイメージのコンテンツを精査するサポートシステムがないと Docker Hub のようなリポジトリ経由で提供される 安全性が損なわれた または悪質なコンテナイメージが 無防備な組織に配布される可能性があります Docker Hub のようなレジストリサーバーは 信用できないコンテナのリスクを軽減するのに役立つ管理機能を提供することができます 例えば 管理者はレジストリ内の機能を利用して 自社のネットワーク内に入ることを許可するコンテナイメージの種類を制限することができます ここ数か月 Docker はコンテナの信頼性を保証する責任を果たすためのさらなる措置を取りました Docker Content Trust は公開鍵暗号方式を利用して 発行者が Docker コンテナに 署名 して含まれるコードの健全性を保証できるようにしました 信頼されていないユーザーが Docker イメージを発行したい場合は Notary や The Update Framework (TUF) のような提携プロジェクトが同様の機能を提供します コンテナイメージの脆弱性コンテナの由来を保証することは必要ですが Docker 導入の安全を確保するには十分ではありません コンテナの発行者を確認しても ダウンロードしたコンテナ内のソフトウェアアプリケーションやそのサポートファイルに欠陥や悪用可能な脆弱性がないことは保証されません 特にコンテナの下にある OS が最新バージョンではない場合は コンテナは古くて安全ではないコンポーネントを組み合わせている可能性があります 4

5 民間から資金提供された調査によると Docker イメージのセキュリティの欠陥は珍しいことではないことがわかります Docker の開発者がコンテナイメージを取得したり置いたりするセントラルリポジトリである Docker Hub にあるイメージを調査したところ 公式リポジトリの 30% 以上に Shellshock や HeartBleed Poodle のような既知の脆弱性を狙った攻撃を 非常に受けやすい イメージが含まれていることがわかりました Docker 上の 一般的な イメージ ( どの認定機関にも明示的に検証されていないイメージ ) の 40% に 既知の悪用可能なセキュリティの欠陥が含まれていることがわかりました 言い換えると Docker を活用したい組織は 信頼 して 検証 できなければなりません つまり 企業は利用したいコンテナの発行者が信頼できることを確認し 企業をリスクに晒すような悪用可能な重大なセキュリティ上の脆弱性を そのコンテナのコンテンツが企業の環境に持ち込まないことを検証しなければなりません コンテナ管理コンテナの導入時に由来やセキュリティの検証に十分適切な措置を取ったとしても 組織は導入したコンテナ化アプリケーションについて警戒し続けなければなりません 他のアプリケーション同様 コンテナ化したアプリケーションは古くなります その過程で新たに発見されたセキュリティ上の脆弱性や その他のリスクに晒される可能性があります コンテナ化したアプリケーションには安全ではない または現在のアプリケーションやネットワーク環境とは同期していないデータや設定が含まれている可能性があります ある事例では 有名なクラウドファンディングサイトが そのウェブベースの資金調達プラットフォームの Docker コンテナを開発用デバッガが有効のまま本番環境へプッシュしました この結果 攻撃者は悪質なコードを脆弱なシステム上で実行できるようになりました Docker アプリケーションコンテナは様々なテクノロジーレイヤーから簡単に組み立てて導入することができますが これはあるレイヤーの脆弱性や設定の誤り 欠陥を 容易に複数のアプリケーションで再現できるということを意味します コンテナスキャニング機能を利用して Docker 導入のセキュリティを確保 Docker を採用する組織が増え このプラットフォームへの依存が増すにつれ コンテナ導入のセキュリティを確保する より優れた多くのツールが出てきました 信頼の連鎖の一方では Docker Content Trust のようなイニシアチブが 発行者が Docker Hub のようなウェブベースのリポジトリに発行するコンテナの信頼性を保証する容易な方法を提供します しかし 組織はライフサイクル全体を通じて コンテナ化アプリケーションのセキュリティを評価できなければなりません Black Duck Hub でコンテナのセキュリティを管理 Black Duck Hub は アプリケーションのライフサイクル全体を通じてアプリケーションコンテナのセキュリティを管理するのに不可欠なツールです Black Duck Hub により 組織は脆弱なオープンソースアプリケーションやその環境内のコンポーネントを識別して追跡することができます 評価には Black Duck の Knowledge- Base を利用します KnowledgeBase には 110 万件に及ぶオープンソースプロジェクトに 5

6 関する情報や 3500 億行以上のコードに渡る 10 万件以上の既知のオープンソースの脆弱性に関する詳細データが含まれています Red Hat との提携を通じ Black Duck のオープンソースやプロプライエタリコードの本番環境を識別してインベントリを作成する能力は 現在コンテナ化された環境にも適用されています Red Hat は Deep Container Inspection (DCI) を発表しました これは企業を対象にコンテナの認定やポリシー 信頼性の検証をまとめて提供する総合的アーキテクチャで アプリケーションコンテナを導入して管理するのに利用できます Red Hat は Black Duck と提携して DCI の一部として組織がコンテナのコンテンツを導入前 導入中 そして導入後に検証する手段を提供します Black Duck Hub の脆弱性をスキャンしてマッピングする機能を統合することで Open- Shift の利用者はコンテナ化アプリケーションに含まれているコードが個別に検証され 認定されていることがわかり 以前より信頼して安全にコンテナ化アプリケーションを用いて開発 実行することができます またこの統合は 新たに公開された脆弱性や セキュリティやリスクに影響する可能性があるコンテナの経年に伴う変化の影響を追跡する手段を提供します コンテナの信頼 検証 活用 Docker のようなコンテナテクノロジーは 企業が重要なアプリケーションを開発 導入 管理する方法を変えることを約束します しかし コンテナは万能薬ではありません アプリケーションのネイティブ環境や仮想マシンへの導入や管理に伴う課題と同じ課題がコンテナの導入にも影響を及ぼします それにも関わらず Docker をはじめとするコンテナプラットフォームの利用は手軽で柔軟であるため 管理者や IT 担当者は導入したアプリケーションのセキュリティを確保するために長年に渡り実施してきた慣行を忘れやすくなります IT 担当者への調査結果を見ると あらゆる規模の企業や組織が Docker のようなコンテナプラットフォームを活用していることがわかります しかし それらの導入のセキュリティや健全性を確保するツールも求められています Docker をはじめとするコンテナプラットフォーム経由で導入するアプリケーションは 導入前に認定し 含まれるコードが信頼できると認められている発行者のものであることを確認しなければなりません しかし コンテナ化アプリケーションのコードの由来を検証するだけでは十分ではありません プロプライエタリやオープンソースアプリケーションのコンポーネントの既知の悪用可能な脆弱性のようなセキュリティ上の問題は 企業のデータや IT 資産にとって重大なリスクとなります そのため組織はコンテナで導入したアプリケーションのセキュリティを 継続的に評価していかなければなりません Black Duck Hub のアプリケーションの脆弱性をスキャンしてマッピングする機能のおかげで Docker の利用者は導入前にも後にも脆弱性を識別し コンテナ化アプリケーション 6

7 が古くなること または新たなセキュリティの脆弱性や攻撃に晒されるのに伴って起こる問題を発見することができます さらに詳しく知りたい場合 : Black Duck Hub の無料デモ Black Duck Hub を利用してアプリケーションやコンテナをスキャンすれば 使用しているオープンソースプロジェクトやバージョンを 例えチームが修正を加えていても 識別することができます 業界で最も包括的なオープンソースプロジェクトのレジストリである Black Duck KnowledgeBase を活用することで Black Duck Hub は既知の脆弱性やライセンス要件 プロジェクトやコミュニティの活動を含め オープンソースプロジェクトに関する深い知見を提供します さらに それらのプロジェクトについて新たな脆弱性が識別された場合は警告し 修復措置を追跡して管理するツールを提供します Black Duck Hub を利用して コードに何が含まれているかを確認してください ぜひお問い合わせの上 Black Duck Hub の無料デモをご覧ください BLACK DUCK SOFTWARE について世界中のお客様は業界をリードする Black Duck Software の製品を用いて オープンソースソフトウェアの保全 管理を行い セキュリティ脆弱性 コンプライアンス 運用リスクに関する問題を解決しています Black Duck の本社は米国マサチューセッツ州バーリントンにあり カリフォルニア州のマウンテンビュー ロンドン フランクフルト 香港 東京 ソウル 北京に事業所があります 詳しくは をご覧ください 日本でのお問い合わせ TEL: をご覧ください