ワークフローサンプル: マイナンバー制度をワークフロー化する(5)

『ご契約にはマイナンバーが必要です。フォームに入力してください。
（もしくは郵送してください）株式会社○○○○』

インターネット上には、無数の「フィッシングサイト」が存在する。たとえば「クレジットカード番号」や「オンラインバンクの暗証番号」などがだまし取られる被害は、後を絶たない。「マイナンバー」（個人番号）を集めようとするフィッシングサイトも、遅かれ早かれ出現するだろう。（「マイナンバー占い」とか、絶対ダメ！！）

『もしウチの社名を名乗るフィッシングサイトが出現したら・・・』

多くの外部フリーランスを活用しているような会社であれば、「オンライン申請」に頼らざるを得ない。しかし、もしも模倣フィッシングサイトが出現するような事態になればタイヘンだ。基本的には、「データ送信先」や「郵送先」の確認をオネガイする、くらいしか方策がない。

確認ファイル送信先のURLは「https://example.com」です！！
確認書類のコピー郵送先は「京都市中京区○○番地」です！！

前回紹介した「マイナンバー申請プロセス」

マイナンバー制度をワークフロー化する(4)

の例では、遠隔地にいるフリーランスさんも、弁護士さんや税理士さんも、オンラインで申請することができた。しかも「マイナンバーの収集に関与する人」を極めて限定的な数に減らすことが可能な、秀逸なワークフローだ。その結果として「人的な情報漏洩のリスク」を限りなくゼロにできることができる。

しかしこの例では、「マイナンバー」や「証明書の画像ファイル」を添付してもらう必要があった。

A. 『運転免許証』の画像
B. 『通知カード』の画像

※A: 『個人番号カード(表)』や『パスポート』等といった写真つき身分証明書で代用可能
※B: 『個人番号カード(裏)』や『新住民票』といったマイナンバーが記載された証書で代用可能

つまり、フィッシングサイト側の視点でいえば「だまし取りやすい構造」と言える。情報セキュリティの有資格者によってもリスク評価は様々だが、少なくとも「リスクがゼロ」とは言い切れない。そもそもセンシティブな情報をオンラインやりとりしないですむ方法は無いものだろうか？

以下のワークフローは

オンラインで、「A.運転免許証の画像」も「B.通知カードの画像」も送信しない(!!)、
オンラインで、「12桁マイナンバー」の送信もない(?!?)、

という特徴がある遠隔地からのマイナンバー申請プロセスだ。キーワードは「情報の分割」だ。この業務プロセスを大雑把に説明すると、次の２工程で構成される。

先頭8ケタの送信
末尾4ケタの口頭連絡

注意）「同一の者であることが明らかである」について、行政機関等との間に「見解の相違」が発生するリスクがあります！詳細については、法律施行規則3条(5)、法律施行規則9条(4)を確認してください。（あるいは、タライマワシを覚悟したうえで、行政機関に確認しに行ってください）
◇行政手続における特定の個人を識別するための番号の利用等に関する法律 (2013-05-31)
◇行政手続における特定の個人を識別するための番号の利用等に関する法律施行令 (2014-03-31)
◇行政手続における特定の個人を識別するための番号の利用等に関する法律施行規則 (2014-07-04)
◆特定個人情報保護評価指針 (2014-04-20)
◆特定個人情報の適正な取扱いに関するガイドライン（事業者編） (2014-12-11)

[マイナンバー申請フロー(5)]

「マイナンバー対応！」といわれるシステムやサービスにおいて、「運転免許証をスマホで撮影し添付してください（郵送してください）」といった手順が必要になるケースは多い。当ブログが紹介した『マイナンバー制度をワークフロー化する(4)）』に掲載されている申請プロセスのサンプルでも同様だ。

しかし、「運転免許証の画像ファイル」をアップロード(?!?)、郵送(!!?)。
これを実際にを体験してみると、やはり、、、なんとなく、、、キモチ悪い。

特に、オンライン申請で、社外の方に「運転免許証の画像ファイル」をアップロードさせるとするならば、少なくとも、社内での十分な実証実験を行う必要があるだろう。想定する申請者が「何とも言えない不安」をうったえそうだと予想できるのなら、申請システムの仕様や事前説明内容を抜本的に見直す必要があるかもしれない。（想定申請者のITリテラシ、申請者と会社との関係性、などに依存する）

今回紹介したワークフローが秀逸である点は、なんといっても

『マイナンバー全12ケタの入力』がない
『本人確認のための画像ファイルの添付』がない
『番号照合のための画像ファイルの添付』がない

という点だ。仮に、悪意を持った社員が現れても、簡単には「特定個人情報」を収集することが出来ない。そして、フィッシング対策についても、

当社が『マイナンバーの全12ケタ』を全て入力していただくことはありません
当社が『身分証明のための画像ファイル』を添付していただくことはありません
当社が『番号確認のための画像ファイル』を添付していただくことはありません

と分かりやすい説明を行うことが可能だ。（←これだけで「標的」から外れる可能性が高まる）

具体的なワークフローについては、プロセス図をじっくり見て頂く必要があるが、、、

0. 申請者が、「先頭8桁」をオンライン申請する（番号確認者を指名する）
1. 経理が、番号確認者をシステム上で選択する
2. 番号確認者が、「末尾4桁」を入力する

という複雑な手順を踏む。マイナンバーは「Webフォーム経由」と「既存社員経由」に情報分割のされて提出される。過去に紹介した２つの業務プロセスの長所を融合したような形だ。

現場上司による本人確認：マイナンバー制度をワークフロー化する(3)
本社経理による一元的な受付：マイナンバー制度をワークフロー化する(4)

たしかに、このワークフローの運用で注意したいのは、やはりその複雑さだ。もし「チェックディジット検査」（自動工程）でエラーとなった場合も原因特定は難しく、基本的には全工程をやり直してもらうしかない。

しかし、、、ここでは、

そもそも「正確で正当なマイナンバー」を収集するために、
そして「特定個人情報の漏洩リスク」をゼロにするために、

あえて複雑なワークフローにしているのだ。まずは、その理念を社内共有すれば、受け入れがたい複雑さとまでは言えないだろう。

当初、社員からの申請やアルバイトからの申請がスムーズに流れるようになれば、その後、社外フリーランス・弁護士弁理士・講演依頼先といった方々に申請してもらえるようになる。さらに、日頃からこのワークフローを意識できるようになれば、その頃には多くの社員が「分割申請する意味」や「特定個人情報の大切さ」を説明できるようになっている、、、ような気がする。

＜自動工程でのチェックディジット検査＞

//// == 参照 / Retrieving ==
var first8 = data.get("5"); // 先頭8桁（数字8文字）
var last4 = data.get("9"); // 末尾4桁（数字4文字）

//// == 演算 / Calculating ==
//// == 代入 / Updating ==
var mynumber = first8 + last4;

if( last4 != null && mynumber.length == 12 ){
var mysum = 0;

for( i=0; i<5; i++){
mysum += parseInt( mynumber.charAt(i) ) * (11 - i - 5);
}
for( i=5; i<11; i++){
mysum += parseInt( mynumber.charAt(i) ) * (11 - i + 1);
}
var checkdigitnum = 11 - mysum % 11;
if( checkdigitnum > 9 ){ checkdigitnum = 0; }

var typedcd = parseInt( mynumber.charAt(11) );

if( typedcd == checkdigitnum ){
retVal.put("24", "OK" ); 
} else {
retVal.put("24", "ERROR: 正しい12桁の数字ではありません" ); 
}

} else {
retVal.put("24", "ERROR: 末尾4桁が入力されていません" );
}

retVal.put("31", mynumber);

[マイナンバー申請フロー(5)：「1.末尾4桁の入力者を指名」画面]