Sleutels beheren. Toegang begrenzen.

Een nieuwe sleutel betekent niet dat de oude direct kan worden verwijderd. Wij brengen in kaart welke data, handtekeningen of back-ups nog afhankelijk zijn van eerdere versies. Applicaties hebben een eenduidige koppeling aan de sleutelversie nodig. Genereren, activeren, intrekken, archiveren en verwijderen krijgen gescheiden statussen en goedkeuringen. Fouten zoals uitgeputte sessies, verlopen aanmeldingen of onderbroken verbindingen worden zichtbaar afgehandeld. Herhalingen mogen geen ongewenste sleutelduplicaten of inhoudelijk dubbele transacties veroorzaken.

In de test toetsen we naast geslaagde aanroepen ook afgewezen rollen en niet-toegestane bewerkingen. Toegangsmiddelen en geheimen mogen niet in broncode, logs of algemene back-ups terechtkomen. Uw team ontvangt configuratie, voorbeeldscenario's en een procedure voor diagnose. Belangrijk voor de start zijn de gebruikte bibliotheken, runtime-omgevingen en bestaande sleutels.

PKCS #11 beschrijft de toegang tot cryptografische tokens en hun functies. KMIP richt zich op het beheer van cryptografische objecten tussen client en sleutelbeheersysteem. Een clouddienst kan op zijn beurt een eigen REST-API aanbieden. Daaruit volgt geen automatische uitwisselbaarheid. OTOKO® documenteert waar een bewerking wordt uitgevoerd, welk sleutelmateriaal een interface daadwerkelijk overdraagt en welke attributen behouden blijven. Zo wordt een protocollijst een helder integratietraject.

Bij hiërarchische versleuteling kunnen datasleutels de eigenlijke gegevens beschermen, terwijl een bovenliggende sleutel deze datasleutels beschermt. Zo hoeft niet elk groot gegevensblok door een HSM te worden verwerkt. Doorslaggevend is waar een datasleutel in leesbare vorm nodig is en hoe lang hij daar beschikbaar blijft. Wij bepalen cachegedrag, rotatie en toegang in de applicatie. De uitspraak “De sleutel blijft in de HSM” is alleen houdbaar voor de concreet beschouwde sleutelrol en de bijbehorende attributen.

Meerdere diensten gebruiken tot nu toe eigen sleutelbestanden. OTOKO® brengt eerst eigenaren, doelen en gegevensafhankelijkheden in kaart. Vervolgens testen wij de ondersteunde integratie van een representatieve dienst en definiëren wij autorisaties per applicatie. De omschakeling verloopt stapsgewijs, met gecontroleerd lezen van bestaande gegevens en schrijven van nieuwe gegevens. Oude sleutels worden pas verwijderd wanneer bewaring, back-ups en herstel zijn meegenomen. Het resultaat is een gedocumenteerde sleutelinventaris met geteste procedures voor gebruik en sleutelwissel.