Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データベースの秘密情報取扱いガイドラインに関する取り組みとSQL Serverでの実装例についてのご紹介 / confidential-information-guidelines-and-sqlserver-implementation

p2sk
November 26, 2020

データベースの秘密情報取扱いガイドラインに関する取り組みとSQL Serverでの実装例についてのご紹介 / confidential-information-guidelines-and-sqlserver-implementation

p2sk

November 26, 2020
Tweet

More Decks by p2sk

Other Decks in Programming

Transcript

  1. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 ECプラットフォーム部
 テックリード 廣瀬 真輝
 SQL

    Serverスペシャリストとしてプロダクト横断で
 課題解決に責任を負いつつ、DBに関する仕組みや
 ガイドライン作りに取り組んでいる。2020年8月にMicrosoft MVP for Data Platform 受賞。
 2
  2. © ZOZO Technologies, Inc. 背景
 • 弊社:3月末から原則リモートワーク • 社会情勢に応じてリモートワークの機会が増えた会社も 少なくないはず

    • DBのSELECT時に秘密情報へのアクセスを制限し、 情報の流出リスクを最小限に抑える必要性が増加 4
  3. © ZOZO Technologies, Inc. 秘密情報管理台帳
 • 秘密情報に該当するテーブル、カラムを管理する台帳 ◦ 秘密情報が増えるたびに追記 •

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

    「誰が」「どのデータストアの秘密情報を閲覧可能なのか」を集約 して管理するためにこの台帳を作成 • 気軽に記名できるわけではなくルールが存在 ◦ 責任者の許可が必要 ◦ DBごとに記名できる人数を制限 10
  5. © ZOZO Technologies, Inc. 秘密情報取扱いルールを策定するためのフロー
 1. 新しく追加されるデータの取扱い基準の設定 2. 既存データで秘密情報に該当する項目の洗い出し 3.

    秘密情報にアクセスできるアカウントの制限 4. 権限のないアカウントからのアクセス制限 5. 権限保持者の大幅な削減による運用負荷増への対処 11
  6. © ZOZO Technologies, Inc. データの取り扱い基準の明確化
 • 「誰が」 ◦ プロダクトまたはDBごとにアサインしたレビュー担当者 •

    「どのような基準で判断するか」 ◦ 社内の情報区分における機密性が一定以上の情報 • 「秘密情報への該当時はどういうアクションが必要か」 ◦ 秘密情報管理台帳に記載 ◦ 秘密情報を閲覧可能となる人物が追加になる場合は閲覧者管理台帳に記載 ◦ 秘密情報をマスク化し、アクセスできるアカウントを制限 ◦ 情報の管理を行っている部署に報告 13
  7. © ZOZO Technologies, Inc. 効率的な既存データの精査方法
 1. 文字列型のカラムは氏名や住所など、秘密情報が入っている可能性が高い a. 全ての文字列カラムの実データをカラムごとに上位100件ほどを目視で確認 b.

    秘密情報が入っていそうなカラムリストを作成 2. 「address」など、秘密情報に該当する可能性が高いカラム名で 各DBのメタデータを検索し、秘密情報が入っていそうなカラムリストを作成 3. 作成した「秘密情報が入っていそうなカラムリスト」を人力で精査 4. 最後に責任者のチェックを通して、最終的な秘密情報カラムリストを作成 5. 秘密情報管理台帳に記載 15
  8. © ZOZO Technologies, Inc. 3.秘密情報にアクセスできるアカウントの制限 • DBの秘密情報を閲覧できる人数を限定 ◦ 1DBあたり2名など、大きく絞り込むほうが望ましい ◦

    閲覧可能者を9割以上削減することも可能 • 秘密情報が閲覧可能な人にも2種類のアカウントを発行 ◦ 秘密情報が閲覧不可能なアカウント(普段使い) ◦ 秘密情報が閲覧可能なアカウント(どうしても調査で必要な時) 16
  9. © ZOZO Technologies, Inc. 17 4.権限のないアカウントからのアクセス制限
 • 権限のない人は秘密情報カラムを閲覧できない状態に ◦ 権限のない=閲覧者管理台帳に記載のない人

    ◦ 秘密情報カラム=秘密情報管理台帳に記載のあるカラム • 秘密情報カラムのアクセス制御をどこまで行えるかは DB製品の機能次第 ◦ カラム単位でのアクセス制御が理想
  10. © ZOZO Technologies, Inc. 20 ここまでのまとめ
 • 秘密情報の取扱いフローを策定 ◦ 新しく追加されるデータの取扱い基準の設定

    ◦ 既存データで秘密情報に該当する項目の洗い出し ◦ 秘密情報にアクセスできるアカウントの制限 ◦ 権限のないアカウントからのアクセス制限 ◦ 権限保持者の大幅な削減による運用負荷増への対処 • エンジニアの運用負荷をできるだけ上げずに 秘密情報の閲覧可能者をできるだけ限定することが重要
  11. © ZOZO Technologies, Inc. 22 1. 秘密情報カラムへのアクセスの制限
 • 以下2点をSQL Serverの機能で実現させる必要性

    ◦ 秘密情報カラムにアクセスできるアカウントの制限 ◦ 秘密情報カラムのマスク化
  12. © ZOZO Technologies, Inc. 23 解決策:「動的なデータマスキング」機能
 • SQL Server 2016から提供

    ◦ 権限を制限したアカウントが該当のデータにアクセスした場合に 自動的にデータをマスクした状態で返すことができる 上:権限があるアカウントでアクセス / 下:権限がないアカウントでアクセス
  13. © ZOZO Technologies, Inc. 24 問題点:SQL Server 2014以下で使用できない
 • 弊社ではSQL

    Server 2016以降の環境もあるが、 それより前のバージョンも利用 ◦ 全環境で「動的なデータマスキング」を使えない
  14. © ZOZO Technologies, Inc. 25 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪(DENY)

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

    a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現
  16. © ZOZO Technologies, Inc. 27 1. ロールの活用
 • 各ログイン/ユーザーへの個別設定ではなく、SQL Serverのユー

    ザー定義ロールを活用した効率的なアクセス制限 ◦ 秘密情報へのアクセスを制限するロールを作成 ◦ 作成したロールに対して秘密情報カラムのSELECT権限をはく奪 ◦ 作成したロールにログイン/ユーザーを参加させる
  17. © ZOZO Technologies, Inc. 28 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪(DENY)

    a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現
  18. © ZOZO Technologies, Inc. 29 a. カラム単位で秘密情報のSELECT権限をはく奪 • SQL Serverのテーブルのアクセス権:カラム単位で制御可能

    ◦ DENY SELECT ON OBJECT::テーブル名(列名) TO ユーザー名 • 権限のはく奪後、アクセス権のないユーザーで該当カラムを取得 するSELECTを実行した際、エラーが発生
  19. © ZOZO Technologies, Inc. 30 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 • VIEWの中ではく奪したカラムをSELECTしている場合 ◦

    VIEWに対してSELECT権限を持っていると、ベーステーブルで権限が はく奪されていてもSELECTができてしまう • VIEW経由でもアクセスを制限したい ◦ 「SELECTをはく奪したカラムを参照しているVIEW」に対しても 権限をはく奪する必要性
  20. © 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経由のアクセス制限を実現
  21. © ZOZO Technologies, Inc. 32 ここまでの作業での問題点 • 気軽な「SELECT * FROM

    テーブル名」ができない ◦ DENYしたカラムを含むテーブルだとエラーになる
  22. © ZOZO Technologies, Inc. 33 動的なデータマスキングの代替案
 1. ロールの活用 2. 秘密情報カラムに対するSELECT権限のはく奪(DENY)

    a. カラム単位で秘密情報のSELECT権限をはく奪 b. 秘密情報をSELECTしているVIEWの参照権限をはく奪 3. 動的なデータマスキングを使用しないマスク化の実現
  23. © ZOZO Technologies, Inc. • 全テーブルに作成 ◦ 秘密情報カラムが存在しないテーブルでも作成 • エンジニアのデータ確認時は「マスク用VIEW」を使用

    ◦ 「各テーブルに秘密情報カラムが存在しているか」を意識することなく クエリを書ける ◦ 動的なデータマスキング機能に近い体験をエンジニアへ提供 • アプリケーションでは使用しない ◦ 後述のメンテナンスにより再作成される場合があるため 38 「マスク用VIEW」に関するルール
  24. © ZOZO Technologies, Inc. 39 2. 秘密情報のメンテナンス
 • サービスの成長に伴う秘密情報カラムの増減を考慮すべき •

    マスクされたVIEWのメンテナンスを自動で実施 ◦ 秘密情報の設定状況が変化した場合、マスク化用VIEWにも変化内容を反映 ◦ 単純な実装:定期的な全VIEWの再作成 ◦ 今回ご紹介する実装:設定の変更が必要なVIEWのみ再作成 ▪ 変更が発生するVIEWを最小限に抑えるため • 秘密情報カラムの増減に伴うDENY/REVOKEを自動で実施
  25. © ZOZO Technologies, Inc. 40 VIEWの再作成が必要となるケース
 • テーブルの定義変更(カラム追加) ◦ 最新の状態をVIEWに反映

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

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

    • テーブルの作成/削除 ◦ 参照用のVIEWの作成/削除 • テーブル内の秘密情報カラム(カラムのDENY)の増減 ◦ 新しくDENYが設定されたカラムをマスク化 ◦ DENYが取り消し(REVOKE)されたカラムを実データ化
  28. © ZOZO Technologies, Inc. 44 テーブルの作成/削除
 • 新規に作成されたテーブルがあれば、対応するVIEWを作成 • 既存のテーブルが削除された場合は、対応するVIEWを削除

    • sys.objectsを使用 ◦ テーブルは存在するがVIEWは存在しない:VIEW作成 ◦ VIEWは存在するがテーブルは存在しない:VIEW削除
  29. © ZOZO Technologies, Inc. 45 VIEWの再作成が必要となるケース
 • テーブルの定義変更(カラム追加) ◦ 最新の状態をVIEWに反映

    • テーブルの作成/削除 ◦ 参照用のVIEWの作成/削除 • テーブル内の秘密情報カラム(カラムのDENY)の増減 ◦ 新しくDENYが設定されたカラムをマスク化 ◦ DENYが取り消し(REVOKE)されたカラムを実データ化
  30. © ZOZO Technologies, Inc. 46 実現方法
 • 2つのリストを作成し、比較してDENY設定の変化を検知 ◦ テーブルのカラムに対するDENY設定状況

    ◦ VIEWのカラムのマスク化の設定状況 • リスト作成に使用する情報 ◦ データベースのオブジェクトに設定している権限 ▪ sys.database_permissions ◦ VIEWが参照しているテーブルとカラム ▪ sql_dependencies ▪ sys.sql_expression_dependencies ▪ sys.dm_sql_referenced_entities
  31. © ZOZO Technologies, Inc. 47 DB上の秘密情報カラムを管理するための仕組みづくり
 • 秘密情報の管理用テーブルを作成 ◦ 秘密情報カラムの追加

    ▪ アクセス制限に使用しているロールへ自動的にDENY設定 ▪ 連動してマスク化用のVIEWでも該当カラムがマスクされる ◦ 秘密情報カラムの削除 ▪ アクセス制限に使用しているロールへ自動的にREVOKE設定 ▪ 連動してマスク化用のVIEWでも該当カラムが実データ化される
  32. © 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