情報BOX 【 知って得するサイバーセキュリティ講座 】
第5回権限と脆弱性
2012年3月23日
権限とエクスプロイト(※)
OSの機能のうち、セキュリティ上最も重要な機能が、権限管理となります。権限とは、OSが管理するファイルや機能に対して、ユーザが使ってもよいかどうか設定を行うことです。
プログラムが実行されると、実行したユーザの権限の範囲内でしかプログラムは動作することができません。ユーザが権限を持っていないファイルに対してプログラムを使ってアクセスしようとした場合、OSによってそのアクセスは拒否され“エラー”として処理されます。
コンピュータに存在するデータは、この権限によってガチガチに守られています。攻撃者はこの権限をなんとか奪うことで、必要な情報を奪おうとするのです。では、この権限を奪う方法とは何でしょうか。
それは、すでに権限を持って動作しているプログラムを乗っ取るのです!!
この、権限を乗っ取るために悪用されるのが、脆弱性です。攻撃者は、脆弱性を侵入口にして、攻撃者の用意したエクスプロイトを送り込みます。送り込まれたエクスプロイトが活動を開始すると、本来のプログラムの動作が乗っ取られ、権限が盗まれてしまいます。
こうなってしまうと、後は、攻撃者の思い通りです。ユーザの権限の範囲で、さまざまな悪意のある活動が行われてしまいます。
もし、管理者権限で動作しているプログラムが乗っ取られてしまうと、コンピュータのすべての機能とファイルが悪用されてしまうのです。
(※)エクスプロイト:プログラムのセキュリティ上の脆弱性を攻撃するために作成されたプログラム
根絶できないバグ
よく、ソフトウェアにはバグがつきものと言われることがあります。理屈的には、一切のバグをなくすことができれば、悪用できるバグである脆弱性もなくすことができるのですが、なぜ、バグをなくすことが難しいのでしょうか。
発見したバグを修正することを“デバッグ”と言いますが、修正するべきバグを発見するためには、“テスト(試験)”を行わなければなりません。この“テスト”の進め方に問題があります。
プログラムの開発者は、まずプログラムがこのように使われるであろうという、“通常想定される範囲”の使い方を決めます。これを“仕様”と呼びます。この“仕様”に従って、プログラムを作成するのです。
開発者は、この“仕様”に基づいて、“通常想定される範囲”のテストを行います。プログラムが“仕様”通りに動作するかチェックするのです。この“仕様”を基にしたテストを行うことで、動作上の問題となる“バグ”を発見することができます。そのため、開発者は、せいぜい、“仕様”通り正しく動作するかのテストしか行いません。“仕様”を満たすか確認するだけでも、膨大なテスト項目をこなす必要がある場合が少なくないのです。
しかし、“仕様”に基づくテストでは、可能性のある〝すべての〟潜在的なバグを発見することは難しいのです。潜在的なバグとは、“仕様”には表れてこない、ある特定の状況下でしか起こらないと思われていることが起こることで、初めて問題となるようなバグなのです。
潜在的なバグをすべてなくすためには、想定以上の、すべての組み合わせに関してテストを行う必要があります。その組み合わせとは、事実上、無限に近いものとなり、莫大なコストがかかってしまいます。
安全性とコストは常にトレードオフの関係にあります。そのため、潜在的なバグを完全になくすということは、非常に難しいのです。
根絶できない脆弱性
潜在的なバグをすべてなくすことが不可能であるということは、脆弱性をなくすことも非常に困難であるということを意味しています。
脆弱性をなくすために、手当たり次第にテストするというのは現実的ではありません。攻撃者がどのように攻撃を行うか、手の内を知り尽くして、“擬似的に攻撃を行う”というテストが必要となります。
このような“疑似的に攻撃を行う”テストのことを、“ペネトレーション・テスト(侵入テスト)”と呼びます。“ペネトレーション・テスト”を行うことで、潜在的バグの中から、実際に問題となる脆弱性を浮かび上がらせるのです。
では、“ペネトレーション・テスト”を必ず行えば脆弱性をなくせるのでは?
確かに、その通り。脆弱性はなくすことができます。しかし、それには一つ、大きなハードルが存在します。
残念ながら、攻撃者の手の内を知り尽くした専門家が少ないのです。攻撃の知識を持つエンジニアが、開発の現場に少ないため、すべての開発で“ペネトレーション・テスト”を行うことが難しいのです。
唯一の解決方法は、セキュリティのプロフェッショナル・サービスを提供する専門会社に、“脆弱性診断サービス”を依頼し、“ペネトレーション・テスト”を行ってもらうことです。
つまり、システム開発会社にソフトウェアの開発を依頼する場合は、合わせて、“脆弱性診断サービス”を依頼する予算を、あらかじめ確保しておく必要があるのです。
◆ 次回は「人間の持つ脆弱性」についてお届けします。
セミナー講演のご依頼・お問い合わせはこちらから。
過去の記事一覧
- 2011年11月1日 第1回 サイバースペースのセキュリティ
- 2011年12月20日 第2回 なぜサイバーセキュリティが必要か?
- 2012年1月25日 第3回 サイバーセキュリティの意義
- 2012年2月29日 第4回 エラーとバグと脆弱性
- 2012年3月23日 第5回 権限と脆弱性
- 2012年4月12日 第6回 人間の持つ脆弱性
- 2012年5月24日 第7回 サイバー攻撃を受けたら何をするべきか【1】
- 2012年6月27日 第8回 サイバー攻撃を受けたら何をするべきか【2】
- 2012年7月26日 第9回 サイバー攻撃を受けたら何をするべきか【3】
- 2012年8月22日 第10回 サイバー攻撃を受けたら何をするべきか【4】
- 2012年9月19日 第11回 汎用ソフトウェアの脆弱性対策
- 2012年10月17日 第12回 ゼロデイ攻撃・標的型攻撃と新型ウイルス対策
- 2012年11月21日 第13回 Webアプリケーションの脆弱性対策
- 2012年12月19日 第14回 Webアプリケーションのセキュリティ設計
- 2013年1月23日 第15回 サイバーセキュリティを実現する
- 2013年2月20日 第16回 デジタルフォレンジックスの導入
- 2013年3月26日 第17回 情報漏洩対策
- 2013年4月24日 第18回 メールの添付ファイル禁止とファイル送信サービス
- 2013年5月22日 第19回 私物モバイル対策(BYOD対策)
- 2013年6月19日 第20回 新型サイバー攻撃には多層防御で対抗する
- 2013年7月23日 第21回 マスコミ社会から口コミ社会へ
- 2013年8月22日 第22回 批判にさらされる企業
- 2013年9月26日 第23回 サイバースペース上での企業の責任を知る
- 2013年10月23日 第24回 顧客の情報を預かる責任
- 2013年11月20日 第25回 個人情報取得のポリシー
- 2013年12月18日 第26回 即応性の危機管理広報
- 2014年1月6日 第27回 情報という経営資源を守れ
- 2014年2月19日 第28回 利用者中心のサイバーセキュリティへ向けて
- 2014年3月13日 第29回 安全・安心なサイバー社会の実現(最終回)