次の方法で共有


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

クラウド規模の分析は、複数のレベルで個人データを保護しながら、要件に合った最適なデータ アクセス パターンを決定するのに役立ちます。 個人データには、運転免許証番号、社会保障番号、銀行口座の詳細、パスポート番号、電子メール アドレスなど、個人を一意に識別できる情報が含まれます。 ユーザーのプライバシーを保護するために、多くの規制が存在します。

Azure などのクラウド環境内でデータのプライバシーを保護するために、データ アクセス ポリシーを指定するデータ機密性スキームを作成できます。 これらのポリシーでは、データ アプリケーションが存在する基になるアーキテクチャを定義し、データ アクセスを承認する方法を定義し、ユーザーがアクセスできる行または列を指定できます。

データ機密性分類スキームを作成する

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

データを取り込む前に、データを 機密または 以下のカテゴリに分類するか、機密の個人データとして分類する必要があります。

  • ユーザーが表示できる列と行を制限する必要がない場合は、機密以下にデータを並べ替えます。
  • データを機密個人情報として分類することで、ユーザーが表示できる列や行を制限することができます。

重要

データセットは、以前に分類が低かった他のデータ製品とデータを組み合わせると、機密または下から機密の個人データに変わる可能性があります。 永続的なデータが必要な場合は、その機密性レベルとオンボード プロセスに合わせて指定されたフォルダーに移動します。

Azure ポリシー セットを作成する

データを分類したら、分類を業界のポリシー要件と社内ポリシーに合わせる必要があります。 デプロイできるインフラストラクチャ、デプロイできる場所、ネットワークと暗号化の標準を管理する Azure ポリシー セットを作成する必要があります。

規制対象の業界では、コンプライアンス フレームワークのベースラインとして、microsoft 規制コンプライアンス ポリシー イニシアチブ 使用できます。

データ分類は、暗号化、許可されたインフラストラクチャ SKU、ポリシー イニシアチブに関する同じ規則に従います。 そのため、すべてのデータを同じランディング ゾーン内に格納できます。

制限付きデータの場合は、インフラストラクチャのより高い要件セットを定義できる管理グループの下の専用データ ランディング ゾーンでデータをホストする必要があります。 たとえば、ランディング ゾーンの暗号化または受信または送信の制限にカスタマー マネージド キーを定義できます。

Note

機密の個人データと機密データまたは以下のデータは、同じデータ ランディング ゾーンに配置できますが、ストレージ アカウントは異なります。 ただし、この方法では、ネットワーク セキュリティ グループなど、ネットワーク層上のソリューションが複雑になる可能性があります。

デプロイされたデータ ガバナンス ソリューションでは、カタログ内の制限されたデータを検索できるユーザーを制限する必要があります。 すべてのデータ資産とサービスに対する Microsoft Entra ID 条件付きアクセスの実装を検討してください。 セキュリティを強化するには、制限付きデータに Just-In-Time アクセスを適用します。

暗号化の要件を検討する

場所と許可される Azure サービスのポリシーを定義するだけでなく、各データ分類の暗号化要件を考慮してください。 次の領域の要件を検討してください。

  • キー管理
  • キー ストレージ
  • 保存データの暗号化
  • 転送中のデータ暗号化
  • 使用中のデータ暗号化

キー管理には、プラットフォームで管理される暗号化キーまたはカスタマー マネージド暗号化キーを使用できます。 詳細については、「Azure でのキー管理の概要」および「適切なキー管理ソリューションを選択する方法」を参照してください。

暗号化オプションの詳細については、「保存時の Azure データ暗号化データ暗号化モデルを参照してください。

トランスポート層セキュリティ (TLS) プロトコルを使用して、クラウド サービスと顧客の間を移動するデータを保護できます。 詳細については、「転送中のデータの暗号化」を参照してください。

使用中にデータを暗号化したままにする必要があるシナリオの場合、Azure Confidential Computing の脅威モデルは信頼を最小限に抑えるのに役立ちます。 これは、クラウド プロバイダーオペレーターやテナントのドメイン内の他のアクターが実装時にコードとデータにアクセスできる可能性を最小限に抑えます。

詳細については、Azure コンフィデンシャル コンピューティング製品 に関するページを参照してください。

データ ガバナンスを実装する

許可された Azure サービスのデプロイのポリシーを定義したら、データ製品へのアクセスを許可する方法を決定します。

Microsoft Purview や Azure Databricks Unity カタログなどのデータ ガバナンス ソリューションがある場合は、強化されたキュレーションされたデータ レイク レイヤー用のデータ資産または製品を作成できます。 これらのデータ オブジェクトをセキュリティで保護するために、データ カタログ内でアクセス許可を設定していることを確認します。

Microsoft Purview を使用して、次の領域を一元的に管理、セキュリティ保護、制御します。

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

Microsoft Purview を使用して読み取りまたは変更アクセスを管理する方法の詳細については、「Microsoft Purview データ所有者ポリシーの概念を参照してください。

Microsoft Purview または別のデータ ガバナンス ソリューションを実装する場合でも、Microsoft Entra ID グループを使用して、データ製品にポリシーを適用します。

データ ガバナンス ソリューションの REST API を使用して、新しいデータセットをオンボードします。 データ アプリケーション チームは、データ製品を作成し、データ ガバナンス ソリューションに登録して、機密データの識別に役立ちます。 データ ガバナンス ソリューションは、定義をインポートし、チームがアクセス ポリシーを設定するまで、データへのすべてのアクセスを拒否します。

データ保護パターンを使用する

機密データを保護するには、実装するデータ、サービス、ポリシーに基づいてデータ保護パターンを選択します。

複数のコピー

機密性の高い個人データ分類を持つすべてのデータ製品のパイプラインによって、2 つのコピーが作成されます。 パイプラインは、1つ目を機密またはそれ以下として分類します。 このコピーには、機密性の高い個人データ列は含まれません。 これは、データ製品の機密フォルダーまたは以下のフォルダーの下に作成されます。 もう 1 つのコピーは、機密性の高い個人データ フォルダーに作成されます。 このコピーには機密データが含まれます。 各フォルダーには、Microsoft Entra ID リーダーと Microsoft Entra ID ライターのセキュリティ グループが割り当てられます。

Microsoft Purview を使用する場合は、データ製品の両方のバージョンを登録し、ポリシーを使用してデータをセキュリティで保護できます。

複数のコピー パターンでは、機密性の高い個人データと機密データまたは以下のデータが分離されます。 ただし、機密性の高い個人データへのアクセス権をユーザーに付与すると、すべての行に対してクエリを実行できます。 組織では、行をフィルター処理するために行レベルのセキュリティを提供する他のソリューションを検討する必要がある場合があります。

行レベルと列レベルのセキュリティ

ユーザーが表示できる行をフィルター処理する必要がある場合は、行レベルのセキュリティを使用するコンピューティング ソリューションにデータを移動できます。

再エンジニアリングを防ぐには、特定のユース ケースに適した Azure サービスまたは Microsoft Fabric ソリューションを選択します。 さまざまな種類のデータベースは、さまざまな目的で設計されています。 たとえば、広範な分析にオンライン トランザクション処理 (OLTP) データベースを使用しないでください。 また、eコマース アプリケーションを使用する場合は、ビッグ データ分析用に調整されたソリューションを使用しないでください。これは、必要なミリ秒の応答時間を達成できないためです。

行レベルのセキュリティをサポートするソリューションを実装する場合、データ アプリケーション チームは、異なる Microsoft Entra ID グループを作成し、データの秘密度に基づいてアクセス許可を割り当てる必要があります。

行レベルのセキュリティに加えて、特定の列へのアクセスを制限できます。 次の表は、読み取り専用アクセス権を持つ 4 つの Microsoft Entra ID グループの例を示しています。

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

第 1 レベルの制限では動的データ マスクがサポートされており、特権のないユーザーから機密データが非表示になります。 REST API を使用して、このアプローチをデータセットのオンボードに統合できます。

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

列の暗号化

動的データ マスクはプレゼンテーションの時点でデータをマスクしますが、一部のユース ケースでは、ソリューションがプレーンテキスト データにアクセスする必要はありません。

SQL Always Encrypted 機能により、SQL Server データベースの機密データのセキュリティが強化されます。 SQL Always Encrypted は、SQL Server データベース内の機密データを安全に保ち、未承認のアクセスから保護するのに役立ちます。 この機能は、保存データと転送中のデータを暗号化し、データの機密性と規制のコンプライアンスを最大限に維持するのに役立ちます。 SQL Always Encrypted は、クライアント側で暗号化と暗号化解除の操作を実行します。 この機能を統合して、最も貴重なデータ資産を保護します。

次の手順