We implemented JIT access for our privileged accounts. Auditor asked what the engineers actually did during those sessions. We had no answer.

Posted by TurnoverEmergency352@reddit | sysadmin | View on Reddit | 29 comments

We moved our prod environment privileged access to a JIT model about 14 months ago. Engineers request elevated access through a workflow, it gets approved, they get a time limited role, it expires after 2 hours. Thought we had done everything right. Least privilege, approval trail, automatic expiration.
SOC2 Type II audit started last quarter. Auditor pulled our JIT access logs and said great, I can see who requested access, who approved it, and when it expired. Now show me what they did with it.
We did not have that. We have CloudTrail in AWS so some API calls are logged, but for database access, for SSH sessions into instances, for any interactive work that happened inside the network boundary, we had call logs with no context and in some cases nothing at all. The JIT system told us a person had access for 2 hours. It did not tell us whether they read one file or exported a table.
The auditor's position was that the approval controls are the front door, and session activity is the actual evidence that the access was appropriate. Having the door log but not the room log is half a control.
We are now evaluating session recording. BeyondTrust, Teleport, StrongDM are all on the list. The problem we keep running into is that session recording either covers SSH and RDP well but misses database query traffic, or covers databases but requires routing everything through a proxy which our engineering team views as a latency and reliability concern for prod operations.
Has anyone found a session recording setup that gives auditors what they need across SSH, RDP, and database protocols without creating enough friction that engineers route around it or it becomes a single point of failure for prod access?

[-]

omglazrgunpewpew@reddit

I feel like this can be split into two things: audit evidence and access path enforcement. JIT proves who had a temp grant. By itself, it doesn't prove what happened under that grant.

As u/shadow1138 mentioned, ask the auditor which control/control wording they're testing. If your control is “privileged access is approved and time-limited,” then JIT logs + ticket/change linkage may be enough. If your control says privileged activity is monitored, reviewed, or attributable, then the auditor is reasonable to ask for evidence.

I def wouldn't try to find one magic recorder for SSH, RDP, and DB as the first move. Build an evidence matrix:

JIT request: user, approver, reason, ticket/change/incident, role, start/end.
Cloud/API: CloudTrail, GuardDuty/Security Hub findings, IAM role use.
SSH/Linux: SSM Session Manager logging to CloudWatch/S3 where possible, plus shell/auditd/sudo logs. Watch the AWS limitation: Session Manager logging does not cover SSH-over-SSM or port forwarding session contents.
Windows/RDP: Windows Security/Event logs, PowerShell logging, EDR timeline, and RDP/PAM recording if absolutely needed.
DB: Use a database native audit first. For Postgres/RDS, pgAudit is a great place to start. For SQL Server, SQL Server Audit or Extended Events. Log privileged/admin users and exclude noisy application service accounts where appropriate.

Then correlate aaaalll of that in the SIEM by ID, ticket number, source, target, and time window. The auditor usually doesn't need an entire replay of every session. They need defensible evidence that privileged activity is attributable, retained, protected from tampering, and ideally, periodically reviewed.

If you do buy a session rec product, enforce it as the only path. A PAM recorder isn't doing jack if engineers can still SSH, RDP, or connect to databases directly. Put the proxy/gateway in HA, monitor it like prod infra, preserve a glass break path, and alert on bypass.

BeyondTrust/CyberArk-style PAM tends to be strong for RDP/SSH session recording. Teleport/StrongDM style access gateways are often better for ID aware SSH/Kubernetes/DB access. But DB query auditing is often cleaner and lower friction with the DB engine’s own audit tools than with full traffic proxying.

Comments saying “ask what requirement this maps to” are right. Comments saying “use native logs first” are also right. Comments saying “front door only is enough” might be true for their SOC 2 scope/control wording, but it isn't something I’d rely on if your described control implies monitoring privileged activity.

Telamar@reddit

I think this is more AI engagement bait or somesuch nonsense, unless this poster has had a sudden change of career from hospitality two months ago: https://www.reddit.com/r/TalesFromTheFrontDesk/comments/1rqpb0g/when_clients_micromanage_every_single_activity/
Username also matches your generic AI poster type.

btbam666@reddit

How did you find their old posts?

It was kind of weird- I googled and found their username referred to in a weird and obviously AI generated news site that generated a 'story' about a post that they made: https://www.perpetual.fyi/when-just-one-change-turns-into-tour-chaos-tales-of-the-micromanaging-guest/

modder9@reddit

You used to be able to just look at a private Reddit profile and hit the search button to reveal all their posts/comments. It was like that for about a year before they fixed it. Reddit is so incompetent.

merp1991@reddit

I swear the 3 part title is a huge giveaway these days too. It reads like a baity YouTube video title

Josh_Fabsoft@reddit

You're in a tough spot, but it's actually pretty common. Many organizations nail the front door (JIT approval) but struggle with session visibility for auditors.

A few approaches that have worked for others:

Native logging first: Start with what you already have. CloudTrail, Windows Event Logs, or your SIEM might capture enough command history and file access to satisfy auditors. Present this first before investing in new tools.

Session recording: If native logging isn't sufficient, tools like BeyondTrust PRA, CyberArk, or Teleport can record full sessions. The trade-off is added friction for engineers, but auditors love the complete visibility.

Change request correlation: Some teams tie JIT requests to specific change tickets or incidents. This gives context about what the engineer should be doing during that session, making it easier to validate against actual activity logs.

Scoped access: Consider whether you can break down that broad privileged access into more specific, limited roles. Instead of "admin access for 2 hours," maybe "database read access for incident #1234." Easier to audit and better security posture.

The good news is your JIT foundation is solid. Most auditors are reasonable if you can show you're capturing the activity data somewhere, even if it's not perfectly packaged. Start with your existing logs and see how far that gets you before adding complexity.

What type of environment are you running? That might help narrow down the best logging approach.

purefire@reddit

Your auditor sucks

ardeth78@reddit

I force all JIT requests to be tied to a change ticket. Otherwise they have read-only admin roles suitable to their own role in the department. JIT checks that there's an open, approved change ticket for the system they're requesting and then routes for approval.

We have automation for basic admin tasks so the service desk doesn't need to JIT for like password resets or software installs.

Our auditors have also never asked for proof of what was done. We show change ticket describing the change, the JIT request, the approval chain and the fact that our system and app logs go to our SEIM. Never been an issue. Write your policy based on what you currently do and review it before the auditor asks and update it as necessary.

TacticalSniper@reddit

I work for a vendor that has a product in this space. Our older product, that is still sold, captures Windows activity, Linux command prompt activity and database queries made from SSMS. We can even take screenshots of activity.

At the same time, there are plenty of potential gaps as well. For example, you must install an agent on every device you want to monitor - no agent, no monitoring. Linux GUI is not supported; so are other database applications. There are other limitations.

My point is that I hadn't seen a solution that proposes absolute coverage across all vectors. You will have trade-offs with every solution and potentially will need to change at least some things around to support full capture.

linkoid01@reddit

I work with CyberArk for many clients that hit this compliance standard. It does everything that you listed there.

Curious201@reddit

this sounds like a PAM/PIM problem more than an RDP problem. if auditors are asking what engineers did during privileged sessions, “they had approval to access the box” is probably not going to be enough. at minimum i would want named accounts, ticket or change reference, reason for access, start/end time, target system, and logs from the system itself, like windows event logs, command history where available, database audit logs, or application logs. if you truly need session-level evidence, then you are looking at a privileged access tool with recording or command logging, but that is a bigger process change than just installing software. i would start by defining what evidence the auditor will accept, because “prove exactly what they did” can mean very different things depending on the control.

ChampionshipComplex@reddit

No thats bullshit

Auditors are a fucking nightmare, because they make assumptions about things they have no capability to understand.

JIT is a security mechanism that prevents accounts being constantly in a permissive state even when you dont need them to be. So it blocks hacks that might for example breach accounts over night or at the weekend. So its a fantastic security tool. Now 'some' configurations of JIT and products you can purchase - offer additional capabilities like tracking the work being done, recording the activity, having approval workflows to check why access is needed.

But thats a different capability and whether you have that or need it, depends on things like how frequently access is needed, what your level of trust is in the staff involved, how work is issued and carried out.

Auditors cant just assume that JIT is always used for activity trackings, just because they might have seen that use case somewhere else or youve shown them that it 'could' be used that way.

In some organizations that might make sense but in others the logs are what tracks change, tickets are there for customer facing activities, only risk change is CABd not day to day operational stuff and you dont try to shoe horn change management into a security tool.

In our org, elevation to global admin requires approval and a comment about why, but not day to day entra or sharepoint admin.

Kind_Ability3218@reddit

i don't understand? first off, why are devs logging into shells and rdping into prod boxes? don't you log ssh sessions already? isn't the task outlined in the access request? you don't have logs for your database? don't you have log aggregation infrastructure? cloud infra change logging enabled? how do you monitor your infrastructure?!

unless you left out some context, you should be worried about observability for you and your team..... compliance audit requirements should be covered by observability infrastructure that covers your internal needs.

and uhhhh... if you haven't lately, check your database backups and replication stats like replication node deltas and replication status.....

National_Way_3344@reddit

This isn't really complicated

If the request doesn't have a change number or a reason it's declined

Thats half the battle gone, you know what they say they're doing

Then all system access gets logged, you'll actually he able to see what happens

But a DBA doing DBA stuff is less if my concern

PeeEssDoubleYou@reddit

Easy this; the access is granted based on an approved RFC, with a runbook for the work, the evidence that they did what the access was required for is the output of the RFC.

Sroni4967@reddit

session recording or at least command logging saves you here

WRB2@reddit

They are looking to see if you logged key strokes and actions while they’re in privileged accounts.

Something you should do

And of course, that should be checked periodically for abuses

Army Training SIR

RansomStark78@reddit

Your auditor is asking for too much.

Ask for which it audit std is not compliant.

And they cant give you general audit std as guideline for it

Do you have a camera in your server room or every patch closet/switch cabinet. Same principle.

PizzaUltra@reddit

Speaking for a few clients of mine: Yes, we (they) have. Can't change a patch cable without it being recorded.

Get Logs of the service to be associated with the session.

It's not trivial, but should be possible with a decent log collector and some rules. That way you dont need session recording and still get the activities.

Asleep_Spray274@reddit

Do you have a requirement or an audit point to meet for this? Is this a requirement or a nice to have?

dwargo@reddit

What database? With SQL Server look at extended events, and with Postgres look at pgAudit. The approach I’ve seen to prove no changes outside the application is to filter by login and exclude the app user - so you don’t run up infinite logs. If you’re running AWS managed RDS that may limit options.

For session recording Guacamole can do that in a pinch, and if you’re in AWS then SSM might can do SSH recording. Plus the COTS stuff you listed - no experience on that.

shadow1138@reddit

Have you looked at the audit logs of the application/systems themselves? E.g. on any Windows servers or endpoints, configuring event viewer's logging capabilities to show actions. And then forwarding those over to a SIEM platform (Sentinel, etc?)

NIST SP 800-53 details the Audit and Accountability domain. That sounds like what your auditor was attempting to understand - how do you know who did what on which system and when it occurred.

What I would want to know from their perspective is simply 'if one of your JIT accounts was provided access to the system, what system events did they do?' Did they install a routine update as part of maintenance, or did they grant themselves access to confidential information? And, how do you prove that in a way your user cannot refute?

I'd ask your auditor for the text of the security controls they're reviewing and see if you can craft an audit management policy around that as you take stock of the logs your systems already generate (with some validated best practice review for those solutions.) That can guide you towards any technology systems you may need.

And for context, while I don't have direct experience with the SOC2 Type II audit process, I do specialize in CMMC and that's the approach that's been effective there. While there's differences in SOC and CMMC, the same principles should apply to your case.

Hope that helps in some way!

Postalcode420@reddit

Our SOC2 auditor is just fine with just the front door. We have cloud trail, securityhub & Guardduty enabled. But they have so far in 2 years not asked us to present anything other than the evidence that a person used the JIT, and the reason for the elevation. And that it can not be accessed without it. Maybe its the way you have described your process? Our elevation process logs the elevation and also sends a notification to the persons manager and team members.

XInsomniacX06@reddit

How do people know what they are approving the access for then? Typically it would be tied to an approved Change request or Incident requiring privileges that would be checked by the approved for the time window of the request.

If you want session recording then you need to utilize something like CyberArk priveleged session manager and restrict direct RDP access from anything except the PSM server, and don’t allow any admins but the security team access to the PSM server.

Sounds like you’re doing a great job already. Could you use defender timeline as evidence?

Beyond trust PRA for contractors, but who cares if they have friction using it, they aren’t people.