オブザーバの柳原です。前回のコラムでは、『情報システムに関わる私達自身が、情報リスクを増大させている』という観点と、『リスクを取る』ことも前進のためには必要な事なのだ、ということをお話しました。今回は、リスクを取るにもコツがある、ということを詳しく説明したいと思います。

目次

１．ジレンマとの戦い

２．ISMSによるリスクの計算

３．既存でないシステムのリスクを考える

４．リスクテイクのコツ

１．ジレンマとの戦い

情報システムを運用していく仕事は、単に既存のハードウェアやソフトウェアの動作を維持するだけではありません。時間の経過とともに刻々と変化する運用状況への対応が求められます。

組織の活動方針の変更や、上司が部下に何気なく依頼した新しい仕事によって、エンドユーザによるシステムへの負荷は簡単に増えてしまいます。サーバやネットワークの負荷は上昇することはあっても、減少するのは稀です。クライアントPC上のリソースも、システム管理者の都合とは無関係に、ソフトウェアの更新や、エンドユーザによる処理データの増加によって、どんどん食われていきます。すなわち、単に既存のシステムを安定稼働させようとしても、システム管理者の手の届かないところで、情報システムは変化していくのです。たいていは、負荷が上昇する方向です。

また、問題は負荷の上昇問題だけではありません。エンドユーザによる適切ではないシステムの利用や情報漏えい、ソフトウェアが意図しない動きをすることによる障害、突発的なハードウェア障害など、予想もしなかった問題に直面することもあります。

システム管理者の仕事とは、この変化や問題に対して、最もコストのかからない方法で、安全に対処することに他なりません。もちろんその対処によって、副次的であったとしても、システムを所有している組織やエンドユーザに対して、メリットを提供することができればベストです。

別の見方をすれば、情報システムの運用状況がどんどん変化していくからこそ、システム管理者の活躍するチャンスがある、とも言えるでしょう。

もちろん、こうした問題を防止したり、迅速に対処するための手法（ソリューション）はたくさん存在しています。しかし、そうしたソリューションを導入することは、既存のシステムへの影響や負荷の増大という新たなリスクを生み出します。導入のためのコストや手間も発生します。

かといって、こうした問題への対処を先送りにすると、不満の蓄積したシステムのステークホルダーから大きなしっぺ返しを受けるでしょう。あちらを立てればこちらが立たず、というわけです。システム管理者の仕事とは、投入できるコストや手間に限界がある状況での、こうしたジレンマとの戦いでもあるのですね。

では、このジレンマから脱出するにはどうすればよいのか。それは問題を先送りせずに、システム管理者がリスクを取るしか無いのです。

（注）以前、学生に「リスクを取る」という話をしましたら、「リスクを除去する」という意味に理解されてしまい、慌てたことがありました。ここでの「リスクを取る」とは、リスクテイク(risk taking)のことです。

２．ISMSによるリスクの計算

では最初に「リスク」とは何かを確認しておきます。あまり問題を一般化してしまってもいけませんので、特に情報システム運用に関するリスクに限定して考えていきます。ISMS(Information Security Management System)について学んだ方は、この節は読み飛ばしていただいてもかまいません。

まず、リスクは定量的なものです。意外に聞こえるかもしれませんが、リスクの大きさは計算したり、定量的に比較できるものです。ISMSによれば、情報リスクの計算式は次のとおり。

情報リスク値＝[情報資産の価値]×[脅威の値]×[脆弱性の値]

価値や値のところには、たとえば１～５といったレベルを付けます。その場合には、リスク値は１～１２５の間で値が変化することになります。通常は、既存の情報システムに存在する情報資産を洗い出した上で、個々にこの計算を行います。そこから求められたリスク値を比較することによって、リスクを低減する優先順位が決まってきます。

もちろん、この例でいうところの１～５といったレベル付けは、かなり経験的であったり、恣意的なものです。しかし、複数の人の眼によって修正を重ねることによって、ある程度、妥当な値をつけることができるでしょう。

３．既存でないシステムのリスクを考える

ISMSの情報リスク値の計算方法は、すでに稼働している情報システムが持つリスクの分析を主眼に置いています。では、この計算方法は、システム管理者のみなさんが、日々運用している情報システムの「変化」に対応するための様々な手法を選定する際に役立つでしょうか？

たとえば、情報漏えい対策を強化するために、すべてのクライアントPCの操作を記録（ログ）するソリューションを導入すると仮定しましょう。この場合、ユーザによる不正操作という[脆弱性の値]を引き下げることができると予想できます。

ところがこのソリューションは、操作記録をサーバに転送するために通信を行う必要があります。通信を行うソフトウェアが脆弱性を持っていないことを保証する手段はあるでしょうか？また、多数のクライアントPCから操作記録を集めたサーバ上にあるデータベースに、脆弱性が無いことを確認することはできるでしょうか？

この例では、情報リスクの低減を狙って導入したソリューションが、「操作記録」という新たな情報資産を生んでしまい、同時に脆弱性が無いことを担保することもできない状況に陥っています。これが、『情報システムに関わる私達自身が、情報リスクを増大させている』という観点の具体例です。

しかしこうしたリスクの増大を恐れていては、情報技術によるすべての対策は不可能になってしまいます。しかし、何らかの対策は実行せざるを得ない。ということは、リスクテイクせざるを得ない、ということになります。

では、適切なリスクテイクの方法はあるのでしょうか？

４．リスクテイクのコツ

ピーター・バーンスタイン(Peter L. Bernstein)は、その著書「リスク―神々への反逆」の中で、人間の行動には二つのパターンがあると述べています。

(1) 過去の行動を観察し，リスクの考え方に従って合理的意志決定を行う人．
(2) その時々の、自分の主観的な信念に基づいて意志決定を行う人．

もちろん、(1)の行動が望ましいわけですが、実際にはまだまだ(2)の行動を取る人が多いのです。情報システムの構築や販売に関係する人であれば、すべての製品に対して公平に、かつ合理的な判断を下すことは難しいでしょう。たいていは自分の好みであったり、所属する企業が販売する製品を、良いものとして推奨するのではないでしょうか。それを仕事としているのであれば、当然のことでしょうし、ビジネスである以上はそれを問題視しても仕方がありません。

ところが、何らかの対策に必要な情報システムを、リスクテイクすることを前提にして導入しようと考えるのであれば、できるだけ(1)の考え方に沿って、製品を比較、検討すべきなのは自明です。もちろん、システム管理者自身がそうした検討を行えるのが理想でしょうが、現実には無理があると思います。ではどうすればよいのか？

ここで注目したいのは、コミュニティの存在だと思うのです。情報システムの開発や運用に関わる人々が集まったコミュニティや、彼らが開催する勉強会は、日本中に存在します。ビジネスから一歩離れたところで情報交換することができますから、少なくともコミュニティ内に流れる情報は偏りが少ないと考えられます。そうした情報を元にして(1)の行動を目指すことができるでしょう。

みなさんは「IT勉強会カレンダー」をご存じでしょうか？
https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com
これを見ると、日本全国で多数のコミュニティによる勉強会が開催されているのがわかります。もちろんこれ以外にもIT系コミュニティはたくさんあるでしょう。そうした活動の中から、より合理的な判断の元になる情報を集めること、、、それが「リスクテイクのコツ」の一つではないでしょうか。