いま注目されている DevSecOps とは - vol.2

皆さん、こんにちは！ SBテクノロジーの湯下です。
前回の記事では、DevSecOps の概要や必要性、DevSecOps を構成する要素についてご紹介しました。今回は、DevSecOps を進めていく上で考慮すべきことを、具体例を交えながらお伝えしていきたいと思います。

DevSecOps を進めていく上で考慮すべきこと

やや逆説的ではありますが、アンチパターンをいくつか挙げてみます。

1. ツールを導入すれば DevSecOps が実現できると思っている
2. DevSecOps を適用するスコープが広すぎる
3. 「セキュリティに関することは、セキュリティ担当の仕事」だと思っている

1.ツールを導入すれば DevSecOps が実現できると思っている

これは、DevOps が流行した時にも言われていたことですが、DevSecOps でも同様であり、ツールはあくまで手段であることを忘れてはいけません。

往々にして DevSecOps では、システムの企画から運用に至るまでのあらゆる工程で様々なツールを利用することになります。また、DevSecOps (または DevOps) の公開事例を探すと、多種多様のツールが紹介されていることも多々あるかと思います。しかし、そもそもどのような課題を解決したいのか、どのような作業をツールに肩代わりさせて、どのようなメリットを享受したいかを考えてツールを選定しないと、無用の長物になってしまいかねません。

また、ツールだけではなく、前回の記事でご紹介した、クラウドやコンテナ、Infrastructure as Code、CI/CD といったテクノロジーについても同様のことが言えます。例えば、オンプレミスで動いている既存システムをコンテナ化して Kubernetes 上に移行する事例は、各所で耳にするようになりましたが、これだけで DevSecOps を実現できるでしょうか？ 言うまでもなく、答えは No です。コンテナ化にしても、インフラの自動化にしても、組織の文化や体制、システム開発/運用のプロセス、セキュリティ/ガバナンスといった観点も含めて整備していかないと、従来よりもむしろ実装や管理のための手間やコストが増えたり、技術要素が複雑化することで、それらを適切に扱うだけのスキルが備わっていないと、かえってセキュリティ上の問題を誘発しやすくなってしまいます。

実際のところ、「CI/CD ツールを使って、ビルド/テスト/リリース作業を自動化しよう」とか「既存システムをコンテナ化しよう」といった具合に、ツールやテクノロジーが先行することが結構あるように感じますが、ToBe 像や実現のためのタスクがイメージしやすいので、それ自体は問題無いと思います。重要なことは、DevSecOps の実現には、ツールやテクノロジーのみならず、組織/プロセス/ガバナンスの観点も併せて検討・整備していき、これらを上手く統合し、より良い形に継続的に改善していく必要があるということです。

そのためには、まず、自分たちが現在どういう状況にあって、自分たちが目指す DevSecOps の形がどのようなもので、そしてそのギャップがどれくらいあるのかを、組織/プロセス/テクノロジー/ガバナンスの観点から整理していくことから始めるのが良いでしょう。そうすることで、現状の課題、DevSecOps 実現のために必要なタスク (仕組み・プロセス作り、ツールの選定・購入、関係各所との調整等)、短期・中長期でのマイルストーンが明らかになっていきます。

ただ、その際、開発担当者/運用担当者/セキュリティ担当者/事業責任者といった様々なステークホルダーを交えて議論・検討しましょう。DevSecOps 推進担当のような立場の人が、数人ないしは 1 人で話を進めても、現場の課題を正しくピックアップできなかったり、DevSecOps の考え方や取り組みに同意してもらえないなど、その後の推進が困難になり、計画段階で頓挫してしまいがちです。このセクションの始めに、ツールやテクノロジーだけでは DevSecOps は実現できないとお伝えしましたが、DevSecOps 推進担当者だけでも実現できません。そもそも、システムは様々な人達が関わって作られ動いていることを考えると当然といえば当然ですが、つい力み過ぎて、気付いたら関係者とちゃんと話をしないまま進めてしまったということも起こりがちなので、その点は特に注意して進めていきましょう。

2. DevSecOps を適用するスコープが広すぎる

DevSecOps では、1. でお伝えした通り、複合的な観点からのアプローチが必要なため、考慮すべき事柄や実施するタスクが様々出てきます。そのため、いざ DevSecOps を進めてしていこうとした際に、そのスコープが広すぎると、数多くのシステムや大勢のステークホルダーを巻き込むことになり、実行計画も非常に複雑かつ長期的なものになります。また、前回の記事でご紹介した DevSecOps を支える要素の中に「全てのステークホルダーから DevSecOps の理念・推進の同意を得ること」という項目がありましたが、これはステークホルダーが多くなるほど困難になります。(というのも、初めて DevSecOps を進めていく場合は、ステークホルダーのほとんどが DevSecOps のことをよく理解していない状況と想定されるためです)

このような状況では、ステークホルダー全員が相当忍耐強くない限り、推進プロジェクトは頓挫してしまうでしょう。その原因としては、対象とするシステムやプロセスに DevSecOps の仕組みを導入しづらいということもありますが、むしろそれよりも、効果を実感できるまでに時間が掛かりすぎることで、モチベーションが続かず、言わば「途中で飽きてしまう」ことが挙げられます。

そうならないためには、「小さく始めて、少しずつ広げていく」こと、そして早い段階で「成功体験」を得ることが肝要です。ただ、目に付いたものを片っ端からやっていくというわけではありません。現在抱えている課題、システムの特性、チームの体制、メンバーのスキル状況等から、何であれば効果が上げやすいかを見極める必要があります。

ここで具体的に、とある情報システム部門において、自社運用しているシステム基盤に対して DevSecOps を適用するケースを考えてみましょう。なお、このチームの現在の課題、システム、チーム体制/スキルは、以下のようであるとします。

この場合、どこから手を付けるべきでしょうか？ 課題に着目すると、テクノロジーの観点では Infrastructure as Code (IaC) によるインフラ構築・運用の自動化が有効そうです。また、現在のシステム構成や今後の計画を鑑みると、IaC の仕組みが整えやすいクラウド環境から進めていくのが良いでしょう。

しかし、この状況では、まず先にやるべきことがあります。それは、チーム メンバー全員で DevSecOps の理念・取り組みを理解し合い、そしてメンバーからの賛同を得ることです。この部分が不十分だと、後々 DevSecOps の取り組みを一部のメンバーがやっている「よく分からないもの」と考え、「自分事」として捉えなくなります。(最悪の場合、変革に対する抵抗勢力になることもあります！)

今回のケースだと、(開発系・基盤系を問わず) チーム メンバー全員を招集したミーティングにて、DevSecOps の概要や今回の取り組みから説明し、DevSecOps がなぜ必要なのか、どういった点でメリットがあるのか、またどういった点で変化が生じ、リスクや影響があり得るのか等をディスカッションするところから始めます。その際、実際に動くものを見てみたいと思うメンバーもいるでしょうから、例えば IaC でインフラ構築作業がどのように自動化されるかを示す簡単なデモを見せるのが効果的かと思います。このようにステークホルダー全員で共通認識や納得感を持つことで、この先の DevSecOps の取り組みの継続や拡大が、格段にしやすくなります。

この後は、実際に IaC の導入を進めていくことになりますが、この時に力み過ぎて「既存のクラウド環境全てを IaC 化しよう」と考えないようにしましょう。なぜかと言うと、単純に結果を出せるまでに時間が掛かるからです。既存環境に手を加えるということは、稼働影響を与えないように注意深く行う必要がありますし、関係各所への調整事も多くなるでしょう。いきなりそういったことに神経と時間を使うよりは、ある程度の失敗や再試行が許容される環境 (例えば、稼働開始まで自由に手を加えられる新規構築の IaaS 環境) で始めるのが得策です。短期間で結果を出し、チーム メンバーに発表し、もらったフィードバックを基に洗練していくというサイクルを繰り返していくことで、直接関わっているメンバーだけでなく、他のメンバーもモチベーションを持ち続けることができます。このように小さな成功体験を 1 つ 1 つ積み重ねていくことが、DevSecOps を進めていく上でとても重要なポイントとなるので、常に意識するようにしましょう。

3. 「セキュリティに関することは、セキュリティ担当の仕事」だと思っている

DevSecOps では、開発担当者 (Dev)、セキュリティ担当者 (Sec)、運用担当者 (Ops) が協働してシステム開発・運用を行っていくことになりますが、これは、単にそれぞれの担当者やチームがそれぞれの仕事をするというわけではありません。開発担当者や運用担当者は、セキュリティのことを全てセキュリティ担当者にお任せするということではなく、セキュリティに関する責任はステークホルダー全員で共有し、一体となって対処する必要があるということになります。

これまでも、開発に関するセキュリティ対策 (例 : セキュアコーディング、アプリケーションの静的解析) は開発担当者が、運用に関するセキュリティ対策 (例 : OS のセキュリティパッチ適用、ID 情報の棚卸し) は運用担当者が行ったり等、開発担当者や運用担当者も何かしらのセキュリティ対応を行っており、全くセキュリティに関与していないということはほとんど無いかと思います。ただ、逆に言うとそれくらいの関わり方しかしていなかったとも言えます。

例えば、普段の開発・運用業務の中で行っているセキュリティ対応以外の部分でセキュリティの問題が発生した場合、それは誰が責任を持って対処すべきでしょうか？ 開発・運用担当者の立場からすれば、「それはセキュリティ担当者が対処すべきだ」と考えたくなるかもしれませんが、その発想自体とその発想に至ることになった既存のプロセスや体制に課題があります。DevSecOps の考え方では、それは開発・運用・セキュリティ担当者全員で対処すべき問題となります。問題の特定から、暫定対応、根本原因の調査と恒久対応、再発防止策の策定までを、ステークホルダー全員で検討・対処していく必要があります。これは、システム開発段階でも同様です。システム企画や設計の段階から、アプリケーション、プラットフォーム、オペレーション、ガバナンス等の様々な観点から、開発するシステムで発生し得る脅威やリスクをステークホルダー全員で洗い出し、それらの対処策を協議・決定していきます。

また、前回の記事で、DevSecOps の実現において組織観点で必要な要素として「実用的なセキュリティ/品質保証 (QA) 情報を、ソフトウェア ライフサイクル全体で各チームが自動的に利用でき、共同作業ができるようにすること」であるとご紹介しました。これを実現するためには、先に説明した協働的な問題解決のアプローチはもちろんのこと、アプリケーションやプラットフォーム等に関するセキュリティ情報を継続的に取得し、ダッシュボードで可視化するような仕組みも併せて構築する必要があります。

例えば、アプリケーションの脆弱性情報は SAST/DAST/IAST 等の解析ツールで、クラウド プラットフォーム設定の脆弱性や監査情報は CSPM/CWPP 等のツールで取得し、それをチャットツールに通知する、タスク管理ツールに自動登録するといった仕組みも良いですし、構成管理データベース (CMDB) に取り込んだ情報を基にリアルタイムに更新されるダッシュボードを作るのも良いと思います。

そうすることで、各担当者/チーム間での「ポテンヒット」を未然に防ぐことができますし、客観的かつリアルタイムなデータを基に適切な判断・対応を早期に行えるようになります。また、自身の担当領域以外の問題に対しても責任意識を持ちやすくなるため、「セキュリティは全員の責任」という考え方が段々とチームや組織全体に浸透していくことになるでしょう。

まとめ

今回は、いくつかのアンチパターンを例に DevSecOps を進めていく上で考慮すべきことをご紹介しました。ざっくりではありますが、今回の内容を以下にまとめさせていただきました。

1. 組織/プロセス/テクノロジー/ガバナンスの観点から、ステークホルダー全員で協働的にアプローチしていく。
2. 小さく始めて、少しずつ適用範囲を広げていく。成功体験の積み重ねが鍵。
3. ステークホルダー全員がセキュリティに責任を持ち、一体となって取り組んでいく。