orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

政府や自治体のシステムが今までどうなっていて今後どうなるかをできる限り簡単に説明してみる

f:id:orangeitems:20210828004426j:plain

 

政府や自治体のシステムって、縦割りでベンダーに丸投げするから無駄が多くて、税金から払わなくてもいいお金が一杯出て行っている。しかも国民から見るといっぱいサイトがある割にはどれもデザインが違っていて、さっぱりどこ見ていいかわからない。どうなってんの。

ここがまず国民の不満の出発点だと思うんですね。

そしてクラウドなる新しいITの利用が一般化してきていて、政府や自治体も積極活用しようということになりました。ただその話が出てきたのが2012年でそのときはAWSすらまだ数あるサービスの一つだったこともあり、国内ベンダーに、政府共通プラットフォームなる基盤を作らせて2013年に利用をし始めました。クラウドと言っても、VMwareの基盤にインターネットをつないだだけです。

そして、2016年に、会計検査院からこの基盤はダメ出しを受けます。利用料が高い割にはさっぱり使われておらず、使われ方もまるで不合格。この状況が改善しないまま、2019年に政府は新しい方針を出します。第二次「政府共通プラットフォーム」です。2020年10月に運用を始めたこの基盤はAWSです。AWSに今後政府や自治体のあらゆるシステムが乗るんじゃないかと当時は巷を騒がせました。

 

ここまでの流れは、過去書いていますのでご興味があればぜひお読みください。

 

www.orangeitems.com

 

さて、話はここからです。

このニュースが出ました。

 

nordot.app

 政府が中央省庁の情報システムを統合するため昨年10月に開始した「共通プラットフォーム」の運用を打ち切ることが27日、総務省などへの取材で分かった。約720件ある政府情報システムのうち利用は約40件と低迷。総務省が今年6月、各省庁に来年度以降の受け入れ中止を通知した。年間予算約100億円を見込んだ事業は開始から1年持たずに頓挫した。

 現在の「第2期」共通プラットフォームは、今年9月に発足するデジタル庁の新しいシステムには引き継がず、数年の移行期間を経て廃止される。政府共通システムはデジタル庁で一から作り直すことになる。

 

で、このまま理解するのはおかしいので、この記事を書きました。

デジタル庁がどう絡んでくるかがこのままでは不明です。共通プラットフォームはどうなるの?。まるでデジタル庁が「第3期」共通プラットフォームを作るのかと思いますよね。少しこれまでの考え方とは違うんです。

下記の記事を熟読すると、これから何が始まるのかがわかります。

 

xtech.nikkei.com

 中央省庁に加えて地方自治体や独立行政法人など公的機関も共同利用する、空前の規模のクラウド基盤構想が、早ければ2022年度の一部運用開始を目指し動き出す。自治体に対しては、基幹系システムの稼働環境として採用する努力義務を法律で課す方針であることが日経クロステックの取材で明らかになった。実現すれば自治体とITベンダーともに対応には大きな変革が迫られるのは必至だが、国と地方の基幹系システムを全て飲み込む超巨大クラウド構想は本当に実現するのか。

 政府が行政デジタル改革の一環として構築するクラウド基盤「Gov-Cloud(仮称)」は、2021年9月に発足する「デジタル庁(仮称)」が構築・運用を担当する。2020年12月下旬に閣議決定した行政デジタル改革の基本方針で構想を明らかにしており、2021年度に実証実験や設計に着手する。

 政府は自治体が運用する基幹系システムの標準化を進めている。自治体には既に2025年度までを期限として国が定めた標準システムへの移行を義務付ける方針を公表済みだが、自治体にとってはGov-Cloudへの移行も同時に検討するべき事項となる。

 

そう、この「Gov-Cloud」こそが新しいプラットフォームです。

え、どこのクラウド?、AWS?、Azure、国内ベンダー?、なんて発想の人が多分ほとんどなのですが、ここを改めて頂きたいのです。

 

 実際、政府はGov-Cloudについて、民間のクラウドベンダーからIaaS(インフラストラクチャー・アズ・ア・サービス)やPaaS(プラットフォーム・アズ・ア・サービス)を調達して構築する方針だ。2020年10月に米アマゾン・ウェブ・サービス(AWS)のサービスを採用して稼働した第2期の政府共通プラットフォームが先行事例となる。

 とはいえ中央省庁の中小規模の業務システムが主な対象だった第2期政府調達プラットフォームと比べ、Gov-Cloudは共同利用の対象が大幅に広がる。調達するクラウドの規模もさらに大きくすることを想定している。ベンダーにコストや機能を競わせて、用途などで複数のサービスを組み合わせて使う「マルチクラウド」になるという。

 

つまり、政府の基準にあった複数のクラウドサービスをデジタル庁が購入し、それを政府や自治体が利用する、という図式になります。技術の変化により何を選定するかは変動しますから、AWSもその一つに過ぎません。

共同通信の記事では「第2期」共通プラットフォームは取り壊し、デジタル庁の基盤に作り直す、という表現でしたがこれは違いそうです。今稼働しているシステムについても、このまま使うかも含めてレビューし最適化して行くと言うことになるでしょう。また、Gov-Cloudがいろいろなサービスの中でAWSも今後選ぶというのは確実なので、AWSが捨てられるという話でもありません。

そもそも、Gov-CloudはIaaS(インフラ)だけではなく、PaaS(プラットフォーム)やSaaS(ソフトウェア)まで範疇に入れていますので、インフラだけをこれまで話題としてきた政府系プラットフォームとは違うんだということを頭に入れて頂きたいところです。

 

一方で、Gov-Cloudは最近は「ガバメントクラウド」と呼ばれるようですが、こんな話も。

 

xtech.nikkei.com

 IT室は2021年9月からガバメントクラウドの先行事業を始める予定だった。2021年6月に自治体の募集を開始し、平井卓也デジタル改革相は7月の記者会見で市町村から52件の応募があったと述べていた。しかしIT室によると8月25日現在、クラウド提供事業者の募集に向けて準備中で調達内容を検討中という。

 

このマルチクラウドで行く基盤自体がまだ未定なので、いったい何の基盤上にアプリケーションが載せられるのかわからず、そのため実際のシステムのオーナーである自治体は予算取りできん!、ってことになってるらしいです。

 

ちなみに、デジタル庁が採用するクラウドの基準は「ISMAP」と呼ばれ、これを理解するには下記のサイトの記事がわかりやすいです。

 

mypage.otsuka-shokai.co.jp

クラウドサービスの文脈で、「ISMAP」という言葉を目にすることが多くなってきた。ISMAPは、内閣官房、総務省、経済産業省により設立された「政府情報システムのためのセキュリティ評価制度」のことである。ISMAPは、この英訳である「Information system Security Management and Assessment Program」を略した通称名であり「イスマップ」と読む。

ISMAPの目的は、政府がクラウドサービスを調達する際に、そのセキュリティレベルを判断できるようにするための基準を定めること。政府が求めるセキュリティ要求を満たしているクラウドサービスをあらかじめ評価・登録することで、円滑な導入を実現するための制度である。つまり、ISMAPに登録されていないクラウドサービスは、政府が導入検討する情報システムの対象とされない可能性が高い。

 

ここに登録されたサービスしかデジタル庁は買わないので、日本のデータセンター事業者はこぞってどうやったらISMAPに登録できるか血眼で努力しています。

ISMAPに登録されているサービスは以下のサイトで公開されています。

 

www.ismap.go.jp

 

ISMAPの制度設計は着々と進んでいるのですが、デジタル庁がガバメントクラウドで何を採用するかはまだ決定が遅れている。

以前のように、インフラありきで基盤を決めるのではなく、政府の基準(ISMAP)をクリアしたサービスの中でデジタル庁が最適と考えるサービスを選択し、マルチクラウドで是々非々で考えていく。

こういうシナリオで今の状況を捉えておくとよいでしょう。

個人的にも一昔前の「AWSの上に全部政府のシステムが乗る!」って言う雰囲気は全く好きではなかったので、良い方向に進んでいると思います。一つのインフラ基盤しか使えないというのは明らかに複数のリスクがありますから。

 

ちなみに、AWSも、ガバメントクラウドに深く寄与していきたいという意欲的な記事も出してますので、こちらも紹介しておきます。

 

aws.amazon.com

本日令和2年(2020年)12月25日、『デジタル・ガバメント実行計画』が閣議決定に至りました。

今回のブログでは、335ページの大部の政策集となった『デジタル・ガバメント実行計画』(以下、『実行計画』。全文はこちら)を、クラウドの観点から読み直すことで、特に政府部門・公共部門の各お客様にクラウド導入をご検討いただく判断の一助となることを目指します。昨年版から120ページ以上も大幅加筆された最新の『実行計画』では、何が謳われているのでしょうか?

 

今回のようにデジタル関係のニュース記事は、情報が切り取られ過ぎて意図を正しく理解するのが難しいので、一度立ち止まって情報収集することをお勧めします。

 

ワクチン接種会場で感じたこと

f:id:orangeitems:20210826173323j:plain

 

ワクチンの一回目を打ってきたのですが、まあ運営側ももう二か月くらい続けているからですかね、かなりテキパキしてたなという印象です。

集団接種自体が高齢者からスタートしたせいか、年齢層が下がって、対象者の歩くスピードが早く受け答えも早いので、運営側も気持ちいいのかなと思います。たくさんの人々を誘導しつつ、正確にワクチン接種まで行い、そして出口まで速やかに出す。簡単なように見えて参加してみるとかなり考えられた作りであることがわかります。

まず、入口で、予約時間より早く来た人を通さないこと。中の人数をコントロールしないと途端に密になってしまいます。

その後、バッファとなる空きスペースに待機しつつ、各種書類に不備がないかを事前チェックします。チェック後しばらく自分の番がコールされるのを待ちます。

コールされ、次のコーナーに向かうと、再度、事前チェックされました。二度目は「ワクチン接種券」のシステム入力と、ワクチン接種に問題がないかの問診でした。

そこまで終わったら、ちょっと離れた別室まで歩かされ、再度、医者による問診がありました。なんで二回も?と思ったのですが、念には念をという感じでした。

その後、また、前回と違う空きスペースに通され、しばらくしたらやっと接種会場へ。

お医者さん(多分)に注射されましたが、全然痛くなかったです(大事)。

ここまで、入場から15分くらいでした。

接種後、また、前回と違う空きスペースに通されるとともに、私の右肩にシールを貼られました。ワクチン接種後急変しないかを確認するために15分の待機が必要で、その時間が貼られました。

待機している間に、今日の接種に関する書類の説明をされ、また副反応に関する書類を渡され、その後右肩のシールを左肩に貼りかえられました。

そしてその時間が来たら、シールを剥がされ、「今日は終了です。」との案内が。

全体としては入場から30分で全部完了しました。出口に進んで終了です。

と、記憶をさかのぼって思うのですが。完全にプログラミングの世界ですよね。

接種対象者というデータがあって、それを読み込むメモリー領域があって、接種にあたっては事前プログラムで加工したうえで、何度かバッファーに読み直し、最終的に処理を行い、データを更新して完了。

あまりにもデータを読み込みすぎるとメモリーがオーバーフローするし、プログラムにバグがあると書類に不備が発生し例外処理が走って、途端にパフォーマンスが低下する恐れがあります。そのため事前チェック処理をたくさん入れているロジックを感じました。また、接種後のステータス確認もきちんと行っていました。

思ったのですが、ITでこういうことをやらせると日本人は比較的苦手なのに、なぜ人手でアナログに動かせるとこんなに優秀なのかなーと。

これって、学校教育の賜物なんじゃないかと思いました。

アナログベースでは、多くの人々はかなり主体的に、ロジカルに動けるんじゃないですかね。それって、日本の教育制度がいかに優れているかということを証明していると思います。

最近は人工知能(AI)の話に事欠きませんが、結局は人を並べて一斉に対応させたほうが完全によりよい結果を出すのではないですかね。日本に限った話ですが。

これだけ、おしなべて教育水準が高い人々を所有する日本が、希望退職や早期退職で人をどんどん放出する話が出てくるのは実は変な話で、日本人ってAIなんぞより全然優秀なのに使いこなせてないだけなんじゃないかなと思った次第です。

学校教育も、アナログからデジタルへの変革期が来ていると思いますが、ちゃんと土台に乗せて基礎を学ばせる体系ができたら、未来もそんなに暗くはないんじゃないかな、と感心して帰宅の途に着きました。

 

企業はオープンソース無料版をフリーライドするなという主張は正しいのか?

f:id:orangeitems:20210823133422j:plain

 

オープンソースソフトウェアに昔からある、フリーライド(無料でただ乗り)問題についての意見です。

 

japan.zdnet.com

TDFは、LibreOfficeを「自由・オープンソースソフトウェア」(FOSS)と称している。ボランティアによって開発されているCommunity版を企業組織がフリーライドする行為は慎むべきであり、さもなければLibreOfficeはオフィスの生産性スイートである「OpenOffice」のような停滞に陥る可能性があるという見解を維持している。

 

無料版と有料版があり、無料はCommunity Editionとして無料となっているケース、別のソフトウェアでもありますよね。Community、という言い方に対して良い訳語が日本語にないらしく、日本人はピンと来ていないように思います。

・UiPath
・Delphi
・Nutanix
・Visual Studio
・MySQL
・Automation Anywhere
・LabVIEW
・Alfresco
・Veeam

などなど。ほかにもモリモリあります。Free Editionとは誰も言わなくなりましたね。

 

なぜFreeではなくCommunityなのでしょうか。コミュニティーとは「共同体意識を持つ人々の集団。地域社会。」のような意味ですが、ソフトウェアにこの言葉を使うのは意味不明です。無料で使ったら、君も集団の仲間だよ、ぐらいの意味かもしれません。でも別にコミュニティーの一部になったわけでもなく、単に無料で使ってるだけだと思います。

で、この無料で使っている人たちに、以下のように呼び掛けるのはいかがなものでしょうか。

 

ボランティアによって開発されているCommunity版を企業組織がフリーライドする行為は慎むべきであり、さもなければLibreOfficeはオフィスの生産性スイートである「OpenOffice」のような停滞に陥る可能性があるという見解を維持している。

 

オープンソースへのフリーライドは慎むべきだ、という議論はオープンソースが生まれた当初からある議論です。しかし、この理屈は私はそろそろ時代遅れになっているのではないかと考えます。

一つに、Communitiy Editionをビジネス利用されたくないのであれば、契約で絞るという手段があります。

 

openstandia.jp

MySQL Community Serverは、無償で自由にダウンロードして利用できますが、MySQLの使用にあたってGPLのライセンス使用条件に従う必要があります。 また、商用製品として使用する場合などは、使用条件を詳細に確認する必要があります。

 

で、サーバー製品などはGPLライセンスとしてオープンソースにすると、かなり制約を受けるのでサブスクリプション版など有償版を買ってもらいやすい環境となります。

また、MySQLの場合はOracleが契約の履行を実質監視しているので、企業側もおいそれとはCommunity Editionでフリーライドしにくいのです。

 

ですから、「開発はボランティアでやってるんだから、商用利用している企業はCommunity Editionで済ませてフリーライドするんじゃないよ。そしたら開発側も干上がっちゃって誰も開発する気がなくなり、ソフトウェアも更新されなくなっちゃうよ」と言う、と。これってビジネスとしておかしいんじゃないかと思うんですね。

RedHatなんかは、オープンソースのソフトウェアをくるんで企業に有償でソフトウェアを販売していますが、逆にRedHatがパッケージとして利用しているオープンソースの団体には多額の資金を提供しています。

 

www.redhat.com

 

オープンソースコミュニティー側も、ユーザーを脅すばかりじゃなく、どうビジネスとして成立させるかまでを構築する必要があります。そこまでが持続可能なソフトウェアとしても成立条件ではないかと思うのです。

以前、GitHubをMicrosoftが買収しましたが、これもオープンソースコミュニティーの一つの在り方です。一つの企業がオープンソース自体の運営に責任を持ち、その収支構造までデザインし、ユーザーに永続的に安全なソフトウェアを提供する必要があると思います。

ソフトウェアは、幾多の事件の通りサイバー攻撃にさらされて続けています。どこかの営利団体が収支が成り立つ形で保守し続けないと、たちまちマルウェアの餌食になる世界です。

フリーライドが問題ではなく、フリーライドさせてしまう配布・利用の仕組みを、オープンソースソフトウェアの運営側が法的、経済的に改めることこそ、オープンソースのあるべき姿ではないかと思いますがいかがでしょうか。結果として、「ボランティアで開発」というあまり生産的ではない状況を変えることができるように思います。

 

みずほ銀行システム障害(2021/8/20)ハードウェア障害で話を終わらせてはいけない

f:id:orangeitems:20210820234431j:plain

 

2021/8/20に発生したみずほ銀行のシステム障害について、記者会見をNHKのサイトにて閲覧しました。

 

www.itmedia.co.jp

勘定系システム「MINORI」のハードウェア部分で発生したシステム障害により、8月20日朝からみずほ銀行とみずほ信託銀行の店頭窓口で入出金や振り込みが一時できなくなっていた問題で、みずほフィナンシャルグループ(FG)は同日、緊急の会見を開き、MINORIと店舗の事務処理端末をつなぐシステムが故障していたと明らかにした。バックアップも機能しなかったといい、故障原因やバックアップが作動しなかった原因について「調査中」としている。

 

何かあったら日本国中に注目されてしまうシステムを運用するというのは、それはもう大変なことです。グループCEOや銀行頭取も責められていましたが、トップは「再発防止策を考えます」で逃げられるかもしれないが、銀行窓口や営業店(フロント)には大いに負荷をかけてしまう。しかももう今年に入って5回目ですから、フロントが作り上げてきた信用を都度都度壊してしまう。障害を起こさなくする、というのは一言で言えますが、なぜそれをやらなければいけないかと言うと、全くの信用問題だからだと言えます。

度重なる障害の結果作り上げられた再発防止策。それを実施していた最中に再発してしまう。しかも今回の障害は、ハード障害とのことで、場所は違いますが3月12日に発生した「DBサーバーディスク装置」ということで、そこから5か月経っているのになぜ、これだけ広範な業務影響が出てしまうのかということが、会見中でも記者から何度も質問されていました。

なお、3月12日の障害においては、日立の名前が出されたのですが、今回は非公開とのこと。

 

jp.reuters.com

日立製作所は5日、みずほ銀行で3月12日に発生した外貨建て送金遅延について陳謝した。みずほフィナンシャルグループは同日、障害は日立が保有・管理するサーバーとディスク装置が故障ししたために発生し、日立側で万一に備えた早期復旧手順と体制が確立されていなかったなどと指摘した。

 

前回は、「ベンダー側で手順や体制が確立できていなかった」という結論となりましたが、今回は会見を聴く限りは様相が違いました。

「複雑な壊れ方をした」ということばが何度か出てきました。DBサーバーディスク装置と言う表現は、あたかも物理サーバーのローカルディスクの用にも聞こえますが違うようで、いわゆるストレージサーバーなのだと思います。

このストレージサーバー、どの機種も似た構成ですが、「CPUやメモリー、ファームウェア、ディスクコントローラー」などを乗せたシステムボードを、アクティブ-スタンバイ、もしくはアクティブ-アクティブで、二系統持っています。

そして、ディスクの集合体に対して、二系統がつながりアクセスできるようになっています。

今回は、バックアップ、という言葉も出てきましたので、アクティブ-スタンバイで動作していたのでしょう。アクティブ側が故障を発生したのでスタンバイ側に切り替わろうとしたけれども、切り替わらなかった、いや、切り替わったのだけれど中途半端に切り替わり「複雑な壊れ方をした」、と会見で伺いました。

さて、この話自体は、ベンダー自身が説明したわけでもなく、まだ原因未定のフェーズだったので、話としてはもっと解像度を上げて説明がされると考えます。

 

3月12日に同様の障害が起きた、ということが気になって、二か月前にみずほより提出された再発防止策をのぞいてみました。

 

www.mizuho-fg.co.jp

2021 年 3 月 11 日 23 時 39 分、①MINORI の共通基盤に存在するストレージ装置内の通信制御装置が故障したことで、ストレージ装置とサーバの間の通信が遮断され、同サーバ上で稼働する業務システムが停止しました。そのうち、②「統合ファイル授受」(センター集中記帳処理に必要なファイル等の受け渡しを基盤間で行う業務システム)の停止により、センター集中記帳処理が遅延し、これにより、③主に外国為替送金処理が遅延する等の影響が生じました。

エラーを検知後、直ちにストレージ装置の復旧対応を行いましたが、通信制御装置の交換後も接続が回復せず、全サーバ復旧までは 6 時間 41 分、統合ファイル授受の復旧までは 6 時間 59 分を要しました。

「統合ファイル授受」復旧後、センター集中記帳処理が順次再開されましたが、外為システムにおいて適切な復旧(リカバリ)手順が取られず、規定の時限までに処理が完了しませんでした。

 

www.mizuho-fg.co.jp

• ベンダーによる復旧に約7時間
• みずほ側の復旧作業においても手順ミス

 

前回と様子が違うのが、みずほ行内での対応に不備はなく、「ハードウェア障害」というキーワードが強調された会見ということでした。

ただ、前回はベンダー名として日立が出て来たのに、今回は非公開というのは、この前の東証システムトラブルの際に非公開を貫いた事例があったからなのかはわかりませんが、ちょっとちぐはぐな気もしました。

 

 

 

さて、3月、8月と、似たようなハードウェア障害が発生したのですが、一つ分かったことがあるのではないでしょうか。

「ストレージサーバーは、システムトラブルが起こると復旧には10時間前後かかる」、と。

ベンダーと、ハードウェア障害が起こっても短時間で回復できる仕組みを今から考えると言う趣旨の発言もありましたが、結局は前回も、今回も時間はかかったわけです。

だから、ストレージサーバーは壊れるし冗長化してもすぐには復旧しないことがある、と言うことを前提にシステム増強を進めるべきです。

いろんな機能によってこの基幹システムMINORIは成り立っていますが、それぞれの機能において、ハードウェア構成が独立した正副のシステムを動作させ、システムごと副系に切り倒すことは有効でしょう。

もしくは、システム性能を2倍以上にしたA系、B系を稼働し、それぞれアクティブ-アクティブで使うという方法も取れます。仮にA系が停止した場合はB系で2倍稼働させる。

以上は、AとBで2系統の話ですが、場合によりA、B、C・・・などと3系統以上にすることも実装可能です。

二日前ほどに、集中管理は危険というお話をしたばかりですが。

 

www.orangeitems.com

 

1つのハードウェアが停止したら、重要業務が止まり、会社の信用問題に関わるというのは正直言って脆弱な設計のように見えます。

そして、複数の機能が今回のように1つのハードウェアが停止したら止まるのであれば、リスクは掛け算になります。どの機能が欠けても、大騒ぎになるのですから。

 

CEOや頭取が記者会見をして、ハードウェアの構成からシステム障害のロジックまで語らなければいけないのは、これはメガバンクほどの巨大組織としてはレベルが低いと思います。

1つや2つのハードウェアが想定外に停止しても、業務が継続されるべき、です。

もし、今回ハードウェア障害の原因を突き止めたとしても、全く同じ理由で障害が起こることはほぼありません(修正されるため)。しかし、また違う理由で何かが起こるのです。3月にも8月にも起こったのですから。

機器の冗長化レベルの話に済ませるのではなく、システム全体の冗長化が必要、ということですね。ハードウェアのレイヤーを仮想化し、ソフトウェアたる業務は動作が継続できるような作りにしなければいけません。

それぐらい、日本に取って重要システムですから。

 

ひとまずは今日の感想です。もっと詳しい情報が出てきたらまた考察します。

 

サイバーセキュリティーの盲点 行き過ぎた集中管理はシステムを脆弱にする

f:id:orangeitems:20210818125753j:plain

 

サイバーセキュリティーについて思っていることを話しておきます。

運用管理者の責務の中でもっとも大事なのは把握です。会社にどんなネットワークが構築され、その中にどんなサーバーがあり、何を動かしているか。そしてユーザー管理、権限管理がどのように機能しているか。そして最近はインターネット経由で会社の外と連携しています。SaaSを利用しているかもしれませんので、閉じた世界で考えるのは危険です。いくら社内がヘルシーに動いていても、会社の外で使っていたあのサービスが問題を起こしたときに、思っても見ない事故につながることもあるやもしれません。

把握していない場所で何が起こっても運用管理者は手出しができない割に、経営者からは説明責任を求められます。とにかく把握把握ということで、運用管理者は把握できやすくするためにいつも努力をしているといっても過言ではありません。

そこで運用管理者は把握するために何をするでしょうか。ここが大事です。「集中管理」です。WindowsならばActive Directoryドメインを構築しようとします。全てのサーバーやクライアントPCをドメインコントローラーにぶら下げればあら便利。全て一つのコンソールから管理できるようになります。テンプレートを作って配下にばらまいて、同じ管理ポリシーを適用することもできます。

また、最近はクラウドを企業が使うのが当たり前になってきたのですが、クラウドも複数の種類を使う(例えばAWS、Azure、Google Cloudなど)ことも多く、どこに何があるのかを把握することが大変になっていました。また同じAWSでもアカウントが部署ごとに別ということもあります。このようなニーズに対して、全てのクラウドに接続し一つの管理コンソールで確認できるソリューションも流行しています。確認だけではなく、サーバーを作成したり、料金を比較したりなど、この分野も進歩しています。

その他いくつでも例は挙げられますがこの辺にして、集中管理と把握は結びついていることが前提として、サイバーセキュリティーの盲点を話します。

集中管理できる状態のときに、何でもできるID、特権IDの存在が大問題になります。

Windowsドメインであれば、ドメインアドミニストレーター権限を持つIDです。このIDが攻撃者に知れ渡ると、基本的にはドメインの下にあるリソース全てが脅威にさらされます。

ドメイン配下にバックアップサーバーがある構成は最悪です。バックアップサーバー自体も同時に攻撃されたときに、どこにもバックアップが無い状態でデータを人質に取られてしまいます。

特権IDのパスワードは運用管理者が厳重に管理しているから大丈夫、と思っている人もいるかもしれません。しかし運用管理者の端末が何らかのマルウェアに感染し、バックドアを仕掛けられ、その端末に「password.txt」なんてファイルがあってそれを開けたら特権IDのパスワードやIPアドレスが書かれていたら?。

もしくは、ドメインコントローラーのWindows自体にバックドアが仕掛けれられたら終わりです。特権IDのパスワード自体を変えてしまえばいいのですから。

最近、よく使われるLinuxであるUbuntuが21.04でActive Directoryに参加する機能を実装しましたが、絶対私は使用しないです。面倒であっても各サーバーごとに独立して権限設定すべきだと思っています。

クラウドの集中管理であったって、各クラウドの参照だけに留めるべきだと思っています。全クラウドでサーバーを作ったり削除できたりする権限まで持ったとしたら、第三者がサーバーを立てまくるかもしれません。

各システム、各機能ごとに、権限は全く別にし、分散して管理するのがサイバーセキュリティーを高めるポイントだと考えます。

A社のシステムが危険だとしても、B社のシステムが同時にダウンすることはあまりないのです。それはA社とB社が独立性を保っているからです。

これが、A社とB社が経営統合し、システム更新のときに共通基盤を作り、その基盤上にA社とB社のリソースを載せた時に問題が起こります。共通基盤が脅威にさらされたとき、A社とB社が両方吹っ飛ぶ可能性があります。

こんなことを言うと、集中管理しないことで運用コストがかかるじゃないか、という意見が出てきます。そうです。サイバーセキュリティーにはコストがかかるのです。このコストを省略するために集中管理を進め、その結果一か所に権限が集中し過ぎて、それを破られたときに全部アクセス不能になる。

実際、サイバーセキュリティーにおけるPDCAの現場では、運用管理者が把握できているかを厳しく問われます。そのため情報システム投資の目的で多くの集中管理ソフトウェアが導入され、その結果把握に関してどんどん自動化できるようになっています。

ところが、この進捗こそがサイバーセキュリティーを脆弱にしていくのです。そして特権IDの管理方法についてとても厳重にしていくのですが、結局は運用管理者は作業のために利用せざるを得ず、そこが弱点となっているシステムが多数世の中に存在すると思っています。

この辺りの考え方は、実はサイバーセキュリティーの本を見たってどこにも書いてありません。分散管理することで把握に人手が必要になり、コストが増えていくことは、経営者にとってうれしくないからです。ほとんどのサイバーセキュリティーの理論は経営者目線で書かれています。ベンダーも、経営者に対してサービスを売るので、そうならざるを得ないからです。

今、システム構築や運用に関わっている方は、ぜひ、分散し冗長に管理することのメリットを頭に入れておいてほしいです。人手はかかります。でも問題が起こった時に、「ああ、分けておいてよかった」と思うと思います。