シンジです。いつだったか知人から、「入社初日にデータ抜かれて翌日から連絡が取れなくなった人がいて」といった話を聞きました。調べてみると名前も住所もでたらめで、まさにデータをぶっこ抜くためだけに面接を通過してきたという興味深い話でした。結局そこで深刻なデータ侵害はなかったようですが、この話を聞いてから今シンジだったら何ができるか考えて社内に実装した話です。
面接はZoomで、会うこともない
どこから接続しているかも分からないし、それを知ったところで本当にそうなのか確認することも難しい。そもそも会ったところで、履歴書や本人が申告する名前と住所が本当に本人のものかを確認することもしていません。もし自分が面接を受けたときに、身分証明してくださいって言われてもなんか気持ち悪いし、もちろんそれが必要な業界や業種があるわけですが、当社のようなただのITベンチャーが、何が身分証明だせだばかやろうとか思うわけです。そして我々には、その身分証明が本物かどうかを見分ける力すらありません。
そこでeKYCを使えばいいと思い付く
本人確認の手続きのことを「KYC」と言います。Know Your Customerの略です。この本人確認手続きを丸ごとデジタル化したものが「eKYC」です。eはelectronicです。
もともとeKYCは2018年11月に改正された犯収法(犯罪収益移転防止法)によってデジタルでもOKとなったことで広く使われるきっかけになりました。これは主に金融機関等を規制する法律として、本人確認の要件を具体的に定義しています。個人だけでなく法人の確認にも使われるようです。
シンジ自身もスマホ1つだけで銀行口座を開設したり、クレジットカード発行したりしたときに、デジタルな本人確認手続き、つまりeKYCを体感していたので、これなら利用者の負担も少なくなかなかおしゃれにいけるのではと思い付きましたがハードルが沢山ありました。
eKYCを扱う業者の選定というかむしろお願い
自分たちでeKYCのアプリを作ろうと思えばできるとは思います。ただ前述の要件を確実に守らなければならなかったり、運用面での専門性を考えると、やはりここは既にあるサービスを利用する方が得策だろうなと思うわけです。餅は餅屋です。
で、eKYCのサービスを提供する業者さんは結構な数いるんですが、根本的な問題として「月にたった数人いるかどうかの入社前人材に対するeKYCサービス」を行うところがありませんでした。こんな使い方で申し訳ないのですが、、、という感じで9社くらいに連絡入れた気がしますが、返事が来たのは3社、用途を理解してなんとかやらせてもらえたのが1社といった感じでした。
その業者さんがTRUSTDOCKさんでした。というわけで選択肢がなくなりましたので、TRUSTDOCKさんには頭が上がらない感じですいませんすいませんと話しを進めていくことになります。
利用頻度と料金設定
頻度は先程も書いた通りですが、もともとeKYCのサービスがtoCな数多くの人たちの本人確認手続きを想定していますので、料金体系もそれに合わせたプランニングがされているわけですが、当社の用途では全く合いません。んでまぁなんやかんやありまして、すごい安い値段で使いやすいプランを設定して頂けたので、なんかほんとすいませんありがとうございますって感じです。具体的な値段は書きませんが、情シスでなくても人事担当者でも、「あーその値段ならありだな」って言ってもらえるような設定にしていただけました。
eKYCのシステムは作り込みが必要なので、そこをサポートしてくれることも含めた初期費用と、毎月の基本料金と、本人確認1件あたりいくらみたいな感じです。
シームレスな入社手続きになるような設計
本人確認のプロセスを増やすだけだと利用者もこちらも手間なので、入社前から入社日までのプロセスを自動化しつつ本人確認を加えました。
内定フラグが人事システムで発行されると、人事担当者は対象者への本人確認を含む入社フローを発行するために、Slackで「/ekyc」コマンドを発行します。ここはあえて手動にしました。このコマンドを発行すると、対象者の雇用形態などいくつかの選択肢から項目を選択します。このデータはAWS Lamdbaを通してAWS Systems Managerに一時的に保管されます。この時一意のUUIDが発行され、これが内定者と紐付くIDとして利用されます。
内定者に対しては、入社手続きを行うための専用URLをUUIDを用いて発行し、メールで連絡します。この時利用するメールアドレスは、内定前までに人事システムに入力される個人がもつメールアドレスです。
内定者はメールに記載されたURLへアクセスすると、氏名や住所、希望するデバイス（WinかMacかなど）の情報を入力します。この情報を送信すると、またこれがAWS Sytem Managerに一時的に保管されるのと同時に、TRUSTDOCKのAPIを通じて身分確認の開始通知を送信します。帰ってきたIDと内定者データを紐付けて、比較対象のデータをTRUSTDOCKに送信します。この時、ALMリスク確認といって反社DBとのマッチング検索も行い、この結果は即返されます。ここまでの処理は1秒未満で、内定者にはスマホで読み取るQRコードが表示されます。
スマホアプリによる本人確認開始
TRUSTDOCKは自身で作成したアプリにeKYCを埋め込むこともできますが、TRUSTDOCKが提供するアプリによっても同じ事が可能なので、これを使うことでアプリ制作をまるっとスキップできます。
ちなみにTRUSTDOCKは、スマホがなくてもPCやMacだけでも同じ事ができます。今回はスマホ利用前提にしてます。
利用させたい身分証明書は提供者がいくつか選択できます。どんな要件に合致させたいのかによって、このあたりは変更可能です。
この本人確認は全てデジタルで行われるわけではなく、TRUSTDOCK側で有人による目視確認も含まれます。確認開始から確認完了までの時間は大凡1日だそうですが、体感ではもっと早かったです。
最終の入社確認プロセス
TRUSTDOCKによる本人確認手続きが完了すると、Webhookが発行され、それを受け取ると同時に社内のWorkatoに入社手続き開始フラグを渡すと同時にjson形式でBoxにデータを保管します。この時、AWS Sytem Managerに保管していた個人データを削除します。
Workatoは人事担当者にSlackで連絡を入れ、入社するか入社しないかの選択をします。入社しないを選択すると、これまで収拾した応募者の全てのデータが削除されます。入社するを選択すると、入社予定日をSlackが聞いてきます。
あとはWorkatoが入社日までの時間を判断して、SmartHRには雇用者のデータが自動入力され、DocuSignによる雇用契約書の締結と秘密情報保持契約の締結が発行されます。この時点で入社当日に各種ライセンスの契約数が足りているかどうかも計算され、その結果が情シス担当者に通知されます。Workatoが入社日当日になると、全てのアカウントプロビジョニングを指示します。というかここはWorkatoが指示してOktaがやります。
というわけで4月からこれで運用してます
ところでこれって個人データを扱ってる分けなので、おまけにこれらをセキュリティ評価した結果も見てみましょう。（当社の情報セキュリティ責任者である三上さんがやってくれましたので抜粋します）
自社管理下インフラ（AWS・Slack・Box・Workato）
根本的な設計として要配慮個人情報を取得する構成になっておらず、保護対象の個人データは、ユーザーが入力した氏名等の基本的な個人情報のみになります。
フロー内のデータの保存期間については、正常に処理が完了した場合も、途中での内定者側処理のスタックが行われた場合のいずれであっても、データがフロー内に保持され続けることはなく、内定からeKYCによる本人確認の完了までに、180日間を経過したタイミングで、個人情報が自動的に破棄されます。180日間という日数はeKYCの照合完了から入社までの間が最長半年間開くことを見込んで設定しています。
自社のBoxに保存されるjsonファイルについても同様に、180日間経過後に廃棄されるとともに、保持期間中もアクセス権の設定により、社内の権限外のユーザーが閲覧できないように設計されています。
同様に、jsonファイルをSlack上から直接参照可能な、/eKYC list コマンド実行時についても、コマンドの実行可能な社内担当者をホワイトリストとして定義することで、権限外の閲覧を防止しています。
jsonファイルを格納するBoxフォルダに対するアクセス権の変更・および従業員のフォルダへの直接のアクセスについても、Webhookを利用したSlackへの通知を計画しており、こちらも検知可能となります。
このため、残存する個人情報の漏洩可能性のあるプロセスは、入社予定日入力時の内定者に対するメール通知ですが、通知文面に個人情報を含めないことで、内定者がメールアドレスを誤って入力していたとしても、個人情報の漏洩は発生しません。
フロー内での個人情報の削除の証跡を残し、これを監査可能するため、個人情報の削除のログについては、Slackの特定チャンネル及び、SIEMに記録され、検証可能となるように設計しています。
TRUSTDOCK側
Trustdock側のポリシーにより、契約終了後90日以内で個人情報は削除されます。また、当社側から任意の個人情報を削除可能です。
評価項目とその詳細
当該eKYCフローで取得する個人情報および個人情報になりうる情報について
フォームに対する、以下の内定者入力項目および、Trustdockのスマホアプリによる、端末カメラを利用した画像（個人識別符号）を取得。
フォームで内定者が入力する情報
- 就業時の希望アカウント名
- 姓名（日本語および英語表記）
- 個人メールアドレス
- 生年月日
- 性別
- 住所
- 電話番号
当該フローで取得する個人情報に要配慮個人情報が含まれるか否か
含まれません。内定者が入力するフォームについては要配慮個人情報に該当する情報の記入項目がありません。TRUSTDOCKによる反社チェック(リスク確認)によって取得する情報は、APIを利用した照合に対して、ヒットしたかしないかの結果のみが通知されるため、犯罪歴などの要配慮個人情報は取得しません。
適切なデータ廃棄のための対策
当該フロー内の自社管理下インフラ
全般的な対策として、内定者が入力した個人データについての保持期間は、フロー内で180日間で設定されており、期間経過後に自動消去されます。そのため、フローの処理が内定者の途中離脱や、人事担当者の処理漏れなどで中断した場合も、180日間で個人データ自体が削除されます。
なお、Workatoが参照するBoxフォルダ内のjsonファイルについても180日経過後に削除されます。また、これらとは別に、入社しないことがわかったタイミングでSlack側から人事担当者が操作することによって個人データの削除が行われます。
TRUSTDOCK側
Trustdock側に受け渡す個人識別符号については、Trustdock側で管理され、以下のポリシーに基づき消去されます。（TRUSTDOCKセキュリティホワイトペーパー_v2_3.pdf より参照）
- お客様が任意のタイミングで任意のデータ1件ごとにデータ削除APIを実施することで、該当の個人情報はDBおよびストレージから消去されます。
- TRUSTDOCKへの本人確認依頼の証跡、本人確認業務の実施の証跡およびテナントに関する情報は、個人情報を含まない状態で契約終了後も保管し続けます。
- DBのバックアップは日次で取得し、AWS上にて7世代まで保管し、それ以前のバックアップデータは消去します。
- アプリケーションのログは現時点では期限なく保管しています。今後、1年間の保管に変更の可能性があります。
- TRUSTDOCK利用に関する契約が終了した場合、上記を除くお客様からお預かりした個人情報を含む全てのデータは契約の終了から3ヶ月以内にDBおよびストレージから消去します。
漏洩可能性のあるプロセスと対策
AWS・TRUSTDOCK・Workatoに対するインフラそのものへの不正アクセスを除いた場合、情報漏洩の可能性のあるプロセスと対策は以下の通りです。
AWS S3に対しての不正アクセス
ステップ1で事前にUUIDを発行し、それと組み合わせたURLを内定者のアクセスURLとして使用します。それ以外のURLへのアクセスは401エラーを返すほか、アクセスURL自体が24時間で失効するように設計し、漏洩を防止します。
Boxに保存されたJsonファイルへの権限のない従業員のアクセス
Boxのフォルダに対して、Workatoからのアクセスに必要な範囲および、内定者の辞退などの入社の取りやめに際してのデータの削除の確認を行うために必要な範囲に限り、当該フォルダに対してのアクセス権を付与することで、権限外の個人情報へのアクセスを防止します。
入社予定日入力後に入社予定者に送信される通知メール
入社予定者自身がメールアドレスを誤入力していた場合に誤送信が起こり得ます。しかし、送信メールの文中に含まれる個人情報をなくすなど、送付される文面を工夫することで、個人情報の漏洩を防止します。
Boxに保存されたJsonファイルに対する権限のない従業員の参照コマンド”eKYC list”の実行
eKYC listコマンドをSlack上から実行可能なユーザーを指定することで、権限外のユーザーのコマンド実行を禁止し、権限外のユーザーの格納個人情報の参照を防止します。
フロー内の個人データの廃棄処理および参照に対する監査体制
ログの取得やレポート機能などによる証跡の取得および通知を実行し監査可能とします。監査タイミングや内容は以下の通りです。
- 内定者による個人情報の入力の完了
- AWS Systems Managerからの個人データの削除
- 人事担当者による入社処理の取り消しによるjsonファイルの削除
- 内定者のデータ入力から180日経過後の個人データの自動削除
jsonファイルを格納したBoxフォルダについての以下の情報
- 日時
- アクセスしたユーザー
- 共有権限の変更があった場合はその内容
- その他ワークフローの作成など、ファイルの意図しない移動などが発生する可能性のある操作など
eKYC listコマンドの実行
- 日時
- 実行したユーザー
eKYC listコマンドの実行権限者の変更
- 日時
- 変更内容
結局作り込みは必要なので
開発者が全くいない場合だと実装は難しいと思います。そして作り込みの方法によっては、個人データが脆弱な扱いをされる場合もあるでしょう。
でもまぁよく考えてみれば、そもそもeKYCうんぬんの前に、入社前の人事情報、まともに管理できてるって言えますか？この本人確認を切り口に、整備し直すのもありかもしれませんね。