Hoe VaultPAM sessieopnamen beveiligt

Een opname die niet betrouwbaar is, is geen bewijs. Zij kan activiteit tonen, maar niet de moeilijkere vragen beantwoorden: is dit de opname van deze sessie, is zij gewijzigd, wie heeft haar bekeken en is zij volgens de regels behandeld? Daarom is het beschermen van een opname meer dan een bestand opslaan. Het is een technische keten die begint met gecontroleerde vastlegging en doorgaat met encryptie, integriteitsverificatie, toegangsbeslissingen, bewaring en auditgeschiedenis. Dit artikel legt uit hoe VaultPAM die keten opbouwt, zodat een opname kan dienen als bewijs waarvoor verantwoording kan worden afgelegd, in plaats van als een niet-geverifieerd artefact te worden behandeld.

Lees voor het audit- en onderzoeksperspectief — de vragen die een beoordelaar over het voltooide record stelt — Sessieregistratie als auditbewijs. Dit is het aanvullende perspectief: hoe de opname wordt behandeld zodat bewijs betrouwbaar kan zijn.

Begin met het gecontroleerde toegangspad

Vertrouwen kan niet pas na afloop van een sessie worden toegevoegd. VaultPAM legt opnamen vast via zijn gecontroleerde, browsergebaseerde en agentloze toegangspad en bemiddelt daarbij RDP-, SSH-, VNC- en HTTP-sessies. Dat pad biedt het punt waarop een opname als onderdeel van de geprivilegieerde sessie wordt vastgelegd.

Dit is belangrijk omdat bewijs verbonden moet blijven met de toegangsactiviteit die het weergeeft. De opname is niet slechts een handig bestand om te bewaren; het is een beschermd record van een sessie die het gecontroleerde pad heeft doorlopen. Alles wat volgt, is ontworpen rond dezelfde vraag: kan een beoordelaar op dit specifieke artefact in deze specifieke context vertrouwen?

Versleutel elk artefact en bind het aan zijn context

In rust wordt elk opnameartefact versleuteld met AES-256-GCM, met een eigen gegevenssleutel per artefact. Dit is envelopversleuteling: de gegevenssleutel beschermt het artefact, terwijl een speciale sleutelbeheerdienst de gegevenssleutel omhult. Sleutelmateriaal staat nooit naast de gegevens die het beschermt.

De scheiding is bewust. Een opname bevat geprivilegieerde activiteit; de bescherming van de inhoud mag dus niet afhangen van het behandelen van opname en sleutel als één pakket. Envelopversleuteling scheidt het versleutelde artefact van het sleutelmateriaal, terwijl elk artefact zijn eigen gegevenssleutel kan hebben. Eenvoudig gezegd wordt het artefact beschermd met een voor dat artefact gemaakte sleutel, en wordt die sleutel afzonderlijk beschermd.

Encryptie alleen is niet voldoende wanneer versleutelde tekst tussen contexten kan worden verplaatst en geaccepteerd alsof hij daar thuishoort. VaultPAM authentiseert ook contextuele metadata als aanvullende geauthenticeerde gegevens: de organisatie, opname, het artefact en het segment. Dit is contextbinding. Als versleutelde tekst wordt verplaatst of opnieuw gelabeld voor een andere context, mislukt de ontsleuteling.

Deze keuze beschermt zowel de betekenis rond de bytes als de bytes zelf. Een beoordelaar hoeft niet aan te nemen dat een versleuteld segment nog steeds behoort bij de opname, het artefact, de organisatie en de segmentcontext die ernaast staan. De encryptie controleert die relatie tijdens het ontsleutelen.

Verwijder platte tekst pas nadat de beschermde kopie is bewezen

Veilige verwerking heeft een belangrijk detail in het schrijfpad: lokaal vastgelegde platte tekst wordt niet verwijderd enkel omdat een upload is gestart. Deze wordt pas verwijderd nadat de versleutelde upload persistent is opgeslagen en een byte-voor-byte ontsleutelings-/terugleesverificatie is geslaagd.

De volgorde is opzettelijk. Zij voorkomt dat een uploadverzoek wordt beschouwd als bewijs dat het beschermde artefact beschikbaar en leesbaar is. De persistentievoorwaarde bevestigt dat de versleutelde upload is opgeslagen; de ontsleutelings-/terugleescontrole bevestigt dat het versleutelde artefact byte voor byte kan worden geverifieerd. Pas nadat beide voorwaarden zijn geslaagd, wordt de lokaal vastgelegde platte tekst verwijderd.

Deze kleine sequentieregel heeft een grote bewijstechnische consequentie. Het beschermde record moet worden vastgesteld en gecontroleerd voordat de lokale platte tekst wordt gewist. Anders zou een storing tussen de vastlegging en de geverifieerde versleutelde persistentie ertoe kunnen leiden dat een organisatie niet op het beoogde opnameartefact kan vertrouwen.

Wanneer opnamemetadata en bewijs tussen interne diensten bewegen, worden die aanroepen wederzijds geauthenticeerd met mTLS. Wederzijdse authenticatie zorgt ervoor dat de interne partijen die deze opnamecontext dragen elkaar authenticeren.

Maak wijzigingen detecteerbaar en verificatie herhaalbaar

Vertrouwelijkheid en integriteit beantwoorden verschillende vragen. Encryptie beschermt opname-inhoud in rust. Integriteit vraagt of de opname-inhoud nog samenhangt met de vastgelegde sessie.

VaultPAM beschermt opname-inhoud met een SHA-256-hashketen over opnamefragmenten. Het bewaart duurzame integriteitsmanifesten en een offline verificatiehulpmiddel kan elke opname opnieuw controleren. Samen bieden deze elementen een verificateur een herhaalbare manier om de integriteit van een opname te toetsen, in plaats van te vertrouwen op de bewering dat een opname niet is gewijzigd.

De hashketen maakt afzonderlijke opnamefragmenten onderdeel van een geordende integriteitscontrole. Het duurzame manifest bewaart de voor verificatie benodigde informatie en het offline hulpmiddel maakt het mogelijk die controle opnieuw uit te voeren wanneer bewijs nodig is. Dit is nuttig bij een routinematige beoordeling, onderzoek of audit: de integriteitsvraag kan door verificatie worden beantwoord, niet enkel door vertrouwen.

Native RDP-opname heeft een aanvullende voorwaarde. Een hulpbestand voor frame-integriteit is vereist en de inname mislukt als de verificatie daarvan niet foutloos is. Daardoor is frame-integriteit een vereist onderdeel van het accepteren van een native RDP-opname, in plaats van een optionele controle die later wordt uitgevoerd.

Bepaal wie het bewijs kan zien en leg die toegang vast

Een beschermde opname kan nog steeds risico creëren als te veel mensen haar kunnen bekijken of exporteren. VaultPAM scheidt de rechten om een opname te bekijken of af te spelen van de rechten om haar te exporteren of downloaden. Dit zijn afzonderlijke handelingen met afzonderlijke autorisatiebeslissingen.

Alle opnamebewerkingen zijn afgebakend per klantomgeving. Dit geldt voor de handelingen rond opnamen, inclusief toegang tot het bewijs. Die grens is belangrijk omdat een opname alleen betekenis heeft binnen de context van de organisatie en opname waartoe zij behoort.

VaultPAM legt zowel geslaagde toegang als autorisatieweigeringen vast in het auditlog. Het resultaat is een eenvoudig maar belangrijk principe: toegang tot het bewijs is zelf bewijs. Een geslaagde weergave of export laat een record achter, net als een niet-geautoriseerde poging. Daardoor is de beoordeling van opnamen verantwoordbaar, zonder te stellen dat iedereen daartoe toegang zou moeten hebben.

Bewaar opnamen met operationele waarborgen

Bewaring moet de beschikbaarheid van bewijs in evenwicht brengen met een gedefinieerde levenscyclus. VaultPAM biedt configureerbare bewaarperioden van 30, 90, 180 of 365 dagen. De standaardwaarde is 90 dagen, met een respijtperiode van 7 dagen.

Het verkorten van een bewaarperiode krijgt aanvullende waarborgen. Het vereist nieuwe verhoogde authenticatie en een getypte bevestiging door een platformbeheerder. De daaruit voortvloeiende verwijderingen worden geaudit en verwijdering houdt rekening met waarborgen voor een juridische blokkering.

Deze waarborgen richten de aandacht op de wijziging die de beschikbaarheid van opnamebewijs kan verkorten. Een verkorting van de bewaartermijn wordt niet behandeld als een gewone configuratiewijziging: zij vereist een nieuwe authenticatiestap, een expliciete getypte bevestiging en de rol van platformbeheerder. De daaruit voortvloeiende verwijderactiviteit wordt onderdeel van de auditgeschiedenis, terwijl juridische blokkeringen een waarborg blijven in het verwijderingsproces.

Wat dit betekent voor NIS2- en SOC 2-lezers

Voor NIS2-lezers koppelt de conformiteitskoppeling van VaultPAM artikel 21, lid 2, onder a), aan het auditspoor en sessieopnamen voor alle geprivilegieerde toegang, en artikel 21, lid 2, onder b), aan realtime waarschuwingen voor verdachte geprivilegieerde sessies en volledige sessieweergave voor incidentonderzoek. De technische details in dit artikel helpen verklaren waarom een sessieopname deze koppeling kan ondersteunen: het record wordt via het gecontroleerde pad vastgelegd, in rust beschermd, aan zijn context gebonden en kan op integriteit worden geverifieerd.

Voor SOC 2 is de huidige status precies: Type II-audit loopt, rapport wordt in 2026 verwacht. De bescherming van opnamen moet worden beoordeeld aan de hand van de aantoonbare controles, waaronder encryptie, verificatie, autorisatiegrenzen, waarborgen voor bewaring en auditgeschiedenis — niet aan de hand van een rapport dat nog niet is uitgebracht.

Zie voor de bredere beveiligingscontext rond de hier beschreven opnamebeschermingen de beveiligingspagina van VaultPAM.

Bewijs moet toetsbaar zijn, niet alleen opgeslagen

Het resultaat is niet de belofte dat een opgeslagen opname betrouwbaar is enkel omdat zij bestaat. Het is een verzameling controles en grenzen: gecontroleerde vastlegging, envelopversleuteling met een gegevenssleutel per artefact, geauthenticeerde context, geverifieerde versleutelde persistentie vóór verwijdering van lokale platte tekst, hashketenverificatie, afzonderlijke toegangsrechten, per klantomgeving afgebakende bewerkingen en beheerde bewaring.

Dit is de technische standaard achter een opname die bewijskracht kan hebben. Wanneer de vraag is wat er in een geprivilegieerde sessie is gebeurd, moet het antwoord berusten op een record waarvan de inhoud, context, toegang en levenscyclus allemaal kunnen worden onderzocht. Zo wordt sessieopname bewijs waarop een organisatie kan vertrouwen.