Een eigen TomOS-product dat automatisaties credentials via een centrale, MFA-beveiligde toegangspoort laat opvragen, met tijdelijke sessies en fail-closed gedrag.
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.
De toegangspoort moest verschillende maatregelen combineren zonder één maatregel als volledige bescherming voor te stellen:
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.
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.
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.
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.
Het ontwerp ondersteunt afzonderlijke callercredentials en sessies. Daardoor kan toegang gericht worden ingetrokken, mits callers daadwerkelijk met gescheiden rechten en sleutels zijn ingericht.
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.
De goedgekeurde clients horen credentials alleen in-memory te gebruiken en nooit naar broncode, configuratie of logs te schrijven.
Een nieuwe readsessie vereist goedkeuring op een vertrouwd apparaat. Verzoeken binnen de geldige sessie gebruiken de tijdelijke autorisatie.
Bij weigering, time-out of ontbrekende sessie wordt geen credential vrijgegeven. Dit maakt het systeem niet penetratiebestendig.
Centrale opslag vereenvoudigt rotatie, maar vervangt ze niet. Rechten, callers en logs moeten eveneens worden beheerd.
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.
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