Adobe Experience Platformは、複数のエンタープライズシステムのデータを統合し、必要に応じて、クエリサービスを通じてデータのクリーンアップ、形成、操作、エンリッチメントをおこなうことができます。 これにより、マーケターは、顧客をより良い方法で識別、理解し、惹きつけることができます。 特定のデータは組織のポリシーや法規制に基づく使用制限の対象となる場合があるので、適切なデータガバナンスを確保することは、個人情報の処理にとって重要な側面になります。 取り込んだデータとその関連操作が、定義されたデータ使用ポリシーに準拠していることを確認することが重要です。
クエリサービス内のデータガバナンスを使用すると、顧客データを管理し、データの使用に適した規制、制限、ポリシーへのコンプライアンスを確保できます。 これは、ビジネスで定義された規制に従って使用ポリシーが適用されていることを確認する際に重要な役割を果たします。
データ処理を日常的におこなう組織は、すべてのユーザーに対してプライバシーを重視する環境を作成するために、これらのガイドラインの概要を策定し、実践し、実施することをお勧めします。
クエリサービスを使用する際に、データのコンプライアンス規制に準拠するには、次のカテゴリが役立ちます。
このドキュメントでは、ガバナンスの各領域を調べ、クエリサービスを使用する際にデータコンプライアンスを容易にする方法を示します。 詳しくは、 ガバナンス、プライバシー、セキュリティの概要 を参照して、Experience Platformが顧客データを管理し、コンプライアンスを確保する方法に関する幅広い情報を確認してください。
データセキュリティとは、データを不正なアクセスから保護し、ライフサイクル全体を通じて安全なアクセスを確保するプロセスです。 安全なアクセスは、役割に基づくアクセス制御や属性に基づくアクセス制御などの機能によって、役割および権限の適用を通じてExperience Platformで維持されます。 また、Platform 全体でのデータ保護を確保するために、資格情報、SSL、データ暗号化も使用されます。
クエリサービスに関するセキュリティは、次のカテゴリに分かれています。
Adobe Experience Platformのアクセス制御を使用すると、 Adobe Admin Console :役割ベースの権限を使用して、クエリサービス機能へのアクセスを管理します。 同様に、スキーマとデータフィールドのラベル管理を通じて、特定のデータ属性へのアクセスを制御できます。
この節では、クエリサービス機能を最大限に活用するためにユーザーが持つ必要がある、必要なアクセス制御権限について説明します。 次のドキュメントを参照: 権限の管理 および ユーザーの管理 を参照してください。
関連するアクセス制御権限は、スコープのレベルに応じて、以下の表で定義されます。
クエリ実行権限
クエリサービス内でクエリを実行するには、次の権限を持つ役割がユーザーに割り当てられている必要があります。
権限 | 説明 |
---|---|
クエリの管理 | この権限を持つユーザーは、データ調査とバッチクエリを実行できます。このクエリは、既存のデータセットの読み取りまたはデータセットに対するデータの書き込みをおこなうことができます。 これには、 CREATE TABLE AS SELECT (CTAS ) および INSERT INTO AS SELECT (ITAS ) クエリを使用します。 |
データセットの権限
この節は、クエリサービスを通じてデータをクエリする際に、データセットへのアクセスに必要なリソースベースのアクセスに関するガイドとして機能します。
権限インターフェイスを使用して、次の権限を持つデータセットおよびスキーマのリソースベースのアクセス制御を定義できます。
権限 | 説明 |
---|---|
データセットの管理 | この権限は、スキーマに対して読み取り専用アクセスを提供し、クエリサービスで使用するデータセットの読み取り、作成、編集、削除にアクセスできます。 |
データセットの表示 | この権限を持つユーザーは、クエリサービスで使用するデータセットとスキーマに対して読み取り専用アクセスを許可します。 |
属性ベースのアクセス制御機能を使用すると、クエリサービスのユーザーは、重要なユーザーデータへのアクセスを制限できます。 ロールに割り当てられた権限に基づいて、アクセスを許可または制限できます。 個々の列へのユーザーアクセスは、関連するデータ使用ラベルと、ユーザーに割り当てられた役割に適用される権限セットによって制御されます。
データ使用ラベルを使用してスキーマフィールドグループとクラスにタグ付けすると、同じフィールドグループとクラスを持つすべてのスキーマに、データ使用制限が適用されます。 概要については、 属性ベースのアクセス制御 を参照してください。
この機能を使用すると、選択したユーザーグループに機密列に対するアクセス権を付与できます。 列に対するアクセス制御は、特定のタイプのユーザーに対する読み取り機能と書き込み機能の両方を制限できます。
列のアクセス制御は、標準スキーマとアドホックスキーマの両方のスキーマレベルで適用できます。 XDM スキーマにデータ使用ラベルを適用して、1 つ以上の列へのアクセスを制限します。 データのラベル付けは、事前定義済みのスキーマまたは CTAS 操作の一部として生成されたアドホックスキーマを使用してクエリサービスで作成されたデータセットに対しても、一貫して適用されます。
ラベルとロールを使用して適切なレベルのアクセスを適用すると、ユーザーがアクセス不能なデータにアクセスしようとすると、次のシステム動作が発生します。
ユーザーがスキーマ内の列の 1 つへのアクセスを拒否された場合、制限された列に対する読み取りまたは書き込み権限も拒否されます。 これは、次の一般的なシナリオに当てはまります。
ユーザーが計算フィールドにアクセスしようとすると、構成で使用されるすべてのフィールドに対するアクセス権を持つ必要があります。また、システムが計算フィールドへのアクセスを拒否することも必要です。
クエリサービスは、標準の ANSI SQL を CREATE VIEW
ステートメント。 機密性の高いデータワークフローの場合、ビューを作成する際に適切なコントロールを適用する必要があります。
この CREATE VIEW
キーワードは、クエリのビューを定義しますが、ビューが物理的に実体化されていません。 代わりに、ビューがクエリで参照されるたびにクエリが実行されます。 ユーザーがデータセットからビューを作成すると、親データセットの役割ベースと属性ベースのアクセス制御ルールは次のようになります not 階層的に適用される その結果、ビューの作成時に各列に明示的に権限を設定する必要があります。
を使用 属性ベースのアクセス制御機能 ファクトデータセットとディメンションデータセットに基づいて、組織またはデータの使用範囲を定義できます。 加速貯蔵. これにより、管理者は特定のセグメントへのアクセスを管理し、ユーザーまたはユーザーグループに与えられるアクセスをより適切に管理できます。
高速データセットに対してフィールドベースのアクセス制限を作成するには、クエリサービス CTAS クエリを使用して高速データセットを作成し、既存の XDM スキーマまたはアドホックスキーマに基づいてこれらのデータセットを構築します。 管理者が スキーマのデータ使用状況ラベルの追加と編集 または アドホックスキーマ. スキーマに対して、 ラベル ワークスペース スキーマ UI
データ使用ラベルは、 データセットに直接適用または編集された データセット UI を使用して、またはアクセス制御から作成した ラベル ワークスペース。 方法に関するガイドを参照してください。 新しいラベルを作成 を参照してください。
個々の列へのユーザーアクセスは、添付されたデータ使用ラベルと、ユーザーに割り当てられた役割に適用される権限セットによって制御できます。
クエリサービスには、Platform UI を通じてアクセスするか、外部と互換性のあるクライアントとの接続を形成することでアクセスできます。 使用可能なすべてのフロントへのアクセスは、一連の資格情報によって制御されます。
サードパーティのクライアントを使用してクエリサービスにアクセスするには、認証の資格情報が必要です。 これらの資格情報は、互換性のある外部クライアントのいずれかを使用してクエリサービスにアクセスする場合に必須です。 外部クライアントに接続するには、次のいずれかを使用します。 期限切れの資格情報 または 期限切れでない資格情報.
資格情報の期限が切れています ユーザーは、外部クライアントとの一時的な接続を形成できます。 この一連の資格情報は 24 時間のみ有効です。 これらの種類の資格情報の有効期限は、クエリサービスダッシュボードの「資格情報」タブと共に表示されます。
期限切れでない資格情報 を使用すると、外部クライアントとの永続的な接続を形成でき、手動のパスワードを必要とせずに、クエリサービスに簡単に接続できます。
有効期限のない資格情報を生成するオプションを有効にするには、以下に示す手順に従う必要があります。 前提条件のワークフロー. このプロセスの一環として、組織管理者は、製品プロファイルの権限を設定し、有効期限の切れない資格情報を使用するためのアクセス権を持つアカウントを管理者が制御できるようにする必要があります。
有効期限のない資格情報で許可されたテクニカルユーザーアカウントには、役割を割り当てて、責任とニーズに基づいて読み取りと書き込みアクセスの範囲を定義することで、適切なデータガバナンスを確保できます。 前の節を参照してください。 アクセス制御によるロールベースの権限の使用 をクリックして、クエリサービスへのアクセスを管理します。
前提条件のワークフローが完了したら、権限を持つユーザーが 必要な接続資格情報の生成.
セキュリティを強化するために、クエリサービスは、クライアント/サーバー通信を暗号化する SSL 接続をネイティブでサポートします。 Platform は、データセキュリティのニーズに合わせて様々な SSL オプションをサポートし、暗号化と鍵交換の処理オーバーヘッドのバランスを取ります。
利用可能なに関するガイドを参照してください クエリサービスへのサードパーティクライアント接続の SSL オプション を参照してください。 verify-full
SSL パラメーター値。
暗号化とは、データをエンコードされた読み取り不可能なテキストに変換し、情報を復号化キーなしで保護し、アクセスできないようにする、アルゴリズムプロセスの使用です。
クエリサービスのデータコンプライアンスにより、データが常に暗号化されます。 送信中のデータは常に HTTPS に準拠し、保存時のデータはシステムレベルのキーを使用して Azure Data Lake ストアで暗号化されます。 詳しくは、 Adobe Experience Platformでのデータの暗号化方法 を参照してください。 Azure Data Lake Storage での保存データの暗号化方法について詳しくは、 Azure の公式ドキュメント.
クエリサービスは、ユーザーのアクティビティを記録し、そのアクティビティを様々なログタイプに分類します。 次の情報をログに記録します: who 実行済み what アクションおよび when. ログに記録される各アクションには、アクションのタイプ、日時、アクションを実行したユーザーの電子メール ID、アクションのタイプに関連する追加の属性を示すメタデータが含まれます。
任意のログカテゴリを、Platform ユーザーの希望に応じてリクエストできます。 この節では、クエリサービスに対して取り込まれる情報のタイプと、この情報にアクセスできる場所の詳細を説明します。
クエリログ UI を使用すると、クエリエディターまたはクエリサービス API を使用して実行されたすべてのクエリの実行詳細を監視および確認できます。 これにより、クエリサービスアクティビティに透明性が向上し、のメタデータを確認できるようになります。 すべて クエリサービス全体で実行されたクエリ。 調査クエリ、バッチクエリ、スケジュール済みクエリのどれであるかに関わらず、すべてのタイプのクエリが含まれます。
クエリログは、Platform UI の ログ タブ クエリ ワークスペース。
監査ログには、クエリログよりも詳細な情報が含まれ、ユーザー、日付、クエリのタイプなどの属性に基づいてログをフィルタリングできます。 クエリログ UI で使用できる詳細のほか、監査ログには、個々のユーザーに関する詳細とセッションデータまたはサードパーティクライアントへの接続が保存されます。
ユーザーの行動を正確に記録することで、監査記録は問題のトラブルシューティングに役立ち、企業のデータ管理ポリシーや規制要件に効果的に対応するのに役立ちます。 監査ログは、すべての Platform アクティビティの記録を提供します。 監査ログを使用すると、クエリの実行、テンプレート、スケジュール済みクエリに関するユーザーアクションを監査して、クエリサービスでユーザーが実行するアクションの透明性と可視性を高めることができます。
次の表に、監査ログによってキャプチャされるクエリカテゴリと、それらが記録するアクションタイプを示します。
カテゴリ | アクションタイプ |
---|---|
クエリ | 実行 |
クエリテンプレート | 作成、削除、更新 |
スケジュール済みクエリ | 作成、削除、更新 |
以下に、3 つの拡張サーバーログのリストを示します。このリストには、クエリログ内のログよりも詳細な情報が格納されます。 拡張ログは、監査ログクエリカテゴリ内にあります。
詳しくは、 監査ログの概要 監査ログが組織でデータコンプライアンスへの対応に役立つ方法の詳細を参照してください。
Platform のデータガバナンスフレームワークは、すべてのAdobeソリューション、サービス、プラットフォームにわたって、責任を持ってデータを一律に使用する方法を提供します。 メタデータをキャプチャ、伝達し、Adobe Experience Cloud全体で使用するための体系的なアプローチを調整します。 これにより、データ管理者は、必要なマーケティングアクションに従ってデータにラベルを付け、意図されたマーケティングアクションからそのデータに対して課される制限を設けることができます。 概要については、 データ使用ラベル 「データガバナンス」では、データセットとフィールドにデータ使用ラベルを適用する方法について詳しく説明します。
データのジャーニーのあらゆる段階で、データのコンプライアンスに向けて取り組むことをお勧めします。 このために、アドホックスキーマを使用する派生データセットは、データガバナンスフレームワークの一部として適切にラベル付けされる必要があります。 クエリサービスで形成される派生データセットには、次の 2 種類があります。標準のスキーマと、アドホックスキーマを使用するデータセットを使用するデータセット。
クエリサービスを使用して作成されたデータセットは、「派生データセット」と呼ばれます。
アドホックスキーマは、特定の目的のために個々のユーザーが作成するので、XDM スキーマフィールドは、特定のデータセットに対して名前空間化され、異なるデータセット間での使用を目的としていません。 その結果、アドホックスキーマは、デフォルトではExperience PlatformUI に表示されません。 標準スキーマとアドホックスキーマの両方でデータ使用ラベルの適用に違いはありませんが、ラベル付けを目的としてクエリサービスで作成されたアドホックスキーマは、まず Platform UI で表示できるようにする必要があります。 詳しくは、 Platform UI 内でのアドホックスキーマの検出 を参照してください。
スキーマにアクセスした後、次の操作を実行できます。 個々のフィールドにラベルを適用. スキーマにラベルが付けられると、そのスキーマから派生するすべてのデータセットは、これらのラベルを継承します。 ここから、特定のラベルを持つデータを特定の宛先に対してアクティブ化しないように制限するデータ使用ポリシーを設定できます。 詳しくは、 データ使用ポリシー.
Privacy Service は、法的プライバシー規制に従って、データに対する顧客のアクセス要求と削除要求を管理するのに役立ちます。 これをおこなうには、データで既存の識別子を検索し、要求されたプライバシージョブに応じて、そのデータにアクセスまたは削除します。 サービスがプライバシージョブ中にアクセスまたは削除するフィールドを決定するには、データに適切なラベルを付ける必要があります。プライバシーリクエストの対象となるデータには、様々なデータを、プライバシーリクエストが適用される個人と結び付けるために、顧客 ID 情報を含める必要があります。 クエリサービスでは、プライバシージョブを満たすために、使用するデータを一意の識別子でエンリッチメントできます。
プライバシーリクエストは、データレイクまたはプロファイルデータストアに送信できます。 データレイクから削除されたレコードは、それらのレコードから作成されたプロファイルを削除しません。 また、データレイクから個人情報を削除するプライバシージョブでは、プロファイルは削除されないので、プライバシージョブの完了後に取り込まれた(そのプロファイル ID を含む)情報は、通常どおりに更新されます。 これにより、臨時のスキーマで使用されるデータを適切に識別する必要が再確認されます。
詳しくは、Privacy Serviceのドキュメントを参照してください。 プライバシーリクエストの id データ およびデータ操作を設定し、Adobeテクノロジーを活用して、顧客のプライバシーリクエストに適した id 情報を効果的に取得する方法について説明します。
データガバナンスのクエリサービスの機能は、データの分類とデータ使用規制への準拠のプロセスをシンプル化し、合理化します。 データが識別されると、クエリサービスを使用して、すべての出力データセットにプライマリ ID を割り当てることができます。 あなた 必須 データセットに id を追加して、データプライバシーリクエストを容易にし、データのコンプライアンスに向けて作業します。
スキーマデータフィールドは、Platform UI とクエリサービスを使用して ID フィールドとして設定できます。また、次のことも可能です。 SQL コマンド「ALTER TABLE」を使用してプライマリ ID をマークします。. を使用した ID の設定 ALTER TABLE
コマンドは、Platform UI を使用してスキーマから直接データセットを作成するのではなく、SQL を使用してデータセットを作成する場合に特に便利です。 手順については、ドキュメントを参照してください。 UI での id フィールドの定義 標準スキーマを使用する場合。