The proposed StoreRounds connector, for your IT person
Pre-production status: StoreRounds' product core works with test-store data, but no named production POS adapter is generally available today. This is the proposed least-privilege design for an approved, founder-assisted pilot, not a record of a shipping connector. Do not install software, create credentials, or approve network access until a pilot-specific build and destination have been supplied for review.
One page a store owner can hand a cautious admin before a pilot. It states the controls the connector would have to meet, how IT should verify them, and how access would be revoked. If a pilot build does not match this document or your direct observations, do not approve it.
Prints on one page. Screen version at storerounds.com/docs/it-security-one-pager. Planning guide: review a proposed on-premise SQL POS connection.
The proposed pilot connector would read a fixed set of sales and store tables as a read-only, least-privilege user and send daily totals outbound only over TLS to a pilot-specific destination. The design requires no inbound ports, no database writes, and no remote interactive access to the machine. Each claim must be verified against the supplied pilot build before approval.
What would an approved pilot connector access?
The proposed pattern uses a dedicated database login named storerounds_ro, created by your administrator and granted SELECT on only the pilot-approved tables below. It must not be a member of db_datareader or any broad role. Object names are POS-specific and must be documented for the approved pilot before credentials are created. Placeholders below are in angle brackets.
| Object (placeholder) | Why it is read | What is not read |
|---|---|---|
| dbo.<SALES_TABLE> | Daily sales header: date, store, totals, transaction count. | No customer PII. |
| dbo.<SALES_LINE_TABLE> | Line items for category and product-level totals. | No cost or supplier terms beyond what the owner enables. |
| dbo.<TENDER_TABLE> | Payment type split: cash versus card totals, for reconciliation. | No card numbers, PAN, or track data. Ever. |
| dbo.<STORE_TABLE> | Store codes and names, to label each location. | No employee records. |
Template grant statements appear in the planning guide, stage 1. They are not instructions to connect now. An approved pilot must provide the exact objects, build, destination, and verification evidence before installation.
What can it do, and what can it not do?
The proposed design may
- Run SELECT queries against the four named table groups.
- Open one outbound TLS connection to the pilot-specific StoreRounds destination on 443.
- Aggregate the day's totals locally and send those totals out.
- Report its own health, reconnect after a dropped session, and log both.
The proposed design must not
- Insert, update, delete, or alter any row or object. Writes are denied at the database.
- Accept any inbound connection. It opens and listens on no port.
- Give anyone at StoreRounds a shell, RDP, or interactive session on the machine.
- Move laterally. It holds one read-only credential to one database and no domain rights.
- Read payment card data or tables it was not granted.
What would an approved pilot need on the network?
The proposed design needs one outbound path, with no inbound rule, port forward, DMZ, or static public IP. The exact destination is not approved by this template; verify it from the pilot package and observed traffic before allowlisting it.
| Direction | Outbound only. Connection is initiated from inside the network. |
| Destination | Pilot-specific named host, supplied and verified before install |
| Port / protocol | TCP 443, HTTPS over TLS 1.2 or higher |
| Inbound ports | None. Nothing is opened or forwarded. |
| Database reach | LAN only, to the POS DB host on 1433 (SQL Server) or 3306 (MySQL) |
| Certificate | Validates the server certificate. Fails closed if it cannot. |
| Runs as | A local service on the back-office machine, least privilege, no domain admin |
For an approved pilot, allowlist only the destination supplied in the signed-off pilot package and deny the connector everything else. Confirm the observed traffic matches before the pilot handles real store data.
How is the data handled in transit and at rest?
- In transit: the proposed design requires TLS 1.2 or higher and local aggregation so daily totals, rather than row-by-row database exports, leave the store. Verify both on the pilot build.
- At rest: the pilot design requires encrypted storage for received totals and an operating-system protected credential store for the database credential, never a plain-text file. StoreRounds must supply evidence before approval.
- Excluded data: the approved table grants must exclude payment card data, customer PII, and every table outside the agreed scope.
- Ownership, export, and deletion: the owner retains control of the data. Self-serve export and deletion controls are not live today; until they ship, requests are handled manually through StoreRounds support and receipted. Dropping the database credential stops new reads.
How do I audit what it is doing?
Do not take this template's word for it. For an approved pilot, verify each claim directly against the supplied build and observed behavior.
Confirm the account is read-only
-- Lists every permission held by storerounds_ro. Expect exactly: -- SELECT / GRANT on the four named objects, CONNECT on the database, -- and the explicit DENY rows for write, execute, and alter. If any -- other GRANT appears, or SELECT on an object you did not name, stop. USE [<YOUR_POS_DB>]; SELECT ISNULL(OBJECT_NAME(major_id), '(database-wide)') AS securable, permission_name, state_desc FROM sys.database_permissions WHERE grantee_principal_id = USER_ID('storerounds_ro') ORDER BY state_desc, securable;
-- Should list SELECT on the named tables and nothing else. SHOW GRANTS FOR 'storerounds_ro'@'10.0.0.%';
Watch what it actually connects to
- Outbound: confirm the pilot connector's only external destination is the named host supplied in the pilot package on 443, at your firewall or with a host tool such as netstat or your endpoint monitor.
- Database sessions: the storerounds_ro sessions appear in your normal DB session views (for example sys.dm_exec_sessions on SQL Server, SHOW PROCESSLIST on MySQL) and run only SELECT. You can enable an audit or the general query log on that account to log every statement it runs.
- Connector log: require a local, human-readable event log of each poll and send. A self-serve Connections screen is not a current production control; StoreRounds must provide pilot logs directly until that control is proven.
How do I revoke it, and how fast?
The proposed pilot must leave an immediate customer-controlled revoke path. Dropping the database credential is the primary independent switch; uninstalling the local pilot software is the second.
- Kill the credential: drop the database user and the connector cannot read again, even if still installed.
- Remove the software: stop and uninstall the pilot connector from the machine. Do not depend on a self-serve dashboard control that is not yet proven.
-- SQL Server USE [<YOUR_POS_DB>]; DROP USER [storerounds_ro]; USE [master]; DROP LOGIN [storerounds_ro]; -- MySQL / MariaDB DROP USER 'storerounds_ro'@'10.0.0.%'; FLUSH PRIVILEGES;
For an approved pilot, verify the account never received write access before relying on this revoke model.
For an approved pilot, rotate the password in the database and update the pilot connector with founder-assisted support. SQL Server: ALTER LOGIN [storerounds_ro] WITH PASSWORD = '<NEW>'; MySQL or MariaDB: ALTER USER 'storerounds_ro'@'10.0.0.%' IDENTIFIED BY '<NEW>'; Then re-run the agreed read-back test. A self-serve connection screen is not available today.
Reviewer sign-off
For the owner's records. Fill in after you have checked the account rights, the outbound destination, and the revoke path above.