ネットワークから考えるITガバナンス ― 「点」ではなく「つながり」を統制する
はじめに
私は普段、ITガバナンスやサイバーセキュリティを中心とした領域について、細々と関わっている者です。
本記事では、 「ITガバナンスを、個々の組織・システム・統制を独立して捉えるのではなく、それらの接続関係から成る“ネットワーク”として捉えることで、ガバナンスの構造やリスクをより体系的に整理できるのではないか」 という仮説を起点に、ネットワークの考え方とITガバナンスとの関係について整理します。
ここでいう「ネットワーク」は、LANやWANといった通信ネットワークそのものだけを指すものではありません。
ノード、エッジ、経路、境界、依存関係、集中点、冗長性といったネットワークを構成する概念を、組織、業務、システム、データ、権限、意思決定、内部統制1などに拡張して考えることを意図しています。
なお、本記事は既存のITガバナンス理論や特定のフレームワークについて公式な解釈を示すものではなく、筆者個人が立てた仮説に基づく考察です。
本記事では便宜上、この考え方を「ネットワーク型ITガバナンス」と表現しますが、既存の正式なフレームワークや方法論の名称ではありません。
また、本記事に記載する内容はすべて筆者個人の見解であり、筆者が所属または関係する企業、団体その他の組織の見解を代表するものではありません。
1. ネットワークとITガバナンスを整理する
1.1 本記事における「ネットワーク」
ネットワークという言葉から、多くのIT技術者はルータ、スイッチ、IPアドレス、ルーティングなどを想像すると思います。
しかし、ネットワークをより抽象化すると、その本質はそれほど複雑ではありません。
大きくは、
- ノード（Node）：何らかの主体や要素
- エッジ（Edge）：ノード同士の関係
- 経路（Path）：複数のエッジによって形成されるつながり
によって構成されます。
例えば企業のIT環境も、
というネットワークとして捉えることができます。
そして組織についても同様です。
この場合、流れているものはパケットではありません。
情報、権限、責任、意思決定、リスクに関する情報、要求事項などです。
つまり、企業そのものを一種の巨大なネットワークとして見ることができます。
1.2 ITガバナンスとは何を統治しているのか
ITガバナンスというと、
- IT戦略
- IT投資
- 規程
- 会議体
- リスク管理
- 情報セキュリティ
- システム管理
- 内部統制
など、さまざまな要素が挙げられます。
しかし、これらを個別に管理すること自体がガバナンスの目的ではありません。
本質的には、
「企業のビジネス目的を実現するために、情報とテクノロジーをどのように評価し、方向付け、監視するか」
という問題だと考えます。
COBIT 2019でも、ガバナンスに関する目的はEvaluate（評価）、Direct（方向付け）、Monitor（監視） という考え方で整理されています。
また、対象となるのは単なるIT部門のプロセスだけではありません。
COBIT 2019では、プロセスに加えて、
- 組織構造
- 情報フロー
- 人・スキル
- 文化・行動
- ポリシー・手続
- サービス、インフラ、アプリケーション
などを、ガバナンスシステムを構成する要素として捉えています。
この考え方は、個々の要素だけではなく、それらの関係を見る「ネットワーク」という見方とも比較的相性が良いように思います。
1.3 ネットワークとITガバナンスの類似点
両者を対応させると、例えば次のように整理できます。
| ネットワークの概念 | ITガバナンスに置き換えた場合 |
|---|---|
| ノード | 組織、業務、システム、データ、人、委託先 |
| エッジ | 依存関係、権限、データフロー、契約、報告関係 |
| 経路 | 業務処理、意思決定、エスカレーション |
| ハブ | 共通基盤、重要システム、意思決定主体 |
| 境界 | 組織境界、責任分界、Trust Boundary2 |
| ボトルネック | 単一承認者、共通基盤、特定ベンダ |
| セグメンテーション | 職務分掌、権限分離、環境分離 |
| 冗長性 | BCP3、代替要員、バックアップ、マルチベンダ |
| 障害伝播 | サイバー攻撃、障害、業務停止、サプライチェーンリスク |
ここから、本記事では次の仮説を置きます。
ITガバナンスとは、個々の統制を配置することだけではなく、企業を構成するノードとエッジの関係を望ましい状態に維持することなのではないか
2. なぜネットワークからITガバナンスを考えるのか
2.1 「点」で統制を見ることの限界
ITガバナンスやセキュリティの評価では、どうしても個別の統制に目が向きます。
例えば、
- アカウント管理ができているか
- MFAが導入されているか
- ログを取得しているか
- バックアップを取得しているか
- 脆弱性管理を実施しているか
- 委託先管理を実施しているか
といった確認です。
もちろん、これらの統制はそれぞれ重要です。
一方で、個々の統制が存在しているか、あるいは個々の統制が完全に実施されているかだけで、企業全体のITリスクを判断することはできません。
極端な例を挙げれば、ある個別システムにおいて脆弱性管理が十分に実施できていなかったとしても、
- 外部ネットワークから直接到達できない
- ネットワークが適切に分離されている
- アクセス可能な主体が強く制限されている
- 侵入や不審な挙動を検知できる
- 当該システムが担う業務の重要性が限定的である
といった複数の条件や補完的な統制が存在することによって、残余リスク4が組織のリスクアペタイト5等の範囲内に収まっていると判断できる場合があります。
これは脆弱性管理が不要だという意味ではありません。
重要なのは、
「その統制が実施されているか」だけではなく、「その統制や他の統制との組み合わせが、会社全体の構造の中でどのリスクを、どの程度低減しているのか」
を見ることです。
逆のケースも考えられます。
個々のシステムで、
- パッチ適用が行われている
- MFAが導入されている
- ログが取得されている
- バックアップが取得されている
といった統制が一通り実装されていたとしても、認証基盤や共通ネットワーク、クラウド基盤など、複数の重要業務が依存する共通ノードに重大な問題が存在していれば、企業全体では高いリスクを抱えている可能性があります。
つまり、
個別統制の充足度と、企業全体としてのリスク水準は必ずしも一致しません
個々の統制を「点」として評価するだけではなく、
- そのシステムが何に接続されているのか
- どの業務がそのシステムに依存しているのか
- 他の統制によってどの程度補完されているのか
- 問題が発生した場合にどこまで影響が伝播するのか
という構造としての評価が必要になります。
2.2 リスク事象の影響はエッジを通じて伝播する
サイバーインシデントも、システム障害も、サプライチェーン上の問題も、ある一つの場所だけで完結するとは限りません。
例えば、
という依存関係があれば、
「委託先の問題」 が、
「クラウドサービスの問題」 となり、
「システム障害」 となり、
最終的には、
「重要業務の停止」 や 「顧客への影響」
として表面化する可能性があります。
厳密には、リスクそのものがエッジを物理的に移動するわけではありません。
重要なのは、ある場所で顕在化したリスク事象の影響が、依存関係を通じて企業価値までどのように波及するのかを見ることです。
この考え方は、ネットワークとしてガバナンスを見る大きな理由の一つです。
3. ネットワーク型ITガバナンスはトップダウンで考える
ここまでネットワークの話をしてきましたが、実際に企業のガバナンスへ適用する場合には一つ注意が必要です。
単純に、
「サーバを全部並べて線でつなぐ」
だけでは、ITガバナンスにはなりません。
それでは単なる構成管理や資産管理になってしまいます。
ネットワーク型ITガバナンスで重要なのは、経営目的を起点としてトップダウンアプローチでネットワークを構築することだと考えます。
3.1 システムから始めるボトムアップアプローチ
例えば、IT資産から始めると、
という考え方になります。
これは構成管理、資産管理、セキュリティ管理などでは非常に重要なアプローチです。
しかしガバナンスを考える場合、
「なぜそのシステムを管理するのか」
という目的が後から登場してしまいます。
3.2 経営目的から始める
そこで順番を逆転させます。
例えば、
「製品を安定的に顧客へ供給する」
という目的があるとします。
そこから、
- どの業務が重要なのか
- その業務は何に依存しているのか
- どの情報が必要なのか
- どのシステムが支えているのか
- どのIT基盤がそのシステムを支えているのか
- どの外部事業者に依存しているのか
と下に降りていきます。
すると、
「何を守るべきか」から「何を統制すべきか」を逆算できるようになります。
NIST Cybersecurity Framework 2.0（NIST CSF 2.0）でも、新たに追加されたGOVERN機能によって、サイバーセキュリティを単なる技術対策ではなく、組織のミッション、リスク管理戦略、役割と責任、ポリシー、サプライチェーン等と結び付けて扱うことがより明確になりました。
セキュリティだけを独立して考えるのではなく、企業目的やエンタープライズリスクとの接続から考えるという点では、本記事の仮説とも近い方向性だと考えています。
3.3 トップダウンで設計し、ボトムアップで検証する
ただし、トップダウンだけで完結するわけではありません。
経営層が考えている業務構造と、実際のIT環境が一致しているとは限らないためです。
例えば、
- 公式には利用していないSaaSが重要業務で使われている（シャドーIT）
- 特定担当者のExcelに業務が依存している（属人化）
- 想定していなかった外部APIへ依存している
- BCP上は代替可能とされているが、実態としては代替できない
- 重要システムが別の共通基盤へ強く依存している
- 特定の委託先に運用ノウハウや復旧手段が集中している
といったことは十分に考えられます。
したがって、
トップダウンでガバナンス構造を設計し、ボトムアップで実際の資産・業務・依存関係から検証する。
という双方向のアプローチが現実的です。
トップダウンで「こうあるべき」を描き、ボトムアップで「実際にはどうなっているか」を確認する。
そして両者の差異そのものを、リスクとして捉えることもできます。
4. 実際にガバナンスや内部統制へどう落とし込むか
では、ネットワークの考え方を実際のITガバナンスへ適用するとすれば、どのような方法が考えられるでしょうか。
ここでは5つのステップに整理してみます。
Step 1. 経営目的・守るべき価値を定義する
最初に定義するのはシステムではありません。
例えば、
- 企業の経営目標
- 顧客へ提供する価値
- 重要な事業・製品・サービス
- 法令・規制上の要求
- 契約上の要求
- リスクアペタイト
などです。
ネットワークの最上位には、企業が最終的に守りたい価値を置きます。
ここを曖昧にしたままシステムや統制を並べても、なぜそのシステムが重要なのか、なぜその統制へ投資するのかを説明できません。
Step 2. 重要業務をノードとして配置する
次に、企業価値を実現するために必要な業務を整理します。
製造業であれば、
- 受注
- 調達
- 製造
- 出荷
- 請求
- 研究開発
などが考えられます。
この段階では、BIA（Business Impact Analysis）6の考え方も活用できます。
BIAでは一般に、
「この業務が停止した場合、どの程度の影響が生じるか」
という観点から業務の重要性を考えます。
ネットワークとして考える場合には、そこからさらに、
「その業務が成立するために、何に依存しているのか」
という方向へ論点を展開していきます。
Step 3. 依存関係をエッジとして描く
次に、重要業務を支えている要素との依存関係を整理します。
例えば、次のような形です。
ここで一つ、内部統制の実務から考えてみます。
金融商品取引法に基づく財務報告に係る内部統制報告制度（いわゆるJ-SOX7）では、評価対象となる業務プロセスにおける取引の流れを把握し、必要に応じて業務の流れ図などを用いて可視化することがあります。
例えば、
受注
↓
承認
↓
売上計上
↓
請求
↓
入金
といった形で、業務がどのような手順で処理され、どこにリスクや統制が存在するのかを整理します。
このような業務プロセスの可視化は、リスクと統制の関係を把握するうえで非常に有効です。
ただし、ここで注意したいのは、
J-SOXが業務フローだけを見ており、その背後にあるITを考慮していないわけではない
という点です。
金融庁の「財務報告に係る内部統制の評価及び監査に関する実施基準」では、業務プロセスで利用されるシステムだけではなく、
- 業務プロセスとシステムとの関係
- システム間のデータフロー
- ハードウェア
- 基本ソフトウェア
- ネットワーク
- 外部委託
など、そのシステムを支えるIT基盤の概要を把握する考え方が示されています。
また、主要な取引について、
どの会計データが、どのシステムに依存しているのか
を把握することも求められています。
つまり、依存関係を見るという考え方そのものは、既存の内部統制実務にも既に存在しています。
さらにJ-SOXでは、IT統制を大きく「ITに係る全般統制8」と「ITに係る業務処理統制」という観点から捉えます。
これは、本記事で考えているネットワーク型の見方と非常に近い部分があります。
例えば、複数の業務システムが同じIT基盤に依存しているのであれば、共通するIT基盤に対する全般統制が有効に機能することで、その上で稼働する複数の業務システムを支えることができます。
では、本記事で改めて問題提起したいことは何でしょうか。
それは、
財務報告という目的に対して行われているこの依存関係の把握を、企業全体のITガバナンスへ拡張して考えることはできないか
ということです。
例えば、売上計上という一つの業務プロセスを考えても、その裏側では、
といった複数のIT要素に依存している可能性があります。
業務フロー上では、
「担当者が入力し、上長が承認する」
という統制が適切に設計されていたとしても、そのERPが利用している認証基盤に問題があれば、適切な権限管理が成立しない可能性があります。
データの完全性や正確性を確保する仕組みに問題があれば、承認された取引と実際に記録されるデータとの間に齟齬が生じる可能性があります。
クラウド基盤やネットワークに障害が発生すれば、業務プロセスそのものが実行できなくなる可能性もあります。
さらにITガバナンスとして範囲を広げれば、
- 認証基盤は他のどの重要業務でも使われているのか
- クラウド事業者への依存は企業全体でどこまで集中しているのか
- 委託先のさらに先に再委託先が存在するのか
- 障害時に代替する経路があるのか
- 復旧に必要な人員・知識が特定の担当者に集中していないか
といった論点まで見えてきます。
本記事でいう「エッジを描く」とは、単にシステム構成図を作成することではありません。
重要なのは、
- この業務はどのシステムに依存しているのか
- そのシステムはどの認証基盤に依存しているのか
- どのデータベースやクラウド基盤に依存しているのか
- どのネットワークを経由しているのか
- どの委託先や再委託先に依存しているのか
- その依存先が停止・侵害された場合、どの業務まで影響するのか
といった依存関係そのものを可視化することです。
言い換えれば、業務フローが、
「業務がどのように流れるか」
を表現するものだとすれば、ネットワーク型ITガバナンスでは、それに加えて、
「その業務が何によって成立しているか」
という依存関係を見ることになります。
この二つを重ね合わせることで、個別の業務プロセスだけでは見えにくかった、IT基盤、共通サービス、人、委託先などへの集中した依存関係を把握できるようになります。
ここで重要なのは、単純なIT資産台帳を作ることではありません。
「システムAが存在する」という情報よりも、
「重要業務XがシステムAに依存している」
という関係性の方が、ガバナンスを考えるうえでは重要です。
さらに可能であれば、エッジに、
- 依存度
- 代替可能性
- RTO9 / RPO
- データの重要度
- 責任分界
- 接続方式
- 権限関係
などの属性を持たせることで、単なる構成図から、企業全体のリスク構造を示すモデルへと発展させることができます。
Step 4. ネットワーク上の重要点を特定する
ネットワークができると、個別評価だけでは見えにくかったリスクを考えやすくなります。
Centrality：ネットワーク上の中心性
Centrality10とは、ネットワーク内において、あるノードがどの程度中心的・重要な位置を占めているかを捉える考え方です。
本記事では特に、
多数の重要業務やシステムから依存されているノード
に着目します。
例えば、
- IdP
- Active Directory
- DNS
- ERP
- 共通ネットワーク
- 共通クラウド基盤
- 特定の承認者
などです。
個別には一つのシステム、一人の担当者に過ぎなくても、多数の重要業務から依存されていれば、企業全体では非常に重要なノードになります。
Single Point of Failure：単一障害点
Single Point of Failure（SPOF）11は、その要素単独の障害によって重要な機能全体が停止し得る単一障害点を意味します。
これは技術だけの話ではありません。
例えば、
「この人しか承認できない」
「この担当者しか復旧方法を知らない」
「このベンダでなければ復旧できない」
といった人的・組織的なSPOFも考えられます。
Concentration Risk：集中リスク
複数の重要業務が、一つのクラウド、SaaS、通信事業者、委託先、担当者などへ集中して依存している状態です。12
例えば、それぞれのSaaSについて個別にリスク評価を実施し、
「サービス単体では問題ない」
と判断していたとしても、
企業の重要業務の大部分が同一クラウド事業者へ依存しているのであれば、企業全体では別の集中リスクを抱えている可能性があります。
これは個別評価を積み上げるだけでは見えにくいリスクの一つです。
Propagation Risk：影響の伝播
本記事では、一つの障害や侵害による影響が、依存関係を通じて別のノードへ次々と波及する可能性を、便宜上伝播リスク（Propagation Risk） 13と呼びます。
例えば、
- 認証基盤の侵害を起点として複数システムへ不正アクセスが拡大する
- 共通クラウド基盤の障害によって複数業務が同時停止する
- 委託先で発生したインシデントが自社サービスへ波及する
といったケースです。
ここで見るのは、個々のノードのリスクだけではありません。
「そこに問題が起きた場合、どこまで影響が届くのか」
という経路です。
Segmentation：影響をどこで止められるか
セグメンテーション14は、もともとネットワークセキュリティでも馴染みのある考え方です。
これを組織やガバナンスへ類推してみると、
- 職務分掌15
- 権限分離
- 法人分離
- テナント分離
- ネットワーク分離
- 管理者権限の分離
なども、
問題が発生した場合の影響範囲を限定する仕組み
として見ることができます。
もちろん、ネットワークセグメンテーションと職務分掌が同じ統制という意味ではありません。
ここで言いたいのは、
「一つの問題が全体へ自由に伝播しないよう境界を設ける」
という構造的な考え方には共通性があるということです。
Step 5. 重要なノードとエッジへ統制を配置する
ここまで整理すると、
「すべてのシステムへ同じ統制を入れる」
という考え方から離れることができます。
つまり、リスクベースアプローチを実現できます。
例えば、
という構造なら、SaaS A、B、Cを個別に強化することも必要ですが、共通IdPが多数のサービスに対する認証・認可の起点となっている以上、そのノードに対する統制はネットワーク全体に大きく影響します。
対策例として、
- 強固なMFA
- 条件付きアクセス
- 特権アクセス管理（PAM：Privileged Access Management）
- ログ監視
- アクセスレビュー
- 冗長化
- インシデント対応手順
などを重点的に配置することで、複数のサービスに対する統制効果を高められる可能性があります。
同時に、IdPそのものが重要な共通ノードとなる以上、その障害や侵害が広範囲に波及しないよう、可用性や復旧、管理者権限などについても相応に強い統制が求められます。
つまり、
統制設計とは、重要なノードだけでなく、重要なエッジと経路を見つけ、限られた統制資源を効果的に配置することでもある
という見方ができます。
5. 内部統制も「点」ではなく「ネットワーク」で考える
ネットワークの考え方は、ITシステムだけでなく、内部統制そのものにも適用できると考えます。
例えば、セキュリティリスクが発見されてから改善されるまでを考えます。
内部統制の評価では、単に統制が存在しているかを見るだけではありません。
必要な統制が適切に設計・整備されているか、そして実際の業務の中で継続的・適切に運用され、有効に機能しているかを評価します。
したがって、
- リスク評価手続が整備され、運用されているか
- 報告ルールが適切に機能しているか
- 会議体が実際に必要な意思決定を行っているか
- 是正管理プロセスが継続的に運用されているか
といった点を評価します。
そのうえで、ネットワークとして考えると、さらにもう一つ確認したい論点があります。
「個々の統制が有効であったとしても、それらをつなぐ情報・権限・意思決定の経路まで有効に機能しているか」
という論点です。
例えば、
どれだけ立派なリスク管理規程があり、現場でリスク評価が行われていたとしても、現場で発見された重要なリスク情報が適切な意思決定者へ届かなければ、組織全体として期待した統制効果を得ることはできません。
逆に考えれば、内部統制とは、
- 誰が検知するのか
- 誰が評価するのか
- 誰へ報告するのか
- 誰が意思決定するのか
- 誰が改善するのか
- 誰が改善結果を確認するのか
という情報・責任・権限・意思決定のネットワークでもあります。
これは内部統制の基本的要素でいう「情報と伝達」16とも密接に関係します。
また、NIST CSF 2.0のGOVERNでも、組織としてサイバーセキュリティリスクを管理するための役割、責任、権限、方針、監督、サプライチェーンリスク管理などが明示されています。
統制の「有無」や個別の「有効性」だけではなく、
統制同士の接続が正しく設計され、その経路が組織全体として実際に機能しているか
を見る。
これもネットワークからITガバナンスを考える一つの意味だと思います。
6. ネットワークとして見ることで何が変わるのか
ここまでの内容を整理すると、評価する対象が少し変わります。
従来、
「システムAには適切な統制が存在し、有効に機能しているか」
と考えていたものを、
「システムAは何を支えており、何に依存しており、ここで問題が発生した場合にどの経路で企業価値へ影響するか」
という論点を加える。
また、
「リスク管理プロセスが適切に整備・運用されているか」
という論点に対して、
「検知されたリスク情報が、適切な意思決定主体へ到達し、判断され、是正され、その結果が再び監視へフィードバックされる構造になっているか」
という論点に変える。
これは、個別の統制を見ることを否定するものではありません。
むしろ、
個別統制を企業全体の構造の中で位置付け直す
ための考え方です。
個別統制の評価とネットワークとしての構造評価は、どちらか一方を選ぶものではありません。
「点」が適切でなければネットワークは成立しません。
一方で、「点」がそれぞれ適切であったとしても、そのつながり方によっては企業全体として大きなリスクが生じます。
この両方を見る必要があります。
7. この考え方の限界
一方で、企業をネットワークとして表現すればすべて解決するわけではありません。
特に実務では、いくつか課題があると考えます。
7.1 関係性の維持が難しい
企業のシステム、業務、組織、委託先は常に変化します。
一度ネットワークを作成しても、更新されなければすぐに実態と乖離します。
例えば、
- 新しいSaaSを導入する
- システムをクラウドへ移行する
- API連携を追加する
- 委託先を変更する
- 組織改編を行う
- 業務プロセスを変更する
といった変更が発生するたびに、エッジも変化します。
そのため、実務に落とし込むのであれば、ネットワークを一度だけ作成するのではなく、変更管理、IT資産管理、CMDB、BIA、リスクアセスメントなど既存の管理プロセスとどう接続するかを考える必要があります。
7.2 すべての関係を定量化できるわけではない
技術的な依存関係と異なり、
- 組織文化
- 暗黙知
- 人間関係
- 実質的な意思決定者
- 特定担当者が持つ経験やノウハウ
などは簡単にはモデル化できません。
組織図上ではA部長が意思決定者であっても、実際にはB担当者の知見がなければ判断できない、といったケースもあります。
つまり、公式な権限関係と実態の依存関係が異なる可能性があります。
7.3 エッジを引きすぎると何も見えなくなる
企業には膨大なシステム、人、データ、委託先が存在します。
すべての要素をノードとして配置し、すべての関係をエッジとして描けば、巨大で複雑なグラフが出来上がります。
しかし、それでは重要な構造を把握できません。
したがって、
何のために、そのネットワークを描くのか
という目的が重要になります。
例えば、
- 重要業務停止のリスクを見たい
- サイバー攻撃の影響範囲を見たい
- クラウドへの集中リスクを見たい
- 委託先依存を見たい
- 内部統制上の情報伝達経路を見たい
といった目的によって、必要なノードやエッジは変わります。
7.4 ネットワーク分析そのものを目的にしない
高度なグラフ分析を行ったとしても、最終的な目的は企業価値の実現とリスク管理です。
Centralityを計算することや、巨大なグラフを美しく可視化すること自体が目的になってはいけません。
本記事で使っているネットワークという考え方は、あくまで、
「企業にとって重要な依存関係を理解し、より適切な意思決定と統制配置につなげるための見方」
です。
その意味でも、
「どの企業目的・リスクを明らかにするためのネットワークなのか」
を最初に定義するトップダウンの考え方が重要になります。
8. まとめ ― ITガバナンスとは「関係性を統治すること」なのではないか
ITガバナンスという言葉からは、
- 規程
- 会議体
- リスクアセスメント
- IT統制
- セキュリティ対策
- システム管理
といった個別の仕組みを想像しがちです。
しかし、それぞれが単独で企業を統治しているわけではありません。
組織があり、
業務があり、
情報があり、
システムがあり、
人がいて、
外部事業者がいて、
それらの間を情報、権限、責任、意思決定、そしてリスク事象による影響が流れています。
そう考えると、ITガバナンスとは、
ITを構成する個々の要素を統治するだけではなく、経営・組織・業務・情報・システム・人・委託先によって形成される「関係性」を統治することである。
とも捉えられるのではないでしょうか。
そして、ガバナンスの成熟度についても、
単純な「統制の数」やチェックリストへの適合率だけではなく、
組織というネットワークの中で、重要なノードとエッジが認識され、必要な場所に必要な統制が配置され、情報と意思決定が適切な経路を流れ、障害やリスクが発生しても全体として制御できる状態
として考えることができるかもしれません。
ネットワークエンジニアリングでは、個々の機器だけを見てネットワーク全体を評価することはありません。
どの機器がどの機器につながり、
どの経路を通信が通り、
どこがボトルネックで、
どこに冗長性があり、
どこに依存が集中し、
一つの障害がどこまで波及するのかを見るはずです。
ITガバナンスについても、同じように「点」だけではなく「つながり」から考えてみる。
そして、
トップダウンで企業目的から重要な関係を描き、ボトムアップで実際のIT・業務・人・委託先との依存関係を検証する。
既存の内部統制やITリスク管理の考え方を否定するのではなく、それらを企業全体の「関係性」という視点から捉え直してみる。
それが、本記事で提示したかった仮説です。
参考にした考え方・フレームワーク
- ISACA「COBIT 2019 Framework: Introduction and Methodology」
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」
- 金融庁・企業会計審議会「財務報告に係る内部統制の評価及び監査の基準」
- 金融庁・企業会計審議会「財務報告に係る内部統制の評価及び監査に関する実施基準」
- NIST Glossary「Risk Appetite」「Acceptable Risk」
- Business Impact Analysis（BIA）
- グラフ・ネットワークにおけるNode / Edge / Path / Centrality等の概念
本記事の「ネットワーク型ITガバナンス」「伝播リスク」といった整理・表現は、上記のフレームワークが定義する正式な方法論または用語ではなく、既存のガバナンス、内部統制、リスク管理、ネットワーク分析の考え方をもとに筆者個人が整理したものです。
-
内部統制：組織の目的を達成するために、組織内の者によって遂行されるプロセス。日本の内部統制基準では、「業務の有効性及び効率性」「報告の信頼性」「事業活動に関わる法令等の遵守」「資産の保全」の4つの目的が示されている。本記事でいう内部統制はJ-SOXに限定したものではなく、より広い意味で使用している。 ↩
-
Trust Boundary（信頼境界）：主体やシステム間で、信頼レベルや適用されるセキュリティ要件が変化する境界。本記事では、技術的な境界だけでなく、組織・委託先などの責任分界にも概念を拡張して使用している。 ↩
-
BCP（Business Continuity Plan：事業継続計画）：災害、システム障害、サイバー攻撃などが発生した場合でも、重要な事業を継続し、または必要な水準まで復旧させるための計画。 ↩
-
残余リスク（Residual Risk）：リスクへの対応や統制を実施した後にも残るリスク。 ↩
-
リスクアペタイト（Risk Appetite）：組織が目的や価値を追求するうえで、広いレベルでどのような種類・程度のリスクを受け入れるかを示す考え方。より具体的な許容水準を示す「リスク許容度（Risk Tolerance）」とは関連するが異なる概念。 ↩
-
BIA（Business Impact Analysis：事業影響度分析）：業務が停止・中断した場合に生じる影響を分析し、重要業務や復旧の優先順位、必要となる復旧目標などを整理するための分析。 ↩
-
J-SOX：金融商品取引法に基づく「財務報告に係る内部統制報告制度」の通称。上場会社等の経営者が財務報告に係る内部統制を評価し、その結果を内部統制報告書として開示する制度。内部統制一般とJ-SOXは同義ではなく、J-SOXは内部統制のうち特に財務報告の信頼性に関係する領域を対象としている。 ↩
-
ITに係る全般統制（ITGC：IT General Controls）：業務システムに組み込まれた個別のIT統制が継続して有効に機能するための環境を支える統制。代表的な領域として、システムの開発・変更、運用・管理、アクセス管理などの安全性確保、外部委託管理などがある。これに対し、入力チェック、自動計算、システム上の承認など、個々の業務処理に組み込まれた統制を「ITに係る業務処理統制」と呼ぶ。 ↩
-
RTO（Recovery Time Objective：目標復旧時間） は、業務やシステムをどの程度の時間以内に復旧させるかという目標。RPO（Recovery Point Objective：目標復旧時点） は、障害発生時にどの時点までのデータを復旧できる状態とするかという目標。 ↩
-
Centrality（中心性）：グラフ・ネットワーク分析において、ノードの構造上の重要性を評価する概念の総称。Degree Centrality、Betweenness Centralityなど複数の考え方が存在する。本記事では厳密な計算方法ではなく、特に「多くの重要な要素から依存されているノード」を発見するための観点として使用している。 ↩
-
SPOF（Single Point of Failure：単一障害点）：一つの構成要素に障害が発生するだけで、システムや業務全体が停止・重大な機能低下を起こす状態またはその要素。 ↩
-
集中リスク（Concentration Risk）：特定の事業者、システム、地域、技術、人員等に依存が集中することで、一つの事象から広範囲に影響を受ける可能性が高まるリスク。 ↩
-
伝播リスク（Propagation Risk）：本記事における便宜的な表現であり、特定の標準やフレームワークにおける正式名称として用いているものではない。障害・侵害等による影響が、システムや業務の依存関係を通じて他の要素へ波及する可能性を指す。 ↩
-
Segmentation（セグメンテーション）：ネットワークやシステムなどを複数の領域へ分離し、アクセス可能な範囲や障害・侵害の影響範囲を限定する考え方。 ↩
-
職務分掌（Segregation of Duties）：相反する権限や業務を一人・一主体に集中させず、複数の担当者等に分離することで、不正や誤りを防止・発見しやすくする内部統制上の考え方。 ↩
-
情報と伝達：日本の内部統制基準における基本的要素の一つ。組織の目的達成に必要な情報が適切に識別・把握・処理され、組織内外の必要な者へ正しく伝達されることを指す。 ↩