A read-only access checklist for connecting production systems

Every tool that reads from production is a new path into it. Monitoring agents, log shippers, analytics platforms and incident tools all ask for access, and the request usually arrives with a deadline. This checklist is for the security and platform teams who have to say yes safely. It applies to any vendor, including us.

1. One dedicated account per source

Never reuse a person's credentials or a shared service account. Create an account for the tool on each system it reads from, named so that anyone reading a log knows what it is. One account per source means you can revoke one without touching the others, and every action in your own logs is attributable.

• Name it after the tool and its purpose, for example pindot_reader.
• Give it no interactive login where the system allows that.
• Record who owns the account and when it is due for review.

2. Least privilege, by kind of source

What read-only means depends on what is being read. Work through each source type on its own terms.

Databases

Grant SELECT on the schemas the tool genuinely needs, and nothing else. Where you can, point it at a read replica rather than the primary, and set a statement timeout so a heavy query cannot hurt production. In PostgreSQL the role can also be made read-only at the session level, so a write fails even if a grant is later widened by mistake.

CREATE ROLE pindot_reader LOGIN PASSWORD '<from your vault>';
GRANT CONNECT ON DATABASE payments TO pindot_reader;
GRANT USAGE ON SCHEMA public TO pindot_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO pindot_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO pindot_reader;
ALTER ROLE pindot_reader SET default_transaction_read_only = on;
ALTER ROLE pindot_reader SET statement_timeout = '30s';

Log files on servers

If logs are read over SSH, use a dedicated user with key-based login only, membership of the group that can read the log directory, and nothing more. Restrict the key in authorized_keys so it cannot forward ports or open a terminal, and limit where it may connect from.

restrict,from="10.4.0.0/16" ssh-ed25519 AAAA... pindot-reader

File drops, service desks and APIs

• SFTP drops: a chrooted account that can list and read the drop directory, with no write permission.
• Service desks and ticketing: an integration user with read scopes only. Check whether read includes attachments, which often hold personal data.
• REST APIs: a token scoped to the endpoints the tool polls. Prefer tokens that expire.
• Pushed sources such as syslog and webhooks: a separate token or port per source, so one noisy or compromised sender can be cut off alone.

3. Where credentials live, and how they change

Ask where the tool stores the credentials you give it, and how. They should be encrypted when saved, never shown back to users after entry, and never written to the tool's own logs. Keep the source of truth in your own vault and plan rotation before go-live, not after.

• Credentials are encrypted at rest and never displayed again once saved.
• Rotation is a routine change, not an outage: test it once before launch.
• Credentials never travel by email, chat or ticket comment.

4. Network paths

Draw the path from the tool to each source before you open anything. Know which host the connection comes from, which port it reaches, and whether anything has to cross a network boundary. Allow-list the tool's address on each source. And ask the opposite question too: what does the tool need to reach on the way out? For tools that run inside your network, the right answer may be nothing at all.

5. Audit, on both sides

Your own systems should record what the tool's accounts did, and the tool should keep its own record of what it read and why. When the two agree, you can answer an auditor's question without trusting either alone. Turn on query or access logging for the dedicated accounts, at least for the first weeks.

6. Test the boundary

Before declaring the connection read-only, try to break it. Log in as the tool's account and attempt a write: an insert, a file upload, a ticket update. Each should be refused by the source system. Keep the evidence of that test with the access request.

Questions to ask any vendor

1. Which permissions does each connector need, exactly, and why?
2. Can the product write to our systems in any configuration? If so, what turns that on, and who can?
3. How are our credentials stored, who at your company can see them, and how do we rotate them?
4. What leaves our network, if anything, and can we run the product with no outbound connection?
5. What does the product record about each query or answer, and can we export that record?
6. How do we remove a source completely, including anything already collected from it?

How Pindot answers these

Pindot connects to each source with read-only access, ideally through a dedicated account as described above. It never writes to the systems it reads, the credentials it uses are encrypted when saved, and every answer leaves an audit record of where it looked and which records it used. Bring this checklist to a demo and we will go through it with you, connector by connector.