こんにちは。ECプラットフォーム部の廣瀬です。

ZOZOテクノロジーズでは、お客様の氏名や住所をはじめとする秘密情報を保護するための様々な取り組みを行っています。本記事ではその中の一部である、データベース（以下、DB）に保存している秘密情報の取扱いルールについてご紹介したいと思います。なお、今回の内容は特定の製品の機能に関する話ではなく、取り組みの基本的な考え方についての話となっています。

背景

何も対策を講じない場合、開発者がDBの秘密情報を権限的には閲覧することが可能な状態となり得ます。例えば、

select * from [秘密情報が含まれるテーブル]

といったSQLを実行することで、秘密情報を閲覧できてしまいます。

意図的に機密性の高い情報にアクセスするようなエンジニアは基本的にはいないでしょう。ただし、秘密情報を利用する意図がなくても、新機能のリリース時のデータ確認などで自然と秘密情報が目についてしまう可能性はあります。例えば、単一テーブルのデータを参照する際に「select *」で情報の確認を行った場合などです。

弊社では、以前からフルリモートワーク制度を導入していました。また、3月末からは原則としてリモートワーク推奨となっております。弊社だけでなく、社会情勢に応じてリモートワークの機会が増えた会社は少なくないと思います。このような状況下においてリモートワークでDBの情報を参照した際に、秘密情報へのアクセスを制限し、情報の流出リスクを最小限に抑える必要性が高まっていると感じています。

そこで、弊社で運用しているDB秘密情報の取扱いルールをご紹介することで、秘密情報保護の取り組みの参考となる内容をご提供できればと考えました。まずは、「どのような情報を秘密情報とするか」についてご説明したいと思います。

秘密情報の明確化

弊社では、保護対象の情報を明確化するために「情報区分表」を作成しています。これは、機密性のレベルを数段階用意し、各レベルにどういった情報が対応するのかを定義した表です。

以下に、情報区分のイメージを示します。

秘密情報への該当	情報区分	考え方	例
〇	機密性最高	最も保護すべき機密性の高いデータ	...
〇	機密性高	...	...
...	...	...	...
×	機密性低	一般的に広く認知されているデータ	都道府県のマスタデータ

この情報区分表において、機密性のレベルが一定以上の重要度が高い項目に該当している情報を秘密情報としています。

次に、秘密情報に関連するデータの管理方法についてご紹介します。

管理台帳の作成

弊社では、秘密情報に関連する台帳を2種類作成しています。

1. 秘密情報管理台帳

秘密情報に該当するテーブル、カラムを管理する台帳です。プロダクトやDB単位で作成し、秘密情報が増えるたびに追記していきます。弊社で使用している様々なデータストアに存在する秘密情報を集約するためにこの台帳を作成しています。この台帳があることで、例えば以下のようなメリットがあります。

別のDBにテーブルのデータを連携する際、台帳を確認するだけでマスク対象のカラムを判断できる
センシティブな情報を可視化することで、今後必要なセキュリティ関連の施策やルール変更時に該当箇所の洗い出しを一からやらなくて済む

2. 閲覧者管理台帳

秘密情報の閲覧可能者を管理する台帳です。ここに記名のある人物だけが秘密情報を閲覧できる状態となっています。また、気軽に記名できるわけではありません。責任者の許可が必要である点や、DBごとに記名できる人数を制限している点など、記名のためのルールを整備しています。「誰が」「どのデータストアの秘密情報を閲覧可能なのか」を集約して管理するためにこの台帳を作成しています。

ここまでで、「どういった情報が秘密情報に該当するのか」や、「秘密情報やその情報を閲覧可能な人物をどう管理するのか」についてご紹介しました。続いて、秘密情報の取扱いルールを策定するために整備したフローをご紹介します。

秘密情報取扱いルールを策定するためのフロー

弊社で秘密情報の取扱いルールを策定した際には、次のようなフローの整備を行いました。

新しく追加されるデータの取扱い
既存データで秘密情報に該当する項目の洗い出し
秘密情報にアクセスできるアカウントの制限
権限のないアカウントからのアクセス制限
権限保持者の大幅な削減による運用負荷増への対処

以降、順を追って説明します。

1. 新しく追加されるデータの取扱い

「現時点で保持している情報」だけでなく「今後新しく取得される情報」の取扱い方法についても検討が必要となります。例えば、機能の改修や追加に伴ってDBに追加されるデータの種類が増える場合、そのデータが秘密情報に該当するかを判断する必要があります。そこで、新たに取得する情報について、「誰が」「どのような基準で判断し」「秘密情報に該当すると判断した場合はどういったアクションが必要なのか」を明確にしています。

「誰が」
- プロダクトまたはDBごとにアサインしたレビュー担当者
「どのような基準で判断し」
- 社内の情報区分における機密性が一定以上の情報
「秘密情報に該当すると判断した場合はどういったアクションが必要なのか」
- 秘密情報管理台帳に記載
- その秘密情報を閲覧可能となる人物が追加になる場合は閲覧者管理台帳に記載
- 秘密情報をマスク化し、アクセスできるアカウントを制限
- 情報の管理を行っている部署に報告

2. 既存データで秘密情報に該当する項目の洗い出し

弊社では、以前より情報区分が整理されており、どのような情報が秘密情報の対象となるかが明文化されていました。また、どのカラムが秘密情報に該当するかの精査も行われている状態でした。既存のシステムでこうした取り組みが行われていない状況下では、秘密情報に該当するか精査されていないカラムが大量に存在することになると思います。全カラムの精査が現実的でない場合は、効率的な既存データの精査方法として、以下のような手順が考えられます。

文字列型のカラムは氏名や住所など、秘密情報が入っている可能性が高いため、全ての文字列カラムの実データをカラムごとに上位100件ほどを目視で確認し、秘密情報が入っていそうなカラムリストを作成
「address」など、秘密情報に該当する可能性が高いカラム名で各DBのメタデータを検索し、秘密情報が入っていそうなカラムリストを作成
作成した「秘密情報が入っていそうなカラムリスト」を人力で精査
最後に責任者のチェックを通して、最終的な秘密情報カラムリストを作成
秘密情報管理台帳に記載

3. 秘密情報にアクセスできるアカウントの制限

DBの秘密情報を閲覧できる人数を限定します。例えば1DBあたり2名など、大きく絞り込むほうが望ましいです。何も対策を実施していない状況から人数の絞り込みを行えば、秘密情報の閲覧可能者を9割以上削減することも可能かと思います。

また、弊社では秘密情報が閲覧可能な人に対しても、秘密情報が「閲覧不可能なログインアカウント」と「閲覧可能なログインアカウント」の2種類を発行しています。これにより、普段は秘密情報を閲覧できないログインアカウントを使ってもらい、どうしても調査に必要な時だけ別のログインアカウントを使って秘密情報を使った調査を実施できるようにしています。