セキュリティ診断だけでは不十分？安全なWebアプリケーション開発で最も大事なこと

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

初回は、執行役員SIS事業領域担当で、ラックのCTO（最高技術責任者）も務める倉持浩明が担当します。倉持はWebアプリケーションの黎明期からセキュリティ対策に取り組んでおり、多くの企業のエンジニア向けにセキュア開発に関するトレーニングを提供してきました。『基本がわかる安全設計のWebシステム^*』（日経BP）などの著書があり、講演活動などを通じて安全なWebアプリケーション開発の普及に取り組んでいます。

* 基本がわかる安全設計のWebシステム - 倉持 浩明

Webアプリケーションの半数に追加のセキュリティ対策が必要

WebアプリケーションやWebサイトを開発・運用している企業の多くは、セキュリティ診断を実施しています。ラックの「セキュリティ診断レポート 2020 秋」によると、リスクレベルの高い脆弱性を検出する割合はここ数年減少傾向にあるようです。

しかし、減少傾向とはいえ、ラックが実施したWebアプリケーション診断では48％のWebアプリケーションにおいて、重要な脆弱性を検出しています。実に半数近くも、セキュリティ対策が必要な状況にあります。

セキュアなWebアプリケーション開発のノウハウ

リスクレベルの高い脆弱性を検出する割合が減少傾向にある理由として、開発現場でセキュアなWebアプリケーション開発のノウハウが浸透してきたことと、開発者が意識せずとも開発ツールでセキュリティ対策を実施できる環境が整備されてきたことが考えられます。

開発者の間でセキュアなWebアプリケーション開発のノウハウが浸透してきた背景に、業界団体やコミュニティの存在があると筆者は感じています。

独立行政法人 情報処理推進機構（IPA）の『安全なウェブサイトの作り方』やOpen Web Application Security Project（OWASP）の『OWASP Top10（オワスプ トップテン）』は、Webアプリケーションのセキュリティ対策を考える上でのデファクトスタンダードになっています。OWASPはWebアプリケーションのセキュリティに関するプロフェッショナルが集まる非営利団体で、日本国内でも各地で勉強会などのイベントが積極的に開催されています。

勉強会などのイベントでは、有識者による講演や、各社の取り組み事例の共有（ベストプラクティスだけでなくアンチパターンも含めて）がカジュアルな雰囲気のもとで行われます。こうしたイベントを通じて、セキュリティ専門家とアプリケーション開発者との間に共通言語が生まれ、セキュアなWebアプリケーション開発のノウハウが開発者の間で共有・浸透してきたのです。

さて、OWASP Top10とは「最も重大なWebアプリケーションリスク」をトップテン形式で紹介し、その基本的な対策方法を示すものです。ランキングは定期的に更新され、最新版は2017年11月20日に発行されています。なお、日本語版はOWASPジャパンの有志により2017年12月26日に発行されています。わずか1カ月で日本語訳版が公開されていることからも、コミュニティのパワーを感じます。

安全なWebアプリケーション開発でもっとも大事なこと

OWASP Top10で示されているようなWebアプリケーションのセキュリティ上の問題点を回避するために、開発者はどうするべきかを示したのが「OWASP Proactive Controls」です。OWASP Top10ではリスクの視点から列挙しているのに対し、OWASP Proactive ControlsではWebアプリケーションのセキュリティレベルを高めるために取り組むべきポイントが、重要度順に列挙されています。

最新版は2018年版ですが、1つ前の『OWASP Proactive Controls 2016』の日本語訳ではわれわれも翻訳に協力しました。

OWASP Proactive Controlsの中で、安全なWebアプリケーションを開発する上で「最も大事なこと」として提示されているのは「セキュリティ要件の定義」です。

ほとんど全てのシステム開発は「要件」から始まります。セキュリティも同様です。伝統的なウォーターフォールやV字モデルのシステム開発プロセスでは、初めにシステムが備えるべき機能を要件として定義します。たとえばECサイトであれば、「商品を選択し買い物かごに入れられる」「会員登録できる」「決済が完了したらサンクスメールを送信する」などです。ユーザーの目線に立って「どのようなことをシステムに実現してほしいか」という要望を整理していきます。

ただし、システムを開発するにあたっては、このような「ユーザー目線」の要件を定義するだけでは不十分です。パフォーマンスやデータ容量そしてバックアップなどいわゆる「非機能要件」も併せて整理する必要があります。こうした非機能要件はシステム開発のプロである開発者がリードし、整理していくことになります。セキュリティ要件も、非機能要件の最たるものです。セキュリティ要件についても、要件定義フェーズで整理・検討しておくことで手戻りを防げます。

セキュリティ要件については、セキュリティの専門家によるアドバイスやレビューを基に整理していくのが効果的です。セキュリティ要件とは業界標準や法律および過去のセキュリティ問題の再発防止策などから導出されるものです。セキュリティ要件をイチから検討していくのではなく、検証済みで再利用可能なガイドやフレームワークを利用していくと、効果的にセキュリティ要件を定義できます。

業界標準や法律上従うべきセキュリティ要件としては、政府機関の情報システム調達についてセキュリティ要件を適切に組み込むための「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」や、クレジットカード会員データを安全に取り扱う事を目的として策定された、クレジットカード業界のセキュリティ基準であるPCI-DSSなどがあります。開発チームが詳細なセキュリティ要件を策定する際に活用できるリソースには『OWASP Application Security Verification Standard（OWASP ASVS）』などがあります。

アジャイル開発でセキュリティ要件を定義するには

それでは、アジャイル開発においては、セキュリティ要件はどのように扱えばいいのでしょうか。

アジャイル開発は、ウォーターフォールやV字モデルのシステム開発プロセスのように「最初にすべての要求を明らかにする」ことは想定していません。アジャイル開発が得意とする領域において、要求とは「徐々に明らかになっていくもの」であるからです。アジャイル開発では「ユーザーが本当に必要としているもの（要求）」を継続的なデモやフィードバックを通じて学習していきます。

ユーザーはソフトウエアが持つべき「ふるまい」についてはフィードバックできますが、セキュリティ要件についてはできません。ECサイトのユーザー登録画面を例とすると、AよりBの方がユーザー登録数増加につながる「ふるまい」であると分かっても、その画面にCSRF対策のトークンが必要かどうかについては、ユーザーには分かりません。

アジャイル開発においては「ユーザーの見た目にわかりやすい要件」と「ユーザーの目に触れることのない非機能要件」の間で実装の優先順位を付けるのは、後になればなるほど難しくなります。そしてセキュリティ要件は後から付け足すのが難しいケースが多くあります。ですから、アジャイル開発においても、初期段階からセキュリティチームをメンバーに加えてセキュリティ要件を検討し実装していくようにしましょう。

OWASP Proactive Controls 2018では、アジャイル開発においてセキュリティ要件を定義する場合に使われることの多い方法である「ユーザーストーリー」を紹介しています。アジャイル開発チームに参加するセキュリティエンジニアが、アジャイル開発の流儀を学ぶことで、開発チームと早期に連携できます。

さいごに

今回は、セキュアなWebアプリケーション開発で必要な要素として「セキュリティ要件定義」を紹介しました。ウォーターフォール型であれ、アジャイル開発であれ、要件定義の段階からセキュリティ専門家によるレビューとアドバイスを組み入れていくことが必要です。

なお、ラックではセキュリティ対策とWebアプリケーション開発の双方の視点から開発段階、工程に応じたセキュリティ施策を提案・支援するサービス「システムセキュリティデザイン」を提供しています。Webアプリケーション開発を熟知したエンジニアが、セキュリティについてアドバイスしますので、気軽にお問い合わせください。