なぜPHPアプリにセキュリティホールが多いのか?

第46回 セキュリティ対策を考える上で欠かせないコンテクスト

この記事を読むのに必要な時間:およそ 9 分

セーフガード(セキュリティ対策)には必要条件しか求められていない

セーフガードは「リスクを低減する実践,手順,又はメカニズム」と定義されています。この定義では「セーフガード(セキュリティ対策⁠⁠」となる対策は必要条件しか求めていません。必要なセーフガード(セキュリティ対策)は保護すべき資産やリスク評価が変わると変化しますが,セーフガード(セキュリティ対策)であるものがセーフガード(セキュリティ対策)でなくなる訳ではありません※3⁠。

また,セーフガードはリスクを低減するだけで構いません。つまりセーフガードは完全な対策でなくても構いません。多くの場合,複数のセーフガードを組み合わせて初めて完全なセーフガードになります。個々のセーフガードはリスクを低減するだけで有効なセーフガードとなります。

例えば,プリペアードクエリはSQLインジェクション対策として有用でリスクを低減します。しかし,識別子のエスケープはできず,SQL語句が入力パラメータである場合の対策としても機能しません。文字エンコーディングのバリデーションが必要な処理系もあるでしょう。プリペアードクエリはSQLインジェクションのリスクを低減しているすぎません。エスケープとバリデーション,必要な場合は文字エンコーディングのバリデーションを組み合わせて初めて完全なセーフガード(セキュリティ対策)になります。

特定の要件にのみ必要な対策であっても,セーフガードは常にセーフガードです。例えば,SQL文を実行した場合の「責任追跡性」を達成するためには,どのプロセスやユーザがSQL文を実行したのか記録する「監査ログ」を持たなければなりません。⁠セーフガード(セキュリティ対策⁠⁠」である「監査ログ」がないアプリケーションは脆弱性を持つアプリケーションであることになります。しかし,SQL文実行の「責任追跡性」がないアプリケーションは脆弱なアプリケーションでしょうか? 多くのWebアプリは「責任追跡性」を必要としておらず(リスクを許容しており⁠⁠,⁠監査ログ」は保護すべき資産のセキュリティ対策として必要ないセーフガード(セキュリティ対策⁠⁠」であるだけです。

「監査ログ」機能は明確にセーフガード(セキュリティ対策)です。例に挙げた多くのWebアプリのような場合に「セーフガード(セキュリティ対策)でない」と定義を変更してしまうようでは混乱するだけです。ですから「セーフガード(セキュリティ対策⁠⁠」となる対策には必要条件しか必要ありません。ISO規格のガイドラインではセキュリティ維持に役立つセーフガード(セキュリティ対策)はすべてセーフガード(セキュリティ対策)であり,守るべき資産やリスクによって⁠必要な⁠セーフガード(セキュリティ対策)を選ぶようになっています。ある対策がセーフガード(セキュリティ対策)になったり,ならなかったりするような定義ではありません。

同様の考え方は医療でも利用されています。例えば,健康対策です。⁠運動」は健康対策として広く薦められており,実際多くの方にとって運動は健康維持に有用です。しかし,心臓や血管に問題がある方には健康対策として幅広い分野で役立つ「運動」が命に関わる問題となり得ます。このような場合には健康にとって有害と言える「運動」ですが,有害な場合があっても「運動は健康対策ではない」とは言いません。

健康維持に役立つ対策はすべて健康対策であり,症状や状態によって必要な健康対策が変わるだけです。

医者が健康対策であるものを,ある時は「健康対策⁠⁠,ある時は「健康対策ではない」と説明すると患者が混乱するだけです。⁠運動」が逆にリスクを増やす場合,その患者に対して必要な対策ではないこと,不要な対策であることを説明することあっても,広く一般に「運動は健康対策ではない」などと言う医者は居ないでしょう。ITセキュリティのスペシャリストも医師が健康対策を考える場合と同じように,セーフガード(セキュリティ対策)を考えています。

※3

ISO/IEC 27001-2では「管理策」と記述されていますが,管理策は明確に定義されていません。セキュリティの概念を理解するにはISO/IEC 13335-1の方が優れていると考える理由の1つです。

セキュリティとリスクとセキュリティ対策の関係

セキュリティとリスク(脆弱性⁠⁠,セーフガード(セキュリティ対策)は次の図のような関係になります※4⁠。分かりやすいようにかなり簡略化しています。

図1 セキュリティと脆弱性とセキュリティ対策※5

図1 セキュリティと脆弱性とセキュリティ対策

ITセキュリティの専門家であればこの関係をよく理解しています。教科書的なセキュリティ入門書では,リスク分析で必要なセキュリティとリスクを洗い出し,回避すべきリスクと許容すべきリスク(脆弱性)を識別し,回避すべきリスク(脆弱性)に対してセキュリティ対策(セーフガード・安全対策)を適用するように解説してることが多いと思います。このプロセスはセキュリティとセキュリティ対策を正しく理解する上で重要です。

これから説明する3つの図は,例示するために簡略化した図です。

必要なセキュリティとして「機密性」が必要な場合,機密性に関連する脆弱性を識別し,識別した脆弱性のためのセキュリティ対策を選びます。

図2 機密性が必要なシステムにおけるセキュリティと脆弱性とセキュリティ対策の関係

図2 機密性が必要なシステムにおけるセキュリティと脆弱性とセキュリティ対策の関係

この場合,機密性→インジェクション→入力バリデーション,出力エスケープ,出力ヘルパーの利用という関係を持つことになります(既に説明したとおり,分かりやすいよう,図と関係は簡略化しています⁠⁠。

セキュリティ対策として真正性が必要な場合は次の図のようになります。Webアプリケーションに「真正性」が求められる場合,CSRFがリスクとなり,セキュリティトークンの利用が対策になります。

図3 真正性が必要なシステムにおけるセキュリティと脆弱性とセキュリティ対策の関係

図3 真正性が必要なシステムにおけるセキュリティと脆弱性とセキュリティ対策の関係

真正性→CSRF→セキュリティトークン,という関係を持つことになります。

「可用性」が求められる場合は,サービス不能がリスクとなり,処理・仕様の簡略化が対策の1つとなります。

図4 可用性が必要なシステムにおけるセキュリティと脆弱性とセキュリティ対策の関係

図4 可用性が必要なシステムにおけるセキュリティと脆弱性とセキュリティ対策の関係

可用性→サービス不能→処理・仕様の簡略化,という関係を持つことになります。

セキュリティ・リスク(脆弱性⁠⁠・セキュリティ対策(セーフガード)の要素が変わることはありません。変化するのはどのようなセキュリティを求め,どのようなリスク(脆弱性)に対処または受け入れ,それらに対して必要なセキュリティ対策(セーフガード)を選択するかが異なるだけです。システムによって必要または認識するセキュリティ・リスク(脆弱性⁠⁠・セキュリティ対策(セーフガード)が変わるだけで,セキュリティ・脆弱性・セキュリティ対策自体が変化する訳ではありません。

これ以降,⁠セキュリティ対策(セーフガード⁠⁠」と書かず単に「セキュリティ対策」と書きます。

※4

ISO/IEC 13335-1ではさらに細かく分類していますが,解りやすいよう変更しています。

※5

すべての脆弱性,セキュリティ対策を列挙しているわけではありません。

著者プロフィール

大垣靖男(おおがきやすお)

University of Denver卒。同校にてコンピュータサイエンスとビジネスを学ぶ。株式会社シーエーシーを経て,エレクトロニック・サービス・イニシアチブ有限会社を設立。
オープンソース製品は比較的古くから利用し,Linuxは0.9xのころから利用している。オープンソースシステム開発への参加はエレクトロニック・サービス・イニシアチブ設立後から。PHPプロジェクトでは,PostgreSQLモジュールのメンテナンスを担当している。

URLhttp://blog.ohgaki.net/

著書