Azure でのクラウド規模の分析のデータ プライバシー

  • [アーティクル]

クラウド規模の分析では、組織は、複数のレベルで個人データを保護しながら、要件に合わせて最適なパターンを決定できます。 個人データは、運転免許証番号、社会保障番号、銀行口座番号、パスポート番号、メール アドレスなど、個人を識別するために使用できる任意のデータです。 現在、ユーザーのプライバシーを保護するために、多くの規制があります。

データ機密性の分類体系

分類 説明
パブリック このデータは、誰もがアクセスでき、誰にでも送信できます。 たとえば、政府の公開データなどです。
内部でのみ使用されます このデータは、従業員のみがアクセスでき、社外に送信することはできません。
機密 このデータは、特定のタスクに必要な場合にのみ共有できます。 このデータは、機密保持契約を結ばずに社外に送信することはできません。
機微 (個人データ) このデータには、マスクする必要がある非公開の情報が含まれており、知る必要がある場合にのみ、限定された期間共有されます。 このデータは、承認されていない担当者や社外に送信することはできません。
制限付き このデータは、その保護に責任を負う指定された個人とのみ共有できます。 たとえば、法的文書や営業秘密などです。

データを取り込む前に、データを 機密以下または機微 (個人データ) として分類する必要があります。

  • ユーザーがエンリッチ済みまたはキュレーション済みのデータ資産へのアクセス権を取得した場合、データが機密以下に分類されることがあります。 ユーザーは、すべての列と行を表示できます。

  • 列と行が異なるユーザーに表示される制限がある場合、データが 機微 (個人データ) に分類されることがあります。

重要

データが結合されると、データセットが機密以下から機微 (個人データ) に変わる "可能性があります"。 データを永続化する必要がある場合は、データの機密性の分類と、それをオンボードするためのプロセスに一致する別のフォルダーに、コピーする必要があります。

機密以下

すべてのオンボード データ製品について、Microsoft はエンリッチ レイヤーとキュレーション レイヤーに 2 つのデータ レイク フォルダー (機密以下と機微 (個人データ)) を作成し、アクセス制御リストを使用して Microsoft Azure ディレクトリ (Microsoft Entra ID) パススルー認証を有効にします。

データ アプリケーション チームが機密以下のデータ資産をオンボードする場合は、ユーザー プリンシパル名とサービス プリンシパル オブジェクトを 2 つの Microsoft Entra グループ (1 つは読み取り/書き込みアクセス用、もう 1 つは読み取り専用アクセス用) に追加できます。 これらの 2 つの Microsoft Entra グループは、オンボード プロセス中に作成し、生データおよびエンリッチ済みデータ用の機密以下コンテナーを使用して適切なデータ製品フォルダー内で並べ替える必要があります。

このパターンにより、Microsoft Entra パススルー認証をサポートする任意のコンピューティング製品で、データ レイクに接続し、ログインしているユーザーを認証できます。 ユーザーがデータ資産の Microsoft Entra グループに属している場合は、Microsoft Entra パススルー認証を介してデータにアクセスできます。 これにより、グループ内のユーザーは、ポリシー フィルターを使用せずにデータ資産全体を読み取ることができます。 その後、適切なログと Microsoft Graph を使用して、アクセスを詳細に監査できます。

データ レイクのレイアウトに関する推奨事項については、データ ランディング ゾーンごとに 3 つの Azure Data Lake Storage Gen2 アカウントをプロビジョニングする方法に関する記事を参照してください。

Note

コンピューティング製品の例としては、Azure Databricks、Azure Synapse Analytics、Apache Spark、Microsoft Entra パススルー認証で有効になっている Azure Synapse SQL オンデマンド プールがあります。

機微データ (個人データ)

機微 (個人データ) の場合、企業は、ポリシー、データ コピー、またはコンピューティングを通じてユーザーが表示できる内容を制限する必要があります。 この場合、組織は、アクセス制御をコンピューティング レイヤーに移動または挿入することを検討する必要があります。 クラウド規模の分析内でデータをセキュリティで保護するには、4 つの方法があります。

シナリオ例

次の例では、機微 (個人データ) をセキュリティ保護するためのオプションについて説明します。

データ アプリケーションによって、北米とヨーロッパの人事 (HR) 社員データ製品が取り込まれます。 このユース ケースでは、ヨーロッパのユーザーにはヨーロッパの社員レコードのみが表示され、北米のユーザーには北米の社員レコードのみが表示されるようにする必要があります。 また、給与データを含む列は HR マネージャーだけに表示されるようさらに制限されています。

最初の 2 つのオプションでは、機微 (個人データ) を処理する方法が提供され、統合運用チームとデータ製品チームを統合し、アクセスを識別して制限するための制御も付与されます。 小規模の分析プラットフォームならそれでも十分かもしれませんが、データ製品が数百にもなる大企業のデータ管理ランディング ゾーンには、ポリシー エンジンを配置する必要があります。 ポリシー エンジンにより、次のものを管理、セキュリティ保護、制御するための一元的な方法をサポートします。

  • データへのアクセス
  • データ ライフサイクルの管理
  • 内部および外部のポリシーと規制
  • データ共有ポリシー
  • 機微 (個人データ) の識別
  • 保護とコンプライアンスに関する分析情報
  • データ保護レポート用のポリシー

通常、ポリシー エンジンは、Azure Purview のようなデータ カタログと統合されます。 Azure Marketplace にはサードパーティ ベンダーのソリューションが掲載されており、一部のベンダーは Azure Synapse や Azure Databricks と連携して、情報の暗号化と復号化を行いながら、行と列レベルのセキュリティも提供します。 2022 年 1 月に、Azure Purview では、BLOB および Azure Data Lake Storage (ADLS) Gen2 に格納されているデータへのアクセスを制御するアクセス ポリシーのパブリック プレビューを開始しました。 Azure Storage のデータ所有者によるデータセットのプロビジョニング（プレビュー）参照してください。

ポリシー エンジンでは、Microsoft Entra グループを使って、データ製品にポリシーを適用する必要があります。 データ プライバシーを提供するすべてのポリシー ソリューションでは、機微 (個人データ) をトークン化し、常に属性のアクセス制御をチェックして、ユーザーがアクセスする必要のある列をトークン化解除できるようにすることが想定されています。

前述のように、ポリシー エンジンが成功するためには、ポリシー エンジンがデータ カタログと統合し、DevOps が REST API を使用して新しいデータセットをオンボードすることが重要です。 データ アプリケーション チームが読み取りデータ ソースを作成すると、それらのソースはデータ カタログに登録されて、機微 (個人データ) を識別するのに役立ちます。 ポリシー エンジンでは、定義をインポートし、チームがアクセス ポリシーを設定するまで、データへのすべてのアクセスを拒否する必要があります。 このすべてを、IT サービス マネジメント ソリューションから REST API ワークフローを使用して行う必要があります。

オプション 2: 機密以下および機微 (個人データ) バージョン

機微 (個人データ) として分類される各データ製品について、パイプラインによって 2 つのコピーが作成されます。 1 つのコピーは機密以下として分類され、すべての機微 (個人データ) 列は削除され、そのデータ製品の [機密以下] フォルダーに作成されます。 もう 1 つのコピーは、そのデータ製品の [機微 (個人データ)] フォルダーに作成されます。これにはすべての機微データが含まれます。 各フォルダーに、Microsoft Entra リーダー セキュリティ グループと Microsoft Entra ライター セキュリティ グループが割り当てられます。 ユーザーは、データ アクセス管理を使用して、データ製品へのアクセスを要求できます。

これで機微 (個人データ) と機密以下の分離を実現できますが、Active Directory パススルー認証を介して機微 (個人データ) へのアクセスを許可されたユーザーは、すべての行に対してクエリを実行できます。 行レベルのセキュリティが必要な場合は、オプション 1: ポリシー エンジン (推奨) か、オプション 3: Azure SQL Database、SQL Managed Instance、または Azure Synapse Analytics SQL プールを使用する必要があります。

オプション 3: Azure SQL Database、SQL Managed Instance、または Azure Synapse Analytics SQL プール

データ アプリケーションでは、SQL Database、SQL Managed Instance、または Azure Synapse Analytics SQL プールを使用して、行レベルのセキュリティ、列レベルのセキュリティ、および動的データ マスキングをサポートするデータベースにデータ製品が読み込まれます。 データ アプリケーション チームにより、さまざまな Microsoft Entra グループが作成され、データの秘密度をサポートするアクセス許可が割り当てられます。

このシナリオのユース ケースでは、データ アプリケーション チームは読み取り専用アクセス権を持つ次の 4 つの Microsoft Entra グループを作成する必要があります。

グループ アクセス許可
DA-AMERICA-HRMANAGER-R 給与情報を含む北米の HR 社員データ資産を表示する。
DA-AMERICA-HRGENERAL-R 給与情報を含まない北米の HR 社員データ資産を表示する。
DA-EUROPE-HRMANAGER-R 給与情報を含むヨーロッパの HR 社員データ資産を表示する。
DA-EUROPE-HRGENERAL-R 給与情報を含まないヨーロッパの HR 社員データ資産を表示する。

最初の制限レベルでは、動的データ マスクがサポートされているため、機密データは特権を持たないユーザーに表示されません。 この方法の利点の 1 つは、REST API を使用してデータ セットのオンボードに統合できることです。

2 番目のレベルでは、HR 以外のマネージャーに給与が表示されないようにする列レベルのセキュリティと、ヨーロッパと北米のチーム メンバーが見ることのできる行を制限する行レベルのセキュリティが追加されます。

透過的なデータ暗号化に加えて、セキュリティ層によりデータの列が暗号化されて、読み取り時に復号化されます。

これらのテーブルは、Apache Spark コネクタ: SQL Server および Azure SQL Database により、Azure Databricks で使用できるようになります。

オプション 4: Azure Databricks

4 番目のオプションでは、Azure Databricks を使用して機微 (個人データ) を探索します。 Fernet 暗号化ライブラリ、ユーザー定義関数 (UDF)、Databricks シークレット、テーブル アクセス制御、動的ビュー関数の組み合わせを使用すると、列の暗号化と復号化に役立ちます。

列レベルの暗号化の適用とデータ重複の回避に関するブログ記事では、次のように説明されています。

このプロセスの最初の手順は、インジェスト中にデータを暗号化することによってデータを保護することであり、考えられる解決策の 1 つとして、Fernet Python ライブラリがあります。 Fernet は、いくつかの標準的な暗号化プリミティブを使用して構築された対称暗号化を使用します。 このライブラリは、データ フレーム内の特定の列を暗号化できるようにする暗号化 UDF 内で使用されます。 暗号化キーを保存するには、アクセス制御が実施されている Databricks シークレットを使用して、データ インジェスト プロセスのみにアクセスを許可します。 データがデルタ レイク テーブルに書き込まれると、社会保障番号、電話番号、クレジット カード番号、その他の識別子などの値を保持している個人データ列を、未承認ユーザーが読み取ることはできなくなります。

機密データを作成して保護したら、特権を持つユーザーがその機密データを読めるようにする必要があります。 最初に実行する必要があるのは、Databricks で実行されている Hive インスタンスに追加する永続的な UDF を作成することです。 UDF を永続的なものにするには、その UDF を Scala で記述する必要があります。 さいわいなことに、Fernet には、暗号化を解除された読み取りに使用できる、Scala 実装も備わっています。 また、この UDF は暗号化された書き込みで使用されるのと同じシークレットにアクセスして暗号化解除を行います。この場合、クラスターの Spark 構成に追加されます。 そのためには、特権のあるユーザーと特権のないユーザーがキーへのアクセスを制御するためのクラスターアクセス制御を追加する必要があります。 UDF が作成されると、特権を持つユーザーが復号化されたデータを表示できるように、ビュー定義内で使用できます。

動的ビュー関数を使用すると、ビューを 1 つだけ作成し、それが属している Databricks グループに基づいて、暗号化または復号化された値を返すことができます。

前の例では、北米用とヨーロッパ用の 2 つの動的ビュー関数を作成し、このノートブックで暗号化技法を実装します。

北米ビュー:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

ヨーロッパ ビュー:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

これを機能させるには、ワークスペースで Azure Databricks のテーブル アクセス制御を有効にして、次のアクセス許可を適用します。

  • DA-AMERICA-HRMANAGER-R と DA-AMERICA-HRGENERAL-R の Microsoft Entra グループに vhr_us ビューへのアクセス権を付与します。
  • DA-EUROPE-HRMANAGER-R と DA-EUROPE-HRGENERAL-R の Microsoft Entra グループに vhr_eu ビューへのアクセス権を付与します。

列は暗号化されており、機密以下のワークスペースでは復号化できないため、機密以下のワークスペースでは引き続き Microsoft Entra パススルー認証を使用でき、アクセス許可に基づいてユーザーにレイクの探索を許可できます。

テーブル アクセスを使用する場合は、アクセスを必要とするチームを Azure Databricks ワークスペースに追加します。 Azure Databricks によりサービス プリンシパルを使用して Azure Data Lake Storage にマップされますが、データは Azure Databricks のテーブル アクセス制御で保護されます。

新しいデータ製品がデプロイされたら、DevOps プロセスの一部では、スクリプトを実行して Azure Databricks ワークスペースにテーブルのアクセス許可を設定し、適切な Microsoft Entra グループをそれらのアクセス許可に追加する必要があります。

Note

Azure Databricks のテーブル アクセス制御を、Microsoft Entra のパススルー認証と組み合わせることはできません。 そのため、Azure Databricks ワークスペースを 1 つだけ使用し、代わりにテーブル アクセス制御を使用することもできます。

制限付きデータ

機密データまたは制限付きデータのオプションを実装するのと共に、機密性の高いデータは専用のデータ ランディング ゾーンおよびデータ管理ランディング ゾーンでホストすることをお勧めします。

これにより、Just-In-Time アクセス、暗号化用のカスタマー マネージド キー、ランディング ゾーンに適用されるインバウンドまたはアウトバウンドの制限など、特定の要件が可能になります。 このガイダンスでは、この種のデータを同じデータ ランディング ゾーンの異なるストレージ アカウントに格納する方法を評価しました。 しかし、ネットワーク セキュリティ グループなどでは、たとえばネットワーク層でのソリューションが複雑になる可能性があります。

専用の "制限付き" データ管理ランディング ゾーンでは、その "制限付き" データ ランディング ゾーン内のデータをカタログに接続する必要があります。 カタログ内でこのデータを検索できるユーザーを制限する必要があります。

次の手順