# Case Study: Vault Guard — Zero-Trust Credential Beveiliging | tom.cool > Eigen TomOS-product voor gecontroleerde credentialtoegang via een centrale gateway, tijdelijke sessies, MFA-goedkeuring en fail-closed gedrag. Bron: [https://tom.cool/cases/vault-guard](https://tom.cool/cases/vault-guard) Dit is de tekstweergave van de gepubliceerde pagina. Voor formulieren, configuratie, actuele beschikbaarheid en bestellen: open de bronpagina. [Terug naar realisaties](https://tom.cool/cases) - Eén gerichte aanvraag **Aanvraag** Een automatisering vraagt toegang. - Toestaan of weigeren **Goedkeuring** Een nieuwe sessie vraagt toestemming via Duo. - Toegang verloopt automatisch **Tijdelijk gebruik** Alleen tijdens een geldige sessie. Geweigerd of verlopen? Het geheim wordt niet vrijgegeven. Bedrijf / Eigen product ## Vault Guard Een eigen TomOS-product dat automatisaties credentials via een centrale, MFA-beveiligde toegangspoort laat opvragen, met tijdelijke sessies en fail-closed gedrag. [Ontdek het project](https://tom.cool/cases/vault-guard#hoofdstuk-1) [Bespreek je vraag](https://bedrijf.tom.cool/#veiligheid) Projectgegevens API Centrale toegang MFA Nieuwe sessie TTL Tijdelijke sessie Logs Controleerbare toegang Het Probleem ### Wachtwoorden Delen is een Beveiligingsnachtmerrie TomOS gebruikt verschillende geautomatiseerde processen — van beheerflows tot AI-assistenten. Sommige daarvan hebben **wachtwoorden, API-sleutels en toegangscodes** nodig. De ontwerpvraag: hoe geef je een proces tijdelijk toegang zonder geheimen als gewone configuratie te verspreiden? De traditionele aanpak — credentials opslaan in configuratiebestanden op elk apparaat — is als een sleutel onder de deurmat leggen. Het werkt, tot iemand hem vindt. - Wachtwoorden verspreid over meerdere apparaten en bestanden - Geen zicht op wie wanneer welke credential gebruikt - Een gecompromitteerd apparaat kan lokaal opgeslagen geheimen uitlezen - Rotatie wordt moeilijker wanneer dezelfde credential op meerdere plaatsen staat Wat Niet Werkte ### De Ontwerpvereisten De toegangspoort moest verschillende maatregelen combineren zonder één maatregel als volledige bescherming voor te stellen: - **Rotatie ondersteunen:** een centrale bron beperkt het aantal plaatsen dat bij een wijziging moet worden aangepast - **Toegang segmenteren:** callers en sessies moeten afzonderlijk kunnen worden ingetrokken en beoordeeld - **Fail-closed werken:** bij ontbrekende goedkeuring, verlopen sessie of gatewayfout wordt geen credential vrijgegeven **Ontwerpprincipe:** behandel netwerktoegang niet als voldoende bewijs dat een credentialverzoek legitiem is. De Afweging ### Waarom Een Eigen Toegangspoort? Vault Guard vervangt de centrale secrets manager niet. Het voegt een gecontroleerde toegangspoort toe voor agent- en automatiseringsworkflows die een secret tijdelijk in het geheugen nodig hebben. De beveiliging ontstaat uit de combinatie van centrale opslag, een geauthenticeerde caller, MFA bij een nieuwe sessie, een korte sessieduur, logging en een clientcontract dat geheimen niet naar bestanden schrijft. Ontwerplaag | Invulling | Doel | Grens | Controle | Centrale kluis | Secrets manager | Eén bron | Beheert niet de caller | Rotatiebeleid | Gateway | Vault Guard API | Caller controleren | Geeft secret in-memory door | Requestlogs | MFA-sessie | Goedkeuring | Nieuwe sessie openen | Tijdelijk geldig | Vervaldatum | Clientcontract | In-memory gebruik | Persistente kopieën vermijden | Caller blijft risicogrens | Code- en logreview | Bij een nieuwe readsessie vraagt Vault Guard menselijke goedkeuring. Verzoeken binnen de geldige sessie gebruiken die tijdelijke autorisatie; gevoelige schrijfhandelingen volgen een afzonderlijke goedkeuringsroute. De Oplossing ### Eén Gateway, Tijdelijke Goedkeuring We bouwden **Vault Guard** als gecontroleerd toegangspunt tussen geautoriseerde callers en de centrale secrets manager. Een nieuwe readsessie vereist expliciete MFA-goedkeuring; daarna is de sessie slechts tijdelijk geldig. Systeem vraagt credential Vault Guard onderschept Push naar goedgekeurd apparaat Goedgekeurd? Credential vrijgegeven Na goedkeuring ontvangt de caller de gevraagde waarde tijdelijk in het geheugen. Het clientcontract verbiedt opslag in configuratiebestanden en logs, maar een gecompromitteerde geautoriseerde caller blijft een risico. Daarom horen beperkte rechten, korte sessies, logging en rotatie bij hetzelfde ontwerp. In De Praktijk ### Expliciete Sessiesturing Bij het openen van een nieuwe readsessie verschijnt een push-notificatie op een goedgekeurd apparaat. Na goedkeuring kan de caller gedurende de ingestelde sessieduur toegestane secrets opvragen. Bij weigering, time-out of verlopen sessie faalt de gateway gesloten. - Nieuwe readsessie: push-notificatie en expliciete goedkeuring - Daarna een tijdelijke sessie voor toegestane verzoeken - Na de sessieperiode: opnieuw goedkeuring vereist - Wordt het verzoek geweigerd of genegeerd? Toegang geblokkeerd Schaalbaar ### Elk Systeem, Eigen Toegangspas Het ontwerp ondersteunt afzonderlijke callercredentials en sessies. Daardoor kan toegang gericht worden ingetrokken, mits callers daadwerkelijk met gescheiden rechten en sleutels zijn ingericht. - Unieke sleutel per systeem of automatisatie - Gericht intrekken volgens het ingerichte toegangsmodel - Afzonderlijke sessies waar callersegmentatie is toegepast - Toegangsmetadata voor controle en incidentonderzoek ### De Technische Uitkomst Een eigen toegangspoort die centrale secretopslag, tijdelijke autorisatie en fail-closed gedrag combineert. Ze verkleint het verspreidingsrisico, maar elimineert geen risico op een gecompromitteerde caller, foutieve rechten of misbruik tijdens een geldige sessie. Central Secrets manager MFA Nieuwe readsessie Memory Clientcontract Fail closed Geen geldige sessie ### Waarom Dit Werkt ##### Geen Persistente Kopie De goedgekeurde clients horen credentials alleen in-memory te gebruiken en nooit naar broncode, configuratie of logs te schrijven. ##### MFA Per Nieuwe Sessie Een nieuwe readsessie vereist goedkeuring op een vertrouwd apparaat. Verzoeken binnen de geldige sessie gebruiken de tijdelijke autorisatie. ##### Fail-Closed Bij weigering, time-out of ontbrekende sessie wordt geen credential vrijgegeven. Dit maakt het systeem niet penetratiebestendig. ##### Rotatie Blijft Nodig Centrale opslag vereenvoudigt rotatie, maar vervangt ze niet. Rechten, callers en logs moeten eveneens worden beheerd. Eigen TomOS-product ### Controleerbare toegang Vault Guard voegt een expliciete autorisatielaag toe tussen automatisaties en de centrale kluis. De beveiligingswaarde hangt af van correcte callerrechten, sessie-instellingen, logging, clientgedrag en rotatie. ### Ook uw credentials onder controle brengen? Van zero-trust architectuur tot MFA-integratie — ik ontwerp beveiligingsoplossingen op maat van uw situatie. Neem contact op voor een vrijblijvend gesprek. [Bekijk security & continuïteit](https://bedrijf.tom.cool/#veiligheid)