自治体情報システムの共同化とフォレンジックから見た課題
デジタル・フォレンジック研究会 会長
立命館大学情報理工学部 上原哲太郎

はじめに：自治体の情報システムの不幸• 機関委任事務を法定受託事務に整理し直し自治事務も拡大
その流れで地方分権の名の下「それぞれ創意工夫せよ」と言われてきた結果、ある程度の規模の自治体は独自に業務システムを成長させてきた• オープン化とパッケージ化・アウトソーシングの波はただでも立場の弱い情報システム担当を追い込みメインフレーム・オフコン時代に抱えていた内製できる開発者を駆逐してしまった• 結果的にコスト高の情報システムを抱え込みパッケージ依存・業者依存のために急な業務に情報システムが即応できない「デジタル敗戦」• これをバネに急激なクラウド化をテコにした共通化が進められようとしているが対応できるのか？
2

自治体システムの情報化の経緯• 昭和30年代にまで遡れる・・・• 35年大阪市 36年京都市 38年東京都・神奈川県• 大型計算機時代：大都市のみ• 昭和50年代に急速に進展• オフコンの利用：市町村に広く浸透• しかしここまでは基本的に自治体の自主的活動• e-Japanに基づくネットワーク化• 住基ネットとLGWAN＝「政府主導の統一的な情報化」• この頃から「地方自治への逆行」の声はあった• 後期高齢者医療制度をはじめとする「統一システム」• 広域連合の仕組みによる共同業務だけでなく全国的にシステムの統一化が図られた

3

かつての典型的自治体情報システム
住基CS
LGWAN

住基ネット

FW
FW／GWサーバ

FW/文書交換
システム等

住基

税務
バッチ処理
or 即時連携

戸籍
乳幼児
選挙・・・

固定資産
軽自動車
・・・

閉鎖系LAN(メインフレーム・オフコン)

フ
ァ
イアウ
ォ
ール
または未接
続

文書管理
施設予約・・・

フ
ァ
イアウ
ォ
ール

Web
メール

イン
ター
ネ
ット

議会録
提供・・
情報系LAN(パソコン)

開放系DMZ4

自治体の情報システムの特徴• 「基幹系」「情報系」「インターネット系」に分けられる• 基幹系のコアをなすのは「住民基本台帳」と「税務」• これを中心に業務ごとにシステムが組まれる• どんな自治体も50や100の「システム」がある• ある程度の規模の市町村は基幹系はメインフレームだった時代がありその負の遺産に今も苦しむ• レガシーマイグレーション問題• 小規模だとオフコン時代にパッケージ化が進んでた• 情報系はPCやUNIXサーバ中心• 国は長く統制をとってこなかった• よってシステムの実装は千差万別• しかし住基ネットとLGWANによって初めて統制の動き• APPLIC標準でAPI/データ互換が一応図られたが…

5

6

その情報システムの管理は？
• 早くから情報化を果たしたところほど「全て自分たちでやる」傾向が強い•よってメインフレームがあったところは今でも独自開発できるスタッフを抱えているところも• しかし多くは外注に出している•アウトソーシング推進の影響• 結果として「情報システム」を理解する正規職員が減少• 極めて少ないスタッフで運営•町村レベルではまず専属スタッフはいない•システム管理で手一杯・セキュリティは？？？
•システム調達業務しかできないところも7いくつかポイントとなる事件• 1999年 宇治市住民基本台帳漏洩事件•開発委託先の持出・転売• 2007年 愛南町住民情報漏洩事件•作業委託先がマルウェア感染• 2015年 日本年金機構サイバー攻撃•付随して上田市サイバー攻撃事件•いわゆる標的型メール攻撃8

長野県上田市に対する標的型攻撃• 年金機構への攻撃の際に発見される• 1500台のPCのうち9台が感染• 標的型攻撃から4ヶ月気づかず• ログが残らず情報漏えいの全容は不明• 住基ネットから強制遮断
再接続まで1ヶ月半• 業務正常化に半年以上
9

標的型攻撃はパターンがある
内部サーバ

外部サーバ

File,DB,Apps… Web,Mail,DNS…

LAN

基盤構築

DMZ

Internet

踏み台

侵入→基盤構築→目的達成…なので基盤構築時の活動を妨害し早期発見

10この県単位共同化も大きなポイント
セ Web
キ メール
自治体システムの「強靭化」
ュリ
テ
FW
住基ネット
ィク
SOC監視 ラ 議会録
ウ 提供・・
LGWAN
住基CS
ドFW／GWサーバ

住民のマイナンバー

FW/文書交換
システム等

LGWANASPへ

フ
ァイアウ
ォ
ール
または未接
続

文書管理
職員の施設予約
マイナンバー・・・

ファイアウォール

イ
ネン
ッタ
トー
インターネット系
ここの切断が話題になった

閉鎖系LAN

情報系LAN(パソコン)11

自治体情報システムの原課調達主義問題• 各原課（＝業務担当課）が業務で使用する情報システムを個別に申請・調達・運用する体制• 原課は情報システムの専門家ではないので…
• システムの機能・処理能力と費用の関係について適正な評価が出来ない→費用対効果が悪化• 「使い勝手」を仕様に記述できない→導入後改修＝追加費用• 他システムとの連携・システム更新時のコストを見誤る・見落とす→導入後追加調達＝追加費用• 定期的に担当者異動で運用ノウハウ喪失→導入業者依存• 自治体側にはシステムに詳しい人が育たない• それどころか業務ノウハウも業者に依存するようになる• セキュリティも導入業者任せ→セキュリティポリシーと不整合• 多様なニーズに対応する導入業者のカスタマイズ負担も大きい

本質的にコスト高の構造 これは共同化が解消する？

12

自治体情報システムに見られる「IT版ストックホルム症候群」＝全ての根本原因• ©前田達之(@keikuma)氏• cf. サーバ管理者日記 2010年8月19日• 原課調達主義＋減点評価主義から産まれる• 自治体において不適切な調達・導入・運用にも関わらず、導入業者のコスト高やミスを原課がかばう現象• そもそもコストが評価できない ミスの本質が指摘できない• 業者を失うと仕事が出来なくなる• 結果、コスト高は放置され軽微な事故の報告は隠蔽される• 特に情報セキュリティ関連の事故は報告すると個人情報漏洩の懸念から責任追及されやすい→隠蔽体質になる• ハインリッヒの法則（ヒヤリハットの法則）に従い重大事故の危険を見逃した状態でシステムが放置される→地雷を抱えた状態になる
13

この状況でやってきたコロナ禍

14

接種券&V-SYS問題は根が深い

15

IT新戦略＝世界最先端デジタル国家創造宣言
・官民データ活用推進基本計画

16デジタル庁の目指す統一システム

17

総務省「自治体ＤＸ推進計画概要」R2.12.25より

18

総務省「自治体ＤＸ推進計画概要」R2.12.25より

19

20

21

基本17分野

住民基本台帳選挙人名簿管理
固定資産税
個人住民税
法人住民税
軽自動車税
国民健康保険
国民年金
障害者福祉

後期高齢者医療
介護保険
児童手当
生活保護
健康管理
就学
児童扶養手当子ども・子育て支援
問題は独自部分?
22

先行事業が進行中
https://www.digital.go.jp/posts/ZYzU5DYY

23

並行した動き1：マイナンバー見直し

マイナンバー制度及び国と地方のデジタル基盤抜本改善ワーキンググループ（第1回）資料より 24並行した動き2：住基ネット見直し

25
https://www.soumu.go.jp/main_content/000753609.pdf

沸き起こる「間に合わない」の声• 政令市は特に…
• 規模が大きい• そもそも独自システムを育ててきた歴史が長い• 独自施策が多くパッケージに単純に乗らない• 長い間に人が去りシステムがブラックボックス化している…
26

レガシーマイグレーション問題はブラックボックス問題• 京都市のレガシーマイグレーション事例（日経等の報道）• 30年以上メインフレーム上で動かした基幹システムを新システムに刷新する事業• 2014年から移行開始 2016年には多くを移行• 性能が出にくいバッチ処理部分について刷新を
2016年1月 11億円でS社が落札→2017年1月に完了せず 法廷へ• 2018年3月 15億円でC社が落札→2020年1月予定がこれも完了せず総事業費がさらに膨らみ約99億円となる？
• 2020年9月 事業一部中断へ
国の動きを待つというが…？
27

共同化の必要性をどう考えるか？
→必要。コスト構造からしてもう他に手はない。

• ただしコストを下げるためにはカスタマイズをどのように実現するかが鍵• おそらく基幹業務を細分化してマイクロサービスにする方向が本当は良い• SaaSよりPaaSに近いモデルが理想• しかし2025年という年限が切られてる状態ではおそらくは2段階にせざるを得ない• 単純にパッケージをクラウド移植したものに移行（リフト）
マイクロサービス化はその後に考える？
28

業務フローの改善が重要• 困ったのは法廷受託事務でも結構ローカルルールが発生している• 事務の本能として「帳票の体裁」に拘りすぎる問題• 文書を中心にするのではなくデータを中心に業務フローを組む発想が必要

29

自治体の業務の自由度を確保する方策• ガバメントクラウドの実現法が鍵• いわゆる「マイクロサービス化」がポイント• 業務パッケージを細かく機能分割する• 困るのはその先• APIが提供されたとしてそれを業務に組み込むのは誰か• 従来パッケージのカスタマイズを行っていたのは自社or系列ベンダだがWebサービス化された業務システムのカスタマイズに地方の事業者はどの程度対応できるのか？
30

地域のベンダーへどのような影響が出るか• 影響はある（ノウハウのご破算）• しかしもっと大きな問題は「技術者が育たない問題」だった• そもそも地方ベンダーは現時点でも「パッケージインストール」と「カスタマイズ」を主業務にしてきた• マニュアル化が進むと技術として蛸壺化する• 業務そのものの分析とサービスの組み立てが今後メインの業務と出来るのなら生き残れる• それは地域活性化にも役立つはず31データの移行における課題
データの移行以外の点での課題• データ移行問題の本丸は「外字問題」
文字情報基盤への移行が既定路線だが大変な労力• データが人質なのは間違いないがそれ以上に「業務が人質」になっている• 業務ノウハウがシステムの中でブラックボックス化しているので自治体と共依存になってしまっている• それを引き剥がさないとベンダロックイン問題が解決しない32

フォレンジックにおける課題• 国・自治体・ベンダの責任分解は複雑になる• インシデントレスポンス時には調整が難しい• インシデントの影響範囲の見極めも大変• クラウド固有の問題• ログの多くはクラウドプロバイダにあるが大半がビッグデータ化しているシステムでは特定インシデントに関わるものの抽出に大きな負荷• 保全の対象とできる部分が限られる• 消去されたデータの復元が困難• 事前の備えが必要• そもそもシステムは設計段階でフォレンジックを意識すべきでは？
33