EN

NRIセキュア ブログ

デジタル時代の開発サイクル「DevSecOps」|迅速な開発とセキュリティの融合

目次

     

     急激なテクノロジーの進化に伴い、世界中の企業がデジタル化へのシフトを明確に打ち出しています。デジタル化が進展した現代は、利用者にとって、サービスの選択肢がとても多い時代です。そんな状況において、サービス提供者たる企業は、サービスに対する興味や体験を向上させるための仕掛けとして、俊敏かつ柔軟な開発スタイルを志向しています。

    「俊敏かつ柔軟な開発スタイル」というコンセプトを紐解いていくと、難解な専門用語(DevSecOps、DAST、SAST など)に多数向き合うことになります。デジタル時代の開発トレンドに関する要点を解説しながら、シフトライト(Shift Right)という言葉を具体的に紹介します。

     

     

    DevSecOps とは?

    businessman hand working with new modern computer and business strategy gear to success as concept

     詳細な説明を始める前に、あるWebコンテンツを紹介させてください。

     

    セキュアな開発ライフサイクル「DevSecOps」と、それを支えるセキュリティ対策ツールの種類と特長
    「DevSecOps」によるセキュアで迅速な開発ライフサイクルの実現 第1回

     

     ユービーセキュアの社員が CodeZine に連載しているコンテンツで、第1回では、DevSecOps を始めとする専門用語を幅広く取り上げつつ、分かりやすく解説しています。例えば、セキュアな開発ライフサイクルである DevSecOps のことは、、、

      これは、DevOpsにセキュリティの要素も取り込もうという考え方です。これだけではよく分からないので、そもそも DevOps とは何なのかというところから考えてみましょう。

     

      これはそのまま Development(開発)とOperations(運用)を組み合わせた言葉です。

     開発チームと運用チームが一体となって、これまでよりも迅速かつ頻繁にアプリケーションをリリースしていこうという概念になります。

     

      これを実現しようとすると、チームが分かれていることで発生するコミュニケーションコストやタイムラグが問題となってしまいます。また、頻繁にリリースするという目的は、開発チームと運用チームが一体となるだけでは実現できません。
     そのため
    DevOps では、アプリケーションのビルドやテスト、そしてリリースといった開発工程をできる限り自動化し、繰り返し実施できる環境を整えることが求められます。

     

      しかし、アプリケーションを頻繁にリリースできる体制・環境を作ったとしても、

    セキュリティ対策が不十分なままではリリースすることができません。そこで、

    開発チームと運用チームだけではなく、セキュリティも一体となることで、十分な

    セキュリティを担保しつつ、DevOps の目的としていた頻繁なリリースを達成しよう

    というのが、DevSecOps の考え方になります。

       という解説をしています。いかがですか? DevSecOpsという、難しく感じがちな専門用語を、少し身近な概念と思っていただけたでしょうか?

     

     上記引用の中に、大切なポイントが3つあります。後段の説明にも深く関係してくるので、ポイントを整理しておきます。 

    ■ DevSecOps 3つのポイント

     1.迅速かつ頻繁なリリース

     2.チームの一体化と開発工程の自動化

     3.十分なセキュリティの担保
     (但し、迅速・頻繁なリリースを妨げないことが大前提)

    開発ライフサイクルにおけるシフトレフト

    Continuous Improvement on the Mechanism of Metal Gears.

     ここ数年「シフトレフト」という言葉を聞く機会が増えています。さきほどの DevSecOps の説明にもあった、セキュアな開発ライフサイクルの中で、より早く、より頻繁にテストを行うべきという概念です。デジタル時代においては開発とリリース・運用の境界が融解し、チームの一体化やツールの自動化を通じて、継続的な取り組みにすることが必要です。

     このトレンドは、アプリケーションセキュリティの文脈にも影響を与えています。例えば、セキュリティ診断の分野です。従来のようなリリース前に外部セキュリティベンダーに脆弱性診断を依頼するようなスタイルだけではなく、より開発者の近くで脆弱性が自発的に取り除ける仕掛け(脆弱性を埋め込んだままのコードをリポジトリにコミットできない)や、自動的に脆弱性スキャンを回すことで繰り返し脆弱性検証が行える仕掛けなどが該当します。

     ここには、
    設計段階からセキュリティを考慮するという話も当然含まれますが、その場合でも迅速かつ頻繁なリリースを妨げないことが大前提となります。

    「シフトライト」、リリース後から始まる本当の勝負

    Facts Myths written on a chalkboard

     

     間断なく連続的に新機能をリリースしてゆくサイクルは、利用者にサービスを利用し続けてもらうために必要です。これによって、利用者に新しい体験や感動をいち早く味わってもらうことができ、サービスに対するロイヤリティの向上に繋がるからです。

     

     では、リリースして以降、どのようにしてこのサイクルを回せばいいのでしょうか。それは、以下のような観点で、データを検証していくことが重要です。

     ・新機能の利用状況が想定通りか(きちんと使ってもらえているか)
     ・本番環境での新機能のパフォーマンスが想定通りか

     

     これらの本番環境上のデータを適切に検証し、よりよい方向に正していく活動が自然に行われることが大事です。

     

     つまり、この観点ではリリースしてからが「本番のテストの始まり」とも言えます。これまでのレガシーなスタイルでは、ローンチするまでにテストをやり切って完璧な状態に仕上げ、リリース判定会議などを乗り切ってリリースする必要がありました。そして、初期のトラブル対応をこなしたらテストは一旦終わり、という考え方でしたが、今はそうではありません。開発はこれで終わりではなく、連続的に続いていきます。そのために、本番環境から得られた課題が適切に次の開発に活かされるようなサイクルを紡いでゆく必要があるのです。

     

     「シフトライト」とは、リリース後の本番環境から生み出される大量のデータを宝の山に見立てること。そして、そこから機能/非機能要件的な課題を抽出し、競争を勝ち抜いてゆくための迅速なアクションにつなげていくこと。これらの「分析主導」のアプローチのことを指します。

     

     左、右とは、企画/開発からローンチまでのタイムラインを右矢印で引っ張った際のベクトルの方向のことを指しています。ここでのポイントは、そのサイクルは分断されておらず、実際にはつながっているということです。

     

     アジャイルのテスティングフレームワークとしては、

      ・Testing Quadrant
      ・Test Pyramid
      ・New Model Testing

     などの考え方が整理されているので、ご興味がある方は、それらが支持される変遷などを追ってみてください。

     アプリケーションセキュリティにおけるシフトライト

    Business person standing against the blackboard with a lot of data written on it

     

      「実際にユーザーが手に触れる本番環境でのデータを重視する」、このようなシフトライトのアプローチは、競争を勝ち抜いてゆくために重要な要素です。そして、これらのアプローチが安全かつ迅速に行えることを支援するために、昨今のクラウド環境ではリリース作業をボタン一つで行えるように準備されているケースもあります。これらは、「ダークローンチ」、「カナリアリリース」、「ブルーグリーン・デプロイメント」などと呼ばれることもあります。

     

     ところで、セキュリティの観点で「シフトライト」を考えた場合、どのような取り組みが考えられるでしょうか。まず考えられるのが、能動的な監視運用である 「Threat Hunting」です。

     

    「Threat Hunting」とは、脅威をただモニタリングするのではなく、異常な傾向などから脅威を積極的に見つけ出して“ハンティング”するという考え方です。アプリケーションログの例外出力を統計しながら、異常な例外を見逃さないといった基本的な考え方がシフトライトに通じる点です。

     

     また、以下のようなソリューションも、シフトライトの考え方に基づいていると言えます。

     ・世間の脅威動向と合わせた確認観点の追加(インテリジェンスの活用)
     ・リスト型アカウントハッキング等による不正ログインや不正取引を、利用者のビヘイビアを見分けながら炙り出すソリューション
     ・(脆弱性診断ではなく)本番へのペネトレーションテスト


     一方、セキュリティ監視運用チームは、伝統的に INBOUND / OUTBOUND の通信経路上のローデータをプロトコルレベルで見ています。しかし、アプリケーションログはフォーマットが様々であるため、アプリケーション運用チームが個別に監視運用を行っているというケースが多いでしょう。したがって、そこには、少なからず「溝」が生じるのです。

     

     これまでは別々のものとして管理されることが多かったセキュリティ監視運用とアプリケーション運用ですが、デジタル化がもたらす頻繁なアップデートやフィードバックを安全に実現するために、セキュリティの脅威を察知・除去するという軸で、より一体となってアクションしてゆくことが求められると考えられます。


     「溝」が識別できたのなら、埋めればいい。

     課題を真正面から捉えながらも、どこまでもポジティブに改善に取り組み、発見と成長を繰り返し続けること。これはDevOps や DevSecOps を成功させている組織にほど、共通的に見られる姿勢・意識・文化です。

    RASPという新たな選択肢

     

     ここで一つ、新たなキーワードを紹介します。Runtime Application Self Protection (RASP) という、アプリケーションと一体となって稼働し、アプリケーション動作を監視/防御する概念のツールが登場しています。日本国内では既にWAF(Web Application Firewall) がある程度普及しているため、一見すると重複する機能のようにも見えるかもしれません。

     

     RASPは、アプリケーションの挙動を SIEM に連携することも可能で、前述の「溝」を埋めるパーツとして活用できる可能性があります。アプリケーションセキュリティにおける「シフトライト」の要の一つとして、その運用が成熟してゆくことを期待しています。

     

     ユービーセキュアは、高速開発のさらなる効率化・安全確保を支援すべく、米国Contrast Security社の IAST ならびに RASP 製品である「Contrast Assess」と「Contrast Protect」を提供します。Webアプリケーション脆弱性検査ツール Vex と Contrast Assess, Contrast Protect を組み合わせることで、高速開発におけるセキュリティ検査の効率性をさらに向上させる日本国内では数少ないDevSecOps ソリューションをお客様に提供可能です。

     

     2018年8月7日 お知らせ(ユービーセキュア)
      IAST、RASPに対応した、米国Contrast社の脆弱性検査製品を販売開始
      -「DevSecOps」に対応、高速アプリケーション開発がより効率的に-

    contrast-fig3

    図. 高速アプリケーション開発に対応した脆弱性診断ソリューション

    (参考:https://www.ubsecure.jp/product/contrast_security

     

     

    サイバーセキュリティとチームカラー

     サイバーセキュリティでは、攻撃者視点で許可を得てハッキングを行い、問題を事前に抽出するRedTeam、防御側を担当する BlueTeam と呼ばれる概念・組織があります。また、両者の視点やノウハウを結び付け、攻防一体となって防衛力を高めてゆく概念を PurpleTeam と呼ぶこともあります。

     

     昨年の BlackHat のとある講演にて、開発部門を YellowTeam と見立て、RedTeam や BlueTeam と密接に連携することで、PurpleTeam 同様に防衛力を高めていこうとする概念の発表がありました。

     

     Red と Yellow の連携を OrangeTeam 、Blue と Yellow の連携を GreenTeam としており、デジタル時代において、セキュリティが開発と一つのチームとしてゴールを共有していかなければならないとする考え方を、わかりやすく象徴的に表していると思いました。

     

     

    Red_Blue_Yellow

    図. サイバーセキュリティにおけるチームの考え方

    (参考:https://www.blackhat.com/docs/us-17/wednesday/us-17-Wright-Orange-Is-The-New-Purple.pdf

     

     

     WAF や RASP については、冒頭に紹介したWebコンテンツ「DevSecOps」によるセキュアで迅速な開発ライフサイクルの実現 第1回   の中でも触れていますので、是非ともご覧ください。

     さいごに ~ 組織的な結束と継続的改善こそが鍵 ~

     グローバルで著名なリサーチ会社による「DevOps」に関する調査で、興味深い結果がありました。 

     

     「あなたの組織に DevOps を取り入れていこうとする時に、最大のチャレンジ要素はなにか?」という問いに対して、「人」という回答が5割、「プロセス」が4割となっており、なんとこの2つで全体の約9割を満たしていました。一方で、「技術」という回答は1割未満でした。

     

     これは決して、技術が重要でないという意味ではなく、DevOps や DevSecOps の成功の鍵の多くを、「人」と「プロセス」が握っており、その整備なくしては技術が宝の持ち腐れになるという示唆だと理解しています。

    Rugby fans in arena against rugby players doing a scrum

     

     スポーツで例えると、セキュアな開発ライフサイクルは、ラグビーに近いと言えるかも知れません。

     早大ラグビー部、日本代表の監督を務めた故・大西鉄之祐氏は、代表監督就任に際して「展開・接近・連続」という戦法を披露しました。ボールを素早く動かす試合展開、相手に接近して紙一重の攻防を仕掛ける。そして、連続プレーで相手を疲れさせる。体格に劣る日本が、器用さと持久力を生かして、世界と戦って勝つ道筋を示しました。

     

     アプリケーションを頻繁にリリースすることを「展開」、テスト工程がより開発者の近くで行われているというトレンドを「接近」、なんども繰り返してリリースできることを「連続」と捉えると類似点が見えてくる気がします。そして、なによりもラグビーは球技の中でも人数が多いスポーツ(15名)なので、チームワークを強化・改善することが欠かせません。

     

     2015年のラグビーワールドカップの初戦で、日本が世界の強豪である南アフリカをロスタイムの奇跡の逆転トライで破った試合、最後のトライは、何度も、何度も、パスをつなぎ、諦めることなく、チームを信じて、波状攻撃した末の偉業でした。

     

     一つのサービスを構成するアプリケーションは、ますます巨大化 (もしくは細分化) し複雑化していきます。サービスを有機的に維持し、更にアップデートを継続してゆくには相応の自己変化や努力が必要となります。そこにレガシーなセキュリティをそのままあてはめようとすれば確実にギャップが生じます。いまこそ、知恵・工夫の見せ所なのです。

     

     最近、とあるお客様から機械が生成したと思われる80ページものレポートを見せられながら「セキュリティ業界は努力が足りないのではないか」と叱咤・激励をいただくことがありました。慢心している暇はありません、デジタルの時代に相応しいセキュリティサービスを追求していきます。

     

    vex

     

    Webアプリ脆弱性検査ツール Vex サービス概要紹介サイト