「昨日のアプリケーションのために設計されたセキュリティインフラで、明日のサービスを守ることはできない。セキュリティの目標は変わらない。サービスデリバリーを弾力的に保護し、センシティブなデータを守り、攻撃が発生した場合の経済的影響を最小限に抑えることにある」

　「そうした機能を提供する方法は、クラウド特有の機能を活用して設計し直すことができる」

情報セキュリティの再考

　クラウドネイティブとDevOps環境で開発されるアプリケーションの時代の中で、情報セキュリティは再考すべきときにあるとマクドナルド氏は言う。その目標は「全般的なセキュリティおよびリスク耐性の向上と、セキュリティおよびITの耐久性向上」にある。

　その響きは有望だ。だが大企業にとって、ITの再考は言うはやすしでも、実行に移すのは難しい。DevOpsとコンテナ化について考え、安全に打ち出すためにはどんなやり方が最善なのか。そもそもなぜそうしなければならないのか。

　この文脈における「コンテナ化」とは、モジュール式のアプローチによるプログラミングを指す。このアプローチでは、運用に必要なもの全てを含む軽量なソフトウェアパッケージが同じOSの上に積み重ねられる。

　コンテナ化への対応が容易な理由はそこにある。マイクロサービスとコンテナは、条件が整ったことで特に過去2年の間に劇的なペースで普及した。

　企業は既に仮想化とオープンソースのメリットを認識し、クラウドアプリケーションは確実に浸透している。コンテナへの飛躍は自然な流れであり、ほとんどの場合、自信を持って推進できる。サーバ仮想化が最初に登場したとき、明らかなメリットがあるにもかかわらず企業による採用が遅かったのとは対照的だ。

　コンテナへの確信が表れているもう一つの側面として、既にこれを導入している企業の存在がある。その動きの最前線にいるGoogleは、オープンソースのコンテナオーケストレーションツール「Kubernetes」を開発した。

　Kubernetesは、瞬く間に導入の自動化とコンテナ化されたアプリケーションを拡張および管理するためのデファクトスタンダードとなった。今ではGoogleを離れて完全にオープンな方式で進化している。

　急成長しているIT主導型の公益企業OVO Energyの開発者でコンテナを推進するクリス・スミス氏は、「Bristech」という知識共有のためのITコミュニティーを推進している。コンテナの使用事例は明らかだと同氏は言い、「OVOはコンテナを大いに利用しており、ここから普及が進む。ほとんどの先進的な技術主導企業も同じような状況だが、これは主流の領域に入りつつある」と指摘する。

　「Googleは『Docker』のようなコンテナ技術が台頭するずっと前から、1日に何億ものコンテナを運用してきた。これは企業での普及に向けた潜在的可能性を表すと言ってもいい。組織がその展望に目を向ければ、仮想マシンを運用するよりアジャイルでスピードが速く、コスト効率の高いソフトウェアのスピーディーなデリバリーを望む場面で理にかなう領域が見つかる」（スミス氏）

　セキュリティに関してスミス氏は、DevOpsとコンテナの採用は、最初に専用のニッチチームで正しい組織的文化を育みながら、適切な制限をかけ、セキュリティツールの成熟を注意深く見守ることに尽きると指摘する。

　「OVOは人気オープンソースツールを使ってコンテナイメージをスキャンし、既知の脆弱（ぜいじゃく）性を探し出す。われわれのシステムや慣行が現実的に優れているのは、コンテナの脅威の一つがブレークアウト（脱獄）だからだ」

　「もしDockerデーモンを露呈させたりしたら、コンテナリソース上で任意のコードの実行が可能になる。DevOpsに取り掛かる前に確実なプロセスを導入してエンドポイントの守りを固めておけば、この種のリスクは避けられる」

　「IPアドレスのホワイトリストやHTTPS、クライアント証明書、メッセージの署名に対する共有された秘密の利用といった手段を使えば、脆弱なエンドポイントは回避できる。インフラを継続的にスキャンすることもできる」。スミス氏はそう言い添えた。

　コンテナで最も多いのは、分離や深層防御が事前に実装されていないことに伴う危険だとスミス氏らは指摘する。「あるホストが不正なパッケージや不正なコンテナによって破られたとしても、ネットワーク分離やセキュリティグループ、厳格なファイアウォールのルールがあれば、不正なソフトウェアが問題を拡散させることはできない。危険なのは、一部の開発者にコンテナを実験的に利用させ、その後プロトコルが適切に整う前に一部のプロジェクトが実を結んでしまった場合だ。つまり、どんな組織でも前もって考えておく必要がある」

　スミス氏は今、開発者の間でクラウドインフラやコンテナ、コンテナセキュリティへの関心が高まりつつある状況を、Bristechを通じて実感している。

　「DevOpsでは必然的に、開発者の多様なスキルが求められる。従来の環境では、コード担当者がコードを書き、テスターがテストを行い、プロダクション環境に開発者が関わる必要はなかった。だがDevOpsチームは、誰もが開発とテストと導入を担い、全般的な所有権を握る」

　「これは思考の切り替えであり、全ての開発者にその飛躍のための準備ができているわけではない。だが適切なサポートがあれば、間違いなくその切り替えができ、統合的に組み込まれたセキュリティについて適切に理解できる人物はいる」

　DevOpsの新興企業RUGGDの創業者、サイモン・ミントン氏は、スミス氏と同様、セキュリティとDevOpsで最も大切なのは最初のアプローチと文化的正しさ、そしてそれにこだわり続けることだと指摘する。

　「コンテナは開発にとって利便性が高い。そのおかげでどんな開発環境にも対応できるようになり、バージョン管理などが可能になる。だがセキュリティアプローチも組み込む必要がある。もしコンテナが露呈すれば、広範囲のアクセスを許すことになりかねないことは明白だ」

懸念材料はなし

　DevOpsの文化を取り入れた企業は、同時にセキュリティも大胆に取り入れていることを裏付ける証拠があることから、これは必ずしも懸念材料にはならないとミントン氏は言う。この2つの組み合わせに関する認識は浸透している。

　「この調査は、DevOpsの文化が最も成熟している企業で、コンテナのためのセキュリティツールがいかに採用されているかを物語る。そうした成熟度の高いDevOps企業は一般的に、開発チームに組み込まれてセキュリティ啓発とベストプラクティスの構築を担う『セキュリティチャンピオン』の役職を創設している」

　ビジネス機能の大部分にコンテナを採用した企業の一つに、ブックメーカーのSmarketsがある。同社の従業員は110人で収益は2500万ポンド（約35億円）超。英ロンドンと米ロサンゼルス、マルタにオフィスを構える。同社エンジニアリング担当バイスプレジデントのミカ・ボストローム氏は、スピードとアジャイル性に関してコンテナは正しい選択肢だが、ある程度の規律も求められると話す。

　「例えばコンテナ関連のサプライチェーンが存在する。構築済みのコンテナイメージは簡単で、使いたい衝動に駆られる。だが予想外の事態が起きることもあり、それを見過ごさないようにしなければならない。コンテナには理解しなければならない攻撃面も存在する。コンテナは身軽さと同一視されることもあるが、必要最低限のもののみを残して全てをそぎ落とすことが簡単にできるとは限らない。実際に簡単ではない」とボストローム氏。

　ボトムアップ方式でこの課題に対応するには教育に尽きるとボストローム氏は話し、「われわれはセキュリティを求め、同時に使い勝手も求める。学習に意味を持たせ、開発チームをより良いプラクティスへと向かわせる方法で取り組むことが課題になる」と指摘する。

　「われわれのアプローチは、セキュリティを確実に組み込みながら、それが妨げにならないように気を配る。この安全性をもっと便利なものにすることができれば、その道は正しい」

　「われわれのプロジェクトの多くは、複雑なことをしていながらその複雑性が隠されている。われわれが目指しているのはそれだ。コンテナツールの中で、Dockerは最も簡単で最も勢いがあり、ツールも素晴らしい。だが未来はオーケストレーションと複雑性にある。その到来が予想される中、われわれはあらゆる段階で学習しなければならないと認識している」

　ボストローム氏によれば、SmarketsにとってDevOpsとはリスクに耐える文化を取り入れることでもある。「障害が起きても安定性を保つシステムを構築すれば、信頼が生まれ、もっと自由な実験ができるようになる。ソフトウェア開発の間でセキュリティは評判が悪い。なぜならそのために何かが、大抵の場合は使い勝手が損なわれると見なされるからだ」

　「DevOpsは特注ツールと関連付けられるかもしれない。だが技術問題ばかり見ていると、全体像が見えなくなる。これは結局のところ、使い勝手を向上させるものだ」

　セキュリティはコモディティではなく、進行中のプロセスの結果だとボストローム氏は言う。その点でこれは、本質的に開発プロセスを特定の方法で運用する文化としてのDevOpsと多くの共通点がある。「この2つを融合させることで、われわれは最終的に人々の行動を変えることを目指しているということを忘れてはならない。強制ではなく、優しく背中を押すことにより、人間の本質にあらがうのではなく、それを利用したいと思っている」

　では具体的にどうコンテナに着手して、セキュリティを維持すべきなのか。単純な方法は存在するのか。

　CA Technologiesの上級トランスフォーメーションコンサルタント、コリン・ドモニー氏は、アプリケーションセキュリティとセキュアなDevOpsに注目している。同氏には、Deutsche Bankで4年間この分野に携わった経験もある。「ここには前向きなメッセージがある。大企業の多くは既に、ガバナンスやインフラのコントロールに苦慮しており、時代遅れのOSを使っていたり、パッチが行き届かなかったりすることもある。その現実に照らして、コンテナとオーケストレーションが約束するものは、セキュリティに関する限り有望だ」

　コンテナの柔軟性は、セキュリティの観点から多くのメリットをもたらすとドモニー氏は言う。企業が正しいアプローチを採れば、確認され、テストされ、確固たるものとなったイメージを導入できると力説する。「この考え方で物事にアプローチすれば、よりセキュアなインフラを構築できるチャンスがあるのは明らかだ」

　「確かに、開発者に信頼と責任を置くことにはなるが、いずれにしてもそうするだろう。しかもKubernetesのようなオーケストレーション技術は多くの問題を解決してくれる」

　組織はまず、適用しやすいポリシーを取り入れた計画で、小さく始める必要があると同氏は言う。ポリシーは、特定のパラメーターの範囲内でのコンテナ運営と、きめ細かいネットワーク管理を確実に徹底させる必要がある。

　「要は、今そこにツールがあるということだ。それは完璧ではない。だがそれを積み重ねればセキュリティを実現できるのか。見方によっては実現できないかもしれない。だがそれは動く標的であり、企業が順応することは可能だ」

　「この分野は、過去1年半の間に前例のないペースで進化している。従って、どんな溝でもすぐに埋まると信じるに足る理由は数多くある」とドモニー氏は話している。

コンテナとTitusを通じてNetflixのグローバル化を支援

　メディア大手のNetflixにとって、Amazon EC2（Elastic Compute Cloud）の仮想マシン（VM）へのデプロイを加速できたのはコンテナのおかげだった。

　Netflixはコンテナベースアプリケーションのためのインフラ基盤として、コンテナ管理プラットフォーム「Titus」を使っている。Titusはクラスタ拡張とリソース管理、Amazon EC2と密接に統合されたコンテナ実行機能を提供する。

　NetflixがTitusに切り替えた2015年12月時点で、1週間に数千のコンテナを立ち上げた。2018年初めまでに立ち上げたコンテナは100万を超え、ワークロードは数百に上る。コンテナの利用は約1年で千倍に増えた計算になる。以後も成長のペースは衰えていない。

　2017年初め、Netflixのサービスとしてのストリーム処理チームは、「Apache Flink」ベースのクラスタ管理のシンプル化と高速化を実現するため、Titusの採用を決めた。

　Netflixは、Dockerのレイヤー構造のイメージとコンテナデブロイ用に前もってプロビジョニングされたVMを使うことにより、開発者によるアプリケーションの新バージョンのプッシュ配信を以前よりも高速化する一助とすることに重点を置いている。

　Netflixによると、VMを使った場合は数十分かかっていたが、Titusを使ったデプロイは1～2分でできるようになった。

　こうした全ての改善点の根底にあるテーマとして、Netflixは「開発者のイノベーション速度」を掲げる。これは実用的には、バッチとサービスの両方のユーザーがローカルで実験でき、テストをもっと迅速にできることを意味する。

　開発者はさらに、プロダクションへのデプロイについても以前よりも自信を持てるようになった。Netflixの顧客に素早く機能を提供する原動力となっているのはこのスピードであり、これは同社の事業の要となっている。

　セキュリティに関して同社は、既存のEC2サービスを「深く活用」することを選んだ。ルート可能なIPには個別のオーバーレイネットワークではなく、仮想プライベートクラウドを利用している。さらにエラスティックネットワークインタフェースを使って、全コンテナにアプリケーション専用のセキュリティグループを持たせている。

　Netflixによると、Titusが提供するメタデータプロキシはそのコンテナの環境に関するコンテナ専用の表示と、IDアクセス管理認証情報を取得できる。

　コンテナからホストのメタデータを参照することはできず、NetflixはLinuxとDockerおよび同社独自の隔離技術を組み合わせて、マルチテナント分離（CPU、メモリ、ディスク、ネットワーキング、セキュリティ）を実装している。