セキュリティインシデントの多くは「システム運用」の不備に起因
昨今、大規模なシステム障害が後を絶たちません。全国銀行資金決済ネットワーク（全銀ネット）の通信システム障害は記憶に新しく、多くのメディアでも取り上げられています。他にも金融システムに関しては、2021年にみずほ銀行の度重なるシステム障害も大きな話題となりました。また、コロナ禍では新型コロナウイルス接触確認アプリ（COCOA）のクリティカルな機能障害も議論の的に。直近では、公文書管理システムの大量ファイル消失、ディスク容量不足による工場の稼働停止、手順書の記載ミスによるシステム障害の発生、2023年11月に発生した日本カードネットワーク（CARDNET）センターのシステム障害など、今年を振り返るだけでも数多くのシステム障害が発生しています。
そして、これらのシステム障害はいずれも人為的なミス、検証や現状把握が不十分であったなど、「運用面での管理不足」に起因しています。
システム障害にともなう損失は、たった一度の発生で数億円、さらに情報が漏えいした場合には数百億円規模で損失が発生する試算もあり、ITシステムを運用する組織にとっては決して無視できないリスクでしょう。
だからこそ、システム運用において“本当に必要な対応”が行えているかどうか、今一度運用を見直し、「リスクベースでのシステム運用」を行う必要性について考えることが大切です。
短期間に連続発生した、メガバンクのシステム障害
日本有数のメガバンクである“みずほ銀行”では、2021年に9回にわたりシステム障害を発生させてしまい、金融庁と財務省から行政処分を受けました。9回の障害を起こした原因としてハードウェア障害や設定ミス、設計ミスなどがあったとされています。
これらの事象を防ぐためには、
- システムの構成管理を適切に実施する
- 作業時の構成確認を行うことでミスに気づく機会を設ける
- プログラム変更にともなう検証を徹底し、リリース前にミスを発見できる仕組みを作る
ことなどが重要です。
もう少し、それぞれの原因への対策を考えてみましょう。
2021年のハードウェア障害では、障害発生後の調査において“特定の型番で故障率が高まっている”ことが判明しています。たとえば、機器の稼働状況について網羅的な把握を行い、構成情報として管理しておくことで、保守における部品交換などの計画を立てやすくしていれば障害発生を防げたかもしれません。また、設定ミスでは作業時のダブルチェックや作業後の構成監査を実施しておけば、ここまで影響が広がる前に防げた可能性があります。設計ミスでは、構成を変更する際の検証が徹底されていれば不備に気づけたかもしれません。
みずほ銀行は、この障害に関する再発防止に向けた取り組みを公開しています。その中に、一連の事象における直接的な原因として「システムの安定稼働に必要な事項を十分に洗い出さずに、MINORIを開発フェーズから保守・運用フェーズへと態勢移行させた上、MINORIの保守・運用に必要な人員の配置転換や維持メンテナンス経費の削減等の構造改革を推進したこと」が記載されています。
このことから、体制変更がどこにどのように影響するのかを事前に把握・管理することが重要だとわかります。“運用体制を把握すること”もシステムを構成する一部要素として、適切に管理する必要があることにも注意が必要です。全体構成を適切に把握できて初めて、優先順位付けを行い対応していく、いわゆる「リスクベースの管理」を行えます。そのため、まずは組織体制を含めてシステムそのもの、それを運用する体制を把握するところから見なおすことが重要でしょう。
新型コロナウイルス接触確認アプリ（COCOA）の通知障害
COCOAは、厚生労働省が主幹した新型コロナウイルス接触確認のためのアプリケーション。利用者同士が1メートル以内に15分以上いた場合に、お互いのスマホの端末に記録を残し、陽性が確認された人が保健所から発行される処理番号を登録すると、相手方に感染者と濃厚接触の可能性がある旨をプッシュ通知する仕組みです。Android向けとiOS向けにローンチされ、全利用者の3割が利用するAndroid向けのアプリケーションで障害は発生しました。
COCOA自体は、陽性者を登録しているシステムである「HER-SYS」とは切り離された別システムとして稼働しており、通知を行う場合はHER-SYSとデータを照合する必要があります。そのため、COCOA側で仕様を変更した際には外部システムであるHER-SYSと連携できることを確認する“テストの実施”が重要なポイントと言えるでしょう。
本来であれば、COCOAのメイン機能が問題なく動作することを確認するためにテストは必要ですが、当時は対応の緊急性を優先したために当該テストが省略されました。これによりアプリケーションの改修がシステム連携に問題ないかどうか、未確認の状態でリリースされたのです。
これにより不具合が発見できず、本来通知しなければならないタイミングで通知が行われない不具合が発生しました。現実には、必要な手続きの一部を省略してリリースすることが状況によってあり得るかもしれません。しかし、不具合が発生して想定通りに動作しなければ、どれだけ早くリリースしても意味がないでしょう。むしろアップデート前より状況が悪くなることで信頼を失ったり、機能としてまったく役に立たなくなったりするような重大な影響を及ぼしかねません。
このような事態を避けるためには、仕様変更などを行う際に必要な手続きのうち実施する必要性、実施しないことによるリスクの大きさを可視化し、優先順位をつけて対応していく「リスクベースの変更管理」を行うことが有効な手段として挙げられます。
