連載：DXにおけるDevSecOpsとは？「DevSecOpsの導入を成功させるための5つのチャレンジ」「DevSecOps Days Tokyo」レポート②

基調講演「DevSecOpsの導入を成功させるための5つのチャレンジ」

こんにちは。日本での初めてのDevSecOps Daysに参加でき、とてもうれしく思います。DevSecOpsはとても素晴らしいものですが、課題がないわけではありません。その課題とソリューションをご紹介したいと思います。

私はソフトウェア開発の世界に25年以上身を置いていまして、アジャイル開発、IEEEなどの標準機関に関わり、DevOpsとDevSecOpsについも、カーネギーメロン大学で2015年から教えています。これは実は世界で最初の大学でのDevOpsとDevSecOpsについての講義でした。DevSecOpsはスピード感のあるソフトウェアです。20年前にソフトウェア開発をする時には6カ月サイクルや2年サイクルで作っていたように思いますが、DevSecOpsでは2秒単位で開発していると感じます。

まずは、IEEE におけるDevSecOpsの定義を見てみましょう。DevSecOpsは原則と実践の一体となったもので、単なるガバナンスの問題ではありません。ソフトウェア開発のライフサイクルに関わる人は誰でも、ステークホルダーとのコミュニケーションやコラボレーションが求められます。ステークホルダーとは、Devチーム、Opsチームといった開発組織だけでなく、ビジネスに関連するアーキテクト、デザインや法務に関わる人など、パイプラインに関わる全ての人が、DevSecOpsに関わりを持つ人となります。ですからDevSecOpsは、セキュリティがソフトウェア開発のプラクティスの全てにインテグレートされたものということになりますし、あらゆるステークホルダーの意識にセキュリティを入れ込むことでもあります。私たちはセキュリティに十分注意してこなかったのではないでしょうか。ソフトウェアのライフサイクルの中にはセキュリティを含めなければなりません。DevOpsはCI/CD （継続的インテグレーション/継続的デリバリー）をパイプラインに入れますが、いったんインフラができあがればもっと簡単にセキュリティも組み込めるはずです。

さて、DevOpsの原則はデプロイメントに関する特徴であり、これは繰り返し漸進的に行われるものです。ソフトウェア開発のライフサイクルは、それを通じて、特徴を作り出していきます。その際はメトリクスも正しいものを使い、モニタリングします。それから継続的なフィードバックも行わなければなりません。何か変更を加えたらキーメンバーにフィードバックし、共有することで透明性を確保します。

DevSecOpsのプラスな面とは何でしょうか？ それは、繰り返せるステップがあるということ、デプロイや開発の中でエラーを減らすことができることでしょう。デプロイに関して最も重要なのは、ビジネスのニーズに対応するということです。

加えてDevSecOpsの利点となるのが、トレーサビリティでしょう。もし社内のシステムの中にデータエレメントがあったなら、どうやって作業したのか、誰がコードを変えたのかといったことが分かるトレーサビリティがなくてはなりません。また、以前に何が行われたかということだけを見るのではなく、本番環境で何が行われたのかが分かるトレーサビリティも必要になります。

最後に、継続的なフィードバックについてです。これはステークホルダー間のコミュニケーションを作っていくということで、重要なものです。本番環境でどんな風にシステムが動いているのかということが分かれば、きちんとチームにフィードバックすることによってオンタイムで修正できます。

そしてライフサイクルの最初から最後まで、セキュリティを導入したいと考えています。セキュリティの要件についても、コンポーネントは何があるのか、どのようなメカニズムを使うのか、どのように暗号化するのか……。セキュリティは、そういったアーキテクチャやデザインのところからスタートします。

このようにリサーチに基づいてアーキテクチャのデザインフェーズから行うと、セキュリティの問題は50%削減できるといわれています。というのも、大半の脆弱性は2つの要因から起こるものだからです。1つめはデザインや設計部分の問題、システムの齟齬などです。そしてもう1つはバグです。この時、誰かがシステムのバグに乗じてエクスプロイトすることがあります。このような不具合やバグを防ぐためには、テストが必要です。動的テスト、静的テスト、ペンテストなどを行います。これらはライフサイクル全体で見て、すべてお互いにつながっていかなければなりません。

1つめの課題は「Lack of Assurance」

それでは、課題について見ていきましょう。課題には「保証の不足」「組織的な壁」「品質」「スキル」「ガイダンス」の5つがあると思います。一つひとつ見ていきましょう。

まずは保証の不足（Lack of Assurance）です。品質保証について、明確な定義はされていません。ですからセキュリティの保証にどんな標準があるのかということを学ぶ前に、まずセキュリティの保証をどういった風にやっているのかということをチームメンバーに聞いてみたり、カンファレンスに参加したりしてはいかがでしょうか。他の人から学び、そしてその経験を共有することが大事です。

2つめの課題は「組織的な壁」

2つめは組織的な壁（Organizational Barriers）です。これは非常に重要なものですが、まずはステークホルダー間の協力が欠けていることが挙げられるでしょう。まさに2009年にDevOpsがスタートしたのはここからです。協力関係が十分でないために問題が起こり、ソフトウェア開発に支障が出ることがあるといわれていました。

ステークホルダー間でのコラボレーションのためには何ができるのかというと、まずチームで考えなければなりません。チームを細かく分断するのではなく、同じゴールを目指して、皆で同じ船に乗ります。もし船が沈みそうな時は、全員一丸となって船を救わなければいけないわけです。そして間違いから学ぶ文化を作っていかなければなりません。何か間違いがあったのであれば、それを罰するのではなく、後から分析してみるわけです。そのフィードバックをチーム全員で共有します。

次はパイプラインのセキュリティです。正しいソフトウェアとパイプラインを作るために、使っているツールを統合しパイプラインに入れ込んでいきます。MTTR（平均復旧時間）やMTTD（検出までの平均時間）といったデータも集めていくわけです。そうすると、さらに連携がとれるでしょう。

そして、セキュリティの優先順位を上げることも大切です。チェックリストを作り、ライフサイクルを通してきちんと対応できるようにします。

3つめの課題は「品質不足」

3つめは、品質不足（Lack of Quality）ということです。セキュリティもアーキテクチャの要素だということは、つい忘れてしまうかもしれません。既にシステムを走らせてから行うのでは遅すぎるわけです。何かが起こってから対応する対症療法では、質も落ちてしまいます。ライフサイクルの早い段階からセキュリティを入れ込むことが大切です。

4つめの課題は「セキュリティスキル不足」

4つめは、セキュリティスキル不足（Lack of Security Skills）というものです。正しいスキルセットを持つチームメンバーがいないと、セキュリティに取り組むのは難しくなります。

私はカーネギーメロン大学院でも教えていますが、学生の多くはセキュリティのことをきちんと理解していません。コンピュータサイエンスのトレーニングはしていますし、アルゴリズムも書ける、そして機能についても理解できているのですが、セキュリティとなると分からなくなってしまうのです。

教育機関でトレーニングを受けていない開発者もそうです。ビジネス分析やデータ分析をしたとしても、最初はやはりセキュリティのスキルを持っていません。問題に直面した時に、現場で学んでいくわけです。しかし、それでは遅いかもしれません。問題が起こったらチームで学んでいくことが大事です。チームメンバーが犯したミスから学び、組織としてもそういった姿勢を推奨していく、そしてセキュリティのトレーニングをしていくということです。オンデマンドでも可能でしょう。

また、監査も重要です。彼らはセキュリティの構成要素の知識こそないものの、コンプライアンスからの視点を持っています。ですから、セキュリティの要件とはどんなものか学んでもらったらどうでしょうか。チームメンバーと一緒に、チームではどういうことを考えているのか、そしてOWASP Top 10やNIST SP 800-53（訳注：連邦政府情報システム、および連邦組織のためのセキュリティ管理策とプライバシー管理策）といった共通の標準から学んでもらえば、監査人もセキュリティの視点を持って見ることができます。また共通の標準として、データの要件にはどんなものがあるのかを理解してもらわなければなりません。私たちの方から、監査人に対して教育をすることが大事なのです。

5つめの課題は「セキュリティガイダンスが不十分」

5つめは、セキュリティガイダンスが不十分である（Insufficient Security Guidance）ということです。十分なリソースがあれば対応できるかもしれません。より長期的に持続可能なものを考えてみましょう。

まず、ナレッジベースを作っていくことができます。小さなものから拡大していき、組織用にセキュリティのアーキテクチャを作っていくということです。標準化については、大きなものから取り組むのは避け、基本的なフレームワークから行いましょう。

そして次に、積極的なモニタリングです。多くの場合、本番環境はモニタリングしているかもしれませんが、それを他の組織の皆さんと共有していないのではないでしょうか。本来やるべきことは、すべてのピースをモニタリングし、Devチームやアーキテクトと情報を共有することです。上流の方で見つかった脆弱性などを、Devチームに共有していないというケースが散見されます。何か起こった時に共有するというよりは、自分たちを守る志向に走ってしまっているのは悲しいことだと思います。

このモニタリングを積極的に行うためには、オンタイムにアラートを出し、どんなことが起こっているのかモニターすることです。そうすれば何らかのインシデントが起こった際も対応できるようになります。

DevSecOps環境構築には2つの課題がある

DevSecOpsの環境を構築する際には、2つの課題があると思います。一つは時間をかけ過ぎていることです。各ベンダーやAWSなど、ソフトウェアやインフラの購入元はいろいろあると思います。しかし、どこからサービスを買ったとしても、開発者がそれをきちんと使えているのか、スキルを持っているのか、そしてオン・ボーディングのノウハウを持っているのか、そういったことをユーザーの観点から考えてください。大切なのは、正しい知識をチームメンバーに与え、情報を共有することです。何もないのであればチームで一緒に作っていきます。そういったガイダンスや教訓、Webページなどを作る必要があるでしょう。

もう一つの課題は、メンテナンスです。アップデートしていくのであれば、バックアップはあるかどうか、バックアップ環境が整っているか、オペレーションのサポートはあるか、ベースイメージをどうやって保存するか、オーケストレーションの部分をどのように作っていくか、ライセンスにいくら払っているのかなど、メンテナンスに関してコストも含め考えておいてください。そうすることで、パイプラインを効果的に使ってメンテナンスできます。「DevSecOpsでDevSecOpsの環境を整える」わけです。

DevSecOpsの今後

課題とその対策が分かったら、まずはギャップを評価し、現在の問題は何かを捉えます。なぜDevSecOpsなのか、目的は何なのか、改善すべきギャップは何なのかなど……。スキルを改善するのであれば、DevSecOps Daysに参加させるといったようにトレーニングを提供するわけです。問題がプロセスに絡んでいるのであれば、プロセスを変更しましょう。あまり大きなことから始めず、小さなことから始めてどんどん大きくしていきます。赤ちゃんがハイハイから始まって歩けるようになるのと同じです。

リーダーやマネージャーの方は、チームメンバーが間違いから学ぶチャンスを与えてあげる、あるいはメトリクスなども活用し、お互いに学び合える環境を作ってください。そうすると、どんどん成果が出てきます。品質を犠牲にすることなく、セキュリティに取り組むこともできます。DevSecOpsに限界はありませんから、どんどん早く回していくことができると思います。

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

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

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