セキュリティー管理責任者はいま何を考えるべきか

企業のリスクをマネージする戦略考システムが安定して稼働し、サービスを途切れなく提供することが、セキュリティーの達成目標である。そして、それはシステムの耐故障性確保、つまりシステムの稼働確保にもおよぶ。なにも外部からの第十回稼働確保とセキュリティー管理攻撃やウイルスと戦うことだけがセキュリティー管理ではない。稼働確保のための基本的な技術をもう一度見直そう。
text :

山口英 奈良先端科学技術大学院大学情報科学研究科教授

義する場合が多いだろう。

うのが普通である。
「システムのあるべき（1）稼働しているシステムが予期しない形姿」
をもう一度見直してみてほしい。セキ

この連載では繰り返し述べているが、で停止することはないし、また停止しュリティー管理の立場から見てぴたりとセキュリティー管理とは、ひと言で言えているシステムが予期しない形で稼当てはまる「あるべき姿」であるが、セキ働することもない。

ュリティー管理においてはなにも特別なセキュリティー管理の役割を整理

ば、「管理対象である情報通信システムがどのような状態に保たれるべきかを定（2）利用者ごとに適切な権限が与えられ、義し、その状態をできる限り維持するこその権限の範囲を逸脱する行為をしとに努力する一連の作業」である。

ないようにすること。仮に利用者がシステム管理を真面目に適正に行って考え方ではない。システム管理全般から考えても「あるべき姿」である。

セキュリティー管理をこのように定義し権限の範囲を逸脱しようとしても、そいれば、セキュリティー管理を行うのは必た場合、セキュリティーポリシーとは、「保れが防御され、その行為自体が検出然的なことである。適切に設計されてたれるべきシステムの状態はどのようなされること。

実行されているシステム管理がなければ、ものであるかを整理し、その状態を維持（3）システムが管理する資源の割り当てするための作業に関して基本的な考え方が円滑かつ安全に行われ、システムを記述すること」といえる。

が稼働するのに必要な資源が枯渇しセキュリティー管理を構築することはできない。
この意味において、最近になってセキ

また、システムのあるべき姿（状態）かないように維持されること。

ュリティー管理が重要だと声高に述べ、ら逸脱してしまう可能性がある事象を、シ（4）システムがどのような状態になってい最優先の作業であるかのように述べる専ステムに対する脅威と捉える。通常は、るかを説明できるようになっているこ門家もいるが、その一方的な論調には筆どんなに単純なシステムであっても多種と。

者は素直に賛同できない。セキュリティー管理はシステム管理の一連の必須作

多様な脅威が存在するので、それぞれの脅威の損害期待値等を勘案してリスク評

システム管理との関係決め、それに従ってセキュリティー管理の業の1つであり、他のシステム管理作業とはけっして切り離して考えることはでき価を行い、各脅威への対策の優先度をセキュリティー管理は、システム管理のないのだ。

ために行われる一連の作業に含まれるしたがって、今までセキュリティー管理ものだ。しかし、他のシステム管理作業が適正に行われてきていなかったので、うな状態なのか。少し大雑把ではあるが、と独立して考えることはできない。他のこれからセキュリティー管理をしっかりし次の4つの条件を満たしている状態と定システム管理作業と相互に深く関係し合なければならないと考えている組織に読具体的な作業を実施する。
さて、システムがあるべき姿とはどのよ

156 +++ internet magazine 2004.03 +++インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

セキュリティー管理責任者はいま何を考えるべきかないということがわかるだろう。

者の皆さんが所属しているとしたら、同時ば、それぞれのユニットに対して別々にシステム管理全般についても再点検のUPSを用意して接続する。

し、管理体制を作り直す必要があるだろ（3）各 UPS は、別々の電源供給回路にう。セキュリティー管理だけを特別視する接続して、単一のブレーカー断によっ組織だとしたら、まず確実にシステム管理て両方の電源供給が停止しないようの本質が理解されていないと考えられるにする。

からだ。

上記3点の対策は、現在のデータセンシステムの稼働確保問題を考える場合ターのシステム環境では普通に行われてに定石とも言える方法がある。それが、いることである。しかし、本当にこれで十Single Point of Failureの除去である。

止まらないことの難しさ

では、この問題はどのように考えたらよいのだろうか。

障害からシステムを守る基本分なのだろうか。もう少しシステムのこと

Single Point of Failureとは、ある場本題に戻ろう。セキュリティー管理のを考え進めていくと、まさにパラノイア的所の単一故障によってシステム全体の稼中でも重点目標として「システムの稼働確（妄想的）に想像力を膨らませ、その対策働が停止してしまうことである。電源事故

保」がある。簡単に言えば、システムが予を考えてしまう。

対策で考えると、システムに用意されてい定どおりに稼働し、不測の事態で停止したとえば、電力会社からの供給回線がないように管理作業を行うことである。

1つだけでは不安なので、別々の供給回

言い換えると、稼働中のシステムが停止線を用意し、1つの引き込み回線に障害Single Point of Failureを発見するこる 1 つだけ の 電 源 ユ ニットは、まさにSingle Point of Failureと言える。

しないようにし、安全な起動や停止を実が発生したとしても大丈夫なようにしておと、発見した Single Point of Failureの施し、サービスを計画どおりに提供する

くことを真剣に考えているデータセンタ与えうる影響を評価すること、そして、そための維持管理をすることである。

ーもある。またUPSによって可能となるのSingle Point of Failureを除去する作

これを実行するためには、何がシステ

電源供給も10分というようなものではな業を行うことが、まさに障害からシステムムを停止させてしまう可能性があるか、そく、12時間というような長時間を考えてを守る基本である。

してそのリスク対策として何をすべきなのいるところもある。

Single Point of Failureの除去には、かを考えなければならない。ところが、シ

さらに、場合によっては自家発電設備

通常は予備機材を用意するのが一般的

ステムの稼働確保のために考えられるリを用意して、電力喪失事故に備えているである。たとえば、単一のコンピュータシ

スクに思いを巡らすと、多種多様なものデータセンターも多い。特に阪神淡路大ステムは、それ全体が Single Point ofがあることに気づくだろう。

震災では、建物倒壊や通信回線断といっFailureになってしまう。そこで、負荷分散た被害をほとんど受けなかったビルであ装置（ロードバランサー）を使って2台の情報通信システム構成の設計においてっても、電源供給が48時間近く停止したシステムに負荷を分散させるようにして、は、電源周りについては十分に考えてお地域が広くあった。このことを教訓にし1台のシステムが故障したとしても大丈夫かなければならない要素である。通常は、て、真剣に自家発電設備を用意した組織なようにしておくことで対応する。またネUPSを用意して停電や電源瞬断があっも数多くあると聞いている。

ットワーク機器の場合には、すべてがたとえば、電源問題を考えてみよう。

たとしても、システムが停止しないような

このように見ていくと、「システムの稼Single Point of Failureになるケースが対策をするだろう。しかし、これだけで十働確保」に重点を置いた電源設計を見た多い。このため、ネットワーク機器と回線分な対策であると言えるだろうか。

だけでも、単純かつ低コストな対策からに関しても冗長化（二重化）していくこと大がかりな対策までを施す可能性があるが一般的に行われる。

真面目にシステムのことを考えると、次のようなことも考えなければならない。と言えよう。

このように、システムを構成する要素（1）
システム本体に用意されている電源さらに深く考えていくと、電源問題だけから、システム全体、さらには回線やネッユニットそのものが二重化されているではなく、それ以外にも多くのリスクに対トワークといったところまで、くまなく調べシステムを利用する。これにより電源応していく必要があるのだ。このため、シて Single Point of Failureを発見し、そユニット故障の問題を避けることがステムの稼働確保をどのようにしていくのの除去を冗長化によって対処していくのできる。

かという問題については、幅広い視野とが定石である。また、最近ではそのため洞察力をもって対策を考えなければならの機器やソフトウェアが数多く提供され（2）電源ユニットが二重化されているなら

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D+++ internet magazine 2004.03 +++157ている。いろいろなレベルでの Single言わない。しかし、過去10年間の突発事たにもかかわらず、大規模災害への対策Point of Failureを取り除くことができる

故を考えてみると、地震、短時間集中豪は不十分であると思う。

し、また同時にどのような技術が利用可

雨による浸水、火災などは十分考える必筆者自身は1995年の阪神淡路大震災

能かをたえず調べておくことも、運用技術要がある。また、爆弾テロなどによる破に大阪で遭遇したが、その衝撃は想像を者として重要なことだ。

壊行為も、日本ではまだまだ確率が低い絶するものであった。いまだに生々しく記のかもしれないが、当然考えておく必要憶に刻み込まれている。しかし、現在のがあるだろう。もちろん、この種の突発事

情報通信システムに大きく依存した社会故に対応しなければならないシステムはは、残念ながら一度も阪神淡路大震災ク限定されるが、多くのユーザーにサービラスの大地震の洗礼は受けていない。しスを提供しているシステムの場合には、たがって、私たちは一度も経験してない一度は検討したほうがよいだろう。

ことを、次に起こるであろう大震災では戦略
1Single Point of Failureを見つけ、冗長化を施してシステムが稼働停止にならないようにすることが定石である。

突発事故は常に念頭に置く
Single Point of Failureを除去するよ

さて、この種の突発事故に対する対応対処しなければならない。この意味で、

うにシステムを構築していても、想定され策にも定番がある。それは物理的に離れ私たちはもっと入念に検討をすべきだとる脅威によっては冗長化が単純にできなた場所に、バックアップシステムを用意し常々思うのだ。

いものもある。それが大規模災害である。ておくことである。同時にシステムが壊滅

たとえば、システムを設置しているデーしない距離にシステムを隔離して設置し、タセンターに不審者が侵入してシステムどちらかのシステムが故障しても大丈夫を破壊し、全面的に利用できない状況がなように対応するのである。

人的事故も稼働確保を阻止する
さらに、システムの稼働確保を阻止す発生する可能性を考えてみよう。あるい

典型的には、東京と大阪にサーバーをる大きな要因の1つに「人」がある。今回は、大地震が発生し、東京一帯が壊滅的置くという形態である。あるいは、最近で紹介した定石や定番の考え方で、システな打撃を受けたとしよう。このような場は国際回線の急速な広帯域化を考えて、ムに冗長性を確保したものの、土壇場で合、単純にシステムの Single Point ofシステムを日米2か所に分散して設置す

人間が介在することによってトラブルが発Failureを除去しているだけでは対応しきるところもある。このように、物理的にシ生することがある。

れない。システム全体が壊滅してしまうステムを分散して設置するということは当可能性が否定できないからだ。

たり前のことと考えるべきだろう。

このような話をすると、「そんな荒唐無稽な状況を想定する必要があるのか。そんなことが起きるものか」と言う人も多い。しかし、過去10年を思い出してほし戦略
２

バックアップシステムを物理的に数百 km 以上隔離して設置し、大規模災害に備えるのもシステムの稼働確保での定石である。

い。大地震はめったに発生しないと誰もが信じていた神戸辺りで、阪神淡路大震

たとえば、こんなことが実際にあった。
情報提供を行うシステムで、バックアップ用のシステムを用意しておきながら、予算的な問題で負荷分散装置を用意することができなかった。そのため、障害発生時にはオペレーターがネットワーク回線をつなぎ直すというシステムを考えた。

大規模災害への対策は入念に災が発生し、米国ではハイジャックされた

当然、この2つのシステムの内容は同期するように設定しておかなければならな飛行機がビルに突っ込み、国際的な金余談となるが、いま東京を関東大震災融センターは一瞬にして壊滅した。さらや阪神淡路大震災クラスの大地震が襲きには、見事にこの装置は機能しなかっに、自爆テロによって世界中の主要ビルったとしよう。わが国の経済活動は壊滅た。管理者が、2つのシステムの内容をが破壊される可能性が跳ね上がってしま的な打撃を受けると思われるが、その中同期させる作業を忘れていたために、シったのである。これを考えると、東京で定でもしぶとく生き残っていられる企業はどステムの内容が古いまま放置されていた

常的に爆弾テロが発生し、挙句の果てのくらいあるだろうか。あるいは東京はどのだ。この例とは別に、トラブル発生時に大地震が東京を襲うということが現実のくらいの期間で復興できるのだろうか。のために確保していた保守部材を、管理味を帯びないと言い切れるだろうか。

1990年代中盤からのIT重視政策により、者が勝手に他の目的のために流用してい隕石によるシステム破壊や火星人によ

これだけコンピュータとネットワークに大たケースもある。

るシステム盗難までを考えなさいとまではきく依存した日本社会を作り出してしまっ

158 +++ internet magazine 2004.03 +++い。しかし、実際にトラブルが発生したと

このように、人は決められたことを的確

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

セキュリティー管理責任者はいま何を考えるべきかにやらなかったり、約束を破ってしまったに考えると、単純に 1 台のシステムでサりすることがある。このため稼働確保のービスを提供する場合と比較すると、4倍重要な作業を、管理者を含めた人間が行以上のコストがかかることになる。

何をすればよいのだろうか。
1つは、稼働再開を短時間で果たすた
めに、できる限り短時間にシステム停止うようなシステム運用を設計してしまうと、システムを停止させないようにするたの原因を特定し、原因の除去と稼働再開

人間の質が問題となってしまうこともある

めには、コストがかかるのは当たり前ののためのさまざまな方策を考えて、可能のだ。つまり、人間が Single Point of話である。しかし、あまりにもコストが高性の高い方法を復旧することである。こFailureになってしまうのである。この｢人｣くなることから、経営陣の説得が困難に

れは緊急事態の、本来想定されていない問題については、筆者は1つのルールをなることも多い。このような場合にはどの状況での対応であるから、創意工夫と大持っている。常々、判断をするのは人間ようにしたらよいのだろうか。

胆な発想も求められる。時には、従来のがすべき行為だと思っているが、必要な費用問題を考えた場合に、経営陣をタイミングで必要なことを短時間でやる

説得する方法としては、純粋にセキュリという作業については、人間は大変不得ティー管理で行われるリスク評価（リスクもう1つ管理者が行わなければならな手なので信用しないというルールだ。

アセスメント）の手法を使うことが最適といことは、システムが停止した原因を特管理構造から離れて対策を組み立てることが必要になる場合もあるだろう。

この意味では、実際のバックアップシ言えよう。つまり、損害額期待値を計算定し、誰が賠償責任を持つのかを考えるステムへの切り替えや、システムのデーし、その損害額期待値の何パーセントをことである。もちろん、場合によっては誰タの同期などの処理については、できる対策に投入するかという論法で説得を行も責任をとれない状況もあるかもしれな

限り自動化し、システムが確実に処理をうのだ。さすがに最近ではセキュリティい。しかし、多くの場合には、事故を引きするように設計することが肝要だと考えー管理について経営者側も理解を示す起こした原因が存在し、その原因を作りている。システムの稼働確保について命ようになり始めていることから、リスク評出した人や組織があるはずだ。賠償責任

運を人間に託すのには、人間はいい加減価についても多くの経営者に対して説得を負わせるのに必要な情報を収集して保で不確か過ぎるのだ。

力をもつようになってきているのだ。その存しておくことも十分に考えておかなけれ意味で、リスク評価をシステムの稼働確ばならない。

戦略
３

人間は常にSingle Point of Failureになりうる構成要素だと考えるべきだ。人間にシステム稼働確保の命運を託してはいけない。

コストに対する考え方をもつべし
ここまで、システムを停止させない対策

保のためのコスト算定に使ってみるのも悪くないアイデアである。
戦略
４

本当に止まってしまったときは？

として考えるべきことを述べてきた。しかし、もう1つ十分に考えなければならないことが、「コストの問題」である。

戦略
５

システムの冗長性を確保するためのコストについては、リスク評価をもとに妥当性を検討するのは良い考え方だ。

システムが止まってしまったら、その回復に全力をかけるとともに、その賠償責任を負う人（組織）が誰かも考えながら証拠を確保することも忘れないことが大事である。また、そのための道具も用意しておこう。

セキュリティー管理には総合力
本来、多重故障の発生確率は非常に低く、滅多に発生することはないと考えシステムの不測の停止を避けること

たとえば、WWW サービスを提供してる。冗長性確保では、単一故障だけを対は、システム管理において重要であるが、いるシステムがあったとしよう。これまで

象に設計することが多い。しかし、実際セキュリティー管理においても重要な実に述べた考え方で冗長性を確保すると、に多重故障が発生してしまうこともあり、現目標となる。管理対象となる情報通信

Single Point of Failureの除去を考えてシそれによってシステムが停止してしまうこ

システムを停止させないための方策設計

ステムを二重化し、さらに突発事故対策ともある。
「絶対に大丈夫なシステム」をや対策実装などを考えることで、セキュリも考えると、結局システムは最低でも 4作ることは理論的には不可能であり、確ティー管理においても総合的な力が必要台は必要になり、さらに負荷分散装置と率として停止する可能性が低いシステムになることがわかるだろう。

してローカルに分散させるために2台必を作ることが精一杯である。

セキュリティー管理は、他のシステム管要となり、さらに広域ネットワーク上で分本当にシステムが不測の事態で停止し理作業と不可分である。さまざまな力が散させるために2台必要となる。このようてしまったとしよう。このとき、管理者はセキュリティー管理に力を与えるのだ。

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D+++ internet magazine 2004.03 +++159

［インターネットマガジン バックナンバーアーカイブ］ ご利用上の注意
この PDF ファイルは、株式会社インプレス R&D（株式会社インプレスから分割）が 1994 年～2006 年まで発行した月刊誌『インターネットマガジン』の誌面を PDF 化し、「インターネットマガジン バックナンバーアーカイブ」として以下のウェブサイト「All-in-One INTERNET magazine 2.0」で公開しているものです。

http://i.impressRD.jp/bn
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
z 記載されている内容（技術解説、URL、団体・企業名、商品名、価格、プレゼント募集、アンケートなど）は発行当時のものです。
z 収録されている内容は著作権法上の保護を受けています。著作権はそれぞれの記事の著作者（執筆者、写真の撮影者、イラストの作成者、編集部など）が保持しています。
z 著作者から許諾が得られなかった著作物は収録されていない場合があります。
z このファイルやその内容を改変したり、商用を目的として再利用することはできません。あくまで個人や企業の非商用利用での閲覧、複製、送信に限られます。
z 収録されている内容を何らかの媒体に引用としてご利用する際は、出典として媒体名および月号、該当ページ番号、発行元（株式会社インプレス R&D）、コピーライトなどの情報をご明記ください。
z オリジナルの雑誌の発行時点では、株式会社インプレス R&D（当時は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが、すべての情報が完全に正確であることは保証できません。このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

このファイルに関するお問い合わせ先
All-in-One INTERNET magazine 編集部
im-info@impress.co.jp
Copyright © 1994-2007 Impress R&D, an Impress Group company. All rights reserved.