ユーザーアクセスと権限の理解

物まね

なりすましは、特定のユーザーにユーザーインターフェースがどのように映るか、またどのエンティティにアクセスできるかを確認するのに役立ちます。

管理者 : mdiCogOutline: > Users > Users > 詳細表示 > なりすましをクリックし、なりすまししたいことを確認することでユーザーをなりすませできます。なりすましモードを終了するには、以下のいずれかを行えます:

• サイトのクッキーを削除し、ウェブページを更新してください
• ログアウトしてからスーパーユーザーとして再度ログインしてください。

!ヒント効率的になりすましをするには、2つ目のブラウザ(またはシークレットウィンドウ)でスーパーユーザーとしてContent Hubにログインしてください。そこでユーザーのなりすましを設定し、別のウィンドウでスーパーユーザーとしてのアクセスを引き続き変更できます。これにより、変更を同時に即座にユーザーのアクセスをテストできます。

セキュリティ診断

偽装の代替として、セキュリティ診断ツール は、特定のエンティティ(資産またはコンテンツ項目)に対してユーザーが持つ正確な権限、どのユーザーグループが各権限を付与し、どの継承チェーンを通じてかを確認するのに役立ちます。

ユーザーインターフェースの各領域へのアクセス

モジュールだけではユーザーインターフェースの特定の領域へのアクセスが保証されません。ユーザーがページにアクセスするには、以下のすべてが真実でなければなりません。

• 必要なモジュールは免許証に記載されている必要があります。
• 必要なモジュールはユーザーのアカウントに 割り当て られなければなりません。
• ユーザーは、その特定の Portal.Page エントリに対して権限を与えるポリシーを持つユーザーグループのメンバーReadなければなりません。
• ページは 見える状態でなければなりません。

これらの条件のいずれかが満たされない場合、ユーザーはメニューバーの項目やその中のページを見ることはできません。例えば、アセットやコレクションの読み取り権限を持つユーザーを追加しても、そのユーザーがMediaモジュールを割り当てていない場合、そのユーザーはアセット や コレクション ページにアクセスできません。

上記の条件は、ページを可視化しナビゲート可能にするのに十分です。ユーザーがページ上のデータ、例えば検索結果の資産を見るためには、ページに表示されるエンティティ定義に対する権限Read必要です。

モジュールとユーザーグループ

ユーザーグループごとにモジュールを割り当てる際の以下の挙動に注目してください。

• ユーザーグループに割り当てられたモジュールは、新たに追加されたユーザーに自動的に割り当てられますが、モジュールが割り当てられる前にグループにいたユーザーには割り当てられません。モジュールは既存メンバーに個別に割り当てるか 、大量編集を使って行う必要があります。
• ユーザーグループからユーザーを削除しても、そのグループに割り当てられたモジュールは削除されません。
• 以前グループから割り当てられたモジュールを削除しても、そのユーザーをそのグループから除外することはありません。

ユーザーグループポリシー

ユーザーグループの重要な要素の一つがユーザーグループのポリシーです。すべてのユーザーグループにはポリシーがあります。すべてのポリシーは ルール、メンバーのセキュリティ、権限で構成されており、これらが組み合わさってユーザーのアクセス権を決定します。

ルールと条件

ユーザーグループポリシーを設定する際は、まずポリシー内にルールを作成することから始めます。単一のユーザーグループポリシーには複数のルールを含めることができます。デフォルトでは、ルールの範囲内のすべてのエンティティにルールが適用されます。ルールがどのエンティティに適用されるかを細かく制御するには、ルールに条件を追加できます。単一のルールには複数の条件を含めることができます。

加法許可モデル

Content Hubは許可のみ権限モデルを使用しています。ユーザーグループポリシーのすべてのルールは付与であり、アクセスをブロックしたり削除したりするルールタイプはありません。

拒否メカニズムがないため、ルールを追加してアクセスを制限することはできません。ルールを追加すると追加のアクセスしか許されません。したがって、ユーザーが何かにアクセスできないようにするためには、そのユーザーが所属するどのグループもそのアクセスを許可しないようにしてください。

ユーザーのアクセスを制限するには、以下のいずれかを行う必要があります:

• 不要な権限を与えるグループからユーザーを削除してください。
• そのグループのポリシーから許可を取り除いてください。これはグループの全メンバーに影響します。

加算権限モデルは、ユーザーがユーザーインターフェースで見るものに直接適用されます。ユーザーがページに対してRead権限を持ち、アクセスの他の条件を満たしている場合、そのページとそのナビゲーションアイコン(あれば)はそのページに表示されます。ページをユーザーから隠したい場合は、そのユーザーが所属するどのグループもそのページに権限を与えReadないようにしてください。例として、「管理」エリアへのアクセスを阻止する項目を参照してください。

相続の仕組み

Inherits securityが関係で有効化されると、エンティティはその関係を通じて関係するエンティティのセキュリティコンテキストを継承します。Content Hubは、ユーザーがエンティティにアクセスできるかどうかを評価する際にこの継承コンテキストを使用します。

例えば、PCMProductStatusToProduct関係を通じて関連したProductStatusエンティティと関連するProductエンティティを考えます。その関係で**「継承**」が有効であれば、製品はそのステータスのセキュリティメタデータを継承します。Createdステータスの製品に権限を与えるユーザーグループルールを用いることで、特定の製品が該当するかどうかを正しく評価できます。

Inherits securityが関係で有効でない場合、Content Hubは条件を評価するためにトラバースできません。ルールは正しく設定されていますが、どのエンティティともマッチングせず、権限も付与されません。

コレクションと資産

コレクションの権限とアセットの権限は常に別々に評価されます。ユーザーにコレクションへのアクセスを許可しても、その中の資産へのアクセスが自動的に与えられるわけではありません。

これはCollectionToAsset関係がデフォルトで 「継承」のセキュリティ を無効にしているためです。つまり:

• M.Collectionエンティティを読めるユーザーは、その中の資産を自動的に見ることはできません。
• 特定のコレクション内のアセットへのアクセスを許可するには、M.Asset定義に対して別Read権限をユーザーに付与する必要があります。コレクションとその資産をリンクする共有のタクソノミーカテゴリを使用することで、該当するコレクションにスコープをかけることができます。
• コレクションの詳細ページにある ユーザーアクセス コントロールは、コレクションエンティティ自体へのアクセスのみを許可します。コレクション内の資産へのアクセスは許可しません。これらのユーザーに資産へのアクセスを与えるには、ユーザーグループポリシーで適切な M.Asset 権限を設定する必要があります。

!警告CollectionToAsset関係で「継承セキュリティ」を有効にすることは、標準設定から逸脱するスキーマ変更であり、予期しない動作を引き起こす可能性があります。ユーザーがアセットの読み取りアクセス権を持っている場合、このフラグを有効にすることで、そのアセットに属する他のすべてのコレクションも可視化できる可能性があります。たとえそのコレクションにアクセスする明示的な権限がなくてもです。このフラグを本番環境で有効にする前に、その影響を慎重に評価してください。

多層継承

継承は推移的である。もしエンティティAがある関係を通じてエンティティBからセキュリティを継承し、エンティティBが別の関係を通じてエンティティCからセキュリティを継承した場合、エンティティAもエンティティCからセキュリティを継承する可能性がある。

複数の関係を持つスキーマで継 承セキュリティ が有効の場合、ユーザーが明示的にアクセス権を与えられていないエンティティにアクセスする可能性があります。例えば、特定のブランドにアクセスできるユーザーが、継承関係の連鎖を通じてそのブランドに関連する機能、シリーズ、特別オファーに予期せずアクセスすることがあります。

セキュリティ診断ツールを使って、任意のエンティティの権限チェーンを追跡し、どのユーザーグループとどの継承パスがアクセスを許可しているかを検証します。アクセスが意図した範囲を超えている場合は、許可条件に必要でない中間関係の「継承セキュリティ」を無効にしてください。

!ヒントInherits セキュリティを2レベル以上のネスト関係で有効にするとパフォーマンスにも影響が出ます。なぜなら、Content Hubはエンティティが作成されたり更新されたりするたびにこれらのチェーンを通過しなければならないからです。可能な限り深い継承チェーンは制限してください。

関係上のセキュリティを継承する

関係上の継承セキュリティを可能にするには:

1. Manage > Schemaにアクセスし、関係を含むエンティティ定義を開きます。
2. 設定したい関係メンバーを見つけてください。
3. 関係の 「Advanced 」タブを開きます。
4. Enable Inherits security。
5. 「保存」をクリックします。

フラグを有効にした後、キャッシュ をクリアして変更が即座に有効になるようにしてください。

直接メンバーの条件

条件がエンティティ定義に直接属するメンバー(例えばアセットのタクソノミータグ)に基づいている場合、追加の設定は不要です。Content Hubはエンティティ自身のデータと照合して条件を評価します。

関連団体の条件

条件が関連エンティティに基づいている場合(例えば、関係を通じて製品のステータスでフィルタリングする場合)、両エンティティ定義をつなぐ関係で「 継承 」セキュリティフラグを有効にする必要があります。これがなければ、Content Hubは関係を歩いて条件が満たされているかを評価できず、ルールは静かに効果を持ちません。

これは誤設定の権限のよくある原因です。関係ベースの条件でルールを設定し、期待されるアクセスが認められない場合は、他のトラブルシューティングをする前に、該関係でInherits securityが有効かどうかを確認してください。

制約

• 権限は常に加算的です。条件は許可が適用される対象を絞りますが、アクセスを拒否することはできません。ユーザーのグループの他のルールが条件なしで同じ権限を与えた場合、そのルールが優先され、ユーザーはより広範なアクセス権を保持します。
• タクソノミー条件を使用する場合は、関連するすべてのタクソノミー値を含めてください。Updateエンティティの現在および将来の状態の両方に対して検証されるため、条件に値が欠落している場合、ユーザーはその値にエンティティを更新したり更新したりすることはできません。例えば、M.AssetTypeにだけ含めるPoster、ユーザーはArtworkタグ付けされた資産を編集できません。詳細については、「ユーザーグループポリシーの設定」をご覧ください。
• 特別な「 現在のユーザーによって作成されたのみエンティティ 」オプションも条件の一つです。選択された場合、ルールは現在のユーザーが作成したエンティティにのみ適用され、ルール上の他の条件も加わります。

権限レイヤーの結合

Demo.Photographerというユーザーを考えてみてください。彼はタスクページで割り当てられたタスクだけを見るはずです。これを実現するには:

• ユーザーに Project モジュールが割り当てられます。
• このユーザーはW.Photographersユーザーグループのメンバーであり、Portal.Page 定義のみでRead権限を与えています。
• ユーザーはContent Hubでユーザーに必要な最低権限を割り当てるEveryoneユーザーReadグループのメンバーであり、プロジェクト、タスク、ジョブに関連するページに権限を与えるM.Builtin.Project.Everyoneユーザーグループにも所属しています。
• ユーザーにはプロジェクトロールが割り当てられていません。

これらのレイヤーを合わせることで、ユーザーは タスク ページと割り当てられたタスクにアクセスでき、他のコンテンツや機能を公開しません。

管理エリアへのアクセス防止

ユーザーがManage エリアへのアクセスを阻止したいシナリオを考えます。権限は加算的であるため、管理 エリアを非表示にするルールを設定することはできません。代わりに、ユーザーが属する各ユーザーグループのポータルページ権限を確認し、ユーザーがアクセスする必要があるページのみを含めてください。

それを行うには:

1. ユーザーが所属するすべてのグループを確認しましょう。これらのグループのいずれかから「管理」ページに付与された権限Readは「管理」エリアへのアクセス権を与えます。これらの権限を特定し、必要に応じて削除してください。

   標準Superusersグループはデフォルトで 管理 エリアへのアクセスを提供します。 Everyoneグループを含む他の標準化されたグループは、デフォルトで 管理 エリアへのアクセスを提供しません。

2. ユーザーの ユーザーグループポリシーでPortal.Pageルールを作成し、Portal.Page条件を追加し、「 選択 」をクリックして条件のアイテムを選択します。「 アイテム選択 」モードで、ユーザーが必要とする特定のポータルページ(例えば 「資産 検索ページ」や「資産詳細ページ」)を選択します。これらのページのみでReadを付与してください。 「管理 」ページは選択しないでください。

3. 影響を受けたユーザーのアクセスをテストして、管理エリアにアクセスできないか確認してください。

!注同じ方法でContent Hub内の任意のページへのアクセスを制限できます。デフォルトでは、Superusersグループのユーザーはすべてのポータルページに対してRead権限を持っています。その他のユーザーグループについては、グループが必要な特定のページにのみReadを与えてください。

資産へのアクセス管理

例えば、あるユーザーのアセットページへのアクセスをコントロールできる状況を考えます。このユーザーはすでにMediaモジュールを割り当てているので、メニューバーのアセット項目を見てクリックできます。このユーザーは現在Everyoneグループのメンバーのみなので**、「アセット**」をクリックするとアセットが空のページに表示され、アセットは利用できません。アセットを閲覧させるには、アセットデータとアセットポータルページの両方に権限Read与える必要があります。

そのためには、新しいユーザーグループを作成し、そのユーザーを追加します。グループのポリシーでは、2つのルールを作成します。

• ルール1では、Asset( M.Asset) を追加し、 Readを有効にします。これにより資産データへのアクセスが可能になります。
• ルール2では、 **ポータルページ(Portal.Page)**を追加し、条件を Portal.Page: Assets (およびアセット詳細ページ)に設定し、 Readを有効にしてください。これにより、メニュー内でページが見え、ナビゲートできるようになります。

変更を保存した後、ユーザーはAssetsページで利用可能なすべてのアセットを確認できます。これはどちらのルールにも条件がないためで、それぞれのルールはその範囲内のすべてのエンティティに適用されます。

ルールに条件を追加することで、ユーザーがどのアセットを閲覧できるかを細かく制御できます。例えば、**Asset media(M.AssetMedia)**に基づくルール1に条件を追加し、「 Select」をクリックし、「 docx 」と 「mp4」を選択します。選択を確認し、変更を保存します。ユーザーはこれでDOCXとMP4のアセットのみにアクセスできます。

例えばルール1に「 地理:カナダ」などの2つ目の条件を追加すると、アセットがアクセス可能になるには両方の条件が真でなければなりません。ユーザーは現在、地理タグがカナダに設定されているDOCXまたはMP4アセットのみにアクセスできます。

関連団体によるアクセス制限

例えば、ABCにユーザーが入りたい場合を考えてみましょう 。Product。CreatorグループはCreatedステータスの商品のみを更新できる場合です。

**Product (M.PCM.Product)**のルールを作成し、M.PCMの条件を追加します。ProductStatus: Created、UpdateとDeleteを有効にします。結果をテストしますが、Createdステータスの製品であっても、編集コントロールはユーザーに表示されません。

原因は、PCMProductStatusToProduct関係に「 継承セキュリティ 」が有効になっていないためです。Content Hub関係をトラバースしてステータス条件を確認できないため、ルールは適用されません。

これを直す方法:

1. > Schema > Product (M.PCM.) の****管理へ**> 編集**
2. 商業タブで、関係メンバーPCMProductStatusToProductを見つけてクリックします。その他の操作 > 編集 。
3. メンバー 編集 モードの Advanced タブで「 Inherits security」を有効にし、「 保存」をクリックします。
4. キャッシュをクリアしろ。

この変更後、条件は正しく評価され、ABC内のユーザーも 対象となります。Product.CreatorはCreatedステータス内の製品のみを更新・削除できます。

コレクション内の資産へのアクセス許可

collectionTestユーザーグループのユーザーに特定のコレクション内のアセットを表示させたいシナリオを考えてみてください。

コレクションのM.Collection定義でReadを付与し、ユーザーをグループに追加すると、ユーザーはコレクションページでコレクションを見ることができます。しかし、コレクションを開くと空っぽに見えます。

原因は、コレクション権限とアセット権限が別々に評価されていることです。 CollectionToAsset関係ではデフォルトで 「継承」のセキュリティ が無効になっているため、コレクションへの読み取りアクセスがその中の資産にカスケードされません。

これを解決するには、collectionTestグループに別途権限をReadM.Asset付与する必要があります。すべての資産ではなく、その特定のコレクション内の資産のみへのアクセス範囲を限定するには、共有の分類カテゴリを使用します:

1. 「新しい**分類****法>**管理」> に行き、Category例えば
2. タクソノミー管理ページで、Add をクリックすると、Category Aなどの項目をタキソノミーに追加できます。
3. M.CollectionをCategoryに、M.AssetをCategoryにリンクするリレーションメンバーを作成し、両方でInherits Securityを有効にします。
4. コレクションとその資産を Category Aに割り当ててください。
5. collectionTestグループポリシーで、Category: Category Aの条件でM.Assetのルールを追加し、Readを有効にします。

collectionTestのユーザーは、タグ付けされたアセットのみに限定されたコレクション内のアセットを見ることができますCategory A。

アセットおよび公開リンクへの読み取り専用APIアクセスの付与

REST APIを使ってレポートプラットフォームをContent Hubに接続したいシナリオを考えてみましょう。プラットフォームはレポートを生成するためにすべてのアセットとそれに関連する公開リンクを読み取りますが、作成、変更、削除はできません。

API.ReadOnlyのような新しいユーザーグループを作成し、そのポリシーを開きます。2つのルールを追加します:

• ルール1では、 Asset (M.Asset) を選択し、 Readを有効にしてください。条件を追加しないでください。
• ルール2については、 パブリックリンク(M.PublicLink) を選択し、 Readを有効にしてください。条件を追加しないでください。

どちらのルールにも条件がないため、それぞれが定義されたすべての主体に適用されます。つまり、システム内のすべての資産およびすべての公開リンクは、このグループのメンバーによって読み取れます。

AssetToPublicLink関係に対して第三のルールは必要ありません。なぜなら、Content Hubでは権限は関係ではなくエンティティ定義に基づいて定義されているからです。ユーザーがM.AssetとM.PublicLinkの両方で権限Readを持つ場合、それらの間のAssetToPublicLink関係は自動的にAPIを通じて通過可能です。

!注Read権限はデフォルトでエンティティのすべてのプロパティへのアクセスを許可します。 メンバーセキュリティは 特定のプロパティを制限できますが、環境で明示的に設定されていない限り、完全なプロパティ読み取りに追加の設定は必要ありません。

!ヒント上記のルールはシステム内のすべての資産および公開リンクへのアクセスを許可します。実際には、統合に必要なデータのみに統合アクセスをスコープするのが良い考えです。例えば、承認済みの資産のみを処理する統合では、M.AssetルールにFinalLifeCycleStatus: Aprated条件を追加できます。同様に、特定のブランドや分類カテゴリに紐づいた資産へのスコープアクセスも可能です。スコープを制限することで、統合アカウントが本来の用途外のデータにアクセスするリスクを減らします。

このグループはAPIアクセスのみ用でブラウザUIナビゲーションを必要としないため、Portal.Pageルールは必要ありません。ポータルページの権限は、ユーザーがContent Hubインターフェースで見るもののみを制御します。統合アカウントにもUIアクセスが必要な場合は、「資産へのアクセス管理」例で説明された方法に従い、ポータルページ(Portal.Page)のルールを追加してください。

最後に、統合用の専用サービスアカウントユーザーを作成し、API.ReadOnlyグループに追加します。そのアカウントはシステム内のすべての資産と公開リンクに読み取りアクセス権を持ち、書き込み機能は一切ありません。