1. ユーザー・ガイドforリリース3.0.2
  2. Identity and Access Management
機械翻訳について

2 Identity and Access Management

Oracle Private Cloud Appliance Identity and Access Management (IAM)では、テナンシのどのクラウド・リソースにどのユーザーがどのアクセス権を持つかを制御できます。

概念の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」を参照してください。

ユーザー・アカウントの作成および管理

デフォルトでは、テナンシは管理者グループに管理ユーザーを持ち、ポリシーによって管理者グループがテナンシを管理できます。 ユーザーがテナンシまたは別のコンパートメント内のリソースのサブセットのみを管理するように制限する場合、または一部のリソースへのフル・マネジメント・アクセス権未満にユーザーを制限するには、ユーザー・アカウントを作成し、1つ以上のグループにユーザー・アカウントを追加し、それらのグループに1つ以上のポリシーを作成します。

ユーザー・アカウントは、自動的にどのグループのメンバーでもありません。 どのグループのメンバーでもないユーザーはテナンシに表示されますが、どのリソースにもアクセスできません。

ユーザー・アカウントおよびグループの概念の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」を参照してください。

ユーザーの作成

ユーザーを作成すると、そのユーザーはテナンシに自動的に作成されます。 ユーザーに対して別のコンパートメントを指定することはできません。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

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

  3. 「ユーザーの作成」ダイアログで、次の情報を入力します:

    • 名前: このユーザー・アカウントの名前。 ユーザー名には次の特性があります:

      • テナンシ内で一意である必要があります。 削除されたユーザーと同じ名前のユーザーを作成できます。

      • 大文字と小文字は区別されません。

      • 後で変更できません。

      • 少なくとも2文字以上100文字以下である必要があります。

      • 英数字、ピリオド(.)、ハイフン(-)、アンダースコア(_)、プラス記号(+)およびアットマーク(@)のみを使用できます。

    • 摘要: 個人の氏名やアカウントの簡単な説明など、このユーザーの説明。 説明には次の特性があります:

      • 1-400文字にする必要があります。

      • 一意である必要はありません。

      • 後で変更できます。

    • 電子メール・アドレス: (オプション)ユーザーの電子メール・アドレス。 後で更新できます。

    • パスワード: (オプション)このユーザーがコンピュートWeb UIにログインできるようにするには、「このユーザーの一時パスワードの生成」というラベルのボックスにチェックマークを入れます。

      パスワードは後で指定できます。 「一時コンピュートWeb UIパスワードの指定」を参照してください。

      ノート:

      フェデレーテッド・ユーザーのパスワードはこのサービスを介して管理されません。 フェデレーテッド・アイデンティティ・プロバイダの情報を参照してください。

    • タグ付け: (オプション) リソース作成時のタグの追加の説明に従って、このユーザー・アカウントの定義済タグまたはフリー・フォーム・タグを追加します。 タグは後で適用することもできます。

  4. 「ユーザーの作成」ダイアログで「ユーザーの作成」ボタンをクリックします。

    「このユーザーの一時パスワードの生成」というラベルの付いたボックスを選択した場合は、「新規ユーザー」ダイアログの一時パスワードが表示され、一時パスワードが表示されます。 このダイアログを閉じた後は、このパスワードを再度取得できません。 一時パスワードをコピーし、ユーザーに配信するための安全な場所にパスワードを保存し、"I have made a note of the password"ボタンをクリックします。

    新しいユーザーの詳細ページが表示されます。

    次のステップ:

    • ユーザーが独自の永続「コンピュートWeb UI」パスワードを設定できるように、ユーザーに一時パスワードを指定します。

      • 「このユーザーの一時パスワードの生成」というラベルが付いたボックスを選択した場合は、「新規ユーザー」の一時パスワード」ダイアログからコピーした一時パスワードを指定します。

      • 「このユーザーの一時パスワードを生成」というラベルのボックスにチェックマークを付けなかったか、そのパスワードを保存しなかった場合は、「一時コンピュートWeb UIパスワードの指定」の手順に従ってユーザーの一時パスワードを生成します。

    • このユーザーを少なくとも1つのグループに追加します。 「ユーザーの更新によるグループへのユーザーの追加」を参照してください。

    • ユーザーがOCI CLIを使用する場合は、「OCI CLIのインストール」を参照してください。

OCI CLIの使用

  1. 次の情報を取得します:

    • ユーザーの名前と説明。 パラメータについては、「コンピュートWeb UI」プロシージャを参照してください。 OCI CLIでは説明を指定する必要がありますが、値は空の文字列にできます。

    • (オプション)ユーザーのテナンシのOCID。 デフォルトでは、構成ファイルのルート・コンパートメントOCIDが使用されます。

  2. ユーザーcreateコマンドを実行します。

    構文:

    oci iam user create --name text --description text

    名前および説明の値の特性については、「コンピュートWeb UI」プロシージャを参照してください。 定義済タグおよびフリー・フォーム・タグを追加するには、「リソース作成時のタグの追加」を参照してください。

    例:

    $ oci iam user create --name flast --description "First Last" --email first.last@example.com

    このコマンドの出力は、user getコマンドの出力と同じです。

    次のステップ:

一時的な「コンピュートWeb UI」パスワードの指定

新規ユーザーおよびパスワードを忘れたユーザーに対して、この手順を実行します。 この手順では、一時ワンタイム・パスワードを生成します。 ユーザーがこのパスワードを使用してサインインすると、続行する前にパスワードを変更する必要があります。 生成された一時パスワードは7日後に期限切れになります。

テナンシ管理者は、任意のユーザーに一時パスワードを指定できます。 ユーザーは、「独自のコンピュートWeb UIパスワードの設定」の手順に従って、独自の永続パスワードを設定する必要があります。

ノート:

フェデレーテッド・ユーザーのパスワードは、IAMサービスを介して管理されません。 フェデレーテッド・アイデンティティ・プロバイダの情報を参照してください。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

  2. 新しいパスワードが必要なユーザーに対して、アクション・メニューをクリックし、「パスワードの変更」オプションをクリックします。

  3. 「パスワードの変更」ダイアログで、一時パスワードの作成ボタンをクリックします。

    「パスワードが変更されました」ダイアログがポップアップします。 「新しいパスワード」フィールドには、一時パスワードが含まれます。

  4. この一時パスワードをコピーして保存します。

    このダイアログを閉じた後は、このパスワードを再度取得できません。 一時パスワードをコピーし、ユーザーに配信するための安全な場所にパスワードを保存します。

  5. ダイアログの閉じるボタンをクリックします。

  6. この一時的なワンタイム・パスワードをユーザーに提供します。 ユーザーは、新しいパスワードを設定するときに、「独自のコンピュートWeb UIパスワードの設定」に記載されているルールに従う必要があります。

OCI CLIの使用

  1. パスワードが必要なユーザーのOCID (oci iam user list)を取得します。

  2. ユーザー「コンピュートWeb UI」 password createまたはresetコマンドを実行します。

    例:

    $ oci iam user ui-password create-or-reset --user-id ocid1.user.unique_ID
{
  "data": {
    "inactive-status": null,
    "lifecycle-state": "ACTIVE",
    "password": "N59%fP9uTq6\\",
    "time-created": "2021-10-13T22:10:49.290000+00:00",
    "user-id": "ocid1.user.unique_ID"
  }
}

  3. コマンド出力からpassword値をコピーし、この一時的なワンタイム・パスワードをユーザーに提供します。 ユーザーは、新しいパスワードを設定するときに、「独自のコンピュートWeb UIパスワードの設定」に記載されているルールに従う必要があります。

自分の「コンピュートWeb UI」パスワードの設定

ユーザーは、独自の「コンピュートWeb UI」パスワードを設定または変更するためのアクセス・ポリシーを必要としません。

パスワードの設定

この手順を使用して、最初に「コンピュートWeb UI」パスワードを設定するか、パスワードを忘れた場合はパスワードをリセットします。

「コンピュートWeb UI」の使用

  1. 生成された一時パスワードを取得します。

  2. 「コンピュートWeb UI」のログイン画面で、ユーザー名を入力します。

  3. 一時パスワードを入力します。

    パスワードの有効期限が切れており、新しいパスワードを作成する必要があることを示すダイアログが表示されます。

  4. Change my passwordボタンをクリックします。

  5. 「パスワードの変更」画面で、「現在のパスワード」フィールドに一時パスワードを入力します。

  6. 「新規パスワード」フィールドに新しいパスワードを入力し、Confirm「新規パスワード」フィールドに再度入力します。

    パスワードは12文字以上で、次のそれぞれが少なくとも1つ含まれている必要があります: 大文字、小文字、数字および記号。

  7. Save Changesボタンをクリックします。

    パスワードが正常に更新されたことを示すダイアログが表示されます。

  8. 「続行」ボタンをクリックします。

  9. 新しいパスワードを使用してログインします。

パスワードの変更

現在のパスワードがまだ機能している間に「コンピュートWeb UI」パスワードを変更するには、この手順を使用します。

「コンピュートWeb UI」の使用

  1. 「コンピュートWeb UI」の右上隅で、ユーザー・メニューをクリックします。

  2. 「パスワード変更」をクリックします

  3. 「パスワードの変更」画面で、「現在のパスワード」フィールドに現在のパスワードを入力します。

  4. 「新規パスワード」フィールドに新しいパスワードを入力し、Confirm「新規パスワード」フィールドに再度入力します。

    パスワードは12文字以上で、次のそれぞれが少なくとも1つ含まれている必要があります: 大文字、小文字、数字および記号。

  5. Save Changesボタンをクリックします。

    パスワードが正常に更新されたことを示すダイアログが表示されます。

  6. 「続行」ボタンをクリックします。

ユーザー情報およびグループ・メンバーシップの表示

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

    「ユーザー」ページには、ユーザー・アカウントを異なるコンパートメントに配置できないため、テナンシのすべてのユーザーが表示されます。 すべてのユーザーがテナンシ内にあります。

  2. 詳細情報を表示するユーザーの名前をクリックします。

  3. そのユーザー・アカウントの詳細ページで、Resourcesセクションまでスクロール・ダウンします。

  4. グループ・リソースをクリックします。

    このユーザーがメンバーであるグループのリストが表示されます。

  5. グループのメンバーの完全なリストを表示するには、グループ・リストでグループの名前をクリックします。

    そのグループのResourcesセクションまでスクロールし、Group Membersをクリックします。

OCI CLIの使用

  1. グループのリストが必要なユーザー・アカウントのOCID (oci iam user list)を取得します。

  2. list groupコマンドを実行します。

    構文:

    oci iam user list-groups --user-id user_OCID

    list-groupsコマンドの出力は、このユーザーがメンバーである各グループのgroup getコマンドの出力と同じです。

    user getコマンドは、グループ・メンバーシップを表示しません。

ユーザーの更新によるグループへのユーザーの追加

ユーザーがリソースにアクセスできるようにするには、少なくとも1つのグループのメンバーである必要があります。

「コンピュートWeb UI」の使用

ユーザー「コンピュートWeb UI」ページを使用するかわりに、「グループの更新によるグループへのユーザーの追加」の説明に従ってグループ・ページを使用できます。

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

  2. グループに追加するユーザーの名前をクリックします。

  3. 詳細ページで、リソース・セクションまでスクロール・ダウンし、グループをクリックします。

  4. グループ・リストの上部にあるユーザーをグループに追加ボタンをクリックします。

  5. ユーザーをグループに追加ダイアログで、ドロップダウン・リストからグループを選択し、OKボタンをクリックします。

    選択したグループがユーザー・グループ・リストに追加されます。

OCI CLIの使用

  1. OCI CLIプロシージャについては、「グループの更新によるグループへのユーザーの追加」を参照してください。

  2. user list-groupsコマンドを使用して、このユーザーがメンバーであるグループを表示します。 user list-groupsコマンドの出力は、このユーザーがメンバーである各グループのgroup getコマンドの出力と同じです。

ユーザーの更新によるグループからのユーザーの削除

すべてのグループからユーザーを削除すると、ユーザーはどのリソースにもアクセスできません。

「コンピュートWeb UI」の使用

ユーザー「コンピュートWeb UI」ページを使用するかわりに、「グループの更新によるグループからのユーザーの削除」の説明に従ってグループ・ページを使用できます。

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

  2. グループから削除するユーザーの名前をクリックします。

  3. Resourcesセクションまでスクロールし、Groupsをクリックします。

  4. ユーザーを削除するグループに対して、アクション・メニューをクリックし、グループから削除オプションをクリックします。

    選択したグループがユーザー・グループ・リストから削除されます。

OCI CLIの使用

  1. OCI CLIプロシージャについては、「グループの更新によるグループからのユーザーの削除」を参照してください。

  2. user list-groupsコマンドを使用して、このユーザーがメンバーであるグループを表示します。 user list-groupsコマンドの出力は、このユーザーがメンバーである各グループのgroup getコマンドの出力と同じです。

ユーザーの変更

ユーザー・アカウントの説明および電子メール・アドレスを変更できます。 「既存のリソースへのタグの適用」の説明に従って、タグを追加、変更または削除できます。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

  2. 変更するユーザー・アカウントについて、アクション・メニューをクリックし、編集オプションをクリックします。

  3. usernameの編集ダイアログで、アカウントの説明、電子メール・アドレスまたはタグを変更します。

  4. 「変更の保存」をクリックします。

OCI CLIの使用

  1. 変更するユーザー・アカウントのOCID (oci iam user list)を取得します。

  2. ユーザー更新コマンドを実行します。

    構文:

    oci iam user update --user-id user_OCID [ --description desc ] \
[ --email email ] [ --defined-tags tags ] [ --freeform-tags tags ]

    このコマンドの出力は、user getコマンドの出力と同じです。

ユーザーの削除

ユーザーが任意のグループのメンバーである場合は、ユーザーを削除できません。 自分のユーザーは削除できません。

ユーザーを削除すると、そのユーザー・アカウントに関連付けられているすべてのAPIキーも削除されます。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ユーザーをクリックします。

  2. 削除するユーザーの名前をクリックします。

  3. ユーザーがどのグループのメンバーでもないことを確認します。

    ユーザーの詳細ページで、リソース・セクションまでスクロール・ダウンし、グループをクリックします。 このユーザーをグループから削除するには、グループ・リストのグループのアクション・メニューをクリックし、グループから削除オプションをクリックします。

  4. ユーザー詳細ページの上部にある削除ボタンをクリックします。

  5. Delete User確認ダイアログで、Confirmボタンをクリックします。

OCI CLIの使用

  1. 削除するユーザー・アカウントのOCID (oci iam user list)を取得します。

  2. user list-groupsコマンドを使用して、ユーザーがどのグループのメンバーでもないことを確認します。

  3. ユーザー削除コマンドを実行します。

    構文:

    oci iam user delete --user-id user_OCID

    例:

    $ oci iam user delete --user-id ocid1.user.unique_ID
Are you sure you want to delete this resource? [y/N]: y

    確認せずにユーザーを削除するには、--forceオプションを使用します。

ユーザー・グループの作成と管理

クラウド・リソースへのアクセスは、ユーザーに直接付与されるのではなく、グループに付与されます。 ユーザー・アカウントは、自動的にどのグループのメンバーでもありません。 ユーザーがクラウド・リソースを操作できるようにするには、ユーザーをグループに追加し、そのグループのアクセス・ポリシーを作成する必要があります。 したがって、グループは、同じクラウド・リソースのセットに対して同じタイプのアクセス権を持つユーザーのセットです。 アクセスする必要があるコンパートメントとリソース、およびそれらのリソースを操作する方法に応じて、ユーザーをグループに編成します。 1人のユーザーが複数のグループのメンバーになることができます。

ユーザー・アカウントおよびグループの概念の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」を参照してください。

グループの作成

グループを作成すると、そのグループはテナンシに自動的に作成されます。 グループに別のコンパートメントを指定することはできません。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティ、グループの順にクリックします。

  2. グループの作成ボタンをクリックします。

  3. 「グループの作成」ダイアログで、次の情報を入力します:

    • 名前: このグループの名前。 グループ名には次の特性があります:

      • テナンシ内で一意である必要があります。 削除されたグループと同じ名前のグループを作成できます。

      • 大文字と小文字は区別されません。

      • 後で変更できません。

      • 100文字以下にしてください。

      • 英数字、ピリオド(.)、ハイフン(-)およびアンダースコア(_)のみを含めることができます。

    • 摘要: このグループの説明。 説明には次の特性があります:

      • 1-400文字にする必要があります。

      • 一意である必要はありません。

      • 後で変更できます。

    • タグ付け: (オプション) リソース作成時のタグの追加の説明に従って、このグループの定義済タグまたはフリー・フォーム・タグを追加します。 タグは後で適用することもできます。

  4. 「グループの作成」ダイアログで「グループの作成」ボタンをクリックします。

    新しいグループの詳細ページが表示されます。

    次のステップ:

OCI CLIの使用

  1. 次の情報を取得します:

    • グループの名前と説明。 制限事項については、「コンピュートWeb UI」プロシージャを参照してください。 OCI CLIでは説明を指定する必要がありますが、値は空の文字列にできます。

    • (オプション)グループのテナンシのOCID。 デフォルトでは、構成ファイルのルート・コンパートメントOCIDが使用されます。

  2. グループcreateコマンドを実行します。

    構文:

    oci iam group create --name text --description "text"

    名前および説明の値の特性については、「コンピュートWeb UI」プロシージャを参照してください。 定義済タグおよびフリー・フォーム・タグを追加するには、「リソース作成時のタグの追加」を参照してください。

    例:

    $ oci iam group create --name Product-A --description "Resource management for Product A."

    このコマンドの出力は、group getコマンドの出力と同じです。

    次のステップ:

グループ情報とグループ・メンバーの表示

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティ、グループの順にクリックします。

    グループ定義は異なるコンパートメントに存在できないため、「グループ」ページにテナンシ内のすべてのグループが表示されます。 すべてのグループはテナンシ内にあります。

  2. 詳細情報を表示するグループの名前をクリックします。

  3. そのグループの詳細ページで、Resourcesセクションまでスクロール・ダウンします。

  4. グループ・メンバー・リソースをクリックします。

    このグループに属するユーザーのリストが表示されます。

  5. ユーザーがメンバーであるグループの完全なリストを表示するには、グループ・メンバー・リストでユーザーの名前をクリックします。

    そのユーザーのResourcesセクションまでスクロールし、Groupsをクリックします。

OCI CLIの使用

  1. ユーザーのリストを必要とするグループのOCID (oci iam group list)を取得します。

  2. list usersコマンドを実行します。

    構文:

    oci iam group list-users --group-id group_OCID

    list-usersコマンドの出力は、このグループのメンバーである各ユーザーのuser getコマンドの出力と同じです。

    group getコマンドはメンバー・ユーザーを表示しません。

グループの更新によるグループへのユーザーの追加

リソースにアクセスできるようにするには、ユーザーがグループのメンバーである必要があります。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティ、グループの順にクリックします。

  2. ユーザーを追加するグループの名前をクリックします。

  3. 詳細ページで、リソース・セクションまでスクロールし、グループ・メンバーをクリックします。

  4. グループ・メンバー・リストの上部にあるユーザーをグループに追加ボタンをクリックします。

  5. ユーザーをグループに追加ダイアログで、ドロップダウン・リストからユーザーを選択し、OKボタンをクリックします。

    選択したユーザーがグループ・メンバー・リストに追加されます。

OCI CLIの使用

  1. 次の情報を取得します:

    • ユーザーを追加するグループのOCID (oci iam group list)。

    • このグループに追加するユーザーのOCID (oci iam user list)。

  2. グループadd userコマンドを実行します。

    構文:

    oci iam group add-user --group-id group_OCID --user-id user_OCID

    例:

    $ oci iam group add-user --group-id ocid1.group.unique_ID --user-id ocid1.user.unique_ID
{
  "data": {
    "compartment-id": "ocid1.tenancy.unique_ID",
    "group-id": "ocid1.group.unique_ID",
    "id": "ocid1.user_group_membership.unique_ID",
    "inactive-status": null,
    "lifecycle-state": "ACTIVE",
    "time-created": null,
    "user-id": "ocid1.user.unique_ID"
  }
}

グループの更新によるグループからのユーザーの削除

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティ、グループの順にクリックします。

  2. ユーザーを削除するグループの名前をクリックします。

  3. 詳細ページで、リソース・セクションまでスクロールし、グループ・メンバーをクリックします。

  4. グループ・メンバー・リストで、グループから削除するユーザーのアクション・メニューをクリックし、グループから削除オプションをクリックします。

  5. 確認プロンプトで、「OK」です。

    ユーザーがグループから削除されます。

OCI CLIの使用

  1. 次の情報を取得します:

    • ユーザーを削除するグループのOCID (oci iam group list)。

    • グループから削除するユーザーのOCID (oci iam user list)。

  2. group remove userコマンドを実行します。

    構文:

    oci iam group remove-user --group-id group_OCID --user-id user_OCID

グループの変更

グループの説明は変更できます。 「既存のリソースへのタグの適用」の説明に従って、タグを追加、変更または削除できます。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティ、グループの順にクリックします。

  2. 変更するグループのアクション・メニューをクリックし、編集オプションをクリックします。

  3. 「グループ名」の編集ダイアログで、グループの説明またはタグを変更します。

  4. 「変更の保存」をクリックします。

OCI CLIの使用

  1. 変更するグループのOCID (oci iam group list)を取得します。

  2. グループ更新コマンドを実行します。

    構文:

    oci iam group update --group-id group_OCID [ --description desc ] \
[ --defined-tags tags ] [ --freeform-tags tags ]

    このコマンドの出力は、group getコマンドの出力と同じです。

グループの削除

グループにメンバーがある場合、グループを削除できません。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティ、グループの順にクリックします。

  2. 削除するグループの名前をクリックします。

  3. グループにメンバーがいないことを確認します。

    グループ詳細ページで、リソース・セクションまでスクロール・ダウンし、グループ・メンバーをクリックします。 グループからユーザーを削除するには、グループ・メンバー・リストでユーザーのアクション・メニューをクリックし、グループから削除オプションをクリックします。

  4. グループ詳細ページの上部にある削除ボタンをクリックします。

  5. グループの削除確認ダイアログで、確認ボタンをクリックします。

OCI CLIの使用

  1. 削除するグループのOCID (oci iam group list)を取得します。

  2. group list-usersコマンドを使用して、グループにメンバーがないことを確認します。

  3. グループ削除コマンドを実行します。

    構文:

    oci iam group delete --group-id group_OCID

    例:

    $ oci iam group delete --group-id ocid1.group.unique_ID
Are you sure you want to delete this resource? [y/N]: y

    確認せずにグループを削除するには、--forceオプションを使用します。

コンパートメントの作成および管理

コンパートメントには、クラウド・インスタンス、仮想クラウド・ネットワーク、ブロック・ボリュームなどのリソースが含まれます。 テナンシは、クラウド・リソースおよび他のコンパートメントを作成できるルート・コンパートメントです。 最大6レベルの深さのコンパートメントの階層を作成できます。 コンパートメント・リソースへのアクセスを特定のユーザー・グループに制限できます。 ビジネス・ニーズが変更された場合は、ほとんどのリソースをコンパートメント間で移動できます。

テナンシ内に作成するコンパートメントは、クラウド・リソースへのアクセスを編成および制御するための主要なビルディング・ブロックです。 コンパートメントおよびリソースを作成する前に、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「コンパートメント内のリソースの編成」を参照してください。

テナンシの理解

テナンシは特別なコンパートメントです。 テナンシは、クラウド・リソース(他のコンパートメントを含む)をすべて作成および管理するルート・コンパートメントです。

ユーザー、グループおよびアイデンティティ・プロバイダは、テナンシのコンパートメントではなく、常にテナンシに直接アタッチされます。 ユーザー、グループまたはアイデンティティ・プロバイダを作成する場合、別のコンパートメントを指定することはできません。 OCI CLIを使用してユーザー、グループまたはアイデンティティ・プロバイダを操作する場合、configファイルのテナンシのOCIDがデフォルトで使用されます。

その他のリソースは、テナンシまたは他のコンパートメントに存在できます。 多くの場合、これらのリソースで操作するには、「コンピュートWeb UI」で正しいコンパートメントを選択するか、OCI CLIでコンパートメントOCIDを指定する必要があります。

テナンシのOCIDを取得するには、次の手順を使用します。

「コンピュートWeb UI」の使用

  1. ページの右上にあるユーザー・プロファイル・メニューをクリックします。

  2. オプションをクリックします。

  3. テナンシの詳細ページで、OCIDの下の表示またはコピー・ボタンを使用します。

OCI CLIの使用

  1. compartment listコマンドを使用します。 

    $ oci iam compartment list

    ocid1.tenancy.unique_ID OCIDを探します。

    • オプションを指定しない場合、compartment listコマンドは、テナンシの直接子コンパートメントであるすべてのコンパートメントをリストします。 テナンシは、リスト内のすべてのコンパートメントについてリストされた最初のプロパティ(compartment-id)の値です。

    • --include-rootオプションを指定すると、テナンシが最初にリストされ、テナンシOCIDがidプロパティの値になります(compartment-idプロパティの値はnullです)。

    他のリソースと同様に、コンパートメントlistまたはgetで、compartment-idコンパートメントはidコンパートメントの親コンパートメントです。

コンパートメントのリスト

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、コンパートメントをクリックします。

    リストには、テナンシの直接の子コンパートメントであるすべてのコンパートメントが表示されます。

  2. リストされているコンパートメントのサブコンパートメントであるコンパートメントを表示するには、リストされているコンパートメントの名前をクリックします。 そのコンパートメントの詳細ページで、リソース・セクションまでスクロールし、子コンパートメントをクリックします。

    子コンパートメント・リストでコンパートメントの名前をクリックし、このステップを繰り返す必要がある場合があります。

特定のリソースが配置されているコンパートメントを検索するには、それらのリソースのリストに移動します。 リソース・リストの上にあるコンパートメント・ドロップ・ダウン・メニューを使用して、コンパートメントを選択します。

OCI CLIの使用

--helpオプションを使用して、--access-levelオプション、および--lifecycle-stateや--sort-byなどのlistコマンドに共通のオプションについて学習します。

  1. テナンシ内のすべてのコンパートメントおよびサブコンパートメントをリストするには、--compartment-id-in-subtreeオプションを値trueとともに指定します。 

    $ oci iam compartment list --compartment-id-in-subtree true

    次のステップで説明する--compartment-idオプションを指定しても、この出力は変更されません: テナンシ以外の特定のコンパートメントのコンパートメント・ツリーのみをリストすることはできません。

  2. 別のコンパートメントの直接子コンパートメントであるすべてのコンパートメントをリストするには、その親コンパートメントのOCIDを指定します:

    $ oci iam compartment list --compartment-id ocid1.compartment.unique_ID

    この出力には、指定された親コンパートメントはリストされず、この親コンパートメントの階層でより深いコンパートメントはリストされません。 この出力には、指定した親コンパートメントの直接の子コンパートメントのみがリストされます。

    親コンパートメントを指定しない場合、テナンシの直接の子コンパートメントであるすべてのコンパートメントがリストされます。 テナンシの直接の子コンパートメントに加えてテナンシをリストするには、--include-rootオプションを指定します。

  3. 特定のコンパートメントを1つのみリストするには、コンパートメント名を指定できます。

    $ oci iam compartment list --name Acompartment

    出力は、そのコンパートメントのgetと同じです。 

    $ oci iam compartment get --compartment-id OCID_of_Acompartment

コンパートメントの作成

テナンシまたは別のコンパートメントにコンパートメントを作成できます。 最大6レベルの深さのコンパートメントの階層を作成できます。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、コンパートメントをクリックします。

  2. コンパートメントのリストの上にあるコンパートメントの作成ボタンをクリックします。

  3. 「コンパートメントの作成」ダイアログ・ボックスで、次の情報を入力します:

    • 名前: このコンパートメントの名前。 コンパートメント名には次の特性があります:

      • テナンシ内で一意である必要があります。

      • 大文字と小文字は区別されません。

      • 後で変更できます。

      • 100文字以下にしてください。

      • 英数字、ピリオド(.)、ハイフン(-)およびアンダースコア(_)のみを含めることができます。

    • 摘要: このコンパートメントの説明。 この説明は400文字以下で、後で変更できます。

    • コンパートメントに作成: 新しいコンパートメントを作成するコンパートメント。 新しいコンパートメントは、選択したコンパートメントのサブコンパートメントになります。

    • タグ付け: (オプション) リソース作成時のタグの追加の説明に従って、このコンパートメントの定義済タグまたはフリー・フォーム・タグを追加します。 タグは後で適用することもできます。

  4. ダイアログ・ボックスでコンパートメントの作成ボタンをクリックします。

    新しいコンパートメントの名前をクリックして、コンパートメントの詳細(タグを含む)を表示します。

OCI CLIの使用

  1. 新しいコンパートメントを作成するコンパートメントのOCIDを取得します。 新しいコンパートメントは、指定されたコンパートメントのサブコンパートメントになります。 

    $ oci iam compartment list --compartment-id-in-subtree true

  2. コンパートメントcreateコマンドを実行します。

    構文:

    oci iam compartment create --compartment-id compartment_OCID \
--name text --description "text"

    名前および説明の値の特性については、「コンピュートWeb UI」プロシージャを参照してください。 定義済タグおよびフリー・フォーム・タグを追加するには、「リソース作成時のタグの追加」を参照してください。

    例:

    $ oci iam compartment create -c ocid1.compartment.parent_compartment_unique_ID \
--name ProductX --description "A child compartment of compartment Products"
{
  "data": {
    "compartment-id": "ocid1.compartment.parent_compartment_unique_ID",
    "defined-tags": {},
    "description": "A child compartment of compartment Products",
    "freeform-tags": {},
    "id": "ocid1.compartment.new_compartment_unique_ID",
    "inactive-status": null,
    "is-accessible": null,
    "lifecycle-state": "ACTIVE",
    "name": "ProductX",
    "time-created": "2021-10-05T22:58:23.216657+00:00"
  },
  "etag": "b212700d-45fa-46a9-90da-bcc016c587bc"
}

    この出力を後で表示するには、compartment getコマンドを使用します。

タグのデフォルトの適用

コンパートメントには、タグのデフォルトと呼ばれるリソースを含めることができます。 タグのデフォルトは、タグのデフォルトが親コンパートメントに追加された後に作成されたすべてのリソースおよび子コンパートメントによって継承される定義済タグです。 タグのデフォルトをコンパートメントに追加するには、「タグのデフォルトの構成」を参照してください。

アクセス制御のポリシーの追加

子コンパートメントは、親コンパートメントからアクセス権限を継承します。 新しいコンパートメントへのアクセスを親コンパートメントへのアクセスとは異なるものにする場合は、新しいコンパートメントのアクセス・ポリシーを作成します。 たとえば、コンパートメントProductsのすべてのリソースを読み取るgroup DevX権限と、サブコンパートメントProductX内のすべてのリソースを管理する権限を付与します。 コンパートメントProductsのすべてのリソースを読み取るgroup DevY権限と、サブコンパートメントProductY内のすべてのリソースを管理する権限を付与します。 継承のため、グループDevXはコンパートメントProductYのすべてのリソースを読み取ることができ、グループDevYはコンパートメントProductXのすべてのリソースを読み取ることができます。

ポリシーの作成およびアタッチの詳細は、「ポリシーの管理」を参照してください。

コンパートメントへのリソースの追加

次のいずれかのメソッドを使用して、リソースをコンパートメントに追加します:

  • リソースの作成時にコンパートメントを指定します。

  • 別のコンパートメントからリソースを移動します。

    アタッチされたリソースが移動されたリソースとともに移動するかどうかなどの詳細は、特定のリソースのドキュメントを参照してください。

    移動されたリソースに正しいタグとポリシーが適用されているかどうかを確認します。 タグおよびポリシーを手動で削除および追加する必要がある場合があります。

「コンピュートWeb UI」のコンパートメント詳細ページのリソース・ボックスと、OCI CLIのコンパートメントのlistおよびgetコマンドは、コンパートメントに属するすべてのリソースを表示しません。 リストされていないリソースの場合は、インスタンスなどのそのリソースの「コンピュートWeb UI」ページに移動し、リソース・リストの上にあるコンパートメント・ドロップ・ダウン・メニューからコンパートメントを選択します。 OCI CLIで、リソースをリストするときにコンパートメントOCIDを指定します。 「コンピュートWeb UIの使用」および「OCI CLIの使用」も参照してください。

コンパートメントの更新

コンパートメントの名前と説明を変更できます。 「既存のリソースへのタグの適用」の説明に従って、タグを追加、変更または削除できます。 親コンパートメントは変更できません。 親コンパートメントを変更するには、「別のコンパートメントへのコンパートメントの移動」を参照してください。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、コンパートメントをクリックします。

  2. 更新するコンパートメントがリストに表示されない場合は、「コンパートメントのリスト」の説明に従って、更新するコンパートメントに移動します。

  3. 更新するコンパートメントについて、アクション・メニューをクリックし、編集オプションをクリックします。

  4. compartment_nameコンパートメントの編集ダイアログで、変更を行います。

  5. Save Changesボタンをクリックします。

    コンパートメント名をクリックして、タグを含むコンパートメントの詳細を表示します。

OCI CLIの使用

  1. 更新するコンパートメントのOCIDを取得します。

    $ oci iam compartment list --compartment-id-in-subtree true

  2. コンパートメント更新コマンドを実行します。

    構文:

    oci iam oci iam compartment update --compartment-id compartment_OCID \
options_with_values_to_update

    例:

    --defined-tagsまたは--freeform-tagsオプションを指定する場合は、保持するコンパートメントにすでに存在するタグを含め、このコンパートメントに必要なすべての定義済タグおよびフリー・フォーム・タグを完全に指定する必要があります。 これらのタグ・オプションに指定する値は、既存の値を置換します。 「リソース・タグの操作」を参照してください。 --forceオプションを指定しないかぎり、確認を求めるプロンプトが表示されます。 

    $ oci iam compartment update --compartment-id ocid1.compartment.unique_ID \
--defined-tags '{"Product":{"LMN":"Development"}}' --freeform-tags '{"MyTag":"val-u"}'
WARNING: Updates to freeform-tags and defined-tags will replace any existing values.
Are you sure you want to continue? [y/N]: y

    このコマンドの出力は、compartment getコマンドの出力と同じです。

別のコンパートメントへのコンパートメントの移動

コンパートメントを同じテナンシ内の別の親コンパートメントに移動できます。 コンパートメントを移動すると、コンパートメントのすべてのサブコンパートメントが移動されます。 移動されたコンパートメントの一部のリソースが移動されます。 必要に応じて、他のリソースを個別に移動できます。 詳細は、特定のリソース・タイプのドキュメントを参照してください。

コンパートメントを新しい親コンパートメントに移動すると、新しい親のアクセス・ポリシーが有効になり、以前の親のポリシーが適用されなくなります。 コンパートメントおよびその前の親コンパートメントのリソースへのアクセス権を持つグループは、コンパートメントの移動時にアクセスを失います。 新しい親コンパートメントへのアクセス権を持つグループは、移動されたコンパートメントとそのリソースにアクセスできます。

新しい親に作成されたすべてのリソースに自動的に適用されるタグのデフォルトは、新しく移動されたコンパートメントとそのリソースに自動的に適用されません。 移動したコンパートメントにタグのデフォルトを個別に削除および追加し、移動したリソースにタグを削除して追加する必要がある場合があります。

「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「別の親コンパートメントへのコンパートメントの移動」も参照してください。

現在のコンパートメントおよび宛先コンパートメントの最下位の共有親コンパートメントに対するmanage all-resources権限を持つグループに属している必要があります。

コンパートメントを移動するには、OCI CLIを使用する必要があります。

OCI CLIの使用

  1. 移動するコンパートメントのOCIDと宛先コンパートメントのOCIDを取得します。

    $ oci iam compartment list --compartment-id-in-subtree true

  2. コンパートメント移動コマンドを実行します。

    構文:

    oci iam compartment move --compartment-id compartment_to_move_OCID \
--target-compartment-id destination_compartment_OCID

    iam work-request getコマンドを使用してコンパートメント移動のステータスを確認するか、「コンピュートWeb UI」で作業リクエストの詳細を表示します。 一部のリソースは、コンパートメントよりも移動に時間がかかる場合があります。

コンパートメントの削除

コンパートメントを削除するには、まずコンパートメントにアタッチされているポリシーを含め、コンパートメント内のすべてのリソースを移動、削除または終了する必要があります。 開始する前に、コンパートメント内のすべてのリソースの移動および削除機能を確認してください。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、コンパートメントをクリックします。

    テナンシ内のコンパートメントがリストされます。

  2. 削除するコンパートメントがリストに表示されていない場合は、「コンパートメントのリスト」の説明に従って、更新するコンパートメントに移動します。

  3. 削除するコンパートメントについて、アクション・メニューをクリックし、「コンパートメントの削除」オプションをクリックします。

    「コンパートメントの削除」オプションが選択できない場合は、このコンパートメントを削除する権限がない可能性があります。

  4. コンパートメントの削除確認ダイアログで、削除をクリックします。

    コンパートメント・ステータスが削除中に変更されます。

    コンパートメントの詳細ページのリソース・ボックスで、作業リクエストをクリックし、コンパートメントの削除の詳細を表示します。 作業リクエストが完了すると、コンパートメントがコンパートメント・リストから削除されます。 作業リクエストが失敗した場合、コンパートメントのステータスはアクティブに戻ります。

OCI CLIの使用

  1. 削除するコンパートメントのOCIDを取得します。

    $ oci iam compartment list --compartment-id-in-subtree true

  2. コンパートメントの削除コマンドを実行します。

    構文:

    oci iam compartment delete --compartment-id compartment_OCID

    iam work-request getコマンドを使用して、コンパートメントの削除のステータスを確認します。

ポリシーの管理

ポリシーは、1つ以上のポリシー・ステートメントの名前付きセットです。 ポリシー・ステートメントは、リソースにアクセスするための権限をユーザーに付与します。

アクセス・ポリシーを設計する場合は、次のポリシー特性に注意してください:

  • ポリシーは、ポリシーをアタッチするコンパートメントとそのコンパートメントのすべてのサブコンパートメントに適用されます。 テナンシを含む特定のコンパートメントで付与された権限は、そのコンパートメントのすべてのサブコンパートメントに継承されます。

  • 1人のユーザーが複数のグループのメンバーになることができます。 グループは複数のポリシーの対象にできます。 1つのポリシーには、最大50個のポリシー・ステートメントを含めることができます。

  • 一部のユーザーが名前付きリソースへのフル・アクセスを必要とし、他のユーザーはリソースのみを使用する必要がある場合は、複数のグループおよび複数のポリシーを作成する必要があります。 テナンシには、最大100個のポリシーを設定できます。

  • サブコンパートメント内のリソースへのフル・アクセス権を持つユーザーには、そのコンパートメントおよび親コンパートメント内の関連リソースへの表示または使用アクセスも必要です。 たとえば、コンパートメントにインスタンスを作成するアクセス権を持つユーザーは、タグ・ネームスペースを使用して定義済のタグをインスタンスに適用したり、別のコンパートメント内のイメージを読み取るためのアクセスが必要になる場合もあります。

概念の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。

ポリシー・ステートメントの記述

1つのポリシーには、最大50個のポリシー・ステートメントを含めることができます。 テナンシには、最大100個のポリシーを設定できます。 ポリシーで許可するものを決定し、この項の情報を使用して必要なステートメントを記述します。

ポリシー・ステートメントに名前を付ける予定のグループおよびコンパートメントが存在することを確認します。 使用する各グループおよびコンパートメントの名前またはOCIDに注意してください。

ノート:

OCIDのかわりにポリシー・ステートメントに名前を使用すると、グループまたはコンパートメントの名前がその後変更されても、ポリシーは引き続き有効になります。 内部的には、名前ではなくOCIDが使用されます。 ただし、管理者はグループまたはコンパートメントの名前が変更されるかどうかを理解するのがより難しい場合があります。

タグを使用してポリシーを複数のグループまたは複数のコンパートメントに適用する場合は、タグが存在することを確認してください。 タグ・ネームスペースの名前、キーの名前およびポリシー・ステートメントで使用する値を書き留めます。

概念および参照情報および一般的な文の例については、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。

ポリシー・ステートメントの構文

ポリシー・ステートメントは、リソースにアクセスするための権限をユーザーに付与します。 ユーザーはポリシーのサブジェクトとも呼ばれます。権限は動詞とも呼ばれます。 リソース・タイプおよびコンパートメントは、ユーザーがアクセス権を付与される可能性のあるリソースのセットを定義します。 このリソースのセットは、ターゲットとも呼ばれます。 条件を使用すると、ユーザー・セット、リソース・セット、リソースに対して実行できる操作を絞り込むことができます。

ポリシー・ステートメントの構文は次のとおりです:

allow users to permissions [resource_type] in compartment [ where conditions ]

キーワードallow、toおよびinは必須であり、大文字と小文字は区別されません。

users

1つ以上のユーザー・グループまたはany-user。 複数のグループを指定するには、リスト内の2つのグループ名またはOCIDごとにカンマを使用します。 グループ名とグループOCIDの両方を指定することはできません。 キーワードany-userを指定して、すべてのユーザーに権限を付与できます。

  • group group_name[,group_name …]

  • group id group_ocid[,group_ocid …]

  • any-user

permissions

  • inspect, read, use、またはmanageのいずれか。 これらの権限アグリゲータが付与するアクセス権の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」にある"Policy Syntax"の"Verb"を参照してください。

  • 次の形式の1つ以上の特定の権限(INSTANCE_UPDATEなど): 

    { PERMISSION_1[, PERMISSION_2]... }

    このオプションを使用する場合は、resource_typeを指定しないでください。 リソース・タイプは権限に含まれます。

権限アグリゲータと1つ以上の特定の権限を同じリソースに付与するには、2つのポリシー・ステートメントを使用します。

resource_type

次のいずれかを表す単一のキーワード:

  • 単一のリソース・タイプ(instancesやvolumesなど)。

  • リソース・タイプのファミリ。 たとえば、instance-familyリソース・タイプ・ファミリには、次のリソース・タイプが含まれます:

    • app-catalog-listing

    • console-histories

    • instances

    • instance-console-connection

    • instance-images

  • all-resources

4つのアクセス権アグリゲータ・キーワードの1つではなく特定のアクセス権を一覧表示する場合は、resource_typeを指定しないでください。 リソース・タイプは権限に含まれます。

リソース・タイプのリストについては、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」にある"Policy Syntax"の"Resource Types"の表を参照してください。

compartment

単一のコンパートメント名またはOCIDまたはtenancy。

  • compartment compartment_name

  • compartment id compartment_OCID

  • tenancy

複数のコンパートメントでアクセス権を付与するには、複数の文を使用します。

condition

定義済の変数の後に演算子と値が続きます。 「条件の使用」を参照してください。

条件の使用

ポリシー・ステートメントで条件を指定して、アクセス権を付与されるユーザーのセット、アクセス権を付与されるリソースのセット、およびリソースで実行できる操作を絞り込むことができます。 条件は、指定した値を持つ事前定義された変数です。 ANDおよびOR関係で条件のリストを指定できます。 アクセスを許可するには、条件句全体がtrueと評価される必要があります。 予期しないfalseと評価される可能性がある条件の詳細は、「適用できない条件」を参照してください。

条件句の構文は次のとおりです:

where condition
where all|any {condition[, condition]...}

conditionの構文は次のとおりです: 

variable op 'value'
variable

表2-1を参照してください。

op
value

valueには、完全に指定された文字列を指定することも、*ワイルドカードを使用することもできます。 valueが完全に指定された文字列の場合は、値を一重引用符で囲みます。 *を使用する場合は、値をスラッシュ(/)で囲みます: 

'BU1-ProdX'
/*Prod*/
/*ProdX/
/BU1-Prod*/

条件値は大文字と小文字が区別されません。 たとえば、値がBucketAの条件は、そのようなバケットが存在する場合、同じコンパートメント内のバケットbucketAにも適用されます。

次の表で、requestで始まる変数は、実行されているリクエストを参照: ユーザーが「コンピュートWeb UI」オプションをクリックしたか、OCI CLIコマンドを入力しました。 targetで始まる変数は、ユーザーがコマンド内でクリックまたは名前を付けたリソースを参照します。

表2-1 条件でサポートされている事前定義変数

変数 説明

request.groups.id

リクエスト元ユーザーが属するグループのリスト。

request.operation

試行中の操作の名前。

request.permission

操作の実行に必要な権限の名前。

target.compartment.id

ターゲット・リソースを含むコンパートメントのOCID。 ターゲット・リソースを含むコンパートメントは、ポリシー・ステートメントのin句で指定されたコンパートメントの子コンパートメントである可能性があります。

target.compartment.name

ターゲット・リソースを含むコンパートメントの名前。 ターゲット・リソースを含むコンパートメントは、ポリシー・ステートメントのin句で指定されたコンパートメントの子コンパートメントである可能性があります。

target.user.id

ターゲット・ユーザーのOCID。 リクエストされた権限でユーザーを作成する場合、このOCIDは使用できません。

target.user.name

ターゲット・ユーザーの名前。

target.group.id

ターゲット・グループのOCID。 リクエストされた権限でグループを作成する場合、このOCIDは使用できません。

target.group.name

ターゲット・グループの名前。

target.group.member

リクエスト元のユーザーがターゲット・グループに属している場合はtrue。

target.policy.id

ターゲット・ポリシーのOCID。 リクエストされた権限でポリシーを作成する場合、このOCIDは使用できません。

target.policy.name

ターゲット・ポリシーの名前。

target.tag-namespace.id

リスト、更新または削除するためにユーザーがリクエストしているタグ・ネームスペースのOCID。

target.tag-namespace.name

ユーザーが作成または更新をリクエストしているタグ・ネームスペースの名前。 複数の名前を区切るにはカンマを使用します

request.principal.group.tag

「条件での定義済タグの使用」を参照してください。

target.resource.tag

「条件での定義済タグの使用」を参照してください。

target.resource.compartment.tag

「条件での定義済タグの使用」を参照してください。

例: request.permissionを使用した権限の指定

オブジェクトを作成する権限ではなく、オブジェクトを削除する権限を付与するには、manageアクセス権を付与し、アクセス権の作成と検査のみが付与されることを示す条件を指定できます: 

allow group ObjectWriters to manage objects in compartment ABC 
where any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}

例: target.compartment.nameおよびワイルドカードを使用したコンパートメントの指定

次の例では、コンパートメントXYZを除き、Xで始まる名前を持つコンパートメント内のvirtual-network-familyのすべてのリソースを管理する権限をユーザーに付与します: 

allow group NetworkAdmins to manage virtual-network-family in tenancy 
where all {target.compartment.name=/X*/,target.compartment.name!='XYZ'}

例: ネストされた条件

次のポリシーにより、グループBucketAdminsのユーザーは、コンパートメントABCのBucketAの保持ルールの読取り、更新または管理を行うことができます:

allow group BucketAdmins to manage buckets in compartment ABC 
where all {target.bucket.name='BucketA', 
any {request.permission='BUCKET_UPDATE', request.permission='BUCKET_READ',
RETENTION_RULE_MANAGE}}

ポリシーは特定の名前付きバケット用であるため、ユーザーはバケットのリストの取得を許可しません。 ユーザーがバケットのリストを取得できるようにするには、次の個別の文を追加します: 

allow group BucketAdmins to inspect buckets in compartment ABC

「適用できない条件」を参照してください。

例: 定義済タグの適用

次の例では、グループBucketAdminsおよびObjectWritersのユーザーがStorageTagsタグ・ネームスペースにタグを適用できます:

allow group BucketAdmins,ObjectWriters to use tag-namespaces in tenancy 
where target.tag-namespace.name='StorageTags'

例: メンバーである任意のグループの編集

次の例では、すべてのユーザーがメンバーである任意のグループを編集できます:

allow any-user to use groups in tenancy where target.group.member='true'
適用できない条件

条件が残りのポリシー・ステートメントに適用されない場合、その条件はfalseに評価され、アクセスは付与されません。

条件は、リクエストで使用できない情報をテストしている場合、適用できません。 たとえば、次のポリシー・ステートメントは、リソースusersへのuseアクセス権を付与しますが、リクエスト・ユーザーは、use権限に含まれている場合でも、ユーザーのリストまたは更新を許可しません: 

allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'

ユーザーのリストまたはユーザーの更新リクエストには、グループに関する情報が含まれていません。 リスト・ユーザーおよび更新ユーザーのリクエストには、target.group.nameの値がありません。 テストは失敗し、ユーザーをリストまたは更新するリクエストは拒否されます。

この例を修正するには、where句を削除し、inspectまたはreadアクセスのみを許可できます。

条件での定義済タグの使用

特定の条件では、ユーザー、コンパートメントまたはリソースに適用された定義済タグの値が評価されます。 これらの条件では、事前定義された変数をタグ変数と呼ぶことができます。

タグ変数とともに条件を使用すると、次のことができます:

  • 複数のユーザー・グループ、コンパートメントまたはリソースに適用される単一のポリシー・ステートメントを記述します。

  • ポリシー・ステートメントを変更せずに付与される権限を変更します。 かわりに、アクセスを許可または取り消すには、別のリソースにタグを適用するか、リソースからタグを削除します。

定義済タグを作成および適用する方法の詳細は、「リソース・タグ管理」を参照してください。

タグ変数を使用する条件の一般的な構文は、他の条件変数を使用する条件の構文と同じです:

variable op 'value'

これら3つの各パーツの値は、タグ専用です。

variable

タグ条件変数には、タグ・ネームスペースの名前および変数名にキーの名前が含まれます:

base_variable_name.tag_namespace_name.tag_key_name
op

=, !=, in、またはnot inのいずれか。

inおよびnot in操作は、タグに対して可能な値のセットのメンバーを参照します。

value

valueは、定義されたタグの値です。 値は単一値または値リストです。

次のタグ変数がサポートされています:

request.principal.group.tag

この変数は、1つの文の複数のグループへのアクセス権を付与される可能性があります。 次の文では、タグOperations>Project>ABCでタグ付けされたグループのメンバーであるユーザーが、コンパートメントProdXのインスタンス・リソースを管理できます: 

allow any-user to manage instance-family in compartment ProdX 
where request.principal.group.tag.Operations.Project='ABC'

前述の文の'ABC'を'*'または/*/,に置換すると、Operationsの値でタグ付けされたグループのメンバーであるユーザー>ProjectがコンパートメントProdXのインスタンス・リソースを管理できます。

target.resource.compartment.tag

この変数は、1つの文で複数のコンパートメントへのアクセス権を付与される可能性があります。 次の文では、グループNetAdminsのユーザーは、タグ操作>プロジェクト>ABCまたはタグ操作>パーソネル>テストでタグ付けされた任意のコンパートメントのネットワーク・リソースを使用できます: 

allow group NetAdmins to use virtual-network-family in tenancy where
any { target.resource.compartment.tag.Operations.Project='ABC', 
target.resource.compartment.tag.Operations.Personnel='Test' }

前述の文でanyをallに置換した場合、NetAdminsグループのユーザーは、タグOperations>Project>ABCおよびtag Operations>Personnel>Testの両方のタグが付けられた任意のコンパートメントのネットワーク・リソースを使用できます。

次の文を使用すると、グループNetAdminsのユーザーは、タグ操作>人事>開発またはタグ操作>人事>テストのいずれかのタグが付けられた任意のコンパートメントのネットワーク・リソースを使用できます:

allow group NetAdmins to use virtual-network-family in tenancy where
target.resource.compartment.tag.Operations.Personnel in ('Development', 'Test')

target.resource.tag

この変数は、指定されたタイプの1つ以上のリソースへのアクセス権を付与します。 次の文では、グループXadminは、タグOperations>Project>XYZでタグ付けされたコンパートメントProdX内の任意のインスタンスを使用できます。 

allow group Xadmins to use instances in compartment ProdX 
where target.resource.tag.Operations.Project = 'XYZ'

テナンシのリソースにアクセスするためのポリシーの記述

始める前に

他のテナンシからのテナンシ・アクセスを許可するポリシーを記述して、テナンシ間でリソースを共有できます。 両方のテナンシの管理者は、どのリソースにアクセスして共有できるかを明示的に示す特別なポリシー・ステートメントを作成する必要があります。 これらの特別な文では、次の特殊動詞を使用します:

  • 裏書: このポリシー・ステートメントは、ソース・テナンシ内のグループが他のテナンシで実行できる作業について説明します。 別のテナンシ・リソースを操作する必要があるユーザーのグループを含むテナンシのendorse文を記述します。
  • 許可: このポリシー・ステートメントは、他のテナンシのグループが宛先テナンシで実行できる作業について説明します。 リソースにアクセスする権限を付与するテナンシのadmit文を記述します。 admit文は、宛先テナンシのリソース・アクセスを必要とするソース・テナンシのユーザーのグループを識別します。

  • 定義: このポリシー・ステートメントは、ソース・テナンシ OCID、ソース・グループ OCIDおよび宛先テナンシ OCIDの別名を割り当てるために使用されます。 admitポリシー・ステートメントで使用する「ソース・テナンシ」別名および「ソース・グループ」別名を定義します。 endorseポリシー・ステートメントで使用する「宛先テナンシ」別名を定義します。

    endorse文またはadmit文と同じポリシー・エンティティにdefine文を含める必要があります。

endorse文とadmit文は連携して動作します。 endorse文はソース・テナンシに存在し、admit文は宛先テナンシに存在します。 アクセスを指定する対応する文がない場合、特定のendorseまたはadmit文はアクセス権を付与しません。 両方のテナンシがアクセスに同意し、アクセスを許可するポリシーを持っている必要があります。

ソース・テナンシでは、次の構文を使用してdefineおよびendorseポリシー・ステートメントを記述します: 

define tenancy destination-tenancy-alias as tenancy_ocid
endorse group group-name to verb resource in tenancy destination-tenancy-alias

宛先テナンシでは、次の構文を使用して、2つのdefineポリシー・ステートメントおよびadmitポリシー・ステートメントを記述します: 

define tenancy source-tenancy-alias as tenancy_ocid
define group source-group-alias as group_ocid
admit group source-group-alias of tenancy source-tenancy-alias to verb resource in compartment/tenancy

概念および参照情報および一般的な文の例については、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。

ソース・テナンシのポリシー・ステートメント

ソース・テナンシの管理者は、宛先テナンシのリソースを管理するためにテナンシのグループをエンドースするポリシー・ステートメントを作成します。

次の例に示すように、ソース・テナンシに対して広範なポリシー・ステートメントを記述できます。

  • StorageAdminsなどの特定のグループを承認して、テナンシ内のすべてのオブジェクト・ストレージ・リソースに対して何でも行うには: 

    endorse group StorageAdmins to manage object-family in any-tenancy

  • DNSAdminsなどの特定のグループを承認して、テナンシ内のすべてのDNSリソースに対して何でも行うには: 

    endorse group DNSAdmins to manage dns in any-tenancy

ソース・テナンシ・グループのアクセス範囲を減らすポリシーを記述できます。 このタイプのポリシーの場合、ソース・テナンシの管理者は、宛先テナンシOCIDの別名を定義し、ポリシー・ステートメントでその別名を参照する必要があります。次に例を示します:

  • StorageAdminsなどの特定のグループを承認して、DestinationTenancyなどの特定のテナンシ内のオブジェクト・ストレージ・リソースを管理するには、次のポリシー・ステートメントを使用します: 

    define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
endorse group StorageAdmins to manage object-family in tenancy DestinationTenancy

  • DNSAdminsなどの特定のグループを承認して、DestinationTenancyなどの特定のテナンシ内のDNSリソースを管理するには、次のポリシー・ステートメントを使用します: 

    define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
endorse group DNSAdmins to manage dns in tenancy DestinationTenancy

宛先テナンシには、ソース・テナンシ・グループが宛先テナンシおよびそのリソースにアクセスできるようにするポリシーも必要です。 宛先テナンシでこの対応するポリシーがない場合、ソース・テナンシ・グループは宛先テナンシまたはそのリソースにアクセスできません。

ポリシー・ステートメントの記述の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」のポリシーの仕組みを参照してください。

宛先テナンシ・ポリシー・ステートメント

宛先テナンシの管理者は、ソース・テナンシのグループが宛先テナンシおよびそのリソースにアクセスすることを許可するポリシー・ステートメントを作成します。

次の例に示すように、宛先テナンシに対して広範なポリシー・ステートメントを記述できます。

  • ソース・テナンシ内の特定のグループ(StorageAdminsなど)が宛先テナンシ内のすべてのオブジェクト・ストレージ・リソースに対して何でも実行できるようにするには: 

    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group StorageAdmins as ocid1.group.oc1..<unique_ID>
admit group StorageAdmins of tenancy SourceTenancy to manage object-family in tenancy
  • ソース・テナンシ内の特定のグループ(DNSAdminsなど)が宛先テナンシ内のすべてのDNSリソースに対して何でも実行できるようにするには:
    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group DNSAdmins as ocid1.group.oc1..<unique_ID>
admit group DNSAdmins of tenancy SourceTenancy to manage dns in tenancy

ソース・テナンシ・グループのアクセス範囲を宛先テナンシ・リソースに減らすポリシーを記述できます。 これらのタイプのポリシーの場合、宛先テナンシの管理者は、ソース・テナンシOCIDおよびソース・グループOCIDの別名を定義してから、ポリシー・ステートメントで次のような別名を参照する必要があります:

  • StorageAdminsなどのソース・テナンシ内の特定のグループに、SharedBucketsなどの特定のコンパートメント内のオブジェクト・ストレージ・リソースの管理を許可するには、次のポリシー・ステートメントを使用します: 

    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group StorageAdmins as ocid1.group.oc1..<unique_ID>
admit group StorageAdmins of tenancy SourceTenancy to manage object-family in compartment SharedBuckets
  • DNSAdminsなどのソース・テナンシ内の特定のグループが、SharedZomesなどの特定のコンパートメント内のDNSリソースを管理できるようにするには、次のポリシー・ステートメントを使用します:
    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group DNSAdmins as ocid1.group.oc1..<unique_ID>
admit group DNSAdmins of tenancy SourceTenancy to manage dns in compartment SharedZones

ソース・テナンシには、ソース・テナンシ・グループの宛先テナンシおよびそのリソースへのアクセスをエンドースするポリシーも必要です。 ソース・テナンシでこの対応するポリシーがない場合、ソース・テナンシ・グループは宛先テナンシまたはそのリソースにアクセスできません。

ポリシー・ステートメントの記述の詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」のポリシーの仕組みを参照してください。

ポリシーの作成

始める前に

ポリシーには少なくとも1つのポリシー・ステートメントが必要です。 空のポリシーを作成し、後でステートメントを追加することはできません。 ポリシーで許可するものを決定し、「ポリシー・ステートメントの記述」を参照して必要な文を設計してください。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 「ポリシーの作成」をクリックします。

  3. 「ポリシーの作成」ダイアログで、次の情報を入力します:

    • 名前: ポリシー名。 ポリシー名には次の特性があります:

      • テナンシ内で一意である必要があります。

      • 大文字と小文字は区別されません。

      • 後で変更できません。

      • 100文字以下にしてください。

    • 摘要: ポリシーの説明。 この説明は400文字以下にしてください。

    • コンパートメントに作成: このポリシーをアタッチするコンパートメントを選択します。 ポリシーはこのコンパートメントと、このコンパートメントのすべての子コンパートメントに適用されます。

    • 計算書: ポリシー・ステートメントを入力します。 ポリシー・ステートメントの記述方法の詳細は、「ポリシー・ステートメントの記述」を参照してください。

      2つ目のポリシー・ステートメントを追加するには、別のステートメント・ボタンをクリックします。 最大50個の文を入力できます。 複数のポリシー・ステートメントを作成する場合は、ステートメントの横にあるXボタンをクリックしてそのステートメントを削除できます。

    • タグ付け: (オプション) リソース作成時のタグの追加の説明に従って、このポリシーの定義済タグまたはフリー・フォーム・タグを追加します。 タグは後で適用することもできます。

  4. 「送信」ボタンをクリックします。

    新しいポリシーの詳細ページが表示されます。 ページの「リソース」セクションに、ポリシー・ステートメントが表示されます。

OCI CLIの使用

  1. ポリシーをアタッチするコンパートメントのOCIDを取得します。 ポリシーはこのコンパートメントと、このコンパートメントのすべての子コンパートメントに適用されます。 

    $ oci iam compartment list --compartment-id-in-subtree true

  2. --statementsオプションの引数を作成します。

    --statementsオプション引数の値は、JSON形式のポリシー・ステートメントの配列です。 この引数は、コマンド行またはファイルで文字列として指定できます。 ポリシー・ステートメントの記述方法の詳細は、「ポリシー・ステートメントの記述」を参照してください。

  3. (オプション) 「リソース作成時のタグの追加」の説明に従って、このポリシーの定義済タグまたはフリー・フォーム・タグの引数を作成します。 タグは後で適用することもできます。

  4. ポリシーcreateコマンドを実行します。

    構文:

    oci iam policy create -c compartment_OCID --name text --description "text" \
{ --statements '["statement","statement"]' | --statements file://policy.json }

    compartment_OCIDは、このポリシーをアタッチするコンパートメントです。 名前および説明の値の特性については、「コンピュートWeb UI」プロシージャを参照してください。 定義済タグおよびフリー・フォーム・タグを追加するには、「リソース作成時のタグの追加」を参照してください。

    このコマンドは、policy getコマンドと同じ出力を返します。

ポリシーの更新

「コンピュートWeb UI」を使用したポリシーの説明またはタグの変更

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 変更するポリシーがリストに表示されない場合は、ポリシー・リストの上にあるコンパートメント・ドロップ・ダウン・メニューから適切なコンパートメントを選択します。

  3. 変更するポリシーについて、ポリシーのアクション・メニューをクリックし、編集オプションをクリックします。

  4. 説明またはタグを更新します。

    タグを変更するには、「既存のリソースへのタグの適用」を参照してください。

  5. Save Changesボタンをクリックします。

「コンピュートWeb UI」を使用したポリシー・ステートメントの変更

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 変更するポリシーがリストに表示されない場合は、ポリシー・リストの上にあるコンパートメント・ドロップ・ダウン・メニューから適切なコンパートメントを選択します。

  3. 変更するポリシーの名前をクリックします。

  4. ポリシーの詳細ページで、リソース・セクションまでスクロールします。

  5. 文リストで、ポリシー・ステートメントの構成ボタンをクリックします。

  6. policy_nameポリシー・ダイアログのステートメントの編集で、ポリシー・ステートメントを変更または追加します。

    ポリシー・ステートメントを変更するには、「ポリシー・ステートメントの記述」を参照してください。

    ポリシー・ステートメントを追加するには、別のステートメント・ボタンをクリックします。 最大50個の文を入力できます。

    複数のポリシー・ステートメントが存在する場合は、ステートメントの横にあるXボタンをクリックしてそのステートメントを削除できます。

  7. 「送信」ボタンをクリックします。

OCI CLIの使用

  1. ポリシーOCIDを取得します。

    $ oci iam policy list --compartment-id compartment_OCID

  2. (オプション)ポリシー・ステートメントを変更または追加するには、--statementsオプションの引数を作成します。

    --statementsオプション引数の値は、JSON形式のポリシー・ステートメントの配列です。 この引数は、コマンド行またはファイルで文字列として指定できます。 ポリシー・ステートメントの記述方法の詳細は、「ポリシー・ステートメントの記述」を参照してください。

    --statementsオプションに指定した引数は、ポリシー内の既存の文を置き換えます。 既存のポリシーから保持するステートメントを必ず含めてください。 policy getコマンドを使用して、現在のポリシー・ステートメントを表示およびコピーします。

    --forceオプションを指定しない場合、ポリシー内の既存の文が表示され、置換の確認を求められます。

  3. (オプション) 「リソース作成時のタグの追加」の説明に従って、このポリシーの定義済タグまたはフリー・フォーム・タグの引数を作成します。

  4. ポリシー更新コマンドを実行します。

    構文:

    oci iam policy update --policy-id policy_OCID [ --description desc ] \
[ --defined-tags tags ] [ --freeform-tags tags ] \
[ --statements policy_statements --version-date "" ]

    --statementsを指定する場合は、--version-date ""を含める必要があります。

    このコマンドは、policy getコマンドと同じ出力を返します。

ポリシーの削除

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 削除するポリシーがリストに表示されない場合は、ポリシー・リストの上にあるコンパートメント・ドロップ・ダウン・メニューから適切なコンパートメントを選択します。

  3. 削除するポリシーについて、アクション・メニューをクリックし、削除オプションをクリックします。

  4. 確認ダイアログで、「削除」ボタンをクリックします。

OCI CLIの使用

  1. ポリシーOCIDを取得します。

    $ oci iam policy list --compartment-id compartment_OCID

  2. ポリシー削除コマンドを実行します。

    構文:

    oci iam policy delete --policy-id policy_OCID

    このコマンドは、policy getコマンドと同じ出力を返します。

Microsoft Active Directoryによるフェデレート

フェデレートを使用すると、会社のユーザーは、会社の他のログインですでに使用しているPrivate Cloud Appliance 「コンピュートWeb UI」と同じログイン資格証明を使用できます。 「連邦」に、管理者は既存のアイデンティティ・プロバイダとOracle Private Cloud Applianceの間に信頼関係を作成します。 この関係が確立されると、「コンピュートWeb UI」にアクセスするときに、フェデレーテッド・ユーザーに「シングル・サインオン」のプロンプトが表示されます。

詳細は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「アイデンティティ・プロバイダによるフェデレート」を参照してください。

複数のActive Directory (AD)アカウントをOracle Private Cloud Applianceとフェデレートできます。 各フェデレーションの信頼は、単一のADアカウント用です。 信頼を作成するには、Oracle Private Cloud Appliance 「コンピュートWeb UI」でいくつかのタスクを実行し、Active Directory Federation Services (ADFS)でいくつかのタスクを実行します。

フェデレーションを開始する前に、次のタスクを完了していることを確認してください:

  • 組織用にインストールおよび構成されたMicrosoft ADFS。

  • Oracle Private Cloud ApplianceのグループにマップされるグループをADに作成します。

  • Oracle Private Cloud Appliance 「コンピュートWeb UI」にサインインするユーザーをADに作成します。

ノート:

Oracle Private Cloud ApplianceにマップするADグループに共通プレフィクスを使用することを検討してください。 たとえば、PCA_Administrators、PCA_NetworkAdmins、PCA_InstanceLaunchersなどのADグループ名を使用します。

ADFSからの必須情報の収集

Private Cloud Applianceとフェデレートするには、SAMLメタデータ・ドキュメントと、Private Cloud ApplianceグループにマップするADグループの名前が必要です。

  1. ADFSのSAMLメタデータ・ドキュメントを見つけてダウンロードします。 デフォルトの場所は次のとおりです。 

    https://your_hostname/FederationMetadata/2007-06/FederationMetadata.xml

    このドキュメントは、アイデンティティ・プロバイダの作成時にアップロードします。

  2. Private Cloud ApplianceグループにマップするすべてのADグループをノートにとります。

    重要:

    ADをアイデンティティ・プロバイダとして追加する前に、すべてのPrivate Cloud Applianceグループが構成されていることを確認します。

アイデンティティ・プロバイダの自己署名証明書の検証

重要:

ADFS証明書が既知の認証局によって署名されている場合は、この検証ステップをスキップできます。 既知の認証局によって署名されたADFS証明書は、Private Cloud Appliance証明書バンドルにすでに存在している必要があります。

Private Cloud Appliance認証局(CA)は、自己署名OpenSSLによって生成されたルートおよび中間x.509証明書です。 このCA証明書は、x.509サーバー/クライアント証明書を発行するために使用され、外部CA信頼情報をラックに追加できます。 ADFSに自己署名証明書を使用する場合は、ADFSの外部CA信頼情報をラックの管理ノードに追加する必要があります。

ノート:

metadataUrlプロパティを使用してアイデンティティ・プロバイダを作成または更新する場合は、アイデンティティ・プロバイダwebサーバー証明書チェーンをCAバンドル外のPrivate Cloud Applianceに追加する必要があります。 webサーバー証明書チェーンを検索し、次の手順のステップ3-8を実行する方法については、アイデンティティ・プロバイダのドキュメントを参照してください。

外部CA信託情報の追加

  1. ブラウザから、「ADFSからの必須情報の収集」の説明に従って、ADFSのSAMLメタデータ・ドキュメントをダウンロード

  2. テキストまたはXMLエディタでファイルを開き、署名証明書セクションを見つけます。 たとえば: 

    <KeyDescriptor use="signing">
<KeyInfo>
<X509Data>
<X509Certificate>
<!--CERTIFICATE IS HERE-->
</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>

  3. 管理ノード1にログオンします。 デフォルトでは、管理ノード1の名前はpcamn01です。

  4. /etc/pca3.0/vaultに移動し、customer_caという名前の新しいディレクトリを作成します。

    ノート:

    このディレクトリは、複数のファイルに使用できます。 たとえば、アイデンティティ・プロバイダ証明書とwebサーバー証明書チェーンのファイルを作成できます。

  5. customer_caディレクトリに、拡張子が.pemの新しいファイルを作成します。

  6. <X509Certificate>タグ・セットと</X509Certificate>タグ・セットの間にあるFederationMetadata.xmlファイルから証明書をコピーし、その証明書を新しい.pemファイルに貼り付けます。 必ず-----BEGIN CERTIFICATE-----および-----END CERTIFICATE-----行を含めてください。 たとえば: 

    -----BEGIN CERTIFICATE-----
CERTIFICATE CONTENT
-----END CERTIFICATE-----

  7. 保存してファイルを閉じます。

  8. 次のコマンドを実行して、すべての管理ノードでca_outside_bundle.crtを更新します: 

    python3 /usr/lib/python3.6/site-packages/pca_foundation/secret_service/cert_generator/cert_generator_app.py -copy_to_mns

アイデンティティ・プロバイダの管理

Private Cloud Applianceでアイデンティティ・プロバイダとフェデレートするには、「コンピュートWeb UI」でアイデンティティ・プロバイダを作成し、アカウント・グループをマップします。

この項では、アイデンティティ・プロバイダの更新方法(期限切れのときにメタデータXMLファイルを更新するなど)と、すべてのアイデンティティ・プロバイダの表示方法、アイデンティティ・プロバイダの詳細の表示方法、アイデンティティ・プロバイダの削除方法についても説明します。

アイデンティティ・プロバイダとしてのActive Directoryの追加

Private Cloud ApplianceでADとフェデレートするには、アイデンティティ・プロバイダとしてADを追加します。 ADをアイデンティティ・プロバイダとして追加するときにアカウント・グループをマップすることも、後でアカウント・グループをマップすることもできます。

重要:

ADをアイデンティティ・プロバイダとして追加する前に、すべてのPrivate Cloud Applianceグループが構成されていることを確認します。

「コンピュートWeb UI」の使用

  1. Private Cloud Applianceログインとパスワードを使用してサインインします。

  2. ナビゲーション・メニューを開き、アイデンティティ、フェデレーションの順にクリックします。

  3. フェデレーション・ページで、アイデンティティ・プロバイダの作成ボタンをクリックします。

  4. 「アイデンティティ・プロバイダの作成」ダイアログで、次の情報を指定します:

    1. 表示名

      フェデレーテッド・ユーザーが「コンピュートWeb UI」へのサインインに使用するアイデンティティ・プロバイダを選択したときに表示される名前。 この名前は、テナンシに追加するすべてのアイデンティティ・プロバイダで一意である必要があり、変更できません。

    2. 説明

      アイデンティティ・プロバイダのわかりやすい説明。

    3. 認証コンテキスト

      クラス参照の追加をクリックし、リストから認証コンテキストを選択します。

      1つ以上の値を指定した場合、Private Cloud Appliance (リライイング・パーティ)は、ユーザーの認証時に、指定した認証メカニズムのいずれかをアイデンティティ・プロバイダが使用することを想定します。 アイデンティティ・プロバイダから返されたSAMLレスポンスには、その認証コンテキスト・クラス参照を持つ認証文が含まれている必要があります。 SAMLレスポンス認証コンテキストがここで指定したものと一致しない場合、Private Cloud Appliance認証サービスはレスポンス・コード400でSAMLレスポンスを拒否します。

    4. アサーションの暗号化(オプション)

      有効にすると、認可サービスはアイデンティティ・プロバイダからの暗号化されたアサーションを想定します。 アサーションを復号化できるのは、認可サービスのみです。 有効にしない場合、認可サービスは、SAMLトークンが暗号化されていないがSSLで保護されていることを想定しています。

    5. 強制認証(オプション)

      有効にすると、ユーザーは、認可サービスによってリダイレクトされたときに、常にアイデンティティ・プロバイダで認証するよう求められます。 有効にしないと、アイデンティティ・プロバイダとのアクティブなログイン・セッションがすでにあるユーザーは再認証を求められません。

    6. メタデータ

      SAML 2.0準拠のアイデンティティ・プロバイダからFederationMetadata.xmlドキュメントをアップロードします。 ファイルをドラッグ・アンド・ドロップするか、XMLコンテンツを貼り付けることができます。

    7. タグ付け(オプション)

      「リソース作成時のタグの追加」の説明に従って、フリー・フォームまたは定義済のタグを追加します。 タグは後で適用することもできます。

  5. アイデンティティ・プロバイダの作成ボタンをクリックします。

    新しいアイデンティティ・プロバイダにOCIDが割り当てられ、フェデレーション・ページに表示されます。

アイデンティティ・プロバイダをテナンシに追加したら、「グループ・マッピングの作成」の説明に従って、Private Cloud ApplianceとActive Directoryの間のグループ・マッピングを作成します。

アイデンティティ・プロバイダのリスト

テナンシのすべてのアイデンティティ・プロバイダをリストするには、この手順を使用します。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    「フェデレーション」ページが開き、このテナンシで構成されているすべてのアイデンティティ・プロバイダのリストが表示されます。

OCI CLIの使用

  1. 次の情報を取得します:

    • テナンシのOCID ( oci iam compartment list -include-root)

    • フェデレーションに使用されるプロトコル( SAML2)

  2. アイデンティティ・プロバイダ・リスト・コマンドを実行します。

    $ oci iam identity-provider list -c ocid1.tenancy.unique_ID \
--protocol SAML2
アイデンティティ・プロバイダの詳細の表示

特定のアイデンティティ・プロバイダの詳細情報を表示するには、この手順を使用します。

アイデンティティ・プロバイダに表示される詳細には、OCID、認証コンテキストおよびリダイレクトURLなどの設定が含まれます。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    このテナンシで構成されているアイデンティティ・プロバイダがリストされます。

  2. 詳細を表示するアイデンティティ・プロバイダについて、アクション・メニューをクリックし、詳細の表示をクリックします。

    そのアイデンティティ・プロバイダの詳細ページが表示されます。

OCI CLIの使用

  1. アイデンティティ・プロバイダのOCIDを取得します( oci iam identity-provider list)

  2. アイデンティティ・プロバイダgetコマンドを実行します。

    $ oci iam identity-provider get --identity-provider-id ocid1.identityprovider.unique_ID
アイデンティティ・プロバイダの更新

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    このテナンシで構成されているアイデンティティ・プロバイダがリストされます。

  2. 更新するアイデンティティ・プロバイダに対して、アクション・メニューをクリックし、編集をクリックします。

  3. 次のいずれかの情報を変更できます。 詳細は、「アイデンティティ・プロバイダとしてのActive Directoryの追加」のステップ4を参照してください。 これらの変更の一部がフェデレーションに与える影響を考慮してください。

    • 説明

    • 認証コンテキスト

      クラス参照を追加または削除します。

    • アサーションの暗号化

      アイデンティティ・プロバイダから暗号化されたアサーションを有効または無効にします。

    • 強制認証

      アイデンティティ・プロバイダからのリダイレクト認証を有効または無効にします。

    • メタデータ

      アイデンティティ・プロバイダから新しいFederationMetadata.xmlドキュメントをアップロードします。

    • タグ付け

      フリー・フォームまたは定義済タグを追加または削除します。

  4. アイデンティティ・プロバイダの更新ボタンをクリックします。

アイデンティティ・プロバイダの削除

フェデレーテッド・ユーザーがPrivate Cloud Applianceにログインするためのオプションを削除する場合は、アイデンティティ・プロバイダを削除する必要があります。 アイデンティティ・プロバイダを削除すると、関連するすべてのグループ・マッピングも削除されます。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    このテナンシで構成されているアイデンティティ・プロバイダがリストされます。

  2. 削除するアイデンティティ・プロバイダに対して、アクション・メニューをクリックし、削除をクリックします。

  3. Delete Identity Providerプロンプトで、Confirmをクリックします。

    成功ポップアップが一時的に表示され、アイデンティティ・プロバイダはフェデレーション・リストに表示されなくなります。

アイデンティティ・プロバイダのグループ・マッピングの操作

グループ・マッピングを使用する場合は、次の点に注意してください:

  • 特定のADグループが単一のPrivate Cloud Applianceグループにマップされます。

  • Private Cloud Applianceグループ名にはスペースを含めることはできず、後で変更できません。 使用できる文字は、文字、数字、ハイフン、ピリオド、アンダースコアおよびプラス記号(+)です。

  • グループ・マッピングは更新できません。 マッピングを削除し、新しいマッピングを追加できます。

グループ・マッピングの作成

アイデンティティ・プロバイダを作成したら、ADFSグループからPrivate Cloud Applianceグループへのマッピングを作成する必要があります。

マップするアイデンティティ・プロバイダ・グループごとに、次の手順を繰り返します。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    このテナンシで構成されているアイデンティティ・プロバイダがリストされます。

  2. グループ・マッピングを作成するアイデンティティ・プロバイダをクリックします。

    そのアイデンティティ・プロバイダの詳細ページが表示されます。

  3. リソース・セクションまでスクロールし、グループ・マッピングをクリックします。

    このアイデンティティ・プロバイダのグループ・マッピングがリストされます。

  4. マッピングの追加ボタンをクリックします。

    「IDPグループ・マッピングの作成」ダイアログが表示されます。

  5. 名前フィールドに、アイデンティティ・プロバイダ・グループの「正確な」名を入力します。

  6. グループ・リストから、アイデンティティ・プロバイダ・グループにマップするPrivate Cloud Applianceグループを選択します。

  7. Create IDP Group Mappingをクリックします。

    新しいグループ・マッピングがリストに表示されます。

グループ・マッピングの表示

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    このテナンシで構成されているアイデンティティ・プロバイダがリストされます。

  2. アイデンティティ・プロバイダの名前をクリックします。

    そのアイデンティティ・プロバイダの詳細ページが表示されます。

  3. リソース・セクションまでスクロールし、グループ・マッピングをクリックします。

    このアイデンティティ・プロバイダのグループ・マッピングがリストされます。

グループ・マッピングの削除

削除するアイデンティティ・プロバイダ・グループごとに、次の手順を繰り返します。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューを開き、アイデンティティをクリックしてからフェデレーションをクリックします。

    このテナンシで構成されているアイデンティティ・プロバイダがリストされます。

  2. グループ・マッピングを削除するアイデンティティ・プロバイダをクリックします。

    そのアイデンティティ・プロバイダの詳細ページが表示されます。

  3. リソース・セクションまでスクロールし、グループ・マッピングをクリックします。

    このアイデンティティ・プロバイダのグループ・マッピングがリストされます。

  4. 削除するグループ・マッピングについて、処理メニューをクリックし、削除をクリックします。

  5. プロンプトが表示されたら、確認をクリックします。

    成功ポップアップが簡潔に表示され、アイデンティティ・プロバイダ・グループ・マッピングがグループ・マッピング・リストに表示されなくなります。

ADFSでの信頼できるリライイング・パーティとしてのOracle Private Cloud Applianceの追加

重要:

ADFSがPrivate Cloud Appliance証明書を信頼できるように、Private Cloud Appliance証明書バンドルをADに追加する必要があります。 これを行わない場合、ユーザー・ログインは失敗します。 Private Cloud Appliance証明書バンドルの詳細は、「認証局バンドルの取得」を参照してください。

フェデレーション・プロセスを完了するには、ADFSで信頼できるリライイング・パーティとしてPrivate Cloud Applianceを追加し、関連するリライイング・パーティ要求ルールを追加する必要があります。

  1. フェデレーション・ページの「コンピュートWeb UI」で、次のテキスト・ブロックを表示します:

    Microsoft Active Directory Federation Servicesまたは他のSAML 2.0準拠アイデンティティ・プロバイダとの信頼を設定する場合は、Private Cloud Applianceフェデレーション・メタデータ・ドキュメントが必要です。 これは、Private Cloud Applianceエンドポイントおよび証明書情報を説明するXMLドキュメントです。 ここをクリック

  2. "Click Here"をクリックします。

    ブラウザでメタデータXMLファイルが開き、次のようなURLが表示されます:

    https://console.system-name.domain-name/wsapi/rest/saml/metadata/ocid1.tenancy.unique_ID

  3. メタデータXMLファイルURLをコピーします。

  4. ADFSとともにインストールされたシステムから、ブラウザ・ウィンドウを開き、URLを貼り付けます。

  5. ファイルを保存し、.xml拡張子を使用してください。 たとえば、my-sp-metadata.xmlです。

  6. AD FS管理コンソールに移動し、フェデレートするアカウントにサインインします。

  7. 信頼できるリライイング・パーティとしてPrivate Cloud Applianceを追加します。

    1. AD FSで、リライイング・パーティ信頼を右クリックし、リライイング・パーティ信頼の追加を選択します。

    2. 「リライイング・パーティ信頼の追加ウィザードのようこそ」ページで、請求認識を選択し、開始をクリックします。

    3. 「データ・ソースの選択」ページで、「リライイング・パーティに関するデータをファイルからインポート」を選択します。

    4. 参照をクリックしてmy-sp-metadata.xmlファイルに移動し、開くをクリックします。

    5. 「表示名」の指定ページで、表示名を入力し、リライイング・パーティのオプションのノートを追加し、次をクリックします。

    6. 「アクセス制御ポリシーの選択」ページで、付与するアクセスのタイプを選択し、次へをクリックします。

    7. 追加準備完了「信託」ページで設定を確認し、次をクリックしてリライイング・パーティの信頼情報を保存します。

    8. 終了ページで、「このアプリケーションの要求発行ポリシーを構成」を選択し、閉じるをクリックします。

      「請求発行ポリシーの編集」ダイアログが表示され、次のセクションで開いたままにできます。

リライイング・パーティ要求ルールの追加

信頼できるリライイング・パーティとしてPrivate Cloud Applianceを追加した後、必要な要素(Name IDおよびグループ)がSAML認証レスポンスに追加されるように要求ルールを追加する必要があります。

名前IDルールを追加するには:

  1. 「請求発行ポリシー」の編集ダイアログで、ルールの追加をクリックします。

    「ルール・テンプレートの選択」ダイアログが表示されます。

  2. 請求ルール・テンプレートの場合、受信請求の変換を選択し、次へをクリックします。

  3. 次のように入力します。

    • 要求ルール名: このルールの名前を入力します。 たとえば、nameidです。

    • 受信要求タイプ: Microsoft Windowsアカウント名を選択します。

    • 発信要求タイプ: 氏名IDなどの請求タイプを選択します。

    • 送信名IDフォーマット: Persistent Identifierを選択します。

    • すべての要求値をパススルーを選択し、終了をクリックします。

      ルールがルール・リストに表示されます。

「発行変換ルール」ダイアログに、新しいルールが表示されます。

ADユーザーが100グループ以下の場合は、グループ・ルールを追加します。 ただし、ADユーザーが100を超えるグループに属している場合、これらのユーザーはPrivate Cloud Appliance 「コンピュートWeb UI」を使用するように認証できません。 これらのグループについては、グループ・ルールにフィルタを適用する必要があります。

グループ・ルールを追加するには:

  1. 「発行変換ルール」ダイアログで、ルールの追加をクリックします。

    「ルール・テンプレートの選択」ダイアログが表示されます。

  2. 請求ルール・テンプレートで、カスタム・ルールを使用した請求の送信を選択し、次へをクリックします。

  3. 変換要求ルールの追加ウィザードで、次を入力します:

    1. 要求ルール名: グループを入力します。

    2. カスタム・ルール: カスタム・ルールを入力します。 

      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("https://auth.oraclecloud.com/saml/claims/groupName"), query = ";tokenGroups;{0}", param = c.Value);

    3. 「終了」をクリックします。

「発行変換ルール」ダイアログに、新しいルールが表示されます。

グループのポリシーの設定

フェデレーテッド・ユーザーがPrivate Cloud Applianceリソースに対して持つアクセスを制御するポリシーを構成します。 ポリシーの一般情報は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。 詳細については、「ポリシーの管理」を参照してください。

フェデレーテッド・ユーザーのサインイン情報の指定

フェデレーテッド・ユーザーがPrivate Cloud Appliance コンピュートWeb UIにログインできるようにするには、次の手順を実行します:

  • URLforに「コンピュートWeb UI」を指定します。

  • アクセス権を持つテナンシの名前をユーザーに指定します。

  • 必要なグループ・マッピングが構成されていることを確認します。

  • 必要なポリシーが構成されていることを確認します。

重要:

フェデレーテッド・ユーザーは、OCI CLIを使用してPrivate Cloud Applianceにログインできません。