Koppelingen met bestaande systemen

Een leeskoppeling wordt in vier lagen begrensd: netwerk, identiteit, autorisatie in de bron en vastlegging. Het platform levert netwerk en identiteit; welke handelingen de toepassing mag, bepaalt het bestaande systeem met de rol die zijn eigenaar aan haar identiteit koppelt. De vastlegging begrenst niets, maar maakt de toegang achteraf controleerbaar.

Een koppeling heeft instemming van de eigenaar van de bron over identiteit, gegevens, doel en einddatum, en de eigenaar levert de gegevens voor de toegang. Zij gaat standaard naar een testexemplaar van het bestaande systeem en wordt jaarlijks door die eigenaar herbeoordeeld. Voor het lezen van productiegegevens bij ontwikkelen en beproeven ligt een besluit van de gegevenseigenaar vast, ook over de omgang met gekopieerde gegevens in logboeken en back-ups.

Omdat het platform niet zelf kan garanderen dat een toepassing alleen leest, wordt bij een leeskoppeling altijd getest dat de bron schrijven weigert. Ook toont de koppeling aan dat een niet-gedeclareerde verbinding, ook via een ander adres of een andere poort, in het cluster en het datacenternetwerk wordt geweigerd en gemeld.

Een koppeling wordt gedeclareerd in de dienstbeschrijving: bron, doel, poort, richting en gebruiksdoel, met de gegevensclassificatie, de eigenaar en het technisch contact van de bron en de versie van het koppelvlak. Daarna volgen de zonecontrole, de filterregel in het datacenter, de uitgaande regel in het cluster, de identiteit en de proef langs het gebruikerspad; draaiboeken in de automatisering richten het netwerkpad in.

Een koppeling van buiten naar een toepassing op het platform is een publicatie op de externe verkeersverdeling, geen gedeclareerde uitgaande verbinding.

Na de eerste leeskoppeling komen koppelingen per dienst via Applicatieverkeer en ketenkoppelingen, en in groeipadstap 4 API-beheer aan de applicatie-ingang: toegang en dosering per API, via een API-gateway achter de clusteringang en volgens het API-contract, voor teams die API’s aanbieden.

De identiteit van een koppeling wordt per koppeling bepaald, in een vaste volgorde: eerst een SPIFFE-identiteit als X.509-certificaat voor wederzijdse TLS, dan als JWT, en alleen als de bron geen van beide kan controleren een leesaccount als uitzondering. De terugval wordt vooraf gepland.

Kent de bron geen applicatie-identiteit, dan gebruikt de koppeling een leesaccount met een statisch geheim in OpenBao. Het geheim wordt iedere 30 dagen vervangen, met overlap als de bron twee geldige waarden tegelijk toestaat en anders binnen een gedateerde onderbrekingsuitzondering, en na een incident binnen 24 uur. Het is een beheerd langlevend geheim, als goedgekeurde uitzondering geregistreerd met eigenaar, reden en einddatum. Bij een database als bron levert de database-engine van het geheimenbeheer de inloggegevens.

Bij problemen met de applicatie-identiteit valt een koppeling tijdelijk terug op een leesaccount met centraal beheerd geheim en einddatum, als goedgekeurde uitzondering met instemming van de eigenaar van de bron. Een mislukte koppeling wordt volledig verwijderd; de gegevens van het bestaande systeem veranderen niet.

De eerste koppeling wordt met het eerste applicatieteam langs het werkelijke gebruikerspad beproefd, ook op wat er gebeurt als iets misgaat. Zij is gereed wanneer de testtoepassing een opdracht kan opslaan en de brongegevens kan lezen maar niet wijzigen, en de scenario’s zijn beproefd met vastgelegd resultaat.

Bevindingen van het eerste team komen op de verbeterplanning voordat volgende afnemers aansluiten. Een open bevinding met gevolgen voor beveiliging of beheer blokkeert het aansluiten tot zij is opgelost of de diensteigenaar het restrisico heeft geaccepteerd, medeondertekend door de CISO-functie.

De stromen van een koppeling worden gecontroleerd met de netwerkweergave van Advanced Cluster Security, en vanaf groeipadstap 2 met het netwerkinzicht van de eigen bewakingsvoorziening. Afwijkingen worden gemeld, en werkelijke en gedeclareerde stromen komen in het maandelijkse verslag.