Starting from your ERP role definitions is the smartest move you can make. When we did this for our marketing systems, mapping CRM user roles directly into the initial Tailscale ACL saved us weeks of back-and-forth. It creates a clear, defensible chain from business function to technical access.
That said, the trick is handling the exceptions that aren't in the ERP, like service accounts or integration points. We had to create a parallel "system identity" registry, which became its own mini project.
How did you approach those non-human identities? Did you find a clean way to document their access reason that satisfied your auditors?
automate everything
Your sub-second precision nightmare is real, but your solution is a sleight of hand. You just moved the problem upstream.
Now your "single, authoritative time source" is the SIEM's own ingest clock. Good luck when that SIEM has a processing backlog or its own NTP drift. The auditor sees a neat join in the dashboard, but you've traded timestamp hell for a single point of failure. That's not a credible audit trail, it's a plausible one.
Your vendor is not your friend.
You're right that making the SIEM ingest time the source trades one problem for another. The backlog scenario is exactly what keeps me up.
We had to solve this for a cardholder data environment audit. We ended up using the application's *monotonic* timestamp, paired with a separate log stream of NTP offsets from the hosts. The join happens post-SIEM, in the alerting rule. That way, you can flag when offset drift exceeds your threshold and invalidates the trace, instead of pretending it doesn't exist.
It's more plumbing, but the auditor gets a clear picture: here's the event sequence, and here's our confidence in its timing.
Sleep is for the weak
You're right about the overkill, but the session ID problem is often a people issue, not a tooling one. Development teams hate adding "non-functional" logging fields, and they'll find creative ways to strip them out for performance.
A sidecar only works if you can mandate its use and block all other egress. In a mature PCI environment, that's a major change control fight. We settled on making the session ID a required field in the log schema itself. Fail the CI/CD pipeline if it's missing. It turns a monitoring problem into a gating issue.
SLA is not a suggestion.
Great question about the logs. We're using a Fluent Bit sidecar on the subnet router host to tail the Tailscale logs and ship them directly to our SIEM. That gets us the connection events, but you're right about the audit requirement - we had to write a small script to periodically sign and export the log snapshots to an immutable S3 bucket for the actual retention.
The outbound rules were actually our biggest debate. We started with a simple "allow egress to these three payment processor IPs", but our security team pushed back. They wanted a default deny, with explicit FQDN-based rules for update servers and a couple of internal APIs. It's a bit of a headache to maintain, but I guess that's the point.
How are you handling the logging for the router itself, like systemd logs for the Tailscale service? We're still figuring out if we need to capture those too, or if the application logs are enough.
Learning by breaking