Cloud-HSM met heldere sleutelcontrole.

Private koppeling, naamresolutie, authenticatie en latentie beïnvloeden elke cryptografische aanroep. Wij testen de route met het werkelijke belastingsprofiel en plannen het gedrag bij een onderbroken verbinding. Een tweede eindpunt helpt alleen als de sleutels en autorisaties daar op passende wijze beschikbaar zijn. Externe sleuteldiensten en door de klant beheerde sleutels verschillen bovendien in de vraag welke gegevens en diensten zij daadwerkelijk onder controle hebben. Wij leggen deze grenzen zo vast dat functioneel verantwoordelijken de resterende invloed van de aanbieder begrijpen.

Een exitconcept beschrijft welke sleutels geëxporteerd kunnen worden, welke gegevens opnieuw versleuteld zouden moeten worden en welke diensten vervangen moeten worden. Termijnen, verwijderbevestigingen en afhankelijkheden van back-ups horen daarbij. In het project spreken wij haalbare beheerdoelen af en toetsen wij de herstart en het intrekken van rechten. Een algemene toezegging van volledige overdraagbaarheid zou zonder deze toetsing niet houdbaar zijn.

AWS CloudHSM en Azure Key Vault Managed HSM staan voor verschillende integratie- en beheermodellen. AWS CloudHSM biedt HSM-clientkoppelingen voor daarvoor geschikte applicaties; Azure Managed HSM biedt een beheerde sleuteldienst met Azure-integratie. Wij toetsen API, sleuteltypen, identiteiten en herstelmodel per workload. Een overstap is daarom niet zomaar het vervangen van een serveradres. Doorslaggevend is of de concrete applicatie en de vereiste mate van controle bij de dienst passen.

Bring Your Own Key betekent in eerste instantie het inbrengen van eigen sleutelmateriaal in een ondersteunde dienst. Het beantwoordt op zichzelf niet wie sleutelbewerkingen kan starten of waar gegevens in leesbare vorm worden verwerkt. Bij extern sleutelbeheer komen er extra technische afhankelijkheden bij, bijvoorbeeld een externe dienst voor bepaalde vrijgave- of uitpakbewerkingen. Wij leggen deze vertrouwensgrenzen vast en toetsen ook het gericht intrekken van rechten. Functies en beperkingen worden voor de concrete clouddienst getoetst.

Een bestaande applicatie moet verhuizen, maar het beheer van de sleutels moet controleerbaar blijven. OTOKO® onderzoekt eerst of de bestaande interface hergebruikt kan worden of dat een aanpassing nodig is. In de pilot meten wij responstijden vanuit het doelnetwerk, toetsen wij gescheiden beheerdersrollen en testen wij het herstel. Het exitconcept beschrijft zowel exporteerbare sleutels als gevallen waarin het genereren van nieuwe sleutels en een omzetting van gegevens nodig zouden zijn. Daaruit ontstaat een beheermodel met benoemde verantwoordelijkheden.