アララ停止で横浜市の電子申請、メール認証が要る人はログインできず

メールが1通届かないだけで、役所の申請の入口が閉じることがあります。

横浜市の電子申請・届出システムは、10月31日17時40分ごろからメールを送れなくなりました。メールの二段階認証が必要な人はログインできません。11月3日21時45分の更新でも、復旧の見込みは未定です。

原因は市のシステムではなく、その先にあるメール配信サービス「アララ メッセージ」の緊急停止です。アララの件は約7700万件の漏えいとして伝わりました。ただ、配信を任せていた側には、止まり方というもう1つの問題が出ています。

3つの市で、止まったものが違う

横浜市、大阪市、姫路市の申請の仕組みは、いずれもTKCの提供です。メールの配信はそのTKCからアララへの委託で、姫路市の発表の言葉では「再委託」にあたります。

委託の形は同じでも、影響の書かれ方は市ごとに異なります。

いちばん重い影響は、横浜市のログインでしょう。同じシステムの中でも、メールの二段階認証が要る人と要らない人で分かれました。どんな人にメールの二段階認証が必要なのかは、お知らせに書かれていません。本人が選んだ設定なら、認証を増やした人ほど入れないという皮肉な形です。

もちろん、二段階認証をやめようという話ではありません。考えたいのは、2つ目の要素がメールだけで、そのメールを1社の配信サービスに頼っている作りです。大阪市と姫路市の発表はログインの停止にふれていません。メールの二段階認証を使っていないのか、書いていないだけなのかは分かりません。

横浜市のお知らせには、もう1つ細かい記述があります。ログインに1分程度かかり、申請のあとに読み込み中の表示が続いても、1分ほど待てば完了するそうです。メールの送信が終わるのを待ってから次へ進む作りなら、こうなります。配信サービスの停止が、画面の遅さとしても出ているとみています。

止まる先は申請だけでもありません。TKCが影響を受けると挙げたシステムには、マイナンバーカードの交付予約と、緊急連絡先の登録も入っています。姫路市の発表によると、ひょうご防災ネットのメール配信にも影響が出る可能性があります。

関西の利用者の目線では、アララ不正アクセスで止まる関西のメール 防災はアプリ、申請はマイページ（西のITメディア）で読めます。

影響も漏えいもないという説明は、数日で変わった

委託元に届く説明の変わり方も、情シスには他人事ではありません。

10月29日と30日に「ない」と伝えられたものが、11月2日には最大223万812件になりました。TKCのアドレスの内訳と、各市の利用者が含まれるかは、まだ分かっていません。

時間を重ねると、もう1つ見えてきます。アララの第2報の表では、サービスを経由した持ち出しは10月29日1時36分から30日2時22分で、把握は31日の午前です。TKCの環境がこの区分かは書かれていません。そうだとすれば、横浜市のお知らせが「ない」と伝えた10月29日16時15分は持ち出しの最中で、確認した側がまだ気づいていなかった時間です。

責めたいわけではありません。調査が進めば答えは変わります。アララ自身も、10月30日の続報では、ほかの環境での流出はないとしていました。

委託先の影響なしという答えは、その時点の回答として受け取りたいものです。社内に流すときは、いつの、だれの、どの範囲の確認かを添えておきましょう。段数が増えるほど、この情報は落ちやすくなります。今回はアララからTKCへ、TKCから市へ、市から市民へと3段ありました。

会社に関係するのは2つの場面

まず、TKCの企業向けのシステムを使っている会社です。TKCの第1報は、次のシステムでメールを送れないとしています。

• FXクラウド、FX4クラウド、SX2、SX4クラウド
• PXまいポータル、TKCまいポータル
• 証憑保存機能、インボイス・マネジャー、月次決算速報サービス

代わりの運用があるものは、利用者に個別に案内しているそうです。顧問の税理士に勧められて使い始めた仕組みは、情シスの台帳に載っていないことがあります。経理に聞いてみるのが早いでしょう。

次に、自治体の電子申請を事業者として使っている会社です。横浜市の約82万件の登録には、事業者のアカウントも含まれます。届け出の担当者がログインできないなら、期限のある手続きは、早めに市の担当部署へ相談することになります。

アララもTKCも使っていない会社に、直接の影響はありません。ただ、同じ作りは自社の中にもありえます。

自社の確認メールはどこから出ているか、確かめること

1. 重要なSaaSと社内のシステムから、確認コード、パスワードの再設定、招待のメールを1通ずつ集めます。ヘッダーのReturn-PathとDKIMのd=を見ます。配信サービスのドメインが見えれば、そこが依存先です。Amazon SESの独自のMAIL FROMやSendGridのドメイン認証を使う送り主では、自社名や送り主のドメインしか見えません。そのときは、そのサブドメインのCNAMEやMXを引くか、Receivedの最初の送信元を見ます。SaaSから届くメールでヘッダーから先が分からなければ、そのSaaSの委託先の一覧か窓口で確かめます。
2. 管理者のアカウントから順に、メール以外の認証要素を足します。ログインや再設定の手段がメールだけなら、配信が止まった日は、セッションが切れた管理者から順に入れなくなります。緊急用のアカウントも、別の要素で1つ用意します。
3. パスワードの再設定ができない日の答えを、ヘルプデスクと決めておきます。だれが本人を確認し、だれが再設定するか、の2つです。
4. 自社で作ったシステムは、テスト環境で配信先を止めてみます。画面が送信の完了を待って止まるなら、送信を別の処理に分けます。切り替え先の候補はメール配信サービスの地図で比べられます。
5. 次の契約の更新で、委託先に3つ聞きます。メール配信の再委託先はどこか、止まったときと漏れたときの連絡はいつ来るか、影響がないと答えるときの根拠は何か、です。

今夜、委託先のメールが止まったとします。最初に入れなくなるのはだれでしょう。答えが「管理者」なら、今週の優先順位はもう決まっています。