皆様はセキュリティ関連の重大事故のニュースを少なからず目にしていることかと思います。例えば、誰でもアクセス可能な設定をしたままパブリッククラウドにデータを保存し、情報漏えいが発生した、というニュースが度々流れています。これは一見単純なミスのように思えますが、単純なミスが結果的に重大事故を引き起こすことは言うまでもありません。

　このような背景より近年、DevOpsそのものにセキュリティの観点も踏まえた 『DevSecOps』というキーワードが出始めています。

　そこで本記事では、DevOps にセキュリティの観点を加えた DevSecOps について解説します。

　そもそも「DevOpsってなに？」、「CI/CDについて詳しく知りたい」という方は、下記の記事 (はじめての DevOps) に詳しく記載しておりますので、ご欄ください。

■ 目次
・DevSecOpsとは
・DevSecOpsのポイント
・DevSecOpsの実装例

1. DevSecOpsとは

　DevSecOpsとは、ITサービスを提供する上で必要不可欠なセキュリティ対策を組み込みつつ、アプリケーションの開発からデプロイ(デリバリー)までのライフサイクルを効率的、安定的にまわそうというものです。(DevSecOps のイメージは図1参照)

図 1. DevSecOps ライフサイクル
(引用 : トレンドマイクロ社DevSecOps時代のCloud Security)
(URL : https://www.trendmicro.com/ja_jp/business/campaigns/aws/resources/devsecops_whitepaper.html)

　DevOps 自体は包括的な取り組みとなりますので、暗黙的にはセキュリティの視点も含まれていないわけではありません。ただ言葉そのままを捉えると開発視点に比重が置かれ、セキュリティという大事な視点が抜けやすくなるために Sec の文字も加わったと捉えています。

　DevOps, CI/CD といえば『効率を上げるためだけのもの』、と誤解されやすいですが、それだけではなく、同じ手順に従い自動的にプロセスが実行されることになるため、アプリケーションのデプロイまでの品質をより 『安定的』 に提供する、という大きなメリットもあります。

　セキュリティ関連の問題への最善な対応としては、発生しうることを前提とし、一連の工程をできるだけ妨げないよう対処できるのが好ましいものとなりますが、DevOps, CI/CDを利用することでこの大方針を実現しやすくなるのです。

2. DevSecOpsのポイント

　DevSecOps 実現のために何が必要になるのでしょうか。

　セキュリティ対策には前述の 図 1 のように様々な観点で対応する必要はありますが、主なポイントは下記の 4 つが挙げられます。

• シフトレフト対応
• できるだけ自動化
• 情報共有
• 追跡可能

　それぞれのポイントについて解説します。

2-1. シフトレフト

　もっとも重要なポイントは『シフトレフト』対応になります。

　昨今 DevSecOps という言葉とあわせて、「シフトレフト」という言葉が広まりつつあります。

　一般的にソフトウェア開発の工程では初期の段階で何らかの欠陥が 85% 以上潜在的に存在すると言われています。また、後の工程で対処しようとすればするほどコストが何百倍にも指数関数的に跳ね上がっていきます。(図2参照)
よって、『シフトレフト』とは工程のより前段階(シフトレフト)で対処、もしくは対処のための仕組みを作る。という事になり、これは当然セキュリティ対策にも当てはまることになります。

図 2. 源流管理の重要性
(引用 : Applied Software Measurement, Capers Jones,1996)

　後の工程になればなるほど対処が複雑になっていくことは皆様の経験則からも実感があるのではないでしょうか。

2-2. できるだけ自動化

　セキュリティ対策を『できるだけ』自動的に組み込むことが重要です。開発者側としてみればできるだけ負担がかからないよう自然と組み込まれていれば、開発の妨げにならずにアプリケーションのデリバリーを実施しやすくなるためです。

　ただ、『できるだけ』という部分も大事です。すべてを自動化しようとすると当然その分の実装に必要な時間やコストがかかります。完璧なセキュリティ対策はないという前提を受け入れ、その時点で何が必要最低限なのか、さらにそれを早めにステークホルダーと合意を得る、という観点も重要となります。

2-3. 情報共有

　セキュリティインシデント等は関係者等で共有されなくてはなりません。例えば、一度対応済のものが、担当者が変更になったことで次のアプリケーションリリースでは抜け落ちてしまうことはよくあるケースです。他の関係者(開発者、運用者等)と GitHub 等でセキュリティチケットを管理、共有していきます。チーム活動として振り返り等を実施していくことも重要となります。

2-4. 追跡可能

　何も問題が発生しなければ当然よいのですが、セキュリティインシデントは必ず発生することを前提として準備すべきです。そのため、セキュリティインシデント発生時に何が起こったかを明らかにするために追跡可能な状態にしておきます。もう少し具体的な手法を述べると、例えば、ログを残し、それを後で確認(検索)できるような仕組みにしておくことです。また、ログや証跡を残すことは監査対応時にも非常に重要となります。

3. DevSecOpsの実装例

　DevSecOps の具体的な実装例を示します。

　今回、主要クラウドの１つである、AWS での実装例について紹介します。
　日本でも徐々にクラウドの利用が浸透、もしくは少なくとも検討段階に入っているのではないでしょうか。

　クラウドを利用する理由は、必要な機能がマネージドサービスとして提供されインストール不要で利用可能であるためです。また、各機能や設定がコード化可能(Infrastructure as Code)であり、コード化することで開発から運用までの一連のサイクルが自動化しやすくなるメリットがあるためです。

　下図 3 が AWS 上での実装例です。赤字の文字が『2. DevSecOps のポイント』で解説したポイントの箇所です。

図 3. DevSecOps on AWS の例

　DevSecOps を実装する上では CI/CD の仕組みが重要な役割を果たします。

　CI/CD を利用することにより、各セキュリティチェックが自動的に、かつ前工程での実施が容易となるためです（この自動的実施される流れをパイプライン化と呼びます。）。

　パイプライン化されていますので、ソースコードの更新が発生したらチェックが必ず走ることになり、実施漏れが発生しません。

　各機能の実装方法についてですが、リソース定義の自動チェックをAWS CodePipeline + AWS CodeBuild での単体テストフェーズ実行するPython のプログラムを用いて AWS CloudFormation 内の定義をチェックする形で実装を行っております。
こちらの動作については、後術するIgniteにて実装サンプルを用意しております。
サンプルを実際に触ってみることが一番の理解につながりますので興味ある方はぜひIgniteを使ってみてください。

まとめ

　今回 DevSecOps の概略、およびDevSecOps の具体的な実装を解説いたしました。
　セキュリティ対策に完璧なものはなく、今回提示した仕組み以外にソースコードの静的解析や不正侵入検知/防御等々も検討していく必要はありますが、DevSecOpsの具体的な例がまだまだ少ないというのが現状です。

　今回の内容をすぐにお試しいただけるような仕組みとして、当社 Ignite 専用サイトにDevSecOps カタログを公開しています。Ignite 専用サイトは下記よりアクセスできます。

Ignite DevOps サイト

(https://www.ignite.ci?id=dsointro)

(“IGNITE DASHBOARD” をクリック)

　Ignite 専用サイトでユーザー登録いただければ、ご利用のAWS 環境に今回の環境が自動でデプロイされ利用可能となりますのでご興味のある方はぜひIgniteをお試しください。

　※この仕組み自体は無償のものですが、ご利用の AWS 環境の料金はかかります。

また、拡張等ご相談ありましたら ignite@ctc-g.co.jp までお問合せください。

■ Ignite とは

　DevOps の取り組みを促進、支援させていただくために、CI/CD 環境をワンクリックでお客様の AWS 環境へ展開可能な仕組みを 2018年3月に公開致しました。
　Ignite の詳細については、下記をご覧ください。