前のページに戻ります ホームへ サイトマップへ
           
   
 
 



実効性のあるデータ保全を目指して_   
 
     

 業務継続管理におけるデータ管理の課題 2011.3.31

2011年3月11日は、日本中の、いや、世界中に人々にとって、忘れられない日になってしまいました。
 地震発生直後から24時間近く停電していたため、なかなか情報収集が出来ませんでしたが、翌日テレビを見て、あまりの事に不覚の涙を禁じ得ませんでした。
 地震と津波によって、尊い命を落とされた方々のご冥福を心からお祈りすると共に、ご遺族の皆様に心よりお悔やみを申し上げます。
 また、お怪我をされた方の一日も早いご回復と、被災された皆さんが一日も早く立ち直られ復興を遂げられることをお祈りいたします。
 東北地方では、多数の事業所が操業を停止し、2週間以上経った今日になっても、未だ回復の見通しが立たない事業所も多いとの報道もあります。
 私達自身も、何時までも茫然とはして居られません、私達自身も立ち直って、しっかり被災地を支えて行きたいと思います。

業務継続管理とは
 今回は、この未曽有の大災害に触発され、データ管理面から、事業継続管理について考えて見たいと思います。
 情報システムの災害対策と言えば、現段階(2011.3.21)では何と言ってもISO/IEC17799:2005 (JISQ27001:2006)【情報セキュリティマネジメントシステム要求事項】の事業継続管理と言うことになるでしょう(以下、ISMS)。
 事業継続管理は、情報セキィリティマネージメントシステム(JISQ27001)の要求事項ですが、最近では、BS25999が事業継続マネジメントの認証制度としてしスタートし、近いうちにISO化されるので、何れ認証を取る企業も増えて来ると想われます。

事業継続管理のコスト
 今回の大災害によって、ISMSを取得していなかった企業、今まで興味の無かった企業は、大いに慌てていることと思います。
 しかし、ISMSの認証取得企業は安心かと言うと、必ずしもそういう訳ではないと思います。
 ISMSのPDCAを回し、適切な管理策を実施していたとしても、発生頻度の低い大災害の影響を完全に防止する事は出来ません。
 況や千年に1度の大災害の影響を完全に排除する管理策を実施するとなると、施設や資源の分散を中心に対応することになるので、計画的で長期に亘る取り組みと相当にコストが必要になります。
 リスクの評価は、資産価値と発生頻度に影響されるので、頻度の低いインシデントに対応する場合には、保険などによるリスク移転も考慮し、総合的な対応を検討する事を勧めます。
 ISMSも事業継続管理も、ビジネスの一環であることに変わりはないので、コスト度外視など有り得ません。
 当然、最小のコストで最大の効果を目指す、コストパフォーマンスが求められます。
 と言うことで、ここでは事業継続管理における生産性やコストパフォーマンスを議論して行きたいと思います。
 有り体に言えば、データベースの設計品質の悪さや、ユーザインターフェースの実現のみに着目する設計思想など、情報システムに重複や冗長性を組み込み拡大していく仕組みによって、情報資産の70%以上は多重に重複していると言う指摘がありますが、その重複を再生産・拡大する仕組みをそのままにして、さらに運用負荷となる事業継続管理の強化を推進して良いのかと言う議論です。
 例えば、単純に量とコストが比例していると仮定すると、データのバックアップを強化して外部保管やデリバリシステムで月100万円のコスト増になる場合、本当は30万円で良いにも関わらず、システムの作りが悪いおかげで100万円掛ると言うことを放置しておくつもりですかと言う議論です。

事業継続管理のコストパフォーマンス
 ISMSでの事業継続管理の目的は「情報システムの重大な故障又は災害の影響からの事業活動の中断に対処するとともに、それらから重要な業務プロセスを保護し、また、事業活動及び重要な業務プロセスの時機を失しない再開を確実にするため」と述べられています。
 その対応範囲は、災害だけでなく、重大な障害も含みます。
 また、インシデント発生時の中断からの再開だけでなく、業務プロセスを継続するための保護も目的に含んでいます。
 重大な故障や災害に際して、事業の継続、又はその再開を要求された時間内に行うための管理策と言う位置づけです。
 具体的には、以下の要求事項が設定されています。
 【情報セキィリティマネージメントの実践のための規範(JISQ27002)】から抜粋

_ 14 事業継続管理 
_ _ 14.1 事業継続管理における情報セキュリティの側面
    目的:情報システムの重大な故障又は災害の影響からの事業活動の中断に対処するとともに、それらから重要な業務プロセスを保護し、また、事業活動及び重要な業務プロセスの時機を失しない再開を確実にするため。
_ _ _  14.1.1 事業継続管理手続きへの情報セキュリティの組み込み
_ _ _  管理策
_ _ _   組織全体を通じた事業継続のために、組織の事業継続に必要な情報セキュリティの要求事項を取り扱う、管理された手続を、策定し、維持することが望ましい。
_ _ _  14.1.2 事業継続及びリスクアセスメント
_ _ _  管理策
_ _ _  業務プロセスの中断を引き起こし得る事象は、そのような中断の発生確率及び影響、並びに中断が情報セキィリティに及ぼす結果とともに、特定することが望ましい。 
_ _ _  14.1.3 情報セキュリティを組み込んだ事業継続計画の策定及び実施
_ _ _  管理策
_ _ _   重要な業務プロセスの中断又は不具合発生の後、運用を維持又は復旧するために、また、要求されたレベル及び時間内での情報の可用性を確実にするために、計画を策定し、実施することが望ましい。
_ _  14.1.4 事業継続計画策定の枠組み
       管理策
        すべての計画が整合したものになることを確実にするため、情報セキュリティ上の要求事項を矛盾なく取り扱うため、また、試験及び保守の優先順位を特定するために、一つの事業継続計画の枠組みを維持することが望ましい。
       14.1.5 事業継続計画の試験、維持及び再評価
       管理策
       事業継続計画が最新で効果的なものであることを確実にするために、定めに従って試験・更新することが望ましい。

 情報セキィリティマネージメントの実践のための規範(JISQ27002)からの抜粋なので、管理策の語尾が全て「望ましい」になっていますが、情報セキィリティマネージメントシステム要求事項(JISQ27001)では、「しなければならない」となっています。

 事業継続管理が直接的のデータ管理と関連するのは「14.1.1 事業継続管理手続きへの情報セキュリティの組み込み」に関する部分です。
 情報セキィリティマネージメントの実践のための規範(JISQ27002)の、管理策に続く「実施の手引」を見ると、以下のように書かれています。

_ 14 事業継続管理 
_ _ 14.1 事業継続管理における情報セキュリティの側面
_ _ _  14.1.1 事業継続管理手続きへの情報セキュリティの組み込み
_ _ _  管理策
_ _ _   組織全体を通じた事業継続のために、組織の事業継続に必要な情報セキュリティの要求事項を取り扱う、管理された手続を、策定し、維持することが望ましい。
_ _ _  実施の手引
_ _ _   事業継続管理手続きには、次の重要な要素を組み込むことが望ましい。
_ _ _ a)     重要な業務プロセスの識別及び優先順位付けも含め、組織が直面しているリスクを、可能性及び影響の面から理解する(14.1.2参照)。
_ _ _ b)  重要なプロセスにかかわる全ての資産を識別する(7.1.1参照)。
_ _ _ c)  情報セキュリティインシデントによって発生する業務プロセスの中断が事業に及ぼすと思われる影響を理解し、情報処理施設の事業目的を確立する。
 なお、組織の存続性を脅かす可能性のある重大なインシデントと同様に、影響がそれほど大きくないインシデントにも対処する解決策を見出すことが重要である。
_ _ _ d)  運用上のリスク管理の一部であることと同様、事業継続手続き全体の一部をなす場合もある適切な保険への加入を考慮する。 
_ _ e)  予防及び緩和のための追加管理策を特定し、それらの実施を考慮する。
      f)  識別された情報セキュリティの要求事項を取り扱うのに十分な、財政上、組織上、技術上及び環境上の経営資源を特定する。
      g)  要員の安全並びに情報処理設備及び組織の資産の保護を確実にする。
      h)  合意された事業継続戦略に沿って情報セキュリティの要求事項を取り扱った事業継続計画を策定し、文書化する(14.1.3参照)。
      i)  策定した計画及び手続を定めに従って試験し、更新する(14.1.5参照)。
      j)  事業継続管理を組織のプロセス及び機構に組み込むことを確実にする。 事業継続管理手続きの責任は、組織内の適切な階層に割り当てることが望ましい(6.1.1参照)。

 データは、代表的な情報資産なので、このb)で、プロセスに関わる資産として識別されることになります。
 重要、つまり障害や災害による業務停止に際し、優先的に回復すべきと判断されたプロセスに関連するデータを、先ず識別しようと言う考え方です。
 識別されたデータは、他の情報資産と共に、事業継続計画で保全と回復の要領が決められ、ISMSの運用に組み込まれて行くことになります。
 つまり、事業継続管理としてのバックアップや回復手順や運用訓練などが、通常の情報システム運用に組み込まれて来ると言うことになるので、ここでデータを保全する単位や量、頻度に関する配慮が、事業継続管理のコストパフォーマンスに大きく影響を与えることになります。
 
データの保全はデータベース単位で
 インシデントの発生時に、バックアップ機器が通常運用と同程度の規模で展開出来るとは限りません、場合によっては規模を縮小して縮退運転を行わなければならなくなる可能性があります。
 また、そもそもインシデントの発生が一部の機器、又はアプリケーションに限られる場合もあります。
 それらの事態に臨機応変に対応するためには、情報資産の中核となるデータは、あらゆるプロセスのバリエーションに対応するために、データベースの単位で保全する必要があります。

 データベースを丸ごとバックアップしたりロードすると言うと、大量のデータを扱うように思いますが、ここで対象にしなければならない部分は、ビジネスを記録する領域だけです。(右図の記録部分)
 そのため、データ分析が正しく行われていれば、大した量にはなりません。
 また、データベースがビジネスの構造を正しく反映したデータ構造で作られていれば、規模は極小化されている上に、日毎など、期間別に取得すれば良いので、無理な話ではありません。
 記録以外の導出、集計、履歴の部分は、基本的には全て、記録からの導出が可能です。
 また、記録部分と同様に、期間で区切って少量ずつの取得が可能なので、データ取得の負荷は極小化されます。
データベースで管理するデータの種類と保全のポイント
 データの種類  データの概要と特徴  保全要領
 ・記録 ・ビジネス中の存在・出来事の記録 ・時系列に発生するので、発生分を発生順に保全する事で取得負荷を軽減
・導出 ・記録から導出
・イベント単位の導出は更新なし
・記録から再計算可能な場合は保全は任意、基本は再計算
・集計 ・記録・導出を期間で集計
・期間の集計結果は更新なし
・用途が情報系、記録・導出から再集計可能なので、取得は任意
・履歴 ・記録・導出・集計の複写
・データの更新なし
・記録部分の履歴はここが原本になるので、記録同様に保全⇒記録の変更分が履歴
 但し、記録は、そのまま処理が完結した後も存在しているので、期間を区切るなどして、アクティブなデータと不活性なデータを分離して扱う工夫は必要になります。
(例えば、会計処理が終了した受注は、記録部分から外し、情報系の履歴に移すなど)
 なお、データを記録する側の機能、つまり、データ入力登録機能については、ビジネスとデータベースをつなぐもので、データベースに遅滞なくビジネスの事実を記録するためには不可欠です。
 継続したい業務の内容にもよりますが、データベースが一式保全されていれば、登録機能の運営に支障は無いので、データ入力登録機能のシステムも、データベースとセットで保全の対象と考える方が良いでしょう。

冗長性の高いデータ構造の場合
 データベースを使っていない場合、又はデータベースを使っていても、データがデータベースに一元管理されている訳ではなく、昔ながらの目的別の中間ファイルを使っている場合などは、データの更新連携機能まで遡って保全の対象とする必要があります。
 つまり、データベースを使っているシステムでは、重要なプロセスをユーザインターフェースで特定すれば、当該ユーザインターフェースへのデータ供給に関しては、データベースまで遡れば保証されます。
 また、遡るなどと大げさなことを言わなくても、基本的には、ユーザインターフェースが直接データベースをアクセスしているので特定は容易です。
 しかし、データベースが使われていない場合は、データ供給経路を遡って、ビジネスのデータを情報システムに記録している機能の部分を保全の対象としておかないと、ビジネスの現在を反映したユーザインターフェースの実現が出来なくなってしまいます。

データベースの設計品質が低い場合
 データベースの設計品質が低く、データベースの中に冗長性を含んでいる場合、重要なプロセスに加えて、データベース内の整合性を維持する処理、即ち、データの整合性維持の処理も合わせて保全の対象にしておかないと、折角保全されたデータベースを使っても、出力の整合性が損なわれる可能性があります。
 事業継続管理の有効性からも、データベースはデータベースとしての正しい形で設計する必要があることがおわかり頂けると思います。

プロセス側からの特定
 データベースを一つのデータ単位として扱えば、扱いは容易だが、情報セキュリティマネジメントの実践のための規範で言う14.1.1 b)「重要なプロセスにかかわる全ての資産を識別する」を教条的に適用しようとすると、データの特定はかなり困難な作業となる。
 データベースは、データ項目の集合形成や集合間の関連を言わばデータベースの中に隠蔽する事によって、データニーズは個別のデータハンドリングではなく、SQLと言う形でデータベースに対して操作する形なので、テーブル単位などで扱うことは難しい。
 やはり、データベースはデータベースの単位で扱うこと以外の選択は無いと言うことなので、扱い易いデータベースを設計しておくしか、データ管理面から業務継続管理の有効性を高める手立てはない様です。

業務継続管理における生産性
 以上、データ管理との関係で、業務継続管理の実効性を検証してみたが、システム開発のQCDがデータベースの設計品質によって左右されるのと同様に、事業継続管理の計画立案においても、データベースの設計品質が業務継続管理の効果を上げ、コストを下げる大きな要素となることを確認しました。
 業務継続管理は、障害・災害時の対応ですが、そのためのデータ保全や関連諸作業は、日常のシステム運用の中で行われることなので、生産性やコストパフォーマンスを度外視して良いと言う訳には行きません。
 データベース設計の品質を上げて、生産性の良い業務継続管理を実現する必要があります。
 逆に、動機が緊急の事業継続管理対応であっても、データベース設計品質の向上は、日常の情報システム運用の生産性も上げるので、一石二鳥の効果が実現すると言う訳です。


 
   トップページへ