Back-ups van een evenementenwebsite beveiligen: toegangs- en herstelchecklist

Download het controleblad

Download het controleblad

Het werkblad scheidt bronsysteem, locatie, eigenaar, toegangsrollen, verwijderbeveiliging, versleuteling en sleutelbeheer, bewaartermijn, laatste herstelbewijs en open actie. Gebruik een regel per echte kopie, ook voor downloads van medewerkers. Noteer accountverwijzingen, geen wachtwoorden, herstelcodes, sleutels of deelnemersrecords.

Een vinkje bewijst geen actieve leveranciersinstelling. Vraag de bevoegde persoon de huidige configuratie of gedateerd bewijs te tonen en wijs elke afwijking toe.

Breng elke kopie en haar gegevens in kaart

Noem site, registratiedatabase, foto's en documenten, gepubliceerde media, configuratie en DNS. Leg vast wat in de hostingback-up zit en wat bij een aparte ticket-, betaal-, e-mail- of bestandsdienst staat. Een herstelde homepage bewijst niet dat bestellingen terugkomen.

Elke geëxporteerde deelnemerslijst is een aparte kopie met eigen locatie en verwijderverantwoordelijke. Toegang tot het live dashboard is niet hetzelfde als toegang tot de back-up. Beschrijf die grens.

Beperk toegang en verwijderrechten

Leg vast wie kopieën kan maken, lezen, herstellen, de bewaartermijn wijzigen en verwijderen. Geef redacteuren alleen de benodigde rechten en beoordeel gedeelde of voormalige leveranciersaccounts na rolwijzigingen. Controleer de aanmelding van de back-upconsole en de herstelroute bij verlies van een apparaat.

Scheid waar mogelijk verwijder- en omzeilrechten van dagelijks redactiewerk. Verifieer echte rechten in het leveranciersaccount. CISA raadt beschermde, gescheiden kopieën aan omdat toegankelijke back-ups met productie kunnen worden aangevallen.[1]

Bescherm opslag én de herstelroute

Controleer versleuteling tijdens opslag en transport en wie sleutels in een incident kan terugvinden. Zet geen sleutel in dit werkblad en vertrouw niet op één laptop. Kijk of ten minste één kopie gescheiden is van normale verwijderrechten in productie.

Controleer bij een retentievergrendeling de modus en reikwijdte. Volgens AWS beschermt S3 Object Lock specifieke objectversies; een verwijdermarkering kan toch de actuele versie worden en gebruikers met speciale rechten kunnen governance omzeilen. Een vergrendeling bewijst geen volledige of leesbare back-up.[2]

Bepaal bewaartermijn en bewaak fouten

Kies de herstelgeschiedenis op basis van wijzigingen, incidenten en goedgekeurde bewaarplichten. Langere bewaring houdt oudere herstelpunten vast maar ook persoonsgegevens. Laat privacy- en financiële verantwoordelijken dit afwegen. Benoem wie verwijdering goedkeurt en hoe kopieën van vertrekkende leveranciers verdwijnen.

Controleer de inhoud van de back-uptaak en wijs iemand aan die mislukkingen ziet. Er is geen universele frequentie: kijk naar het toelaatbare gegevensverlies en het echte leveranciersgedrag. De laatste geslaagde kopie en laatste hersteltest zijn verschillende datums.

Bewijs herstel in een veilige omgeving

Herstel volgens goedgekeurde procedure in een geïsoleerde omgeving. Controleer pagina's, afbeeldingen, formulieren en configuratie; voorkom dat testmails of betalingen echte bezoekers raken. Controleer apart wat een externe ticket- of betaaldienst kan herstellen.

Noteer herstelpunt, tijden, ontbrekende onderdelen, toegangsproblemen en eigenaar en datum voor een nieuwe test. CISA adviseert beschikbaarheid en integriteit van kopieën te testen. Een gemeten herstel geeft meer zekerheid dan een groen taaklampje.[1]