De herstelomgeving

De herstelomgeving krijgt een NodePool van drie werkers van maat L, in verschillende rekken, uit de reserve van de werkervirtualisatie. Samen met een teruggezet cluster en de twee herstelservers gebruikt zij ten hoogste de capaciteit van één werkerknooppunt van de werkervirtualisatie. Er is één herstelomgeving tegelijk per cel.

Back-ups, buckets en sleutels zijn per cel; de andere cel levert alleen capaciteit. Die reserve draagt ook onderhoud, uitval en de overname van bedrijfskritische diensten. Een herstelproef valt daarom nooit samen met een incident, een overname of onderhoud op die reserve, en bij een incident gaat herstel voor onderhoud.

De herstelomgeving staat binnen 90 minuten klaar, inclusief het ophalen van de kopie uit de back-upvoorziening, behalve bij een kopie uit FortKnox.

De herstelomgeving heeft eigen aanmelding, geheimen en sleutels, zonder productiegeheim: een eigen realm voor herstel in Keycloak met alleen herstelrollen, of de noodaanmelding uit de kluis als de toegangsvoorziening zelf is aangetast, en een eigen naamruimte herstel-<cel> in OpenBao met nieuwe waarden. Na afloop wordt zij met al haar onderdelen verwijderd: volumes, momentopnamen, geheimen, realm, herstelservers en herstelbucket, en komt de reserve weer vrij.

De controle op besmetting vergelijkt de controlesom van de kopie met de registratie van Cohesity, scant containerbeelden met Clair en scant bestanden, volumes, virtuele schijven en databasebestanden met de eindpuntbeveiliging van RWS op twee herstelservers: Tanium op Linux en Windows Defender op Windows. De indicatoren komen van het SOC, en het verslag gaat via de beheerwerkplek naar het SOC.

De controle toetst de integriteit en sluit bekende aantasting uit, onbekende niet. Dat restrisico is aanvaard en wordt begrensd door een kopie van vóór het tijdstip van aantasting, software uit de vrijgave en nieuwe sleutels.

Containerbeelden komen bij herstel op inhoudskenmerk uit de containerregistry, zijn door Clair gescand en starten alleen na controle van de handtekening; een niet-ondertekend beeld start in de herstelomgeving niet.

Er zijn twee herstelpaden. Voor een toepassing en haar gegevens worden objecten, volumes en databases teruggezet in de herstelomgeving zelf. Voor een heel applicatiecluster wordt ook de gehoste besturing uit de etcd-momentopname opgebouwd, met werkers in de herstelzone, maar pas na uitsluiting van het origineel, omdat dat herstel dezelfde naam vraagt.

Herstel van een gehoste besturing, een platformcluster of het vlootbeheer begint pas na uitsluiting van het oorspronkelijke exemplaar.

Na een geslaagde controle wordt productie hersteld uit dezelfde kopie, herkend aan haar controlesom; een cluster verhuist niet van de herstelzone naar productie. Volumes komen pas bij de terugkeer naar productie weer op het opslagcluster.

Terugzetten uit Cohesity gaat via een herstelbucket. Back-upbeheer zet op verzoek van platformbeheer een kopie van vóór het gekozen tijdstip terug in een herstelbucket op Cohesity, en de herstelomgeving, voor een etcd-momentopname het clusterbeheer, leest die met een eigen leesidentiteit. Zo is er geen schrijfpad van de herstelomgeving naar de kopieën.

Een dienst wordt in vijf stappen uit een kopie hersteld, op verzoek van de diensteigenaar of het SOC.

De herstelzone, VLAN 690 in vrf-herstel, bestaat ook zonder opgebouwde omgeving en heeft geen route van of naar productie; alleen de vaste stromen voor back-up en herstel zijn toegestaan. Vanuit productie, de afnemerszones en vrf-platform is de herstelzone niet bereikbaar, en iedere andere stroom weigert en logt de firewall.

Ieder cluster in de herstelzone, ook een daar teruggezet applicatiecluster, krijgt zijn volumes alleen via de gastklasse van de werkervirtualisatie (RBD, storageDriver Manual), geen opslagclientnetwerk en een statisch adres; er is geen DHCP-doorgifte. Een definitie met een opslagclientnetwerk of DHCP in de herstelzone wordt geweigerd.

Werkers en herstelservers krijgen een statisch adres uit de herstelreeks, gereserveerd in Infoblox, geregistreerd in NetBox en vastgelegd in hun definitie als code. Besturingen in de herstelzone krijgen een API-adres uit een eigen deelreeks en een eigen ingangsadres op het clusterbeheer; het API-adres van de herstelomgeving heeft een vaste naam onder het domein van de cel.

Back-up en herstel gebruiken deze verbindingen.