Praktik terbaik saat mengaktifkan enkripsi bergerak - Amazon ElastiCache
Sebelum mengaktifkan enkripsi dalam transit: pastikan Anda memiliki penanganan catatan yang tepat DNSSelama enkripsi bergerak: perhatikan kapan proses migrasi selesai

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik saat mengaktifkan enkripsi bergerak

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

catatan

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

Sementara cluster sedang dimigrasikan dari no- TLS ke TLS -preferen, catatan per-node lama disimpan dan DNS catatan per-node DNS baru sedang dihasilkan dalam format yang berbeda. TLS-enabled cluster menggunakan format DNS rekaman yang berbeda dari cluster. non-TLS-enabled ElastiCache akan menyimpan kedua DNS catatan ketika cluster dikonfigurasi dalam mode enkripsi: Lebih disukai sehingga Aplikasi dan OSS klien Valkey atau Redis lainnya dapat beralih di antara mereka. Perubahan berikut dalam DNS catatan terjadi selama proses TLS -migrasi:

Deskripsi perubahan dalam DNS catatan yang terjadi saat mengaktifkan enkripsi dalam transit

Untuk CME cluster

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

  • Titik akhir cluster asli untuk cluster yang tidak TLS diaktifkan akan tetap aktif. Tidak akan ada downtime ketika cluster dikonfigurasi ulang mode TLS enkripsi formulir 'none' ke 'preferred'.

  • OSSTitik akhir TLS Valkey atau Redis baru akan dihasilkan saat cluster diatur ke TLS mode -preferen. Titik akhir baru ini akan menyelesaikan IPs sama dengan yang lama (non-TLS).

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

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

  • Endpoint lama yang tidak TLS diaktifkan akan dihapus. Tidak akan ada downtime dari titik akhir TLS cluster.

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

Untuk CMD cluster dengan Failover Otomatis diaktifkan atau Failover Otomatis dinonaktifkan

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

  • Titik akhir primer asli dan titik akhir pembaca untuk cluster yang tidak TLS diaktifkan akan tetap aktif.

  • Titik akhir TLS primer dan pembaca baru akan dihasilkan saat cluster diatur ke TLS Preferred mode. Titik akhir baru ini akan menyelesaikan 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. describe-replication-group API

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

  • Titik akhir TLS non-primer dan pembaca lama akan dihapus. Tidak akan ada downtime dari titik akhir TLS cluster.

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

Penggunaan DNS catatan yang disarankan

Untuk CME cluster

  • Gunakan endpoint konfigurasi cluster alih-alih DNS catatan per-node dalam kode aplikasi Anda. Menggunakan DNS nama per-node secara langsung tidak disarankan karena mereka mungkin berubah saat menambahkan atau menghapus pecahan.

  • 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 dalam transit selesai, kueri titik akhir konfigurasi cluster dengan describe-replication-group API (seperti yang ditunjukkan di atas (dalam huruf tebal)) dan gunakan jawaban yang DNS Anda dapatkan sejak saat ini.

Untuk CMD cluster dengan Failover Otomatis diaktifkan

  • Gunakan titik akhir utama dan titik akhir pembaca alih-alih nama per-node dalam kode aplikasi Anda karena DNS nama per-node DNS lama dihapus dan yang baru dihasilkan saat memigrasikan cluster dari no- ke -preferen. TLS TLS Menggunakan DNS nama per-node secara langsung tidak disarankan karena Anda dapat menambahkan replika ke cluster Anda di masa mendatang. 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 utama dan titik akhir pembaca yang di-hardcode dalam aplikasi Anda adalah praktik yang buruk karena dapat diubah selama proses migrasi. TLS Setelah perubahan migrasi ke TLS -preferen selesai, kueri titik akhir utama dan titik akhir pembaca dengan describe-replication-group API dan gunakan respons yang DNS Anda dapatkan sejak saat ini. Dengan cara ini, Anda dapat melacak perubahan titik akhir secara dinamis.

Untuk CMD cluster dengan Failover Otomatis dinonaktifkan

  • Gunakan endpoint utama dan endpoint pembaca alih-alih DNS nama per-node 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 DNS nama per-node lama dihapus dan yang baru dihasilkan saat memigrasikan cluster dari no- TLS ke TLS -preferred, jangan gunakan nama per-node secara langsung. DNS Ini wajib agar klien dapat terhubung ke cluster selama TLS -migrasi. Selain itu, Anda akan mendapat manfaat dari menyebarkan pembacaan secara merata di antara replika saat menggunakan titik akhir pembaca dan melacak DNS -record saat menambahkan atau menghapus replika dari cluster.

  • Memiliki endpoint konfigurasi cluster yang di-hardcode dalam aplikasi Anda adalah praktik yang buruk karena dapat diubah 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 ketika cluster menyelesaikan migrasi ke TLS -preferen, ia dapat menerima dan melayani keduanya TCP dan TLS koneksi. Oleh karena itu, Anda tidak boleh membuat klien yang akan mencoba membuat TLS koneksi ke cluster sampai enkripsi in-transit selesai.

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

  • Menggunakan SNS layanan untuk mendapatkan pemberitahuan ketika enkripsi selesai

  • Menggunakan describe-events API yang akan memancarkan peristiwa ketika 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")

  • Menegaskan bahwa cluster telah transit_encryption_enabled disetel ke True dengan menanyakan file. describe-replication-group API

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

Saat cluster berada dalam mode TLS -preferen, aplikasi Anda harus membuka TLS koneksi ke cluster 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 TCP koneksi yang lebih jelas ke OSS mesin Valkey atau Redis menggunakan perintah info 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