新章 第十一話 誰がシステムの安全に責任を持つのか――担当者を叱っても、設計は変わらない
第十一話 誰がシステムの安全に責任を持つのか、―担当者を叱っても、設計は変わらない
情報流出が発生すると、まず原因が調べられる。
どこから侵入されたのか。
どの情報が外部に流出したのか。
どのような設定が問題だったのか。
誰が異常に気づき、誰が対応したのか。
原因を究明することは必要である。
しかし、調査の結果、担当者の操作ミスや管理不足が見つかったとして、それだけで問題は解決したと言えるだろうか。
担当者を処分する。
研修を受けさせる。
確認手順を増やす。
注意喚起のメールを全社員に送る。
こうした対応が役に立つ場合はある。
だが、同じ事故が再び起きる可能性を残したまま、個人への注意だけで終わってしまうこともある。
もし、一人の操作ミスで重要な情報が大量に流出する設計だったなら、問題はその担当者だけにあるのだろうか。
もし、現場が危険性を指摘していたにもかかわらず、修正に必要な予算や人員が確保されていなかったなら、誰が責任を負うべきなのだろうか。
そして、システム全体を把握できないほど複雑になっていたなら、その複雑さを生み出した判断は、どこで行われたのだろうか。
情報セキュリティを考えるには、事故を起こした人だけではなく、事故が起きる環境をつくった組織にも目を向ける必要がある。
## 一 技術者に責任を負わせても、技術者だけでは解決できない
企業の情報システムを実際に管理しているのは、技術者や運用担当者である。
彼らは、システムを監視し、設定を変更し、障害に対応し、脆弱性を修正する。
しかし、現場の担当者が、組織のすべてを自由に変更できるわけではない。
古いシステムを更新するには、予算が必要になる。
運用を変更するには、関係部門との調整が必要になる。
業務を停止して修正するには、経営上の判断が必要になる。
外部事業者との契約を見直すには、法務や調達部門の協力が必要になる。
技術的に危険だと分かっていても、現場だけでは解決できない問題がある。
たとえば、古いシステムに重大な脆弱性が見つかったとする。
理想を言えば、速やかに修正すべきだろう。
しかし、修正によって業務が停止する可能性がある。システムが古く、修正プログラムを適用すると正常に動作しなくなるかもしれない。そもそも、そのシステムを構築した事業者との契約が終了している場合もある。
こうした事情があるとき、担当者に「すぐに直せ」と命じるだけでは、問題は解決しない。
必要なのは、危険性を評価し、代替策を検討し、修正に必要な資源を確保し、経営上の優先順位を決めることである。
技術者には、技術的な危険を発見し、説明し、対策を提案する役割がある。
しかし、その提案を実行できる環境を整えることは、組織全体の責任でもある。
現場に責任を求めるのであれば、現場が責任を果たせる権限と資源も与えなければならない。
## 二 経営判断は、システムの構造に残る
企業の経営判断は、決算書や事業計画だけに残るわけではない。
情報システムの構造にも残る。
システムを更新するか、古いまま使い続けるか。
独自に構築するか、外部サービスを利用するか。
複数のシステムを統合するか、分離したまま管理するか。
安全性の向上に、どれだけの費用と人員を配分するか。
これらは、技術的な選択であると同時に、経営上の選択でもある。
費用を抑えるために、更新を延期することはあり得る。
業務を効率化するために、システムを統合することもあり得る。
人員不足を補うために、外部の事業者に運用を委託することもあり得る。
それぞれの判断には、合理的な理由があるかもしれない。
問題は、そうした判断が間違っているかどうかを、結果だけで単純に決めることではない。
判断した時点で、どのような危険性が認識されていたのか。
その危険性を、誰が評価したのか。
危険を受け入れる判断を、誰が承認したのか。
事故が起きた場合の影響を、どこまで想定していたのか。
そこを検証する必要がある。
特に、システムの複雑さが増している場合には、目先の効率だけでは判断できない。
統合によって運用費用が下がっても、管理すべき接続点が増えることがある。外部サービスを利用すれば、自社の負担が減る一方で、サービス提供者への依存が強まることもある。
短期的な費用削減が、長期的な管理負担の増加につながる可能性もある。
だからこそ、情報セキュリティは、技術部門だけに任せるべき問題ではない。
経営陣は、技術的な詳細をすべて理解する必要はないかもしれない。
しかし、自社がどのようなリスクを抱え、どのリスクを受け入れ、何を優先して対策しているのかについては、説明できなければならない。
## 三 企業統合で増えるのは、規模だけではない
第七話で考えた、企業統合の問題に戻ろう。
企業が別の企業を買収したとき、手に入るのは売上や顧客基盤だけではない。
システムも、データも、契約も、運用ルールも、過去の判断も引き継ぐことになる。
買収前から存在していたシステムを、そのまま使い続ける場合もあるだろう。統合を進めるために、新しいシステムへ移行する場合もあるだろう。
しかし、どちらを選ぶにしても、移行期間には複雑さが生じる。
旧システムと新システムが並行して動く。
部門ごとに異なる権限管理が残る。
古いアカウントが使われなくなっても、適切に削除されない。
担当部門が変わり、管理責任が曖昧になる。
こうした問題が実際にどの企業で発生しているかは、個別の事実に基づいて検証する必要がある。
ただし、統合に伴って管理対象が増える以上、その管理を設計すること自体が重要な課題になる。
会社を買収することと、その会社の情報システムを把握することは同じではない。
ブランドを統一することと、アクセス権限を統一することも同じではない。
組織図を一つにすることと、事故発生時の責任分担を明確にすることも同じではない。
統合によって得られる利益を実現するには、統合によって増える複雑さにも対処しなければならない。
そのためには、買収や再編の計画段階から、システムの構成、依存関係、データの所在、管理責任を調べる必要がある。
そして、統合が終わったと宣言するだけではなく、統合後も継続的に検証する必要がある。
企業の歴史が長いこと自体が、危険なのではない。
過去に積み重なった仕組みを把握せず、その複雑さを管理できないことが、リスクになり得るのだ。
## 四 外部に任せても、責任まで外部に移るわけではない
現代の企業は、多くの業務を外部の事業者に委託している。
クラウドサービス、データセンター、ソフトウェアの保守、ネットワークの運用、情報セキュリティの監視。
すべてを自社で行うよりも、専門的な事業者を利用するほうが合理的な場合は多い。
外部委託そのものが問題なのではない。
問題は、委託したことによって、自社が管理しなければならないリスクまで見えなくなってしまうことである。
自社のデータは、どこに保存されているのか。
外部事業者は、どこまでアクセスできるのか。
障害が発生したとき、誰が何を担当するのか。
事故を発見した場合、どのくらいの時間で報告されるのか。
契約が終了したとき、データやアクセス権限はどのように処理されるのか。
こうした条件が明確でなければ、問題が発生したときに、責任の所在や対応の手順が曖昧になる可能性がある。
また、委託先が安全性を確保していても、その先に別の事業者が存在する場合がある。
自社から直接見える範囲だけを管理していても、実際に依存している仕組みの全体像を把握できるとは限らない。
だからこそ、外部委託では、契約を結ぶことだけでなく、継続的な確認と管理が必要になる。
ただし、すべての責任を委託元だけに負わせればよいという話でもない。
サービス提供者には、自らのサービスを適切に設計し、運用し、問題を報告する責任がある。利用者には、サービスの性質を理解し、自社の情報や権限を適切に管理する責任がある。
それぞれの役割を明確にし、事故が起きたときに連携できる仕組みを用意することが重要なのである。
## 五 AIに任せた仕事の責任は、誰が負うのか
第十話では、AIがサイバー攻撃と防御の双方を変えつつあることを考えた。
AIは、大量のログを分析し、異常の候補を見つけ、調査を支援できる。
一方で、AIエージェントが外部のサービスに接続し、ファイルを読み、業務システムを操作するようになれば、その行動を管理する必要性も高まる。
AIが誤った判断をした場合、誰が責任を負うのだろうか。
AIを開発した事業者か。
AIを導入した企業か。
利用目的や権限を設定した担当者か。
AIの判断を確認せずに実行を承認した管理者か。
答えは、状況によって異なる。
すべてをAIのせいにすることはできない。
AIは、自分で企業の経営方針を決め、予算を配分し、社会的な責任を引き受ける存在ではない。AIをどのような目的で導入し、どのような権限を与え、どのように監督するかは、人間や組織が決めることだからだ。
一方で、AIの判断をすべて人間が逐一確認すればよいという単純な話でもない。
AIを導入する目的の一つは、人間だけでは処理しきれない仕事を支援することにある。すべての操作に人間の確認を必要とすれば、速度や効率という利点が失われる場合もある。
必要なのは、操作の重要度に応じて権限を設計することだ。
情報を検索するだけの操作と、機密情報を外部へ送信する操作では、危険性が異なる。
調査の候補を提示することと、重要なシステムを停止することでも、必要な確認の水準は異なる。
その違いを踏まえ、どの操作をAIに任せ、どの操作には人間の承認を必要とし、どの操作を禁止するのかを決める。
さらに、AIの行動を記録し、問題が起きたときに検証できるようにする。
AIを導入するとは、単に便利な道具を追加することではない。
新しい権限と、新しいリスクを組織の中に組み込むことでもある。
だから、AIを利用する組織には、その利用方法を設計し、監督する責任がある。
## 六 安全性は、報告書の中だけに存在してはならない
大きな企業では、情報セキュリティに関する報告書が作成される。
対策の実施状況。
脆弱性の修正状況。
監査の結果。
訓練の実施回数。
事故への対応状況。
これらの情報は、経営判断に役立つ。
しかし、数字が整っていることと、実際のシステムが安全であることは同じではない。
訓練を実施していても、実際の事故で連絡網が機能するとは限らない。
バックアップを取得していても、復旧できるとは限らない。
脆弱性を管理していても、把握されていないシステムが残っていれば、管理の網から漏れる可能性がある。
安全性は、書類上の手続きが完了しただけでは確保されない。
重要なのは、対策が実際に機能するかを検証することだ。
復旧手順を実際に試す。
アクセス権限を定期的に確認する。
異常を検知したときの対応を訓練する。
外部事業者との連絡や役割分担を確認する。
システム構成が変わったときに、管理対象を更新する。
そして、問題が見つかったときに、それを報告した人が不利益を恐れずに伝えられる環境をつくる。
現場からの報告が、組織の中で止まってしまえば、経営陣は実際のリスクを把握できない。
問題を報告した人を責める組織では、問題が隠される可能性がある。
一方、問題を早期に報告し、改善につなげる組織では、事故が起きる前に対処できる可能性が高まる。
ただし、報告しやすい文化だけで十分というわけでもない。
報告を受けた後、実際に調査し、優先順位を付け、必要な対策を実行する仕組みが必要である。
安全性は、報告書の中だけに存在するものではない。
現実のシステムと、日々の運用の中に存在しなければならない。
## 七 責任とは、事故のあとに犯人を探すことだけではない
ここまで考えてきたことを整理しよう。
技術者には、システムの危険性を発見し、対策を実施する役割がある。
経営陣には、必要な予算や人員を確保し、リスクに関する判断を行う役割がある。
外部のサービス提供者には、自らが提供するサービスを適切に設計・運用し、利用者と必要な情報を共有する役割がある。
利用者にも、与えられた権限を適切に使い、不審な状況を報告する役割がある。
それぞれの役割は異なる。
だからこそ、責任を一人に集めるだけでは、組織全体の安全性を確保できない。
事故が起きた後に、誰が間違えたのかを調べることは必要である。
しかし、それだけでは、次の事故を防ぐための設計は変わらない。
なぜその操作が可能だったのか。
なぜ異常を検知できなかったのか。
なぜ被害が広がったのか。
なぜ対策が実行されなかったのか。
これらを検証し、仕組みを改善することまでが、事故への対応である。
責任とは、失敗した人を見つけることだけではない。
失敗が重大な被害につながる構造を見つけ、改善し、同じ問題が繰り返されないようにすることでもある。
そして、重大なリスクを認識しながら対策を先送りした判断についても、検証されなければならない。
個人のミスを免責するということではない。
個人の責任と、組織の責任を混同しないということだ。
## 八 最後に残る問い
情報セキュリティの問題は、技術が進歩すれば自然に解決するものではない。
システムが複雑になれば、管理すべき対象も増える。
AIが高性能になれば、できることも増えるが、権限の管理や誤作動への備えも必要になる。
企業が統合されれば、事業の可能性は広がるが、異なる仕組みを管理する負担も生まれる。
外部サービスを利用すれば、効率化できる一方で、依存関係を把握する必要がある。
その一つひとつに、技術的な判断があり、経営上の判断があり、組織としての責任がある。
だから、情報セキュリティを担当者だけの仕事にしてはいけない。
経営陣がすべての技術的な問題を理解できなくても、リスクを把握する仕組みを整えることはできる。
現場がすべての経営判断を変えられなくても、危険性を報告し、改善を求めることはできる。
外部事業者に業務を委託しても、何を委託し、何を自社で管理するのかを明確にすることはできる。
すべての事故を防ぐことはできないかもしれない。
しかし、事故が起きても被害を限定できるようにすること、復旧できるようにすること、原因を検証して改善することは、組織として取り組める。
そのためには、安全性を現場の善意や個人の努力に委ねず、仕組みとして組み込む必要がある。
ここまで、企業の統合、システム設計、世界の情報流出、AIによる攻防、そして責任の所在を考えてきた。
それぞれの問題は違う。
しかし、共通しているのは、人間が作り上げた仕組みを、人間の注意力だけでは支えきれなくなっているという現実である。
では、最後に何を問うべきなのだろうか。
情報セキュリティの担当者を増やせば、それでよいのか。
最新のAIを導入すれば、それでよいのか。
企業を統合し、システムを一元管理すれば、それでよいのか。
どれも、必要な対策の一部にはなり得る。
しかし、それだけでは十分ではない。
技術を導入することと、その技術を安全に使い続けることは違う。
組織を大きくすることと、その組織を管理できることも違う。
安全対策を実施したと報告することと、実際に安全性が確保されていることも違う。
**安全性を本当に引き受けるとは、何を意味するのだろうか。**
この問いに、最終話で答えたい。
