Er is geen ‘ontsleuteling’ voor een gecodeerd VPN-geheim

De uitdrukking de gecodeerde sleutel ontsleutelen veronderstelt één enkele bewerking die niet bestaat. Een opgeslagen VPN-geheim kan basis-gecodeerde bytes zijn, een versleutelde blob die aan een keystore is gebonden, of een eenrichtingsverificator die helemaal niet kan worden omgekeerd, en elk ervan vraagt een andere reactie. Basis-codering voegt naar ontwerp geen vertrouwelijkheid toe, dus het decoderen kan een bruikbaar geheim terugvinden in plaats van een beschermd geheim te onthullen. Beginnen bij het veld en bij het product dat het heeft geschreven, is de enige betrouwbare identificatie.

Houd de waarde weg bij webdecoders en bij openbare forumberichten, want een gecodeerd geheim blijft een geheim.

Codering, versleuteling en een verificator zijn drie dingen

RFC 4648 definieert basis-coderingen als weergaven van gegevens in beperkte omgevingen, en de beveiligingssectie zegt duidelijk dat ze geen enkele computationele vertrouwelijkheid bieden. Dat betekent dat een Base64-veld door iedereen terug in bytes kan worden omgezet, wat een herstelrisico is en geen cryptografische barrière. Versleuteling is anders: zonder het sleutelmateriaal blijven de bytes ondoorzichtig. Een verificator is weer anders, omdat hij ontworpen is om niet omgekeerd te kunnen worden. De gedocumenteerde veldnaam lezen vertelt meestal welke van de drie u hebt.

Een tekenreeks Base64 noemen stelt niet vast wat hij bevat. Hij kan decoderen naar een sleutel, naar een geserialiseerde structuur of naar willekeurige opvulling, en de aanblik van de tekst zegt niets over welke.

Identificeer het veld voordat u het aanraakt

Noteer het exporterende product en de versie, het profielformaat en de gedocumenteerde veldnaam. Splits daarna de soorten geheim die in het spel zijn: een groepsvooraf gedeelde sleutel is geen individueel accountwachtwoord, geen wachtwoordzin voor een privésleutel en geen authenticatietoken. Die hebben verschillende eigenaren en verschillende vervangingsprocedures, en ze verwarren verandert de verkeerde inloggegevens. Een profiel dat nog verbindt is ook geen toestemming om inloggegevens te extraheren die aan iemand anders toebehoren.

De nuttige informatie voor de ondersteuning is het product, het veld, de fout en het geautoriseerde doel. Het geheim zelf maakt geen deel uit van die lijst.

Herstel is een geautoriseerde procedure, geen decoder

Als het product een omkeerbare export voor geautoriseerd herstel documenteert, gebruik dan de eigen import- of herstelprocedure binnen een beschermde omgeving. Bewaar het originele bestand, en houd gedecodeerd materiaal buiten logboeken, shellgeschiedenis en tickets. Als de waarde versleuteld is of aan een beschermde opslag is gebonden, komen de gedocumenteerde ontgrendelmethode en de vereiste autorisatie van de eigenaar, omdat decoderen noch een sleutel noch de toegangscontext van een andere gebruiker levert. Als het veld een verificator bevat, volg dan de gedocumenteerde vervangingsroute in plaats van decoders te proberen.

Wanneer de eigenaar de waarde niet kan herstellen of veilig opnieuw kan uitgeven, is het antwoord nieuwe inloggegevens en bijgewerkte peer-configuraties. Dat is een project met een overgang, geen opdracht.

Een gedeeld geheim vervangen is een gecoördineerde wijziging

Het overschrijven van een gedeeld productiegeheim aan slechts één kant breekt elke goedgekeurde client die de vorige waarde nog heeft. Plan de overgang, beslis of toegang moet worden ingetrokken, en houd een herstelpad beschikbaar voordat u een van de eindpunten wijzigt. Kondig het venster aan bij de mensen die het zullen merken.

Als de oorspronkelijke waarde is blootgelegd, is rotatie het juiste antwoord en voegt het decoderen ervan niets toe. Een blootgelegd geheim is gecompromitteerd, ongeacht of iemand de bytes heeft hersteld.

Noteer waar de nieuwe waarde leeft en wie de eigenaar is. Het volgende incident vraagt daarnaar, niet naar een decoder.