Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

Share

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、トータルコストを低減しつつ、さらなるクオリティ向上を実現する手法です。セキュアなWebアプリケーション開発プロセスの実現のためには、この考え方が重要です。しかし、多くの企業・組織にとって、DevSecOpsの実現には様々な課題があるのが実情です。 本記事では、開発の現場担当者が感じている課題を整理したうえで、セキュアなWebアプリケーション開発にむけて、どのように取り組むべきかについてご紹介します。

OWASP Top10に新たな項目

2021年9月、「OWASP Top 10 2021」が発表されました。Webアプリケーションセキュリティに関する最も重大な10項目のリスクを取り上げたものです。前回発表された2017年版(OWASP Top 10 2017)から4年ぶりの更新となります。

※OWASP(Open Web Application Security Project)…Webアプリケーションセキュリティに関する国際的コミュニティ

2017年版Top 10の各項目は、2021年版ではそれぞれ順位を上げ下げしつつ、一部統合されて7項目となり、完全に消えたものはありませんでした。そして、新たなカテゴリが3項目追加される形で計10項目となりました。

OWASP Top 10 – 2021

A01:2021 –アクセス制御の不備
A02:2021 –暗号化の不備
A03:2021 –インジェクション
A04:2021 –NEW セキュアでない設計
A05:2021 –セキュリティ設定のミス
A06:2021 –脆弱かつ古いコンポーネントの使用
A07:2021 –識別と認証の不備
A08:2021 –NEW ソフトウェアとデータの整合性の不備
A09:2021 –セキュリティログとモニタリングの不備
A10:2021 –NEW サーバサイドリクエストフォージェリ(SSRF)

NEW」は2021年度版で追加された項目
https://owasp.org/Top10/ より弊社和訳

新設された3項目のうち2つが、システム開発のプロセスにかかわる内容に焦点を当てています。

● セキュアでない設計(Insecure Design)
  ポイント:設計における管理策の欠如、ロジックの検証が不十分である等
  推奨対策:シフトレフトによる開発ライフサイクルの実践 等
● ソフトウェアとデータの整合性の不備(Software and Data Integrity Failures)
  ポイント:安全でないデシリアライゼーション、
  信頼できないコンポーネントの利用、CI/CDパイプラインにおける検証不備 等
  推奨対策:データの整合性チェック、コンポーネントのセキュリティチェック、
  CI/CDのセキュリティ対策

※シフトレフト…開発工程のより早い段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方

ここで推奨対策例として出てきた「シフトレフト」と「CI/CDのセキュリティ対策」はアプリケーション開発プロセス手法である「DevSecOps」実現に欠かせません。

アプリケーション開発における「DevSecOps」

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、結果的にトータルコストも削減でき、サービスの価値をさらに向上させる手法です。

DevSecOpsとシフトレフト(Shift Left)について、詳しくは過去記事「前倒しで対処 ー セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー」をご覧ください。

“セキュリティ”が組み込まれていないと…

DevSecOpsにおけるシフトレフト

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

DevSecOpsにおけるCI/CDのセキュリティ対策

“Sec”が入らないDevOpsにおいては、設計・実装を小さな単位で素早く繰り返し実行していく手法(アジャイル開発手法等)が一般的ですが、このスピード感をサポートするのが「CI/CD」です。

CI/CDの説明図

CI(Continuous Integration)は継続的インテグレーション、CD(Continuous Delivery)は継続的デリバリの略です。アプリケーション開発におけるコード、ビルド、テスト、デプロイといった各作業を自動化して継続的にサイクルを回せるようにする仕組みを指します。オンプレミスでもクラウド上でも展開可能で、CI/CDを提供する様々なツールやサービスが提供されています。

ただし、CI/CDはセキュリティ上のリスクにもなりえます。CI/CD環境に脆弱性が潜んでいて不正アクセスされるようなことがあれば、そこを発端に組織全体が危険にさらされる恐れもあるのです。このため、DevSecOps実現のためには、CI/CDのセキュリティ対策が不可欠です。

セキュアでない設計によるリスク

では、シフトレフトが意識されていない、セキュアでない設計にはどのようなものがあるでしょうか。ユーザの認証に用いられる情報がIDと生年月日である場合、生年月日は他者が容易に知りうる情報なので、本人確認の仕様としてはふさわしくないことがわかります。例えば、補助金の申請システムにおいて、申請者の本人確認や申請内容の検証が甘いために容易に複数の虚偽申請を許してしまうようでは、実用に耐えるとはいえないでしょう。

こうしたセキュリティについて考慮されていない設計は、弊社の脆弱性診断でも相当数検出されています。アカウントロックアウトが設定されていない、Webサーバからのレスポンスにクレジットカード番号のような重要情報が含まれている、個人情報が暗号化されないまま送信されている、といった例は多々見受けられます。放置しておくと、個人情報や機密情報の漏洩を引き起こしかねません。

プライバシーマーク推進センターによって報告された、2020年度「個人情報の取扱いにおける事故報告集計結果」によると、誤送付や紛失・盗難によらない情報漏洩のうち、プログラムやシステムにおける設計・作業ミスを原因とするものは102件あったとのことです。大した件数ではないようにも見えますが、インシデント1件あたりの漏洩件数が増加傾向にあるとの報告もあり、影響の大きさに注意が必要です。また、これらはあくまで報告があったものだけの数ですので、セキュアでない設計によるアプリケーションが人知れず稼働したままになっている危険性は大いにあるでしょう。

一般財団法人日本情報経済社会推進協会(JIPDEC)プライバシーマーク推進センター
2020年度「個人情報の取扱いにおける事故報告集計結果」(2021年10月15日更新)より

CI/CDパイプラインにおける検証不備によるリスク

コードカバレッジツールへのサイバー攻撃の概要図

CI/CDパイプラインに起因するリスクの方はどうでしょう。2021年にあるインシデントが発生しました。ソースコードのテスト網羅率を計測するコードカバレッジツールがサイバー攻撃を受けた結果、このツールを使用していた国内企業のCI環境に不正アクセスされ、重要情報を含む1万件以上の情報漏洩につながったというものです(右図参照)。

自動化、高効率化ツールによる利便性を享受するためには、そこに係るすべてのツールや工程におけるセキュリティチェックを行う必要があるのです。

DevSecOps実現を阻む壁

さて、安全なWebアプリケーション開発の重要性は認識できているとしても、実現できなければ意味がありません。とはいえ、DevSecOps実現には、多くの企業・組織において様々な障壁があるものと思われます。今回は主な障壁を「組織」と「技術」のカテゴリに分類し、それらの問題点および解決の糸口を考えていきます(下図参照)。

DevSecOps実現のためにできること

DevSecOpsに特化したガイドラインが存在しないというのも、対応を難しくしている要因の1つかもしれません。とはいえ、Webアプリケーション開発におけるセキュリティ対策の課題を考慮すると、鍵となるのはやはりシフトレフトです。シフトレフトを意識しながら、システム開発プロセスに組み込まれたセキュリティ対策を実践する例として、以下のようなイメージが考えられます。

Webアプリケーション開発におけるセキュリティ対策実施の背景には、Webアプリケーションの規模や利用特性ばかりでなく、開発組織の業務習慣や文化等、様々な事情があることでしょう。例えば、セキュアコーディングのルール整備やスキルの平準化が不十分という課題があれば、まずは現場レベルでそこから取り組んでいくといったように、信頼されるWebアプリケーション構築のために、少しずつでもDevSecOpsの実装に近づけていくことが肝要です。

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

●NIST
 Security Assurance Requirements for Linux Application Container Deployments
 https://csrc.nist.gov/publications/detail/nistir/8176/final

●OWASP
 OWASP Application Security Verification Standard
 https://github.com/OWASP/ASVS

●内閣サイバーセキュリティセンター(NISC)
  情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
  https://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


SQAT® Security Serviceページへのバナー

BBSecコーポレートサイトへのバナー



Share

前倒しで対処 ー セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー

Share

セキュリティにおける 「シフトレフト(Shift Left)」 とは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。元々この概念は仕様を満たしているか等の検証に対するソフトウェアテストのジャンルで使われていた言葉ですが、近年セキュリティの世界で注目されています。

ソフトウェア開発の主要工程である「設計」→「開発」→「検証」→「運用」の各プロセスは、計画書や図などで、通常左から右に向けて記載されます。図の左側(レフト)、すなわち時間軸の早い段階で脆弱性を作り込まない対策を施した開発を行えば、セキュリティリスクを低減させるだけでなく、品質向上、期間短縮、トータルコスト低減などの効果があります。

セキュアなWebアプリケーション開発を推進する国際NPO「OWASP(Open Web Application Security Project)」もシフトレフトを推奨しており、Googleをはじめとする先進IT企業ではこの考え方を採用したシステム開発を行っています。

「シフトレフト」と「セキュリティ・バイ・デザイン」「DevOps」「DevSecOps」との違い・関係

シフトレフトと関連する言葉に、「セキュリティ・バイ・デザイン」「DevOps(デブオプス)」「DevSecOps(デブセックオプス)」などがあります。

「セキュリティ・バイ・デザイン(SBD:Security by Design)」とは、開発の企画・設計段階からセキュリティを考慮することです。

「DevOps(デブオプス)」は、ソフトウェア開発チーム(Developer)と運用チーム(Operations)が互いに協力し合い、ソフトウェアとサービスのクオリティを向上させます。「DevSecOps(デブセックオプス)」は、開発チームと運用チームに、セキュリティチーム(Security)が加わり、セキュリティを含めトータルコストを低減しつつ、さらなるクオリティ向上を実現する仕組みです。

セキュリティ・バイ・デザインは概念、DevSecOpsは体制運用、そしてシフトレフトは工程管理の考え方ですが、いずれも、事故やトラブルが起こってから、あるいは脆弱性が見つかってから、といった事後対応のセキュリティ対策ではなく、事前対応、すなわち前倒しで実践する点で一致しています。

シフトレフトによって向上する品質

たとえば、ビルを建てた後になってから、建物の基礎部分に問題が見つかったら改修は容易ではありません。また、社会的な信頼も大きく損なうことでしょう。ソフトウェアも同じで、問題発見が早いほど、改修に必要な労力、費用、時間は少なくてすみますし、信用失墜の危険性も軽減できます。

リリース直前の脆弱性診断でWebアプリケーションに脆弱性が発見されたら、手戻り分のコストがかかるだけではなく、リリース日の遅れや、機会損失の発生を招き、ステークホルダーのビジネスにまで影響を及ぼしかねません。シフトレフトの考え方でセキュリティに配慮しながら開発を進めれば、こうしたリスクを低減でき、ソフトウェアの信頼度が高まります。

シフトレフトによるトータルコスト低減メリット

セキュリティに配慮せず開発を行えば、短期的にはコストを抑え、開発期間を短くすることができるでしょう。しかし、リリース後の運用過程で、もしサイバー攻撃による情報漏えいや知的財産の窃取などが起こったら、発生した損失や対応費用など、長期的に見たコストはより大きくなるでしょう。

こうしたトータルコストの低減効果こそ、シフトレフトによるセキュアな開発および運用の真骨頂です。

シフトレフトとは、発生しうるトラブルに事前に備えるということです。病気にならないように運動をしたり、食生活に気をつけたりといった、ごくごくあたりまえのことです。

つまり、これまでのソフトウェア開発は、その当たり前をやっていなかったとも言えます。シフトレフト、セキュリティ・バイ・デザイン、 DevSecOpsという言葉がいろいろな場面で見られるようになったことは、開発現場が成熟してきた現れでもあります。今後、こういった開発プロセスが新常識となっていくことでしょう。

シフトレフトを普及させた裁判の判決とは

ここで、セキュリティ視点でのシフトレフトの考え方を日本に普及させるきっかけのひとつになったとされる、2014年の、ある裁判の判決をご紹介します。

とある企業の開発依頼で納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性があったことで、不正アクセスによる情報漏えい事故が発生しました。依頼した企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として提訴、東京地方裁判所がそれを認め、開発会社に約2200万円の損害賠償支払いを命じました( 平成23年(ワ)第32060号 )。ただし、全面的に開発会社の落ち度としたわけではなく、発注会社側が責務を果たしていない点については、相当程度の過失相殺を認めています。

この判決は、これまで技術者がいくらセキュリティの必要性を説いても首を縦に振らなかった、セキュリティよりも利益を重視していた「開発会社の経営管理層」と、セキュリティよりもコストと納期を重視していた「発注者」の考えを変えるインパクトを持っていました。

将来事故が起こらないよう、トータルコストを抑えセキュリティに配慮した開発を行う有効な方法としてシフトレフトが採用されたのは、ごく自然なことといえるでしょう。

シフトレフト視点での開発上の注意

シフトレフトに基づく開発におけるセキュリティ対策の実施例は以下のとおりです。

●セキュリティ・バイ・デザイン
まず、セキュリティ・バイ・デザインの考え方に基づいて、企画・設計段階からセキュリティを考慮しましょう 。

●セキュアな開発環境
開発は、脆弱性を作り込まないようにするフレームワークやライブラリなど、セキュアな開発環境を活用して行います。

●ソースコード診断
開発の各段階で、プログラムコードに問題がないかを適宜検証するソースコード診断を実施します。

●脆弱性診断
もし、どんなセキュリティ要件を入れたらいいかわからなくても、独立行政法人情報処理推進機構(IPA)などの専門機関がいくつもガイドラインを刊行しています。「このガイドラインを満たすような開発を」と依頼して、それを契約書に記載しておけばいいでしょう。ガイドラインの中身を完全に理解している必要はありません。

リリース前や、リリース後の新機能追加等の際には、必ず事前に脆弱性診断を行います。また、脆弱性が悪用された場合、どんなインシデントが発生しうるのかを、さらに深く検証するペネトレーションテストの実施も有効です。

シフトレフト視点での発注の仕方

シフトレフトは主に開発者側の考え方です。では、ソフトウェア開発を依頼する発注者はどうすればいいのでしょうか。

まず、発注の際には必ずセキュリティ要件を入れましょう。納品されたシステムやWebアプリケーションにセキュリティの問題が発見された際に対応を要求しやすくなります。

もしそれによって見積額が上がったら、トータルコストのこと、シフトレフトというこれからの新常識のことを思い出していただきたいと思います。

・安全なウェブサイトの作り方(IPA)
https://www.ipa.go.jp/security/vuln/websecurity.html

シフトレフトが変えるセキュリティの未来

とはいえ、今回ご紹介したシフトレフトの考え方が社会に広く普及するまでには、もう少し時間がかかりそうです。

SQAT.jp を運営する株式会社ブロードバンドセキュリティが、リリース直前のWebサービスに脆弱性診断を行うと、山のように脆弱性が発見されることがあります。

その脆弱性の中には、2014年の裁判で開発会社の債務不履行とされたSQLインジェクションのような、極めて重大なものが含まれていることも多くあります。

業界が成熟し、シフトレフトによるセキュリティ対策が実践されていけば、脆弱性診断というサービスの位置づけ自体が将来変わることすらあるかもしれません。たとえば自動車のような、安全規格に基づいて設計製造された製品における出荷前の品質チェック、あるいは監査法人による会計監査のように、「きちんと行われている前提」で実施する広義のクオリティコントロール活動の一環になるかもしれません。

SQAT.jp は、そんな未来の到来を少しでも早く実現するために、こうして情報発信を行い続けます。

まとめ

・シフトレフトとは上流工程でセキュリティを組み込み、トータルコストを抑えるという考え方
・セキュリティを考慮せずにWebサービスを開発し提供するのは、たとえるなら建築基準法を考慮せずにビルを建ててテナントを入居させるようなもの
・セキュリティをコストととらえ費用を惜しむと、将来的により高い出費を余儀なくされる可能性がある
・シフトレフトによるセキュリティ対策には、セキュリティ・バイ・デザイン、セキュリティ要件の明示、セキュアな開発環境、早期段階から適宜に実施する各種セキュリティ診断等がある


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share