# 生原稿まんまんのdraft
「Windows Server 2008 実践ガイド」でカットした原稿です
「セキュリティ」をどうするかといった話題の話をすると、多くのエンジニアはクラッカーからの侵入に対処するためにファイヤウォールの導入するとか、パスワードルールを厳密にする等の「手段」について考えてしまう傾向にある。
これは決して間違いではないが、手段を考える前に「目的」を明確にていしないと最適な手段であるかを確認する事が出来ない。
セキュリティを考えるには、「守るべき対象」を定め、その対象がどのような「リスク」にさらされているのか、そのリスクはどのくらいの「頻度」で発生し得るのか、リスクが発生した時にどのくらいの「ダメージ」があるのかを明確にしておく必要がある。
例えば、搭乗した飛行機が墜落するリスクを避けるために飛行機を使わずに陸路で移動すると言うのは、もっともらしい対策のように見えるが実はナンセンスな対策なのだ。
1年間に飛行機事故で不幸にも亡くなる方はの数は、多く見積もっても1,000人に届かない。日本国内に限定するなら、年平均は限りなく0に近い数値になる。
一方、交通事故で亡くなる方は年間5,000人前後と比べ物にならないくらい発生頻度が高いのだ。
確かに「死亡事故」と言う最悪のリスクと、「死亡する」と言う最大のダメージは同じだが、航空機搭乗でこのリスクに遭遇する頻度は限りなく0なのだ。それより自動車で死亡事故に遭遇する頻度の方がはるかに高い。
マスコミは特異点をクローズアップして報道するので、マスコミから流れてくる悲惨な状況に踊らされてテロに遭遇する不安をかきたてられても、テロ発生確率が高い場所に行かない限りテロに遭遇して命を落とす頻度は無視できる程度でしかないのである。
リスクを正しく評価し、適切な対策を施さないと無駄な費用ばかりかさんでしまうし、本来対策しなくてはならないリスクを見逃してしまう危険性すらある。
リスクを分析する方法はいろいろあるが、筆者は「頻度」と「ダメージ」に着目してリスクを分析しているので、この分析方法を簡単に解説しておこう。
リスク分析をするには、守るべき対象を定める事から始める。本書はWindows Server 2008の本なので、ICTを中心に話を進めよう。
では、ターゲットを「ファイルサーバ」に定めた事にする。次はファイルサーバに発生し得るリスクをあげてみよう。
リスクを考える時は出来るだけ具体的に考えるのが良い。具体的な事象でなければ対策が立てられないからだ。
・ サーバが経年劣化で壊れて使えなくなる
・ ビルが火災になってサーバが燃える
・ 間違ってファイルを消してしまう
・ ファイルを間違って上書きして壊してしまう
・ ファイルシステムがクラッシュしてサーバが使えなくなる
・ サーバが盗難される
・ 上階の漏水でサーバが壊れる
・ 落雷でサーバが壊れる
・ 停電でファイルシステムがクラッシュ
・ クラッカーに侵入されてサーバが乗っ取られる
これ以外にもリスクは色々あるハズだ。ここで大切なのは、リスクに対していきなり対策を考えるのではなく、これらのリスクに対して「頻度」と「ダメージ」を評価する事だ。
筆者は「頻度」と「ダメージ」を5段階に評価している。
リスク評価
| 項目 | レベル | 評価 | 例 |
| 頻度 | 0: 基本的に発生しない | 0 | 一般人がテロに遭遇する/搭乗した飛行機が墜落する |
| 1: 数十年に1度 | 1 | 甚大な被害を及ぼす天災や事故 | |
| 2: 数年に1度 | 3 | サーバが壊れる等今すぐには起きないかもしれないが必ず発生する/3重以上の多重ミス/厳重な対策が破られる | |
| 3: 年に数度 | 5 | 2重ミス、不正行為など頻繁ではないが日常的に発生し得る/一般的な対策が破られる | |
| 4: いつ起きてもおかしくない | 10 | 人為的ミス、担当者が体調不良で休む、コンピュータに対するアタックなと日常的に起きている/ターゲットに誰でも触れられる状態にある | |
| ダメージ | 0: 無し | 0 | リスクが起きたとしても実質的なダメージがほとんど無い |
| 1: 小 | 1 | 容認範囲内のダメージで、企業活動は停止しないまでも容認範囲内の業務停止が発生する | |
| 2: 中 | 3 | ダメージが大きく、容認範囲内ではあるが企業活動が停止、あるいは容認範囲以上の業務停止が発生する | |
| 3: 大 | 5 | 容認範囲以上のダメージ(損害/企業活動停止等)が発生する | |
| 4: 壊滅的 | 10 | 廃業/倒産等事業継続不能な状況に追い込まれる可能性が高い |
試しに、先ほどあげたリスクを分析してみよう。リスクスを分析するときには、リスクとリスクが発生した時のダメージを割り出して、それぞれの頻度とダメージを評価する。今回は壊れる系は致命的なデータ破損を想定したのでダメージは高い評価となっている。
頻度とダメージの評価値を掛け合わせたものをリスク指数として割り出すのがリスク分析だ。
このリスク指数を元に、対策を施すか否かを検討するわけだ。今回はリスク指数を15以下にすることを目標に定める事にした。
対策を施した後のリスク指数を再度算出して、目標値を下回っている事を確認しよう。
目標値をクリアできたら、効果に対して「トレードオフ」が妥当なのかを検討する。トレードオフとは、対策に必要な費用であったり、対策を施すことによる不便さや、余計にかかる時間等だ。これがバランスしない対策は対策として成り立たないので注意が必要だ。
妥当な対策が見つかったらからと言って、安心はしていられない。対策を施す事によって新たなリスクが発生する可能性があるからだ。例えば、サーバ室の施錠にカードキーを使ったとすると、サーバ室への侵入は防げるかもしれないが、正規の利用者がカードキーを紛失するリスクが新たに出現する事になるので、新たに発生したリスクに対してもリスク分析をする必要がある。
このようにリスク分析は何度か繰り返して実施する必要がある。
リスク分析(指数＝リスク評価×ダメージ評価)
| ターゲット | 対策前 | 対策後 | 備考 | |||||||||||
| リスク | 頻度 | 評価 | ダメージ | ダメージ | 評価 | 指数 | 対策 | 頻度 | 評価 | ダメージ | 評価 | 指数 | ||
| ファイルサーバ | サーバが経年劣化で壊れて使えなくなる | 2 | 3 | 修理完了までの1日程度業務停止 | 3 | 5 | 15 | 毎日バックアップ実施 | 2 | 3 | 1 | 1 | 3 | 致命的なデータ破損を想定 |
| ファイルサーバ | ビルが火災になってサーバが燃える | 1 | 1 | 長期間企業活動停止 | 3 | 5 | 5 | － | － | － | － | － | － | 致命的なデータ破損を想定 |
| ファイルサーバ | 間違ってファイルを消してしまう | 4 | 10 | 企業活動停止の可能性あり | 3 | 5 | 50 | 毎日バックアップ実施 | 4 | 10 | 1 | 1 | 10 | 致命的なデータ破損を想定 |
| ファイルサーバ | ファイルを間違って上書きして壊してしまう | 4 | 10 | 企業活動停止の可能性あり | 3 | 5 | 50 | 毎日バックアップ実施 | 4 | 10 | 1 | 1 | 10 | 致命的なデータ破損を想定 |
| ファイルサーバ | ファイルシステムがクラッシュしてサーバが使えなくなる | 2 | 3 | 企業活動停止の可能性あり | 3 | 5 | 15 | 毎日バックアップ実施 | 2 | 3 | 1 | 1 | 3 | 致命的なデータ破損を想定 |
| ファイルサーバ | サーバが盗難される | 3 | 5 | 機密情報が流出し壊滅的ダメージを被る | 4 | 10 | 50 | サーバ室に施錠し、機密情報は暗号化する | 2 | 3 | 1 | 1 | 3 | |
| ファイルサーバ | 上階の漏水でサーバが壊れる | 2 | 3 | 修理完了までの1日程度業務停止 | 3 | 5 | 15 | 毎日バックアップ実施 | 2 | 3 | 1 | 1 | 3 | 致命的なデータ破損を想定 |
| ファイルサーバ | 落雷でサーバが壊れる | 3 | 5 | 修理完了までの1日程度業務停止 | 3 | 5 | 25 | バックアップとUPS導入 | 2 | 3 | 1 | 1 | 3 | 致命的なデータ破損を想定 |
| ファイルサーバ | 停電でファイルシステムがクラッシュ | 3 | 5 | 企業活動停止の可能性あり | 3 | 5 | 25 | バックアップとUPS導入 | 2 | 3 | 1 | 1 | 3 | 致命的なデータ破損を想定 |
| ファイルサーバ | クラッカーに侵入されてサーバが乗っ取られる | 4 | 10 | 機密情報が流出し壊滅的ダメージを被る | 4 | 10 | 100 | セキュア設定と対策ソフト導入及び機密情報の暗号化 | 2 | 3 | 2 | 3 | 9 | |
ターゲットはサーバそのものであったり、サーバに格納されているデータであったり、通信回線であったりと、ICT関連だけでも相当数の分析必要ポイントが存在しているハズだ。
ターゲットは比較的簡単に見つける事が出来るが、ターゲットに対してどのようなリスクがあるのかを割り出すのが意外と手間なので、参考までに筆者が使っているアンチョコをお見せしよう。これ以外にもリスクは色々あるので、必要に応じてリスクパターンを追加して使っていただきたい。
リスクパターン例
| ターゲット | リスクパターン | 例 |
| 物/データ | 壊れる | 上書き/削除等のオペミスでデータを壊す メディア(HDD/CD/DVD/Tape)劣化でデータが読めなくなる 火災でサーバが消失 携帯電話水没 ノートPCを落下させて壊す |
| キャパシティオーバー | 想定以上のCPU消費でサーバが使えない 想定以上のディスク消費でハードディスクパンク 想定以上の通信トラフィックでネットワークダウン |
|
| 資格喪失 | x.509証明書有効期限中に更新手続きをしなかったので証明書か切れる 条件を満たさなくなったので資格喪失する |
|
| 紛失する | ノートPCを電車に置き忘れる USBメモリを間違って捨てる |
|
| 盗難される | クライアントPCが盗難される ファイルサーバに保管していた取引先情報が盗難される |
|
| 不正アクセス | 人事考査情報が一般社員に見られる ファイルサーバにある開発中の製品情報を営業が見る インターネットサーバがDoS攻撃を受ける |
|
| 漏洩 | 顧客リストを名簿屋に売却する 開発中の製品情報を掲示板に書く |
|
| 悪用 | Webサーバが踏み台にされる 会社の携帯電話で私用電話をする PCがウイルス/Bot感染する |
|
| 行動/サービス | 間違う/忘れる/ミスをする | メールの送り先を間違える 請求書の金額を一桁間違える |
| 停止 | サーバが壊れて業務が出来なくなっる | |
| 一時停止 | 停電でPCが落ちて業務が出来なくなる トナーが切れて見積書が印刷できない |
|
| 不達 | メールが届かず発注が出来ない 請求書が届かず入金されない |
|
| 不在 | ヘルプデスク担当が休暇を取ったためにPCが復旧できない デモ用のPCが出払っていてプレゼンテーションが出来ない |
|
| ルール/法令 | 違反 | ライセンス数以上にソフトウェアをインストールしてしまう 裏紙をメモに使って顧客に渡す インストールメディアを自宅に持ち帰って、個人のPCにインストールする |
リスク分析手法はこれ以外にもいろいろあるので、使いやすいリスク分析手法を見つけて、リスク分析をする習慣を身につけていただきたい。
リスク分析は、頭の柔らかさがモノを言うし、アタック系のリスクに対してはどのように攻撃が有効なのかを考える事でもある。
一人で考えるより、数人でブレインストーミングする方が効率が上がるので一度試してみると良いだろう。
無意識にリスク分析が出来る様になると、日常生活で発生する危険に対して敏感に反応する事が出来る様になる。少なくとも、電車の中で良く見かける網棚に荷物を置いて座席に座ったり、ズボンの後ろポケットに財布を(見える様にして)入れるような事は怖くてできなくなるはずだ。
事業継続計画(BCP/Business Continuity Plan)とは、企業活動が停止するダメージや障害が起きた時に、事業をどのように継続するのかを策定する計画だ。
軽微な所ではサーバ故障やシステムダウンにはじまり、ビル火災、地震/洪水などの地域レベル大規模災害までをレンジとして考えて、企業活動停止が許される時間どの程度なのか(事業再開目標時間)、どの程度まで縮退して事業を継続するのかを計画する。
例えば、サーバが故障しても企業活動停止は許さないとか、本社機構が失われても10日以内に企業活動を再開する等が目標として掲げられる。
この目標はICT管理者だけが考えても答えは出ない。経営層が会社としての方針と目標を出して、それを実現するためにどのようにするのかを考える事だからだ。
事業継続計画の実現方法を考える時にもリスク分析の手法が使えるので、リスク分析手法を是非活用してほしい。
| コラム:脆弱性の排除 ネットワーク/インフラセキュリティを考える時に留意すべき点は、クラッカーは身元を隠すために踏み台となるホストを日夜捜している点だ。 つまり、サーバそのものにさしたる価値が無くても、サーバを乗っ取られると攻撃拠点として悪用されてしまう脅威が必ずある事を忘れてはならない。 特に注意すべきは、OSやアプリケーションそのものの脆弱性だ。クラッカー達はこれらの脆弱性を突いて侵入を試みる。 OSやアプリケーションメーカは、脆弱性を排除するためのセキュリティパッチを提供しているので、外部(特にインターネット)に対してサービスを提供しているサーバは、セキュリティパッチ適用は必須事項である。 内部に向けてサービスを提供しているサーバに関してもセキュリティパッチを適用するのが望ましいが、稼働しているシステムが停止してしまうリスクもあるので、むやみに適用するわけには行かないが、社内専用のサーバであっても、クラッカーに侵入を許してしまったクライアントコンピュータをが踏み台にしてクラッカーが攻撃してくる危険性は日増しに高くなっている。近年良く聞く「Bot」がそうだ。 セキュリティパッチを適用する前に適用テストするのは必須だが、出来る限りセキュリティパッチを適用して脆弱性を排除する必要がある。 OS/アプリケーションメーカだけではなく、JPCERT/CC等の多くのセキュリティ機関が脆弱性情報を提供しているので、これらの機関が発信するセキュリティ情報には耳を傾けておこう。 JPCERT/CC http://www.jpcert.or.jp/ IPAセキュリティセンター http://www.ipa.go.jp/security/ Japan Vulnerability Notes http://jvn.jp/ |
Copyright © MURA All rights reserved.