Skip to content
Notifications
Clear all

Audit logs are huge and killing our storage. How to trim them?

1 Posts
1 Users
0 Reactions
0 Views
(@jennyk8)
Estimable Member
Joined: 1 week ago
Posts: 78
Topic starter   [#10756]

Hi everyone, I've been wrestling with a classic scaling problem in our BeyondTrust environment and I'm hoping some of you have navigated this already. Our audit logs—specifically for Privilege Cloud sessions—have grown exponentially over the last year. We're now looking at terabytes of data, and it's becoming a real cost and performance issue for our SIEM and long-term storage. The default "keep everything forever" approach just isn't sustainable for us.

I’ve been doing a deep dive into the available controls, and while there are settings, I’m trying to balance compliance needs (we have a 7-year retention requirement for some records) with sheer practicality. I’d love to compare notes on what others are doing.

Here’s what I’ve explored or configured so far, focusing on reducing volume *before* it hits storage:

* **Session Recording Settings:** We've switched from recording *all* session activity to "Input and metadata only" for most of our non-critical systems. This drastically reduces the file size per session.
* **Log Verbosity Levels:** In the BeyondTrust Platform Settings, we adjusted the diagnostic logging level for non-production environments from "Verbose" down to "Warning." This cut down a surprising amount of overhead.
* **API & Integration Logs:** We reviewed which integrations (like our SIEM connector) were pulling full fidelity and set some to only pull aggregated or alert-based data.

My main hurdles now are:

1. **The Core Audit Data:** Even with lighter recordings, the core audit trail of who accessed what, when, and what commands were run is massive. Is anyone using the built-in job to archive older logs to colder storage (like S3 Glacier or Azure Archive)? How has that workflow held up?
2. **Filtering at the Source:** I’m looking at policies to exclude certain low-risk, high-volume systems from generating detailed audit events, but the fear of creating a blind spot is real.
3. **Summarization:** For compliance, we don’t necessarily need every single `ls` command from a developer’s session. Has anyone built a downstream process to summarize session data after, say, 30 days, keeping only the metadata (user, asset, duration, approval) and a flag for any policy violations?

I put together a quick comparison of the impact of the changes we’ve made, which might be useful:

| Setting | Before State | After State | Estimated Storage Reduction |
| :--- | :--- | :--- | :--- |
| Session Recording Type | Full Video Capture | Input & Metadata Only | ~65% per session |
| Diagnostic Log Level | Verbose (All) | Warning (Prod), Error (Non-Prod) | ~40% of platform logs |
| Syslog Forwarding | All Events | Only Alert & Audit Events (excludes Debug/Info) | ~50% of forwarded volume |

What I’m missing is a strategic view. How are you all approaching this? Are you setting hard global retention periods within the BeyondTrust platform itself, or handling it all externally? Any scripts or tools you’ve built to parse and purge these logs gracefully?

Really appreciate any workflows or real-world numbers you can share.
~jenny


Let the data speak.


   
Quote