「攻めていくか、守りに徹するか」
ーBlack Duck Softwareのテクノロジーエバンジェリスト、ティム・マッケイが考えるリスク可能性と、コンテナ化した環境でのデータセンターオペレーションについての考察ー
オープンソーステクノロジーがエンジニアリングチームに浸透するにしたがって、オペレーションセキュリティがデータセンターのオペレーションにどのように影響するかを検証することが重要になってくる。アプリケーションのデプロイおよび管理を限定しているガバナンスの現状に向き合いながらも、データセンターは境界線内での防衛から内部監査コントロールにいたるまで、幅広いセキュリティ対策もせざるを得ない。
現実には、データセンターの管理チームは外部および内部の脅威に対して受け身になりがちだ。EU一般データ保護規則（GDPR）などの規制の階層化や、絶え間ないサイバーセキュリティ脅威に対応するうち、情報の侵害における複雑さに追いつこうとするモデルがどんどん複雑になっていく一方で、DevOpsチームの責任もどんどん重くなっていく。
オープンソースプラットフォーム
データセンターのオペレーターの多くは、Linuxのようなオープンソースプラットフォームや、KVMあるいはXenといった仮想化ソリューションにはなじみがある。これらのツールがあれば、システムのデプロイ速度を標準化および向上させながら、ハードウェアの根本的な問題からワークロードを切り離すこともできる。しかしオープンソースのデプロイの実務面が標準になると、思いもよらぬところにまでオープンソースコンポーネントがデプロイされてしまう。ネットワークデバイス、ファイアーウォール、プロキシ、不法侵入管理システム、さらにはソフトウェア定義ネットワーク（SDN）まで、すべてにオープンソーステクノロジーが行きわたることになる。
新しいオープンソースプロジェクトの開発者は、自分たちに固有の問題を解決するためのプロジェクトを作ることが多々ある。彼らにとっては、それが目の前の必要を満たしてくれるだけで「十分よくできた」ソリューションだからだ。そしてそのソースコードをパブリックな場所にポストするのだが、そこには関連するオープンソースライセンスが付随している。ほかのどんなソフトウェアライセンスでもそうだが、オープンソースライセンスはある種の権利と義務をともなっている。「伝播性のない」ライセンスが二次著作物をシェアする義務を負わないことを意味するのに対して、「伝播性のある」ライセンスでは二次著作物をシェアしなければならない。企業が伝播性のないライセンスに基づいたコードを導入した場合、コミュニティにシェアしないままで新しいものを作れるが、伝播性のあるライセンスに基づくコードを導入したならば、それをコミュニティでシェアしなければならない。
オープンソースライセンスがデータセンターオペレーションに与える影響を理解するには、組織がどのようにしてテクノロジーを導入するのかを理解する必要がある。ほんの10年前には、ソフトウェアは所有するものであり、入手するにはライセンス料を支払ってソフトウェアソリューションを購入し、デプロイするものだった。Red HatやSUSEといったオープンソースソフトウェアの営利ベンダーも存在するとはいえ、営利ベンダーをはるかにしのぐ数のオープンソースプロジェクトが存在している。
オープンソースソフトウェアソリューションを導入することは、必要なものの大部分を満たしてくれるパッケージをダウンロードしてデプロイする程度に簡単なことかもしれない。たとえそのソリューションが期待に100%こたえてくれなくても、開発者がソースコードにアクセスすれば欠けているコンポーネントを作ることができる。しかし、伝播性のあるライセンスを通じて提示される改善を、コアプロジェクトが取り入れる必要はないため、改善を提示した個人が所有する分岐をプロジェクトの外に作ることになる。（伝播性のないライセンスならば内部分岐を作ってもよい。）ともかく、どんな分岐であれ、それが平行した開発ストリームとなる。
オープンソースコンポーネントを組み込んだ企業ソフトウェアには、意図的であれ非意図的であれ、コンポーネントの分岐が含まれていることが多い。意図的な分岐とは上記のようなもので、非意図的な分岐とは、オリジナルのコンポーネントの開発が続くうちに、あるコンポーネントがシステムに組み込まれるときに起きるものだ。そうすると、組み込まれたバージョンがオリジナルのコンポーネントの展開のしかたとは異なってくる状況が生まれる。そうなったら、自分が分岐させたソフトウェアコンポーネントを維持管理する責任を使用者が負うことになる。
この責任が、データセンターオペレーションの中でオープンソースベースのシステムを管理する場合のポイントになる。ベンダーが供給するのがソフトウェアであれ、ファームウェアであれ、電化製品であれ、目下の所有リスクを評価するには、成果物の構成を理解することが重要である。セキュリティ事象が起きた場合には、規則違反というリスクもありうる。
成果物のオープンソースコンポーネントを記述してあるBOMは、データセンターのオペレーターが脆弱性とライセンスの両方でリスクを減らすのに役立つ。伝播性のあるライセンスが絡んでいる場合、ソースコードのかたちで開示される。伝播性のないライセンスは、最終使用者にソースコードにアクセスする権限を委譲しないため、かわりにオープンソースライセンスにのっとった適切な方法でこれを開示する必要がある。ライセンスにかかわらず、これらのコンポーネントは、関連するガバナンス規則の「補修」および「進行中のセキュリティ監視」条件の影響下にあるソフトウェア資産である。
コンテナ化したシステム
コンテナ化したシステムとは、すなわちオープンソースソフトウェアのスタックである。このスタックは、オペレーティングシステム（Linuxが一般的）、コンテナランタイム（Dockerからのものが一般的）、コンテナオーケストレーションシステム（Kubernetes、Red Hat OpenShift、Apache Mesosなど）、そしてコンテナイメージからなっている。このコンテナイメージは「ベースイメージ」から構築されたもので、アプリケーションコードが結合したLinuxオペレーティングシステムコンポーネントを含んでいることが多く、コンテナ化したアプリケーションを形成している。任意のコンテナイメージに関連するリスクを理解するためには、スタックの各レイヤーに存在するリスクと、スタックおよびコンテナ内の各レイヤーの構造を理解する必要がある。
継続的統合とデリバリーのDevOpsの原則は、コンテナ化したアプリケーションの高速でのデプロイを可能にする。それによって、開発期間および機能的アジリティには、デリバリーパイプラインのあらゆるフェーズにおけるセキュリティ評価が含まれていなければならない。例えば、統合フェーズのあいだにセキュリティリスクの評価を実行しなければならない。ガバナンス規則にしたがうことができなければ、アプリケーションのデリバリーは失敗する。
“開発期間および機能的なアジリティにはデリバリーパイプラインのあらゆるフェーズにおけるセキュリティ評価が含まれていなければならない”
同じように、規制要件を満たしていることを立証するために、データセンターチームはデプロイに先立ってセキュリティ監査を行うよう自動化する必要がある。正しく設計されていれば、コンテナ化したアプリケーションはひとつの変更不能コンテナイメージから複数のインスタンスをデプロイするので、コンテナイメージの認証を通じてセキュリティリスクを継続的に監視するという規制要件を満たすことができる。これにより、監視要件がシステムパフォーマンス全体に与える影響を最小化することができる。オーケストレーションシステムに内在する情報とあわせて、このモデルはシステムが自動的に新たなセキュリティ開示の影響評価を行えるようにする。
このような影響評価は、いかなる改善計画においても重要なコンポーネントである。デプロイしたアプリケーションの構造と、デプロイスタック内の従属物を完全に理解できていなければ、影響評価は失敗しがちになる。この問題に対する実行可能なソリューションには、次のような明確な特性がある。
・すべてのコンテナイメージを、ソースやデプロイモデルにかかわらず、自動的にスキャンする
・オーケストレーションソリューションにメタデータを提供し、デプロイポリシーを執行できるようにする
・セキュリティ変更点がデプロイ可能なイメージで開示されると同時にそれを識別する
・コンセプトエクスプロイトを検査するためにセキュリティ開示をマッピングし、すぐに実施可能な改善ガイダンスを提供する
・特にコード分岐に関して、オープンソースについてのデプロイを理解する
データセンターのチームは、1週間に何百と開示される新たなオープンソース脆弱性に必死で追いつこうとしている。オープンソースコードの構成および影響評価を大局的に理解することなしに、データセンターチームがあらゆるセキュリティ事象にすばやく対応することは困難である。
★参考：blackduck software
