Waarom geheimen van je thuisserver verplaatsen van configuratiebestanden naar een geheimenopslag?

Geheimen voor thuisservers horen in een secretsopslag, omdat configuratiebestanden langdurige inloggegevens dupliceren in apps, back-ups, logboeken en beheerworkflows.

Een zelfgehoste server begint vaak met één databasewachtwoord in een compose-bestand en groeit daarna uit tot een verzameling API-sleutels, cloudtokens, SMTP-inloggegevens, VPN-sleutels, encryptiewachtwoorden, webhookgeheimen en beheerderscookies. Die waarden kunnen terechtkomen in omgevingsbestanden, geëxporteerde stacks, schermafbeeldingen, back-ups, shellgeschiedenis en supportbundels. Een secretsopslag maakt niet elke app betrouwbaar, maar creëert wel één gecontroleerd ophaalpad met afzonderlijke authenticatie, rotatie, beleidsregels en auditregistraties. In de onderstaande secties wordt uitgelegd hoe dit de blootstellingsgrens verandert.

Configuratiebestanden veranderen één inloggegeven in vele kopieën

Een configuratiebestand is ontworpen om leesbaar te zijn voor de applicatie en handig voor implementatie. Wanneer het plaintext-inloggegevens bevat, wordt elke kopie van dat bestand een nieuwe plek waar het geheim kan uitlekken.

HashiCorp beschrijft de verspreiding van geheimen als het verschijnen van inloggegevens in broncode, configuratie, versiebeheer, wiki's en andere systemen zonder één betrouwbare inventaris. Op een thuisserver kunnen geëxporteerde compose-stacks en geautomatiseerde back-ups oude waarden bewaren lang nadat de live-app is gewijzigd.

Het risico betreft niet alleen diefstal van het huidige bestand. Een geredigeerd dashboard, gekopieerd probleemoplossingsarchief of afgeschreven back-up kan een nog steeds geldig token bevatten dat niemand eraan denkt in te trekken.

Een secretsopslag scheidt configuratie van inloggegevens

De applicatie heeft nog steeds een databaseadres, gebruikersnaam, geheimnaam of ophaalmethode nodig, maar de implementeerbare configuratie hoeft de waarde van het inloggegeven zelf niet langer te bevatten.

Een gecentraliseerde opslag creëert een gecontroleerd ophaalkanaal waarin een geauthenticeerde workload alleen het geheim ontvangt dat deze mag gebruiken. Het geheim kan tijdens runtime worden geïnjecteerd, in een beperkt geheugenpad worden aangekoppeld of worden uitgewisseld voor een kortstondige inlogcredential.

Dit voorkomt niet dat een gecompromitteerde geautoriseerde app haar eigen geheim gebruikt. Het voorkomt wel dat niet-gerelateerde apps, back-ups en configuratielezers die waarde standaard ontvangen.

De opslag zelf wordt kritieke infrastructuur. Daarom moeten de beschikbaarheid, back-up, het herstel en de toegang voor beheerders expliciet worden ontworpen.

Een identiteit per app vervangt gedeelde beheerdersinloggegevens

Een secretsopslag is het nuttigst wanneer elke applicatie zich met een eigen identiteit authenticeert. Meerdere containers zouden geen geheimen moeten ophalen door één root-token of één voor iedereen leesbaar hoofdbestand te delen.

Moderne methoden voor geheimenbeheer combineren workloadidentiteit met beleid op basis van minimale rechten, zodat een foto-app haar databasewachtwoord kan lezen terwijl een downloader geen encryptiesleutels voor back-ups kan opvragen. De identiteit kan worden gekoppeld aan een machine, serviceaccount, orchestrator, certificaat of kortstondige aanmeldingsflow.

Dit verandert de omvang van de schade door een uitgelekt applicatiecredential. De aanvaller krijgt toegang tot één afgebakend geheimenpad in plaats van tot een bestand met inloggegevens voor elke service op de host.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rotatie wordt een levenscyclusbewerking in plaats van een zoektocht door bestanden

Hardgecodeerde inloggegevens zijn moeilijk te wijzigen, omdat elke gebruiker en elke gekopieerde configuratie moet worden gevonden, bewerkt en in de juiste volgorde opnieuw gestart. Die operationele kosten moedigen het gebruik van langdurige geheimen aan.

Dynamische geheimen kunnen voor één applicatiesessie worden gegenereerd en ingetrokken of verlopen zonder een permanent wachtwoord in meerdere bestanden te hoeven bewerken. Statische geheimen kunnen ook centraal worden geversioneerd en geroteerd wanneer de backend geen dynamische inloggegevens kan uitgeven.

Voor rotatie is nog steeds applicatiegedrag nodig waarmee inloggegevens veilig opnieuw kunnen worden geladen of vernieuwd. Een opslag kan geen downtime voorkomen wanneer de app haar geheim slechts één keer bij het opstarten leest en verouderde verbindingen onbeperkt aanhoudt.

Auditregistraties tonen welke workload een geheim heeft opgehaald

In plaintext-bestanden wordt zelden vastgelegd wie ze heeft gelezen. Bestandssysteemlogboeken kunnen in sommige omgevingen toegang tonen, maar leggen die leesactie meestal niet vast als een specifieke geheimversie, beleidsbeslissing of later gebruik in de backend.

Richtlijnen voor geheimenbeheer beschouwen toegangscontrole en -audit als een belangrijk voordeel van centralisatie. Een ophaalregistratie kan de workload, het geheimenpad, het tijdstip, de bron en het resultaat identificeren, zodat normaal opstartgedrag kan worden onderscheiden van onverwachte grootschalige toegang.

Auditlogboeken moeten buiten de applicatie die ze bewaken worden opgeslagen en zelf tegen uitlekken van geheimen worden beschermd. Het volledig loggen van de teruggegeven waarde zou de oorspronkelijke blootstelling opnieuw creëren.

Bij migratie moeten oude kopieën worden verwijderd, niet alleen een kluis worden toegevoegd

Een inloggegeven naar een opslag verplaatsen maakt de kopieën die al aanwezig zijn in Git-geschiedenis, back-ups, compose-exports, schermafbeeldingen, shellgeschiedenis of applicatielogboeken niet ongeldig.

GitGuardian adviseert toegewijd beheer te combineren met rotatie van inloggegevens en scanning, omdat een kluis de waarden beheert die correct worden opgehaald, maar geheimen die eerder zijn uitgelekt niet kan wissen. Roteer het inloggegeven na de migratie en verwijder of laat herstelbare oude kopieën waar mogelijk verlopen.

De bespreking van de reikwijdte van bind mounts gaat over dezelfde grens: een geheimenbestand dat in elke container wordt aangekoppeld, blijft breed blootgesteld, zelfs als de bron een kluis wordt genoemd.

Test het herstel na een schone herstart, waarbij het oorspronkelijke configuratiegeheim is verwijderd. De migratie is pas voltooid wanneer de beoogde apps actuele waarden ophalen, onbevoegde apps falen, rotatie werkt en de secretsopslag zelf veilig kan worden hersteld.

Veelgestelde vragen

Zijn omgevingsvariabelen een secretsopslag?

​​Nee. Ze zijn een aflevermechanisme en kunnen, afhankelijk van het platform, nog steeds zichtbaar worden in procesinspectie, crashrapporten, containermetadata, foutopsporingsuitvoer of geëxporteerde implementaties.

Moet elke thuisserver een speciaal vaultproduct gebruiken?

Niet noodzakelijk. De vereiste complexiteit hangt af van het aantal apps, het dreigingsmodel, de herstelvaardigheden en de vraag of eenvoudigere injectie van beschermde bestanden beperkte toegang en betrouwbare rotatie kan bieden.

Beschermt een secretsopslag tegen een gecompromitteerde geautoriseerde app?

Slechts gedeeltelijk. De opslag kan beperken welke geheimen de app ontvangt en de geldigheidsduur ervan verkorten, maar de app kan inloggegevens blijven gebruiken die zij rechtmatig mag ophalen.