CloudNative Security Conference 2022から、アクセンチュア株式会社のセキュリティエンジニアである田原聖也氏が行ったセッションを紹介する。「なぜあなたのプロジェクトのDevSecOpsは形骸化するのか」というタイトルで、田原氏が実際に経験したプロジェクトの知見を紹介する内容となっている。
セッションを担当したアクセンチュアの田原氏
開発から運用までを一体化するDevOpsのプロセスの中にセキュリティを向上させるためのプロセスを入れるDevSecOpsは、早い段階で開発するソフトウェアをセキュアにしようという発想を技術面だけに限らず、人とプロセスに注目していることがポイントだ。
このセッションの目的をアンチパターンで紹介
ここではアンチパターンとして「こんなことが起こっていませんか？」と問い掛けている。特に「DevSecOpsを謳っている製品を導入したが、結局誰も使っていない」という辺りは、コンサルティングを提供している会社ならではの悩みが滲み出ているように思える。
DevSecOpsは開発の妨げになってはいけないことを強調
田原氏は本来のDevSecOpsの目的を「デベロッパーと運用チームが持っている開発から運用開始までのスピードを落とさずにセキュアなソフトウェアを開発すること」とした。要件定義からコーディング、保守運用のプロセスを回すことが必要で、そのためにはCI/CDパイプラインの一部として実装されること、コーディングにおいてはIDEを使用してツールの機能でセキュアなコードを生成するべきだと解説した。ここでのポイントは従来のデベロッパー、運用の業務を邪魔しないことだと説明した。
プロセスの中に組み込まれるべきDevSecOpsの要件
その上で、ツールやサービスなどの技術的な側面だけではDevSecOpsは実現できないと解説する。実際の失敗例として技術面の比重が高まってしまい、プロセスの改善や人材への投資、教育などが疎かになってしまうことによって形骸化が進んでしまうことを解説した。
人やプロセスに重点を置かないプロジェクトは形骸化しがち
その上で導入そのものを目的としないDevSecOpsを実現するためには、人とプロセスを整備した上で技術的な部分に投資を行うべきだと説明した。
技術よりも人とプロセスに重点を置くことでDevSecOpsが実現できる
ここで言う「人」とは、セキュリティ担当者を決めて丸投げすることではない。田原氏は、システムに関わるすべての人員が、セキュリティを高めることを目標としてセキュリティ対策の実施などを行うべきであると説明。ここでは経済産業省の指針をベースにして「プラス・セキュリティ」が必要となることを説明した。
専門家に依存せずにすべての人員がセキュリティを意識することが必要
またITシステムのライフサイクルの初期、つまり設計の段階で専門的なセキュリティに関する知識が必要になることは必然だとした上で、開発フェーズ、運用フェーズにおいては各部門がセキュリティを実現する業務を担当する分担体制が望ましいと説明した。
セキュリティチームの分担を徐々に軽くしていく体制が必要
プロセスに関しては、自動化、ゲート化、文書化が要点であると解説した。
プロセスの改善には自動化、ゲート化、文書化が必要
ここから自動化、ゲート化、文書化についてそれぞれ説明を行った。
自動化のための施策例
自動化については赤字で書かれた施策について簡単に説明を行い、さまざまな部分で自動化が可能だが、自動化できない部分に属人化しているプロセスがないかも要チェックだろう。テストを自動で行ってパスしたとしても、本番環境にデプロイするためには事業部長のハンコが必要などという状況では意味がない。またセキュリティの実装をソフトウェア開発の早い段階から行うシフトレフトについても説明。シフトレフトすることでセキュリティインシデントが発生した場合の影響範囲を狭めることができ、効果的だと説明した。
ゲート化についても簡単に説明
ゲート化については開発フェーズが進む段階で解析やテストの結果から、次に行けるかどうかを判断するという例を紹介した。ただ、どのようなパラメータやチェック項目を使うべきかという辺りの具体的な説明はなく、あくまでも推奨する検討項目という扱いであったことが残念だ。
文書化についてはGoogleのDevOpsレポートを引用して説明
文書化についてはGoogleの例を使って、文書の品質が高いチームはセキュリティ対策を実装する可能性が高い、信頼性に関する目標を達成する可能性が高いなどと語った。
文章化についてはツールの使い方以外にもあらゆる情報を文書化すること
文書化ではツールの使い方や手順などのマニュアル類だけではなく、背景や経緯、参考文献なども網羅して文書として残すことが必要だと説明した。また文書は検索の対象となることを想定して検索できるフォーマットやツールを選定することを推奨している。
技術的な部分についても定期的な見直しを推奨
技術的な部分では、ツール選定など日進月歩の進化をしているIT業界では常に見直しを行っていくことが重要だと指摘。ここでもプロジェクトに関わっているエンジニアらしい視点が現われている。
ここからはツールの紹介
ここからは開発から運用のフェーズにおいてDevSecOpsに使えるツールを駆け足で紹介する内容となった。
自身の経験を踏まえたツール解説を実施
コーディング、ビルド、テスト、デプロイ、保守・運用についてそれぞれツールを紹介した。田原氏自身の経験から出てきていると思われるツールの評価などはリアルな声として参考になるだろう。
デプロイフェーズのツールを紹介
ここではAWS ConfigとAmazon Inspectorを紹介。パブリッククラウドについては冒頭でAWSのセキュリティスペシャリストであると自己紹介を行っていただけあり、AWSについて深い知識を持っていることがわかる。
まとめ。技術よりも人とプロセスを整備することが先
最後にまとめとして、「技術よりも人とプロセスを優先してDevSecOpsに取り組むべき」としてプレゼンテーションを終えた。
プレゼンテーション前半のプロセスの改善と文書化をツールの選定に優先して行うべきだという指摘は重要だが、半面、後半のプレゼンテーションではツールの紹介が中心であり、前半の内容の詳細を期待していたために食い足りなさが残った。
「技術よりも人とプロセスに重点を置くべき」と強調しているが、ゲート化の具体例、アンチパターン、文書化に推奨するツールやサービスなどがプレゼンテーションにないままとなっているのは非常に残念である。文書化についてプレゼンテーションの中で触れていないのはなぜか？ などの質問を田原氏に送ったところ、丁寧な回答をいただいた。以下にその質疑応答を紹介する。
質問と回答
Q1：冒頭で強調されている文書化について、後半のツールの紹介の部分では文書化するツールの紹介や方法論について言及がないのはどういう意図か？
A1：ツールに関してはセキュリティに直接関連するもののみにとどめています。指摘いただいた文書関連のツールを紹介しだすと、ではCI/CD製品はどうするか、チケット管理はどうするか、とどんどん発散してしまうかと思います。方法論に関しましても、DevSecOpsからどんどん脇道にそれてしまう懸念があり、含めておりません。
Q2：シフトレフトとも関係するがゲート化について開発当初から仕組みとして組み込むことを推奨となっている。しかし開発から運用までのプロセス設計の段階でチェックポイントやその閾値を開発前に設定するのは難しいのでは？
A2：おっしゃるとおり、初めてシステム開発をする会社・メンバーが、開発前に「ゲート化はどうしよう」と議論することは非常に難しいと思います。企業によってはシステム開発ガイドラインの一部としてDevSecOps、ゲート化に関する標準を事前に定めていることが多いです。現実問題として、開発・運用をして、振り返りをしながら、「ここがダメだった、次はこうしよう」と標準を定めていくこともあります。ただ、それを各企業がバラバラにやるのは非常に大変だと思いますので、我々のようなコンサルタント・エンジニアにご相談いただければ、他社事例を含めた具体的なアプローチを作っていくことができます。
Q3：ゲート化の前にそのアプリケーションの種類に応じたセキュリティポリシーを作るというフェーズが必要だと思われるが、セキュリティポリシーはSLO/SLAの一部としてすでに存在することが前提か？
A3：セキュリティポリシー作成は、DevSecOpsに限らずシステム構築一般で当然実施する工程ですので、スライドP.6等には含めておりません。セキュリティ施策全量は膨大であるため、講演ではDevSecOpsに直接関連するものに留めております。
Q4：ソフトウェア開発が外注化されているような場合、例えば設計はコンサル会社、開発は外部のソフトウェア開発会社、運用は顧客というような状況で、ここで提案されているような自動化やシフトレフトはそもそも可能か？ まず外注化を止めてインハウスで開発するという構造的な変革が前提という発想か？
A4：可能です。私自身の経験として、例として挙げていただいたような形態での開発においてDevSecOpsを適切に運用した経験がございます。ただし、その際に重要になることは、（例で言うところの）顧客が積極的にDevSecOpsを推進するという心がけと行動になります。
設計や開発のベンダーが「DevSecOpsやります」といっても、DevSecOpsはシステムに関わる全フェーズの話なので、そのベンダーが担当外のフェーズでDevSecOpsができていないと、破綻するケースがほとんどです。顧客側がシステムに関わるベンダーに対して一貫したポリシーを提示し、遵守させることが重要です。
ただし、顧客だけでDevSecOpsをゼロから考えることはかなりハードルが高いと思いますので、我々のようなコンサルタント・エンジニアに構想立案から実装まで協力してもらう、というケースはよくあります。
真摯に質問に答えてくれた田原氏に感謝したい。