障害発生時・災害発生時の対外公表について考える

障害発生時・災害発生時の対外公表について考える

9月18日、Zaifがシステムトラブルにより、取引を停止しました。9月18日の15時現在、復旧には1日から2日程度かかる見込みであると発表しています。

https://twitter.com/zaifdotjp/status/1041881617516716032

FISC安全対策基準は、「システムトラブルを起こさない」ための基準と、「システムトラブルが起きたときに備える」基準に大別されていますが、実は「システムトラブルを対外公表する」ことについては、その基準が明確に示されていません。今回は、FISC安全対策基準では明確に示されていない、対外公表について考えます。

利用者に対して、システムトラブル発生時に説明を行うように求めているのは、以下の基準だけです。

【統5】サイバー攻撃対応態勢を整備すること。

サイバー攻撃への対応策として、「利用者(顧客)への説明を行う」という記載がありますが、内容やタイミングについての記載はありません。

【実71】障害時・災害時復旧手順を明確にすること。

営業店に対して、影響範囲や復旧見込みを知らせるように求めていますが、利用者に対する説明については記載がありません。

【実73】コンティンジェンシープランを策定すること。

肝心なコンティンジェンシープランの内容についても、利用者に対する説明といった記載は一切ありません。同じくFISCから出ている「コンティンジェンシープラン策定のための手引書」の第5章には、サイバー攻撃発生時における顧客対応方法についての記載を確認することができますが、こちらも「適時適切に」とあるだけで、内容やタイミングについては具体的な方針については記載がありません。

【実115】インターネット・モバイルサービスの顧客対応方法を明確にすること。

サイバー犯罪が行われた場合の手口については、可能な限り利用者に公表することを求めていますが、その内容やタイミングについての記載はありません。

【実128】コンビニATMの障害時・災害時対応手順を明確にすること。

コンビニATMにて障害が発生した場合、その状況を利用者に連絡する方法について定めておくように記載がありますが、内容やタイミングについての記載はありません。

つまり、サイバー攻撃を含めて、システムトラブルが発生した場合の公表方法については、その内容やタイミングについては各社に任されてしまっています。その反面、トラブル発生後には「適時適切に利用者に公表していない」という金融庁の行政処分が下される、というのが現状となっています。


では、どのような対応をとるのがよいのでしょうか。

事前に、公表するメディアを決めておく必要があります。Webサイトや、ツイッター、Facebook、Telegramといったメディアを使うのが一般的でしょう。Webサイトの場合は、逐次更新を行う特設ページを設定することになりますが、履歴を残すためにも、過去のデータの修正や削除は行わず、常に追記するか、発表時刻ごとにPDFファイルを作成することが必要です。

ハード故障やサイバー攻撃を検知した場合は、オペレータからエンジニアに通知が送られ、現状を確認することになります。この時点で、取引が成立しづらい(または取引できない)状況であることを公表する必要があるものと考えられます。

地震などの広域災害の場合は、現在の状況と、今後のサービスに与える影響について、定期的に発表するのが良いでしょう(特に停電や津波といった、長期間影響を及ぼす可能性がある災害の場合は、定期的に発表する必要があります)。

より具体的には、金融機関の事例を確認すると、取引ができない場合や、影響が出ている場合は発生から1時間以内には公表し、影響がない場合でも、数時間以内には公表しているところが多いようです。参考までに、例を作成しました。

例:(第1報)○月×日午前XX:XXより、XX取引、YY取引、ZZ取引が成立しづらい状況となっております。現在、状況を確認しておりますが、取引可能件数を通常の半分に制限しております。ご利用のお客様にはご迷惑をおかけいたしますが、時間をおいて再取引いただきますよう、お願いいたします。次のご連絡は、おおむね1時間後を予定しております。

このように、発生時刻、影響のある取引、影響内容、制限状況、作業状況、お詫び、次の発表予定時刻です。次の発表予定時刻を明確にしているのは、要らぬ憶測を呼びかねないリスクや、問い合わせの電話やメールが殺到してしまうリスクに備えたもので、「状況に変化がない」場合であっても、その旨を公表します。こういった報告内容は一般的にネガティブレポートと呼ばれます。1時間から2時間程度にしておくことが望ましいでしょう。もちろん、大きな動きがあった場合は、その予定時刻にかかわらず公表します。

例:(第2報)○月×日午前YY:YYより、すべての取引を停止いたしました。現在、状況を確認しておりますが、調査に時間がかかっております。まずはお客様の資産が保護されていることを最優先に確認しております。次のご連絡は、おおむね1時間後を予定しております。

ここで記載しているのは、状況報告時刻、システムの状況、影響の調査状況と範囲です。特に仮想通貨の場合は、利用者の資産に対する影響が一番の関心事ですから、これを最優先で確認する必要があるため、それも含めて公表しています。安全のため、取引をすべて停止することも、場合によっては判断する必要があります。

例:(第3報)○月×日午前ZZ:ZZ、お客様の資産について確認いたしました。午前XX:XX以降、お客様の資産はホットウォレット、コールドウォレットともに保護されていることを確認いたしました。障害の原因は確定しておりませんが、一部のサーバに問題が発生していることを確認しております。次のご連絡は、おおむね1時間後を予定しております。

例:(第4報)○月×日午前AA:AA、原因が、一部のIPアドレスからの大量の通信による高負荷であることを確認いたしました。現在、ファイアウオールの設定を変更した上で、およそ2時間後を目処にサービスを再開する予定です。ご利用のお客様にはご迷惑をおかけしておりますが、復旧まで今しばらくお待ちください。次のご連絡は、おおむね1時間後を予定しております。

原因については、憶測ではなく確定した情報を公表します。確定できない場合は事実のみを公表するに留めます。また、再開の見込みがある場合は、再開予定時刻を明示します。再開予定時刻が公表間隔より広い場合であっても、公表間隔は変更しません。

例:(第5報)○月×日午前BB:BB、現在、ファイアウオールの設定を変更し、最終確認を行っております。1時間後を目処にサービス復旧予定です。ご利用のお客様にはご迷惑をおかけしておりますが、復旧まで今しばらくお待ちください。次のご連絡は、復旧時点、復旧に時間がかかる場合でも1時間後を予定しております。

例:(第6報)○月×日午前CC:CC、ファイアウオールの設定を変更し、XX取引、YY取引を再開いたしました。ご利用のお客様には、大変ご迷惑をおかけいたしました。なお、ZZ取引については、現在もお取り扱いできません。なお、臨時のシステムメンテナンスを行います。○月△日XX:XXからYY:YYまでの期間中、すべてのサービスがご利用いただけませんので、ご注意ください。ZZ取引の再開については、○月△日YY:YYの臨時メンテナンス終了後となる見込みです。

平時と異なり、緊急時は、「状況に変化なし」という報告を流すだけでも、対応が行われていることが見えるため、十分に意味があります。調査中であれば何を調査しているのか、その状況はどうなっているのか、回復作業中であれば、何を回復させようとして、どれくらいに復旧する予定なのか、といった情報を盛り込むことで、利用者側に不安ではなく、安心感を与えることができるようになります。

ただ、公表することで、かえって社内に焦りを生むようなことだけは避けてください。「公表した内容と違う」のであれば、無理にねじまげることなく、公表した内容を訂正します。「予定よりも時間がかかっている」のであれば、その通りに公表します。取り繕うのではなく、事実を公表することが、利用者から信頼される一歩ですし、仮に調査が誤っていたのであれば、それは次回に向けた改善点とするのが、最も重要なことと考えられます。

障害訓練を行う際には、こういった対外公表を行う、といった点についても、是非検討してください。

FISC安全対策基準では、「障害訓練を行い、手順を改善すること」が求められています。

 

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です