
データ分類 – どのように分類し、どこに保存するか
以前、成熟したデータ分類プログラムの要件について説明しました。この投稿では、そのようなプログラムの管理メカニズムをレビューします。データ分類は通常、以下のような3層または4層のシステムを含みます。
データ分類に新しい組織には、3層システムから始めることをお勧めします。これらのレベルとそれに対応するアクションやコントロールを定義するのは難しい場合があります。3層システムでは、すべての内部データを機密扱いとします。
したがって、優先事項は機密データをサポートするために必要なプロセスと手順を作成することです。インタビューや技術的な調査を通じて、後で公開データや高度機密データの限られた量を特定できます。その後、場所、プロセス、アプリケーションを含め、ビジネス全体に目標を明確に伝えることができます。
今日は、データが通常どのように組織内で保存されているか、そしてどこに保存されているかを取り上げます。これらの構造は、プログラムの範囲、運用、技術的な決定に大きな影響を与えます。各組織が異なるビジネスプロセスと技術を持っているため、各データ分類プロジェクトも異なるものになります。
構造化データと非構造化データの比較
構造化データと非構造化データを分類することは、説明するのが最も簡単なデータ分類コンポーネントですが、管理するのが最も難しいです。構造化データとは、通常データベース内のアプリケーションに含まれるデータのことです。組織のアプリケーション所有者、データベース管理者、またはアプリケーションベンダーが、アプリケーションに保存されているデータの種類を説明できます。
組織は、アプリケーションにどれだけのデータとデータタイプが保存されているかに驚かされます。人事、顧客関係管理(CMR)システム、企業資源計画(ERP)プラットフォーム、アカウントプラットフォーム、M&Aソリューションは、歴史的に大規模な構造化データの蓄積を保持するアプリケーションのほんの一例です。これらのシステムの多くは規制されており(例:人事、ERP)、したがってデータは特定の期間、場合によっては無期限に保持する必要があります。
「個々のソフトウェア配布のセキュリティとガバナンス機能は、細かいアクセス制御や新たなガバナンス要件をすべて満たすわけではありません。」
– Doug Henschen
非構造化データは、アプリケーションに保存されていないデータです。Excelスプレッドシート、PowerPointプレゼンテーション、Wordドキュメントは、非構造化データの典型的な例です。非構造化データは、構造化データシステムから生成されたレポートにしばしば見られます。
非構造化データは通常、構造化データの10倍の量です。その理由は簡単です。重要なファイルのコピーを複数の場所に保存することで、従業員は安心感を得るからです。メールは、組織内で最大の非構造化データの量を占めています。
考えてみてください。従業員は、重要または機密の文書をメールで送信して、全員がコピーを持っていることを確認し、そのメールをPSTファイルやノートパソコンのフォルダに保存します。ネットワーク全体の数百の場所に、機密性の高いデータを含む単一ファイルの数百のコピーが存在する可能性があります。
データレイクとクラウドソリューションの不吉なアプローチ
今日のビジネスのトレンドは、組織が保存しているすべての構造化データに価値を見出すことです。不動産から廃棄物管理までの業界が、収集しているデータに隠れた価値を発見しました。このトレンドは金融業界で始まったと思う人もいるかもしれませんが、それは間違いです。
データの台頭は、GoogleやFacebookが先駆けた分析への注目から始まりました。これらの組織は、特定のユーザーに広告をターゲットにすることで、収益性と顧客の粘着性を向上させることができることを認識しました。
IPアドレス、ログイン時間、ホバリングポイントなどのデータは、ユーザーに関するユニークな知見を提供し、より多くの広告主に販売することができました。その情報は、他の組織にとってもさまざまな理由で有用でした。ケンブリッジ・アナリティカを覚えていますか?この新しい価値データは、当時はそのように呼ばれていなかったものの、最初のデータレイクによって可能になりました。
「新しいものには、古いものから期待していた利益がないのが鍵です。」
– Merv Adrian
データレイクは、組織に対してあらゆるソースと形式のデータを「ダンプ」するユニークな機会を提供します。通常、管理されておらず、湖にアクセスできるアカウントにはオープンです。湖の目的(マーケティング、ビジネスインサイト、アーカイブなど)に関係なく、データ分類の特性は同じです。まず、すべてのデータを受け入れます。次に、設計上オープンプラットフォームです。第三に、これらのソリューションの大部分はクラウドに移行しているか、クラウドで構築されています。
データウェアハウスとデータレイクの比較
データウェアハウスは、レイクよりも安全です。これは、データが入力される前にクレンジングされるためです。以下を参照してください: データウェアハウスは、クラウドに入る前にデータをクレンジングします。
一方、データレイクは、変換や再構築のステップを経ずにすべてのデータを取り込みます:
データレイクは、データウェアハウスとは異なり、すべてのデータを無条件で受け入れます。
このようなデータをすべてレイクにする際に生じるデータ分類の問題を見過ごすことはできません。特に規制コンプライアンスの観点からです。レイクの設計には最初から関与する必要があります。
レイクがどのように構築されているかに関係なく、データ分類はその設計において考慮されるべきです。たとえば、アーカイブ目的でレイクが設計されている場合、高度機密データを含めるべきでしょうか?高度機密データは独自のレイクを持つべきか、それとも完全に除外すべきでしょうか?
データの注入の最初、またはプロセスデータストアからエクスポートされるときに分類を適用することが最良の戦略です。
レイクにデータを提供しているシステムを知ることは重要です。データがレイクに投入されると、エンタープライズデータベースやリレーショナルデータベースシステムと比較して、ガバニンググループ(サイバー、リスク、コンプライアンスなど)に利用可能な保護が少なくなります。
従来のデータベース管理システムでは、情報セキュリティチームがすべてのネットワークセキュリティとアクセス制御の保護を担当するかもしれませんが、データがデータベース管理システムに入った後はほとんど何もしません。
しかし、データレイクの構造には、基本的な参照整合性から役割ベースのアクセスや職務分離に至るまで、従来のデータベース管理システムに関連するすべてのガバナンス機能とポリシーが備わっているわけではありません。
データレイクのセキュリティにアプローチする一つの方法は、それを上流、中流、下流のコンポーネントを持つパイプラインとして考えることです。各段階に関連する脅威ベクトルは多少異なるため、それぞれ異なる方法で対処する必要があります。
データレイクは組織に大きな価値を提供しますが、分類コントロールを維持するためには異なるガバナンスモデルが必要です。
次回予告
次の投稿では、これまでに議論したすべての要素をデータ管理コントロールマトリックスと共にまとめます。