テナンシを設定するためのベスト・プラクティスについて学習
Oracle Cloud Infrastructureにテナンシが作成された後、会社の管理者は、設定タスクを実行してクラウド・リソースおよびユーザーの組織プランを策定する必要があります。作業の開始に役立つこのトピックの情報を使用してください。
テナンシの管理の詳細は、テナンシ管理も参照してください。
プランの作成
ユーザーおよびリソースを追加する前に、テナンシのプランを作成する必要があります。プランを作成するには、基礎知識としてOracle Cloud Infrastructure Identity and Access Management (IAM)のコンポーネントを理解している必要があります。IAMの機能を把握し、理解していることを確認します。Identity and Access Managementの概要を参照してください。
プランには、リソースを編成するためのコンパートメント階層と、リソースへのアクセスを必要とするユーザー・グループの定義を含める必要があります。これら2つの要素は、アクセスを管理するためのポリシーの記述方法に影響するため、まとめて検討する必要があります。
プランの開始に役立つ次の入門トピックを参照してください:
コンパートメントの理解
コンパートメントは、クラウド・リソースの編成に使用する主要なビルディング・ブロックです。コンパートメントを使用してリソースを編成および分離すると、管理とアクセス保護が容易になります。
テナンシがプロビジョニングされると、ルート・コンパートメントが自動的に作成されます(テナンシはルート・コンパートメントです)。ルート・コンパートメントには、すべてのクラウド・リソースが保持されます。ルート・コンパートメントはファイル・システムのルート・フォルダのようなものと考えることができます。
初めてコンソールにサインインしてサービスを選択すると、1つのルート・コンパートメントが表示されます。
ルート・コンパートメントの下にコンパートメントを作成し、リソース管理目標に合致するようにクラウド・リソースを編成できます。コンパートメントを作成する際は、ユーザー・グループがそのコンパートメントのリソースに対して実行できるアクションを指定するポリシーを作成することで、コンパートメントへのアクセスを制御します。
コンパートメントの操作を開始する際は、次の点に注意してください:
- リソース(インスタンス、ブロック・ストレージ・ボリューム、VCN、サブネットなど)を作成する時点で、どのコンパートメントにそれを配置するかを決定する必要があります。
- コンパートメントは、物理的ではなく論理的であるため、関連するリソース・コンポーネントを異なるコンパートメントに配置できます。たとえば、インターネット・ゲートウェイへのアクセス権を持つクラウド・ネットワーク・サブネットは、同じクラウド・ネットワーク内の他のサブネットとは別のコンパートメントに保護できます。
- テナンシ(ルート・コンパートメント)の下に、最大6つのコンパートメントの階層を作成できます。
- リソースへのアクセス権をユーザー・グループに付与するポリシー・ルールを記述する場合、アクセス・ルールを適用するコンパートメントを常に指定します。そのため、リソースをコンパートメント間で分散する場合、それらのリソースへのアクセス権を必要とするユーザー用に、各コンパートメントに適切な権限を付与する必要があることに注意してください。
- コンソールでは、コンパートメントはリソースを表示するためのフィルタと同様に動作します。コンパートメントを選択すると、選択したコンパートメント内のリソースのみが表示されます。別のコンパートメントのリソースを表示するには、最初にそのコンパートメントを選択する必要があります。検索機能を使用して、複数のコンパートメントにわたるリソースのリストを取得できます。検索の概要を参照してください。
- テナンシ・エクスプローラを使用すると、特定のコンパートメントに存在するすべてのリソース(リージョンにまたがる)の完全なビューを取得できます。コンパートメント内のすべてのリソースの表示を参照してください。
- コンパートメントを削除する場合、最初にコンパートメントのすべてのリソースを削除する必要があります。
- コンパートメントを計画する場合、使用状況および監査データの集計方法を検討する必要があります。
誰がどのリソースにアクセスする必要があるかの検討
テナンシの設定を計画する際のもう1つの主な検討事項は、誰がどのリソースにアクセスする必要があるかということです。様々なユーザー・グループがリソースにアクセスする方法を定義することで、リソースを最も効率的に編成する方法を計画し、アクセス・ポリシーを簡単に記述して維持できます。
たとえば、次の操作を必要とするユーザーが考えられます:
- コンソールを表示しますが、リソースを編集または作成することはできません
- 複数のコンパートメント間で特定のリソースを作成および更新します(たとえば、クラウド・ネットワークとサブネットを管理する必要があるネットワーク管理者)
- インスタンスとブロック・ボリュームを起動および管理しますが、クラウド・ネットワークにアクセスすることはできません
- すべてのリソースに対する完全な権限を持ちますが、特定のコンパートメント内のみに限定されます
- 他のユーザーの権限および資格証明を管理します
サンプル・ポリシーを確認するには、「共通ポリシー」を参照してください。
コンパートメントを設定するためのサンプル・アプローチ
テナンシ(ルート・コンパートメント)へのすべてのリソースの配置
組織が小規模な場合、またはOracle Cloud Infrastructureを評価する概念実証の段階にいる場合は、ルート・コンパートメント(テナンシ)にすべてのリソースを配置することを検討します。このアプローチにより、すべてのリソースを迅速に表示して管理することが簡単になります。さらに、ポリシーを記述してグループを作成し、特定のリソースに対する権限を、アクセスを必要とするユーザーのみに制限できます。
単一コンパートメント・アプローチを設定するための概要タスク:
- (ベスト・プラクティス)サンドボックス・コンパートメントを作成します。ルート・コンパートメントでリソースを維持するプランであっても、機能を試すことができる専用の領域をユーザーに提供するため、サンドボックス・コンパートメントを設定することをお薦めします。サンドボックス・コンパートメントではリソースを作成および管理する権限をユーザーに付与できる一方で、テナンシ(ルート)・コンパートメントではリソースに対するより厳格な権限を維持できます。「サンドボックス・コンパートメントの作成」を参照してください。
- グループとポリシーを作成します。共通ポリシーを参照してください。
- ユーザーを追加します。ユーザーの管理を参照してください。
会社のプロジェクトに合致したコンパートメントの作成
このアプローチは、個別管理が必要な部門が会社に複数ある場合や、個別の方が管理しやすいプロジェクトが複数ある場合に検討します。
このアプローチでは、各コンパートメント(プロジェクト)について、そのプロジェクトのみにアクセス・ポリシーを設定できる専用の管理者グループを追加できます。(ユーザーとグループは、まだテナンシ・レベルで追加する必要があります。)1つのグループにすべてのリソースに対する制御を付与する一方で、ルート・コンパートメントまたは他のプロジェクトに対する管理者権限を付与しないようにできます。このようにして、社内の様々なグループが独自のリソースに対して独自のサブクラウドを設定し、それらを独立して管理できるようにすることが可能です。
複数プロジェクト・アプローチを設定するための概要タスク:
- サンドボックス・コンパートメントを作成します。機能を試すことができる専用の領域をユーザーに提供するため、サンドボックス・コンパートメントを設定することをお薦めします。サンドボックス・コンパートメントではリソースを作成および管理する権限をユーザーに付与できる一方で、テナンシ(ルート)・コンパートメントではリソースに対するより厳格な権限を維持できます。
- ProjectAやProjectBなど、各プロジェクトのコンパートメントを作成します。
- ProjectA_Adminsなど、各プロジェクトの管理者グループを作成します。
-
各管理者グループのポリシーを作成します。
例:Allow group ProjectA_Admins to manage all-resources in compartment ProjectA) - ユーザーを追加します。ユーザーの管理を参照してください。
- ProjectAおよびProjectBの管理者に、指定されたコンパートメント内にサブコンパートメントを作成してリソースを管理することを許可します。
- ProjectAおよびProjectBの管理者に、各自のコンパートメントへのアクセスを管理するポリシーを作成することを許可します。
セキュリティ要件に合せたコンパートメントの作成
会社に、異なるレベルのセキュリティを必要とするプロジェクトまたはアプリケーションがある場合は、このアプローチを検討してください。
セキュリティ・ゾーンは、コンパートメントおよびセキュリティ・ゾーン・レシピに関連付けられます。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureでは、これらの操作がセキュリティ・ゾーン・レシピのポリシーに対して検証されます。セキュリティ・ゾーン・ポリシーに違反している場合、操作は拒否されます。サブコンパートメントがある場合、デフォルトでは、セキュリティ・ゾーンは同一になります。
セキュリティ・ゾーン・ポリシーは、次のようなOracleセキュリティ原則に準拠しています:
- セキュリティ・ゾーンにないコンパートメントは安全性が低い可能性があるため、そのコンパートメントにセキュリティ・ゾーンのデータをコピーすることはできません。
- セキュリティ・ゾーン内のリソースにパブリック・インターネットからアクセスできないようにする必要があります。
- セキュリティ・ゾーン内のリソースは、Oracleによって承認された構成およびテンプレートのみを使用する必要があります。
このアプローチでは、最高レベルのセキュリティ・アーキテクチャとベスト・プラクティスに準拠する必要があるプロジェクトのコンパートメントとセキュリティ・ゾーンを作成します。このレベルのセキュリティ・コンプライアンスが不要なプロジェクトの場合は、セキュリティ・ゾーンの外にコンパートメントを作成します。また、お客様のセキュリティ・ゾーン用にカスタム・レシピを作成して、使用可能なポリシーのサブセットのみを有効にすることも可能です。
前述のアプローチと同様に、コンパートメントごとに、その単一プロジェクトのアクセス・ポリシーを設定できる専用の管理者グループを追加できます。
- アクセス(IAM)ポリシーは、コンパートメント内の特定のリソースを管理する権限をユーザーに付与します。
- セキュリティ・ゾーン・ポリシーは、セキュリティ・ゾーン・コンパートメントの管理操作がOracleのセキュリティ・ベスト・プラクティスに確実に準拠するようにします。
データの整合性を確保するため、特定のリソースは、セキュリティ・ゾーン内のコンパートメントから、セキュリティ・ゾーン外のコンパートメントに移動できません。
詳細は、「セキュリティ・ゾーンの概要」を参照してください。