スクリプティングガバナンスツールの詳細
スクリプティングガバナンスツール (SGT) は、 ServiceNow AI Platform全体でスクリプティングアクセスを管理するための単一の一元コントロールを提供します。
Zurich リリースでは、アドミニストレーターが ServiceNow AI Platformのスクリプトフィールドを編集できるユーザーを一元管理できる機能が導入されています。この機能では、 条件付きスクリプトライター グループとその子ロール snc_required_script_writer_permission に基づいてビルドされた新しい権限レイヤーが追加されます。既存の ACL ベースのアクセスに関係なく、スクリプトフィールドを編集するには、ユーザーがこのグループのメンバーである必要があります。この権限レイヤーは、データ型 ACL によって適用され、スケジュール済みジョブとシステムプロパティによって管理されます。
この機能を管理するために、 ServiceNow AI Platform は スクリプティングガバナンスツール (SGT) を提供しています。これは、アドミニストレーターがスクリプティングアクセス権を持つユーザーを確認し、スクリプトフィールドを編集したユーザーを探してインスタンスをスキャンし、ユーザーからスクリプティングアクセスを直接追加または取り消すことができるダッシュボードです。
重要な理由
スクリプティングは、テーブル間でデータの読み取りと書き込みを行い、ビジネスロジックをバイパスし、基本的なレベルでプラットフォームの動作を変更できるため、スクリプティングアクセスはあらゆるインスタンスを管理するための最も重要な権限の 1 つになります。
Zurich より前は、スクリプティングアクセスは個々のスクリプトフィールドの ACL によってのみ制御されていました。スクリプトを編集できるユーザーを決定するには、アドミニストレーターが各 ACL を個別にチェックする必要がありました。インスタンス全体のスクリプティングアクセスを表示または管理する単一の場所はありませんでした。
スクリプティングガバナンス機能は、既存の ACL ベースの権限の上にアクセス制御の必須の第 2 レイヤーを追加することで、この問題に対処します。スクリプトフィールドを編集するには、フィールドレベルの ACL を満たすだけでは不十分です。セキュリティアドミニストレーターは、 条件付きスクリプトライター グループにユーザーを追加または削除することで、スクリプティングアクセスを一元的に管理できるようになりました。
2 層アクセスモデル
スクリプティングガバナンス機能では、2 層のアクセスモデルが適用されます。ユーザーがスクリプトフィールドを編集するには、両方のレイヤーが個別に通過する必要があります。1 つのレイヤーを通過するだけでは十分ではありません。
- レイヤー 1 - 既存のフィールドレベルの ACL
- ユーザーは、スクリプティングフィールドで既存の ACL を渡す必要があります (すぐに利用可能またはカスタム)。このチェックは、チューリッヒより前の動作から変更されていません。
- レイヤ 2:SGT ロールチェック
-
ユーザーは、条件付きスクリプトライターグループのメンバーシップを通じて付与されるsnc_required_script_writer_permissionロールも保持している必要があります。
ロールがフィールドレベルの ACL を満たしていたため、Zurich アップグレード前にスクリプトフィールドを編集できたユーザーは、レイヤー 2 も満たさない限り、アップグレード後にブロックされます。 snc_required_script_writer_permission ロールは、それ自体で新しいスクリプティングアクセスを許可しません。すでにレイヤー 1 を通過しているユーザーのみのアクセスのロックが解除されます。
次の表は、2 層モデルでのアクセス結果をまとめたものです。
| フィールドレベルの ACL (レイヤー 1) に合格しますか? | snc_required_script_writer_permission (レイヤー 2) を保持しますか? |
スクリプトフィールドを編集できますか? |
|---|---|---|
| あり | あり | ✅ はい |
| あり | いいえ | ❌ いいえ |
| いいえ | あり | ❌ いいえ |
| いいえ | いいえ | ❌ いいえ |
データタイプ ACL
スクリプティングガバナンス機能では、レイヤー 2 を適用するための 9 つのデータタイプ ACL が導入されています。これらは、次のデータタイプの snc_required_script_writer_permission ロールを必要とする ACL の場合を除き却下されます。
- データタイプ
-
- スクリプト
- script_client
- script_plain
- script_server
- email_script
- html_script
- html_template
- xml
- condition_string
注:デフォルトでは、admin ロールにはスクリプティングアクセス権がありません。アドミンユーザーは同じ 2 レイヤーチェックの対象となり、 条件付きスクリプトライター グループのメンバーであるか、明示的に snc_required_script_writer_permission ロールを保持していない限り、スクリプトフィールドを編集することはできません。詳細については、「 データタイプ ACL」を参照してください。
スケジュール済みジョブとプロパティ
スクリプティングガバナンス機能の一環として、子ロールとしてsnc_required_script_writer_permissionロールを持つ条件付きスクリプトライターグループが導入されています。Zurich へのアップグレードが完了すると、1 回限りのスケジュール済みジョブが実行され、対象となるすべてのユーザーがこのグループに自動入力され、アップグレード後にスクリプティングアクセス権が失われることがなくなります。そのジョブが完了すると、グループメンバーシップを最新の状態に保つために、定期的な週次ジョブが作成されます。ジョブとその適格基準の両方を次のように説明します。
- 条件付きスクリプトライターグループにユーザーを追加
- Zurich へのアップグレードが完了した直後に 1 回実行されるジョブ。適格基準を満たすすべてのユーザーが条件 付きスクリプトライター グループに追加され、アップグレード後にユーザーがスクリプティングアクセス権を失うことがなくなります。ジョブが完了すると、プラットフォームによって無効になります。
- 条件付きスクリプトライターグループのユーザーを更新
- 適格基準を満たす新しいユーザーをグループに追加し、適格基準を満たさなくなったユーザーを削除する週次ジョブ。これは、 glide.security.scripting_role.auto_provisioning プロパティによって制御されます。
表 : 1. プロパティに基づいて動作を更新します 値 動作 true (デフォルト) 週次ジョブはスケジュールどおりに実行され、対象となるユーザーがグループに自動的に追加されます。 false ジョブは実行されません。ユーザーは、アドミニストレーターが手動でグループに追加するだけです。
適格性クライテリア
どちらのスケジュール済みジョブも同じ基準を使用して、 条件付きスクリプトライター グループに追加するユーザーを決定します。
| 明示的なロールプラグイン | ユーザータイプ | 要件 | グループに追加されましたか? |
|---|---|---|---|
| 有効 | 外部 | — | いいえ |
| 有効 | 内部 | snc_internal と少なくとも 1 つの追加ロールが必要です | あり |
| 無効 | 任意のユーザー | 少なくとも 1 つのロールが必要です | あり |
スクリプティングガバナンスツール
スクリプティングガバナンスツールは、アドミニストレーターが ServiceNow プラットフォームでスクリプティングアクセスを管理するのに役立つダッシュボードです。これにより、条件付きスクリプトライターグループのメンバーであるユーザーが可視化され、インスタンスでスクリプトを記述できるユーザーの数が明確になります。
スクリプティングロールを含むグループと、スクリプティングロールを子ロールとして含むロールを表示することもできます。このツールを使用してスクリプトアクセスを管理するには、次の 2 つの方法があります。
- 手動構成:条件付きスクリプトライターグループにユーザーを手動で追加または削除して、スクリプティングにアクセスできるユーザーを制御します。
- スクリプトを作成したユーザーのスキャン:インスタンスをスキャンして、特定の期間内にスクリプトを作成したユーザーを見つけます。スキャンは監査ログを照会し、スクリプトフィールドを持つテーブルに対して書き込みまたは更新を実行したユーザーを特定します。