前回は「セキュリティマネジメント」とはどういったものか、実践する上で必要な要素はどういったものか、について考察してきました。今回は、セキュアな運用を実現するために必要な「運用設計」について考えていきたいと思います。

目次

「運用設計」とは何か

「運用」とは何か

「サービスデリバリ」視点から見えてくる「セキュア運用」

まとめ

「運用設計」とは何か

「運用設計」という言葉は、運用現場で日常的に使われている割には「その実体」がはっきりしない不思議な言葉です。では、「運用設計」とは一体何なのでしょうか。筆者は「各現場に適した業務の枠組み(フレームワーク)を作り込むこと」であると考えています。

 

「フレームワーク」という言葉は、世間一般に「物事を整理する手法」という意味で使われていますが、「運用設計」においては運用業務の維持および向上を実現するために、更に以下の3つの性質が求められます。

 

・客観性 (誰がどう見ても同じ表現や事実で認識を共有できること)

・合理性 (科学的/論理的手法を用いた定量評価により合理性検証が可能であること)

 

・再現性 (高度に属人的な前提を置かずに、反復して実現可能であること)

 

つまり、「客観的な立場に立ち、科学的/論理的手法を用いて業務の合理性を検証し、業務を継続的に遂行するための枠組みを構築すること」が「運用設計」の実体になります。 一貫した設計思想を基に、運用現場にとって効率的で分かりやすい「フレームワーク」が各現場で求められる「運用設計」であり、それを作り上げるのが「運用のプロ」としての仕事と言えるでしょう。

 

「運用設計」を適切に実施していない運用現場では、一般的に以下のような状況になると考えられます。

 

・意見や分析が主観的になる。

・感覚値で論じられること(非科学的)が多く、論理的な議論ができず(非論理的)、
　非合理的な結論になりやすい。

・客観化がされておらず、合理的な結論が導き出せないため、同様の問題が発生
　した時に過去の経験が活かされにくい(非再現的)。

 

残念ながら、このような運用現場では、セキュリティの3大要素である機密性・完全性・可用性のいずれも客観的に担保することができないでしょう。 セキュアな運用を実現するためには、まず「運用設計」をきちんと考えなおす必要があることがおわかりいただけるかと思います。

 

ここまで「運用設計」の話をしてきましたが、では「運用」とは何でしょうか?

 

実は「運用」という言葉の概念は人によって異なるのが現状です。 このことは各ステークホルダから「運用」への期待や評価を曖昧にし、議論が噛み合わず「運用」への理解を妨げるなど多くの弊害を招いています。

 

 

・「運用」は忙しそうだけど、何をやっているのかよくわからない。

・頼み込めば「運用でカバー」はしてくれるものだ。

・運用現場はコストセンターなので、「運用はゼロ」が理想だ。

 

このような運用現場にとってマイナスなイメージは、運用現場の内外から見たときに共通した「運用」の概念が存在していないために起きています。 先程の「運用設計」に求められる3つの性質の一つである「客観性」(誰がどう見ても同じ表現や事実で認識を共有できること)がまず実現できていないわけです。

 

「運用」は「サービスデリバリ」である

「運用」という言葉自体の歴史は古く、14世紀中ごろの中国の史書に登場したのが最古と言われています。 現代の辞書においては、次のように解説されています。

 

・うまく機能を働かせ用いること。活用。(広辞苑第六版)

・そのものの持つ機能を活かして用いること。 活用。(大辞泉)

 

つまり「運用」とは「ものを活用すること」を意味します。

 

活用する対象を「運用現場のリソース」とし、その目的を「ステークホルダの期待に応えること」とすると、運用業務における「運用」という言葉は次のように定義できると思います。

 

運用とは
運用組織のリソースを活用し、対価や評価を得ることを目的に、外部に対して継続的に何らかの価値を提供すること、を言う。

 

このうち、「何らかの価値を提供すること」を「サービス」、「継続的に提供すること」を「デリバリ」と表現すると、運用業務における「運用」とはほとんどの場合「サービスデリバリ」と表現できると筆者は考えています。

 

(本コラムにおける「サービスデリバリ」は、ITIL v2におけるカテゴリとしての「サービスデリバリ」とは異なるものです。)

 

「運用」を「サービスデリバリ」ととらえることの大きなメリットとして以下が考えられます。

 

1.「コストセンター」からの脱却

　「サービス」視点で物事を考えるようになる。

2.「定量評価」の実現

　「デリバリ」視点で定量評価が可能になる。

3.「コアコンピタンス」の明確化

　「サービス」視点、「デリバリ」視点で専門性を考えるようになる。

 

この定義により、運用現場とは「サービス」と「デリバリ」の専門家集団であり、その専門能力は以下の2つが柱だということになります。

1. サービス価値の向上 (経営や業務の実務知識と経験)

2. デリバリ価値の向上 (エンジニアリングの実務知識と経験)

 

そして、セキュアなサービス(他部署への価値の提供などを含む)を考案し、そのサービスの価値を実際にセキュアなデリバリによってユーザに提供できるように工夫していくことが、最終的にはセキュア運用につながると筆者は考えています。

この2つの価値で特に留意しておきたいのは、サービスは「独自性」が価値を生み、デリバリは「標準化」が価値を生みやすい点です。 特に、エンジニアリングで独自性を追求したり作り込みしすぎることは、脆弱性の発生やその放置によりその価値を大きく毀損させる危険性があることに留意しておく必要があるでしょう。

 

大企業を中心に導入されているISMS(情報セキュリティマネジメントシステム)においては、毎年の更新監査を通すことを目的として、各現場の個別事情が十分には考慮されていない全社的なセキュリティポリシーが一律に適用されてしまうことが一般的に行われているようです。 その結果、現場の実情とは乖離もしくは業務のオーバヘッドが大きいポリシーの下で業務を遂行している運用現場の話も良く伺います。

 

しかしこのことが即「ISMSが悪い」と言い切れることにはなりません。 会計監査を例に見ればわかりますが、「監査」というものは、監査を受ける側が自分たちの業務を他人が理解できるように客観化してあること、監査人がその客観化された内容を専門家の観点から分析できること、が前提になります。 運用現場が自分たちの業務をセキュリティ視点で客観化できていないことが、全社統一のセキュリティポリシーを適用されてしまう理由の1つになっています。

 

運用現場の価値が「サービス」と「デリバリ」にあるとし、そのコアコンピタンスを特定することができれば、ISMSポリシーをむしろ「現場の価値」を支えるための規約として、例えば「運用設計」に準拠しない不正規な業務設計を牽制することで事故を防止する、ドキュメントを義務付けることで設計思想の喪失を防止するなど、「現場を守るために」ISMSを利用することも可能なのではないでしょうか。

 

今回のコラムでは、まず「運用設計」とは何か、「運用」とは何かについてお話をさせていただきました。 そして、「運用」を「サービスデリバリ」と捉えることで、「運用」の専門性や、「セキュリティポリシー」を自分達を縛る軛(くびき)から自分達の価値を向上させるためのツールに変えていく方法について考察してみました。 現状の苦労からの脱却は容易ではありませんが、現場の今後を日々考えているみなさんのご意見を伺えれば幸いです。

 

次回からは、「セキュアな運用」の設計を考える上で必要なトピックを取り上げていきたいと思います。