クラウドプロビジョニング のポリシー

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:6分
  • クラウドポリシーは、ユーザーが設定したプロパティ値の上書き、承認タスクの作成、IP アドレスの予約、フォームフィールドの事前入力または非表示、カスタムスクリプトの実行、 クラウド APIの呼び出し、サブフローの開始または中止を行うことができます。クラウドポリシーを使用すると、承認、リソース操作、詳細計画操作、カタログアイテムの設定をシステム全体で制御できます。

    ユーザーは承認ポリシーをトリガーするスタックを要求します。

    1. クラウドユーザーポータル で、ユーザーは特定の詳細計画をプロビジョニングする要求を送信します。詳細計画をプロビジョニングするプロセスにより、ポリシーエンジンによる承認ポリシーの適用がトリガーされます。 クラウド承認ポリシーでは、アクティビティを続行する前に、指定されたクラウドアクティビティを承認する必要があるユーザーを指定します。
    2. ポリシーエンジンは、ポリシーのルールで指定された条件を要求が満たすかどうかを特定します。この例では、特定の詳細計画がプロビジョニングされると常に条件は true と評価されます。
    3. 条件が満たされているため、ポリシーエンジンは、ルールにも指定されているアクションを実行します。この例のアクションは、マネージャーの承認アクションを作成するアクションです。
    4. 承認者 (マネージャー) が承認要求をレビューする間、ユーザーには クラウドユーザーポータル で「承認待ち」ステータスメッセージがユーザーに表示されます。
    5. マネージャーが承認すると、詳細計画がプロビジョニングされます。
    図 : 1. 承認待ちのユーザー
    承認待ちのユーザー
    注:
    リソース操作ステップを追加しているときに、フローを呼び出すことはできません。これは既知の制限です。

    ポリシートリガーについて

    トリガーは、ポリシーエンジンを実行に移すイベントです。たとえば、[カタログアイテム要求終了時] トリガーは、ユーザーが要求フォームを送信した後に開始されます。ポリシーの定義について考える場合は、まずポリシーのトリガー方法を検討してください。例:
    • ユーザーが仮想サーバーの [停止] 操作を要求する ([スタックリソース操作時] トリガーが開始される)
    • リソースがリースの終了に達する ([リース終了時] トリガーが開始される)
    • ユーザーが特定のスタックを要求する ([詳細計画のプロビジョニング時] トリガーが開始される)

    通常、ポリシーは、ポリシーのトリガー名で参照します。たとえば、[リース終了時] トリガーによってトリガーされるポリシーを、「リース終了ポリシー」と呼ぶ場合もあります。実装できるトリガーのタイプの詳細については、「クラウドポリシーのトリガー」を参照してください。

    ポリシーの仕組み

    ポリシーごとに、通常はポリシーエンジンを開始するトリガーを設定します。ポリシーエンジンは、ポリシーに対して定義されているすべてのルールを実行して、ポリシーを適用します。 ポリシールールは、条件とアクションの集合です。​すべての条件が「true」と評価された場合、ポリシーエンジンはアクションを実行します。いずれかの条件が「false」と評価された場合、ポリシーエンジンはアクションを実行しません。
    • 一部のポリシータイプは、開始、停止、プロビジョニング、プロビジョニング解除などの特定のタイプのクラウドオペレーション、または「詳細計画 123 のプロビジョニング時操作」や「カタログアイテム ABC 起動時」などの特定のターゲットにのみ適用されます。
    • ターゲットを指定しないポリシーを設定できます (たとえば、「任意の詳細計画のプロビジョニング時操作」または「任意のカタログアイテム起動時」など)。任意のオブジェクトに適用されるポリシーのエラーは無視されます。
    • 複数のポリシーが適用される場合は、ポリシーの適用順序を指定できます (ただし、次のセクションで説明する例外があります)。
    • ポリシーは、ダイナミックフォームを操作して、エンドユーザーに対してフォームフィールドを表示または非表示にできます。ユーザーには、ユーザーが自分のタスクを理解して完了するために必要と判断される情報のみが表示されます。

    ポリシーグループ

    クラウドポリシーグループは、関連するポリシーのコンテナです。一緒に使用することの多いポリシーや、一緒に考慮する必要があるポリシーをグループ化することを検討します。ポリシーをグループ化すると、組織全体でポリシーを一貫して適用できます。

    複数のポリシーが適用される場合の実行順序

    複数の「承認」ポリシーが適用される場合の実行順序:

    複数の「承認」ポリシーが適用されると、ポリシーは次の順序で適用されます(承認ポリシーは [詳細計画のプロビジョニング (承認) 時][スタック操作 (承認) 時][スタックリソース操作 (承認) 時]、および [タスク修正時] です):

    1. 最初に成功した承認ポリシーのみが適用され、他の承認ポリシーは適用されません。
    2. 適用された承認ポリシーに複数のルールがある場合は、最初に成功したルールのみが使用されます。
    3. ルールに複数のアクションがある場合、最初に成功したアクションのみが実行されます。
    4. 適用された承認ポリシーにカスタムの承認と ServiceNow の承認の両方が含まれている場合は、カスタムの承認プロセスのみが実行されます。

    その他のすべてのポリシータイプの実行順序:

    • ポリシーは、[実行順序] プロパティ設定で指定された順序で適用されます。
    • 複数のポリシーの [実行順序] 設定が同じ場合、順序は保証されません。

    ポリシーの操作について

    トリガーは多くの場合、ユーザーの要求と、詳細計画、カタログアイテム、リソース、またはスタックで実行できる操作 (開始、停止、プロビジョニング、またはプロビジョニング解除) に基づいています。一部のトリガータイプでは、クラウドオペレーションを指定しません。たとえば、[リース終了時] トリガーは、操作とは無関係に開始されます。

    ポリシールールについて

    ポリシールールは、条件とアクションの集合です。​すべての条件が「true」と評価された場合、ポリシーエンジンはアクションを実行します。いずれかの条件が「false」と評価された場合、ポリシーエンジンはアクションを実行しません。

    • 条件:条件は、要求フォームデータ、リソースアクティビティ、またはユーザーアクティビティを考慮できます。例:
      • 要求された CPU のサイズは 32 より大きいか。
      • これは [停止] 操作であるか。
      • このリソースのリースは、次の 7 日間で終了するか。
    • アクション:すべての条件が true と評価された場合、ポリシーエンジンはルールで指定されたアクションを実行します。ポリシーアクションの式により、値を設定またはオーバーライドできます。 例:
      • CPU サイズを 16 に変更してユーザーが指定した値をオーバーライドし、承認プロセスを開始します。(要求された CPU が 32 より大きいという条件が満たされたため)。
      • マネージャーの承認タスクを作成します。([停止] 操作が要求されたという条件が満たされたため)。
      • ABC グループのすべてのユーザーに通知を送信します。(リースが 7 日間で終了するという条件が満たされたため)。

    ポリシーアクションスクリプト

    • ポリシーアクションスクリプトを使用して、クラウド要求の値を取得、更新、または設定します。
    • インスタンスは、請求とレポートのためにタグ付けされたリソースを追跡します。ポリシーアクションスクリプトは、リソースタグを追加および変更できます。