ドメイン管理者の考慮事項

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む13読むのに数分

    • 顧客のドメイン分離を構成する前に、次の考慮事項を検証してから Cloud Provisioning and Governance アプリケーションで管理している各ドメインのクラウドリソースをプロビジョニングしたことを確認してください。

    概要

    次のセクションでは、サービスプロバイダーが管理する会社に対してドメイン管理者が実行するアクティビティを一覧表示します。クラウド管理ポータルを使用して、サービスアカウントとクラウドアカウントを設定します。ユーザーがプロビジョニングしたりライフサイクル運用を実行する前に、クラウドリソース用に設定可能な事前プロビジョニング操作を作成します。

    強力なユニバーサルプロセス標準、データ主導型のプロセス設計、厳格なガバナンス、および集中管理により、単一インスタンス内の Cloud Provisioning and Governance でのドメイン分離のこれらのメリットを最大限に活用できます。ドメイン admin ロールは、サービスプロバイダーの組織内のユーザーに厳密に制限され、顧客の組織のクラウド管理者ユーザーにはアサインされません。この制限により、SP は、顧客が他のドメインのデータにフルアクセスしないようにできます。データは複数のクライアント間で共有されるため、ドメイン管理者はデータ漏洩につながる可能性のあるアクセス許可を公開したり提供したりしないでください。

    クラウドリソースのプロビジョニング

    • 関連するサービスアカウントを各ドメインのクラウドアカウントにマップしていることを確認します。たとえば、Azure クラウドからプライマリサブスクリプションを検出すると、1 つ以上の子サービスアカウントが作成され、それらは同じドメインに作成されます。つまり、Azure クラウドのマスターサブスクリプション内のすべてのサービスアカウントは、単一の会社とドメインだけに属している必要があります。

      root_admin または cloud_admin ロールを持つユーザーでログインし、クラウドおよびサービスアカウントの設定や、任意ドメインの検出を実行しします。Discovery またはクラウドアカウントとサービスアカウントの作成とマッピングなどのアクションを実行する場合は、ドメインピッカーを使用します。

      注:
      • Cloud Provisioning and Governance では、ドメインスコープの展開と折りたたみの機能はサポートされていません。
      • ユーザーがアクセスできるものとアクセスできないものの詳細については、「ドメインスコープ」を参照してください。

      サービスアカウントは、プロバイダーアカウントの資格情報とアクセス情報を保存するインスタンスの安全なレコードです。Discovery はこの情報を使用してプロバイダーアカウントにアクセスし、指定された各データセンターでリソースごとにデータを取得します。クラウドアカウントは、管理対象のクラウドインフラストラクチャのすべてまたは一部の Cloud Provisioning and Governance における論理的な表現です。クラウドアカウントには、複数のサービスアカウント (異なるプロバイダーのサービスアカウントを含む) を含めることができます。サービスアカウントごとに、クラウドアカウントに含めるデータセンターを指定します。

      管理キーとサービスアカウント資格情報が各ドメインに固有で、共有されていないことを確認します。複数のクラウドプロバイダーに対してクラウドアカウントとサービスアカウントをセットアップするには、1 日目のセットアップアクションを実行します。
    • クラウド API (CAPI) およびクラウドスクリプトとクラウドスクリプトテンプレート

      ドメイン分離は Cloud Provisioning and Governance でサポートされるため、CAPI はドメイン分離されていません。CAPI はグローバルドメインでセットアップされてリーフドメイン間で共有されるため、ハードコードされた機密情報 (アカウントの詳細、資格情報、名前など) がスクリプトに (コメントや注釈の中にも) 含まれないようにします。

      CAPI を使用すると、REST APIs を使用してクラウドプロバイダーと Cloud Provisioning and Governance をデータ連携できます。クラウドスクリプトは、プラットフォーム機能を使用するシンプルな Java スクリプトです。Cloud Provisioning and Governance アプリケーションでは、スクリプトの実行はクラウドスクリプトとクラウドスクリプトテンプレートに分割されます。テンプレート、リソースブロック、OS プロファイルでスクリプトを使用し、ポリシースクリプトを使用して要求フォーム属性を設定します。ポリシースクリプトがユーザーデータをオーバーライドすることはできません。クラウドスクリプトテンプレートは、実行のターゲットである仮想マシンに渡される実際の実行可能ファイルです。クラウドテンプレートを作成してから、それをクラウドスクリプトに関連付ける必要があります。

    • クラウド検出

      サービスプロバイダー (SP) はドメイン分離を使用して、各顧客のデータを分離します。指定されたドメイン内のユーザーは、自分のドメインまたは子ドメイン内のデータのみを可視化できます。通常、SP はトップレベルドメインを制御します。これにより、すべてのドメインに関連付けられたデータを可視化することができます。Discovery のドメイン分離サポートはレベル 2 とみなされますが、Cloud Provisioning and Governance の子ドメインに委任される管理権限は発生しません。SP は管理権限のコントロールを保持する必要があります。SP は、クラウドリソースを検出するために、ドメイン管理者としてログインするかドメイン管理者の代理として、常にリーフドメインから検出を実行します。

      クラウド検出には、単一のインターフェイスでクラウドのスケジュールを作成して実行できるウィザードが用意されています。Discovery Manager でスケジュールを作成する際に、検出するアカウントを選択し、アカウントにアクセスするための資格情報と、リソースをスキャンする MID Server を選択します。その後、Discovery ホームページで結果を表示し、発生した可能性があるエラーを追跡できます。

      詳細については、次を参照してください。
    • Event Management をセットアップおよび構成して、外部イベントを受信し、イベントおよびアラート管理ルールに基づいてアラートを生成します。イベントの可視性は、関連付けられているサービスアカウントのドメインによって異なります。そのドメインに属するユーザーのみが、処理されたイベントのイベント詳細を表示できます。サービスアカウントに関連付けられていないイベントは、すべてのドメインに表示されます。

      単一の管理コンソールを使用してビジネスサービスおよびインフラストラクチャの健全性を監視し、発生した問題に適切に対応します。Event Management は、ビジネスサービスのパフォーマンスを確実に継続するためのインテリジェントなイベントとアラート分析を提供します。Event Management は、MID Server を介してイベントを受信し、処理します。

      詳細については、次を参照してください：

    • Cloud Provisioning and Governance アプリケーションは、継続的デリバリーソリューション (構成管理とも呼ばれます) とのデータ連携をサポートします。Ansible または Terraform 構成管理プロバイダーを作成し、そのプロバイダーで Discovery を実行してリソースを検索します。それぞれの新しい構成管理プロバイダーの詳細については、「継続的デリバリ (構成管理) のサポート」および「作業負荷プロバイダータイプの作成」を参照してください。この情報は、構成管理プロバイダーを通じて仮想リソースをプロビジョニングするときにユーザーが選択できる管理属性として、[注文カタログ] フォームに表示されます。

    • terraform テンプレートに基づいてカタログを作成し、そのカタログを複数のドメインと共有する場合。グローバルドメインでモジュールの一覧表示 (構成検出) を実行します。MID サーバー はグローバルドメインで作成し、その検出のために Terraform 機能のみアサインする必要があります。これにより、SP は複数のドメインとカタログを共有できます。

      警告:

      Terraform の構成管理以外の機能を備えたグローバル MID サーバー は作成しないでください。

      共通の Terraform カタログを作成して複数の顧客と共有：

    • Cloud Provisioning and Governance ではワークフローのある Now Platform ルールをサポートしています。ルールは、条件とアクションの集合です。​ルールのすべての条件が「true」と評価された場合、システムはアクションを実行します。いずれかの条件が false と評価された場合、システムはアクションを実行しません。ルールを作成すると、アクティビティを追跡し、よりすばやく問題に対応して解決できるようになります。ワークフローフレームワークを活用して 2 日目の操作を自動化します。クラウド API または特定のリソースと通信するワークフローをすばやく書き込みます。SSH、PowerShell、または類似のツールを使用してワークフロー機能にアクセスしてから、拡張します。詳細については、「ワークフローを使用した 2 日目の操作」を参照してください。

    • 予算ベースの通知および承認

      Cloud Provisioning and Governance での Domain Separation は、予算のデータ分離をサポートします。ドメイン固有の予算を割り当てることができます。グループおよびグループ内のユーザーに予算をアサインします。ユーザーやグループが予算のしきい値制限に達すると、それに関するアラートの通知がユーザーやグループに送信されます。詳細については、「予算の構成」を参照してください。

      • クラウドリソースのタグの作成

        タグは、クラウドリソースを分類して、より豊富で詳細な追跡および請求処理レポートデータを提供します。タグキーはドメイン分離されず、他のドメインのユーザーに表示されます。タグの可視性は、関連付けられている CI ドメインまたは関連する請求処理記録ドメインによって異なります。CI または請求処理レコードに関連付けられていないタグは、すべてのドメイン管理者に表示されます。タグが作成されると、作成した新しいカタログに表示されます。クラウド管理者は、カタログに必要なタグを選択する必要があります。

      • 請求処理データは、ドメインごとに分離されて表示できます。請求処理ジョブは、構成されたサービスアカウントのドメインを使用します。請求処理のセットアップを構成すると、クラウド管理者およびクラウドユーザーは、請求処理ダッシュボードでクラウド請求処理データやクラウドタグの使用状況などのレポートを表示できます。

        MID Server を定期的に使用して請求処理データをプロバイダーからダウンロードする、スケジュール設定済みジョブを定義します。Cloud Provisioning and Governance でデータがコストテーブルに保存され、その情報を使用してレポートが生成されます。

        請求処理スケジュールのセットアップと請求処理レポートのダウンロードの詳細については、以下を参照してください。

    次の手順

    重要:

    リソースブロック上のワークフローを呼び出すカスタム操作を作成する際は、コンテキストを適切なドメインに変更してください。

    正しいドメインにコンテキストを変更するには、ワークフロー内から次のスクリプトを呼び出すように [ワークフローアクティビティ] を編集します。適切なユーザーが、サービスアカウントクリエーターまたは注文ユーザーから取得されていることを確認します。この代理操作スクリプトを呼び出すと、ワークフローを正しいコンテキストで実行し、関連付けられたドメインに属する正しい MID サーバー を選択できます。
    //var orderContext = json.decode(workflow.inputs.ordercontext) ;
new CMPDomainSeparationUtil() .impersonateUser(current.request.requested_for);

    インスタンスで管理している各ドメインで利用できる Cloud Provisioning and Governance ライフサイクル操作の実行の詳細については、「クラウドユーザーポータル」を参照してください。