データベース管理者でもマイナンバーのデータは見えないようにする

今回の記事では、マイナンバーを扱うITシステムの中で重要な要素となる「データベース」に着目し、どのような対応をすればいいかを考えていきたい。別添の安全管理措置のガイドラインには、「物理的安全管理措置」と「技術的安全管理措置」の2つの項目がある。物理的安全管理措置の中でデータベースに関連しそうなのが「電子媒体等を持ち出す場合の漏洩等の防止」と「個人番号の削除、機器及び電子媒体等の破棄」の2つだ。

漏洩防止に対応するために必要となるデータベース機能には、データの暗号化があるだろう。万一マイナンバーの入っているデータベースファイル入りのハードディスクを盗まれたり、あるいはデータベースサーバーなりが丸ごと盗難にあったりした場合にも、中身のデータが適切に暗号化されていれば漏洩を防止できるだろう。もう1つの個人番号の削除や電子媒体の破棄の際にも、捨てる前に完全にデータを消去するのはもちろん、仮に片鱗が残っていても解読できないよう暗号化しておくに越したことはない。

技術的安全管理措置では、さらにデータベースに関連する項目が挙げられている。それが「アクセス制御」「アクセス者の識別と認証」「外部からの不正アクセス等の防止」「情報漏洩等の防止」という4項目だ。これらは、データベースの外のID認証の仕組みや、ファイアーウォールなどでも対処すべきものだ。しかし、マイナンバーの最後の砦はデータベースの認証やアクセス制御の機能だろう。

日本オラクル データベース事業統括 製品戦略統括本部の下道高志氏は、データの暗号化に関する注意点を次のように指摘する。

下道高志氏（左）、大澤清吾氏（右）

「データを暗号化すればそれでいいのかと言えば、そうではありません。暗号化はたんなるデータの読み替えなので、それがマイナンバーであることには変わりはありません。なので、暗号化したデータも適切なアクセス制御が必要になります。データの暗号化は、安全管理措置技術の1つに過ぎません」

データベースに格納したマイナンバーデータを暗号化さえしてあればそれでOKではなく、暗号化しても厳密なアクセス制御を行う必要がある。そして、適切な権限を持ったアクセスについても詳細なログをきちんと残さなければならないのは同じことなのだ。

既存の人事情報を管理するデータベースのテーブルにマイナンバーのカラムを追加し、それを暗号化すればいいだろうと考えるかもしれない。もちろんこの方法も可能だが、こうしてしまうと本来マイナンバーとは関係ない人事の業務処理の際には、マイナンバーのカラムにはアクセスできないよう制御する必要があるだろう。そんな時、あなたが使っているデータベースにはカラム単位でアクセス制御する機能があるだろうか。

「であれば、既存のテーブルにカラム追加するよりは、テーブルのレベルで分離して管理すべきだと、エンジニアは考えるでしょう。その上で見てはいけない人をどう管理するかと考えたほうが、技術的にも楽なはずです」

この「マイナンバー情報を見てはいけない人」には、人事の業務を行わないデータベースの管理者も入る。そうなると、データベース管理者であってもテーブルのデータが見えないようにする機能が欲しくなる。これはいわゆる職務分掌というやつだ。Oracle DatabaseのようにOracle Database Vaultの機能を使えば、データベース管理者であってもアクセスを制限できるだろう。しかし「管理者だったらデータベースに対してなんでもできるデータベース」の場合は、厳密な運用管理なりで管理者の行動を制限するしかない。

そうなると、やっかいなのがバックアップなどの作業だ。マイナンバーのテーブルのバックアップは、本来ならマイナンバーという特定個人情報を扱う権限を持ったユーザーがやるべき作業だ。そうなると人事部門の担当者がやることに、それは現実的ではない。この場合はデータベース管理者なりが実施するのが普通で、そのためのルールや方法を別途定めておく必要がありそうだ。何らかデータベースにトラブルがあり、データをリカバリーする際も面倒だ。この場合は、リカバリー時だけデータベース管理者に特定個人情報を取り扱う権限を与え、その上で作業を実施する運用などが考えられる。

マイナンバーのデータへのアクセス制御については単純なID管理だけでなく、アプリケーションなどからAPI経由でアクセスするクライアントIDの管理、そしてデータベースの権限管理までやることで「完璧になります」と下道氏は言う。そして「一番のお勧めは、運用管理者の権限を最小化することです」とも。つまりマイナンバーのアクセス制御では最低限のレベルはID管理だが、大手企業などデータ漏洩のリスクが大きい組織では、データベース管理者なりの権限も最小化する必要がありそうだ。