SBTのスベテ

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

湯下 達郎

はじめまして、SBテクノロジーの湯下です!

早速ですが、皆さんは「DevSecOps」という用語をご存知でしょうか?

その語感から、DevOps にセキュリティの要素を組み込んだもの、というイメージは湧くものの、何となく捉えどころが無く、具体的にどんなことをすれば良いのかが分かりづらい用語かと思います。そのため、この記事では、複数回にわたって、DevSecOps が何であるか、なぜ DevSecOps が重要であるか、DevSecOps を進めていく上で考慮すべきことなどを説明していきます。

現在、連載内容として下記のテーマを予定しており、技術的な内容以外もご紹介していきます。

  • vol.1 DevSecOps の必要性とそれを支える要素
  • vol.2 DevSecOps を進めていく上で考慮すべきこと
  • vol.3 システム アーキテクチャと技術的なアプローチの具体例
  • vol.4 DevSecOps を実現するために、組織文化やプロセス、ガバナンスはどうあるべきか

ともすると、DevSecOps は、技術的に尖った Web サービス企業の BtoC 向けシステムのような、特定のシステムだけに適用できるような代物で、エンタープライズ システムには時期尚早のように思えるかもしれません。また、後ほどご紹介する DevSecOps の要素には、コンテナ、IaC、CI/CD ツール等の最近の技術要素が含まれており、この記事をお読み頂いている方々の中には「自分たちはまだコンテナを使っていないから、関係ないテーマだな」と思われる方がいらっしゃるかもしれません。

しかし、DevSecOps においては、これらの技術要素は全体の一部分でしかなく、その他の要素である「組織文化」「プロセス」「ガバナンス」も同等に重要となります。どのようなシステムであっても、それを作り、支え、改善していくのは人・組織であり、そしてセキュリティはより一層重要になっていきます。DevSecOps では、技術的なアプローチだけでなく、組織文化、プロセス、ガバナンスといった観点からも、システム開発・運用をセキュアに行っていくための考え方や方法論を提供してくれます。そのため、DevSecOps は、特定のシステムや現場に限定されるものではなく幅広く活用できるものと、私は考えています。従って、本連載は、DevSecOps の技術要素やアーキテクチャを知りたいエンジニア層の方だけでなく、DevSecOps を進める上での組織面での課題とアプローチを知りたい、既存システムに DevSecOps のプラクティスを適用したいと考えているマネジメント層の方にもお役立ていただけるかと思います。




DevSecOps という用語について

まず、DevSecOps の意味について説明します。この記事の冒頭でも少し触れたように、DevSecOps は、DevOps にセキュリティの要素を加えた概念・方法論であり、システム開発・運用の全ての工程にセキュリティが組み込まれているべきである、という発想から生まれています。

しかし、「システム開発・運用にセキュリティが組み込まれているべき」という考え方は、至極当然のことのように思えますが、なぜ今 DevSecOps が注目されているのでしょうか?

DevSecOps が何を目指しているのか、どうして従来の方法ではいけないのかという点を、次のセクションでもう少し深掘りしてみましょう。



DevSecOps の必要性

DevSecOps の必要性を説明する前に、DevSecOps の主なメリットを以下に記載します。

  • 従来の方法と比べて、セキュリティの問題に早く気付きやすく、セキュリティ リスクを抑制しやすい
  • 中長期的に見ると、セキュリティの問題に対処するためのコストを低く抑えやすい

それでは、どういう理由によって、これらのメリットが生まれるのでしょうか?

例えば、この記事をお読みいただいている方々の中には、以下のような話を、どこかで見聞きしたり経験したことがある方がいらっしゃるかもしれません。

  • システム リリース前の脆弱性診断で、たくさん設計・実装上の問題が見つかって、急いで修正対応・再テストを行った
  • 本番運用中のサーバーの設定を手動で管理しているが、ミドルウェアの脆弱性問題が出た際に、大量のサーバーに 1 台ずつログインして、バージョンの調査・アップデート・テストを行った
  • 管理しているクラウド リソース (仮想マシン等) が大量にあるが、どのリソースに対してどのような設定をしているかを正確に把握できていないため、いつかセキュリティ インシデントが起きるのでは、と不安に思っている

上記のようなことは、従来であれば (システムの特性や規模にも依りますが) 一時的に人的リソースを投入すれば対応できたケースも少なからずあったのではないかと思います。しかし、ニーズの多様化が進み、また環境・情勢の変化が激しい昨今では、それらの状況に合わせて日々システムの機能追加や構成変更を行うことがこれまで以上に必要となっています。そのため、これからのシステムにおいては、従来のように毎回人的リソースを投入して "頑張る" のには限界があるように思います。

また、「Shift Left」という言葉も近年注目されていますが、これは、システム開発・運用の一連の工程で発生する問題 (アプリケーションの不具合、脆弱性等) は後の工程になればなるほど、その修復に多大なコストがかかるので、出来るだけ早い段階でそれらの問題を解消する、あるいは将来的に回避できるように対応することを指しています。*1

*1 : DevOps Research and Assessment (DORA) のレポート (2016 State of DevOps Report)  の 4 章に Shift Left に関する調査が記載されており、ここでは Shift Left のアプローチを採用したパフォーマンスの高い開発チームが、そうでない開発チームよりも、アプリケーションのセキュリティ修正にかける時間が 50 % も少ないことが示されています。

例えば、アプリケーションの脆弱性診断に関して言えば、前述したシステム リリースの直前に実施するケース以外にも、システム リリース後は半年に一度のメジャー アップデートの時だけ実施する、あるいは、自社のセキュリティ規程に則って年一回実施するといったケースは、現在でも多くあるのではないでしょうか。アプリケーションの機能追加やシステムの構成変更の頻度が少ない場合は、このような方法でも問題ない場合もあるかと思いますが、ソフトウェアそのものがビジネスの中心になっていくと言われている将来では、アプリケーションの機能追加やシステムの構成変更が日常的に行われていくものと思います。その際に、Shift Left のアプローチを取らなければ、アプリケーションやシステムの品質やセキュリティを担保するために多大なコストをかけたり、リリース時期を後ろ倒しにしたり、いわば無理をした形でシステム開発・運用を行っていくことになり、ビジネスの発展の足枷になってしまいます。

DevSecOps が目指すものは、DevOps と同様に、開発チームと運用チームが協働することで、より高効率・高品質・低コストにシステム開発・運用を行い、継続的にビジネスを発展させていくことです。そして、セキュリティの脅威が日々増えていく昨今では、従来通りの方法ではビジネスの発展とセキュリティの担保を両立することが難しいため、システム開発・運用のあらゆる工程でセキュリティ対応を組み込んでいく必要があるのです。



DevSecOps を支える要素

ここまでの説明で、DevSecOps がなぜ必要とされているかについて、ご理解いただけたかと思います。それでは、このセクションでは DevSecOps を支える要素についてご紹介します。

現時点では、リファレンスとなる文献がまだまだ少ない状況ですが、米国の国防総省が公開している DevSecOps に関するホワイトペーパー (DoD Enterprise DevSecOps Reference Design)  の内容が参考になるかと思いますので、以下に抜粋します。(原文が英語のため、日本語に意訳しています)

左右にスクロールしてご覧ください。

要素 含まれるもの
組織
  • 組織文化を変えて、開発・セキュリティ・運用を包括的に捉えて、責任を共有すること
  • 全てのステークホルダーから DevSecOps の理念・推進の同意を得ること
  • 組織のサイロを破壊し、チーム間のコミュニケーションとコラボレーションの強化すること
  • 実用的なセキュリティ/品質保証 (QA) 情報を、ソフトウェア ライフサイクル全体で各チームが自動的に利用でき、共同作業ができるようにすること
  • 良い事象と悪い事象を組織全体で共有し、心理的安全性のある文化を作ること
  • 成功と失敗から学習することで、システム設計の改善・実装の強化・インシデント対応能力の強化を行う
  • 管理を容易にし、変更の範囲を限定するために、小刻みな変更を多くする
  • フィードバックとユーザー主導の変更を受け入れて、新しい要件に対応する
  • 継続的なコード リファクタリングの計画と予算を立てることで、技術的負債の継続的なバイダウンを行う
プロセス
  • チーム全体による協働的な設計
  • テスト駆動開発
  • テクノロジーやツールを駆使した各種プロセスの自動化
  • 反復的なループによる継続的な改善
テクノロジー
  • 各種ツールの適用
  • ソフトウェア ライフサイクルの自動化
  • 運用プロセス/セキュリティ プロセスのオーケストレーション
  • クラウド/コンテナ技術の活用
  • Infrastructure as Code (インフラ環境のコード化による構築・管理の自動化)
  • Security as Code (セキュリティ ポリシーのコード化によるコンプライアンス チェックや監査の自動化)
ガバナンス
  • 組み込みのガバナンス制御を行うこと
  • 統一されたポリシーを強制すること
  • データ駆動型のリスク評価・管理を行うこと
  • ガバナンスの視認性を向上させること
  • 継続的なガバナンス活動を行い、認定 (またはそれに相当する望ましい状態) を維持すること

上表からも分かる通り、DevSecOps はどれか 1 つの要素だけで実現できるものではなく、組織 / プロセス / テクノロジー / ガバナンスといった複合的な観点からアプローチしていく必要があります。DevOps 導入の文脈でよく言われる「DevOps はツールだけで実現できるものでは無い」という話は、DevSecOps でも同様となります。例えば、継続的インテグレーション/継続的デリバリー (CI/CD) のパイプラインに組み込んで脆弱性スキャンを自動的に行うツールが様々なベンダーから提供されつつあり、これを導入することで一定の効果が望めるものと思います。しかし、より効果を上げていくためには、ツールの導入以外に、アプリケーションの設計・実装・テスト手法といった開発プロセスの見直し、開発チームと運用チーム間でのコミュニケーションの方法、セキュリティ対応基準の見直しや脆弱性の管理・対応フローの整備等も行っていくことが肝要です。



まとめ

今回は、DevSecOps が必要とされる背景とそれを支える要素について説明させていただきました。DevSecOps の理念は、昨今のビジネス状況にマッチした理に適ったものであることをご理解いただけたかと思いますが、いざ実際に DevSecOps を進めていこうとすると一筋縄ではいかない点が数多く出てきます。次回では、DevSecOps を進めていく上で考慮すべき事柄について、具体例を織り交ぜながらご紹介したいと思います。

ここまでお読みいただきありがとうございました!

関連ページ

Microsoft Azure 導入・運用支援サービス

【総合】お問い合わせ

製品・サービスに関するお問い合わせはお気軽にご相談ください

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録