ドキュメントAEM 6.4管理ガイド

ユーザー、グループおよびアクセス権限の管理 user-group-and-access-rights-administration

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

作成対象：

  • Admin
CAUTION
AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

CRX リポジトリへのアクセスを有効にするには、次の複数のトピックが含まれます。

基本的な要素：

ユーザーアカウント CRX では、ユーザーアカウントに保持されている詳細情報に従って（特定の個人が、または別のアプリケーションを使用して）ユーザーを識別および検証し、アクセスを認証します。

CRX では、すべてのユーザーアカウントはワークスペース内のノードです。 CRX ユーザーアカウントには次のプロパティがあります。

  • CRX の 1 人のユーザーを表します。

  • ユーザー名とパスワードが格納されます。

  • そのワークスペースに適用できます。

  • サブユーザーを含めることはできません。 階層アクセス権の場合は、グループを使用する必要があります。

  • ユーザーアカウントのアクセス権限を指定できます。

    ただし、管理を簡略化するために、（多くの場合）グループアカウントにアクセス権限を割り当てることをお勧めします。個々のユーザーにアクセス権限を割り当てると、管理が非常に困難になります（インスタンスの数が 1 つか 2 つしかない状況におけるシステムユーザーは例外です）。

グループアカウント グループアカウントは、ユーザーまたは他のグループの集合です。グループに割り当てられたアクセス権の変更は、そのグループ内のすべてのユーザーに自動的に適用されるので、これらを使用して管理を簡略化できます。 ユーザーはどのグループにも属している必要はありませんが、多くの場合、複数のグループに属しています。

CRX では、グループには次のプロパティがあります。

  • 共通のアクセス権を持つユーザーのグループを表します。 例えば、作成者や開発者などです。

  • そのワークスペースに適用できます。

  • メンバーを持つことができます。個々のユーザーや他のグループを指定できます。

  • 階層グループ化は、メンバーの関係を使用して実現できます。 リポジトリ内の別のグループのすぐ下にグループを配置することはできません。

  • すべてのグループメンバーのアクセス権を定義できます。

アクセス権限 CRX では、アクセス権限を使用してリポジトリの特定の領域へのアクセスを制御します。

そのためには、リポジトリ内のリソース（ノードまたはパス）へのアクセスを許可または拒否する権限を割り当てます。割り当てることのできる権限は様々なので、権限を評価して、現在の要求に適用可能な組み合わせを判断する必要があります。

CRX では、ユーザーアカウントとグループアカウントの両方にアクセス権を設定できます。 その後、同じ評価の基本原則を両方に適用します。

アクセス権限の評価方法 how-access-rights-are-evaluated

NOTE
CRX 実装 JSR-283 で定義されるアクセス制御.
CRX リポジトリの標準インストールは、リソースベースのアクセス制御リストを使用するように設定されます。 これは、JSR-283 アクセス制御の実装と、Jackrabbit に存在する実装の 1 つとして考えられます。

件名とプリンシパル subjects-and-principals

CRX では、次に示す 2 つの主要な概念を使用してアクセス権限を評価します。

  • A 元本 は、アクセス権を持つエンティティです。 プリンシパルには次が含まれます。

    • ユーザーアカウント.

    • グループアカウント

      1 つ以上のグループに属しているユーザーアカウントは、それらの各グループプリンシパルにも関連付けられます。

  • サブジェクト ​は、リクエストのソースを表すために使用されます。

    リクエストに適用されるアクセス権を統合するために使用されます。これらは次の場所から取得されます。

    • ユーザープリンシパル

      ユーザーアカウントに直接割り当てる権限。

    • ユーザーに関連付けられているすべてのグループプリンシパル

      ユーザーが属するいずれかのグループに割り当てられているすべての権限。
      結果は、リクエストされたリソースへのアクセスを許可または拒否するために使用されます。

主体のアクセス権のリストのコンパイル compiling-the-list-of-access-rights-for-a-subject

CRX では、件名は次の項目に依存します。

  • ユーザープリンシパル
  • そのユーザーに関連付けられているすべてのグループプリンシパル

対象に適用されるアクセス権のリストは、次の要素から構成されます。

  • ユーザーアカウントに直接割り当てる権限
  • ユーザーが属するいずれかのグループに割り当てられているすべての権限

chlimage_1-307

NOTE
  • CRX は、リストをコンパイルする際に、ユーザー階層を考慮しません。
  • CRX では、グループを別のグループのメンバーとして含める場合にのみ、グループ階層を使用します。 グループ権限の自動継承はありません。
  • グループを指定する順序は、アクセス権に影響を与えません。

要求とアクセス権の解決 resolving-request-and-access-rights

CRX が要求を処理する際には、主体からのアクセス要求とリポジトリノード上のアクセス制御リストを比較します。

次の図は、Linda が次のリポジトリ構造内の /features ノードの更新を要求する場合の処理を示しています。

chlimage_1-308

優先順位 order-of-precedence

CRX のアクセス権は次のように評価されます。

  • ユーザープリンシパルは、以下に関係なく、常にグループプリンシパルよりも優先されます。

    • アクセス制御リスト内の順序
    • ノード階層での位置

  • 特定のプリンシパルに対して、特定のノードに deny エントリと allow エントリが（最大で）1 つ存在します。 冗長なエントリは常に実装によってクリアされ、allow エントリと deny エントリに同じ権限が示されることはありません。

NOTE
この評価プロセスは、標準の CRX インストールのリソースベースのアクセス制御に適しています。

ユーザー aUser がグループ aGroup のメンバーである 2 つの例を次に示します。

   + parentNode
     + acl
       + ace: aUser - deny - write
     + childNode
       + acl
         + ace: aGroup - allow - write
       + grandChildNode

この場合、次のようになります。

  • aUser には grandChildNode に対する書き込み権限が付与されません。
   + parentNode
     + acl
       + ace: aUser - deny - write
     + childNode
       + acl
         + ace: aGroup - allow - write
         + ace: aUser - deny - write
       + grandChildNode

この場合の解決策は、次のとおりです。

  • aUser には grandChildNode に対する書き込み権限が付与されません。

  • aUser の 2 つ目の ACE は冗長になります。

複数のグループプリンシパルからのアクセス権は、階層内と単一のアクセス制御リスト内の順序に基づいて評価されます。

ベストプラクティス best-practices

いくつかの推奨事項とベストプラクティスを次の表に示します。

推奨...
理由...
グループを使用する

アクセス権をユーザーごとに割り当てないようにします。 これには、いくつかの理由があります。

  • グループよりも多くのユーザーがいるので、グループを使用すると構造が簡単になります。
  • グループは、すべてのアカウントの概要を示すのに役立ちます。
  • グループを使用すると、継承が簡単になります。
  • ユーザーが来たり来たりします。 グループは長期的なものです。
ポジティブに

常に Allow ステートメントを使用して、グループプリンシパルのアクセス権を指定します（可能な場合）。 「拒否」ステートメントの使用は避けてください。

グループプリンシパルは、階層内でも、単一のアクセス制御リスト内でも順番に評価されます。

シンプルに

新しいインストールの設定時にある程度時間をかけて検討すると、より良い設定となります。

明確な構造を適用すると、継続的なメンテナンスと管理が簡単になり、現在の同僚や将来の後継者が実装されている内容を容易に理解できるようになります。

テスト
練習のためのテストインストールを利用して、様々なユーザーとグループ間の関係を把握してください。
デフォルトのユーザー／グループ
セキュリティ上の問題を防ぐため、インストール直後に必ずデフォルトのユーザーとグループを更新してください。

ユーザー管理 user-administration

標準ダイアログは​ ユーザー管理 ​に使用されます。

適切なワークスペースにログインする必要があります。その後、次の両方からダイアログにアクセスできます。

  • の ユーザー管理 CRX のメインコンソールのリンク
  • の セキュリティ CRX Explorer のメニュー

chlimage_1-309

プロパティ

  • UserID
    CRX へのアクセス時に使用される、アカウントの短い名前。

  • プリンシパル名
    アカウントのフルテキスト名。

  • パスワード
    このアカウントで CRX にアクセスする際に必要です。

  • ntlmhash
    新しいアカウントごとに自動的に割り当てられ、パスワードが変更されると更新されます。

  • 名前、タイプ、値を定義して新しいプロパティを追加できます。新しいプロパティごとに「保存」（緑色のチェックマーク）をクリックします。

グループのメンバーシップ ​アカウントが属しているすべてのグループが表示されます。「継承」列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。

グループ ID（使用可能な場合）をクリックすると、そのグループ用のグループ管理が開きます。

実行 ​別のユーザーとして実行する機能では、ユーザーは別のユーザーに成り代わって作業を行うことができます。

これは、あるユーザーアカウントが操作を行うための他のアカウント（ユーザーまたはグループ）を指定できることを意味します。つまり、ユーザー B がユーザー A として実行することを許可されている場合、ユーザー B はユーザー A のアカウントの詳細（ID、名前、アクセス権限を含む）をすべて使用してアクションを実行できます。

これにより、別のユーザーアカウントが、別のユーザーとして実行しているアカウントを使用している場合と同様に、タスクを完了できます。例えば、不在時や過剰な負荷を短期間共有する場合などです。

アカウントが別のアカウントになりすます場合、表示は非常に困難です。 ログファイルには、イベントで偽装が発生したことに関する情報は含まれません。 したがって、ユーザー B がユーザー A として実行している場合、すべてのイベントは、ユーザー A が個人的に実行したかのように見えます。

ユーザーアカウントの作成 creating-a-user-account

  1. を開きます。 ユーザー管理 ダイアログ。

  2. 「ユーザーを作成」をクリックします。

  3. 次のプロパティを入力できます。

    • ユーザー ID：アカウント名として使用されます。
    • パスワード：ログイン時に必要です。
    • プリンシパル名：完全な名前を指定します。
    • 中間パス：ツリー構造を作成するために使用できます。

  4. 保存（緑色のチェックマーク）をクリックします。

  5. ダイアログが展開され、次の操作が可能になります。

    1. 設定 プロパティ.
    2. 「グループのメンバーシップ」を確認します。
    3. 定義 実行.
NOTE
次の両方が多数あるインストールで新しいユーザーを登録すると、パフォーマンスが低下する場合があります。
  • ユーザー
  • 多数のメンバーを持つグループ

ユーザーアカウントの更新 updating-a-user-account

  1. ユーザー管理 ​ダイアログで、すべてのアカウントのリスト表示を開きます。

  2. ツリー構造内を移動します。

  3. 編集用に開く必要のあるアカウントをクリックします。

  4. 変更を加え、そのエントリの保存（緑のチェックマーク）をクリックします。

  5. クリック 閉じる 終了するか、または リスト… をクリックして、すべてのユーザーアカウントのリストに戻ります。

ユーザーアカウントの削除 removing-a-user-account

  1. ユーザー管理 ​ダイアログで、すべてのアカウントのリスト表示を開きます。

  2. ツリー構造内を移動します。

  3. 必要なアカウントを選択し、 ユーザーを削除;アカウントは直ちに削除されます。

NOTE
これにより、このプリンシパルのノードがリポジトリから削除されます。
アクセス権限のエントリは削除されません。これにより、履歴の整合性が確保されます。

プロパティの定義 defining-properties

次の項目を定義できます。 プロパティ 新規または既存のアカウントの場合：

  1. を開きます。 ユーザー管理 適切なアカウントのダイアログ。
  2. を定義 プロパティ 名前。
  3. を選択します。 タイプ 」を選択します。
  4. 次を定義： 値.
  5. 新しいプロパティの [ 保存 ] （緑のクリック記号）をクリックします。

既存のプロパティは、ごみ箱シンボルで削除できます。

パスワードを除き、プロパティは編集できません。削除して再作成する必要があります。

パスワードの変更 changing-the-password

この パスワード は、 パスワードを変更 リンク。

また、 セキュリティ 」メニューを使用します。

偽装の定義 defining-an-impersonator

次のように、新規または既存のアカウントに対して次のように実行を定義できます。

  1. を開きます。 ユーザー管理 適切なアカウントのダイアログ。

  2. 別のユーザーとして実行を許可するアカウントを指定します。

    「参照…」を使用して、既存のアカウントを選択できます。

  3. 新しいプロパティの [ 保存 ] （緑のチェックマーク）をクリックします。

グループ管理 group-administration

標準ダイアログは、 グループ管理.

適切なワークスペースにログインする必要があります。その後、次の両方からダイアログにアクセスできます。

  • の グループ管理 CRX のメインコンソールのリンク
  • の セキュリティ CRX Explorer のメニュー

chlimage_1-47

プロパティ

  • GroupID
    グループアカウントの省略名。

  • プリンシパル名
    グループアカウントのフルテキスト名。

  • 名前、タイプ、値を定義して新しいプロパティを追加できます。新しいプロパティごとに「保存」（緑色のチェックマーク）をクリックします。

  • メンバー
    ユーザーや他のグループを、このグループのメンバーとして追加できます。

グループメンバーシップ 現在のグループアカウントが属するすべてのグループが表示されます。 「継承」列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。

グループ ID をクリックすると、そのグループ用のダイアログが開きます。

メンバー 現在のグループのメンバーであるすべてのアカウント（ユーザーまたはグループ）が一覧表示されます。

この 継承 列は、別のグループのメンバーシップの結果として継承されたメンバーシップを示します。

NOTE
いずれかのアセットフォルダーでユーザーに対して所有者、編集者または閲覧者の役割が割り当てられると、新しいグループが作成されます。役割が定義された各フォルダーのグループ名は mac-default-<foldername> の形式となります。

グループアカウントの作成 creating-a-group-account

  1. を開きます。 グループ管理 ダイアログ。

  2. クリック グループを作成.

  3. 次のプロパティを入力できます。

    • プリンシパル名：完全な名前を指定します。
    • 中間パス：ツリー構造を作成するために使用できます。

  4. 保存（緑色のチェックマーク）をクリックします。

  5. ダイアログが展開され、次の操作が可能になります。

    1. 設定 プロパティ.
    2. 「グループのメンバーシップ」を確認します。
    3. 管理 メンバー.

グループアカウントの更新 updating-a-group-account

  1. グループ管理 ​ダイアログで、すべてのアカウントのリスト表示を開きます。

  2. ツリー構造内を移動します。

  3. 編集用に開く必要のあるアカウントをクリックします。

  4. 変更を加え、そのエントリの保存（緑のチェックマーク）をクリックします。

  5. クリック 閉じる 終了するか、または リスト… をクリックして、すべてのグループアカウントのリストに戻ります。

グループアカウントの削除 removing-a-group-account

  1. グループ管理ダイアログ ​で、すべてのアカウントのリスト表示を開きます。

  2. ツリー構造内を移動します。

  3. 必要なアカウントを選択し、 グループを削除;アカウントは直ちに削除されます。

NOTE
これにより、このプリンシパルのノードがリポジトリから削除されます。
アクセス権限のエントリは削除されません。これにより、履歴の整合性が確保されます。

プロパティの定義 defining-properties-1

新規または既存のアカウントのプロパティを定義できます。

  1. を開きます。 グループ管理 適切なアカウントのダイアログ。
  2. を定義 プロパティ 名前。
  3. を選択します。 タイプ 」を選択します。
  4. 次を定義： 値.
  5. 新しいプロパティの [ 保存 ] （緑のチェックマーク）をクリックします。

既存のプロパティは、ごみ箱シンボルで削除できます。

メンバー members

現在のグループにメンバーを追加できます。

  1. を開きます。 グループ管理 適切なアカウントのダイアログ。

  2. 以下のどちらかの操作を行います。

    • 必要なメンバーの名前（ユーザーまたはグループアカウント）を入力します。
    • または、 参照… 追加するプリンシパル（ユーザーまたはグループアカウント）を検索して選択します。

  3. 新しいプロパティの [ 保存 ] （緑のチェックマーク）をクリックします。

または、ごみ箱記号を含む既存のメンバを削除します。

アクセス権限の管理 access-right-management

CRXDE Lite の「アクセス制御」タブを使用して、アクセス制御ポリシーを定義し、関連する権限を割り当てることができます。

例えば、右下のウィンドウの「アクセス制御」タブにある「現在のパス」では、必要なリソースを左側のウィンドウで選択します。

crx_accesscontrol_tab

ポリシーは次のように分類されます。

  • 適用可能なアクセス制御ポリシー ​これらのポリシーは適用できます。

    これらのポリシーは、ローカルポリシーの作成に使用できます。適用可能なポリシーを選択して追加すると、そのポリシーがローカルポリシーになります。

  • ローカルアクセス制御ポリシー ​これらは、適用したアクセス制御ポリシーです。このポリシーの更新、並べ替えまたは削除を行うことができます。

    親から継承したポリシーはローカルポリシーによって上書きされます。

  • 有効なアクセス制御ポリシー ​アクセス要求に対して有効なアクセス制御ポリシーです。ローカルポリシーおよび親から継承したポリシーから派生した集計ポリシーが表示されます。

ポリシーの選択 policy-selection

次の項目用のポリシーを選択できます。

  • 現在のパス ​前述の例では、リポジトリ内のリソースを選択します。この「現在のパス」用のポリシーが表示されます。

  • リポジトリ ​リポジトリレベルのアクセス制御を選択します。例えば、
    jcr:namespaceManagement 権限。ノードではなく、リポジトリにのみ関連します。

  • プリンシパル
    リポジトリに登録されているプリンシパルです。

    プリンシパル ​名を入力するか、フィールドの右側にあるアイコンをクリックして、プリンシパルを選択 ​ダイアログを開きます。

    これにより、ユーザー ​または​ グループ ​を​ 検索 ​できます。表示されるリストから必要なプリンシパルを選択し、「OK」をクリックして値を前のダイアログに戻します。

crx_accesscontrol_selectprincipal

NOTE
管理を簡素化するには、個々のユーザーアカウントではなく、グループアカウントにアクセス権を割り当てることをお勧めします。
多数のユーザーアカウントよりも、少数のグループを管理するほうが簡単です。

権限 privileges

アクセス制御エントリを追加する場合は、以下に示す権限を選択できます（詳しくは、セキュリティ API に関するページを参照）。

権限名
制御する権限
jcr:read
ノードを取得して、そのプロパティと値を読み取ります。
rep:write
jcr:write および jcr:nodeTypeManagement の Jackrabbit 専用の集計権限です。
jcr:all
他の事前定義済み権限がすべて含まれる集計権限です。
詳細
crx:replicate
ノードのレプリケーションを実行します。
jcr:addChildNodes
ノードの子ノードを作成します。
jcr:lifecycleManagement
ノード上でライフサイクル操作を実行します。
jcr:lockManagement
ノードをロックおよびロック解除します。ロックを更新します。
jcr:modifyAccessControl
ノードのアクセス制御ポリシーを変更します。
jcr:modifyProperties
ノードのプロパティを作成、変更および削除します。
jcr:namespaceManagement
名前空間の定義を登録、登録解除および変更します。
jcr:nodeTypeDefinitionManagement
ノードタイプ定義をリポジトリに読み込みます。
jcr:nodeTypeManagement
mixin ノードタイプを追加および削除し、ノードのプライマリノードタイプを変更します。 また、Node.addNode および XML インポートメソッドの呼び出しも含まれ、mixin または新しいノードのプライマリ型が明示的に指定されます。
jcr:readAccessControl
ノードのアクセス制御ポリシーを読み取ります。
jcr:removeChildNodes
ノードの子ノードを削除します。
jcr:removeNode
ノードを削除します。
jcr:retentionManagement
ノード上で保持管理操作を実行します。
jcr:versionManagement
ノード上でバージョン管理操作を実行します。
jcr:workspaceManagement
JCR API によるワークスペースの作成と削除。
jcr:write
次の権限が含まれる集計権限です。
​- jcr:modifyProperties
​- jcr:addChildNodes
​- jcr:removeNode
​- jcr:removeChildNodes
rep:privilegeManagement
新しい権限を登録します。

新しい権限の登録 registering-new-privileges

新しい権限を登録することもできます。

  1. ツールバーから「ツール」を選択し、「権限」を選択して、現在登録されている権限を表示します。

    ac_privileges

  2. 権限を登録 ​アイコン（+）を使用してダイアログを開き、新しい権限を定義します。

    ac_privilegeregister

  3. 「OK」をクリックして保存します。これで、権限を選択できるようになります。

アクセス制御エントリの追加 adding-an-access-control-entry

  1. リソースを選択して「アクセス制御」タブを開きます。

  2. 新しい​ ローカルアクセス制御ポリシー ​を追加するには、「適用可能なアクセス制御ポリシー」リストの右側にある + アイコンをクリックします。

    crx_accesscontrol_applicable

  3. 新しいエントリが「「ローカルアクセス制御ポリシー」の下に表示されます。。

    crx_accesscontrol_newlocal

  4. + アイコンをクリックして新しいエントリを追加します。

    crx_accesscontrol_addentry

    note note
    NOTE
    現時点では、空の文字列を指定するには対策が必要です。
    "" を使用してください。

  5. アクセス制御ポリシーを定義し、 OK 保存します。 新しいポリシーでは、次のことが行われます。

    • 「ローカルアクセス制御ポリシー」の下に表示されます。
    • 「有効なアクセス制御ポリシー」に変更が反映されます。

CRX が選択を検証します。特定のプリンシパルに対しては、特定のノードに deny エントリと allow エントリが（最大で）1 つ存在します。 冗長なエントリは常に実装によってクリアされ、allow エントリと deny エントリに同じ権限が示されることはありません。

ローカル・アクセス制御ポリシーの順序付け ordering-local-access-control-policies

リスト内の順序は、ポリシーの適用順序を示します。

  1. 「ローカルアクセス制御ポリシー」のテーブルで必要なエントリを選択して、テーブル内の新しい位置にドラッグします。

    crx_accesscontrol_reorder

  2. 「ローカルアクセス制御ポリシー」と「有効なアクセス制御ポリシー」のテーブルの両方に変更が表示されます。

アクセス制御ポリシーの削除 removing-an-access-control-policy

  1. 「ローカルアクセス制御ポリシー」のテーブルで、エントリの右側にある赤いアイコン（-）をクリックします。

  2. 「ローカルアクセス制御ポリシー」と「有効なアクセス制御ポリシー」のテーブルの両方からエントリが削除されます。

アクセス制御ポリシーのテスト testing-an-access-control-policy

  1. CRXDE Lite のツールバーから「ツール」、「アクセス制御をテスト」の順に選択します。

  2. 右上のウィンドウに新しいダイアログが開きます。テストする​ パス ​または​ プリンシパル ​を選択します。

  3. 「テスト」をクリックして選択項目の結果を確認します。

    crx_accesscontrol_test

recommendation-more-help
5ce3024a-cbea-458b-8b2f-f9b8dda516e8