3.1.2. Application/Access Control (ACLs)

💡 First Principle: Fine-grained access control, enforced through Access Control Lists (ACLs), ensures that only authorized users can read, write, create, or delete specific data and records, safeguarding sensitive information and maintaining platform integrity.

Scenario: A new custom application contains sensitive financial data. You need to ensure that only users with the finance_manager role can view these records, and only users with the finance_admin role can modify them.

In ServiceNow, security is paramount, especially regarding who can access what data. While Roles and Groups (as discussed in 1.2.6) provide broad permissions, Access Control Lists (ACLs) enforce granular security rules at the row and column level. The fundamental 'why' of ACLs is to implement the Principle of Least Privilege (PoLP) – granting users the absolute minimum access required to perform their job functions. This is crucial for protecting sensitive data, maintaining compliance, and preventing unauthorized modifications or data breaches.

Key concepts of ACLs in ServiceNow:

• Access Control Lists (ACLs): Security rules configured on records (rows) and fields (columns) that specify what permissions are required to perform an action.
  • Operations: ACLs define permissions for common operations:
    • read: Can view the record/field.
    • write: Can modify the record/field.
    • create: Can create new records.
    • delete: Can delete records.
    • report_on: Can build reports on the record/field.
    • execute: Can run scripts or workflows.
• ACL Record Structure: Each ACL record defines:
  • Type: record (for tables/fields) or ui_page, client_callable_script_include, etc.
  • Operation: (e.g., read, write).
  • Name: The table name (incident), or table.field name (incident.short_description). A wildcard * can be used (incident.* for all fields).
  • Requires Role: One or more roles required to pass the ACL.
  • Condition: An optional condition that must evaluate to true (e.g., State is New).
  • Script: An optional server-side script that must return true or false for more complex logic.
• ACL Evaluation Order: ACLs are evaluated from most specific to most general.
  1. record.field (most specific, e.g., incident.short_description)
  2. record.* (all fields on a table, e.g., incident.*)
  3. table.field (field across all tables, e.g., *.active)
  4. table.* (all fields on all tables, e.g., *.*) The system continues evaluating until it finds an ACL that explicitly allows the action. If no ACL allows it, access is denied.
• Wildcard Rule: A common security best practice is to have a table.* ACL that requires a specific role (e.g., itil) for read access, and then create more specific ACLs to grant additional write access.

As a CSA, you'll frequently define and troubleshoot ACLs to ensure users have appropriate data access. Incorrect ACLs can lead to data exposure or prevent users from performing their duties. Mastering ACLs is fundamental to securing your ServiceNow instance.

💡 Tip: When troubleshooting an access issue (e.g., a user cannot see or edit a field), use the Debug Security module. It shows you exactly which ACLs are being evaluated and whether they are passing or failing, including the conditions and roles. This is an invaluable tool for ACL debugging.

⚠️ Common Pitfall: Granting overly broad ACLs (e.g., table.* with no role or condition) or creating conflicting ACLs that lead to unintended access or denial. Always apply the Principle of Least Privilege.

Key Trade-Offs:

• Granularity vs. Management Complexity: Highly granular ACLs provide strong security but can be complex to manage. Balancing this is key.

Reflection Question: How does the ACL evaluation order (most specific to most general) ensure that fine-grained security rules take precedence over broader permissions, and why is this important for data protection?