- 5 minutes to read

Run custom SQL monitoring statements and actions securely with Nodinite

Use custom SQL monitoring and on-demand actions to extend Nodinite, but keep the execution model strict. The Database Monitoring Agent can run monitoring statements, user action scripts, impersonated identities, and custom connection strings. This flexibility gives strong operational value and also introduces clear security boundaries you must manage.

This guide centralizes the security model for all Database feature pages that use custom SQL logic, Remote Actions, impersonation, and connection string overrides.

Note

This guidance applies to SQL Server, Azure SQL Database, and PostgreSQL scenarios where you configure custom SQL statements, authentication overrides, or user action scripts.

Security model at a glance

flowchart LR A[" Administrator"]:::actor --> B[" Web Client"]:::client B --> C[" Database Monitoring Agent"]:::agent C --> D[" Monitoring Statement"]:::script C --> E[" User Action Script"]:::script D --> F[" Connection String"]:::identity E --> G[" Optional Impersonation"]:::identity F --> H[" Target Database"]:::target G --> H classDef actor fill:#90EE90,stroke:#2E7D4E,stroke-width:2px,color:#000 classDef client fill:#87CEEB,stroke:#2E5C8A,stroke-width:2px,color:#000 classDef agent fill:#FFD700,stroke:#A67C00,stroke-width:2px,color:#000 classDef script fill:#D6EAF8,stroke:#5B7FA3,stroke-width:2px,color:#000 classDef identity fill:#FFB347,stroke:#B86B00,stroke-width:2px,color:#000 classDef target fill:#FADBD8,stroke:#B03A2E,stroke-width:2px,color:#000

Diagram: Database Monitoring Agent execution flow where monitoring statements and user action scripts run through explicit connection strings and optional impersonation into target databases.

Current model and upcoming identity grouping

Today, security isolation is configured per SQL Statement and per script entry by using dedicated connection strings and optional impersonation credentials.

An upcoming identity-grouping capability (similar to the Windows Server PowerShell model) is planned to simplify management and improve logical overview. Until that capability is available, use explicit per-statement credential isolation as your primary control.

Area Current model Upcoming model (planned)
Execution identity Per statement/script configuration Grouped identity boundary
Credential handling Connection string + optional impersonation fields Centralized group identity with simpler administration
Security outcome Strong when least privilege is applied consistently Same principle, easier governance and review

Why this matters

Custom SQL execution can read, modify, or delete data depending on granted permissions. A weak configuration can expose system tables, production data, and credentials.

Use a least-privilege design where each statement only has the minimum rights needed for that statement.

Security baseline

Area Recommended practice Avoid
Connection strings Use dedicated connection strings per monitoring or action scope. Use a shared high-privilege connection string for all scripts.
Permissions Grant minimal permissions (SELECT, specific EXECUTE) only where required. Grant sysadmin, db_owner, or broad DDL permissions by default.
Credentials Use dedicated service identities for SQL statement execution. Reuse the Database Monitoring Agent service account.
Scope Point each connection string to a specific target database when possible. Use system databases (master, msdb) for custom monitoring logic.
Impersonation Use impersonation only when required and document ownership. Enable impersonation broadly without ownership and review.
Script governance Review, test, and version all statements before production rollout. Allow unreviewed statements to run in production.
Lifecycle Rotate secrets regularly and review usage logs. Keep credentials static for long periods without audits.

Core guidance

Connection string isolation

Use separate connection strings for different risk levels:

  • Read-only monitoring logic.
  • Restricted management actions.
  • Environment-specific scopes (production, non-production).

This design limits blast radius if one credential is misused or leaked.

Impersonation and authentication overrides

If you use impersonation in the Authentication tab:

  • Use a dedicated account for that specific script scope.
  • Keep the account permissions lower than the agent service account.
  • Never reuse the Database Monitoring Agent service identity.

Least privilege for monitoring and actions

Treat monitoring statements and user action scripts differently:

  • Monitoring statements should usually require read-only access.
  • User action scripts may need write or EXECUTE, but only for explicitly approved procedures.
  • Deny broad DDL operations unless there is a controlled exception and review.

Example least-privilege SQL Server configuration

Use this as a starting template and adapt it to your database names, schemas, and procedures:

-- Create dedicated monitoring login
CREATE LOGIN NodiniteMonitor WITH PASSWORD = 'Complex!Password123';
CREATE USER NodiniteMonitor FOR LOGIN NodiniteMonitor;

-- Grant only required permissions on target database
USE YourMonitoringDatabase;
GRANT SELECT ON SCHEMA::dbo TO NodiniteMonitor;

-- If required, allow execute on explicit procedures only
GRANT EXECUTE ON dbo.SP_CheckConnectionFailures TO NodiniteMonitor;

-- Explicitly deny dangerous permissions
DENY DROP ANY DATABASE TO NodiniteMonitor;
DENY ALTER ANY DATABASE TO NodiniteMonitor;
DENY CREATE TABLE TO NodiniteMonitor;

Example connection string isolation 

Monitoring statement (read-only):
Server=SQL01;Database=IntegrationDB;User ID=NodiniteMonitorRO;Password=***;Encrypt=True;...

User action script (limited management):
Server=SQL01;Database=IntegrationDB;User ID=NodiniteManageLimited;Password=***;Encrypt=True;...

Use separate credentials to isolate risk between read-only monitoring and administrative actions.

Risk examples if isolation is not applied

  • Shared high-privilege credentials can let any configured script modify or delete production data.
  • A script bug can perform unintended writes at scale if permissions are too broad.
  • Compromised configuration access can become broad database access if all statements share one powerful identity.
  • Compliance control weakens when script-level access boundaries are missing.

Script review and operational controls

Before enabling a statement or user action script:

  • Validate in non-production first.
  • Confirm timeout behavior and performance impact.
  • Verify output does not expose sensitive data.
  • Keep change history for who modified statement text and credentials.

Practical checklist

Before publishing or enabling a custom SQL statement or action script, confirm:

  • A dedicated connection string is in use for this scope.
  • Permissions are least privilege for this specific script.
  • Agent service account credentials are not reused.
  • Impersonation (if enabled) is justified and documented.
  • Script logic is reviewed and tested in non-production.
  • Secrets are rotated and ownership is clear.

Additional resources

Cross-agent security pattern

The same secure execution principles apply across both agents:

  • Database SQL statements and user action scripts.
  • Windows Server custom PowerShell scripts and user actions.

Use this guide together with the Windows Server PowerShell security guide to keep a consistent security model across monitoring agents.

Next Step