Azure でのクラウド規模の分析のデータ プライバシー
クラウド規模の分析により、組織は複数のレベルで個人データを保護しながら、要件に合った最適なデータ アクセス パターンを決定できます。 個人データには、運転免許証番号、社会保障番号、銀行口座の詳細、パスポート番号、電子メール アドレスなど、個人を一意に識別できるあらゆる情報が含まれます。 現在、ユーザーのプライバシーを保護するために、多くの規制があります。
Azure などのクラウド環境でデータのプライバシーを保護するには、まずデータ アクセス ポリシーを指定するデータ機密性スキームを作成します。 これらのポリシーでは、データ アプリケーションが存在する基になるアーキテクチャを定義し、データ アクセスの承認方法を定義して、許可された後にアクセスできる行または列を指定できます。
データ機密性分類スキームを作成する
| 分類 | 説明 |
|---|---|
| パブリック | このデータは、誰もがアクセスでき、誰にでも送信できます。 たとえば、政府の公開データなどです。 |
| 内部でのみ使用されます | このデータは、従業員のみがアクセスでき、社外に送信することはできません。 |
| 機密 | このデータは、特定のタスクに必要な場合にのみ共有できます。 このデータは、機密保持契約を結ばずに社外に送信することはできません。 |
| 機微 (個人データ) | このデータには、マスクする必要がある非公開の情報が含まれており、知る必要がある場合にのみ、限定された期間共有されます。 このデータは、承認されていない担当者や社外に送信することはできません。 |
| 制限付き | このデータは、その保護に責任を負う指定された個人とのみ共有できます。 たとえば、法的文書や営業秘密などです。 |
データを取り込む前には、そのデータを機密以下または機微 (個人データ) として分類する必要があります。
- 異なるユーザーに表示される列と行に制限がない場合、データは機密以下のデータに分類できます。
- 異なるユーザーに表示される列と行に制限がある場合、データは機密 (個人データ) に分類できます。
重要
以前は低い機密性に分類されていた他のデータ製品とデータが結合された場合、そのデータセットは機密以下の分類から機微 (個人データ) に変更される可能性があります。 データを永続的に保持する必要がある場合は、機密性レベルとオンボーディング プロセスに合わせて指定されたフォルダーに移動する必要があります。
Azure ポリシー セットを作成する
データ分類をマッピングした後は、分類を地域における規制対象業界のポリシー要件と社内のポリシーに合わせる必要があります。 この手順は、デプロイできるインフラストラクチャ、デプロイできる場所、ネットワークと暗号化の標準を指定する Azure ポリシー セットを作成するために役立ちます。
規制対象の業界向けに、Microsoft はコンプライアンス フレームワークのベースラインとして機能する多くの規制コンプライアンス ポリシー イニシアティブを作成しました。
暗号化と許可されるインフラストラクチャ SKU およびポリシー イニシアティブについて同じルールに従うデータ分類の場合、データは同じランディング ゾーン内に配置できます。
制限付きデータの場合、管理グループの下にある専用のデータ ランディング ゾーンでデータをホストすることをお勧めします。このゾーンでは、暗号化用のカスタマー マネージド キーや、ランディング ゾーンに適用される受信または送信の制限など、インフラストラクチャに対するより高度な要件を定義できます。
Note
ガイダンスでは、機微データ (個人データ) および機密以下のデータを同じデータ ランディング ゾーンに配置し、異なるストレージ アカウントに配置することを評価しました。 ただし、これにより、ネットワーク セキュリティ グループなど、ネットワーク層でのソリューションが複雑になる可能性があります。
デプロイされたデータ ガバナンス ソリューションでは、カタログ内の制限されたデータを検索できるユーザーを制限する必要があります。
また、セキュリティを強化するために、すべてのデータ資産とサービスに対して Microsoft Entra ID 条件付きアクセスを実装し、制限付きデータに対して Just-In-Time アクセスの実装も検討する必要があります。
暗号化
場所と許可する Azure サービスに関するポリシーの定義に加えて、各データ分類の暗号化要件を考慮する必要があります。
- キー管理の要件は?
- これらのキーを格納するための要件は?
- 保存データの暗号化に関する分類ごとの要件は?
- 転送中データ暗号化に関する分類ごとの要件は?
- 使用中データの暗号化に関する分類ごとの要件は?
キー管理において、暗号化キーはプラットフォームで管理することも、お客様が管理することもできます。 Microsoft では、キー管理ソリューションの選択に役立つように、Azure でのキー管理について文書化しています。 詳細については、「Azure でのキー管理の概要」および「最適なキー管理ソリューションを選択する方法」を参照してください。
Microsoft では、保存時の Azure データの暗号化とデータ暗号化モデルについて説明したドキュメントを公開しています。利用可能な暗号化オプションの理解にお役立てください。
Microsoft のお客様は、クラウド サービスとお客様の間でデータが移動するときに、トランスポート層セキュリティ (TLS) プロトコルを使用してデータを保護できます。 詳細については、「転送中のデータの暗号化」を参照してください。
Azure Confidential Computing 脅威モデルは、使用中データを暗号化したままにする必要があるシナリオで、信頼を最小限に抑えるか、クラウド プロバイダーのオペレーターやテナントのドメイン内の他のアクターが実行中コードやデータにアクセスする可能性を排除することを目的としています。
最新の Azure Confidential Computing オファリングについては、Azure Confidential Computing 製品に関する記事を参照してください。
データ ガバナンス
許可される Azure サービスの展開に関するポリシーを定義したら、データ製品へのアクセスを許可する方法を決定する必要があります。
Microsoft Purview や Azure Databricks Unity Catalog などのデータ ガバナンス ソリューションがある場合は、エンリッチ済みおよびキュレーション済みデータ レイク レイヤーのデータ資産/製品を作成できます。 これらのデータ オブジェクトをセキュリティで保護するには、データ カタログ内でアクセス許可を設定してください。
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 は、Microsoft が導入した強力な機能であり、SQL Server データベースに保存されている機密データのセキュリティを強化します。 SQL Always Encrypted により、SQL Server データベースに保存されている機微データが安全に保たれ、不正アクセスから保護されます。 この機能は、保存データと転送中データの両方を暗号化することで、最大限のデータ機密性と規制コンプライアンスを維持するために役立ちます。
Always Encrypted は、暗号化と暗号化解除の操作をクライアント側で実行することで、機微データを不正アクセスから常に保護します。 統合の容易さとコンプライアンスの利点により、価値の高いデータ資産を保護しようとしている組織にとって不可欠なツールとなっています。