目次

• DevSecOpsとは
• 開発×セキュリティ
• 運用×セキュリティ
• まとめ

DevSecOpsとは

DevSecOpsとは、情報システムにおいて、「開発（Dev）」と「運用（Ops）」が密に連携し、かつ「セキュリティ（Sec）」を高い状態に保つことを指します。

図1：DevSecOpsとは

現代において「セキュリティ」を高い状態に保つためには、高い志に基づく高い適応力が肝心です。
「開発」×「運用」についてのポイントは他の記事に譲るとして、本記事では「開発×セキュリティ」と「運用×セキュリティ」の二軸に分解してポイントを解説します。

開発×セキュリティ

開発×セキュリティは、「安全な開発環境、安全な開発方法で、安全な成果物を作ること」と言い換えることができます。
安全な開発環境とは、例えばゼロトラストな思想で構築された開発端末と開発サーバ群を指します。
安全な開発方法とは、例えばソースコードのマージフローなどの開発プロセスが安全であることを指します。
安全な成果物とは、そのままの意味で、出来上がったシステムが安全であることを指します。

安全な開発環境

開発環境の観点では、自分たちで作りこむ部分以外にも様々なSaaSが組み合わせて使用されます。
これらのSaaSのアカウントを「統合」した上で「常に確認する」仕組みを構築することが肝心です。
言い換えれば、どこでユーザ情報を管理し、どのようにその情報を配布し、どのように認証連携を行うかが重要です。これらを正しく設計したうえで、MDM（Mobile Device Management）などを利用してユーザやデバイスが正当な状態にあるか、常に確認するように構築することで、安全かつ効率的な開発環境にすることができます。
一つ一つのプロジェクトでこれらを一から準備することは難しいため、社内インフラとしてこれらが共通的に準備することが望ましいと考えます。

安全な開発プロセス

開発プロセスの観点では、開発リソース効率重視の時代から、開発フロー効率重視の時代へとシフトチェンジが起きました。
それにより、レビュアーなど有識者にどう余力を持たせるかというボトルネックの解消がより重要になりました。
有識者による確認は質の向上に有効な一方、有識者に対するニーズはますます高まっており、有識者を確保することは日増しに難しくなっています。
有識者が確認しなければならない観点をいかに減らし、確認しやすくするかが、フロー効率を考える上でとても重要です。具体的には、自動化できるところは可能な限り自動化し、必要な情報は集約し、人手にできるだけ頼らない品質確保を行う必要があります。

また、重要な思想として多層化というものがあります。簡単に言うと、人間の行動には必ず穴があるので、一つの手段で完璧な保護や完璧な報告は望めないということです。これはセキュリティ製品を組み合わせて多層的に防御しろということだけを指しているだけでなく、専門家や専門ツールによるレビューや診断にも穴があることも意味しています。開発プロセスがフロー効率重視に変化し、不確実性を受け入れていく方向になった以上、セキュリティについても不確実性を受け入れて、防御面でもプロセス面でも多層的に取り組んでいくことがますます重要であるということです。

安全な成果物

開発成果物の観点では、他システムとの接続が当たり前になったことが昨今の大きな変化です。
現代では、システムは単体で成り立つものではなく、様々なOSSやSaaSを利用したり、API連携を行うことが当たり前であるため、サプライチェーンが複雑化しており、システム全体を統制することが難しくなっています。
これまでは、発現しない脆弱性である脆弱性の種は、見つかったとしても直ちに問題がないとして見過ごされてきました。
時代変化と共に不確実性が高まり、脆弱性の種は、自分たち以外の状況の変化によって、いつどんな形で緊急性の高い脆弱性として花開いてしまうか、読めなくなってきています。脆弱性の種は後々雪だるま式に大きくなり、圧倒的な進捗阻害要因となり得ます。
今では優秀な自動化ツールが増えてきており、比較的低い作業コストで脆弱性や脆弱性の種が見つかるようになってきています。これらをうまく利用し、見つかったのが種であってもビルドパイプラインを異常終了させるなどの設定を施すことで、無視できない仕組みの構築し、小さなうちに残らず潰すことを推奨します。

また、システムのセキュリティ品質を高めるためには、セキュリティ設計書を書く、SAST（Static Application Security Testing）/DAST（Dynamic Application Security Testing）/IAST（Interactive Application Security Testing）/エージェント型脆弱性管理ツールなどを導入する、セキュリティ診断を受診するといった、今では当たり前の対策だけでなく、修正の影響を確かめるためのテストコードの充実もとても重要です。そのため、TDD（Test-Driven Development）/BDD（Behavior Driven Development）の実施などDevOpsで推奨されている事項を着実に行うことをお勧めします。

図2：開発×セキュリティのポイント

運用×セキュリティ

運用×セキュリティの最大の目的は、安全なシステムを提供し続けることです。
日々、システムはデベロッパーの掌握圏外で複雑化し、脆弱性に対する外部からの攻撃は激化・高度化し続けています。
IT業界の冗談で、「何もしないのに壊れた」という発言を揶揄するものを時折耳にしますが、「何もしないと壊れる」のがセキュリティです。
現代のITシーンでは、何もしないということは現状維持ではありません。目にもとまらぬ勢いで川下に流されている状態を指します。

安全なシステムを提供し続けるためには、CSF（NIST サイバーセキュリティフレームワーク）などのフレームワークを参考に設計されたセキュリティ運用が重要であることは言うまでもありませんが、ここでは悩みの代表例として、セキュリティパッチ適用について考えてみます。

いざ、セキュリティパッチ適用をしようとした時に困るのは、以下のようなことではないでしょうか。

1点目は、エージェント型の脆弱性スキャナやSCA（Software Composition Analysis）/SBOM（Software Bill Of Materials）を導入することと、最低限必要なセキュリティパッチを見極めるという思想を捨て全てのセキュリティパッチを適用するという思想に変えることによって大きく改善できます。これにより人間による判断が排除でき、作業負荷の大きな改善が見込めます。

解決が難しいのは2点目です。セキュリティパッチの適用を含む多くのセキュリティ改善作業によって引き起こされ得る問題は、インテグレーションテストやシステムテストでしか見つかりません。一般的にインテグレーションテストやシステムテストのテスト項目は設計や要件から作るものですが、これらの改善作業には要件の変更を含まれないため、テスト項目が非常に考えづらいのです。

この問題に対応するポイントは二つあります。

一つ目のポイントは、ユニットテストだけでなくインテグレーションテストやシステムテストを自動化し、回帰テストとして行える範囲を拡大することです。
これまでの開発や運用で行われたインテグレーションテストやシステムテストのうち、主要機能の正常系だけでも必要なたびに再実施できたら安心できないでしょうか。その際はテスト走行部分だけでなく、テストデータのセットアップまで自動化しておくことで、多くのインテグレーションテストやシステムテストについても冪等性を保って自動化可能です。
もちろん、すべてのインテグレーションテストやシステムテストが自動化できるものではありませんし、それを目指してしまうとアジリティが落ちてしまいますので、リスクを分析し許容が適切な場合はそうすることも必要です。

もう一つのポイントは、緊急対応を除き、寝かせる期間を設けることです。例えば、商用環境にパッチ適用する2週間から1カ月ほど前にステージング環境にパッチ適用しておき、その環境上でアプリ担当や発注元企業様に日々のテストを実施していただくことで、総合的に安全性の確度を向上することが可能です。それでも不安な場合は、カナリアリリースという商用環境の一部だけ先に適用する手段を用いることで、より安心することが可能です。これらは、マシンイメージとして適用済みのOSを配布する方法や、スナップショットリポジトリを使用する方法などで容易に実現可能です。

これらの考え方や方法を用いることで、非機能系の改善作業と、アプリケーション開発作業が比較的疎結合になります。結果としてセキュリティパッチ適用についても高サイクルで実施できるようになりますし、副次効果としてリファクタリングなどの保守作業も安心して行えるようになります。

図3：運用×セキュリティのポイント

まとめ

これまでご説明してきた通り、安全なサイクルで安全なシステムを提供し続けるためには、以下の5点が重要です。

このように、反復性や継続性を確保する、逆に言えば反復性や継続性を妨げる要素を極力廃することで、安全な開発プロセスを実現できることになると考えます。
本記事が、皆様のシステム安定運用においてご参考になれば幸いです。