アクティビティについて
アクティビティとは、ポリシーの定義およびデバイスへの割り当てを行うための一時的なコンテキストです。デバイスをインポート、作成、または削除する場合や、各種のシステム管理タスクを実行する場合は、アクティビティを作成する必要はありません(ただし、アクションの一部としてポリシー ディスカバリを実行する場合を除きます)。
アクティビティを作成または開くための要件は、Workflow モードによって異なります。
-
チケット管理が有効になっている Workflow 以外のモード:チケットを開くたびに、アクティビティが自動的かつ透過的に作成されます。チケットを明示的に開かない場合、アクティビティを必要とするアクションを実行するたびに、新しいチケットを作成するか、既存のチケットを開くように要求されます。このモードでは、チケットを明示的に開いて管理する必要があります。
-
チケット管理が有効でない Workflow 以外のモード:ポリシーの定義、変更、またはデバイスへの割り当てを行うたびに、アクティビティが自動的かつ透過的に作成されます。変更をデータベースに送信するまでは、同じアクティビティが使用され、必要に応じて自動的に閉じたり再び開いたりします。Workflow 以外のモードでは、アクティビティを明示的に開いたり管理したりすることはできません。これらのタイプのアクティビティは、設定セッションと呼ばれることもあります。
-
Workflow モード:アクティビティを明示的に開かない場合、アクティビティを必要とするアクションを実行すると、新しいアクティビティを作成するか、既存のアクティビティを開くように要求されます。Workflow モードでは、アクティビティを明示的に開いて管理する必要があります。
(注) |
Workflow モードは、チケット管理が有効か無効かに関係なく、同じように機能します。Workflow モードでチケット管理を有効にすると、アクティビティで使用する [チケット(Ticket)] フィールドが有効になります。チケット ID の入力は必須ではありませんが、使用する場合は、外部の変更管理システムにリンクするように [チケット(Ticket)] フィールドを設定できます。詳細については、「チケット管理」を参照してください。 |
アクティビティを自分で作成するか、またはアクティビティが自動的に作成されると、Security Manager ポリシー データベースの仮想コピーが開きます。このコピー内でポリシーを定義して割り当てます。このコピー内で行った変更は、コピーの内部でだけ使用可能です。他のユーザが別のアクティビティ内でこれらの変更を表示することはできません。アクティビティが送信されて承認(Workflow モード)されると、このコピー内部の変更がデータベースにコミットされ、他のすべてのユーザが変更を表示できるようになります。そのあと、関連する CLI コマンドを生成してデバイスに展開するための展開ジョブを作成できます。
アクティビティの変更を送信する方法は、Workflow モードによって異なります。
-
チケット管理のある Workflow 以外のモード(デフォルト):
を選択して、変更をポリシーデータベースに送信します。 -
チケット管理のない Workflow 以外のモード(デフォルト):
を選択して、変更をポリシーデータベースに送信します。 -
Workflow モード:アクティビティアプルーバを使用する場合は、
を選択するか、個別のアクティビティアプルーバを使用しない場合は、 を選択します。
ここでは、アクティビティが重要である理由と、Workflow モードでのアクティビティの動作について説明します。
アクティビティの利点
アクティビティを使用して、ポリシーおよびポリシー割り当てに対して行われる変更を制御します。アクティビティがどのように実装されるかは、選択したワークフロー設定によって異なりますが、すべてのアクティビティに共通して次のような利点があります。
-
監査証跡:アクティビティによって、Security Manager で行われた変更が追跡されます。アクティビティ/チケットのステータスおよび履歴の表示で説明しているように、この情報を使用して、どのような変更が誰によって行われたかを判断できます。また、監査レポートの使用で説明しているように、Workflow モードと Workflow 以外のモードのどちらにも、アクティビティおよびその他のアクションに可視性を提供するための監査レポートが用意されています。
-
安全性メカニズム:アクティビティは、変更を重ねて実験するための手段を提供します。変更はプライベート データベース ビューに対して行うため、その変更を実装しない場合は、アクティビティまたは設定セッションを廃棄します。詳細については、アクティビティ/チケットの破棄を参照してください。
-
タスク分離:あるアクティビティ(または設定セッション)内で変更されたポリシーは、別のアクティビティ内で変更されないようにロックされます。このため、変更の競合によりポリシーが不安定になることがありません。詳細については、アクティビティとロッキングを参照してください。
また、アクティビティ内で行った変更は、そのアクティビティ内部でだけ表示されます。その他のユーザには、最後に承認されたコミット済みの設定だけが表示されます。ただし、(Workflow モードで)アクティビティを閉じる前に他のユーザにアクティビティが表示されていた場合を除きます。
アクティビティの承認
Workflow モードをイネーブルにした場合、アクティビティ アプルーバを使用するかどうかを選択できます。
アクティビティを承認するための上位の権限を持つ別の人が組織に必要な場合は、アプルーバを使用してワークフローをイネーブル化できます。Workflow モードでアプルーバを使用する場合は、ポリシーをデータベースにコミットできるように、適切な権限を持つ人がアクティビティを承認する必要があります。ポリシー定義レベルでこの承認プロセスを使用すると、ネットワーク デバイスに不適切な設定が適用されることはありません。
アプルーバを使用しないように選択した場合は、ポリシーを定義した人がそのポリシーを承認する権限を持ちます。
アクティビティ承認をイネーブルまたはディセーブルにし、デフォルトのアクティビティ アプルーバを変更する方法の詳細については、[Workflow] ページを参照してください。
アクティビティとロッキング
複数のユーザが競合する変更を行うことがないように、Workflow モードまたは Workflow 以外のモードでユーザがアクティビティまたは設定セッション内で特定のアクションを実行すると、Security Manager によってアクティビティレベルのロックが取得されます。このため、複数のユーザが同じ機能ポリシー、ポリシー割り当て、またはオブジェクトに対して同時に変更を行うことができなくなります。
また、Security Manager では、ロッキングを使用して、コミット済みの設定に関連する操作が常に互いに排他的に実行されるようにしています。これらの操作は、2 つのカテゴリに分けられます。
コミット済みの設定を変更する操作:
-
アクティビティの承認。Workflow 以外のモードでの設定セッションの送信が含まれます。
-
デバイスの削除。
-
デバイス プロパティの編集。
コミット済みの設定を読み込む操作:
-
設定のプレビュー。
-
展開(Workflow 以外のモード)。
-
展開ジョブの作成(Workflow 以外のモード)。
-
アクティビティまたは設定セッションの検証。
コミット済みの設定を変更する操作を実行している間は、その操作が完了するまで、他のユーザはどちらのリストの操作も実行できません。ユーザが操作を試行すると、アクションおよびアクティビティ(または Workflow 以外のモードではユーザ)がロックされていることを示すエラー メッセージが表示されます。たとえば、アクティビティを承認している間(Workflow 以外のモードでは、アクティビティが送信されると自動的に実行される)、その承認が完了するまで、他のユーザがデバイスを削除したり、別のアクティビティを検証したりすることはできません。このタイプのロッキングは、コミット済みの設定を複数のユーザが同時に変更することを回避できるため、マルチユーザ設定においては特に重要になります。
コミット済みの設定を読み込む操作を実行している間、コミット済みの設定を変更する操作はだれも実行できません。たとえば、アクティビティを検証している間、別のユーザはアクティビティを承認できません。ただし、設定を読み込む別の操作を他のユーザが実行することはできます。たとえば、アクティビティを検証している間、別のユーザは展開ジョブを作成できます。同様に、展開前に設定をプレビューしている間、別のユーザも同じように設定をプレビューできます。これは、この 2 つの操作ではコミット済みの設定が読み込まれるだけで、設定が変更されることはないためです。
ヒント |
アクティビティ ロッキングの方が、ポリシー ロッキングよりも広範囲です。これについては、ポリシーのロックについてで説明しています。ポリシー ロッキングにより、2 人のユーザが同じデバイス上の同じポリシーを同時に変更することを回避しています。 |
関連項目
アクティビティと複数のユーザ
各アクティビティ内でポリシーを同時に定義または変更できるのは、1 人のユーザだけです。ただし、Workflow モードがイネーブルになっている場合、または Workflow 以外のモードでチケット管理がイネーブルになっている場合は、アクティビティ内で複数のユーザーが順番に作業できます。つまり、アクティビティまたはチケットが閉じている(ただし、承認はされておらず、承認のための送信もされていない)場合は、別のユーザーがそのアクティビティを開いて変更できます(必要な権限を持っている場合)。複数のユーザは、異なるアクティビティで並行して作業できます。
アクティビティ/チケットの状態について
Workflow モードでのアクティビティと Workflow 以外のモードでのチケット(チケット管理が有効な場合)の状態について、次の表で説明します。主要な状態は太字で示しています。
状態 |
説明 |
---|---|
Edit |
アクティビティ/チケットは作成されましたが、現在編集中ではありません。アクティビティ/チケットは、[編集(Edit)] 状態のとき、開いたり破棄したりできます。 |
Edit Open |
アクティビティ/チケットは編集用に開かれています。アクティビティ/チケット内で、ポリシーの定義や割り当てなどの変更を実行できます。アクティビティ/チケット内で設定中または変更中のポリシー、ポリシー割り当て(ポリシーを割り当てるデバイス)、およびオブジェクトは、ロックされます。つまり、これらを別のアクティビティ/チケットのコンテキスト内で設定または変更することはできません。アクティビティは、[編集がオープン(Edit Open)] 状態のとき、閉じる、破棄、送信、または承認できます。チケットは、[編集がオープン(Edit Open)] 状態のとき、閉じる、破棄、または送信できます。 設定の変更は、アクティビティ/チケットのコンテキストでのみ確認できます。 |
送信済み(Submitted) Submitted Open |
アクティビティが確認および承認のために送信されたか、またはチケットが送信されました(Workflow モードでは、アクティビティ承認が必要な場合だけこの状態を使用できます。詳細については、[Workflow] ページを参照してください)。アクティビティ/チケット内でこれ以上変更することはできません。ポリシー、(ポリシー割り当てを介する)デバイス、またはポリシー変更の影響を受けるオブジェクトは、他のアクティビティ/チケットに対してロックされたままになります。 アクティビティが送信されると、電子メールがアプルーバに送信されます。アプルーバは、アクティビティを(読み取り専用モードで、[Submitted Open] 状態に移行して)開いて、アクティビティ内の変更を確認してから、変更を承認または拒否できます。承認されたアクティビティは、[Approved] 状態に移行します。拒否されたアクティビティは、[Edit] 状態に戻ります。 |
承認済み(Approved)(Workflow モードのみ) |
アクティビティは承認され、対応する設定要素がコミット済みのポリシー設定となりました。ポリシー変更の影響を受けるデバイスは、他のアクティビティに対してロック解除されます。アクティビティは、[承認済み(Approved)] 状態のときに展開できます。 |
承認失敗(Approve Failed)(Workflow モードのみ) |
承認中に(電源障害などにより)エラーが発生すると、アクティビティは [Approve Failed] 状態になります。この場合は、アクティビティを再び承認するか、サーバをリブートしてください。 |
破棄(Discarded) |
アクティビティ/チケットの作成後にアクティビティ/チケットに対して行われた変更は破棄され、アクティビティ/チケットをそれ以上変更することはできません。アクティビティ/チケットに関連付けられているデバイスはロック解除され、新しいアクティビティ/チケットで使用できるようになります。アクティビティ/チケットは、システムから削除されないかぎりテーブルに残り、[破棄(Discarded)] 状態が表示されます。 |
チケットのワークフローは、チケットワークフローの段階を示しています。アプルーバを使用しないアクティビティ ワークフローは、アプルーバを使用しないアクティビティワークフローの段階を示しています。アプルーバを使用するアクティビティ ワークフローは、アプルーバを使用するアクティビティワークフローの段階を示しています。