セキュリティ診断だけでは不十分？ラックのシステム開発でのセキュリティ取り組み

ラックではセキュリティ対策サービスだけでなく、WebアプリケーションやWebサイトなどを始めとした企業情報システムの開発や運用を行うシステムインテグレーションサービスを提供しています。Webアプリケーション開発とセキュリティ分野におけるラックの「御意見番」である3人が、「アプリケーション開発のセキュリティはどうあるべきか？」をテーマに、Webアプリケーションセキュリティのこれまでとこれからをリレー形式で語ります。

今回は技術革新部 部長の藤本が担当します。
藤本は、多数のWebアプリケーションの開発を経験後、フレームワーク開発や大規模システム開発案件において、アーキテクトとして従事しました。アーキテクトとしての活動だけでなく、開発経験を活かしたセキュリティ教育やセキュリティコンサルティングサービスも提供してきました。現在は、技術革新部 部長の立場から、社内のシステム開発の「最後の砦」としてシステム開発の技術支援やアーキテクトの育成に取り組んでいます。

注目されるアジャイル開発やDevOps

デジタル技術を活用して組織やビジネスモデルを変革するために、デジタルトランスフォーメーション（DX）に取り組む企業が増えています。それに伴い、サービスの企画から提供までにかけられる時間は短くなり、システム開発に求められる速度は一段と速くなっています。

不確実性が高まる市場環境と、高速化するシステム開発スピードに対応するため、アジャイル開発やDevOpsという手法に注目が集まっています。

アジャイル開発とは、システムが提供する価値に重きを置いた開発手法です。重要度の高い機能やサービスから順番に開発に着手、リリースし、ユーザの反応を見ながら継続的にシステムをブラッシュアップしていきます。DevOpsとは、開発チーム（Development）と運用チーム（Operation）とが密接に連携して開発から運用のサイクルを高速化し、ビジネスの価値を確実に素早く利用者に届け続けようというコンセプトです。ラックでも2018年にアジャイル開発センターを設立し、アジャイル開発やDevOpsに取り組んでいます。

そして、システム利用者に提供する価値を高めることと同等に、システムのセキュリティを確保することは重要な経営課題です。アジャイル開発やDevOpsなどの高速な開発サイクルにおいても、システムのセキュリティを担保する取り組みを一体化させ、開発スピードを損なわずに構築するシステムのセキュリティを確保しなければなりません。

では、アジャイル開発やDevOpsを採用する場合、どのようにセキュリティ対策に取り組んでいけばよいのでしょうか。

セキュリティ診断だけでは大丈夫とは言えない？

アジャイル開発やDevOpsを推進する開発チームでは、プログラミング中にSQLインジェクションやクロスサイトスクリプティングなどの脆弱性が混入していないかを検査する静的セキュリティ診断（SAST）や、Webアプリケーションを実際に動作させて脆弱性の有無を検査するセキュリティ診断を実施するケースが多くあります。一見すると十分なセキュリティ対策を実施しているように見えますが、次のような設計要素に起因する脆弱性に対しては十分なセキュリティ対策を行えていると言えるでしょうか。

• パスワードをデータベースに保存する際に適切にハッシュ化しているのか
• ユーザ登録の際の本人確認はこの仕様で十分か
• 重要情報をシステム利用者が閲覧した際に、どのようなログを記録しているか

このようなセキュリティ上の問題は、一般的なセキュリティ診断では見つけることができません。パスワードを平文でデータベースに登録するようにプログラミングされていたとしても、一般的なセキュリティ診断では発見することは困難です。また、システムの仕様として本人確認が必要十分かどうかをセキュリティ診断で指摘することも同様です。

このような仕様や設計に起因するセキュリティ上の問題は、要件定義や設計などの早い段階で確認することが大切です。たとえば、認証で使うパスワードを保存する際にハッシュ化していたとしても、MD5など推奨されないハッシュアルゴリズムを使用していないかどうかなどは、設計の段階で考慮しておく必要があります。また、パスワードのポリシーをどのようなものにするかは、業界標準などを踏まえて要件定義の段階で検討しておくべきです。

アジャイル開発やDevOpsでは、どのようにセキュリティ対策を行うべきか

システム開発においては、どのようにセキュリティ対策に取り組んでいけば良いでしょうか。実は、アジャイル開発やDevOpsにおいて特別な対策が必要ということではありません。開発するシステムの要件定義の段階や、システムの設計段階から適切に設計や実装方式を評価することが重要なのです。開発プロセスがウォーターフォール方式であろうとアジャイル開発であろうと変わりません。

適切なセキュリティ対策を行うためには、要件定義や設計段階からセキュリティに関する評価をシステム開発サイクルの中に取り込んでいくことが必要です。「パスワードを適切な方法でハッシュ化してデータベースに保存しているか？」「本人確認のフローは必要十分か？」「適切なログを記録しているか？」など、各段階で見直しをすることをおすすめします。こうすることで、プログラミングやテストの段階でセキュリティに関する検査を行うだけよりも、よりセキュアなシステムを開発することができます。そしてアジャイル開発においても、セキュリティに関する要件の策定や評価を開発工程に取り込んでいくことで、開発のスピードを落とすことなくシステムをリリースし続けられます。

Webアプリケーションのセキュリティ上の問題点を回避するために、開発者はどうしたら良いか？というのを示したものが第一回でご紹介した「OWASP Proactive Controls」です。OWASP Proactive Controlsでも、「セキュリティ要件の定義」が安全なWebアプリケーションを開発するうえで「最も大事」と位置付けられ、セキュリティ要件について設計段階で評価することを重要視しています。

もし、現在の開発プロセスでこのような取り組みをしていないとしたら、気づくのが難しい脆弱性を作りこんでいるかもしれません。そのような場合には、アプリケーション設計者やアプリケーション開発者とは別の第三者に、設計や実装方式に関するセキュリティ評価をしてもらうことが必要です。

システムインテグレーション事業で取り組んでいる、Webアプリ開発のセキュリティ対策

ラックのシステムインテグレーション事業でWebアプリケーションを開発する際、どのようにセキュリティ対策に取り組んでいるのかの一例をご紹介したいと思います。

ラックには、お客様のご要望をもとにアプリケーション開発を提案・開発するシステムインテグレーション事業と、セキュリティコンサルタントをはじめとしたセキュリティサービス事業があります。お客様からシステム開発のご相談を受けたシステムインテグレーション事業のエンジニアは、お客様へのご提案を検討するにあたり、注意すべきシステム要件上の箇所を確認し、お客様とセキュリティ要件についても提案段階から大枠で抑えるべきポイントを決めていきます。

実際の要件定義フェーズでは、ラックで保有しているシステムセキュリティ要件ガイドラインを元に、システムの規模・サービスの提供範囲など様々な要因を踏まえて、システムが具備すべきセキュリティ要件を取捨選択し、セキュリティ要件定義書としてまとめます。

セキュリティ要件定義書には、認証・認可の実装方式にかかわる項目や、パスワードの文字種・桁数そして保存時のハッシュ化の方式についてなどが記載されています。そして、システムで扱う重要情報の定義、ログの取り扱い方法など、システム設計の段階で気にすべき点から開発や運用フェーズに入ってからのことを考慮した項目も含まれています。

セキュリティ要件定義書には、どのようなシステムであっても共通で対応すべき項目・内容もあれば、そのシステム固有の内容もあります。ラックのシステム開発エンジニアであっても、セキュリティ要件について検討するにはセキュリティコンサルタントの力を必要としています。

設計フェーズや開発フェーズの途中でも、セキュリティ要件定義に書かれていることを随時確認しながら開発していきます。しかし、設計や開発を進めていくと、当初検討したセキュリティ要件を満たすことが困難な場面に遭遇します。そのようなときは、セキュリティコンサルタントと協議し、代替案などのアドバイスをもらいながら設計・開発を進めます。設計や開発の作業中にセキュリティの専門家に相談できるので、作業のスピードを落とすことなく開発を進められます。

また、昨今のシステム開発においては、SaaSなどのサービスとの連携や、サードパーティーのプロダクトを組み込んでシステムを構築していくケースが多くあります。エンタープライズ企業がオープンイノベーションに取り組む中で国内外のベンチャー企業のプロダクトを部分的に採用するようなケースも増えています。このような場合に気を付ける必要があるのがシステムのサプライチェーンリスクです。

システムに組み込む外部プロダクトのブラックボックスな部分を踏まえ、セキュリティ要件の確認や実装方法の変更に関しても許容可能かどうかを、セキュリティコンサルタントに相談しながら進めていくと良いでしょう。システム開発に参画するセキュリティコンサルタントの側でも、システム開発チームに伴走しながら一緒にプロジェクトを進めていく気構えが必要です。

こうしてお客様のニーズを満たす最小限のプロダクト（MVP：Minimum Value Product）をリリースします。そしてアジャイル開発のプロセスにそってサービスを拡張していく際にもセキュリティ要件についても都度、見直しを実施していきます。なお、当然ですが、プログラム開発が完了したのちには、ソースコードのセキュリティ診断で実装漏れやうっかりミスが無いかどうかを検査することで、第三者によるチェックを実施します。

さいごに

今回ご紹介したようなセキュリティ対策のアプローチは、ウォーターフォール方式の開発手法であれアジャイル開発手法であれ、すべての領域で言えることです。アプリケーション開発チームと運用チームとの協調（DevOps）に、セキュリティチームも加わる（DevSecOps）ことが必要です。ぜひこの機会に、現在の開発プロセスを見直すきっかけになればと思います。