MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Enkripsi Cadangan Basis Data - Praktik Terbaik

Penyimpanan cadangan di luar lokasi harus menjadi bagian penting dari rencana pemulihan bencana organisasi mana pun. Kemampuan untuk menyimpan data di lokasi fisik yang terpisah, yang dapat bertahan dari peristiwa bencana yang menghancurkan semua data di pusat data utama Anda, memastikan kelangsungan data dan kelangsungan organisasi Anda. Layanan penyimpanan Cloud adalah metode yang cukup baik untuk menyimpan cadangan di luar kantor. Tidak masalah jika Anda menggunakan penyedia cloud atau jika Anda hanya menyalin data ke pusat data eksternal, enkripsi cadangan adalah suatu keharusan dalam kasus seperti itu. Di salah satu blog kami sebelumnya, kami membahas beberapa metode mengenkripsi cadangan Anda. Hari ini kita akan fokus pada beberapa praktik terbaik seputar enkripsi cadangan.

Pastikan Rahasia Anda Aman

Untuk mengenkripsi dan mendekripsi data Anda, Anda harus menggunakan semacam kata sandi atau kunci. Tergantung pada metode enkripsi (simetris atau asimetris), itu bisa menjadi satu rahasia untuk enkripsi dan dekripsi atau bisa menjadi kunci publik untuk enkripsi dan kunci pribadi untuk dekripsi. Yang penting, Anda harus menyimpannya dengan aman. Jika Anda menggunakan enkripsi asimetris, Anda harus fokus pada kunci pribadi, yang akan Anda gunakan untuk mendekripsi cadangan.

Anda dapat menyimpan kunci dalam sistem manajemen kunci atau brankas - ada banyak opsi di pasar untuk dipilih seperti KMS Amazon atau Gudang Hashicorp. Bahkan jika Anda memutuskan untuk tidak menggunakan solusi tersebut, Anda tetap harus menerapkan praktik keamanan umum seperti memastikan bahwa hanya pengguna yang benar yang dapat mengakses kunci dan kata sandi Anda. Anda juga harus mempertimbangkan untuk menyiapkan skrip cadangan Anda sedemikian rupa sehingga Anda tidak akan mengekspos kunci atau kata sandi dalam daftar proses yang sedang berjalan. Idealnya, letakkan mereka di file alih-alih meneruskannya sebagai argumen untuk beberapa perintah.

Pertimbangkan Enkripsi Asimetris

Perbedaan utama antara enkripsi simetris dan asimetris adalah bahwa saat menggunakan enkripsi simetris untuk enkripsi dan dekripsi, Anda menggunakan satu kunci atau kata sandi. Ini membutuhkan standar keamanan yang lebih tinggi di kedua ujung proses. Anda harus memastikan bahwa host tempat Anda mengenkripsi data sangat aman karena kebocoran kunci enkripsi simetris akan memungkinkan akses ke semua cadangan terenkripsi Anda.

Di sisi lain, jika Anda menggunakan enkripsi asimetris, Anda memiliki dua kunci:kunci publik untuk mengenkripsi data dan kunci pribadi untuk dekripsi. Ini membuat segalanya jauh lebih mudah - Anda tidak perlu terlalu peduli dengan kunci publik. Bahkan jika itu akan dikompromikan, itu masih tidak akan mengizinkan segala jenis akses ke data dari cadangan. Anda harus fokus pada keamanan kunci pribadi saja. Lebih mudah - Anda kemungkinan besar mengenkripsi cadangan setiap hari (jika tidak lebih sering) sementara pemulihan terjadi dari waktu ke waktu, sehingga memungkinkan untuk menyimpan kunci pribadi di lokasi yang lebih aman (bahkan pada perangkat fisik khusus). Di bawah ini adalah contoh yang sangat cepat tentang bagaimana Anda dapat menggunakan gpg untuk menghasilkan pasangan kunci dan menggunakannya untuk mengenkripsi data.

Pertama, Anda harus membuat kunci:

[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <[email protected]>"

Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
    "Krzysztof Ksiazek (Backup key) <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

Ini menciptakan kunci publik dan pribadi. Selanjutnya, Anda ingin mengekspor kunci publik untuk digunakan mengenkripsi data:

gpg --armor --export [email protected] > mybackupkey.asc

Selanjutnya, Anda dapat menggunakannya untuk mengenkripsi cadangan Anda.

[email protected]:~# xtrabackup  --backup --stream=xbstream  | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backup

Terakhir, contoh bagaimana Anda dapat menggunakan kunci utama Anda (dalam hal ini disimpan di gantungan kunci lokal) untuk mendekripsi cadangan Anda:

[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5

You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)

gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
      "Krzysztof Ksiazek (Backup key) <[email protected]>"

Putar kunci Enkripsi Anda

Apa pun jenis enkripsi yang Anda terapkan, simetris atau asimetris, Anda harus memikirkan rotasi kunci. Pertama-tama, sangat penting untuk memiliki mekanisme untuk memutar kunci. Ini mungkin berguna jika terjadi pelanggaran keamanan, dan Anda harus segera mengubah kunci yang Anda gunakan untuk enkripsi dan dekripsi cadangan. Tentu saja, jika terjadi pelanggaran keamanan, Anda perlu mempertimbangkan apa yang akan terjadi dengan cadangan lama yang dienkripsi menggunakan kunci yang disusupi. Mereka telah disusupi meskipun mungkin masih berguna dan diperlukan sesuai Tujuan Titik Pemulihan. Ada beberapa opsi termasuk mengenkripsi ulang atau memindahkannya ke pelokalan tanpa kompromi.

Mempercepat Proses Enkripsi dengan Memparalelkannya

Jika Anda memiliki opsi untuk menerapkan paralelisasi proses enkripsi, pertimbangkan itu. Kinerja enkripsi sebagian besar bergantung pada daya CPU, sehingga memungkinkan lebih banyak inti CPU untuk bekerja secara paralel untuk mengenkripsi file akan menghasilkan waktu enkripsi yang jauh lebih kecil. Beberapa alat enkripsi memberikan opsi seperti itu. Salah satunya adalah xtrabackup yang memiliki opsi untuk menggunakan enkripsi tertanam dan memparalelkan prosesnya.

Apa yang Anda cari adalah opsi “--encrypt-key” atau “--encrypt-key-file” yang memungkinkan enkripsi tersemat. Saat melakukan itu, Anda juga dapat mendefinisikan "--encrypt-threads" dan "--encrypt-chunk-size". Kedua meningkatkan buffer kerja untuk enkripsi, pertama menentukan berapa banyak utas yang harus digunakan untuk enkripsi.

Tentu saja, ini hanyalah salah satu solusi yang dapat Anda terapkan. Anda dapat mencapai ini menggunakan alat shell. Contoh di bawah ini:

[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream  |split -b 60M - backup ; ls backup* |  parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl  enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'

Ini sama sekali bukan solusi sempurna karena Anda harus tahu sebelumnya seberapa besar, lebih atau kurang, cadangan akan dibagi ke jumlah file yang telah ditentukan sebelumnya yang cocok dengan tingkat paralelisasi yang ingin Anda capai (jika Anda ingin menggunakan 2 CPU core, Anda harus memiliki dua file, jika Anda ingin menggunakan 4 core, 4 file, dll). Ini juga membutuhkan ruang disk yang dua kali ukuran cadangan, karena pada awalnya menghasilkan banyak file menggunakan split dan kemudian enkripsi membuat kumpulan file terenkripsi lainnya. Di sisi lain, jika ukuran kumpulan data Anda dapat diterima dan Anda ingin meningkatkan kinerja enkripsi, itu adalah opsi yang dapat Anda pertimbangkan. Untuk mendekripsi cadangan, Anda harus mendekripsi setiap file individual dan kemudian menggunakan 'cat' untuk menggabungkannya.

Uji Cadangan Anda

Tidak peduli bagaimana Anda akan menerapkan enkripsi cadangan, Anda harus mengujinya. Pertama-tama, semua cadangan harus diuji, dienkripsi atau tidak. Pencadangan mungkin tidak lengkap, atau mungkin mengalami beberapa jenis kerusakan. Anda tidak dapat memastikan bahwa cadangan Anda dapat dipulihkan sampai Anda benar-benar melakukan pemulihan. Itu sebabnya verifikasi cadangan reguler adalah suatu keharusan. Enkripsi menambahkan lebih banyak kerumitan pada proses pencadangan. Masalah mungkin muncul pada waktu enkripsi, sekali lagi - bug atau gangguan dapat merusak file yang dienkripsi. Setelah dienkripsi, pertanyaannya adalah apakah mungkin untuk mendekripsi dan memulihkannya?

Anda harus memiliki proses pengujian pemulihan. Idealnya, uji pemulihan akan dijalankan setelah setiap pencadangan. Minimal, Anda harus menguji cadangan Anda beberapa kali per tahun. Jelas Anda harus mengujinya segera setelah perubahan dalam proses pencadangan telah diperkenalkan. Sudahkah Anda menambahkan kompresi ke cadangan? Apakah Anda mengubah metode enkripsi? Apakah Anda memutar kunci enkripsi? Semua tindakan tersebut mungkin berdampak pada kemampuan Anda untuk benar-benar memulihkan cadangan Anda. Oleh karena itu, Anda harus memastikan bahwa Anda menguji seluruh proses setelah setiap perubahan.

ClusterControl dapat mengotomatiskan proses verifikasi, baik sesuai permintaan atau terjadwal setelah setiap pencadangan.

Untuk memverifikasi cadangan yang ada, Anda hanya perlu memilih salah satu dari daftar, klik opsi "Pulihkan" dan kemudian melalui wizard pemulihan. Pertama, Anda perlu memverifikasi cadangan mana yang ingin Anda pulihkan.

Kemudian, pada langkah berikutnya, Anda harus memilih opsi pulihkan dan verifikasi.

Anda harus memberikan beberapa informasi tentang host yang ingin Anda uji pemulihannya. Itu harus dapat diakses melalui SSH dari instance ClusterControl. Anda dapat memutuskan untuk tetap mengaktifkan dan menjalankan server uji pemulihan (lalu membuang sebagian data dari server tersebut jika Anda ingin melakukan pemulihan sebagian) atau mematikannya.

Langkah terakhir adalah tentang memverifikasi apakah Anda membuat pilihan yang benar. Jika ya, Anda dapat memulai tugas verifikasi cadangan.

Jika verifikasi berhasil diselesaikan, Anda akan melihat bahwa cadangan ditandai sebagai terverifikasi pada daftar cadangan.

Jika Anda ingin mengotomatiskan proses ini, itu juga dimungkinkan dengan ClusterControl. Saat menjadwalkan pencadangan, Anda dapat mengaktifkan verifikasi pencadangan:

Ini menambahkan langkah lain dalam wizard penjadwalan pencadangan.

Di sini Anda sekali lagi harus menentukan host yang ingin Anda gunakan untuk tes pemulihan cadangan, memutuskan apakah Anda ingin menginstal perangkat lunak di dalamnya (atau mungkin Anda sudah melakukannya), jika Anda ingin mempertahankan server pemulihan dan apakah Anda ingin menguji cadangan segera setelah selesai atau mungkin Anda ingin menunggu sebentar.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Otomasi Basis Data di Balik Identitas Elektronik Baru Swedia Freja eID

  2. Memahami Granularitas Kunci di MySQL

  3. Cara Mencadangkan Basis Data MariaDB Moodle Anda

  4. Praktik Terbaik dalam Penskalaan Basis Data:Bagian Kedua

  5. MariaDB CONNECTION_ID() Dijelaskan