Users and customers: access control for a monitoring system

A monitoring system collects a surprising amount of sensitive material. It knows the address of every device on the network, it holds the credentials to read them, it stores months of traffic history, and its event stream shows who logged in where. Then, almost always, somebody asks for "just a read-only login" so a department head or a client can see their own graphs. This guide covers how to give people the access they need without handing the whole network map to everyone who has a password.

Two kinds of people

Every monitoring setup ends up with two audiences, whether or not the software names them.

Users run the system. They are operators who watch the console and acknowledge alarms (see working the monitoring console), engineers who add hosts and tune thresholds, and administrators who manage the server, the integrations and the other accounts. They need to change things, and they need to see most of the network to do their job.

Customers consume the results. A customer owns or pays for a service and wants to know how it performed: the finance office checking its WAN link, a school principal asking why the building's internet was slow on Tuesday, or the client of a managed service provider (MSP) who wants monthly availability for the three circuits on the contract. Customers need read-only views of their own objects and nothing else.

The word "customer" covers internal teams too. If the facilities department can see the graphs for its building controllers, it is a customer of the monitoring system, even though nobody sends it an invoice.

One old habit is worth keeping: give every monitored object an owner from day one. Create a default owner (call it "internal" or "shared infrastructure") so nothing is ownerless, then assign client circuits, department links and lab gear to their real owners as you add them. Retrofitting ownership onto 2,000 interfaces later is miserable work.

Roles instead of one-off permissions

Granting permissions one person at a time works for three accounts and falls apart at thirty. Role-based access control (RBAC) puts permissions on a role and people into roles. Most current tools do this in some form. The role names vary, but the set below covers what most teams need.

Keep the administrator group small and named. If eight people have full admin "because it was easier", nobody can say who changed the SNMP credentials last month.

Service accounts get their own row because they are the ones everybody forgets. An API token created for a ticketing integration two years ago often still has full rights, no owner and no expiry. Give each integration its own account, scope it to what it does, and write down who owns it.

Scope: roles combined with host groups

A role says what someone can do. A scope says where. In practice, permissions are the combination of the two: "operator on the branch offices", "viewer on Client B's circuits", "engineer on the data center core".

Scopes almost always hang off the same host groups you already use to organize the network (see organizing monitored hosts). Typical scoping keys:

• site or region: hq, branch-east, dc1
• owner or customer: client-a, client-b, dept-finance
• function: core, access, wan, servers

The tools implement this differently. Zabbix assigns permissions to user groups per host group (read, read-write or deny). Grafana combines organization roles (viewer, editor, admin) with folder and dashboard permissions. Checkmk shows ordinary users only the hosts and services they are a contact for, through contact groups. Icinga Web uses roles that pair permissions with object filters. Underneath, the model is the same: people in groups, objects in groups, and a rule connecting the two.

Three traps come up again and again:

1. Auto-discovery into a visible default group. A discovery run finds forty new devices and drops them into a group every viewer can see. Make the landing group for discovered hosts visible to administrators only, and move hosts out after review.
2. Shared objects. The internet uplink serves every customer. Decide whether customers see it (often yes, as a summary graph without the interface name or address) and make that decision on purpose.
3. Aggregate widgets. A "top 10 busiest interfaces" panel or a network-wide availability figure can show a viewer other customers' devices and traffic. Check every widget on a dashboard you share, not just the list of hosts behind it.

Local accounts, directory logins and the emergency account

Local accounts live in the monitoring system's own database. They are simple and they keep working when everything else is down, which matters, because the monitoring system is needed most exactly when things are broken.

Directory logins (LDAP or Active Directory, or single sign-on through SAML or OpenID Connect) move identity somewhere central. The big win is offboarding: when someone leaves, disabling one directory account removes their access to the monitor along with everything else. Map directory groups to roles (nms-operators, nms-admins) rather than adding people one at a time inside the tool, so access follows the same joiner and leaver process as the rest of the organization.

The catch is the dependency. If the directory server or identity provider sits behind the router that just failed, nobody can log in to see why. So keep exactly one local emergency administrator account, often called a break-glass account:

• a long random password kept in the team's password vault, not in anyone's head
• multi-factor authentication if the tool supports it for local accounts
• an alert, or at least an audit entry, every time it is used
• a new password after every use

Turn on multi-factor authentication for every administrator account, local or not. An admin login to the monitor is close to an admin login to the network, because the monitor holds the device credentials.

Logging in to the monitoring system and logging in to network devices are separate problems. Device logins usually go through TACACS+ or RADIUS, and the monitor may receive accounting records of who ran which command on which router. Those records are sensitive in their own right and belong in the same restricted scope as device configs.

Sharing dashboards without sharing the network

More leaks happen through sharing features than through accounts. Four patterns cause most of the trouble:

• Public or anonymous links. Snapshot links and public dashboard features are handy for a one-off, but a link pasted into a ticket or a chat channel can live for years. Prefer links that expire, and check what data a snapshot embeds.
• URL variables used as security. A dashboard that filters on a customer= variable in the address bar is a convenience, not a permission. If the data source answers any query, a curious viewer only has to edit the URL.
• Wall displays. The NOC television runs a kiosk login that never logs out. Give it a viewer account with exactly the scope shown on screen, and make sure the screen does not face a window or a visitor corridor.
• Screenshots in reports. Crop out host names and addresses before a graph goes into a customer report or a public post.

For many customers the right answer is no login at all. A status page, or a scheduled monthly PDF with availability and traffic for their circuits, answers most of their questions and exposes nothing you did not choose to put in it.

What never to expose

Whatever roles you design, some data stays with administrators and engineers only. It should never appear on a customer view, a shared dashboard or a screenshot:

• SNMP community strings and SNMPv3 user names, keys and passphrases. Many tools show these on a host's settings page, so viewers must not reach that page at all.
• Device configuration backups. They contain password hashes, keys, ACLs and the logic of your firewall.
• API tokens and webhook URLs. A chat webhook URL is itself a credential.
• The full address plan and topology map, for anyone outside the team.
• Raw syslog and authentication logs, which carry user names and source addresses.
• Notification contact lists with personal phone numbers.

On the device side, SNMPv3 has its own access control, the view-based access control model in RFC 3415, which can limit the parts of the MIB a given user may read. Use it so that even the monitoring credentials read only what the monitor needs.

Audit logs

When something changes, you want to know who did it. A useful audit log in a monitoring system records:

• logins, successful and failed, with the source address
• account, role and permission changes
• hosts added, removed or moved between groups
• threshold, trigger and template edits
• acknowledgements and maintenance windows (who silenced what, and for how long)
• exports and report downloads

Ship the audit log off the monitoring server to a separate log store, so an administrator cannot quietly edit history and so the log survives a rebuild. Keep it at least as long as your availability reports, because the first question about a bad month is usually whether something was muted.

Alerts follow people

Notifications are tied to users, so access control and alerting decay together. When an engineer leaves, their account is disabled, and any alert routed only to them now goes nowhere. Route alerts to roles or on-call schedules rather than to named individuals, and check that every alert rule has at least one active recipient (see triggers and actions).

A quarterly access review

Put this on the calendar every three months, next to the rest of the routine administration:

1. Export the user list with roles and last-login dates. Disable anything unused for 90 days.
2. Confirm the administrator group still holds only the named people it should.
3. List API tokens and service accounts with an owner for each. Revoke any that have none.
4. Log in as a test viewer for each customer and look at what they can see, including every dashboard and widget.
5. Check that newly discovered hosts are not landing in a group viewers can see.
6. Use the emergency account once in a controlled test, confirm the alert fired, then change its password.
7. Read the last quarter's audit log for permission changes nobody remembers making.

The one thing to remember: test access by logging in as the viewer, not by reading the permissions screen. What the screen says and what the viewer sees are not always the same.