機械翻訳について

第2章 Identity and Access Management

目次

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

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

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

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

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

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

2.1.1 ユーザーの作成

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

コンピュートWeb UIの使用

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

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

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

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

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

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

      • 後で変更できません。

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

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

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

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

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

      • 後で変更できます。

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

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

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

      ノート

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

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

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

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

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

    次のステップ:

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

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

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

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

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

OCI CLIの使用

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

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

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

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

    構文

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

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

    例:

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

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

    次のステップ:

2.1.2 一時コンピュートWeb UIパスワードの指定

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

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

ノート

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

コンピュートWeb UIの使用

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

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

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

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

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

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

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

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

OCI CLIの使用

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

  2. ユーザーのCompute Web UIパスワード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値をコピーし、この一時的なワンタイム・パスワードをユーザーに提供します。 ユーザーは、新しいパスワードを設定するときに、第2.1.3項、「独自のコンピュートWeb UIパスワードの設定」に記載されているルールに従う必要があります。

2.1.3 独自のコンピュートWeb UIパスワードの設定

ユーザーは、自分のCompute Web UIパスワードを設定または変更するためのアクセス・ポリシーを必要としません。

2.1.3.1 パスワードの設定

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

コンピュートWeb UIの使用

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

  2. Compute Web UIのログイン画面で、ユーザー名を入力します。

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

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

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

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

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

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

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

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

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

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

2.1.3.2 パスワードの変更

現在のパスワードの動作中にCompute Web UIのパスワードを変更するには、この手順を使用します。

コンピュートWeb UIの使用

  1. Compute Web UIの右上隅にあるユーザー・メニューをクリックします。

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

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

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

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

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

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

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

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

コンピュート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コマンドは、グループ・メンバーシップを表示しません。

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

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

コンピュートWeb UIの使用

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

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

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

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

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

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

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

OCI CLIの使用

  1. OCI CLI手順については、第2.2.3項、「グループの更新によるグループへのユーザーの追加」を参照してください。

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

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

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

コンピュートWeb UIの使用

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

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

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

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

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

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

OCI CLIの使用

  1. OCI CLI手順については、第2.2.4項、「グループの更新によるグループからのユーザーの削除」を参照してください。

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

2.1.7 ユーザーの変更

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

コンピュート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コマンドの出力と同じです。

2.1.8 ユーザーの削除

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

ユーザーを削除すると、そのユーザー・アカウントに関連付けられているすべての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オプションを使用します。

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

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

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

2.2.1 グループの作成

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

コンピュートWeb UIの使用

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

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

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

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

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

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

      • 後で変更できません。

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

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

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

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

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

      • 後で変更できます。

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

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

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

    次のステップ:

OCI CLIの使用

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

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

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

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

    構文:

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

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

    例:

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

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

    次のステップ:

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

コンピュート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コマンドはメンバー・ユーザーを表示しません。

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

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

コンピュート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"
  }
}

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

コンピュート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

2.2.5 グループの変更

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

コンピュートWeb UIの使用

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

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

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

  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コマンドの出力と同じです。

2.2.6 グループの削除

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

コンピュート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オプションを使用します。

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

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

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

2.3.1 テナンシの理解

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

ユーザー、グループおよびアイデンティティ・プロバイダは、テナンシのコンパートメントではなく、常にテナンシに直接アタッチされます。 ユーザー、グループまたはアイデンティティ・プロバイダを作成する場合、別のコンパートメントを指定することはできません。 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コンパートメントの親コンパートメントです。

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

コンピュート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

2.3.3 コンパートメントの作成

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

コンピュートWeb UIの使用

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

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

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

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

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

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

      • 後で変更できます。

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

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

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

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

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

  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のコンピュート手順を参照してください。 定義済タグおよびフリー・フォーム・タグを追加するには、第3.4.1項、「リソース作成時のタグの追加」を参照してください。

    例:

    $ 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コマンドを使用します。

2.3.4 タグのデフォルトの適用

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

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

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

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

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

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

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

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

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

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

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

2.3.7 コンパートメントの更新

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

コンピュートWeb UIの使用

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

  2. 更新するコンパートメントがリストに表示されない場合は、第2.3.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オプションを指定する場合は、保持するコンパートメントにすでに存在するタグを含め、このコンパートメントに必要なすべての定義済タグおよびフリー・フォーム・タグを完全に指定する必要があります。 これらのタグ・オプションに指定する値は、既存の値を置換します。 第3.4項、「リソース・タグの操作」を参照してください。 --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コマンドの出力と同じです。

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

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

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

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

「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で作業リクエストの詳細を表示します。 一部のリソースは、コンパートメントよりも移動に時間がかかる場合があります。

2.3.9 コンパートメントの削除

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

コンピュートWeb UIの使用

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

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

  2. 削除するコンパートメントがリストに表示されていない場合は、第2.3.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コマンドを使用して、コンパートメントの削除のステータスを確認します。

2.4 ポリシーの管理

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

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

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

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

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

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

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

2.4.1 ポリシーの作成

始める前に

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

コンピュートWeb UIの使用

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

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

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

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

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

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

      • 後で変更できません。

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

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

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

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

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

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

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

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

OCI CLIの使用

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

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

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

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

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

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

    構文:

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

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

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

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

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

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

ノート

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

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

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

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

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

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概要」にある「ポリシー構文」の「動詞」を参照してください。

  • 次の形式の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概要」にある「ポリシー構文」の「リソース・タイプ」の表を参照してください。

compartment

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

  • compartment compartment_name

  • compartment id compartment_OCID

  • tenancy

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

condition

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

2.4.2.2 条件の使用

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

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

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

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

target.resource.tag

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

target.resource.compartment.tag

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

例: 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

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

例: 定義済タグの適用

次の例では、グループ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'

2.4.2.3 適用できない条件

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

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

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

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

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

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

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

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

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

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

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

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

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'

2.4.2.5 ポリシーの更新

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OCI CLIの使用

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

    $ oci iam policy list --compartment-id compartment_OCID

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

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

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

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

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

  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コマンドと同じ出力を返します。

2.4.3 ポリシーの削除

コンピュート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コマンドと同じ出力を返します。

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

多くの企業は、アイデンティティ・プロバイダを使用してユーザー・ログインとパスワードを管理し、セキュアなwebサイト、サービスおよびリソースへのアクセスについてユーザーを認証します。 Oracle Private Cloud Appliance Compute Web UIにアクセスするには、ユーザーはユーザー名とパスワードを使用してサインインする必要もあります。 管理者は、クラウド・リソースにアクセスして使用するための新しい資格証明を作成するのではなく、各ユーザーが既存のログインとパスワードを使用できるように、サポートされているアイデンティティ・プロバイダで「連邦」できます。

フェデレーションには、アイデンティティ・プロバイダとOracle Private Cloud Applianceの間の信頼関係の設定が含まれます。 管理者がこの関係を確立すると、フェデレーテッド・ユーザーはコンピュートWeb UIにアクセスするときに「シングル・サインオン」を求められます。

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

複数のActive Directory (AD)アカウントをOracle Private Cloud Appliance (組織の部門ごとに1つなど)とフェデレートできますが、設定する各フェデレーション・トラストは、「全部」 ADアカウント用である必要があります。 信頼を設定するには、Oracle Private Cloud Appliance Compute Web UIおよびActive Directory Federation Services (ADFS)の一部のタスクを実行します。

連邦政府を始める前に、次の情報がすでにあることを確認してください:

  • 組織のMicrosoft Active Directory Federation Servicesをインストールして構成します。

  • Active Directoryで、Oracle Private Cloud Applianceのグループにマップするグループを設定します。

  • Oracle Private Cloud Appliance Compute Web UIにサインインするユーザーがActive Directoryに作成されました。

ノート

PCA_Administrators、PCA_NetworkAdmins、PCA_InstanceLaunchersなどのフィルタ・ルールを簡単に適用できるように、共通のプレフィクスを使用してOracle Private Cloud ApplianceグループにマップするActive Directoryグループに名前を付けることを検討してください。

2.5.1 ADFSからの必須情報の収集

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

  1. ADFSのSAMLメタデータ・ドキュメントを検索してダウンロードします。デフォルトでは、次の場所にあります:

    https://<yourservername>/FederationMetadata/2007-06/FederationMetadata.xml

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

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

    重要

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

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

重要

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

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

ノート

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

外部CA信頼情報を追加するには、次のステップを実行します:

  1. ブラウザから、次のURLを入力し、ADFSのSAMLメタデータ・ドキュメントをダウンロードします(デフォルトは次のとおりです):

    https://<yourservername>/FederationMetadata/2007-06/FederationMetadata.xml

  2. テキスト・エディタまたはXMLエディタでファイルを開き、次のように署名証明書セクションを見つけます:

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

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

  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

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

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

アイデンティティ・プロバイダを作成した後、更新が必要な場合があります。 たとえば、メタデータXMLファイルは期限切れになったときに更新する必要があります。 また、すべてのアイデンティティ・プロバイダを表示したり、アイデンティティ・プロバイダの詳細を表示したり、アイデンティティ・プロバイダを削除することもできます。

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

Oracle Private Cloud ApplianceでActive Directoryとフェデレートするには、それをアイデンティティ・プロバイダとして追加する必要があります。 同時に、グループ・マッピングを設定することも、後で設定することもできます。

ADをアイデンティティ・プロバイダとして追加するには、コンピュートWeb UIの手順に従います。

コンピュートWeb UIの使用

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

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

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

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

    1. 表示名

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

    2. 摘要

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

    3. 認証コンテキスト

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

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

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

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

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

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

    6. メタデータ

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

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

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

  5. Create Identity Providerをクリックします。

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

アイデンティティ・プロバイダをテナンシに追加した後、Oracle Private Cloud ApplianceとActive Directoryの間のグループ・マッピングを設定する必要があります。

グループ・マッピングを設定するには、第2.5.4.1項、「グループ・マッピングの作成」を参照してください。

2.5.3.2 アイデンティティ・プロバイダの更新

アイデンティティ・プロバイダを更新するには、コンピュートWeb UIの手順に従います。

コンピュートWeb UIの使用

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

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

  2. 更新するアイデンティティ・プロバイダについて、アクション・アイコン(3つのドット)をクリックし、編集をクリックします。

  3. 次の情報のいずれかを変更します。ただし、この情報を変更するとフェデレーションに影響を与える可能性があることに注意してください:

    • 摘要

    • 認証コンテキスト

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

    • アサーションの暗号化

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

    • 強制認証

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

    • メタデータ

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

    • タグ付け

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

    詳細は、第2.5.3.1項、「アイデンティティ・プロバイダとしてのActive Directoryの追加」のステップ4を参照してください

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

2.5.3.3 アイデンティティ・プロバイダの詳細の表示

アイデンティティ・プロバイダの詳細ページには、OCIDや認証コンテキストなどの一般情報が表示されます。 また、リダイレクトURLを含むアイデンティティ・プロバイダ設定も提供します。

このページから、アイデンティティ・プロバイダを編集し、グループ・マッピングを管理することもできます。

アイデンティティ・プロバイダの詳細を表示するには、コンピュートWeb UIまたはOCI CLIの手順に従います。

コンピュートWeb UIの使用

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

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

  2. 詳細を表示するアイデンティティ・プロバイダについて、アクション・アイコン(3つのドット)をクリックし、詳細の表示をクリックします。

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

OCI CLIの使用

  1. 必要なOCIDを検索します:

    • (oci iam identity-provider list)

  2. コマンドに続けて必要なパラメータを入力します。

    構文

    oci iam identity-provider get --identity-provider-id identity-provider-ocid

    例

    # oci iam identity-provider get --identity-provider-id ocid1....unique-id

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

テナンシのアイデンティティ・プロバイダをリストするには、コンピュートWeb UIまたはOCI CLIの手順に従います。

コンピュートWeb UIの使用

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

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

OCI CLIの使用

  1. 必要なOCIDを検索します:

    • (oci iam compartment list -include-root)

  2. コマンドに続けて必要なパラメータを入力します。

    構文

    oci iam identity-provider list --compartment-id tenancy-ocid

    例

    # oci iam identity-provider list --compartment-id ocid1.tenancy....unique-id

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

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

アイデンティティ・プロバイダを削除するには、コンピュートWeb UIの手順に従います。

コンピュートWeb UIの使用

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

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

  2. 削除するアイデンティティ・プロバイダについて、アクション・アイコン(3つのドット)をクリックし、削除をクリックします。

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

    簡単なSuccessポップアップが表示され、アイデンティティ・プロバイダがフェデレーション・リストに表示されなくなります。

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

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

  • 指定されたActive Directoryグループは、単一のOracle Private Cloud Applianceグループにマップされます。

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

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

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

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

グループ・マッピングを作成するには、コンピュートWeb UIの手順に従います。 マップする各アイデンティティ・プロバイダ・グループに対してステップを繰り返します。

コンピュートWeb UIの使用

  1. ナビゲーション・メニューを開き、識別をクリックし、フェデレーションをクリックします。

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

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

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

  3. リソース・セクションで、マッピングの追加をクリックします。

    IDPグループ・マッピング・フォームが表示されます

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

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

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

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

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

グループ・マッピングの詳細を表示するには、コンピュートWeb UIの手順に従います。

コンピュートWeb UIの使用

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

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

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

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

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

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

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

グループ・マッピングを削除するには、コンピュートWeb UIの手順に従います。 削除するアイデンティティ・プロバイダ・グループごとにステップを繰り返します。

コンピュートWeb UIの使用

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

    テナンシ内のアイデンティティ・プロバイダのリストが表示されます。

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

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

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

    削除するグループ・マッピングについて、アクション・アイコン(3つのドット)をクリックし、削除をクリックします。

  4. 要求されたら、確認します。

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

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

重要

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

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

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

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

  2. 「ここをクリック」をクリックします。

    ブラウザでメタデータ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. 信頼できるリライイング・パーティとしてOracle Private Cloud Applianceを追加します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 要求ルール名: このルールの名前を入力します(例: nameid)。

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

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

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

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

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

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

Active Directoryユーザーが100グループを超えない場合、単にグループ・ルールを追加します。 ただし、Active Directoryユーザーが100グループを超える場合、それらのユーザーはOracle Private Cloud Appliance Compute 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. 「終了」をクリックします。

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

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

まだ実行していない場合は、組織Oracle Private Cloud Applianceリソースへのフェデレーテッド・ユーザーのアクセスを制御するIAMポリシーを設定します。 詳細は、「Identity and Access Management概要」を参照してください

2.5.7 フェデレーテッド・ユーザーのサインイン情報の提供

フェデレーテッド・ユーザーがOracle Private Cloud Appliance Compute Web UIにログインする前に、それらにアクセス権のあるテナントのURLと名前を指定する必要があります。 また、グループ・マッピングを構成したことを確認する必要があります。そうしないと、フェデレーテッド・ユーザーはOracle Private Cloud Applianceで作業できません。

重要

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

Copyright © 2013, 2022, Oracle and/or its affiliates.