Tweet
Tweet

Slide 1

Slide 1 text

データベースの秘密情報取扱いガイドラインに 関する取り組みとSQL Serverでの実装例につい てのご紹介
 株式会社ZOZOテクノロジーズ
 ECプラットフォーム部 テックリード
 Microsoft MVP for Data Platform
 廣瀬 真輝 Copyright © ZOZO Technologies, Inc.

Slide 2

Slide 2 text

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 ECプラットフォーム部
 テックリード 廣瀬 真輝
 SQL Serverスペシャリストとしてプロダクト横断で
 課題解決に責任を負いつつ、DBに関する仕組みや
 ガイドライン作りに取り組んでいる。2020年8月にMicrosoft MVP for Data Platform 受賞。
 2

Slide 3

Slide 3 text

© ZOZO Technologies, Inc. 3 #dbts2020 本セッションへのフィードバックはtwitterでお願いします


Slide 4

Slide 4 text

© ZOZO Technologies, Inc. 背景
 ● 弊社：3月末から原則リモートワーク ● 社会情勢に応じてリモートワークの機会が増えた会社も 少なくないはず ● DBのSELECT時に秘密情報へのアクセスを制限し、 情報の流出リスクを最小限に抑える必要性が増加 4

Slide 5

Slide 5 text

© ZOZO Technologies, Inc. 目的
 ● 運用中の「DB秘密情報の取扱いガイドライン」をご紹介し 秘密情報保護の取り組みの参考となる内容を提供したい ● 策定したガイドラインをSQL Serverで実装する場合の 具体的な対応内容をご紹介したい 5

Slide 6

Slide 6 text

© ZOZO Technologies, Inc. DB秘密情報の取扱いガイドライン
 6

Slide 7

Slide 7 text

© ZOZO Technologies, Inc. 秘密情報の明確化
 ● 「情報区分表」を作成して保護対象の情報を明確化 ● 機密性のレベルが一定以上の情報を秘密情報とする 7

Slide 8

Slide 8 text

© ZOZO Technologies, Inc. 管理台帳の作成
 ● 弊社では、秘密情報に関連する台帳を2種類作成 ○ 秘密情報管理台帳 ○ 閲覧者管理台帳 8

Slide 9

Slide 9 text

© ZOZO Technologies, Inc. 秘密情報管理台帳
 ● 秘密情報に該当するテーブル、カラムを管理する台帳 ○ 秘密情報が増えるたびに追記 ● 様々なDBに存在する秘密情報を集約するために作成 ● メリット ○ 別DBへのデータ連携時、台帳を確認するだけでマスク対象のカラムを 判断可能 ○ 今後必要なセキュリティ関連の施策やルール変更時に該当箇所の 洗い出しを一からやらなくて済む 9

Slide 10

Slide 10 text

© ZOZO Technologies, Inc. 閲覧者管理台帳
 ● 秘密情報の閲覧可能者を管理する台帳 ○ ここに記名のある人物だけが秘密情報を閲覧できる状態に ● 「誰が」「どのデータストアの秘密情報を閲覧可能なのか」を集約 して管理するためにこの台帳を作成 ● 気軽に記名できるわけではなくルールが存在 ○ 責任者の許可が必要 ○ DBごとに記名できる人数を制限 10

Slide 11

Slide 11 text

© ZOZO Technologies, Inc. 秘密情報取扱いルールを策定するためのフロー
 1. 新しく追加されるデータの取扱い基準の設定 2. 既存データで秘密情報に該当する項目の洗い出し 3. 秘密情報にアクセスできるアカウントの制限 4. 権限のないアカウントからのアクセス制限 5. 権限保持者の大幅な削減による運用負荷増への対処 11

Slide 12

Slide 12 text

© ZOZO Technologies, Inc. １．新しく追加されるデータの取扱い基準の設定
 ● DBに追加されるデータの種類が増える場合、秘密情報に 該当するかを判断する必要性 ● 新たに取得する情報について、以下3点を明確化 ○ 「誰が」 ○ 「どのような基準で判断するか」 ○ 「秘密情報への該当時はどういうアクションが必要か」 12

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© ZOZO Technologies, Inc. ２．既存データで秘密情報に該当する項目の洗い出し
 ● 秘密情報に該当するか未精査のカラムが大量に存在する場合 ○ 全カラムの精査が理想 ○ 現実的でない場合は、効率的な既存データの精査方法を検討 14

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

© ZOZO Technologies, Inc. ３．秘密情報にアクセスできるアカウントの制限 ● DBの秘密情報を閲覧できる人数を限定 ○ 1DBあたり2名など、大きく絞り込むほうが望ましい ○ 閲覧可能者を9割以上削減することも可能 ● 秘密情報が閲覧可能な人にも2種類のアカウントを発行 ○ 秘密情報が閲覧不可能なアカウント（普段使い） ○ 秘密情報が閲覧可能なアカウント（どうしても調査で必要な時） 16

Slide 17

Slide 17 text

© ZOZO Technologies, Inc. 17 ４．権限のないアカウントからのアクセス制限
 ● 権限のない人は秘密情報カラムを閲覧できない状態に ○ 権限のない＝閲覧者管理台帳に記載のない人 ○ 秘密情報カラム＝秘密情報管理台帳に記載のあるカラム ● 秘密情報カラムのアクセス制御をどこまで行えるかは DB製品の機能次第 ○ カラム単位でのアクセス制御が理想

Slide 18

Slide 18 text

© ZOZO Technologies, Inc. 18 ５．権限保持者の大幅な削減による運用負荷増への対処
 ● 単純に秘密情報を閲覧する人数を限定するだけでは エンジニアの調査や運用の負荷が大幅に増加してしまう懸念 ○ オンコール担当者のアラート調査で秘密情報を閲覧したい場合 ○ 権限保持者に調査を依頼することで、権限保持者に負担が集中

Slide 19

Slide 19 text

© ZOZO Technologies, Inc. 19 懸念に対する解決策
 ● 一時的に有効な秘密情報閲覧権限を発行できる仕組みの整備 ○ ワークフロー申請経由など

Slide 20

Slide 20 text

© ZOZO Technologies, Inc. 20 ここまでのまとめ
 ● 秘密情報の取扱いフローを策定 ○ 新しく追加されるデータの取扱い基準の設定 ○ 既存データで秘密情報に該当する項目の洗い出し ○ 秘密情報にアクセスできるアカウントの制限 ○ 権限のないアカウントからのアクセス制限 ○ 権限保持者の大幅な削減による運用負荷増への対処 ● エンジニアの運用負荷をできるだけ上げずに 秘密情報の閲覧可能者をできるだけ限定することが重要

Slide 21

Slide 21 text

© ZOZO Technologies, Inc. 策定したガイドラインの SQL Serverでの実装例
 21 21

Slide 22

Slide 22 text

© ZOZO Technologies, Inc. 22 1. 秘密情報カラムへのアクセスの制限
 ● 以下2点をSQL Serverの機能で実現させる必要性 ○ 秘密情報カラムにアクセスできるアカウントの制限 ○ 秘密情報カラムのマスク化

Slide 23

Slide 23 text

© ZOZO Technologies, Inc. 23 解決策：「動的なデータマスキング」機能
 ● SQL Server 2016から提供 ○ 権限を制限したアカウントが該当のデータにアクセスした場合に 自動的にデータをマスクした状態で返すことができる 上：権限があるアカウントでアクセス / 下：権限がないアカウントでアクセス

Slide 24

Slide 24 text

© ZOZO Technologies, Inc. 24 問題点：SQL Server 2014以下で使用できない
 ● 弊社ではSQL Server 2016以降の環境もあるが、 それより前のバージョンも利用 ○ 全環境で「動的なデータマスキング」を使えない

Slide 25

Slide 25 text

© ZOZO Technologies, Inc. 25 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪（DENY） a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現

Slide 26

Slide 26 text

© ZOZO Technologies, Inc. 26 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪（DENY） a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現

Slide 27

Slide 27 text

© ZOZO Technologies, Inc. 27 1. ロールの活用
 ● 各ログイン/ユーザーへの個別設定ではなく、SQL Serverのユー ザー定義ロールを活用した効率的なアクセス制限 ○ 秘密情報へのアクセスを制限するロールを作成 ○ 作成したロールに対して秘密情報カラムのSELECT権限をはく奪 ○ 作成したロールにログイン/ユーザーを参加させる

Slide 28

Slide 28 text

© ZOZO Technologies, Inc. 28 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪（DENY） a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現

Slide 29

Slide 29 text

© ZOZO Technologies, Inc. 29 a. カラム単位で秘密情報のSELECT権限をはく奪 ● SQL Serverのテーブルのアクセス権:カラム単位で制御可能 ○ DENY SELECT ON OBJECT::テーブル名(列名) TO ユーザー名 ● 権限のはく奪後、アクセス権のないユーザーで該当カラムを取得 するSELECTを実行した際、エラーが発生

Slide 30

Slide 30 text

© ZOZO Technologies, Inc. 30 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 ● VIEWの中ではく奪したカラムをSELECTしている場合 ○ VIEWに対してSELECT権限を持っていると、ベーステーブルで権限が はく奪されていてもSELECTができてしまう ● VIEW経由でもアクセスを制限したい ○ 「SELECTをはく奪したカラムを参照しているVIEW」に対しても 権限をはく奪する必要性

Slide 31

Slide 31 text

© ZOZO Technologies, Inc. 31 VIEW経由でのアクセス制限を実現させるために ● 以下の2つの情報を組み合わせて使用 ○ SELECTをDENYしたカラムのリスト作成 ■ 権限の制御を行うロールに設定されているDENYの情報を取得 ■ sys.database_permissionsを使用 ■ 「どのカラムに対してアクセスが制限されているか」のリストを作成 ○ VIEWが参照しているテーブルのカラムのリスト作成 ■ VIEWが参照しているテーブルとカラムの情報を取得 ■ sql_dependencies/sys.sql_expression_dependencies/sys.dm_sql_referenced_entitiesなどを使用 ■ 「VIEWで参照しているテーブルとカラム」のリストを作成 ● リストを使い「DENYしたカラムを参照するVIEW」を取得 ○ 取得したVIEWに対してDENYを設定し、VIEW経由のアクセス制限を実現

Slide 32

Slide 32 text

© ZOZO Technologies, Inc. 32 ここまでの作業での問題点 ● 気軽な「SELECT * FROM テーブル名」ができない ○ DENYしたカラムを含むテーブルだとエラーになる

Slide 33

Slide 33 text

© ZOZO Technologies, Inc. 33 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪（DENY） a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現

Slide 34

Slide 34 text

© ZOZO Technologies, Inc. 34 動的なデータマスキングを使用しないマスク化 ● 「各テーブルに対応したVIEWを作成し、テーブルに 秘密情報カラムが存在する場合は該当のカラムをマスク」 というアプローチを採用

Slide 35

Slide 35 text

© ZOZO Technologies, Inc. ● Emailカラムだけ秘密情報と仮定してDENY 35 サンプルテーブル

Slide 36

Slide 36 text

© ZOZO Technologies, Inc. 36 テーブルに対応したVIEWの作成

Slide 37

Slide 37 text

© ZOZO Technologies, Inc. 37 VIEWのSELECT結果（以降、「マスク用VIEW」と呼ぶ）

Slide 38

Slide 38 text

© ZOZO Technologies, Inc. ● 全テーブルに作成 ○ 秘密情報カラムが存在しないテーブルでも作成 ● エンジニアのデータ確認時は「マスク用VIEW」を使用 ○ 「各テーブルに秘密情報カラムが存在しているか」を意識することなく クエリを書ける ○ 動的なデータマスキング機能に近い体験をエンジニアへ提供 ● アプリケーションでは使用しない ○ 後述のメンテナンスにより再作成される場合があるため 38 「マスク用VIEW」に関するルール

Slide 39

Slide 39 text

© ZOZO Technologies, Inc. 39 2. 秘密情報のメンテナンス
 ● サービスの成長に伴う秘密情報カラムの増減を考慮すべき ● マスクされたVIEWのメンテナンスを自動で実施 ○ 秘密情報の設定状況が変化した場合、マスク化用VIEWにも変化内容を反映 ○ 単純な実装：定期的な全VIEWの再作成 ○ 今回ご紹介する実装：設定の変更が必要なVIEWのみ再作成 ■ 変更が発生するVIEWを最小限に抑えるため ● 秘密情報カラムの増減に伴うDENY/REVOKEを自動で実施

Slide 40

Slide 40 text

© ZOZO Technologies, Inc. 40 VIEWの再作成が必要となるケース
 ● テーブルの定義変更（カラム追加） ○ 最新の状態をVIEWに反映 ● テーブルの作成/削除 ○ 参照用のVIEWの作成/削除 ● テーブル内の秘密情報カラム（カラムのDENY）の増減 ○ 新しくDENYが設定されたカラムをマスク化 ○ DENYが取り消し（REVOKE）されたカラムを実データ化

Slide 41

Slide 41 text

© ZOZO Technologies, Inc. 41 VIEWの再作成が必要となるケース
 ● テーブルの定義変更（カラム追加） ○ 最新の状態をVIEWに反映 ● テーブルの作成/削除 ○ 参照用のVIEWの作成/削除 ● テーブル内の秘密情報カラム（カラムのDENY）の増減 ○ 新しくDENYが設定されたカラムをマスク化 ○ DENYが取り消し（REVOKE）されたカラムを実データ化

Slide 42

Slide 42 text

© ZOZO Technologies, Inc. 42 テーブルの定義変更
 ● sys.objectsの「modify_date」でテーブルへの変更を検知

Slide 43

Slide 43 text

© ZOZO Technologies, Inc. 43 VIEWの再作成が必要となるケース
 ● テーブルの定義変更（カラム追加） ○ 最新の状態をVIEWに反映 ● テーブルの作成/削除 ○ 参照用のVIEWの作成/削除 ● テーブル内の秘密情報カラム（カラムのDENY）の増減 ○ 新しくDENYが設定されたカラムをマスク化 ○ DENYが取り消し（REVOKE）されたカラムを実データ化

Slide 44

Slide 44 text

© ZOZO Technologies, Inc. 44 テーブルの作成/削除
 ● 新規に作成されたテーブルがあれば、対応するVIEWを作成 ● 既存のテーブルが削除された場合は、対応するVIEWを削除 ● sys.objectsを使用 ○ テーブルは存在するがVIEWは存在しない：VIEW作成 ○ VIEWは存在するがテーブルは存在しない：VIEW削除

Slide 45

Slide 45 text

© ZOZO Technologies, Inc. 45 VIEWの再作成が必要となるケース
 ● テーブルの定義変更（カラム追加） ○ 最新の状態をVIEWに反映 ● テーブルの作成/削除 ○ 参照用のVIEWの作成/削除 ● テーブル内の秘密情報カラム（カラムのDENY）の増減 ○ 新しくDENYが設定されたカラムをマスク化 ○ DENYが取り消し（REVOKE）されたカラムを実データ化

Slide 46

Slide 46 text

© ZOZO Technologies, Inc. 46 実現方法
 ● 2つのリストを作成し、比較してDENY設定の変化を検知 ○ テーブルのカラムに対するDENY設定状況 ○ VIEWのカラムのマスク化の設定状況 ● リスト作成に使用する情報 ○ データベースのオブジェクトに設定している権限 ■ sys.database_permissions ○ VIEWが参照しているテーブルとカラム ■ sql_dependencies ■ sys.sql_expression_dependencies ■ sys.dm_sql_referenced_entities

Slide 47

Slide 47 text

© ZOZO Technologies, Inc. 47 DB上の秘密情報カラムを管理するための仕組みづくり
 ● 秘密情報の管理用テーブルを作成 ○ 秘密情報カラムの追加 ■ アクセス制限に使用しているロールへ自動的にDENY設定 ■ 連動してマスク化用のVIEWでも該当カラムがマスクされる ○ 秘密情報カラムの削除 ■ アクセス制限に使用しているロールへ自動的にREVOKE設定 ■ 連動してマスク化用のVIEWでも該当カラムが実データ化される

Slide 48

Slide 48 text

© ZOZO Technologies, Inc. 48 まとめ
 ● 運用中の「DB秘密情報の取扱いガイドライン」をご紹介 ● 策定したガイドラインをSQL Serverで実装する場合の 具体的な対応内容をご紹介 ● 今回の内容はテックブログとしても公開中 ○ 「ZOZOテクノロジーズ テックブログ」で検索 ○ https://techblog.zozo.com/entry/confidential-information-guidelines ○ https://techblog.zozo.com/entry/sensitive-data-sqlserver-implementation

Slide 49

Slide 49 text

No content