プラン
このドキュメントでは、プラットフォームの権限システムへの移行計画について説明します。
ユーザーのエクスポート
この機能にはアカウントの「アカウント管理」権限と各プロファイルの「ユーザー管理」権限が必要です。ファイルには、現在ログインしているユーザーが「ユーザー管理」権限を持っているプロファイルのユーザーとレガシーユーザー権限のみが含まれます。権限の強制が有効になっている場合、このボタンは表示されません。
ユーザーのエクスポート機能を使用すると、アカウントのユーザー、プロファイル、および各プロファイルのレガシーユーザー権限を含むコンマ区切り値（CSV）ファイルをダウンロードできます。これにより、ユーザーとその権限を監査し、権限グループを構築し、プラットフォームの権限システムで管理者ロールを割り当てることが容易になります。
- クライアント側の管理メニューで、ユーザー管理をクリックします。テーブルにはアカウントのユーザーとその一般的な権限が表示されます。
- ユーザーのエクスポートをクリックします。
- レガシー権限：管理メニューでユーザー管理をクリックします。ユーザー管理ダイアログが表示されたら、ユーザーのエクスポートをクリックします。
- プラットフォーム権限：管理メニューで権限管理をクリックし、次にユーザータブをクリックします。ユーザーテーブルが表示されたら、ユーザーのエクスポートをクリックします。
CSVファイルには権限値が TRUE または FALSE としてリストされます。
次のスクリーンショットは、GoogleシートにインポートされたダウンロードしたCSVファイルを示しており、行1の軽微な書式構成の調整と、読みやすさのために TRUE と FALSE のエントリを Y と N に変更しています：
エクスポートされたデータには「サイトスキャンの管理」が含まれています。これはレガシー機能であり、移行目的では必要ありません。
この例では、user3 が ユーザー列に3回表示されます。他のユーザーとは異なり、アカウントのすべてのプロファイルで同じ権限を持っているわけではなく、user3 のプロファイル権限はスプレッドシートの別々の行に含まれています。
クライアント側およびサーバー側のユーザーと権限の手動インベントリ
自動エクスポートを使用できない場合や手動でインベントリを実行することを好む場合は、クライアント側で各ユーザーの権限を手動で収集する必要があります。
クライアント側
クライアント側で各ユーザーの権限をエクスポートするには、次の手順を実行します：
- クライアント側の管理メニューで、ユーザー管理をクリックします。テーブルにはアカウントのユーザーとその一般的な権限が表示されます。
- スプレッドシートを作成し、最初の列にユーザーとラベルを付けます。
- スプレッドシートの最初の列にユーザーリストを追加します。
- スプレッドシートの2番目の列にプロファイルとラベルを付けます。
- 最初のアカウントをクリックします。
- ユーザー構成の編集/表示をクリックします。ダイアログボックスには、アカウントおよび各プロファイルでのユーザーの権限が表示されます（フル、部分、なし）。
- スプレッドシートにこの情報を含む3つの新しい列を作成し、後でアカウント管理およびユーザー管理の管理ロールを構成するときに使用する列名をメモします：
- アカウント
- プロファイル
- JavaScriptコード
- 閉じるをクリックします。
- ユーザー権限の編集/表示をクリックします。ダイアログボックスにはアカウント、プロファイル、およびJavaScriptの権限が表示されます（この情報はすでに持っています）。
- 次へをクリックします。
- 現在割り当てられているプロファイルから選択を選択します。
- ドロップダウンボックスから各プロファイルを選択し、次へをクリックします。ダイアログボックスには、ユーザーの各プロファイルでの権限が表示されます。
- ユーザーがすべてのプロファイルで同じ権限を持っている場合は、スプレッドシートのプロファイル列にすべてと入力し、ユーザーの権限をメモします。ユーザーがプロファイルで異なる権限を持っている場合は、ユーザーの行をスプレッドシートで複製し、各行が異なるプロファイルを表すようにし、プロファイル列にプロファイル名を入力し、次の列にその権限をメモします：
- ユーザー管理
- リソースロックの管理
- Dev/カスタム環境への公開
- QA環境への公開
- Prod環境への公開
- タグテンプレートの管理
- 既存バージョンの保存
- 新しいバージョンとして保存
- Dev/カスタム環境への昇格
- QA環境への昇格
- Prod環境への昇格
- キャンセルをクリックします。
- 各ユーザーに対してこのプロセスを繰り返します。
サーバー側
サーバー側で各ユーザーの権限をエクスポートするには、次の手順を実行します：
- サーバー側の管理メニューで、ユーザー管理をクリックします。スプレッドシートにまだ存在しないサーバー側のユーザーの場合は、最初の列に追加します。
- ユーザーアカウントをクリックします。
- 次へをクリックします。ダイアログには、ユーザーの各プロファイルでの権限が表示されます。
- ユーザーがすべてのプロファイルで同じ権限を持っている場合は、スプレッドシートのプロファイル列にすべてと入力し、スプレッドシートにユーザーの権限をメモします。ユーザーがプロファイルで異なる権限を持っている場合は、ユーザーの行をスプレッドシートで複製し、各行が異なるプロファイルを表すようにし、プロファイル列にプロファイル名を入力し、適切な行に権限をメモします。
- アクセスなし - プロファイルにアクセスできません。
- リーダー - プロファイルに対する読み取り専用アクセス。
- エディター - プロファイルを編集および保存できますが、公開はできません。
- パブリッシャー - エディターに加えて、プロファイルを保存および公開できます。また、すべてのサーバー側製品および機能に完全アクセスできます。
- 閉じるをクリックします。
- 各ユーザーに対してこのプロセスを繰り返します。
前の例に基づいて、次のスクリーンショットは、サーバー側のユーザーと権限で更新されたスプレッドシートを示しています：
この例では、user6、user7、およびuser8はクライアント側で権限がなく、スプレッドシートに手動で追加する必要がありました。また、user7はサーバー側のプロファイルApp AとApp Bで異なる権限を持っているため、user7のプロファイル権限用にスプレッドシートの別々の行が作成されました。
これで、レガシー権限システムからのクライアント側およびサーバー側のプロファイルのすべてのユーザー権限が揃いました。
スプレッドシートの監査
スプレッドシートにすべてのユーザーの権限が記載されたので、仕事を遂行するために必要なプロファイルに対してアクセスが多すぎるか、不十分かを確認します。ユーザーはプロファイルのリソースにアクセスするために少なくとも1つの権限グループに所属している必要があります。スプレッドシートを更新して、実際のニーズを反映させてください。
また、会社を離れたり、アカウントへのアクセスが不要なユーザーもスプレッドシートから削除してください。
スプレッドシートに個々のユーザーのニーズを追加
スプレッドシートに各ユーザーのプロファイル権限が記載されたので、次に各ユーザーに対して最終的な製品およびデータレベルのニーズをスプレッドシートに追加する必要があります：
- ユーザーが持つべきPIIデータへのアクセスレベル。
- 各ユーザーがアクセス可能な製品および製品機能。
- 各ユーザーが各製品機能に対して持つべきアクセスレベル。
PIIデータのニーズ
PII権限は、PIIデータを誰が閲覧できるか、および制限データプロパティを編集できるかを制御します。グループに割り当てることができるPII権限のレベルは1つだけです。PII権限の3つのレベルは次のとおりです：
- No PII – ユーザーはPII属性を閲覧できますが、これらの属性の値を見ることはできません。PIIは、TraceやLive Eventsを含む表示される場所であいまいにされます。
- View – ユーザーはPII属性の値を閲覧できますが、PIIデータを編集または管理することはできません。
- Manage & View – ユーザーはPIIデータを閲覧、編集、および管理できます。
スプレッドシートに、ユーザーがPIIに対してアクセスなし、閲覧アクセス、または管理および閲覧アクセスのいずれであるかをメモしてください。### 製品と機能のニーズ
製品アクセス権限は、ユーザーがアクセスできるTealiumの製品と機能を指定します。
製品アクセス権限は機能権限に分けられ、グループに割り当てられた製品権限によって異なる場合があります。以下の表に示すようになります。
閲覧＆編集または閲覧、編集＆削除の権限を持つユーザーは、保存の権限も持っています。
iQタグ管理
| 機能 | 利用可能な権限 |
|---|---|
| JavaScript拡張 | アクセスなし、閲覧、編集＆削除 |
| 高度なJavaScript拡張 - Devへ昇格 | アクセスなし、閲覧、編集＆削除 |
| 高度なJavaScript拡張 - QAへ昇格 | アクセスなし、閲覧、編集＆削除 |
| 高度なJavaScript拡張 - Prodへ昇格 | アクセスなし、閲覧、編集＆削除 |
| Dev/カスタムへ公開 | アクセスなし、閲覧、編集＆削除 |
| QAへ公開 | アクセスなし、閲覧、編集＆削除 |
| Prodへ公開 | アクセスなし、閲覧、編集＆削除 |
| 保存 | アクセスなし、閲覧、編集＆削除 |
| 公開構成 | アクセスなし、閲覧、編集＆削除 |
| コード構成 | アクセスなし、閲覧、編集＆削除 |
| リソースロック | アクセスなし、閲覧、編集＆削除 |
| クライアントサイドバージョン | アクセスなし、閲覧、閲覧＆編集 |
| タグテンプレート | アクセスなし、閲覧、閲覧＆編集 |
| タグ、拡張、ロードルール、データレイヤー | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
AudienceStream
| 機能 | 利用可能な権限 |
|---|---|
| ダッシュボード | アクセスなし、閲覧 |
| Discovery/Sizing | アクセスなし、閲覧 |
| オーディエンス | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| オーディエンスコネクタ | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| 訪問/訪問属性 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
EventStream
| 機能 | 利用可能な権限 |
|---|---|
| データソース | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| イベント属性 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| イベントコネクタ | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| イベント仕様 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| ライブイベント | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| オムニチャネル | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
DataAccess
| 機能 | 利用可能な権限 |
|---|---|
| アクセスキー | アクセスなし、閲覧 |
| Tealium Insights* | アクセスなし、閲覧 |
| EventStore Legacy | アクセスなし、閲覧 |
| AudienceDB | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| EventDB | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| AudienceStore | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| EventStore | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
* Tealium Insightsの権限は、Insights > Manage Usersページを通じてユーザー管理者によって構成できます。詳細については、Tealium Insightsについてを参照してください。
Predict
| 機能 | 利用可能な権限 |
|---|---|
| すべての機能 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
Functions
| 機能 | 利用可能な権限 |
|---|---|
| 認証情報/認証、グローバル変数 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
サーバーサイドツール
| 機能 | 利用可能な権限 |
|---|---|
| ルール管理 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| 訪問削除 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| 訪問検索 | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| 訪問プロファイルサンプラー | アクセスなし、閲覧 |
サーバーサイド（その他）
| 機能 | 利用可能な権限 |
|---|---|
| ラベル | アクセスなし、閲覧、閲覧＆編集、閲覧編集＆削除 |
| トレース | アクセスなし、閲覧 |
| バージョン | アクセスなし、閲覧 |
機能間の権限問題
機能または製品へのアクセスを無効にする場合は慎重に検討してください。ユーザーがある機能へのアクセスを無効にした場合、そのユーザーはそれに依存する他の機能でもその機能にアクセスできなくなります。例えば：
- ユーザーがAudienceStreamのオーディエンスへのアクセスを無効にした場合、そのユーザーはAudienceStreamコネクタでオーディエンスをアクションに選択することができません。
- ユーザーがサーバーサイドのラベルへのアクセスを無効にした場合、そのユーザーはサーバーサイドのラベルを見ることができません。彼らはラベルを含むコネクターや他の機能にアクセスできますが、ラベル自体を見たり編集したりすることはできません。
- EventStreamとAudienceStreamは、ルールやラベルなどのいくつかの機能を共有しています。ユーザーがEventStreamのみにアクセス権を持っていても、EventStreamとAudienceStream間で共有されるルールを編集すると、AudienceStreamのルールも変更されます。
スプレッドシートの更新
各製品と機能に対してスプレッドシートの列を作成し、ユーザーが各々に持つべきアクセスレベルをマークします。
おめでとうございます。これで、スプレッドシートにすべてのユーザーの個々のニーズが記載されました。
次のステップは、ユーザーをグループに編成することです。
組織情報の追加
すべての組織には独自の構造、ニーズ、およびワークフローがあります。組織のワークフローに合わせて権限を構成することで、各人がその職務に適したアクセスを持ち、プライバシー規制によりデータへのアクセスが不適切になることがないようにすることができます。そのためには、ユーザーと組織に関するいくつかの質問をする必要があります。
いくつかの提案です：
- クライアントサイドとサーバーサイドのプロファイルに対して別々の権限グループを構成しますか？これは、組織の異なる部分がこれらの製品を管理しているためです。
- 職責に基づいて権限グループを作成しますか？（開発者、QA、データマネージャー、エンジニア、コンプライアンスなど）これにより、ユーザーを追加、移動、または削除するときに、その職務に基づいて迅速に権限を割り当てることができます。
- 地域によって権限グループを分けますか？これは、プロファイルとユーザーが地理的なキャンペーンやサイトによって編成されており、異なるデータ保管およびデータプライバシー法が適用されるためです。
- 製品別に権限グループを分けますか？（AudienceStream、EventStream、Customer Data Hubなど）
各「はい」の回答に対して、スプレッドシートに別の列を追加し、その質問がそのユーザーの組織とワークフローにどのように影響するかについてその列にメモを追加します。
プロファイル監査
もし主要なクライアントサイドプロファイルとサーバーサイドプロファイルが1つだけで、ブランドと組織が複数の地域と責任構造に分かれている場合、このデータはアカウントの地域プロファイルを構成する将来のプロジェクトの一部として役立つかもしれません。ただし、まずはプラットフォームの権限システムで権限を構成してテストすることをお勧めします。
ユーザーをグループに分類する
スプレッドシートにすべてのユーザーのニーズと組織との関係が文書化されたので、各列ごとにユーザーを分類します。
これで、共通のニーズとアクセス権を持つユーザーをグループに編成することができます：
- グループ内のユーザーがアクセスする必要があるプロファイル。
- 各プロファイルにおけるグループメンバーの必要なアクセスレベル。* グループメンバーがクライアント側およびサーバー側のプロファイルに対する公開権限を持つべきかどうか。サーバー側の公開権限を持つユーザーは、すべてのサーバー側製品と機能に完全アクセスできるため、どのグループにその権限を付与するか慎重に考える必要があります。サーバー側の公開者用に Server-side Publishing という専用グループを作成することをお勧めします。
- 各グループがアクセスできるべき製品と製品機能。
- 各製品機能における各グループのアクセスレベル。
- ユーザーが個人識別情報（PII）データにアクセスできるかどうか。
- ユーザーがクライアント側、サーバー側、または両方でプロファイルを保存および/または公開できるかどうか。
- 製品または機能の編集アクセスは、ユーザーのプロファイル変更を保存する権限も付与します。
- サーバー側の公開アクセスには、サーバー側の製品と機能への完全アクセスが含まれます。
組織の他のニーズに基づいて、ユーザーをより小さなグループに分けることができます。例えば、部門や職務機能によるユーザー管理、地理的なグルーピングなどです。
これらの最終的なユーザーグループが、作成する必要がある権限グループです。
管理者ロールの追加
グループの計画ができたので、次は管理者ロールの計画を立てます。
スプレッドシートを見ながら、アカウント自体についていくつかの質問を自問自答してください：
- アカウントへの完全アクセスが必要な人は誰ですか？
- アカウントのグループ内でユーザーとユーザーメンバーシップを管理するのは誰ですか？
- アカウントの技術的構成を管理するのは誰ですか？
- アカウントの個人識別情報（PII）データ権を管理するのは誰ですか？
- アカウントのプロファイルを管理するのは誰ですか？
クライアント側のユーザー権限インベントリからの管理者およびプロファイル構成は、プラットフォームの権限システムでアカウントの管理者ロールを誰に与えるべきかを決定するのに役立ちます：
- Account Admin - このロールはアカウントへの完全アクセスを持ちます（他のロールの権限を含む）。
- User Admin - このロールは権限グループとユーザー権限を管理します。ユーザーの追加、編集、権限グループへの割り当てを担当する人はこのロールを持つべきです。
- Technical Admin - このロールは、第一者ドメインなどのアカウント構成機能を管理します。
- Privacy Admin - このロールはグループ内のPII権限レベルを管理します（User Adminロールが必要）。データプライバシーとコンプライアンスを担当する人はこのロールの候補です。
- Profile Admin - このロールはプロファイルとライブラリへのアクセスを管理します。アカウント上でプロファイルを構築し整理する人はこのロールを持つべきです。このロールにはプロファイルの編集や公開権限は含まれません。それらは権限グループ内の権限を通じて付与されます。
- Standard User - このロールはグループ権限を通じてすべての権限を受け取ります。
管理者ロールについての詳細は、Admin Rolesを参照してください。
User Admin 管理者ロールは、特に移行プロセスに役立ちます。これらの人々は、ユーザーがプラットフォームの権限システムをテストするにつれて、権限グループを洗練するのを助けることができます。
おめでとうございます。作成する必要がある権限グループと割り当てるべき管理者ロールを理解しました。
最終更新日 :: 2025年August月20日