Praktik terbaik saat mengaktifkan enkripsi bergerak

Sebelum mengaktifkan enkripsi bergerak: pastikan Anda memiliki penanganan catatan DNS yang tepat

catatan

Kita akan mengubah dan menghapus titik akhir lama selama proses ini. Penggunaan titik akhir yang salah dapat mengakibatkan klien Redis OSS menggunakan titik akhir lama dan yang dihapus yang akan mencegahnya terhubung ke cluster.

Saat klaster sedang dimigrasikan dari mode tanpa TLS ke mode utamakan TLS, catatan DNS per simpul yang lama akan dipertahankan dan catatan DNS per simpul yang baru akan dihasilkan dalam format yang berbeda. Cluster yang mendukung TLS menggunakan format catatan DNS yang berbeda dari kluster yang tidak mendukung TLS. ElastiCache akan menyimpan kedua catatan DNS ketika cluster dikonfigurasi dalam mode enkripsi: Lebih disukai sehingga Aplikasi dan klien Redis OSS lainnya dapat beralih di antara mereka. Perubahan dalam catatan DNS berikut terjadi selama proses migrasi TLS:

Deskripsi perubahan dalam catatan DNS yang terjadi saat mengaktifkan enkripsi bergerak

Untuk klaster CME

Ketika sebuah klaster diatur ke 'mode enkripsi bergerak: pilihan':

• Titik akhir klaster asli untuk klaster non-TLS akan tetap aktif. Tidak akan ada waktu henti ketika klaster dikonfigurasi ulang dari mode enkripsi TLS 'tidak ada' ke 'diutamakan'.

• Titik akhir TLS Redis OSS baru akan dihasilkan saat cluster diatur ke mode pilihan TLS. Titik akhir baru ini akan diresolusi ke IP yang sama dengan yang lama (non-TLS).

• Titik akhir konfigurasi TLS Redis OSS yang baru akan diekspos di ElastiCache Konsol dan sebagai respons terhadap API. describe-replication-group

Ketika sebuah klaster diatur ke 'mode enkripsi bergerak: wajib':

• Titik akhir lama non-TLS akan dihapus. Tidak akan ada waktu henti pada titik akhir klaster TLS.

• Anda dapat mengambil yang baru cluster-configuration-endpoint dari ElastiCache Console atau dari describe-replication-group API.

Untuk klaster CMD dengan Failover Otomatis aktif atau Failover Otomatis nonaktif

Ketika grup replikasi diatur ke 'mode enkripsi bergerak: pilihan':

• Titik akhir primer asli dan titik akhir pembaca untuk klaster non-TLS akan tetap aktif.

• Titik akhir primer dan pembaca TLS baru akan dihasilkan saat klaster diatur ke mode TLS Preferred. Titik akhir baru ini akan diresolusi ke IP yang sama dengan yang lama (non-TLS).

• Titik akhir utama dan titik akhir pembaca yang baru akan diekspos di ElastiCache Konsol dan sebagai respons terhadap API. describe-replication-group

Ketika grup replikasi diatur ke 'mode enkripsi bergerak: wajib':

• Titik akhir primer dan pembaca non-TLS lama akan dihapus. Tidak akan ada waktu henti pada titik akhir klaster TLS.

• Anda dapat mengambil titik akhir primer dan pembaca baru dari ElastiCache Console atau dari API. describe-replication-group

Penggunaan catatan DNS yang disarankan

Untuk klaster CME

• Gunakan titik akhir konfigurasi klaster, bukan catatan DNS per simpul dalam kode aplikasi Anda. Penggunaan nama DNS per simpul secara langsung tidak disarankan karena nama DNS tersebut mungkin akan berubah saat menambahkan atau menghapus serpihan.

• Jangan melakukan hardcoding terhadap titik akhir konfigurasi klaster di aplikasi Anda karena titik akhir tersebut akan berubah selama proses ini.

• Memiliki titik akhir konfigurasi klaster yang di-hardcoding di aplikasi Anda adalah praktik yang buruk karena titik akhir tersebut dapat berubah selama proses ini. Setelah enkripsi bergerak selesai, kueri titik akhir konfigurasi klaster dengan API describe-replication-group (seperti yang ditunjukkan di atas (dalam cetak tebal)) dan selanjutnya, gunakan DNS yang Anda dapatkan dalam respons kueri ini.

Untuk klaster CMD dengan Failover Otomatis aktif

• Gunakan titik akhir primer dan titik akhir pembaca, bukan nama DNS per simpul dalam kode aplikasi Anda karena nama DNS per simpul yang lama dihapus dan yang baru akan dihasilkan saat memigrasikan klaster dari mode tanpa TLS ke mode TLS diutamakan. Penggunaan nama DNS per simpul secara langsung tidak direkomendasikan karena Anda mungkin akan menambahkan replika ke klaster Anda nanti. Selain itu, ketika Failover Otomatis diaktifkan, peran klaster utama dan replika diubah secara otomatis oleh ElastiCache layanan, menggunakan titik akhir utama dan titik akhir pembaca disarankan untuk membantu Anda melacak perubahan tersebut. Terakhir, menggunakan titik akhir pembaca akan membantu Anda mendistribusikan operasi baca Anda dari replika secara merata di antara replika di klaster.

• Memiliki titik akhir primer dan titik akhir pembaca yang di-hardcoding di aplikasi Anda adalah praktik yang buruk karena titik akhir tersebut dapat berubah selama proses migrasi TLS. Setelah perubahan migrasi ke pilihan TLS selesai, kueri titik akhir utama dan titik akhir pembaca dengan describe-replication-group API dan gunakan DNS yang Anda dapatkan sebagai tanggapan mulai saat ini. Dengan cara ini, Anda dapat melacak perubahan titik akhir secara dinamis.

Untuk klaster CMD dengan Failover Otomatis nonaktif

• Gunakan titik akhir primer dan titik akhir pembaca, bukan nama DNS per simpul dalam kode aplikasi Anda. Saat Failover Otomatis dinonaktifkan, penskalaan, penambalan, failover, dan prosedur lain yang dikelola secara otomatis oleh ElastiCache layanan saat Failover Otomatis diaktifkan akan dilakukan oleh Anda. Hal ini memudahkan Anda untuk melacak titik akhir yang berbeda-beda secara manual. Karena nama DNS per simpul yang lama dihapus dan yang baru akan dihasilkan saat memigrasikan klaster dari mode tanpa TLS ke mode TLS diutamakan, jangan gunakan nama DNS per simpul secara langsung. Hal ini wajib dilakukan agar klien dapat terhubung ke klaster selama migrasi TLS. Selain itu, Anda akan mendapatkan manfaat dengan menyebarkan permintaan baca secara merata di antara replika saat menggunakan titik akhir pembaca dan melacak catatan DNS saat menambahkan atau menghapus replika dari klaster.

• Memiliki titik akhir konfigurasi klaster yang di-hardcoding di aplikasi Anda adalah praktik yang buruk karena titik akhir tersebut dapat berubah selama proses migrasi TLS.

Selama enkripsi bergerak: perhatikan kapan proses migrasi selesai

Perubahan mode enkripsi bergerak tidak diterapkan segera dan dapat memakan waktu. Hal ini terutama berlaku untuk klaster besar. Hanya setelah menyelesaikan migrasi ke mode TLS diutamakan, klaster ini dapat menerima dan melayani koneksi TCP dan TLS. Oleh karena itu, Anda sebaiknya tidak membuat klien yang akan mencoba membuat koneksi TLS ke klaster sampai enkripsi bergerak selesai.

Ada beberapa cara untuk mendapatkan notifikasi ketika enkripsi bergerak berhasil diselesaikan atau gagal: (Tidak ditampilkan dalam contoh kode di atas):

• Menggunakan layanan SNS untuk mendapatkan notifikasi saat enkripsi selesai

• Menggunakan API describe-events yang akan memublikasikan peristiwa saat enkripsi selesai

• Melihat pesan di ElastiCache Konsol bahwa enkripsi selesai

Anda juga dapat menerapkan logika dalam aplikasi Anda untuk mengetahui apakah enkripsi selesai. Pada contoh di atas, kita melihat beberapa cara untuk memastikan klaster menyelesaikan migrasi:

• Menunggu hingga proses migrasi dimulai (status klaster berubah menjadi "mengubah"), dan menunggu hingga perubahan selesai (status klaster berubah kembali ke "tersedia")

• Memastikan bahwa klaster telah mengatur transit_encryption_enabled ke True dengan mengueri API describe-replication-group.

Setelah mengaktifkan enkripsi bergerak: pastikan klien yang Anda gunakan dikonfigurasi dengan benar

Saat klaster berada dalam mode TLS diutamakan, aplikasi Anda harus membuka koneksi TLS ke klaster dan hanya menggunakan koneksi tersebut. Dengan begitu, aplikasi Anda tidak akan mengalami waktu henti saat sedang mengaktifkan enkripsi bergerak. Anda dapat memastikan bahwa tidak ada koneksi TCP yang lebih jelas ke mesin Redis OSS menggunakan perintah info Redis OSS di bawah bagian SSL.

# SSL
ssl_enabled:yes
ssl_current_certificate_not_before_date:Mar 20 23:27:07 2017 GMT
ssl_current_certificate_not_after_date:Feb 24 23:27:07 2117 GMT
ssl_current_certificate_serial:D8C7DEA91E684163
tls_mode_connected_tcp_clients:0   (should be zero)
tls_mode_connected_tls_clients:100