もし「新規開発を丸投げしセキュアなWebアプリ開発を実現してください」と依頼されたらどうするでしょうか？開発者として開発に参加するのではなく、開発主体、つまりアプリの運営者としてして「新規開発を丸投げしセキュアなWebアプリ開発を実現すること」が目的です。開発プロジェクトのディレクションを担当し、開発は丸投げなので自分が開発に一切関わらないことが前提条件です。
セキュア開発を行うには？を考えたメモです。
選択肢
- 自分が開発しないアプリは信用できないのでWAFを導入する
- セキュアな開発が行われる要求／仕様を開発条件として付ける
1の選択肢は有り得ません。アプリ開発おけるWAFの利用は「追加のセキュリティ対策」であり、最初からWAFで防御しようと考えるのは良い選択ではないです。そもそもWAFは根本対策でない上、大抵の場合大きなコストがかかるうえスケーラブルでない場合が多いです。セキュアなアプリケーション構築を実行した上で、そこでカバーできない部分、プロトコルの脆弱性（例：Heart Breed）やWebサーバーやインフラの脆弱性（例：バッファーオーバーフロー）に対応するため、明らかに攻撃／脆弱性発見目的（例：DoS、文字列中に大量のchr()関数があるなど）でアクセスするユーザーを遮断するために導入するのが適切なWAFの利用方法です。
WAFは選択肢にならないので2を選択することになります。WAFが行う「境界防御」うち、アプリが行える事はアプリで行うのが本来の形です。WAFが行っているセキュリティ対策は基本的に「ブラックリスト型」の「入力バリデーション」です。セキュリティ対策としてブラックリスト型の対策は、大抵の場合、最適化された対策ではありません。アプリで入力バリデーションを行なえば「ホワイトリスト型」でより安全な入力バリデーションを行えます。
システム設計としてWAFを導入しても構いませんが、2の「セキュアな開発が行われる要求／仕様を開発条件として付ける」を必ず行うはずです。
アプリケーション開発の目的
議論を進める前に、まずアプリケーション開発の目的を再確認しておきます。アプリケーション開発の「丸投げ」つまり開発部分を他人任せにするあなたの目的は「価値を生むアプリを作る」ことにあります。
アプリケーション開発の目的
- 「価値を生むアプリを作る」ことが第一の目的
- 「安全なアプリを作る」ことではない
「価値」には安全性も含まれますが、「価値を生むアプリ」の要素の大部分は機能、UI設計にあります。開発責任者となったあなたの役割はセキュアな開発が行われる条件を指定し条件が守られていることを担保すれば、使い易く便利な機能設計、ユーザビリティに優れたUI設計が役割であり、アプリケーションコードの設計やセキュリティ対策の確認が役割ではありません。
セキュアな開発が行える条件
セキュアな開発が行われるよう条件を付ける場合、どのように行うでしょうか？
- 要求仕様に細かいセキュリティ要求／仕様を指定する
- セキュリティ標準／セキュリティガイドラインに則った開発を要求する
1は明らかに非効率的です。なぜなら世の中には既にセキュリティ標準／セキュリティガイドラインが公開されており、ISO 27000やPCI DSSのように標準化されている物もあります。これらの標準／ガイドラインにはセキュアなアプリケーション開発／運用の概念から、具体的な施策まで記載されています。
細かいセキュリティ要求／仕様といっても
- SQLインジェクション対策を行うこと
- XSS（JavaScriptインジェクション）対策を行うこと
のような物であったり
- SQLの実行にはプリペアードクエリを使うこと
のように不十分で安全でないセキュリティ要求／仕様を羅列してもあまり効果はないでしょう。セキュリティ対策に詳しくない開発者であっても、一応はセキュアな開発を行うように気にしてはいます。
安全なアプリケーションを開発するための要求仕様のサンプルはいくつも公開されていますが、多かれ少なかれ先に例示したような簡単で不十分な物が多いです。そのような条件でセキュアなアプリケーション開発が行われることが担保できるなら、世の中はセキュアなアプリケーションばかりになっています。
セキュアな開発が行われる条件としては、既に科学的・体系的に確立しているセキュリティ標準／セキュリティガイドラインを利用すると効率的です。
条件を付けるだけで十分か？
ISO 27000、PCI DSS標準やその他のセキュア開発ガイドラインに「基本的に準拠するように」と条件を付けるだけで十分でしょうか？標準と言っても基本的には「ガイドライン」です。具体的な例や仕様も記載されていますが、セキュリティ対策の選択／実装には様々な選択肢があります。
そもそも標準を理解していない場合も少くありません。ISO 27000ではセキュリティ対策はリスク対応として定義され、リスクを変化させる物だとしています。セキュリティ対策を「リスク削減策」「リスク排除策」だと勘違いしている開発者は少なくありません。標準やガイドラインでは「入力バリデーション」をセキュアコーディング、つまりセキュリティ対策の第一位の対策として挙げていますが、その「入力バリデーション」を「セキュリティ対策ではない」と考えている開発者は想像以上に居ます。
条件が守られていることを確認する
セキュアプログラミング（防御的プログラミング／セキュアコーディング）はプログラミング原則の１つです。しかし、残念ながらこの原則を理解していない開発者は沢山います。条件が守られていることを確認する必要があります。ここで思い出さないとならないのは、あなたの役割です。あなたの役割は開発プロジェクトのディレクションであり
- 「安全なアプリを作る」ことではない
- 「価値を生むアプリを作る」ことが第一の目的
「安全なアプリを作る」は丸投げ開発ではセキュアな開発を理解している他人に役割を任せます。アプリ安全性の担保は単純／簡単な作業ではありません。第一の目的である「価値を生むアプリを作る」作業には邪魔になります。これらは別の要員をアサインすべきで、その役割は以下のような物になります。
- 開発体制のセキュリティのレビュー
- 要求仕様のセキュリティ面でのレビュー
- 採用したセキュリティ対策、採用しなかったセキュリティ対策の管理
- コード／アプリ設計でのセキュリティ面のレビュー
- 書かれたコード、運用環境設定のレビュー
セキュアな開発を保証する要員はとは、ISO 27000、PCI DSS、CWE/SANS TOP 25、OWASP TOP 10およびOWASPガイドライン、CERT セキュアコーディング／ガイドライン、契約プログラミング、CMMI、OpenSAMMなどを理解している人である必要があります。
まとめ
「価値を生むアプリを作る」に専念したい場合、セキュリティ対策をどうするのか考えることは邪魔になります。邪魔とは言っても安全でないアプリを作る訳にもいきません。小規模なプロジェクトであれば仕方ありませんが、ある程度の規模の開発であればセキュリティレビューを行う専門／担当要員は欠かせないと思います。
小規模なプロジェクトであっても少なくとも稼働開始前に
- 書かれたコード、運用環境設定のレビュー
は行う方が良いです。ただし、
- 要求仕様のセキュリティ面でのレビュー
を行っていないと安全性担保の為には大幅な改修が必要になることもあります。小規模プロジェクトであっても
- 要求仕様のセキュリティ面でのレビュー
- 書かれたコード、運用環境設定のレビュー
は最低限行うべきです。専門家が社内に居なかったり、外部の専門家へ委託することが難しい場合でも、組織内でこのようなレビューを行うことにより問題を回避できることは多いと思います。
