2020年10月16日

DevSecOpsとコンテナ: クラウドネイティブモデルが組織のセキュリティにもたらす新たな課題

コンテナのセキュリティを確保することは、従来の仮想マシンよりも困難です。コンテナの開発ライフサイクルにDevSecOpsの手法を導入すると、セキュリティを最初から組み込むことができます。

多くの場合、コンテナのプロジェクトは開発者のノートパソコン上で試験的に小さな環境で開始されます。そのプロジェクトは他のメンバーと共有され、数か月にわたって手を加えられた後に、チームはパッケージ化されたマイクロサービスを組織の本番環境に投入します。簡単なセキュリティチェックを完了すると、展開準備が整います。

ここから予定通りにいかなくなります。セキュリティチームがコンテナのライブラリに脆弱性を見つけて、プロジェクトを中断させます。セキュリティチームのリーダーはアプリを差し戻して再プログラミングを依頼し、詳細なドキュメントを要求します。コストが積み上がっていき、マネージャーは責任者を非難し始めて、経営幹部レベルまで報告が上がります。

アプリケーションデリバリでこのような問題が起こることは珍しくありません。組織において開発、運用、セキュリティ保護の行程をつなぐ仕組みは、昔から不安定なものでした。しかし近年、これらの行程は互いに連携するようになり、DevSecOpsと呼ばれる新しい概念に向けて社内カルチャーの変革が進んでいます。DevSecOpsでは、セキュリティチームとセキュリティの概念がDevOpsプロセスに組み込まれます。このため、セキュリティは最終段階で組み込まれるのではなく、通常はアプリケーションデリバリのプロセス内で早期に対処されるようになります。

コンテナアプリケーションを開発している組織では、「セキュリティのシフトレフト」という戦略が特に重要になります。コンテナは広く普及しており、アプリケーションデリバリのプロセスで欠かせない要素になりつつあります。コンテナのセキュリティを確保するのは、従来の仮想マシン (VM) よりも困難ですが、その一方で、コンテナの仕組みによって間接的に開発チームとセキュリティチームの連携が容易になります。

 

セキュリティの課題

コンテナは、VMよりも攻撃対象領域が大きいので、セキュリティを確保するのがより困難です。一般的なVM構成では、1つのハイパーバイザー上に多数のVMがあります。セキュリティチームが1つのVMで脆弱性を発見すると、実行中のそのVMにパッチを適用するだけで済みます。一方、コンテナプラットフォームではオペレーティングシステムの1つのカーネルが共有されているので、攻撃者は単一障害点を通じてシステム全体を悪用できてしまいます。

そのため、脆弱性の悪用やプログラムに問題があるアプリを通じて、1つのコンテナから、そのカーネル上で実行されているすべてのコンテナの可用性に悪影響が及ぶ可能性があります。仮想マシンでは、各VMに個別のカーネルがあるので、脆弱性の悪用 (またはプログラムに問題があるアプリ) の影響は限定的であり、被害を受けるのはVMの1つのインスタンスだけです。

このような理由から、コンテナ環境ではDevSecOpsのコラボレーションが役に立ちます。コンテナの不変性という特徴は、変更が必要な場合でも、実行中にパッチは適用されずにコンテナ自体が新しいバージョンに置き換えられるということです。この特徴により、開発、運用、セキュリティの各部門に同一の環境が提供され、ワークロードの整合性と予見性が確保されるので、異なる関係者によるコラボレーションが容易になります。

社内カルチャーの変革はトップダウンで始めなくてはなりません。これまで、経営幹部はテクノロジーには口出しせず、製品が予定どおりにリリースされて顧客の人気を集めることに力を注いでいました。彼らはセキュリティをコストセンターとして見ており、使うことはないだろうと思っている保険にお金を支払っているという認識でした。

コンテナでは、セキュリティを最優先に考えるアプローチが重要であり、製品開発ライフサイクルのすべてのレベルでセキュリティに取り組む必要があります。経営幹部がこのアプローチを受け入れなければ、コンテナのプロジェクトは失敗する可能性があるでしょう。トップダウンでの支援を行い、必要な体制やイニシアチブ、つまり、トレーニング、適切な人材の発掘、効果的なセキュリティプログラムの実施といった取り組みをサポートできるようにしてください。経営幹部には、自社の技術チームが適切なセキュリティ制御を実施していることに最終的な責任があります。たとえば、コードの品質保証ツールをCI/CDパイプラインに組み込んでおり、資格証明用の情報を安全に管理しているといったことです。

経営幹部は、正しいトレーニングプログラムが実施されるように努めなくてはなりません。開発者は高品質なコードを出荷することを望んでいますが、多くの場合、自社のプラットフォームで検証済みのコンテナイメージを使用することが重要であるといった概念を学んでいないからです。セキュアなコードを記述するための社内教育プログラムを用意することで、開発者はセキュアコーディングとDevSecOpsにおける自分たちの役割について理解できるようになります。

DevSecOpsの重要性を周知させるには、影響力を持つ協力者を見つけることも重要です。たとえば、開発チームの上級職は部下の開発者を指導することができ、同時に経営陣との橋渡し役にもなります。経営幹部は、DevSecOpsに向けて社内カルチャーの変革に投資したコストが、欠陥率を下げて高品質なソフトウェアをリリースできているという点で見返りを生み出していることを把握する必要があります。

 

DevSecOpsへの移行

DevSecOpsへの移行はどのように進めればよいでしょうか? 組織は3つの目標を達成することから始めることができます。つまり、計画的にセキュリティを確保するというアプローチを採用し、シフトレフトという概念を実践し、デフォルトでセキュリティを確保するというモットーに従います。

 

計画的にセキュリティを確保

クラウドネイティブやコンテナ駆動の環境では、作業が流動的になることが少なくありません。開発者は、先行設計から始めることはほとんどなく、より効率的な新しい方法が見つかったら、しばしば設計を変更します。そのため、開発プロセスの終盤にセキュリティチームが参加して脅威モデリングを行うことは簡単なことではありません。

セキュアな設計を行うという原則を最初から開発プロセスに取り入れましょう。セキュリティへの取り組みを早期に始めることで、専門家は設計段階でリスク要因を減らし、ソフトウェアのサプライチェーンについて理解を深め、セキュリティに関する適切なアドバイスを行えるようになります。さらに、セキュリティチームは早い段階でレビュープロセスに参加できるようになります。

 

シフトレフト

従来のウォーターフォール型の開発では、テストやセキュリティテストは常に最終段階での作業でした。つまり、ソフトウェアを作成した後、運用環境に渡される直前に行われるのです。製品が本番環境に投入される前日にセキュリティを組み込むようなやり方では、セキュリティが開発のボトルネックになります。また、リリースサイクルの合間には、セキュリティチームの作業がなくなってしまいます。

シフトレフトを実践し、テストサイクルをプロセスの早期に移動しましょう。そうすれば、ソフトウェアのテスターが製品開発の議論に参加できるようになります。彼らは製品がどのように使用されるかを把握できるので、その理解に基づいてテスト計画を作ることができ、問題を早期に発見できるようになります。DevOpsでは、製品に対する小さな変更を反復的に行うことが重要なので、リリース日という概念はもはや有効ではありません。代わりに、実用最小限の製品を作成することを目指し、機能を追加しながら作業を進めていきます。

 

デフォルトでのセキュリティ確保

開発者はセキュリティの専門家ではないため、デフォルトでセキュリティを確保するという方針は非常に理にかなっています。この場合、セキュアなアプリケーションを作成するためのツール一式を開発者と運用スタッフに提供します。コンテナ環境にはレジストリという概念がありますが、これはコンテナイメージをダウンロードできるディレクトリです。最初にコンテナイメージを用意し、そのイメージをベースにして独自の機能を追加していきましょう。

コンテナイメージはWebから誰でもダウンロードできますが、これらのイメージには脆弱性が含まれている可能性があります。デフォルトでセキュリティを確保するという方針の下では、公開されたソースからのコンテナイメージのダウンロードを禁止し、厳選されたレジストリを組織内に保持します。開発者がダウンロードできるコンテナイメージは、承認されたソースにあるものだけです。そのような機能は、各オーケストレーションプラットフォームに備わっています。プライベートレジストリを用意すると、セキュリティチームはコンテナのライブラリやセキュリティだけではなくライフサイクルも管理できるようになり、既存のイメージの脆弱性が修正されたら新しいイメージに置き換えることができます。

コンテナのオーケストレーションプラットフォームがあれば、セキュアなレジストリ、コンテナの脆弱性スキャン、シーケンス管理といった便利な制御機能を利用できます。しかし、多くの場合、コンテナのリアルタイム監視、コンテナ間のファイアウォール、CI/CDパイプラインに対する完全なプラグインといった機能は用意されていません。オーケストレーションプラットフォームはいくつかの点で役立ちますが、通常は、必要な機能をさらに追加することになるでしょう。

現在のところ、単一のベンダーやプラットフォームだけでは、コンテナ環境で徹底したセキュリティの保護を実現できないため、業界のベストプラクティスと最高のセキュリティテクノロジーを組み合わせてセキュリティアーキテクチャーを構築することが重要です。そのためには、市場を常にチェックし、課題を特定し、最適なセキュリティツールを見つけ出す必要があります。最終的には、オーケストレーションプラットフォーム、サードパーティツール、オープンソースツールを組み合わせて、既存のプロセスを変更することで、必要なソリューションが得られるでしょう。

 

強固なカルチャーを維持する

作り上げたDevSecOpsのカルチャーを組織に浸透させて最高レベルのコンテナセキュリティを確保するにはどうすればよいでしょうか? いくつかのヒントを紹介します。

  • 新しい課題が見つかったら、その課題について十分に理解します。
  • コンテナのセキュリティプログラムが他のセキュリティ管理プログラムと連携していることを確認します。多くの組織にはCERT (コンピューター緊急対応チーム) があり、新しい脆弱性が発生していないかを監視して、脆弱性に適切に対処できるようにしています。このチームは、使用中のコンテナツールセットについても把握している必要があります。
  • コンテナセキュリティの分野の発展について、常に最新の情報を把握するようにします。
  • コンプライアンスの観点による評価が、コンテナ環境でも行われていることを確認します。

 

また、利用しているベンダーのコンテナーエコシステムが活発で発展し続けているかどうかを常に確認することも重要です。コンテナのトップ企業として知られているDocker社は、自社の戦略を最近変更し、エンタープライズビジネスをMirantis社に売却して今後はオープンソースのコンポーネントに専念することを発表しました。また、Kubernetesはコンテナのオーケストレーションプラットフォームの定番になりつつあります。ほかのスタートアップ企業は買収されたり、合併したり、ビジネスから撤退したりすることになるでしょう。最適なテクノロジーを選択しており、そのテクノロジーを使い続けられることを確認し、1つのテクノロジーに固執しないようにしてください。

 

セキュリティを最初から組み込む

コンテナのテクノロジーは、生産性と柔軟性という点でアプリ開発に多くのメリットをもたらします。しかし、経営幹部の同意を得てサポートを受け、使用するテクノロジーを精査してリスクを認識しておかないと、大きなセキュリティホールが発生する可能性があります。このようなリスクはDevSecOpsに移行することで対処できます。コンテナ開発のライフサイクルにセキュリティを取り入れて、開発者がセキュアコーディングを実践する必要性を理解できるようにするのです。

 

DevSecOpsとコンテナ: リーダーのためのアドバイス

  • コンテナは大きなセキュリティホールを生み出す可能性があります。コンテナ化にDevSecOpsアプローチを導入すると、セキュリティを最終段階で組み込むのではなく、早期からセキュリティに対処できるようになります。
  • 次の3つの目標に取り組みます: 計画的にセキュリティを確保するという考え方を採用し、「シフトレフト」の概念を実践し、デフォルトでセキュリティを確保するという手法に従います。
  • コンテナ開発のライフサイクルにセキュリティを取り入れるには、トップダウン型のサポートが必要です。それがなければ、取り組みは失敗に終わるでしょう。

この記事/コンテンツは、記載されている特定の著者によって書かれたものであり、必ずしもヒューレット・パッカード エンタープライズの見解を反映しているわけではありません。

enterprise.nxt

ITプロフェッショナルの皆様へ価値あるインサイトをご提供する Enterprise.nxt へようこそ。

ハイブリッド IT、エッジコンピューティング、データセンター変革、新しいコンピューティングパラダイムに関する分析、リサーチ、実践的アドバイスを業界の第一人者からご提供します。

enterprise.nxt
ニュースレターのご登録

enterprise.nxtから最新のニュースをメールで配信します。