Kopieën in de cel beschermen tegen fouten en tegen uitval van onderdelen; de onveranderbare kopie op de back-upvoorziening van RWS, buiten de cel en buiten de beheerrechten van het platform, beschermt de productie. De cel heeft geen rechten op haar eigen bescherming, en voor alle back-ups geldt één bewaarregel.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Herstel steunt op lagen van kopieën. In de cel staan momentopnamen en back-ups voor snel herstel na een fout of na
uitval van een onderdeel. Buiten de cel staat de onveranderbare kopie op de bestaande back-upvoorziening van RWS, die
de productie beschermt, en in de afgezonderde bewaarplaats FortKnox de herstelkern. Cohesity haalt de back-ups zelf op;
de cel kan haar eigen bescherming niet wijzigen of wissen.
Waarom zo
Een fout of een aanvaller met platformrechten kan alles bereiken wat binnen de cel ligt, ook een vergrendelde kopie op
het eigen opslagcluster. Alleen een kopie buiten de cel en buiten de beheerrechten van het platform blijft dan bruikbaar.
Door Cohesity te laten ophalen, krijgt de cel geen schrijf- of wisrechten op de plek die haar moet beschermen.
De bewaartermijnen, het ophaalritme en de indeling van FortKnox zijn een voorstel. Ze volgen het back-upbeleid van RWS
en houden het herstelpunt na verlies van de cel klein.
De productiebescherming is een onveranderbare kopie van alle back-ups op de bestaande back-upvoorziening van RWS: Cohesity, met DataLock voor de vergrendeling en FortKnox als afgezonderde bewaarplaats buiten de datacenters. Die omgeving wordt daarvoor uitgebreid; er komt geen eigen hardware. De kopie staat buiten de cel en buiten de normale beheerrechten van het platform.
Toelichting
Herstel na een aanval stelt andere eisen dan herstel na een storing: de aanvaller kan ook beheerrechten, back-ups en sleutels hebben aangetast. Afgewezen alternatief: een vergrendelde bucket op het opslagcluster van de cel. Die beschermt niet tegen opslagbeheerrechten en verdwijnt met de cel.
OpenShift API for Data Protection maakt de back-up van clusterobjecten, volumes en virtuele machines naar de objectopslag van het opslagcluster van de cel. Die back-ups delen het foutdomein en de beheerrechten van de cel; de bescherming van productie komt van de onveranderbare kopie.
Momentopnamen en back-ups in de cel, de onveranderbare kopie en de afgezonderde bewaarplaats zijn verschillende lagen, elk tegen een andere verstoring.
Laag
Wat
Beschermt tegen
Momentopname in de cel
Een CSI-momentopname van ieder volume op het opslagcluster
Een fout, met snel herstel; niet tegen verlies van de cel
Back-up in de cel
Alle back-ups in de realm platform van de objectopslag, in een bucket per cluster of dienst
Uitval van onderdelen; deelt foutdomein en opslagbeheerrechten met de cel
Onveranderbare kopie
Cohesity haalt iedere back-up op en vergrendelt haar met DataLock
Verlies van de cel en aantasting met platform-, opslag- of back-upbeheerrechten
Afgezonderde bewaarplaats
FortKnox, buiten de datacenters, voor de herstelkern en de toegelaten gegevens van bedrijfskritische diensten
Herstel buiten de getroffen vertrouwensgrens
Vergrendelde kopie in de cel
Een bucket met Object Lock in een eigen tenant, alleen voor ontwikkelen en beproeven
Voor ontwikkelen en beproeven is er naast de onveranderbare kopie een vergrendelde kopie in de cel: een bucket met Object Lock in COMPLIANCE-modus voor 35 dagen, in een eigen tenant van de objectgateway met eigen beheeraccounts. Een kopieertaak op het basisdienstencluster vult haar, omdat Velero niet naar een vergrendelde bestemming kan schrijven. Een kopie op het opslagcluster van de cel, ook deze vergrendelde, telt niet als bescherming van reguliere of bedrijfskritische productie.
Toelichting
Zij deelt het foutdomein en de opslagbeheerrechten van de cel. Het vrijgavedossier voor reguliere productie bevat daarom een herstel uit de onveranderbare kopie. Object Lock kan alleen bij het aanmaken van een bucket worden aangezet, rechtstreeks op de objectgateway.
Cohesity haalt de back-ups zelf op uit de objectopslag van de cel, met een identiteit die daar alleen mag lezen. Lukt dat niet, dan schrijft een kopieertaak met alleen toevoegrechten naar een doel op Cohesity met DataLock. De cel heeft zo geen rechten op haar eigen bescherming.
Toelichting
Afgewezen: back-ups vanuit de cel naar Cohesity duwen. Dan krijgt de cel schrijf- en wisrechten op de plek die haar moet beschermen. Ophalen is een voorwaarde bij de acceptatie van de herstelvoorziening; de toegepaste vorm staat in de opslagplaats Draaiboeken.
Geen platform- of opslagaccount heeft rechten op het beschermingsbeleid, de bewaartermijnen of de kopieën op Cohesity. De cel leest alleen, behalve de kopieertaak, die alleen mag toevoegen aan een doel met DataLock. Back-upbeheer beheert Cohesity met eigen accounts buiten het platform.
Toelichting
Productiebeheer kan de beschermingsregels en de onafhankelijke kopieën dus niet wijzigen of verwijderen, en DataLock verhindert wissen en verkorten ook voor de beheerders van de back-upvoorziening. Gecontroleerd met wis-, wijzig-, verkort- en schrijfpogingen die mislukken.
Cohesity haalt ieder uur op, binnen de vergrendeling van de dagelijkse kopie, zodat transactielogboeken en momentopnamen de cel binnen het uur verlaten. Het herstelpunt na verlies van de cel ligt dan circa 1 uur terug.
Toelichting
Afgewezen: alleen dagelijks ophalen. Dan loopt het herstelpunt na verlies van de cel tot 24 uur achter. Dagelijks ophalen blijft wel de terugvaloptie als Cohesity het uurritme niet haalt.
Iedere ophaalrun levert een kopieerverslag met controlesommen en een vergrendelde kopie. Een afwijking gaat naar platformbeheer; een afwijkende controlesom en een verdwenen of gewijzigde back-up gaan naar het SOC.
Toelichting
Het draaiboek voor onveranderbaar bewaren is van back-upbeheer, met platformbeheer: ophaalrun, controlesommen, vergrendeling, FortKnox en kopieerverslag.
Het back-upschema vult het back-upbeleid van RWS in met drie kopieën op twee media, waarvan één buiten de cel: de productiegegevens op het opslagcluster, en de kopie en de onveranderbare kopie in de back-upvoorziening. Wat verder in de cel ligt, telt daarin niet mee. De dagelijkse kopie vervult de dagelijkse differentiële kopie uit het beleid, en de malwarecontrole bij herstel is de scan in de herstelomgeving vóór het terugzetten.
Toelichting
Kopieën, media, locaties en hersteltoewijzing per gegevensverzameling staan in het back-upschema en in de dienstbeschrijving.
Iedere back-up valt onder de bewaarregel; een dienst kan alleen langer bewaren, met een eigen beschermingsbeleid op Cohesity. Een afwijking van schema of bewaarregel is een uitzondering met eigenaar, compenserende maatregel en een einddatum van ten hoogste zes maanden.
Toelichting
Gecontroleerd door het beschermingsbeleid en de schema’s uit te lezen en met het uitzonderingsregister.
Bij beëindiging van een dienst wordt een laatste back-up gemaakt met gestopte schrijvers; die blijft de bewaartermijn van gegevens en back-ups uit de dienstbeschrijving bewaard. Na de verwijdering wordt de sleutel vernietigd.
Toelichting
Een langere termijn is een eigen beschermingsbeleid op Cohesity. Het draaiboek is van platformbeheer met back-upbeheer en wordt beproefd in de acceptatieproef voor beëindiging.
FortKnox is een dienst van een externe aanbieder. Daarheen gaan alleen de herstelkern en de gegevens van bedrijfskritische diensten die volgens hun dienstbeschrijving buiten eigen beheer mogen, versleuteld met sleutels die RWS zelf aanmaakt en beheert en die ook zonder de cel beschikbaar zijn. Wat buiten eigen beheer niet voldoende te beschermen is, blijft op het eigen platform; de overige gegevens van bedrijfskritische diensten staan alleen op Cohesity.
Toelichting
Ieder kwartaal worden de gegevens in FortKnox vergeleken met de dienstbeschrijvingen. Per bedrijfskritische dienst worden de toestemming voor opslag buiten eigen beheer en het gemeten herstelbewijs vastgelegd.