Cadangan offsite aman, bahkan dalam kasus akses root hacker

Saya mencari cara untuk menerapkan cara yang lebih aman dalam melakukan backup di luar kantor yang juga akan melindungi data saya terhadap situasi di mana peretas jahat telah mendapatkan akses root ke server saya. Meskipun kemungkinan itu terjadi lebih kecil dari risiko lain jika SSH dan keamanan kata sandi diatur dengan benar dan sistem tetap diperbarui dengan benar, jumlah kerusakan yang dapat dilakukan secara permanen benar-benar tinggi dan oleh karena itu saya Saya ingin mencari solusi untuk membatasi itu.

Saya sudah mencoba dua cara backup di luar kantor:

• mount webdav root-dapat ditulis sederhana (dan dikonfigurasi dalam fstab) di mana data yang dicadangkan disalin ke. Masalah : sebenarnya bukan cadangan di luar kantor karena koneksi - dan juga akses - ke lokasi di luar selalu dibiarkan terbuka sebagai folder di sistem file. Ini adalah perlindungan yang memadai terhadap berbagai jenis serangan jika mount memiliki hak akses terbatas (baca akses root saja), tetapi tidak melindungi terhadap orang jahat dengan akses root.

• Cadangan Borg melalui SSH dengan otentikasi kunci. Masalah : koneksi ke server luar kantor itu dapat dilakukan dengan kunci yang disimpan di host jika pengguna jahat memiliki akses root ke host.

Sebagai solusi, saya memikirkan cara-cara potensial ini, tetapi saya tidak tahu bagaimana dan dengan apa:

• Cadangan hanya dapat ditulis atau ditambahkan ke tujuan tetapi tidak dihapus.
• Penggunaan perangkat lunak cadangan yang menangani cadangan luar kantor dan tidak mendukung penghapusan massal cadangan luar kantor dari host pertama.

Solusi yang tidak terlalu menarik dalam situasi saya:

• Pekerjaan cadangan tambahan pada host di luar kantor yang mentransfernya ke lokasi yang tidak dapat diakses oleh host pertama (karena keterbatasan teknis).

Adakah yang bisa memberikan saran tentang cara menerapkan cadangan luar kantor yang tepat untuk kasus saya?

Semua saran Anda saat ini memiliki satu kesamaan: sumber pencadangan melakukan pencadangan dan memiliki akses ke tujuan pencadangan. Apakah Anda memasang lokasi atau menggunakan alat seperti SSH atau rsync, sistem sumbernya entah bagaimana memiliki akses ke cadangan. Karenanya, kompromi pada server juga dapat membahayakan cadangan Anda.

Bagaimana jika solusi cadangan memiliki akses ke server? Sistem cadangan dapat melakukan tugasnya dengan akses hanya baca , jadi segala kompromi pada sistem cadangan mungkin tidak akan membahayakan server. Juga, sistem cadangan dapat didedikasikan untuk tujuan itu sendiri, membuat isi cadangan satu-satunya vektor serangan. Itu akan sangat tidak mungkin dan perlu serangan yang sangat canggih.

Untuk menghindari menimpa cadangan dengan konten yang dirusak atau rusak, lakukan pencadangan tambahan yang memungkinkan Anda memulihkan keadaan sebelumnya dalam periode pemulihan yang ditentukan.

Penyimpanan Abadi

Salah satu opsi yang baik adalah membuat penyimpanan cadangan Anda tidak berubah, atau setidaknya memberikan versi yang andal yang memberi Anda kekekalan yang efektif. Agar lebih jelas: kekekalan berarti tidak bisa diubah, atau permanen.

Ada beberapa layanan yang dapat melakukan ini untuk Anda. AWS S3, BackBlaze B2, dan saya curiga Azure dan Google keduanya menawarkan layanan serupa. Anda mungkin dapat mengatur server untuk melakukan ini, tetapi saya tidak yakin bagaimana caranya.

Ketika Anda memiliki repositori yang tidak dapat diubah / dikendalikan versi, Anda dapat mengembalikan cadangan ke titik mana pun, jadi jika host Anda dikompromikan, Anda masih dapat memulihkannya kapan saja.

* AWS S3 **

Saya paling akrab dengan AWS S3. S3 menyediakan penyimpanan terenkripsi dan terenkripsi, dengan tingkat daya tahan tinggi.

S3 mendukung versi, yang memberi Anda keabadian yang efektif. Anda dapat memilih untuk menggunakan aturan siklus hidup untuk menghapus file versi lama setelah periode waktu yang dapat Anda konfigurasi. Anda juga dapat mengarsipkan versi ke penyimpanan dingin (arsip dingin gletser), yang harganya sekitar $ 1 / TB / bulan.

Anda dapat menggunakan kelas tiering penyimpanan cerdas untuk mengurangi biaya. Saya memilih untuk menggunakan aturan siklus hidup untuk memindahkan semua data statis ke kelas akses yang jarang, yang tahan lama dan sedang (panas) kinerja tetapi tidak memiliki skalabilitas atau kinerja standar S3.

S3 menggunakan pengguna dan kebijakan IAM (manajemen akses identitas, yaitu manajemen pengguna). Ini memberi Anda kontrol yang sangat terperinci tentang apa yang dapat dilakukan perangkat lunak cadangan dengan penyimpanan Anda. Anda dapat memberikan izin kepada pengguna cadangan untuk unggahan tetapi menolak pembaruan dan hapus. Anda juga dapat meminta otentikasi multi-faktor untuk menghapus file, atau bahkan menyediakan kunci objek sehingga file tidak dapat dihapus.

Perangkat Lunak yang Disarankan

Saya membuat cadangan tambahan menggunakan Restic . Restic mengunggah file baru ke lokasi penyimpanan Anda. Saya percaya (tapi saya bisa salah) bahwa itu membuat file baru, tetapi secara umum tidak memperbarui atau menghapus file apa pun.

Borg adalah pilihan lain. Saya dulu menggunakan Borg, tetapi saya menemukan bahwa dengan cadangan ukuran sedang saya dari ratusan MB secara efektif mengunggah semua data saya setiap hari dari EC2 ke S3. Bagi saya ini bukan tambahan, jadi saya berhenti menggunakannya. Saya memang menemukan dokumentasi tentang ini, tetapi tidak memiliki tautan.

Ada puluhan perangkat lunak yang dapat diunggah ke penyimpanan cloud.

Penyimpanan yang Dilindungi

Dengan beberapa perangkat lunak cadangan, Anda dapat mencoba memberikan izin pengguna IAM untuk menulis file baru tetapi tidak memperbarui file yang ada. Sangat mudah untuk membuat batasan ini dengan AWS IAM, tetapi sesuai komentar di bawah ini, Restic tidak akan bekerja dengan izin tersebut. Anda juga dapat memiliki otentikasi multi-faktor yang diperlukan untuk menghapus file dari S3.

Anda dapat memiliki pengguna IAM lainnya, jalankan dari katakan PC Anda, yang melakukan scrub bersih secara berkala dari arsip, membuang versi sesuai kebijakan yang Anda tetapkan.

Borg Backup mendukung repositori jarak jauh yang hanya ditambahkan . Setiap kompromi dari server yang didukung dapat mengakibatkan hanya membuat cadangan baru, tidak hanya menimpa yang lama.

Solusi yang tidak terlalu menarik dalam situasi saya:

Pekerjaan cadangan tambahan pada host di luar kantor yang mentransfernya ke lokasi yang tidak dapat diakses oleh host pertama.

Masalah mendasarnya adalah jika Anda dapat mengakses cadangan dari jarak jauh maka peretas juga dapat melakukannya .

(Karena keterbatasan teknis)

Keterbatasan teknis dibuat untuk diatasi.

Adakah yang bisa memberikan saran tentang cara menerapkan cadangan luar kantor yang tepat untuk kasus saya?

Tape drive telah memberikan perlindungan yang aman dan di luar lokasi terhadap semua jenis bencana - termasuk peretas - selama hampir 70 tahun.

Anda dapat menggunakan layanan penyimpanan seperti AWS S3 (atau mungkin setara Google atau Azure) di mana Anda dapat memberikan izin PUT akun root Anda ke keranjang Anda, tetapi bukan izin DELETE. Dengan begitu, Anda bisa menggunakan model push dan penyerang tidak akan bisa menghapus cadangan.

Ada langkah-langkah keamanan lebih lanjut yang dapat Anda ambil dengan AWS, seperti mengharuskan MFA untuk melakukan DELETE pada bucket, tetapi mengizinkan PUT dan GET tanpa MFA. Dengan begitu, Anda dapat membuat cadangan data dan mengambilnya untuk memulihkan layanan tanpa menggunakan perangkat MFA, yang mungkin berguna dalam kasus yang ekstrem (dan mungkin terlalu tidak jelas untuk disebutkan) di mana mengakses perangkat MFA dapat membahayakannya.

Juga, komentar di luar ruang lingkup Anda mungkin menemukan menarik / berguna, ada beberapa cara untuk mengkonfigurasi S3 dan layanan serupa untuk failover otomatis jika sumber data utama sedang offline.

Cadangan Borg melalui SSH dengan otentikasi kunci. Masalah: koneksi ke server luar kantor itu dapat dilakukan dengan kunci yang menyimpan di host jika pengguna jahat memiliki akses root ke host.

Anda dapat menggunakan perintah opsi di otor_keys Anda. Anda memperbaiki perintah yang diizinkan di jarak jauh.

cara menambahkan perintah di ssh official_keys

Bahkan jika seorang penyerang memulihkan root login, ia tidak akan dapat melakukan apa pun selain perintah yang ditentukan.

Teknik yang dapat Anda atur adalah menggunakan sinkronisasi antara server Anda dan server cadangan jarak jauh, dan membiarkan server cadangan jarak jauh melakukan snapshot atau apa pun di ujungnya sehingga sisi server penghapusan tidak menghasilkan penghapusan di luar kantor.