クラウドエンジニアブログ

データガバナンス ~実践編~

human05

古林

みなさまこんにちは。クラウドアーキテクトの卵です。

本ブログも、リモートワーク環境で書いています。あれからまたちょっと模様替えしました。
スマホ置き場やヘッドセット置き場を設けたり、配線周りをもう少しスッキリさせたり、アロマコーナーを作ってみたり、お気に入りのフィギュアを飾ってみたり…。より機能的、かつ、より気分が上がる環境が整ってきました。
ちなみに、現在においても、一番の課題 (部屋がスッキリした状態を維持することができるか) は顕在化しておりません (強調) 。


<目次>
  1. はじめに
  2. データ分析基盤としてのデータガバナンス
  3. データ分析基盤としてのセキュリティ
  4. おわりに



1. はじめに

今回は、前回のブログの続きとなります。
今回は実践編として「データガバナンス」の実現方法をまとめました。

前回のブログでは、データガバナンスとは、平たく言ってしまうと「データの運用ルール」のことであり、データ利活用にはデータガバナンスが必要不可欠、という内容をまとめました。
その中で、データ利活用に必要なもの・役割について、以下のように記載しています。

データの利活用に必要なもの・役割は、最低でもこれだけ必要と言われています。
(実際には、もう少し細分化されることもあります。また、会社によって名称が異なることもあります。特に「役割」の部分。)


<データの利活用に必要なもの・役割>
1.	はじめに1


本ブログでは、「Azure 上のデータ分析基盤環境において、実際にどのようにすればデータガバナンスが保たれるか」に焦点を当てています。そのため、プラットフォーム側で実現できるデータガバナンスの方法について記載します。


<データガバナンスの実現方法 (本ブログの範囲) >
1.	はじめに2



2. データ分析基盤としてのデータガバナンス

前回のブログの『3. データガバナンスの必要性』の部分で、以下のように記載しました。

お客様からの問い合わせや、データ系のセミナー / ウェビナーでよく紹介される事例 (お困りごと) は、「データの内容」と「データのセキュリティ」の大きく 2 つに分けられることが多いように感じます。

  • データの内容
    • データが多すぎて、必要なデータがどこにあるのかが分からない。
    • 各システムの更新頻度が異なるため、それぞれのデータがいつの断面の情報かが分からない。
    • データソースの仕様が変わったため、データの意味が分からなくなった。

本ブログの「1. はじめに」に記載した内容が含まれています。
上記の問題を解決するには「データの品質を保つルール」が必要となります。

  • データのセキュリティ
    • データを集めたら、機密データが全社員に公開されてしまった。
    • データをマスキングしなかったら、情報流出だと怒られた。
    • 逆に、データをマスキングした場合、業務で使えないと怒られた。

2 番目と 3 番目の内容は、一見背反しているように見えますね。
(データの管理者は辛いところだと思います。。。)
「誰が、どのデータを取り扱って良いか (もしくは、閲覧不可なのか) 」という権限管理が、データにおいても必要と言えるでしょう。
上記の問題を解決するには、「データのセキュリティを保つルール」が必要となります。


ここでは「データの品質を保つルール」について、Azure だとどのような施策が取れるかを考えてみます。
(「データのセキュリティを保つルール」については、次章に記載します。)

データの品質を保つには、誰かが適切に管理しておく必要があります。
しかし、ただ管理しているだけだと、データ利活用を促進するという最終目標に達するには少し弱いです。「このようなデータがここにあり、使える状態である」ということを、データサイエンティストをはじめとするデータ利用者が知らないと、データ利活用がままならなくなります。
(データの存在を知らない、ということは「あるある」です。「そのデータ、ウチの部署独自で持ってますよ」「えっ!?」という話も往々にして聞きます。)

上記より、データガバナンスを保つには、データの適切、かつ、利用可能な状態の管理が必要であると言えそうです。
データの適切な管理、データの利用可能な状態の管理について、Azure で実現可能な施策を調査しました。



  • データの適切な管理
  • Azure Data Lake Storage Gen2
    まずは、データの置き場所を整理することから始めましょう。
    ビッグデータの考え方だと、生データはとりあえずデータレイクというストレージに入れるか、ストリーミング処理を行うかの大きく 2 択になります。
    データのリアルタイム集計を行いたい場合は即時性を求められるため、ストリーミング処理を行いますが、それ以外はデータレイクに入れることがほとんどです。

<ビッグ データ アーキテクチャのコンポーネント>
2.	データ分析基盤としてのデータガバナンス1

【参考:ビッグ データ アーキテクチャのコンポーネント】
https://docs.microsoft.com/ja-jp/azure/architecture/data-guide/big-data/#components-of-a-big-data-architecture


このデータレイク (上図の Data Storage ) の配置ルールを決めます。多少語弊があるかもしれませんが、とても平たく言うとフォルダ構成を決める感じです。

Azure の場合、Azure Data Lake Storage Gen2 を利用することをお勧めします。
普通の Blob Storage でも良いのですが、Azure Data Lake Storage Gen2 はビッグデータ分析用に特化した機能を有しています。中でも特徴的なのが、階層型名前空間が追加されている点です。

階層型名前空間の機能を使うと、コンピューター上のファイル システムを編成するのと同じ方法で、アカウント内のオブジェクト / ファイルのコレクションを、ディレクトリおよびネストされたサブディレクトリの階層に編成できるようになります。必要なデータの場所をファイルシステムと同じように指定できるため、データ解析のパフォーマンスも早いです。
(「多少語弊があるかもしれませんが、とても平たく言うとフォルダ構成を決める感じです」は、階層型名前空間を意識して書きました。)

【参考:Azure Data Lake Storage Gen2 の概要】
https://docs.microsoft.com/ja-jp/azure/storage/blobs/data-lake-storage-introduction


  • Delta Lake
    前述した事例 (お困りごと) の中に「各システムの更新頻度が異なるため、それぞれのデータがいつの断面の情報かが分からない。」という内容がありました。
    データサイエンティストが過去のデータを必要としている場合や、過去の分析結果を頻繁に再現する必要がある場合等、データの履歴・断面を厳密に管理したい際には、Delta Lake on Azure Databricks (以降、Delta Lake と表記) がお勧めです。

    Delta Lake はデータレイクに信頼性・パフォーマンス向上を加えた、オープンソースのストレージ レイヤーです。Databricks 社が提供しています。

    Delta Lake の特徴的な機能として、トランザクションログをサポートしています。データベースと同じように、いつ、誰がこのデータに変更を加えたか、という情報を保持できます。
    また、タイムトラベルと呼ばれる、データのバージョン管理機能をサポートしています。データのスナップショットをバージョン管理しています。この機能により、ロールバック、完全な履歴監査証跡、および再現可能な機械学習の実験が可能になります。

    【参考:Delta Lake の概要】
    https://docs.microsoft.com/ja-jp/azure/databricks/delta/delta-intro


  • Azure Data Factory
    「このデータはどこから来て、どこに行くんだろう…?」
    ちょっと哲学的な言い回しで書いてみましたが、データのライフサイクル管理やデータの流れを押さえることはとても重要です。
    (ビッグデータの場合、削除はあまり見受けられませんが)

    Azure の場合、Azure Data Factory を使用することをお勧めします。
    Azure Data Factory を使用することで、クラウドベースの ETL およびデータ統合サービスを通じて、各種のデータ ストアからデータを取り込むことができるデータ主導型のワークフロー (パイプライン) を作成し、スケジューリングできます。
    データの流れを一元管理できる、かつ、視覚的に見ることができる点は、データ利活用においても大きな強みとなります。

<Data Factory の位置づけ>
2.	データ分析基盤としてのデータガバナンス2

【参考:Data Factory の概要】
https://docs.microsoft.com/ja-jp/azure/data-factory/introduction

【参考:Azure Synapse Analytics と Azure Data Factory を使用して自動化されたエンタープライズ BI】
https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/data/enterprise-bi-adf


  • データの利用可能な状態の管理
  • Azure Data Catalog
    みなさまは分からない言葉があった際、インターネットで検索したりしませんか?
    面白そうな本を見つけた際、その本にどんなことが記載されているか、目次を見たりしませんか?
    データの検索・利用についても、上記と同じアプローチを取ることができます。膨大なデータの中から、自分が欲しいデータを早く・確実に取得したい場合は、索引・辞書のようなものが必要になります。

    Azure の場合、データの索引・辞書になってくれるのが Azure Data Catalog というリソースです。Azure Data Catalog は、セルフ サービスのデータ ソース検出を可能にする企業全体の情報 (メタデータ) を管理する、フル マネージド クラウド サービスのカタログです。雑多な情報資産を一元管理することで、データ資産を登録および検出し、データ資産に注釈を付けたり、データに接続したりすることができます。
    データの管理者だけでなく、データの利用者も登録されているデータ ソースに対してタグ付けやドキュメント作成、注釈付けを行うことが可能であるため、カタログを充実させ、育てていくことができます。

    【参考:Azure Data Catalog とは何ですか】
    https://docs.microsoft.com/ja-jp/azure/data-catalog/overview
    ※東日本リージョン、西日本リージョンでは GA されていないのが残念。。。

  • Informatica Enterprise Data Catalog
    もし、「マルチクラウド環境でも同じデータカタログを使用して、一元管理を行いたい」「データプレパレーション (※1) にも力を入れたい」という場合は、データカタログに特化した製品を使用した方が良いです。

    ※1:分析に必要とされるさまざまな非定型データを収集 / 整形し、迅速な分析開始のためのサポートを行う機能。データカタログの情報をインプットとすることで、作業効率が向上する。

    Informatica Enterprise Data Catalog を使用すると、上記の要望も対応できます。
    現在、パブリッククラウドでのホスティング環境として、AWS と Azure がサポートされています。Azure の場合、マーケットプレイスから入手することができます。
    データプレパレーションも専用の GUI (Excel ライクな Web UI ) があり、データ変換機能も搭載されています。
    また、Informatica Enterprise Data Catalog は、メタデータを自動収集しデータカタログを自動で作成してくれる点も魅力です。

    【参考:ハイブリッド環境で複雑化するデータ管理、「攻め」と「守り」のデータガバナンスを実現する方法とは】
    https://www.atmarkit.co.jp/ait/articles/1806/11/news003.html

    【参考:Informatica Enterprise Data Catalog】
    https://www.informatica.com/jp/products/data-catalog/enterprise-data-catalog.html



3. データ分析基盤としてのセキュリティ

「2. データ分析基盤としてのデータガバナンス」に関連して、データガバナンスについて Microsoft の Docs を確認したところ、『ベスト プラクティス : Azure Databricks でのデータ ガバナンス』という、そのものずばりの記事が出てきました。

【参考:ベスト プラクティス : Azure Databricks でのデータ ガバナンス】
https://docs.microsoft.com/ja-jp/azure/databricks/security/data-governance

そこには、「データガバナンスが重要な理由」として、以下の内容が記載されています。

データガバナンスは、組織内のデータ資産を安全に管理するために実装されたポリシーとプラクティスをカプセル化した包括的な用語です。データガバナンスを成功させるための重要な原則の1つとして、データセキュリティは大規模な組織にとって最も重要であると考えられます。データセキュリティにとって重要なのは、データチームが組織全体でユーザーデータアクセスパターンをより優れた可視性と監査機能を持つことができるようにすることです。効果的なデータガバナンスソリューションを実装することで、企業はデータを不正なアクセスから保護し、規制要件に準拠するための規則を確実に適用することができます。


「データガバナンスを成功させるための重要な原則の1つとして、データセキュリティは大規模な組織にとって最も重要であると考えられます。」という記載から、データガバナンスとセキュリティはかなり密接であるように見受けられます。

では、Azure Databricks のセキュリティについてどのように記載されているのかを確認したところ、とても興味深いことが分かりました。


<Azure Databricks のセキュリティとデータガバナンスの関係>
※本情報は 2020/07/29 時点の情報です。
3.	データ分析基盤としてのセキュリティ1



【参考:セキュリティとプライバシー】
https://docs.microsoft.com/ja-jp/azure/databricks/security/

Azure Databricks の「セキュリティとプライバシー」の 1 項目として、「Azure Databricks でのデータ ガバナンス」が挙げられています。
つまり、Azure、少なくとも Azure Databricks では、データガバナンスはセキュリティの中の 1 項目と捉えられている、ということになります。

※それぞれの URL をよく見ると、「セキュリティとプライバシー」 ( /security/ ) の下に「ベスト プラクティス : Azure Databricks でのデータ ガバナンス」 ( /security/data-governance ) がある構成になっていますね。


データ分析基盤としてのセキュリティで必要なことは、プラットフォームのセキュリティで必要なことと変わりはありません。主に以下の 3 点が重要になります。

<データ分析基盤としてのセキュリティで最低限必要な施策>
  • 暗号化
  • 通信制御
  • 認証・認可

『ベスト プラクティス : Azure Databricks でのデータ ガバナンス』でもいくつかの方法が記載されていますが、いずれもアクセス制御 (主に認証) かアクセスの監査に集約されています。


  • 暗号化
    暗号化は「通信の暗号化」と「データの暗号化」の 2 種類が必要となります。

  • 通信の暗号化
    通信の暗号化は、データ通信におけるトランスポートレベルでの暗号化です。
    TLS 1.2 を使用した通信や、HTTPS の利用を強制する施策が一般的です。

<通信の暗号化 (一例) >
3.	データ分析基盤としてのセキュリティ2

リソースによってデフォルトでセキュリティ施策が有効になっているものもある点が安心ですよね。


  • データの暗号化
    データの暗号化は、データベースファイルやクラスターといったデータの入れ物に対する暗号化と、データ自体に対する暗号化があります。
    それぞれ、以下のような施策があります。

<データの暗号化 (一例) >
3.	データ分析基盤としてのセキュリティ3

特にデータ自体に暗号化を実施する場合は、暗号化の対象となるデータと暗号化する理由を明確にしておくことが、データのセキュリティを守るためのルールとして必要になります。

※ちょっと余談ですが、セキュリティアセスメントを実施している際、以下のようなやり取りがしばしば見受けられます。
~ 開発中のシステムに対するセキュリティアセスメント時の一例 ~
SBT:「暗号化の対象となるデータやカラムを教えていただけますでしょうか。」
お客様:『機密情報と個人情報に関わるものを暗号化する予定です。』
SBT:「“機密情報”と“個人情報”は、具体的にどんな情報が該当するのか教えていただけますでしょうか。」
お客様:『えーっと…少々お待ちください…。』

※弊社のセキュリティアセスメントについてはこちらを参照ください (宣伝) 。


  • 通信制御
    通信制御はファイアウォールが一般的です。Azure では、IP ファイアウォール規則だけでなく、仮想ネットワーク ファイアウォール規則 (NSG) もサポートされています。NSG は、Azure 上の特定の仮想ネットワーク (VNet) 内にあるサブネットからのみ、通信を許可するというようなシナリオに有効です。

<通信制御 (一例) >
3.	データ分析基盤としてのセキュリティ4

Azure での通信制御は、やはり NSG がキモになります。


  • 認証・認可
    Azure において認証・認可のメインとなるのは、Azure Active Directory 認証 (AAD 認証) になるかと思います。まずは AAD 認証を行うことをベースとすることを推奨します。

<認証・認可 (一例)>
3.	データ分析基盤としてのセキュリティ5

認証・認可については、会社として一元管理をする方針を取った方が良いです。Azure だと Azure Active Directory という強力な認証基盤があるため、一元管理もしやすいのではないでしょうか。


4. おわりに

今回は「Azure 上のデータ分析基盤環境において、実際にどのようにすればデータガバナンスが保たれるか」という観点で、Azure プラットフォーム側で実現可能なデータガバナンスの方法を調査してみました。意外と? (と言っては失礼ですが…) プラットフォーム側で実現できることが多いのかな?というのが、調査をしてみての正直な感想です。
また、Microsoft の Docs を確認してみても、データガバナンスとセキュリティは場合によっては混在して語られているように見受けられるため、両者は切っても切れない関係にあるように思えました。
(本ブログも、記載内容がセキュリティ寄りになっていますね)

以下、前回のブログの再掲になりますが…。
(大事なことなので 2 回言います)

データの品質やセキュリティを担保し、あらゆるデータを管理することは、データガバナンスが効いている状態に直結すると言えます。
そのためにも、システム的なルールだけではなく、組織・人を含めた全体的な運用ルールが必要となります。
(組織・人の部分が一番難しいことは承知していますが。。。)


データ利活用を促進するためにも、まずはできるところから始めてみてはいかがでしょうか。部分的にでも「データの運用ルール」を制定しておくと、後で全社統合する際に整理できている状態から始まるため、きっと役立つはずです。



関連ページ

データガバナンス ~知識編~

【総合】お問い合わせ

製品・サービスに関するお問い合わせはお気軽にご相談ください

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録