ITセキュリティーに関連したホットトピックを取り上げ、動向や対策をひも解きます。今回は、最近話題に上ることも多い「DevSecOps」を解説します。
はじめに
まず、DevSecOpsとは何かを簡単に説明します。数多くある開発方法論の1つに、開発（Development）と運用（Operations）を密に連携し、プログラムのリリース頻度を高める「DevOps」があります。DevSecOpsは、このDevOpsにセキュリティー（Security）を融合させ、開発スピードを高めながら、セキュリティーを確保することを目指します。
DevOpsの実践例｜短い期間で何度もリリース
DevSecOpsが生まれた背景
なぜDevSecOpsが生まれてきたのでしょうか。インターネットの発展やデジタル化が進む中で、ビジネス上の要求を素早くシステムに反映することが求められ、短いサイクルでプロダクトをリリースする方法論が考え出されてきました。
しかし、開発部門とビジネス部門、サービスを安定して運用するためのメンバーなど、多くのステークホルダーがそれぞれの利害を主張することで、プロジェクトが円滑に進まないといった問題が見られました。
こうした問題を解決するために、全員が1つの目標を持ったチームとして開発・運用のプロセスすべてを担う、DevOpsという考え方が出てきました。ただし実際にDevOpsを開発プロジェクトに適用しようとしたとき、セキュリティー面で壁に突き当たりました。
従来の開発方法論を前提としたセキュリティールールやセキュリティーチェックが、DevOpsの考え方やスピード感とマッチしなかったのです。その結果、DevOpsの効果が出ない、もしくはDevOpsを取り入れることができないという課題が浮かび上がったのです。
従来型開発でのセキュリティー課題
従来のシステムの脆弱性を取り除く方法では、開発フェーズごとにそのフェーズの生成物を検査、確認し、一定のセキュリティーレベルを担保しているかを評価していました。代表例は、システムの構築が完了しリリースする直前にセキュリティーテストや脆弱性診断を数日～数週間かけて行うという作業です。
DevOpsは短いサイクルで何度もプログラムをリリースすることを目指しています。そのため、リリースのたびにシステムの外部から脆弱性があるかどうかを診断するのは現実的には不可能です。
一方で、従来のセキュリティー施策がマッチしないからといって、誰のチェックも入らない状態で、とにかく早くリリースすることのみを目指して開発するわけにはいきません。脆弱性が埋め込まれたままサービスが世間に公開される可能性があるからです。
DevOpsによって脆弱性の検知から改修、リリースまでを素早く行えるようになったからとはいえ、利用者の情報や資産を脅かしたとなれば、一度のセキュリティーインシデントでサービス自体が閉鎖に追い込まれてしまうおそれがあります。
そこで、DevOpsのプロセスの中に初めからセキュリティーを組み込み、チームのメンバー自身がセキュリティーについても責任を持って開発・運用を行うDevSecOpsが生まれたのです。
DevOpsやDevSecOpsという言葉を耳にするようになってから数年がたち、実際に取り組んだ事例やノウハウが表に出てくるようになってきました。
Gitlabが2023年に全世界の企業を調査したところ、全体の56％がDevOpsもしくはDevSecOpsの方法論を活用していると回答しています。数年前から少しずつ数値が増加しているので、DevOpsやDevSecOpsが徐々に浸透してきているといえます。
ただDevOpsは導入済みでも、DevSecOpsとなると十分に実践できていると自信を持って言えないという開発チームも多いのではないでしょうか。
実現のための3つのポイント
これまでDevSecOpsのプロセス構築を支援してきた経験から感じるのは、DevSecOpsを成功させるには1つのツールを入れればよいわけではないことです。文化やプロセス、ツールそれぞれの面からアプローチし、バランスよく組み立てていく必要があります。
DevSecOpsを実現するためのポイント｜3つの側面からプロジェクトを推進
文化
セキュリティーを開発や運用と同じように自分の関心事として捉え、チームメンバーが1つの方向を目指し、良いプロダクトを作るために進んでいくというチームの文化を作り上げる必要があります。
チームの中にセキュリティー担当者（セキュリティーチャンピオン）を置くことは良いプラクティスの一つです。ただし、あくまでもセキュリティーは全員の責任であり、セキュリティー担当者は自身が習得したセキュリティーの知識をチームに還元し、チームがセキュリティー施策を取り入れるのをサポートします。
大きな組織になるとセキュリティー専門の部署を用意している企業もあります。そのような部署とチームの橋渡しや会社のセキュリティー方針に従いつつ開発チームとして実行可能なルールや仕組みに落とし込んでいくのも、セキュリティー担当者に期待される役割です。
プロセス
リソース管理のルールや設計／コードレビュー、セキュリティーチェックが失敗したときはデプロイを中止する必要があります。そのために、CI（継続的インティグレーション）／CD（継続的デリバリー）の仕組みなど、開発プロセスの中にセキュリティーをうまく統合していくことが必要です。
また、サービス企画や全体のアーキテクチャー設計の段階からリスク分析を行い、リスクを最小限にするためにどのフェーズでどのような対策を行うか全体像を描いていきます。この際、開発するシステムに応じて必要なセキュリティー要件へ落とし込んでいきます。
一般に公開されているセキュリティーガイドラインなどを参考にしながら、プロジェクトで開発するシステム単位で要件を漏れなく洗い出します。より高度な技術領域、多数の組織・システムが複雑に関係するようなシステムの場合は、外部の専門家を入れて分析するのも有効です。
加えて、DevSecOpsを円滑かつ継続して実行していくためには、環境面やチームメンバーをサポートする体制についても検討するとよいでしょう。
技術（ツール）
さまざまなツールをプロジェクトや開発チームの特性に合わせて選択し、常に一定レベルの安全性が確保された状態を保つことを目指します。開発したアプリケーションを自動チェックするツールには、SAST（Static Application Security Testing）、DAST（Dynamic Application Security Testing）、IAST（Interactive Application Security Testing）などがあります。
また、インフラストラクチャーをオープンクラウドやコンテナを利用して構築しているのであれば、CSPM（Cloud Security Posture Management）やコンテナスキャンによるチェックが役に立ちます。運用フェーズにおいては、各種ログを解析し外部からの攻撃検知やアプリケーションの普段と違った振る舞いを検知する仕組みが必要です。
セキュリティー・バイ・デザイン
DevSecOpsというと、ツールやプラットフォームなどシステム面が注目されがちですが、システムを含むサービス全体のリスク分析や、設計レビュー、コードレビューといった、アナログなプロセスも必要になります。どんなに優れたツールを導入したとしても、すべての脆弱性が検知できるわけではなく、後続のフェーズに進むほど修正コストが大きくなるのは変わらないからです。
デジタル庁からも「政府情報システムにおけるセキュリティー・バイ・デザインガイドライン」が発行されていますが、この中でも「セキュリティーリスク分析」や「セキュリティー要件定義」といった、開発の最初期段階からセキュリティーを考慮してサービス設計・システム設計を行うことの重要性が説かれています。
ビジネスリスクを踏まえて最終的に判断するビジネス／リスクオーナー、セキュリティー対策の実施状況を評価するセキュリティーリスクアセッサー、実際にセキュリティー対策を実施・管理するシステム管理者といった役割をもった関係者が連携しながら、工程ごとにどのようなセキュリティー対策を取り入れていくべきかが書かれています。このガイドラインはどちらかというと従来のウォーターフォール型の開発スタイルを対象に書かれたものですが、アジャイル開発においても参考になります。
DevSecOpsというと、ツールやプラットフォームなどのシステム的な面が注目されがちですが、システムを含むサービス全体のリスク分析や、設計レビュー、コードレビューといった、基本的な従来の対応も必要になります。
DevSecOpsの導入例
筆者は普段、DevSecOpsやセキュリティー・バイ・デザインについてさまざまな形で支援していますが、好循環を作り出すことができた事例を紹介します。
支援チームの役割の例｜DevSecOpsの導入を支援
特定の業界向けのパッケージ製品を作成しているプロジェクトで、初期の方針としてDevOpsを採用することが決まっており、開発プロセスの中にソースコードのチェックツールを導入済みでした。
その開発プロセスの中に、既存の仕組みに加えて、その他ツール（DAST、IAST）や設計時のセキュリティーレビューを組み込みました。その結果、リリース直前の脆弱性検査で検出された項目は、事前のセキュリティーレビューとDASTのチェックで既に検出されていたものでした。プロジェクト内部の切り分けとしてリスクがほとんどないことを確認済みであったため、あわてることなくリリースを迎えることができました。
さらに当初それほど予想されていなかった効果として、開発サイクルが回ってセキュリティーレビューやツールのチェックを重ねることで、開発担当者がチェックすべきポイントを理解し、事前に先回りできるようになったことが挙げられます。
初回のセキュリティーレビュー時には「どのような情報を用意すればよいのか」すら分からないというような状況でした。それが、企画や設計の早い段階で議論になりそうな部分を見つけ、事前にセキュリティー部門へ相談するということがなされるようになりました。
ここで紹介した事例のように、DevSecOpsへの取り組み方として、既にあるDevOpsのプロセスに対して導入しやすいツールや仕組みから順次取り入れていくという手法がよく使われます。ただし、その前提としてプロジェクトのリスクを分析し、いずれかもしくは複数のフェーズで対策が行われていることを確認しておくのが重要です。
そういった、セキュリティー対策の取捨選択を開発チームが行い、サービスやプロダクトのデザインの段階でセキュリティーを組み込んでいくためには、担当者それぞれがセキュリティーを含めてプロダクトを成功に導くために考えるという姿勢が必要です。
最新の攻撃動向やセキュリティー知識、各種製品の知識等は範囲も広く1つの開発チームのみでカバーするのが難しい状況も考えられるので、社内のセキュリティー部署や外部ベンダーなどもうまく活用しながら、チーム全員が1つの目標に向かって、開発・運用・セキュリティーに取り組むための方法を探っていくとよいでしょう。
※「日経コンピュータ」2023年5月25日号より、一部加筆の上、転載。
https://xtech.nikkei.com/atcl/nxt/mag/nc/18/012300337/051500005/
日経BPの了承を得て転載／無断転載・複製を禁じます。
