Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De beheerwerkplek is het enige pad voor bevoorrechte sessies: een toegangsgateway die iedere sessie opneemt, met geharde beheerservers. Platformbeheer gebruikt de beheeringang en de platformpool in het beheernetwerk, teams met een verhoging de teamingang en de teampool. Dit onderwerp legt de ingangen en pools vast, de filterregels, de aanmelding in de sessie en de opname.
Een bevoorrechte handeling moet herleidbaar zijn tot een persoon, een goedkeuring en een opname, ook tegenover de beheerder zelf. Daarom start geen sessie zonder opname en zijn de beheerinterfaces alleen vanaf de pools bereikbaar. Teams krijgen een eigen ingang en pool, zodat hun sessies niet in het netwerk van iLO, switches en fabriccontroller komen.
Beheertoegang loopt alleen via de beheerwerkplek. Iedere bevoorrechte sessie, ook via opdrachtregel, API, exec en poortdoorschakeling, gaat via de beheerwerkplek en wordt opgenomen. Beheerinterfaces van platformdiensten en apparatuur zijn alleen via het beheernetwerk bereikbaar.
Voor het gewone werk bereiken teams hun eigen naamruimten via de gepubliceerde API, met meerfactoraanmelding.
De beheerwerkplek bestaat uit een toegangsgateway, Apache Guacamole, die iedere sessie opneemt, en geharde beheerservers met de beheerhulpmiddelen, als virtuele machines op het basisdienstencluster van de cel.
Filterregels laten de API en console van platformclusters, iLO, het beheeradres van NetScaler, cephadm en de dashboards alleen toe vanuit het subnet van de beheerwerkplek. Het beheeradres van NetScaler is ook bereikbaar vanaf het uitvoeringsknooppunt van de automatisering in VLAN 600, en voor de bewaking zijn iLO en dat beheeradres bereikbaar met SNMP versie 3 en Redfish. Verkeer tussen platformclusters komt alleen uit de vastgelegde platformnetwerken. De beheerconsole van Keycloak is alleen bereikbaar via een eigen hostnaam en vanaf de beheerwerkplek.
De bewaking van apparatuur is tot groeipadstap 2 de bestaande apparatuurbewaking, daarna de eigen bewakingsvoorziening. Controle: een maandelijkse geautomatiseerde scan vanuit een testmachine in een kantoornetwerk en in een applicatienetwerk.
Platformrollen werken via de beheeringang, vanaf een gehard beheerapparaat; teams via de teamingang. De API’s en consoles van platformclusters zijn alleen bereikbaar vanaf de adressen van de platformpool, niet vanaf de beheerapparaten, zodat geen beheersessie de opname omzeilt.
Reden: één bewaakt beheerpad. Controle: een maandelijkse netwerkscan; het SOC meldt een beheeraanmelding van buiten de beheerwerkplek.
De beheerwerkplek heeft twee ingangen, elk met een eigen client en eigen exemplaren: de beheeringang met de platformpool in VLAN 600, en de teamingang met de teampool op het podnetwerk van het basisdienstencluster. De guacd van de beheeringang bereikt de platformpool via de firewall. Zo blijven teams buiten het apparatuurbeheernetwerk, en overbrugt geen container twee routeringsdomeinen.
Afgewezen alternatieven: teams op een beheerapparaat in het apparatuurbeheernetwerk, want dan komen teamsessies in het netwerk van iLO, switches en fabriccontroller; en een interface van guacd in VLAN 600, want dan overbrugt die container twee routeringsdomeinen buiten de firewall.
Wie welke ingang en pool gebruikt, en waar ze staan.
| Onderdeel | Voor wie | Plaats | Bijzonderheden |
|---|---|---|---|
| Beheeringang | Platformrollen, vanaf een gehard beheerapparaat | VLAN 600 | Alleen verbindingen naar de platformpool |
| Platformpool | Platformrollen | Beheerservers als virtuele machines in VLAN 600 | API’s en consoles van platformclusters zijn alleen vanaf deze adressen bereikbaar |
| Teamingang | Teamleden, vanaf de RWS-werkplek | Eigen doeladres achter het gemeenschappelijke paar van de externe verkeersverdeling; de ingang sluit TLS zelf af | Eigen client; alleen leden van een actieve verhoogde teamgroep bereiken de teampool, en bij het vervallen verbreekt de gateway de verbinding |
| Teampool | Teamleden met een verhoging | Beheerservers als virtuele machines op het podnetwerk van het basisdienstencluster | Netwerkbeleid; eigen bronadres voor de audit van de clusters |
De groep <cel>-<team>-verhoogd komt alleen mee via de aanmeldroute van de teampool. De teampool bereikt alleen de API’s van applicatieclusters, de toegangsvoorziening, de naamdienst en de SIEM, en nooit het apparatuurbeheernetwerk.
Aanvaard restrisico: met een goedgekeurde verhoging werkt de aanmeldroute van de teampool ook vanaf kantoor, buiten de opname. De tweede factor, de maximale duur van 4 uur en een melding door het SOC binnen 1 uur begrenzen dat. Een strenger alternatief, een aparte aanmeldstroom in Keycloak met een clientcertificaat van de teampoolservers, viel af om de beheerlast; het blijft een mogelijke latere verscherping via een wijzigingsvoorstel. Controle: een netwerkscan vanuit de teampool en vanaf kantoor.
De beheerder meldt zich in de opgenomen sessie op de beheerserver zelf aan bij de toegangsvoorziening, met persoonlijk account en tweede factor. Het toegangsbewijs blijft op de beheerserver en vervalt bij het sluiten van de sessie. Een bewijs uit de browser van de eigen werkplek zou elders bruikbaar zijn.
Voorwaarde bij de acceptatie: de WebAuthn-sleutel van het beheerapparaat werkt in de sessie. Geeft Guacamole de sleutel niet door, dan meldt de beheerder zich in de sessie aan met de authenticatorapp, en opent de gateway de sessie met de factor van de rol. Die aanmelding is dan niet phishingbestendig: een aanvaard restrisico, begrensd door WebAuthn bij de opening en door de opname.
Iedere bevoorrechte sessie wordt direct naar vergrendelde opslag opgenomen: guacd schrijft de opname tijdens de sessie in een bucket met Object Lock in de objectopslag van de cel, en start geen sessie als dat niet kan. Opnames blijven 1 jaar bewaard. De verbinding tussen de webtoepassing en guacd is versleuteld, en alle API-handelingen staan ook in de audit van de clusterbesturing.
Reden: herleidbaar, ook tegenover beheerders. Dit is een voorwaarde bij de acceptatie. Terugvaloptie: guacd schrijft op een volume alleen voor guacd, een taak zet iedere opname binnen 1 minuut in de bucket, en de automatisering sluit de ingangen als bucket of volume onbereikbaar is; de opname ligt dan tot 1 minuut op een volume, een aanvaard restrisico dat de audit bij het SOC begrenst. Afgewezen alternatief: de opname lokaal bufferen, want een buffer ligt binnen bereik van de beheerder. Controle: een wekelijkse vergelijking van toekenningen met opnames, een steekproef van opnames tegen de audit van de clusters, en een negatieve proef.
Is de opnamebestemming onbereikbaar, dan sluiten de ingangen, eindigen de lopende sessies en start geen bevoorrechte sessie via de gateway; na herstel volgt eerst een testsessie met opname. Valt het opslagcluster uit, dan loopt het beheer van het opslagcluster via de noodwerkplek.
Platformbeheer krijgt direct een melding. Vanaf groeipadstap 2 gaan de opnames naar de vergrendelde opslag van de eigen bewakingsvoorziening. Het opslagcluster versleutelt de opnames in rust.
Tot de beheerwerkplek op het basisdienstencluster werkt, werken beheerders met persoonlijke accounts op de gateway van de voorlopige beheerwerkplek, met TOTP, geharde beheerapparaten en opname. Dat is een goedgekeurde uitzondering op phishingbestendige meerfactoraanmelding, met als einddatum de acceptatie van het basisdienstencluster, in het uitzonderingsregister.
Zo is er meerfactoraanmelding vanaf de eerste installatie. Aanvaard restrisico: TOTP is niet phishingbestendig; geharde beheerapparaten, de opname en de einddatum begrenzen dat. De voorlopige beheerwerkplek gaat uit nadat de noodwerkplek is beproefd.