Il backup che deve esserci quando serve.
ISO 27001:2022 A.8.13 (backup delle informazioni) è il controllo per il recupero: la capacità di ripristinare informazioni, software e sistemi dopo una perdita, una corruzione o una modifica errata. In pratica si tratta di decidere cosa deve essere sottoposto a backup, mantenerne le copie, proteggere tali copie e testare effettivamente un ripristino per verificare che il recupero funzioni. Il recupero viene sempre più spesso configurato tramite codice: un'impostazione di conservazione su un database gestito, una pianificazione di snapshot, una policy di ciclo di vita. Questo significa che diventa una decisione da prendere nella pull request e può essere disattivato con una singola riga.
The shapes the same control failure takes.
A.8.13 non viene violato perché qualcuno cancella i backup. Viene violato quando una modifica rimuove silenziosamente la capacità di recupero. Le situazioni ricorrenti:
I backup automatici sono disattivati
Un periodo di conservazione viene impostato a zero o un lavoro di snapshot o backup pianificato viene rimosso, quindi un archivio che prima era recuperabile ora non ha più punti di ripristino recenti.
Il periodo di conservazione scende sotto la finestra di recupero
La conservazione di un backup viene accorciata (da trenta giorni a uno) a tal punto da non coprire più il tempo massimo in cui un incidente può passare inosservato prima che sia necessario un ripristino.
Un nuovo archivio viene distribuito senza backup
Un database, bucket o volume che contiene dati reali viene provisionato senza alcuna configurazione di backup, quindi non c'è nulla da cui recuperare in caso di perdita.
Il ripristino non viene mai verificato
Un passaggio che testava o verificava un ripristino viene rimosso, quindi i backup continuano a essere scritti ma nessuno sa se possono effettivamente essere recuperati, cosa che A.8.13 si aspetta che verifichiate.
Un backup viene lasciato non protetto
Uno snapshot o backup viene reso pubblico, non crittografato o condiviso troppo ampiamente, quindi la copia di backup stessa diventa l'esposizione che avrebbe dovuto prevenire.
Backup automatici disattivati sul database primario.
Un team vuole smettere di pagare per lo spazio di archiviazione dei backup automatici su un Postgres gestito durante la fase pre-lancio, quindi una modifica imposta il periodo di conservazione a zero. L'istanza ora non ha backup automatici né recupero point-in-time da essi. Se i dati vengono persi o corrotti, il recupero dipende da ciò che esiste altrove (uno snapshot manuale, uno strumento di backup separato), non da questa impostazione, e spesso non c'è altro.
resource "aws_db_instance" "primary" { engine = "postgres"- backup_retention_period = 7+ backup_retention_period = 0 # disables automated backups}Impostare il periodo di conservazione a zero disattiva i backup automatici e il recupero point-in-time sul database primario, quindi una perdita o corruzione non avrebbe un punto di ripristino automatico recente. A.8.13 (backup delle informazioni) riguarda la capacità di recupero e si aspetta che i backup vengano mantenuti e testati. Mantenete un periodo di conservazione che copra le vostre esigenze di recupero (o spostate i backup su uno strumento dedicato), piuttosto che disattivarli per risparmiare sullo spazio di archiviazione.
Il backup viene verificato in base alla capacità effettiva di ripristino.
Un auditor non prende per buono il fatto che 'abbiamo i backup'; verifica se i backup esistono per i sistemi rilevanti, vengono conservati per il periodo indicato nella vostra policy, sono protetti e, soprattutto, sono stati testati con un ripristino effettivo. Un archivio con backup disattivati, un periodo di conservazione ridotto sotto la finestra di recupero o un nuovo database avviato senza backup sono il tipo di lacune che diventano riscontri, e di solito arrivano con una singola modifica alla configurazione dell'infrastruttura. Il diff è il posto più economico per coglierle.
Una revisione, non il vostro sistema di backup.
heygrc segnalerà le modifiche che interessano A.8.13 e citerà il controllo in modo che la correzione avvenga nella pull request. Non esegue i vostri backup né test i vostri ripristini. Rileva il momento in cui una modifica rimuove o indebolisce la capacità di un archivio di essere recuperato, direttamente nel diff.