Udviklingen af backup-systemet Restic 0.18 er blevet pr\u00e6senteret. Det muligg\u00f8r opbevaring af sikkerhedskopier i krypteret format i et versioneret repository med underst\u00f8ttelse af deduplication. Systemet er oprindeligt designet til, at backup-kopier gemmes i nevenyttige milj\u00f8er, hvor det ikke skal kompromittere systemet, selvom en sikkerhedskopi havner i de forkerte h\u00e6nder. Ved oprettelse af en sikkerhedskopi er det muligt at definere fleksible regler for inkludering og ekskludering af filer og mapper (regelformatet ligner rsync eller gitignore). Der er underst\u00f8ttelse af Linux, macOS, Windows og BSD-systemer. Projektets kode er skrevet i Go-sproget og distribueres under BSD-licensen. <\/p>\n
Sikkerhedskopier kan opbevares p\u00e5 den lokale filsystem, p\u00e5 ekstern serveren<\/a> med adgang via SFTP\/SSH eller HTTP REST, i skyerne Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage og Google Cloud Storage, samt i enhver lager, hvor der findes backends til rclone. Ogs\u00e5 backup serveren, der er udviklet af projektet, kan bruges til opbevaring, som giver h\u00f8jere ydeevne i forhold til andre backends og kan arbejde i kun-tilf\u00f8jelsesmodus, hvilket forhindrer sletning eller \u00e6ndring af sikkerhedskopier i tilf\u00e6lde af kompromittering af den oprindelige server og adgang til krypteringsn\u00f8glerne. <\/p>\n Systemet underst\u00f8tter snapshots, der afspejler tilstanden af kataloghierarkiet p\u00e5 forskellige tidspunkter (snapshots oprettes automatisk for hver sikkerhedskopi). Det er muligt at kopiere snapshots mellem forskellige repository. For at spare b\u00e5ndbredde kopieres kun de \u00e6ndrede data under oprettelse af sikkerhedskopier. En snapshot med backup kan monteres som et virtuelt partition (monteringen udf\u00f8res ved hj\u00e6lp af FUSE). Derudover tilbydes kommandoer til at analysere \u00e6ndringer og selektivt udtr\u00e6kke filer. <\/p>\n Backup-lageret i Restic h\u00e5ndterer ikke hele filer, men blokke med variabel st\u00f8rrelse, der v\u00e6lges ved hj\u00e6lp af Rabins signatur. Oplysningerne opbevares i forhold til indhold snarere end filnavne (tilknyttede data-navne og objekter defineres p\u00e5 metadata-blok niveau). For at spare plads i lageret og undg\u00e5 un\u00f8dvendig kopiering af data udf\u00f8res deduplication. <\/p>\n P\u00e5 eksterne servere gemmes informationer i krypteret form \u2014 SHA-256 hashes bruges til kontrolsummer og deduplicering, AES-256-CTR algoritmen til kryptering, og autentifikation koder baseret p\u00e5 Poly1305-AES anvendes for at sikre integriteten. Der er mulighed for at verificere backupen via kontrolsummer og autentifikationskoder for at bekr\u00e6fte, at filernes integritet ikke er blevet kompromitteret. <\/p>\n I den nye version er muligheden for at udf\u00f8re et angreb (PDF) for at bestemme tilstedev\u00e6relsen af bestemte filer i det krypterede backup-lager blevet fjernet. Angrebet g\u00f8r det muligt at bestemme, om en specifik fil findes i den krypterede backup ved at f\u00e5 adgang til backup-lagringssystemet eller ved at analysere netv\u00e6rkstrafikken til backup-filerne. For eksempel kan et angreb udf\u00f8res af serveradministratoren, hvor backups gemmes, internetudbyderen eller efterretningstjenester, der har f\u00e5et adgang til server<\/a> eller trafikken. M\u00e5let med angrebet kan v\u00e6re at unders\u00f8ge et datal\u00e6k, hvor efterretningstjenester kan vurdere tilstedev\u00e6relsen af interessante dokumenter i backup-lageret. <\/p>\n For at udnytte s\u00e5rbarheden skal angriberen s\u00f8rge for, at deres data bliver tilf\u00f8jet i offerets backup, eller de skal vide, at en fil, som de kender til, findes i backupen. Hvis backupen indeholder en fil, som angriberen kender til (f.eks. en bestemt type system- eller multimedieindhold), kan de ved at f\u00e5 adgang til det krypterede lager afg\u00f8re, om der er andre interessante filer indeni. <\/p>\n Metoden er baseret p\u00e5, at man ud fra indholdets komprimeringsegenskaber kan bestemme parametrene for de blokke, der anvendes ved opdeling af indholdet. For at bestemme s\u00e5danne parametre er det tilstr\u00e6kkeligt at identificere 3 krypterede blokke, der indeholder oplysninger kendt af angriberen. <\/p>\n S\u00e5rbarheden er ikke specifik for Restic og p\u00e5virker andre backupsystemer, der bruger dataopdeling i blokke ved hj\u00e6lp af teknikken CDC (Content-Defined Chunking), s\u00e5som BorgBackup, Tarsnap, Bupstash og Duplicacy. I Tarsnap er problemet l\u00f8st i opdatering 1.0.41, mens der i BorgBackup arbejdes p\u00e5 en rettelse, som planl\u00e6gger at blive inkluderet i borg 2. I Bupstash var den seneste \u00e6ndring for 2 \u00e5r siden, og i Duplicacy \u2014 for 4 m\u00e5neder siden. <\/p>\n Det bem\u00e6rkes desuden, at i systemer, der anvender deduplicering, kan man lettere bestemme, om de \u00f8nskede filer er til stede ved at tilf\u00f8je sine egne filer til backupen. Efter at den kontrollerede fil er tilf\u00f8jet, kan man vurdere \u00e6ndringen i lagerst\u00f8rrelsen \u2014 hvis filen allerede findes i lageret, vil dens gentagne tilf\u00f8jelse ikke f\u00f8re til en v\u00e6sentlig stigning i st\u00f8rrelsen p\u00e5 grund af dedupliceringen. <\/p>\n Udover at fjerne s\u00e5rbarheden i Restic 0.18 er der ogs\u00e5 foresl\u00e5et flere nye funktioner: <\/p>\n\n