ブログ

少数精鋭のコンサルタント集団である〇〇コンサル社では、外部講師を招いた勉強会を頻繁に開催しています。開催回数の増加にともなって、マイナンバーを収集する業務も日常化しています。

外部講師（マイナンバー申請者） には、フィッシングによる情報漏洩リスクを下げるべく、オンラインの申請フォームから先頭8桁のみを申請してもらっています。その申請を受け、「番号確認社員」が “本人確認” （実存確認と番号確認）を実施したうえで、末尾4桁を入力します。

しかし、記憶違いによって末尾4桁の入力を間違えてしまうことがありました。

結果として、誤ったマイナンバーが法定調書（税務署提出用の源泉徴収票）に書き込まれ、税務署から「そのようなマイナンバーは存在しない」と指摘されるという問題が発生してしまいました。なんとかして “再発” を防止したいところです。

〇〇コンサル社では、「チェックディジットを用いた自動検査」を “ワークフロー・アプリ” に組み込むこととしました。

※ チェックディジットとは誤入力を検知するための検証用数字です。マイナンバーの場合は、先頭11桁の数字から12桁目が自動的に決定される仕組みとなっています。

プロセスオーナーは自動工程『#マイナンバー文字列: チェックディジット検査』を、ワークフローの下流に配置しました。

これにより「番号確認社員」が末尾4桁を入力した直後に、サーバサイドにてチェックディジット検査が行われるようになりました。もし、「マイナンバー(8+4)桁」が無効な12桁番号であった場合には、自動的に［再入力工程］に差し戻されるようになりました。

少数精鋭のコンサルタント集団である〇〇コンサル社は、外部講師を招聘した勉強会を頻繁に開催しています。

• 外部講師への講演料を支払う
• 外部講師からマイナンバーを収集する

は、日常的に行われています。

〇〇コンサル社の “マイナンバー収集プロセス” は 「外部講師による申請フォーム入力」 がトリガーとなっています。申請フォームにマイナンバーが入力されると、外部講師を招聘した社員に対して、「本人確認」というタスクが割り当てられる仕組みです。

近年、この “マイナンバー収集プロセス” のトリガー部分（申請フォーム入力）に関して、一部の外部講師から、「フィッシングによる情報漏洩が懸念される」という声が聞かれるようになりました。

〇〇コンサル社のマイナンバー申請フォームは、”リンクを知っていれば誰でもアクセスできるWebフォーム” です。したがって、デザインが模倣された 偽フォーム が作られる可能性は否定できません。

もし万が一、 偽フォーム によって外部講師のマイナンバーが詐取されるような事件が発生すれば、〇〇コンサル社としても、セキュリティ管理体制に対する不信感を招き、顧客や取引先からの信頼を失ってしまう可能性があります。

そこでプロセスオーナーは、このリスクを低減すべく、マイナンバーの分割送信という対策をとることにしました。

具体的には、マイナンバー申請フォームでは「マイナンバーの全12桁」を入力させるのではなく、「先頭8桁のみ」を入力させるように改めました。「残りの4桁」（末尾4桁）については、担当社員（”番号確認社員”）に口頭で伝える旨を記載しました。

この改善の結果、「情報漏洩の懸念が下がった」や「機密情報を全て送信しないので安心だ」といった感想が寄せられるようになりました。