近年の金融DXの進化により、生活者はあらゆる場面でその利便性を享受しています。
例えば、銀行が運営するスマホアプリを使って無料で自行間の送金を無料で行うことが出来ます。
このアプリケーションの裏側にはリアルタイムに金融システムに接続する仕組みが介在していて、適宜アプリケーションに追加あるいは更新のプログラムが実装できる仕組みを有しています。
これらはアジャイルという枠組みの開発モデルで動いていて、そのアジャイルと親和性の高い開発マネジメント形式を2007年頃に体系的に示したのがDevOpsモデルです。
更に2012年頃にセキュリティ脆弱性の早期発見の機能を取り入れたのがDevSecOpsモデルです。
概念
歴史
DevSecOpsは2012年に米国カーネギーメロン大学やIT企業に属する有志によって作られました。
DevSecOps Foundation創設者の一人だったシャノン・リーツ(Shannon Lietz)氏はその後、SONY、ServiceNow、Adobe Securityなどで堅牢なサービス構築に携わり、現在も自身の企業を経営しつつ複数の大企業のセキュリティ領域において多大な役割を担っています。DevSecOpsモデルが立ち上がった背景として、当時2012年にスマートフォンの利用台数がフューチャーフォン(俗にいうガラケー)を上回り、アプリケーション内のプログラム更新頻度が格段に増えたことがありました(これまでの月に数回といった頻度から一日に複数回行われるように)。
セキュリティ対策の活動を開発と同レベルで重要なものと捉え実行するニーズが高まっていた時期でした。
既存モデルとの違い
基幹システムや会計システムの開発の多くはウォーターフォールモデルという「RFPの合意⇒要件定義⇒基本設計⇒詳細設計⇒単体テスト⇒結合テスト⇒ローンチ⇒修正⇒システム安定化」と一つのステージを完遂させて次のステージに進むモデルが採用されています。一方で、外部環境の変化が激しく都度、サービスプロセスやUI変更のチューニングをする必要があるスマホアプリなどはアジャイル形式というモデルで一つ一つのモジュールの開発期間を短く区切って、変更が生じた際に影響のある個所を都度修正していきます。

このアジャイル開発と親和性が高い管理アプローチがDevOpsで、各モジュールが新規作成・変更が生じた際に影響を受ける周辺モジュールの対応が求められます。その際にデグレード(バージョン戻しなど)を求められるケースがあり、機能の利便性とセキュリティの堅牢性がトレードオフの関係になりがちです。DevSecOpsは上流工程からセキュリティ対策を組み込んでいくことで、これらのトレードオフを回避することを後押しします。

特徴
DevSecOpsモデルは上流の工程からセキュリティ対策を組み込んでいます。セキュリティリスクには様々な種類があります。Dos攻撃、なりすまし、改ざんといった外部の者による侵入や不正もあれば、本来は昇格させるべきでないユーザーを特権昇格させることで不正利用を招く、内部におけるガバナンス欠如が端緒となるものもあります。
上流工程から開発タスクと同等の体制でセキュリティ対策のタスク管理・実装を施すことで、新たに発生していくセキュリティリスクの予見と準備を可能にし、サービスがリスクを回避していくことが可能になります。
導入時の体制
DevSecOpsを主導するチームには既存のシステム開発プロジェクトにおける管理業務やセキュリティ対応・対策に携わるなど幅広い経験が必要です。開発工程のどのフェーズで対策を実装すべきか、あるいは特定箇所でどのような条件を満たした際に、セキュリティリスクが発生するかの予見が出来る深い見識が必要です。また、セキュリティ担当チーム内だけでなく、開発チームにおいても「DevSecOpsモデルを理解していて、やるべきことを理解している人材はいるのか?誰なのか?」を把握して相互に協力しながら取り組んでいく必要があります。
導入時のメリット
「DevSecOpsの導入に要するコスト≒期間」の考え方は以下の通りです。
DevSecOps | 開発工数 | Sec対策工数 | 合計 | 対応の堅確性 | Sec拡張性 |
導入 | 80h | 20h | 100h | 高い | 高い |
非導入 | 60h | 40h | 100h | やや属人的 | 低い |
また、ルールが可視化されていて周囲のセキュリティ活動に対する理解度が高まり、直接的な工数以外のメリットも享受できます。
主なアウトプット
各フェーズで得られるアウトプットは以下が主に挙げられます。フェーズ | アウトプット |
計画 | フローチャート、リスク管理書、潜在的脅威・緩和手順レポート |
開発 | テスト手順書、セキュリティ検知書 |
ビルド | 静的コードのスキャンレポート、脆弱性レポート |
テスト | 静的・動的コードの脆弱性レポート、推奨される緩和策 |
リリース | リリース可否の判断履歴、全レポジトリ内のデータ・コードファイル |
運用・監視 | 脆弱性アラート、コンプライアンス報告書 |
課題
DevSecOpsの課題、というよりもシステム全体における話しになりますが、セキュリティの取り組み自体は売上・利益を生まないことから優先度が低く、ついつい後回しになる取組にされがちです。
また、多数の機能が複雑に関わりあうソースコード間にセキュリティの役割が関わることで一層複雑になるため、高い実装スキルが求められます。
一方で、アプリケーション側に配置されるリソースはシステム・セキュリティに対する知見が充分で無い人材がアサインされることも少なくなく、セキュリティリスクへの能動的な気づきが充分でない場合はリスクになりえます。
例えば2024年に最もセキュリティ脆弱性の被害が大きかったSQLインジェクション、これはWebサイトに公開しているデータをエスケープ処理していないことでデータの改ざんや個人情報漏洩に繋がっています。
住宅メーカー | 登録していた会員・従業員約83万人分の個人情報が漏洩した可能性があると発表 |
地方自治体 | ふるさと納税特性サイトの利用者メールアドレス41万件以上の情報が漏洩したと発表 |
学習塾グループ | 資料請求や模試を申し込んだ顧客:約28人分のメールアドレスが漏洩 |
参照:https://owasp.org/www-community/attacks/SQL_Injection#
今後の流れ
サービスを提供する企業は適切なSIerの選定を行う必要があります。
また、システム・セキュリティの分野においては内製への体制移行が簡単ではない一方で、セキュリティに対する知識を持つリソースをクライアント内部に配置する必要があります。
体制が不充分である場合、セキュリティの脆弱性を抱えたままサービスが提供され、事故を未然に防げないリスクを抱えてしまいます。
DevSecOpsの必要性は今後も高まることが予想され、特に金融業においては個人情報保護の重要性が増していることも相まって一層重視されると考えられています。
開発チームのみセキュリティ知識を保有するのではなく、サービス運営チームにも適切な知識と対策タスクを実行するディレクション能力を持つリソースをアサインすることが求められています。
まとめ
IDグループではDevSecOpsの概念や特徴だけでなく、実際の開発・運用フェーズにおける実務においても適切に実装、管理を行いクライアントのサービスを堅確に運用、そのサポートをさせて頂いています。
貴社プロジェクトにおいてDevSecOpsを取り入れたい方は当社までお問い合わせください。
参考URL
https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsTools-ActivitiesGuidebook.pdfhttps://insights.sei.cmu.edu/continuous-deployment-capability/
https://www.devopsinstitute.com/the-history-of-devsecops/