DevOpsとSecは同じ夢を見るか？：セキュリティ・アディッショナルタイム（5）（1/2 ページ）

米国で開催されたRSA Conference 2016では、開発・運用とセキュリティ担当者の距離を縮め、「セキュアでビジネスニーズに合ったサービスを素早く提供する」という共通の目的を達成するためのキーワード「DevSecOps」に関連するセッションが多数行われた。

[高橋睦美，＠IT]

　開発（Development）と運用（Operations）が協力し、ビジネスの要請に合ったシステム開発をスピーディに進めていく「DevOps」の潮流は、継続的インテグレーション／継続的デリバリといった取り組みとも相まって、スタートアップ企業だけでなくエンタープライズ企業にまで浸透しつつある。

　DevOpsは、対立しがちだったDevとOpsが一つのチームとなり、共通のゴールを目指すための取り組みだ。だが、まだ蚊帳の外に置かれている存在がある。それがセキュリティ担当者だ。

　リリース直前の検査であれやこれやと脆弱性を指摘し、修正を余儀なくさせるセキュリティ担当者は、開発、運用双方から煙たがられがちだ。だが、開発プロセスの中にセキュリティ検査を組み込み、短いサイクルで修正とリリースを繰り返せば、コードの品質のみならずセキュリティ品質も高め、手戻りを減らすことができる。これによって、セキュリティ技術者も同じチームの一員として、迅速かつ柔軟なシステム開発に寄与できるのではないか。

　そんなコンセプトの実現を目指し、米国で注目を集めているキーワードが「DevSecOps」（あるいは「Rugged DevOps」）であり、「Security as a Code」だ。このキーワードは、Webアプリケーションセキュリティにフォーカスしたセキュリティカンファレンス「OWASP AppSec」でも注目を集めていたという。

　この流れを受け、米国で開催されたRSA Conference 2016では、カンファレンス内イベントとして「DevOps Connect」が実施された他、複数の専門セッションにおいても「DevSecOps」が言及され、そのメリットと実現のコツが紹介された。

RSA Conference 2016のカンファレンス内イベント「DevOps Connect」

「より迅速に」と「より安全に」の両立を

　これまでシステム開発は、サービスに必要な機能を満たし、いち早くリリースを実現することに力が注がれてきた。もちろんそれらは重要だが、同時に相次ぐ情報漏えい被害などを背景に、脆弱性を作り込まず、攻撃者に付け入る隙を与えないセキュリティ要件の必要性も高まっている。

　DevOps Connectの中で行われた「The Journey to DevSecOps」と題するプレゼンテーションの中で、米インテュイットのDevOps/Red Team担当、シャノン・リーツ（Shannon Lietz）氏は「セキュリティの向上はビジネス上の要請の一部になっているが、DevOpsのフィードバックループにはセキュリティというリンクが欠けている。これが攻撃者を利することになっている」と指摘。「DevOpsのチームをセキュリティ専門家が支援し、攻撃方法や対策に関する知見を提供し、継続的なテストと改善のプロセスにセキュリティを組み入れることで、自社のサービスやシステムをセキュアなものにしていける」と語った。

　米データログのCSO、アンドリュー・ベシェラー（Andrew Becherer）氏は「継続的リリースの中にセキュリティを組み入れるなんて恐ろしい、という声も聞くが、実際にはその反対だ。『より迅速に』と『より安全に』を両立できる。アジャイル開発や継続的デリバリには、『（通常のリリースサイクルから外れた）例外的なパッチ』という概念はないため、迅速に問題を特定して修正できる」と述べている。

　もちろんこれまでも、マイクロソフトが提唱する「セキュリティ開発ライフサイクル」（SDL）のように、設計など開発の初期段階からセキュリティを取り入れるセキュアコーディングの試みがさまざまな主体によって進められてきた。ソフトウェア修正に要するコストや手間は、開発下流の工程になればなるほどかさむ。それを避け、セキュリティ面も含めて品質の高いコードを実現するには、なるべく上流段階からセキュリティを考慮しようというわけだ。

　DevSecOpsはそこからさらに一歩進み、継続的な開発サイクルの中にセキュリティに関するフィードバックを組み入れようという考え方だ。

　セキュアコーディングも重要だが、どちらかというとシュリンクラップ型のソフトウェアに適したもの。これに対しWebアプリやスマートフォンアプリのように、環境の変化や顧客のニーズに合わせて迅速に開発し、一日に何度もコードをリリースする環境ならば、その中にセキュリティ要件に関するテストケースを組み入れ、数時間、数十分というサイクルで脆弱性をつぶしていくという流れは自然に思える。コードを書き、テストを行い、結果を計測してそこから学習する、というDevOpsやアジャイル開発の基本概念は、セキュリティ向上においても非常に有用だ。

　こうしたアプローチはまた、開発者とセキュリティ専門家との間にあった「溝」の解消にも役立つだろうと言う。

　「Product Security at Internet Scale」と題するセッションにおいて、GEヘルスケアのProduct Development担当ディレクター、マイケル・マレー（Michael Murray）氏は、「伝統的なセキュア開発ライフサイクルは、古い企業ではうまく機能していた。では、スピードが鍵を握り、クラウド活用も当たり前というアジャイル開発の中で、どうやってセキュアな開発を実現すべきだろうか。ここで考慮しなくてはならないのは『遅れによる機会損失』だ。リリース前のペネトレーションテストに2週間もかかっていては、逸失利益は相当な額に上る。これこそ、開発者やビジネス側からセキュリティ担当者が嫌われ、無視される理由だ」と説明した。

　同氏は、セキュリティ要件も含めたテストコードを書き、自動化された開発プロセスの中に組み込むことが、「嫌われないようにするコツ」だと述べた。「リリース直前に二週間かけてセキュリティテストを実施する代わりに、テストを各リリースプロセスに分散し、ユニットテスト単位で実施することで、製品やサービスが市場にリリースされる時点でセキュリティが強制されることになる。セキュリティテストをソフトウェア開発サイクルの外に置いていては、いつまで経っても製品をリリースできないだろう」（マレー氏）

　一方で、製品やサービスによっては、ツールによる自動テストだけに頼るだけでなく、専門家チームによる本気の「演習」も有効だろう。米マイクロソフトのGroup Product Planner、サム・グッゲンハイマー氏は、Microsoft Azureにおいてレッドチーム（攻撃側）とブルーチーム（防御側）による「ウォーゲーム」を実施していることを紹介し、「こうした演習を通じて、セキュリティのベースラインを向上させ、その成果をDevOpsのリリースパイプラインに反映できる」と述べている。