De externe verkeersverdeling

Per cel is er één gemeenschappelijk HA-paar, en een eigen paar voor iedere afnemer die eigen regels of gescheiden beheer nodig heeft en dat via zijn dienstbeschrijving afneemt. Ieder paar heeft twee leden, een eigen HA-groep, een eigen beheeraccount en eigen virtuele adressen in de ingangszone; een eigen paar is een eigen grens binnen de ingangszone.

NetScaler BLX 14.1, build 73.32 of later, draait als pakket op virtuele machines met RHEL 9 op OpenShift Virtualization, met lokale schijven uit LVM Storage. Iedere virtuele machine heeft ten minste 2 vCPU, 4 GB geheugen en 20 GB schijf en is gehard volgens de basislijn van de beheerservers, voor zover die op RHEL 9 van toepassing is.

De leden van een paar staan op verschillende knooppunten van het basisdienstencluster, en daarmee in verschillende rekken. Een eigen paar komt er alleen na een capaciteitstoets van het basisdienstencluster. Door hun lokale schijven werkt de ingang door terwijl het opslagcluster wordt hersteld, maar verhuist een lid niet live.

Een lid is via de virtualisatie aangesloten, niet via het podnetwerk, en heeft alleen aansluitingen in VLAN 600 en 640: het beheeradres in VLAN 600, de virtuele adressen en het adres naar achteren in VLAN 640 (MTU 1500), alleen op de bundels van het basisdienstencluster. Het heeft geen aansluiting in een afnemersnetwerk; de overgang naar afnemers loopt alleen via de firewall.

De paren worden beheerd over het apparatuurbeheernetwerk, alleen vanaf de beheerwerkplek en het uitvoeringsknooppunt van de automatisering, via TCP 443 voor de NITRO-API en TCP 22, met een toegangslijst op het paar. Het beheeradres is van nergens anders bereikbaar, en beheerinterfaces worden nooit gepubliceerd.

Beheerders melden zich op een lid aan met een persoonlijk account via de AAA-voorziening van netwerkbeheer tegen de directory, met tweede factor en sessieopname via de beheerwerkplek, zoals bij de switches. Persoonlijke accounts lezen; wijzigen gaat via het draaiboek, en bij een incident via de noodroute met de lokale beheerder uit de kluis. Standaardwachtwoorden zijn vóór ingebruikname vervangen.

Per paar is er één beheeraccount voor de NITRO-API in het geheimenbeheer, dat per uitvoering wordt opgehaald. De draaiboeken draaien met de collectie netscaler.adc op het uitvoeringsknooppunt in VLAN 600, in productie na goedkeuring door een ander dan de aanvrager. Een afnemer met een eigen paar krijgt geen beheertoegang: eigen regels legt hij vast in zijn dienstbeschrijving, en het platform voert ze uit.

De inrichting van een paar komt alleen uit versiebeheer, met een configuratieback-up na iedere wijziging en een dagelijkse melding van verschillen. Een paar is uit code, beeld en geheimenbeheer opnieuw op te bouwen.

De ingang gebruikt open standaarden; de productspecifieke inrichting van BLX staat met haar reden als code in versiebeheer.

Paren en firewalls draaien alleen door de leverancier bevestigde versies; BLX nooit onder build 14.1-73.32 en altijd uit een vrijgegeven beeld. Leden worden vervangen, niet bijgewerkt: eerst het secundaire lid, dan overschakelen, dan het tweede lid, met een vergelijking van de inrichting met versiebeheer. Een nieuwe build gaat naar de leeromgeving, dan naar het gemeenschappelijke paar van cel 1, dat ook de proefgroep publiceert, en na 5 werkdagen zonder storing naar de eigen paren en de paren van cel 2, zoals golf 1 en golf 2. Een teruggang gaat naar de vorige vastgelegde build, nooit onder 14.1-73.32.

Een kritieke kwetsbaarheid in de verkeersverdeling is binnen 7 dagen opgelost, vóór gepland werk; een actief misbruikte binnen 72 uur, met een tijdelijke maatregel binnen 24 uur, zoals een functie uitzetten of een filterregel. Bij een kwetsbaarheid of aanval via de ingang wordt de getroffen publicatie geïsoleerd, via de spoedroute en samen met het SOC.

Vóór de ingang in gebruik gaat, zijn de opstelling van BLX als HA-paar op virtuele machines met RHEL 9 op OpenShift Virtualization en de licentie per exemplaar bevestigd; anders wordt NetScaler VPX gebruikt, met dezelfde inrichting. Op het gemeenschappelijke paar worden de audit als syslog over TLS naar de SIEM en de grenzen voor verbindingen per virtuele server aangetoond, ieder met een terugvaloptie: RHEL 9 op het lid stuurt het auditlogboek over TLS door, en de grenzen gelden per servicegroep.

Het verkeer door de ingang hangt af van de fabric, het firewallcluster, het basisdienstencluster en de naamvoorziening van RWS, niet van het vlootbeheer, het opslagcluster of de andere cel. Na uitval van een cel komt de publicatie per cluster terug zodra het cluster weer draait.

De hersteldoelen van de ingang zijn normen: een lid binnen 1 werkdag, een heel paar binnen 4 uur. Overschakeling binnen een paar gebeurt zonder merkbare onderbreking. Het paar repliceert zijn inrichting zelf en is uit beeld, code en geheimenbeheer op te bouwen.

Het rek is het foutdomein. Per onderdeel liggen de plaatsing, het gedrag bij uitval en het herstel vast.

Als reserve staat in ieder paar één lid stand-by, houdt het basisdienstencluster de middelen van één knooppunt vrij en blijft 30 procent van de adressen in het ingangssegment vrij.

De omvang van ingang en koppelingen per cel bij de eerste levering in cel 1, en de beoogde groei.

De capaciteitsdrempels van ingang en koppelingen zijn normen: bij iedere grens volgt een actie vóór de harde grens.

Tot groeipadstap 2 bewaakt de bestaande apparatuurbewaking (Zabbix) de leden via SNMP versie 3, daarna de snmp_exporter in de eigen bewakingsvoorziening. Tot dan bereikt die bestaande bewaking de beheeradressen van de leden vanuit het externe domein, begrensd tot SNMP versie 3, alleen lezen, vanaf vastgelegde bronadressen; dat is een aanvaard restrisico. De servicegroep, het doel achter een virtuele server, toont of een gepubliceerd cluster bereikbaar is.

De meetwaarden, drempels en acties van ingang en zonering.

De audit van paren en firewalls, alle weigeringen en per verbinding het clientadres, het virtuele adres en het doel gaan versleuteld, als syslog over TLS, naar de SIEM van het SOC; daaruit haalt het SOC het bronadres. Het SOC bevestigt de ontvangst en bewaart een kopie buiten het bereik van platformbeheer. Een logbron die langer dan 15 minuten stil is, wordt gemeld.

Voor ingang, zonering en koppelingen zijn vaste draaiboeken vereist, in de opslagplaats Draaiboeken en uitgevoerd in Ansible Automation Platform. Ieder draaiboek is vóór ingebruikname beproefd en daarna volgens het vaste beproevingsritme, en iedere eigenschap uit de bewijsset heeft ook een negatieve proef. Vóór de overdracht voeren de primaire en plaatsvervangende beheerders ze zelf uit.

Bij de acceptatie van de ingang en van de eerste koppeling wordt het volgende aangetoond; cel 2 herhaalt de proeven die van haar eigen netwerk en paren afhangen.