計画

ユーザーのエクスポート

この機能を使用するには、アカウントに対する「Manage Account」権限と、すべてのプロファイルに対する「Manage Users」権限が必要です。ファイルに含まれるのは、現在ログインしているユーザーが「Manage Users」権限を持つプロファイルのユーザーと従来のユーザー権限のみです。権限の適用が有効になっている場合、このボタンは表示されなくなります。

ユーザーのエクスポート機能を使用すると、アカウントのユーザー、プロファイル、および各プロファイルの従来のユーザー権限を含むカンマ区切り値（CSV）ファイルをダウンロードできます。これにより、ユーザーとその権限を簡単に監査し、プラットフォーム権限システムで権限グループを作成して管理者ロールを割り当てることができます。

1. クライアントサイドの管理メニューで、Manage Usersをクリックします。アカウント上のユーザーとその一般権限の一覧が表に表示されます。
2. Export Usersをクリックします。
   • 従来の権限：管理メニューでManage Usersをクリックします。Manage Usersダイアログが表示されたら、Export Usersをクリックします。
   • プラットフォーム権限：管理メニューでManage Permissionsをクリックし、次にUsersタブをクリックします。Usersテーブルが表示されたら、Export Usersをクリックします。

CSVファイルでは、権限の値がTRUEまたはFALSEとして一覧表示されます。

次のスクリーンショットは、ダウンロードしたCSVファイルをGoogleスプレッドシートにインポートし、1行目の書式を若干調整したうえで、読みやすくするためにTRUEとFALSEのエントリをYとNに変更した例を示しています。

エクスポートされたデータには「Manage Site Scans」が表示されます。これは従来の機能であり、移行には必要ありません。

この例では、User列にuser3が3回表示されています。アカウント上のすべてのプロファイルで同じ権限を持つ他のユーザーとは異なり、user3は、Website A、Website B、およびWebsite Cの各プロファイルで異なる権限を持っています。そのため、スプレッドシートでは、user3のプロファイル権限が個別の行に記載されています。

クライアントサイドおよびサーバーサイドのユーザーと権限の手動インベントリ

自動エクスポートを使用できない場合、または手動でインベントリを作成する場合は、クライアントサイドで各ユーザーの権限を手動で収集する必要があります。

クライアントサイド

クライアントサイドで各ユーザーの権限をエクスポートするには、次の手順を実行します。

1. クライアントサイドの管理メニューで、Manage Usersをクリックします。アカウント上のユーザーとその一般権限の一覧が表に表示されます。
2. スプレッドシートを作成し、最初の列にUsersというラベルを付けます。
3. スプレッドシートの最初の列にユーザー一覧を追加します。
4. スプレッドシートの2番目の列にProfileというラベルを付けます。
5. 最初のアカウントをクリックします。
6. Edit/View User Settingsをクリックします。ダイアログボックスに、アカウントおよび各プロファイルに対するユーザーの権限（Full、Partial、またはNone）が表示されます。
7. スプレッドシートに、この情報を記録するための次の3つの列を新たに作成します。後で「Manage Account」と「Manage Users」の管理者ロールを構成するときに使用できるよう、列名を控えておきます。
   • Account
   • Profiles
   • JavaScript Code
8. Closeをクリックします。
9. Edit/View User Permissionsをクリックします。ダイアログボックスに、Account、Profiles、およびJavaScriptの権限が表示されます（この情報はすでに取得済みです）。
10. Nextをクリックします。
11. **Select from Currently Assigned Profile(s)**を選択します。
12. ドロップダウンボックスから各プロファイルを選択し、Nextをクリックします。ダイアログボックスに、すべてのプロファイルに対するユーザーの権限が表示されます。
13. ユーザーがすべてのプロファイルで同じ権限を持っている場合は、スプレッドシートのProfile列にAllと入力し、そのユーザーの権限を記録します。ユーザーがプロファイルごとに異なる権限を持っている場合は、各行が異なるプロファイルを表すようにスプレッドシートでそのユーザーの行を複製し、Profile列にプロファイル名を入力して、次のタイトルの列に権限を記録します。
    • Manage Users
    • Manage Resource Locks
    • Publish to Dev/Custom Environment
    • Publish to QA Environment
    • Publish to Prod Environment
    • Manage Tag Templates
    • Save Existing Versions
    • Save As New Versions
    • Promote to Dev/Custom Environment
    • Promote to QA Environment
    • Promote to Prod Environment
14. Cancelをクリックします。
15. 各ユーザーについて、この手順を繰り返します。

これで、クライアントサイドのユーザー権限がすべて揃いました。

サーバーサイド

サーバーサイドで各ユーザーの権限をエクスポートするには、次の手順を実行します。

1. サーバーサイドの管理メニューで、Manage Usersをクリックします。サーバーサイドのユーザーがまだスプレッドシートに存在しない場合は、そのユーザーを最初の列に追加します。
2. ユーザーアカウントをクリックします。
3. **Next.**をクリックします。ダイアログに、すべてのプロファイルにおけるユーザーの権限が表示されます。
4. ユーザーがすべてのプロファイルで同じ権限を持っている場合は、Profile列にAllと入力し、スプレッドシートにユーザーの権限を記録します。ユーザーがプロファイルごとに異なる権限を持っている場合は、各行が異なるプロファイルを表すようにスプレッドシートでそのユーザーの行を複製し、Profile列にプロファイル名を入力して、適切な行に権限を記録します。
   • No Access - プロファイルにアクセスできません。
   • Reader - プロファイルに読み取り専用でアクセスできます。
   • Editor - プロファイルを編集して保存できますが、パブリッシュすることはできません。
   • Publisher - Editorの権限に加えて、プロファイルを保存およびパブリッシュできます。また、すべてのサーバーサイド製品および機能へのフルアクセス権を持ちます。
5. Closeをクリックします。
6. 各ユーザーについて、この手順を繰り返します。

前述の例に基づき、次のスクリーンショットは、サーバーサイドのユーザーと権限を追加して更新したスプレッドシートを示しています。

この例では、user6、user7、およびuser8はクライアントサイドで権限を持っていないため、スプレッドシートに手動で追加する必要がありました。また、user7は、サーバーサイドのプロファイルであるApp AとApp Bで異なる権限を持っているため、user7のプロファイル権限ごとに個別の行がスプレッドシートに作成されています。

これで、従来の権限システムから、クライアントサイドおよびサーバーサイドのプロファイルに対するすべてのユーザー権限を取得できました。

スプレッドシートの監査

すべてのユーザーの権限をスプレッドシートに記録したら、業務に必要なプロファイルに対して、アクセス権が多すぎる、または不足しているユーザーがいないか確認します。プロファイルのリソースにアクセスするには、ユーザーが少なくとも1つの権限グループに所属している必要があることに注意してください。実際のニーズを反映するようにスプレッドシートを更新します。

また、すでに会社に在籍していないユーザーや、アカウントへのアクセスを必要としないユーザーを必ず削除してください。

個々のユーザーのニーズをスプレッドシートに追加する

各ユーザーのプロファイル権限をスプレッドシートに記録したら、ユーザーごとに製品およびデータレベルの最終的なニーズをスプレッドシートに追加する必要があります。

• ユーザーに付与するPIIデータへのアクセスレベル。
• 各ユーザーがアクセスできる製品および製品機能。
• 各製品機能に対して各ユーザーに付与するアクセスレベル。

PIIデータの要件

PII権限では、PIIデータを表示できるユーザーと、PIIデータを識別する制限付きデータプロパティを編集できるユーザーを制御します。1つのグループに割り当てられるPII権限レベルは1つだけです。PII権限には、次の3つのレベルがあります。

• PIIなし – ユーザーはPII属性を表示できますが、その属性値は表示できません。PIIは、TraceやLive Eventsを含め、表示されるすべての場所でマスキングされます。
• 表示 – ユーザーはPII属性およびデータの値を表示できますが、PIIデータを編集または管理することはできません。
• 管理と表示 – ユーザーはPIIデータを表示、編集、管理できます。

各ユーザーのPII権限について、アクセス不可、表示アクセス、または管理と表示アクセスのいずれが必要かをスプレッドシートに記入します。

EAおよびEEAでは、PII権限はグループ単位で管理されていました。GAでは、PII権限の管理がグループベースからユーザーベースに移行しました。EAおよびEEAでグループに構成されたPII権限は、ユーザーベースのPII権限に自動的に移行されます。

製品と機能の要件

製品アクセス権限では、ユーザーがアクセスできるTealium製品と機能を指定します。

製品アクセス権限は機能権限に分かれており、次の表に示すように、グループに割り当てられた製品権限によって異なる場合があります。

表示と編集または表示、編集、削除権限を持つユーザーには、保存権限も付与されます。

タグ管理

顧客データプラットフォーム（CDP）

イベントストリーミング

データアクセス

* Tealium Insightsの権限は、ユーザー管理者が分析 > Insights > QuickSightユーザーページから構成できます。詳細については、Tealium Insightsについてを参照してください。

Predict

Functions

サーバー側ツール

サーバー側（その他）

機能間の権限に関する問題

機能または製品へのアクセスを無効にする場合は、慎重に検討してください。ユーザーの特定機能へのアクセスを無効にすると、その機能に依存する他の機能からもアクセスできなくなります。例：

• ユーザーのCDPオーディエンスへのアクセスを無効にすると、そのユーザーはCDPコネクタでアクションの対象となるオーディエンスを選択できなくなります。
• ユーザーのサーバー側ラベルへのアクセスを無効にすると、そのユーザーはサーバー側でラベルを表示できなくなります。ラベルが構成されたコネクタやその他の機能にはアクセスできますが、ラベル自体を表示または編集することはできません。
• Event StreamingとCDPは、ルールやラベルなど一部の機能を共有しています。ユーザーがEvent Streamingにしかアクセスできない場合でも、Event StreamingとCDPで共有されているルールを編集すると、CDP内のルールも変更されます。

スプレッドシートの更新

製品と機能ごとにスプレッドシートに列を作成し、各ユーザーに付与するアクセスレベルを記入します。

これで、すべてのユーザーについて、個別の要件をスプレッドシートにまとめることができました。

次の手順では、ユーザーをグループに分類します。

組織情報の追加

組織ごとに、固有の構造、要件、ワークフローがあります。組織のワークフローに合わせて権限を構成することで、各ユーザーに職務に適したアクセス権を付与し、プライバシー規制に反するデータアクセスを防止できます。そのため、ユーザーをグループに分類するには、ユーザーと組織についていくつかの点を確認する必要があります。

以下にいくつかの例を示します。

• 組織内の異なる部門がクライアント側プロファイルとサーバー側プロファイルを管理しているため、それぞれに個別の権限グループを構成しますか？
• ユーザーの追加、異動、削除時に役職に基づいて権限をすばやく割り当てられるように、職務（開発者、QA、データマネージャー、エンジニア、コンプライアンス担当者など）に基づいて権限グループを作成しますか？
• プロファイルとユーザーが地域別のキャンペーンやサイトに基づいて編成されており、異なるデータ保存法やデータプライバシー法が適用されるため、権限グループを地域別に分割しますか？
• 権限グループを製品別（CDP、Event Streaming、Customer Data Hubなど）に分割しますか？

「はい」と回答した質問ごとにスプレッドシートへ列を追加し、その質問がユーザーと組織およびワークフローとの関係にどのような影響を与えるか、その列にメモを記入します。

プロファイルの監査

主要なクライアントサイドプロファイルと主要なサーバーサイドプロファイルがそれぞれ1つしかなくても、ブランドや組織が複数の地域および責任体制に分かれている場合、このデータは、将来的にアカウントへ地域別プロファイルを構成するプロジェクトの一環として役立ちます。ただし、最初にプラットフォーム権限システムで権限を構成し、テストすることをお勧めします。

ユーザーをグループに分類する

これで、すべてのユーザーのニーズと組織との関係がスプレッドシートに記録されました。各列に基づいてユーザーを並べ替えます。

共通のニーズとアクセス権に基づいて、ユーザーをグループにまとめられるようになりました。

• グループ内のユーザーがアクセスする必要のあるプロファイル。
• 各プロファイルに対してグループメンバーが必要とするアクセスレベル。
• グループメンバーにクライアントサイドおよびサーバーサイドプロファイルのパブリッシュ権限が必要かどうか。サーバーサイドのパブリッシュ権限を持つユーザーは、すべてのサーバーサイド製品および機能へのフルアクセス権も持つため、どのグループにその権限を付与するかは慎重に判断してください。サーバーサイドのパブリッシャー専用に、サーバーサイドパブリッシングというグループを作成することをお勧めします。
• 各グループがアクセスできる製品および製品機能。
• 各製品機能に対して各グループが持つべきアクセスレベル。
• ユーザーが PII データにアクセスできるようにするかどうか。
• ユーザーがクライアントサイド、サーバーサイド、またはその両方でプロファイルを保存および／またはパブリッシュできるようにするかどうか。
  • 製品または機能に対する編集アクセス権には、ユーザーがプロファイルに加えた変更を保存する権限も含まれます。
  • サーバーサイドのパブリッシュアクセス権には、サーバーサイドの製品および機能へのフルアクセス権が含まれます。

部門や職務別にユーザーを管理する、地域別にグループ化するなど、組織のその他のニーズに基づいて、ユーザーをさらに小さなグループに分割できます。

ここで確定したユーザーグループが、作成する必要のある権限グループです。

管理者ロールを追加する

グループの計画が完了したので、次に管理者ロールを計画します。

スプレッドシートを確認しながら、アカウント自体について次の点を検討してください。

• アカウントへのフルアクセスが必要なのは誰か。
• ユーザーと、アカウント内のグループに対するユーザーの所属を管理するのは誰か。
• アカウントの技術的な構成を管理するのは誰か。
• アカウント上の個人を特定できる情報（PII）に関するデータ権限を管理するのは誰か。
• アカウントのプロファイルを管理するのは誰か。

クライアントサイドのユーザー権限インベントリにある［Admin］および［Profiles］構成を使用すると、プラットフォーム権限システムで誰にアカウントの管理者ロールを付与すべきかを判断できます。

• アカウント管理者 - このロールは、アカウントへのフルアクセス権を持ちます（他のロールの権限を含みます）。
• ユーザー管理者 - このロールは、権限グループとユーザー権限を管理します。ユーザーの追加、ユーザーの編集、および権限グループへのユーザーの割り当てを担当するユーザーには、このロールを付与する必要があります。
• 技術管理者 - このロールは、ファーストパーティドメインなど、アカウント構成に関する機能を管理します。
• プライバシー管理者 - このロールは、グループの PII 権限レベルを管理します（ユーザー管理者ロールが必要です）。データプライバシーおよびコンプライアンスの担当者は、このロールの候補となります。
• プロファイル管理者 - このロールは、プロファイルおよびライブラリへのアクセスを管理します。アカウント上でプロファイルを構築および整理するユーザーには、このロールを付与する必要があります。このロールには、プロファイルの編集権限やパブリッシュ権限は含まれません。これらの権限は、権限グループ内の権利を通じて付与されます。
• 標準ユーザー - このロールは、すべての権限をグループ権限から取得します。

管理者ロールの詳細については、管理者ロールを参照してください。

ユーザー管理者の管理者ロールは、ユーザーがプラットフォーム権限システムをテストする際に権限グループの調整を支援できるため、移行プロセスで特に役立ちます。

お疲れさまでした。これで、作成する必要のある権限グループと、割り当てる必要のある管理者ロールを把握できました。