連載：DXにおけるDevSecOpsとは？「米・国防総省はどのようにしてKubernetesとIstioへの移行を果たしたか？」「DevSecOps Days Tokyo」レポート①

DX時代において、業務システムは改革の対象の一つとなっています。業務にマッチしたシステムを構築する必要性から、開発と運用がダイナミックに連携し、改善を繰り返す 開発手法である「DevOps」が浸透しつつあります。

しかし、DevOpsで実現される高速開発と高頻度のリリースを、従来型のセキュリティ対策だけで守りきるのは困難です。そこで、DevOpsにセキュリティを融合させた「DevSecOps」の重要性に注目が集まっています。

2020年10月5日と6日、「DevSecOps Days Tokyo」（主催・DevSecOps Days Tokyoコミュニティ、後援・アメリカ大使館・経済産業省・カーネギーメロン大学CyLab、SEIほか）がオンラインにて開催されました。

DevSecOpsDaysとは、米・カーネギーメロン大学や先端テクノロジー企業の有志によって始められた、DevSecOpsについての情報交換を行うコミュニティイベントです。2020年には東京の他、サンフランシスコやロンドン、シンガポールなど、合わせて世界12都市で開催。
DevSecOpsをテーマにしたイベントが日本で開催されるのは初めてであり、米・国防総省やカーネギーメロン大学関係者が登壇することで注目を集めました。

ここでは、DevSecOps Day Tokyoを4回に分けて、スペシャルレポート。今回は、米・国防総省のニコラス・シャラン氏の基調講演「米・国防総省はどのようにしてKubernetesとIstioへの移行を果たしたか？」の内容をレポートします。

※本記事は、ブレインパッドがDevSecOps Days Tokyoの許可を得たうえで、本イベントを聴講し執筆しています。細心の注意を払って情報を掲載していますが、そのコンテンツの誤謬・遅延・正確性・相当性・完全性などについて一切責任を負いかねますのでご了承ください。

イベントの模様はYouTubeに公開されています。

・Day1：https://www.youtube.com/watch?v=poMiLi0kS88&t=5689s
・Day2：https://www.youtube.com/watch?v=DOaWf2aKFwg&t=1867s

基調講演「米・国防総省はどのようにしてKubernetesとIstioへの移行を果たしたか？」

ニコラス・シャランと申します。米国空軍最高ソフトウェア責任者、そして米・国防総省DevSecOpsイニシアティブ共同統括です。今日このようなお話をさせていただくのは、私たちがやっていることや、オープンソースに積極的に取り組んでいることの重要性をお伝えしたかったからです。私たちは、これまで10か国以上の方々とパートナー関係を組んできました。今後は日本の皆さんと協力し合えることを楽しみにしています。

まず、 DevSecOpsのROIの高さについて考えていきましょう。そのためには、課題に迅速に対応しなければならない一方で、チームでの作業が必要となります。ここにはいろいろなテクノロジーも絡んできますので、ますます複雑な作業となってしまうでしょう。モジュール化、アジャイル化し、より柔軟に適応しながらミッションに関わっていかなければなりません。私たちのミッションには宇宙での活動も含まれまして、そこでは多くのセンサーを用いますので、そうしたモジュール化、アジャイル化が必須になっているのです。また、各国との協力関係というのも重要になっています。

なぜDevSecOpsが必要かという理由は、いくつかあります。まず、タイムリーに行うことが大切だからです。次に、開発のペースが重要であるため。さらに、セキュリティの基本的な考え方も必要であるためです。ソフトウェアのライフサイクルを考えると、サイバーセキュリティに影響が出ないように、またソフトウェアのセキュリティを損なわずに、新しいものをできるだけ早く提供しなければならないでしょう。ですから、セキュリティ内蔵型（Baked-In Security）のソフトウェア開発が必要になります。

国防総省で2年前に取り組みを始めたときに、2つのメインチームを作りました。国防総省全体を横串に刺した「Cloud One」と「Platform One」という2つのチームです。Cloud Oneというのはクラウド関連のオフィスで、機密情報とそうではない情報の両方を扱います。一方のPlatform OneはDecSecOpsのチームで、オン・ボーディングのシーンに対して提供します。このチーム化によって、タイムリーにモジュール化したサービスを提供できるようになりました。

そして、プロダクトやプラットフォームのロックインを回避することが大きな狙いだったので、オープンソースのKubernetesやコンテナを使いました。これは何度も繰り返し組み立てることができる、ブロックのようなものです。中央制御の成果物として、Iron Bankというものも作りました。すべてオープンソースになっていますので、ぜひご覧いただければと思います。

スケーラブルなマイクロサービス・アーキテクチャであることが重要

重要なことは、スケーラブルなマイクロサービス・アーキテクチャであるということです。サービスメッシュについてもお話ししましょう。これはジェット機から宇宙システム、武器システムなど、あらゆるクラウドやオンプレミスで走らせることができるようにコンテナ化されています。また、ソフトウェアが米・国防総省で使われるためにはATO（Authority to Operate）が必要となってきます。ATOを取得するには8～12カ月が必要です。DevSecOpsにおいては、ATOが断続的にならないよう自動的に担保されます。

年間10万人以上を対象にトレーニングをしていて、かつ自習用のコンテンツもあり最新のDevSecOpsのカリキュラムを提供していますが、適切なトレーニング用の教材などを見つけるのはなかなか難しいことです。

スケールアップが容易であるKubernetes

Kubernetesはソフトウェアを抽象化できるオーケストレーションシステムで、コンテナを使うことによってクラウドプロバイダやプラットフォームを抽象化できます。一元化した形で安全に使用でき、自動化のプロセスでスケールアップも可能です。例えば、オープンソースの製品と商用の製品を使うこともできます。

レジリエンシーや自己修復の能力もありますから、もしコンテナがクラッシュしても自動的にリスタートできます。Sidecarを利用することによって、ログ管理、テレメトリング、モニタリングなど、いろいろな機能の導入も可能です。このSidecarは、処理時の負荷にかかわらず常に実行されています。つまりさまざまなペースでソフトウェアを提供できるということです。

Kubernetesはロードバランシングをするための適応能力が高く、オートスケーリングの機能もあります。もっと性能やメモリが必要であれば、スケールアップすることも可能です。このような理由からKubernetesを選びました。他の競合はもはや残っていないと思うので、Kubernetesはデファクトスタンダードともいえます。

DevSecOpsにもこういったスタックまたはツールがあります。200以上のコンテナがありますが、例えばいくつかのコンテナまたはアプリケーションをバーチャルマシンで使うとなると非常に難しいでしょう。そこでコンテナを使うことで、自己管理・合理化することができます。

5層のレイヤーで構成されているDevSecOps

そしてDevSecOpsのレイヤーを考えてみると、まず機密データやそうでないものを扱うインフラストラクチャ・レイヤーがあります。次にKubernetesが乗っているプラットフォーム・レイヤーがあります。その上がCI/CD （継続的インテグレーション/継続的デリバリー）レイヤーで、リポジトリなどもここに入っています。

コンテナの間では東西のトラフィックと呼んでいますが、その管理のためにサービスメッシュ・レイヤーがあります。ここではIstioを使うことで、攻撃の対象を減らしています。そしてアプリケーション・レイヤーは小さいものですが、私たちのチームはこのスタックの上でソフトウェアを開発するわけです。サイバーセキュリティに関しては、いろいろなテストやオートメーションについて、下のレイヤーが行ったことを継承します。

スケールの面ではPlatform Oneが大きな構成要因で、早く動けた理由の一つでもあります。こういったエンタプライズサービスとしての機能を提供し、いろいろな機関やミッションからのニーズを満たしているのです。

「すべてがコード」というDevSecOpsの概念

他には、「すべてがコードである」というDevSecOpsの概念が挙げられるでしょう。変化に対して迅速にデプロイし、パイプラインで対応していくということがチームの成功を左右します。システムをわざとクラッシュさせ再起動させるトレーニングであるカオスエンジニアリングは、元々Netflixが導入したものですが、このようなトレーニングによって、コンテナに侵入された際に止めることができるようにします。

サービスメッシュを成功させるということに関しては、例えばPlatform Oneにおいて6つのコンピュータ言語で活動している場合には、それを分離させます。一つがJavaでもう一つがPythonの場合、ロードバランシングやローディングを行い、ポリシーを暗号化して専用化します。そしてリリースしていく際に、各チームが同じスケジュールで動けるようにするのです。

チームがそれぞれのマイクロサービスに分離していかないのはなぜかというと、各コンテナが単独で使えるようになっているからです。もし他のシステムと連結されていると、リリースができなくなってしまいます。サービスメッシュがあるおかげで、それぞれのコンテナを分けて考えることができるのです。そして重要な土台は、A/Bテストを行うことです。これによりロードバランシングやゼロトラスト、暗号化などが可能になります。

GitOpsについては、すべてがGitにあり、ソースコードがリポジトリに入っている、それだけのことです。誰かがシステムリポジトリにアクセスしようとすると問題になり得るわけですが、GitOpsでは一元化されたソースコードやパスワードなどが暗号化されてリポジトリに入っています。例えば災害が起きた場合にも、ソースコードリポジトリというのを復旧し、プッシュバック、ロールバックできるのです。

日本の皆さんがDevSecOpsに取り組む上でのアドバイスとしては、まずエンタープライズ・サービスを揃えるための外部とのパートナリングが重要となることをお伝えしたいです。また、私は米国の政府組織で初めての最高ソフトウェア責任者という役割を担っていますが、コンセプトが気に入っています。DevSecOpsを推進するために組織を動かしながら、アジャイル、リーンなソフトウェア開発を推進できます。ですから、こうしたトップダウンの効いた組織構造も重要です。さらに、私たちは政府の組織ですが、顧客意識が重要であると考えています。Platform OneやCloud Oneを構築していくにあたって、企業であるかのように顧客を意識して進めてきました。

DevSecOpsに真剣に取り組んでいない方は、できるだけ早く取り組みを始めていく必要があります。いま取り組んでいないと1年か2年以内には、時代遅れの廃れたものになってしまいます。競合相手の方がより速く対応していく可能性があるためです。DevSecOpsをやっているのと、いないのとでは、セキュアなシステムを構築するスピードが何百倍も変わってきます。何百倍も遅いスピードで競争相手と勝負ができる方がいるとは思えません。ですから、できるだけ早くDevSecOpsに取り組んでいく必要があると思います。

※本記事は、DevSecOps Days Tokyoの許可を得て、記事掲載しています。

連載：DXにおけるDevSecOpsとは？

「DevSecOps Days Tokyo」レポート①：「米・国防総省はどのようにしてKubernatesとIstioへの移行を果たしたか？
「DevSecOps Days Tokyo」レポート②：「DevSecOpsの導入を成功させるための5つのチャレンジ」
「DevSecOps Days Tokyo」レポート③（前編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート③（後編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート④：「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」