Restic: Mendukung pencadangan asimetris

Rekap singkat dari diskusi sebelumnya:

• Berguna untuk pencadangan server email atau pencadangan jarak jauh dari data log jika server tersebut disusupi. Data sensitif yang telah diparut dari server mungkin ada dalam cadangan, dan mungkin berguna untuk menolak akses penyerang ke data historis tersebut. Secara bersamaan dibahas bahwa mungkin berguna untuk memiliki "server jaringan gumpalan" dengan sistem kemampuan yang memungkinkan Anda untuk mengonfigurasi akses append-only / read-only / read-write yang sesuai. Memiliki kriptografi asimetris di tempat akan menghilangkan kebutuhan untuk memiliki _yang lain_ set kunci simetris untuk mengeluarkan kemampuan, dan kemungkinan akan menyederhanakan implementasi sistem kemampuan juga.
• Dalam pengaturan dengan beberapa mesin, kunci cadangan _one_ dapat digunakan untuk mengakses beberapa kumpulan data cadangan tanpa harus mengelola banyak kunci simetris. Jika kriptosistem seperti Curve25519 Daniel Bernstein digunakan, kunci tersebut mungkin berasal dari frasa sandi, artinya Anda dapat menggunakan satu frasa sandi utama untuk mengelola cadangan yang dibuat oleh sejumlah (berpotensi besar) dari domain keamanan yang berbeda. Meskipun sesuatu yang serupa tentu saja dapat dicapai dengan kunci simetris n dan penyimpanan kunci terenkripsi.

@heipei FYI Anda mungkin ingin berlangganan masalah ini

baik, kasus penggunaan yang paling jelas dan mendesak adalah tidak memiliki cadangan yang dihapus oleh penyerang yang telah membobol sistem produksi Anda (klien cadangan) dan tahu cara menggunakan restic dari sana.

Itu hampir tidak mungkin hanya dengan menggunakan kripto asimetris. Intinya di sini adalah bahwa konten cadangan lama (belum tentu metadata) tidak boleh tersedia untuk penyerang yang telah membobol server.

Kerahasiaan data ( write-only ) akan dapat dicapai untuk skenario ini dengan penerapan kripto asimetris.

Integritas data adalah binatang yang sedikit berbeda:
Meskipun Anda dapat menggunakan kriptografi asimetris (dan skema tanda tangan satu kali) untuk membuktikan bahwa kumpulan data tertentu belum diubah, Anda tidak dapat mencegah penghapusan atau penggantiannya sepenuhnya. Itu adalah masalah yang membutuhkan sistem penyimpanan append-only (dan read-only , untuk beberapa bagian).
Berkat kontrol akses diskresioner yang relatif mudah diterapkan pada *nix dengan backend seperti ssh (menggunakan perintah seperti chmod , chown , chattr +i , chattr +a untuk mengkonfigurasi kebijakan akses). Cadangan append-only bahkan tidak perlu dienkripsi untuk mencegah penyerang membacanya (misalnya, itu adalah bagian dari apa yang dilakukan rsyslog ), tetapi itu tiba-tiba membuat server cadangan menjadi target yang menarik, dan mengkloning data sensitif ke lebih banyak perangkat tidak benar-benar meningkatkan peluang menjaga kerahasiaan data .

Menerapkan kripto asimetris akan memungkinkan orang untuk melakukan pencadangan semacam ini pada sistem yang bodoh dan tidak tepercaya, salah satu hal tentang restic (selain dari deduplikasi yang ditingkatkan dan semua fitur bagus lainnya). Saya harap penjelasan ini sedikit memperjelas maksud saya.

Ini menarik bagi kami untuk dua kasus yang dijelaskan di https://github.com/restic/restic/issues/187#issuecomment -101974306. Saya berlangganan utas ini untuk mengawasi ini.

Mengenai integritas data : AFAIK, Anda dapat mencapai perilaku append-only di Amazon S3 dengan hanya memberikan kredensial IAM Anda izin PutObject dan GetObject , tetapi menahan DeleteObject izin.

Mengenai kerahasiaan data , saya ingin menyebutkan skenario serangan yang diaktifkan oleh penggunaan kripto simetris:
Jika penyerang memiliki kendali atas akun pengguna korban pada saat korban menggunakan restic untuk melakukan pencadangan, ia dapat:

• mencuri kunci restic korban
• mencuri kredensial IAM korban/sftp login/...

Penyerang kemudian dapat segera menghapus jejak serangannya dari sistem korban yang membuat deteksi menjadi lebih kecil. Karena dia telah mencuri kunci restic dan kredensial untuk sistem penyimpanan jarak jauh, korban akan dengan mudah mengirimkan data masa depan (yang dicadangkan) kepadanya: Penyerang kami hanya perlu mengunduh dan mendekripsi cadangan baru dari sistem penyimpanan jarak jauh dari waktu ke waktu. waktu.

Kripto asimetris dapat membantu mencegah hal ini dengan membiarkan korban menyimpan kunci untuk memulihkan cadangan secara offline.

Mengenai integritas data: AFAIK, Anda dapat mencapai perilaku tambahan saja di Amazon S3 dengan hanya memberikan kredensial IAM Anda izin PutObject dan GetObject, tetapi menahan izin DeleteObject.

Sayangnya PutObject juga memberi Anda hak istimewa untuk menimpa file yang diunggah sebelumnya. Jadi, mungkin itu bukan integritas data penuh?

Kripto asimetris juga memungkinkan penggunaan kunci OpenPGP seperti yubikey atau lebih.

Hari ini saya menyadari bahwa saya tidak benar-benar menginginkan dukungan untuk enkripsi asimetris dalam restic, tetapi dukungan untuk TIDAK menyimpan kunci dalam repositori. Saya mengerti bahwa menggunakan enkripsi asimetris secara efisien berarti restic dapat mengunggah cadangan baru tanpa kemampuan untuk membaca repositori, yang cukup rumit.

Jadi, bagi saya, akan baik-baik saja jika saya bisa menangani kunci simetris tanpa restic, dan tidak diunggah dengan cara apa pun ke repositori, tidak peduli apa pun KDF kompleks yang digunakan.

Kasus penggunaan saya adalah sebagai administrator sistem untuk sejumlah server.

Cadangan asimetris adalah satu-satunya cara untuk melindungi cadangan dalam skenario kompromi server di mana penyerang dengan jahat menghancurkan (atau mengenkripsi ransomware) semua data (termasuk cadangan).

Ini membutuhkan dukungan sisi server baik melalui lapisan penyimpanan tambahan saja atau daemon server yang mirip dengan cara rdiff-backup memiliki opsi --restrict-update-only. Saat ini saya mengatasi ini dengan menggunakan snapshot read-only dari repositori cadangan di server cadangan (diakses melalui sftp).

(Mungkin relevan): Append-only dapat dicapai di Linux melalui flag append-only pada direktori (yang menonaktifkan unlinking) bersama dengan flag immutable pada file. Perintah yang bertanggung jawab untuk menyetel flag tersebut adalah chattr +a /path/to/directory dan chattr +i /path/to/directory/myfile01 .

kasus penggunaan saya di sini adalah #533 - pencadangan tanpa pengawasan. seperti yang dinyatakan di sana, crypto asimetris hanyalah salah satu cara untuk melakukan ini, tetapi sepertinya solusi pertama yang jelas untuk masalah ini.

Dalam skenario di mana repo berada di server jarak jauh - hanya perintah lokal di repo yang dapat dilupakan/dipangkas.

Cadangan sisa, harus terhubung dengan kunci unik untuk sistem itu dengan hak pemulihan / pencadangan saja.

Dalam skenario di mana repo berada di server jarak jauh - hanya perintah lokal di repo yang dapat dilupakan/dipangkas.

Ini harus dilakukan dengan membatasi akses untuk menghapus/memodifikasi file pada tingkat repo. Saya pikir itu di luar ruang lingkup (dan bahkan tidak aman) untuk restic untuk mengelola izin ini. Lagi pula, seseorang dapat menghapus repo atau bahkan kuncinya, menjadikan seluruh repo tidak berguna, terlepas dari apakah tindakan itu diizinkan oleh klien lain.

Mengenai mencegah data cadangan dihancurkan oleh seseorang yang meretas server: rest-server baru-baru ini memperoleh "mode tambahkan saja" dengan PR https://github.com/restic/rest-server/pull/28 yang mencegah hal ini.

Kasus penggunaan saya adalah memiliki banyak sistem yang dicadangkan ke repositori yang sama, mendapatkan keuntungan dari deduplikasi di semua mesin itu, tetapi kompromi dari satu sistem (dan skrip cadangannya) tidak memungkinkan penyerang untuk membaca cadangan dari sistem lain.

Fitur yang saya cari adalah memiliki kunci "cadangan" yang akan memungkinkan sistem untuk menulis (mencadangkan) dan membaca (mengembalikan) tetapi tidak dapat melakukan admin apa pun, (seperti memangkas, menambahkan kunci atau bahkan melihat keberadaan lainnya kunci, (pengguna) atau snapshot yang tidak terkait dengan $backup_key ). (Meskipun serangan saluran samping mungkin dilakukan dengan membandingkan waktu pencadangan, tidak masalah bagi saya jika mereka dapat menentukan keberadaan data, hanya saja mereka tidak dapat ransomware data saya dan tidak dapat melihat pengguna lain.) Saya harapkan pemegang kunci-(hanya)-cadangan untuk dapat memutar frasa sandi mereka sendiri ke depan. Jadi tidak seperti permintaan michbsd, saya dapat menjadi admin dari mesin non-lokal dengan kunci istimewa. (Setelah menggunakan SELinux selama bertahun-tahun, saya sekarang menjadi penggemar granularitas MAC) Terima kasih telah membaca. (Maaf jika ini memiliki masalah sendiri.) Dengan fitur ini #ResticKillsRansomware

Dengan fitur ini #ResticKillsRansomware

Secara umum, cadangan berorientasi tarik (sebagai lawan dari yang berorientasi push) memecahkan ransomware, bukan? :)

Mungkin tetapi itu kemudian memberikan akses jarak jauh dan menambahkan vektor serangan lain. Bagaimana saya mendesainnya, server cadangan saya adalah untuk melestarikan data dan tidak boleh memiliki akses ke lingkungan produksi saya. Demarkasi yang jelas dari domain fungsional.

Saya kira Restic bukan solusinya, karena itu dirancang untuk beroperasi pada repo cadangan secara langsung.

Mungkin Anda bisa melakukan sesuatu dengan semacam server perantara. Mintalah mesin produksi Anda mengunggah tarball ke server, lalu minta sistem lain mengunduh tarball, mengekstraknya, dan mencadangkan konten secara lokal. Masing-masing pihak hanya memiliki akses ke server tengah. Itu akan cukup mudah dilakukan tanpa modifikasi apa pun pada Restic. Mungkin akan lebih aman dan lebih kuat juga, karena bug apa pun dalam mode Restic yang hanya menerima dapat membuat cadangan rentan terhadap klien cadangan yang disusupi.

Fitur yang saya cari adalah memiliki kunci "cadangan" yang akan memungkinkan sistem untuk menulis (mencadangkan) dan membaca (mengembalikan) tetapi tidak dapat melakukan admin apa pun, (seperti memangkas, menambahkan kunci atau bahkan melihat keberadaan lainnya kunci, (pengguna) atau snapshot yang tidak terkait dengan $backup_key ). (Meskipun serangan saluran samping mungkin dilakukan dengan membandingkan waktu pencadangan, tidak masalah bagi saya jika mereka dapat menentukan keberadaan data, hanya saja mereka tidak dapat ransomware data saya dan tidak dapat melihat pengguna lain.) Saya harapkan pemegang kunci-(hanya)-cadangan untuk dapat memutar frasa sandi mereka sendiri ke depan. Jadi tidak seperti permintaan michbsd, saya dapat menjadi admin dari mesin non-lokal dengan kunci istimewa. (Setelah menggunakan SELinux selama bertahun-tahun, saya sekarang menjadi penggemar granularitas MAC) Terima kasih telah membaca. (Maaf jika ini memiliki masalah sendiri.) Dengan fitur ini #ResticKillsRansomware

Meskipun ini mungkin bukan yang Anda inginkan, Anda dapat melihat rest-server . Ini memiliki mode tambahan saja yang mencegah penghapusan dan modifikasi cadangan yang ada.

Meskipun ini mungkin bukan yang Anda inginkan, Anda dapat melihat rest-server. Ini memiliki mode tambahan saja yang mencegah penghapusan dan modifikasi cadangan yang ada.

Aku bahkan tidak menyadari itu ada. D:

Saya melihat dua hal struktural (dan model penyerang yang sedikit berbeda) yang ingin saya buang di sini.

Saat ini, restic (kebanyakan) berinteraksi dengan penyimpanan "bodoh" (lokal, s3, b2, gcs, Azure, semuanya kecuali untuk server REST dengan --append-only ). Itu dapat menyimpan, membuat daftar, mendapatkan, dan menghapus data di backend. Ini diperlukan untuk pencadangan, sehingga kredensial yang diperlukan untuk mengakses backend harus ada. Sisi baiknya, restic dapat menggunakan hampir semua penyimpanan, hanya ada sedikit batasan. Pada sisi negatifnya, begitu penyerang mendapatkan akses ke server, mereka dapat dengan mudah mengekstrak kredensial untuk mengakses backend dan kata sandi restic, memberi mereka semua kemungkinan: Mendekripsi data historis dari repositori, memodifikasi data, menghapus seluruh repositori.

Ketika kami menambahkan kriptografi asimetris, satu-satunya perbedaan bagi penyerang dalam situasi seperti itu adalah mereka tidak dapat mendekripsi data historis dari repositori. Segala sesuatu yang lain, terutama menghapus semua data, masih dimungkinkan. Jadi "tambahkan saja crypto asimetris" bukanlah keseluruhan cerita.

Ide lainnya adalah untuk tidak mengakses penyimpanan "bodoh" secara langsung, tetapi secara tidak langsung melalui implementasi server khusus. Kami telah bermain-main dengan ide ini dan menambahkan opsi --append-only untuk server REST , yang dapat dilihat sebagai "adaptor" untuk mengakses penyimpanan "bodoh" di harddisk lokal. Saya punya beberapa ide tentang cara meningkatkan ide itu, tidak harus dengan server REST.

Misalnya, saya ingin mendefinisikan protokol untuk backend yang diucapkan melalui sepasang deskriptor file, misalnya stdin/stdout. Kami kemudian dapat mengimplementasikan ini dalam program yang dijalankan melalui SSH pada mesin jarak jauh, seperti yang kami lakukan untuk backend sftp. Implementasi server kemudian dapat memutuskan di mana menyimpan data (lokal, s3, b2, apa pun) dan batasan mana yang berlaku (misalnya "hanya menambahkan baca lama atau menambahkan data baru", tanpa kemampuan untuk menghapus apa pun selain mungkin mengunci file. Server misalnya dapat dimulai melalui ForceCommand saat masuk melalui SSH dengan akun pengguna atau kunci SSH tertentu.

Memiliki penyimpanan "non-bodoh" saja tidak akan membantu penyerang membaca data dari repositori (setidaknya tidak tanpa mengubah format repo), tetapi akan mencegah penghapusan semua data dalam repo.

Jadi, sebagai kesimpulan, untuk mempertahankan yang terbaik dari penyerang yang mengambil alih server yang menggunakan restic untuk cadangan, saya pikir kita perlu menerapkan keduanya (penyimpanan non-bodoh dan kripto asimetris). Itu tujuan jangka panjang :)

Saya akan menyalin teks ini ke komentar pertama dalam edisi ini sehingga lebih mudah ditemukan.

ya, merenungkan ini lebih jauh, saya setuju bahwa asym crypto tidak begitu berguna untuk bertahan dari pengambilalihan - ini lebih berguna untuk cadangan yang tidak dijaga (#533).

memiliki protokol komunikasi asli dapat bermanfaat, tetapi saya tidak yakin apa yang Anda dapatkan dari itu melalui server REST saat ini - dapatkah Anda memperluasnya? loteng / borg pergi dengan cara itu: ada klien-ke-server "milik" (seperti dalam, borg-spesifik) protokol di sana dan itu adalah mungkin untuk menerapkan beberapa pembatasan untuk klien. dan ya, ini bergantung pada bendera terbatas ForceCommand dan "borg serve"... ada beberapa catatan yang relevan dalam dokumen borg tentang ini dan kekurangannya yang harus Anda ketahui.

dan tentu saja, cara paling alami untuk melindungi cadangan dari klien yang disusupi adalah dengan tidak mengizinkan klien melakukan pencadangan itu sendiri, tetapi sebaliknya meminta server menarik file dari cadangan, "bergaya bacula" ("Itu datang dalam malam dan menghisap esensi dari komputer Anda", bagi mereka yang mengingat frasa yang menarik itu). sepertinya tidak ada cara yang terdokumentasi dengan baik atau elegan untuk melakukan ini di borg, FAQ menunjuk ke https://github.com/borgbackup/borg/issues/900 sebagai diskusi tentang topik tersebut. di sini ini dilacak di #299, yang belum disebutkan di sini.

singkatnya, saya akan menjaga fokus dukungan kripto asimetris tetap sederhana: membuatnya lebih mudah untuk memiliki penyimpanan kunci di luar lokasi dan pencadangan otomatis. ada cara lain untuk mengamankan klien yang dikompromikan, dan saya pikir dukungan tarik adalah yang paling menarik. sebenarnya, dalam solusi pencadangan optimal saya, saya meminta semua klien mendorong cadangan mereka ke server pusat, lalu server di luar lokasi menarik dari server cadangan utama. cara ini:

1. server cadangan tidak memerlukan akses root di semua mesin
2. namun kompromi mesin masih dapat dipulihkan, bahkan jika mereka dapat mengacaukan cadangan

saya sebenarnya merasa aneh bahwa masalah ini berubah menjadi "saya ingin mengamankan terhadap pengambilalihan klien" - mungkin kami mengacaukan solusi dengan masalah di sini. :)

Hai,

Tampaknya masalah ini bukan hanya tentang cadangan crypto asimetris, tetapi lebih banyak tentang vektor serangan yang berbeda.
Saya tidak membaca kodenya, jadi saya benar-benar memiliki pertanyaan naif, tetapi kasus penggunaan saya sebagian besar tentang dapat membuat cadangan data tanpa mengungkapkan kunci rahasia (dengan menggunakan kunci publik dari kunci pribadi offline dari pemilik cadangan). Untuk kasus penggunaan itu, apakah mudah diimplementasikan?

Pemahaman saya tentang subjek ini adalah bahwa saat ini semua gumpalan dienkripsi dengan kunci yang sama, dan ini berfungsi dengan baik.
Jika kita akan menggunakan kripto asym seperti cara kerja OpenPGP, setiap snapshot yang dibuat akan menghasilkan kunci simetris yang dienkripsi dengan kunci publik dan menambahkannya ke dalam repositori. Tapi saya kira masalahnya adalah untuk dapat menemukan apa yang harus diduplikasi dan apa yang harus dicadangkan, Anda harus dapat membaca info terlebih dahulu, maka Anda juga memerlukan kunci pribadi. Apakah itu benar?
Jika itu masalahnya, dapatkah beberapa bukti pengetahuan nol dapat membantu di sepanjang garis itu?

@dolanor tolong jangan tambahkan kasus penggunaan atau pertanyaan baru untuk masalah ini, gunakan forum untuk pertanyaan. Juga, masih terlalu dini untuk membicarakan detail implementasi.

Saya telah memperbarui ringkasan di posting pertama. Sementara itu backend rclone telah ditambahkan, ini dapat digunakan sebagai "adaptor" seperti dijelaskan di atas, dan diakses misalnya melalui SSH.

Pada sisi negatifnya, begitu penyerang mendapatkan akses ke server, mereka dapat dengan mudah mengekstrak kredensial untuk mengakses backend dan kata sandi lainnya.

Saya harap ini salah ketik: Anda laki-laki materi keyfile terenkripsi di sini, bukan? Semoga penyerang yang mendapatkan akses ke server tidak memiliki akses ke kata sandi plaintext. Yang terburuk yang dapat mereka lakukan adalah mencoba untuk memaksa atau menebak "kata sandi pengguna" yang digunakan untuk mendekripsi enkripsi master dan kunci otentikasi ke repositori.

Jika itu benar, saya akan sangat menyarankan Anda mengubah ringkasan lagi untuk memperjelas, karena pasti terlihat buruk ketika dinyatakan seperti itu. :)

Semoga penyerang yang mendapatkan akses ke server tidak memiliki akses ke kata sandi plaintext. Yang terburuk yang dapat mereka lakukan adalah mencoba untuk memaksa atau menebak "kata sandi pengguna" yang digunakan untuk mendekripsi enkripsi master dan kunci otentikasi ke repositori.

Saya kira itu tergantung pada skenario yang tepat: Jika Anda memasukkan kata sandi secara manual, benar. Jika Anda melakukan pencadangan otomatis terjadwal, di sisi lain, "kata sandi pengguna" harus disimpan di suatu tempat di server.

Dan, tentu saja, penyerang mungkin menukar biner Restic dengan yang membocorkan kata sandi yang dimasukkan dan menunggu Anda memasukkannya. Anda tidak dapat mempercayai sistem yang disusupi.

"kata sandi pengguna" harus disimpan di suatu tempat di server.

dengan "server" maksud Anda "mesin yang kami gunakan untuk menyimpan data" atau "mesin yang menerima/menyimpan data dari cadangan"?

itu agak ambigu, dan sumber kekhawatiran saya: Saya tidak keberatan klien cadangan (mesin yang kami cadangkan yang menjalankan restic) memiliki kata sandi dalam teks yang jelas: seluruh dataset ada di sana jadi jika itu dikompromikan, datanya dikompromikan. tetapi saya berharap server cadangan tidak memiliki akses ke teks yang jelas!

dengan "server" maksud Anda "mesin yang kami gunakan untuk menyimpan data" atau "mesin yang menerima/menyimpan data dari cadangan"?

Mesin tempat kami menjalankan restic tempat kami menyimpan data.

Saya mengerti maksud Anda, Anda benar, itu ambigu. Pemahaman saya dari semua yang saya ketahui tentang model Restic adalah sama dengan Anda, saya cukup yakin tentang itu, tetapi saya tidak dapat memberikan konfirmasi pasti yang Anda inginkan.

Ringkasan menyebutkan opsi --append-only untuk server REST. Mungkin itu harus tetap sebagai satu-satunya metode cadangan tambahan yang direkomendasikan secara resmi, tetapi mungkin baik untuk mendokumentasikan file mana yang perlu ditulis untuk operasi normal untuk membantu mencari tahu cara mengatur pendekatan lain.

Saya percaya bahwa restic backup akan berfungsi dengan baik jika data , index , keys , dan snapshots mengizinkan pembuatan file tetapi tidak memodifikasi atau menghapus ( dan config juga dilindungi). Namun, saya pikir locks perlu mengizinkan penghapusan agar repositori tidak terkunci secara permanen. Juga, beberapa implementasi tambahan saja (seperti atribut untuk sistem file ext4 dan xfs) tidak rekursif, jadi 256 subdirektori dua karakter data perlu dibuat sebelumnya terlebih dahulu dan kemudian atribut perlu ditetapkan pada mereka.

Beberapa backend seperti S3 tidak mendukung append-only tetapi mendukung pembuatan versi objek yang dapat mencapai efek yang sama. Namun, ini memerlukan pemeriksaan model kontrol akses yang cermat. Misalnya, B2 memiliki aturan siklus hidup yang memungkinkan pembuatan versi objek, tetapi kunci API yang diperlukan untuk mencadangkan ke B2 memiliki kemampuan untuk memodifikasi aturan siklus hidup (B2 belum memiliki banyak sistem izin).

Selain: Saya mungkin kehilangan sesuatu, tetapi jika enkripsi asimetris hanya melindungi data historis dari penyerang yang telah membahayakan klien, sepertinya itu prioritas rendah. Akan menyenangkan untuk memiliki tetapi dalam banyak kasus data saat ini lebih berharga daripada versi sebelumnya (meskipun terkadang sesuatu yang berharga secara tidak sengaja dicadangkan, dihapus, tetapi tidak dibersihkan).

@willsALMANJ pengamatan yang baik. Untuk S3 saya ingin tahu apakah versi keberatan dapat direkam untuk memungkinkan pengambilan tampilan yang koheren dari gumpalan yang diperlukan untuk memulihkan snapshot yang diberikan (walaupun Anda dapat memvalidasinya berdasarkan kontennya, jadi tidak terlalu penting).

Re: paragraf terakhir Anda:

• Manfaat utama enkripsi asimetris, selain skenario "dekripsi hal-hal historis" yang Anda sebutkan, adalah dapat menyimpan cadangan dari beberapa mesin independen dalam repositori cadangan yang sama tanpa harus menyediakan kunci individual (yang mengharuskan penyimpanan kunci cadangan di suatu tempat setiap kali Anda menginstal mesin klien baru). Jika Anda menggunakan kunci bersama, Anda mendapatkan skenario ancaman yang mengganggu di mana client1 dapat membaca data client2, yang tidak ideal.

@ fd0 Saya pikir saya memiliki skema yang layak untuk enkripsi asimetris menggunakan pengalamatan HMAC dengan rahasia bersama yang diturunkan. Juga beberapa ide tentang pengumpulan sampah sisi server tanpa membocorkan data, tidak yakin apakah Anda tertarik, tetapi jika Anda tertarik, saya akan tertarik untuk membicarakannya.

Saya tidak tahu apakah saya melewatkan sesuatu di sini, tetapi saya berhasil menjalankan restic dengan pengaturan kebijakan ini pada penyimpanan S3. Itu tidak mencegah penyerang membaca data, tetapi mencegahnya untuk menghapus.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

Perintah pangkas/lupakan kemudian dijalankan dari perangkat tepercaya yang memiliki izin menulis. Saya juga membuat dua kunci di setiap repositori restic. Satu untuk server dan satu untuk perangkat tepercaya, sehingga perangkat tepercaya dapat mengunci penyerang (tetapi penyerang tidak dapat melakukannya karena ia tidak dapat menghapus dalam kunci/*).

Sunting: Maaf, diabaikan bahwa ini sudah dibahas. Tidak ingin membajak thread ini.
PutObject sebenarnya mampu menimpa objek jadi ini bukan solusi untuk melindungi backup .

@freswa Saya bukan ahli S3, jadi saya tidak yakin ini benar, tetapi poin yang dibuat di atas dalam diskusi ini adalah bahwa izin PutObject dapat digunakan untuk menimpa data Anda yang sama buruknya seperti menghapusnya. Dalam posting saya di atas, saya mencatat bahwa Anda dapat mengatasi masalah ini dengan menggunakan versi objek (jangan berikan akses sistem cadangan untuk menghapus versi).

@andrewchambers Saya agak

Jadi, masalah ini adalah tentang (akhirnya) menerapkan pencadangan asimetris, bukan mengakses konfigurasi untuk penyimpanan backend. Terima kasih! :)

@ fd0 Semoga ini menjelaskan apa yang saya maksud https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : Kalau-kalau Anda belum menemukan masalah tulis saja (yang Anda sebutkan di situs Anda), ini https://github.com/ncw/rclone/issues/2499 .

@andrewchambers terima kasih telah menuliskannya, saya sangat tertarik seperti apa implementasi yang sebenarnya. Posting blog meninggalkan beberapa bit menarik terbuka :)

Saya suka bahwa akan ada pesaing lain di ruang program cadangan perangkat lunak gratis, memberi pengguna lebih banyak opsi selalu bagus!

Jadi paralel yang menarik dapat dibuat dengan dua mekanisme enkripsi repositori git.

Di satu sisi Anda memiliki git-crypt : ini menggunakan git smudge/clean filter untuk (masing-masing) mengenkripsi/mendekripsi file antara penyimpanan gumpalan dan salinan yang diperiksa. Ini bekerja dengan baik dan cukup optimal, tetapi memiliki satu lubang mencolok: git commit itu sendiri tidak dienkripsi, hanya konten gumpalan, yang berarti bahwa nama file, commitlog, penulis, tanggal, dan metadata lainnya semuanya disimpan dengan jelas. Itu tidak boleh digunakan untuk banyak kasus penggunaan dan hanya efektif ketika Anda memiliki repositori publik di mana (misalnya) Anda ingin mengenkripsi beberapa bit (tetapi tidak semua).

Di sisi lain Anda memiliki git-remote-gcrypt : yang menggunakan protokol git remote helper untuk mengenkripsi semua yang dikirim di server. Tapi itu sangat tidak efisien, karena seluruh repositori dienkripsi ulang setiap kali dijalankan, karena cara kerja remote khusus.

Sekarang, itu adalah tantangan implementasi khusus git, tetapi saya pikir itu memetakan dengan baik ke dalam masalah yang mungkin Anda dapatkan di sini. Mungkin saya benar-benar keluar dari kedalaman saya di sini dan paralel ini tidak relevan, tetapi saya pikir itu mungkin menarik di sini ...

Selain itu, ada jalan tengah yang saat ini dapat diimplementasikan (mungkin) dengan lebih mudah: izinkan kunci disimpan di luar repositori.

Salah satu vektor serangan yang ditangani adalah penyerang mendapatkan kata sandi kunci, dan kemudian (karena kunci disimpan dengan repositori) dia dapat mendekripsi kunci dengan mudah.

Bagaimana jika kita mengizinkan spesifikasi direktori kunci terpisah, di mana file kunci disimpan? Direktori ini dapat disimpan secara lokal di setiap mesin yang perlu melakukan pencadangan, dan dapat dicadangkan sendiri ke penyedia cloud yang berbeda, atau bahkan kode QR (~ 500 byte cukup kecil untuk dikodekan dengan QR) untuk penyimpanan offline dingin dalam brankas, misalnya.

Jika kunci terenkripsi tidak pernah menyentuh penyedia cloud, vektor serangan akan hilang sepenuhnya. Kunci harus dikompromikan dari tempat fisik atau dieksfiltrasi dengan malware, misalnya.

Ini _dapat dilakukan di Restic_ jika salinan lokal dari repositori disimpan -- cukup kecualikan direktori kunci agar tidak disinkronkan ke remote yang tidak tepercaya saat menjalankan rclone. Ini _tidak bisa_ dilakukan jika tidak ada salinan lokal dan restic langsung berinteraksi dengan remote yang tidak terpercaya.

Saya pikir kita harus menerapkan prinsip tanggung jawab tunggal dan membaginya menjadi 2 tugas:

1. Menjaga data aman dari dekripsi.
2. Menjaga data tetap aman dari tindakan penghapusan yang tidak sah.

Mereka adalah 2 aspek keamanan data yang berbeda. Secara teknis mereka tidak harus bergantung satu sama lain.

Untuk (1), jelas kita dapat "cukup menambahkan dukungan enkripsi asimetris". Untuk (2), saya yakin ada banyak solusi yang mungkin (misalnya, seperti yang disebutkan di atas, hanya menambahkan pengaturan S3).