SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2021】セッションレポート(AD)

DevOpsのセキュリティ面も考慮した「DevSecOps」で、リリース期間短縮・性能と安全性の担保を実現【デブサミ2021】

【18-A-5】セキュアなDevOpsを実現するために今すべきこと

  • X ポスト
  • このエントリーをはてなブックマークに追加

 DevOpsとは、開発担当者と運用担当者が連携して協力する開発手法。最近では多くの企業が採用し、開発効率を改善できる組織体制を構築している。しかし、DevOpsにはアプリケーションセキュリティの観点が組み込まれていない場合が多く、アプリケーションの脆弱性が発覚すると、継続的な開発と運用が妨げられてしまう。そこで本講演では、マイクロフォーカスエンタープライズ株式会社の専門家2名により、脆弱性テストをDevOpsに組み込むDevSecOpsの考え方と、関係者の負担を減らしながらリスクを回避するための実践方法が紹介された。

  • X ポスト
  • このエントリーをはてなブックマークに追加

(上)マイクロフォーカスエンタープライズ株式会社 プリセールス統括本部 松尾政仁氏、(下)マイクロフォーカスエンタープライズ株式会社 プリセールス統括本部 Solutions Architect 森泰人氏

(上)マイクロフォーカスエンタープライズ株式会社 プリセールス統括本部 松尾政仁氏、
(下)マイクロフォーカスエンタープライズ株式会社 プリセールス統括本部 Solutions Architect 森泰人氏

アプリケーションに潜むセキュリティリスクは、開発の前工程で対処すべき

 マイクロフォーカスエンタープライズ株式会社は、顧客のデジタル変革を支援するソフトウェア製品の開発、販売、サポートなどを行っている世界最大級のソフトウェア企業の日本法人。同社のプリセールス統括本部 松尾政仁氏は冒頭、企業が直面している課題について、デジタル化への課題の洗い出しと分析が困難なこと、新規製品のリリース遅れによる競争力低下、マシンラーニング/AIなどへの対応遅れ、クラウド移行対応の遅れ、脆弱性、情報漏洩などのセキュリティリスクへの対応が不十分など、さまざまな問題があることを挙げ「ビジネスの変革と高度化への対応のため、効率化への取り組みが必要です」と述べた。

 昨今の開発システムでは、効率化のアプローチとしてDevOpsを採用が行われており、コードデプロイ頻度が増加、コミットからデプロイまでのリードタイムやインシデントからの回復時間の高速化が行えるようになった。しかしながら、DevOpsのサイクルからセキュリティが取り残されていると松尾氏は指摘する。その理由として、専門性が高いことや、セキュリティ推進の理由となるコンプライアンスがDevOpsの対象外であること、開発者は機能するコードを迅速に提供することが求められているためセキュリティまでケアできていないこと、などが挙げられる。

 次にアプリケーションが持つセキュリティ上の問題について、マイクロフォーカスのFortifyソフトウェアセキュリティリサーチチームが示した「2019 Application Security Risk Report」の内容を紹介した。これによると、Webアプリの79%、モバイルアプリの88%、アプリ全体の61%に問題が存在しているという。

重大度が「クリティカル」または「高」の問題が生じるアプリケーションは多い
重大度が「クリティカル」または「高」の問題が生じるアプリケーションは多い

 アプリケーションに問題が発生した場合、開発の後の工程になればなるほど修正の手間がかかる。NIST(アメリカ国立標準技術研究所)の調査では、修正にかかる手間は、実装段階では要件定義時の手間と比較して10倍、システムテスト段階なら15倍、運用の段階では30倍としている。松尾氏は「できる限り早い段階で脆弱性を見ていく、つまり開発の実装段階で脆弱性を見つけていくという仕組みを作っていくことが重要になります。継続的計画と継続的インテグレーションとテスト、そして継続的脆弱性テストの取り組みによって、DevOpsからDevSecOpsへのシフトを実現できると考えています」と説明した。

 続いて、アジャイル開発におけるDevSecOpsの構成イメージを提示した。アジャイル開発はバックログを管理し、開発者によって出来上がったコードが品質を保っているか継続的にテストをする。何か問題があればその不具合を修正して開発していく。同社のエンタープライズアジャイル管理製品「ALM Octane」は、要件管理、バックログ管理、タスク管理、テスト管理、不具合管理をみて品質を可視化する製品だ。

DevSecOpsのハブとなり、継続的に品質管理や脆弱性のチェックができるALM Octane
DevSecOpsのハブとなり、継続的に品質管理や脆弱性のチェックができるALM Octane

 IDEからALM Octaneのバックログ情報を参照し、開発者がコミットしたら自動的にビルドされ、開発環境やテスト環境にデプロイされる。機能や性能のセキュリティテストはパイプラインにのせて自動的に実行され、それらの結果はALM Octaneでテストの状況と自動的に関連づけされて管理・可視化される。ALM Octaneはスクラムレベルのチームから、エンタープライズまでを対象とし、高い品質を維持しながらリリースの短縮化を実現する体制をサポートするという。

 同社では、DevSecOpsの工程に組み込まれる各種自動テストのための製品群を提供している。「UFT One」はGUI/API機能テスト自動化ツールで、人間に代わってGUI操作を自動的に行い機能的に正しいかどうかの検証を行う。「LoadRunner Professional」は負荷テストのプラットフォーム。たくさんのユーザーに代わってアプリケーションを動作させ、システムや想定しているレスポンスに問題がないか、ボトルネックがどこにあるかを捉えることができる。そして、「Fortify」が、さまざまな手法でアプリケーションセキュリティテストを行うツールだ。

 「ツールによって特徴があり、適切なフェーズやタイミングでテストを行っていきます。コードができあがったタイミングではコードの脆弱性をチェックし、システムのリリース前はパフォーマンステストや動的セキュリティテストを実施します。パイプラインの中に組み込んで、継続的にテストを効率化していくということが重要になります」(松尾氏)

FortifyでDevSecOpsを文化として定着させる

 続いてマイクロフォーカスエンタープライズ株式会社のプリセールス統括本部 Solutions Architect 森泰人氏が「Fortifyを使ったアプリケーションセキュリティ」と題したスライドを掲げて登壇。森氏によると、2021年はDevSecOpsの年とされており、マイクロフォーカスではDevSecOpsを「文化」として捉えていると切り出した。その文化とは、開発・運用・セキュリティの各チームが素早く安全なアプリケーションを提供できるように協力できる環境を構築することとしている。

 一般的に開発者とセキュリティがなかなか結びつかないことも多い。そこで森氏は悪意のある攻撃「HTTP Response splitting」を例に説明した。この攻撃は、HTTPがキャラクターベースのプロトコルである事を悪用して、正規のレスポンスに改行コードを挟む事で2つのレスポンスを連続でブラウザに送り、後半のレスポンスで悪意あるサイトへ誘導してキャッシュサーバーに登録。以降サイトにアクセスした人はキャッシュから汚染されたレスポンスを受け取るといったもの。

 例えば、入力した内容によってベージの遷移先を動的に制御するなど、入力されたデータをレスポンスのヘッダーに利用して返すような実装をしていれば簡単に悪用されてしまう。開発者が対応していなくても運用側でカバーできるという考え方もあるが、この攻撃はURLエンコーディングして改行コードを無効化するコードを1行追加するだけで対処できるのだ。

 ただし、このような対処法ばかりしていたら、対応する開発者に負担がかかる。コロナ禍もあり開発側への要求が高まるなか、機能実装だけでも大変なのに脆弱性の修正は難しい。そこで森氏は、DevSecOps文化を形成するために重要なアプリケーションテストのソリューションであるFortifyを推奨すべく説明を始めた。

 Fortifyには、さまざまな局面に応じたテストツールがラインアップされている。ソースコードを読み込んで解析する静的解析や、アプリケーションを動作させて解析を行う動的解析、動的解析の一種であるIAST(Interactive Application Security Testing)、そして本番環境において不正な動作を排除し記録するRASP(Runtime Application Self Protection)もサポートする。

 では開発者はFortifyをどのように活用するのだろうか。開発者は自分の端末でコーディングし、ソースコードのリポジトリにコミットする。そこから先はJenkinsのようなツールでさまざまなテストが自動化される。ビルドサーバではコードの静的診断が行われ、ビルドが終わればQAサーバで動作させ、動的診断を行う。それぞれの診断結果は、「Fortify Software Security Center」に送られ、開発者はその結果を見て修正の対応をする流れだ。

 森氏は、「FortifyのIDEプラグインもあり、開発者はIDE上で結果を見ることもできるので、現在の運用に組み入れていく形式がいいと思います。Fortify Software Security Centerがハブになるような形で、セキュリティ担当者も結果の確認や問題の選別、レポート出力ができます。このような運用を習慣化していくことを推奨します」と語った。

Fortifyによって、開発にセキュリティテストを無理なく組み入れることができる
Fortifyによって、開発にセキュリティテストを無理なく組み入れることができる

 そして森氏は「幸せな開発者の1日」として、セキュリティテストの自動化を組み入れた開発者のモデルケースを紹介した。開発者は、コーディングした1日の終わりにリポジトリにアップロードして帰宅する。その後、静的テスト、ビルドとデプロイ、動的テストや各種テストから不具合が発生した場合などのチケット登録まで自動化されて進行する。開発者は翌朝に登録されたチケットを処理し、次の新規コーディングを行う、というライフサイクルが実現できるとした。

テストの工程を自動化できるので、開発者はコーディングに集中できる
テストの工程を自動化できるので、開発者はコーディングに集中できる

 森氏は「セキュリティチェックがあるからといって、開発者の仕事が増える訳ではありません。どのみち不具合は解消しなければならないものですが、数か月間に書いたコードをあとから修正するよりは前日のコード修正のほうが容易ですね。このようなサイクルで開発していくと安全なシステムができ、開発者も幸せになります」と、そのメリットを説明した。

 このあと松尾氏が再び登壇し、継続的ビルド&テストのデモンストレーションを行った。開発メンバーがALM Octaneにログインし、IDE上からユーザーストーリーを確認、コードを変更・コミットし、Jenkinsの方でパイプラインを実行。セキュリティテストとしてFortifyが自動実行され、脆弱性情報などの結果がALM Octaneに登録されるという一連の流れが説明された。松尾氏は最後に講演を振り返りとして次のようにコメントした。

 「アプリケーションの脆弱性は、開発の大きな手戻りの要因となります。これを解決していくためには現在のDevOpsに継続的なセキュリティテストを組み込んでいくことが重要です。DevSecOpsにシフトすることでリリース期間の短縮、機能・性能・セキュリティを担保したアプリケーションの開発を実現できます」

 なお、FortifyチームではYouTubeでもDevSecOpsについて解説している。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/13691 2021/03/18 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング