Kontrol Keamanan: Perlindungan data

  • Artikel

Perlindungan Data mencakup kontrol perlindungan data saat tidak aktif, saat transit, dan melalui mekanisme akses resmi, termasuk menemukan, mengklasifikasikan, melindungi, dan memantau aset data sensitif menggunakan kontrol akses, enkripsi, manajemen kunci, dan manajemen sertifikat.|

DP-1: Menemukan, mengklasifikasikan, dan memberi label data sensitif

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

Prinsip keamanan: Menetapkan dan memelihara inventaris data sensitif, berdasarkan cakupan data sensitif yang ditentukan. Gunakan alat untuk menemukan, mengklasifikasikan, dan memberi label data sensitif dalam cakupan.

Panduan Azure: Gunakan alat seperti Microsoft Purview, yang menggabungkan solusi kepatuhan Azure Purview dan Microsoft 365 sebelumnya, dan Azure SQL Penemuan dan Klasifikasi Data untuk memindai, mengklasifikasikan, dan memberi label data sensitif secara terpusat yang berada di Azure, lokal, Microsoft 365, dan lokasi lainnya.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Replikasi data Anda dari berbagai sumber ke wadah penyimpanan S3 dan gunakan AWS Macie untuk memindai, mengklasifikasikan, dan memberi label data sensitif yang disimpan di wadah. AWS Macie dapat mendeteksi data sensitif seperti kredensial keamanan, informasi keuangan, data PHI dan PII, atau pola data lainnya berdasarkan aturan pengidentifikasi data kustom.

Anda juga dapat menggunakan konektor pemindaian multi-cloud Azure Purview untuk memindai, mengklasifikasikan, dan memberi label data sensitif yang berada di wadah penyimpanan S3.

Catatan: Anda juga dapat menggunakan solusi perusahaan pihak ketiga dari marketplace AWS untuk tujuan klasifikasi dan pelabelan penemuan data.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Gunakan alat seperti Pencegahan Kehilangan Data Google Cloud untuk memindai, mengklasifikasikan, dan memberi label data sensitif secara terpusat yang berada di lingkungan GCP dan lokal.

Selain itu, gunakan Google Cloud Data Catalog untuk menggunakan hasil pemindaian Cloud Data Loss Prevention (DLP) untuk mengidentifikasi data sensitif dengan templat tag yang ditentukan.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-2: Memantau anomali dan ancaman yang menargetkan data sensitif

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
3.13 AC-4, SI-4 A3.2

Prinsip keamanan: Pantau anomali sekeliling data sensitif, seperti transfer data yang tidak sah ke lokasi di luar visibilitas dan kontrol perusahaan. Ini biasanya melibatkan pemantauan untuk aktivitas anomali (transfer besar atau tidak biasa) yang dapat menunjukkan eksfiltrasi data yang tidak sah.

Panduan Azure: Gunakan perlindungan Informasi Azure (AIP) untuk memantau data yang telah diklasifikasikan dan diberi label.

Gunakan Microsoft Defender untuk Penyimpanan, Microsoft Defender untuk SQL, Microsoft Defender untuk database relasional sumber terbuka, dan Microsoft Defender untuk Cosmos DB untuk memperingatkan transfer informasi anomali yang mungkin menunjukkan transfer data sensitif yang tidak sah Informasi.

Catatan: Jika diperlukan untuk kepatuhan pencegahan kehilangan data (DLP), Anda dapat menggunakan solusi DLP berbasis host dari Marketplace Azure atau solusi Microsoft 365 DLP untuk menegakkan kontrol detektif dan/atau pencegahan untuk mencegah penyelundupan data.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Gunakan AWS Macie untuk memantau data yang telah diklasifikasikan dan diberi label, dan menggunakan GuardDuty untuk mendeteksi aktivitas anomali pada beberapa sumber daya (sumber daya S3, EC2, atau Kubernetes atau IAM). Temuan dan pemberitahuan dapat di-triase, dianalisis, dan dilacak menggunakan EventBridge dan diteruskan ke Microsoft Azure Sentinel atau Security Hub untuk agregasi dan pelacakan insiden.

Anda juga dapat menghubungkan akun AWS anda ke Microsoft Defender untuk Cloud untuk pemeriksaan kepatuhan, keamanan kontainer, dan kemampuan keamanan titik akhir.

Catatan: Jika diperlukan untuk kepatuhan pencegahan kehilangan data (DLP), Anda dapat menggunakan solusi DLP berbasis host dari AWS Marketplace.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Gunakan Google Cloud Security Command Center/Deteksi Ancaman Peristiwa/Deteksi Anomali untuk memberi tahu transfer informasi anomali yang mungkin menunjukkan transfer informasi data sensitif yang tidak sah.

Anda juga dapat menyambungkan akun GCP ke Microsoft Defender untuk Cloud untuk pemeriksaan kepatuhan, keamanan kontainer, dan kemampuan keamanan titik akhir.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-3: Mengenkripsi data sensitif saat transit

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Prinsip keamanan: Lindungi data saat transit dari serangan 'out of band' (seperti penangkapan lalu lintas) menggunakan enkripsi untuk memastikan bahwa penyerang tidak dapat dengan mudah membaca atau memodifikasi data.

Atur batas jaringan dan cakupan layanan di mana enkripsi data saat transit wajib baik di dalam dan di luar jaringan. Meskipun bersifat opsional untuk lalu lintas pada jaringan privat, ini sangat penting untuk lalu lintas di jaringan eksternal dan publik.

Panduan Azure: Menerapkan transfer aman dalam layanan seperti Azure Storage, di mana data asli dalam fitur enkripsi transit dibangun.

Terapkan HTTPS untuk beban kerja dan layanan aplikasi web dengan memastikan bahwa setiap klien yang terhubung ke sumber daya Azure Anda menggunakan keamanan lapisan transportasi (TLS) v1.2 atau yang lebih baru. Untuk manajemen jarak jauh, gunakan SSH (untuk Linux) atau RDP/TLS (untuk Windows) alih-alih protokol yang tidak terenkripsi.

Untuk manajemen jarak jauh komputer virtual Azure, gunakan SSH (untuk Linux) atau RDP/TLS (untuk Windows) alih-alih protokol yang tidak terenkripsi. Untuk transfer file yang aman, gunakan layanan SFTP/FTPS di Azure Storage Blob, aplikasi App Service, dan aplikasi Fungsi, alih-alih menggunakan layanan FTP reguler.

Catatan: Enkripsi data saat transit diaktifkan untuk semua lalu lintas Azure yang bepergian antar pusat data Azure. TLS v1.2 atau yang lebih baru diaktifkan di sebagian besar layanan Azure secara default. Dan beberapa layanan seperti Azure Storage dan Application Gateway dapat memberlakukan TLS v1.2 atau yang lebih baru di sisi server.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Terapkan transfer aman dalam layanan seperti Amazon S3, RDS, dan CloudFront, tempat data asli dalam fitur enkripsi transit dibangun.

Terapkan HTTPS (seperti di AWS Elastic Load Balancer) untuk aplikasi dan layanan web beban kerja (baik di sisi server atau sisi klien, atau keduanya) dengan memastikan bahwa setiap klien yang terhubung ke sumber daya AWS Anda menggunakan TLS v1.2 atau yang lebih baru.

Untuk manajemen jarak jauh instans EC2, gunakan SSH (untuk Linux) atau RDP/TLS (untuk Windows) alih-alih protokol yang tidak terenkripsi. Untuk transfer file yang aman, gunakan layanan AWS Transfer SFTP atau FTPS alih-alih layanan FTP reguler.

Catatan: Semua lalu lintas jaringan antara pusat data AWS dienkripsi secara transparan di lapisan fisik. Semua lalu lintas dalam VPC dan antara VPC yang di-peering di seluruh wilayah dienkripsi secara transparan di lapisan jaringan saat menggunakan jenis instans Amazon EC2 yang didukung. TLS v1.2 atau yang lebih baru diaktifkan di sebagian besar layanan AWS secara default. Dan beberapa layanan seperti AWS Load Balancer dapat memberlakukan TLS v1.2 atau yang lebih baru di sisi server.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Terapkan transfer aman dalam layanan seperti Google Cloud Storage, tempat data asli dalam fitur enkripsi transit dibangun.

Terapkan HTTPS untuk beban kerja dan layanan aplikasi web yang memastikan bahwa setiap klien yang terhubung ke sumber daya GCP Anda menggunakan keamanan lapisan transportasi (TLS) v1.2 atau yang lebih baru.

Untuk manajemen jarak jauh Google Cloud Compute Engine, gunakan SSH (untuk Linux) atau RDP/TLS (untuk Windows) alih-alih protokol yang tidak terenkripsi. Untuk transfer file yang aman, gunakan layanan SFTP/FTPS di layanan seperti Google Cloud Big Query atau Cloud App Engine, bukan layanan FTP biasa.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-4: Mengaktifkan enkripsi data tidak aktif secara default

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
3.11 SC-28 3.4, 3.5

Prinsip keamanan: Untuk melengkapi kontrol akses, data tidak aktif harus dilindungi dari serangan 'out of band' (seperti mengakses penyimpanan yang mendasarinya) menggunakan enkripsi. Perlindungan ini membantu memastikan bahwa penyerang tidak dapat dengan mudah membaca atau merubah data.

Panduan Azure: Banyak layanan Azure memiliki enkripsi data tidak aktif yang diaktifkan secara default di lapisan infrastruktur menggunakan kunci yang dikelola layanan. Kunci yang dikelola layanan ini dihasilkan atas nama pelanggan dan secara otomatis diputar setiap dua tahun.

Jika memungkinkan secara teknis dan tidak diaktifkan secara default, Anda dapat mengaktifkan enkripsi data tidak aktif di layanan Azure, atau di VM Anda di tingkat penyimpanan, tingkat file, atau tingkat database.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Banyak layanan AWS memiliki enkripsi data tidak aktif yang diaktifkan secara default di lapisan infrastruktur/platform menggunakan kunci master pelanggan yang dikelola AWS. Kunci master pelanggan yang dikelola AWS ini dihasilkan atas nama pelanggan dan diputar secara otomatis setiap tiga tahun.

Jika memungkinkan secara teknis dan tidak diaktifkan secara default, Anda dapat mengaktifkan enkripsi data tidak aktif di layanan AWS, atau di VM Anda di tingkat penyimpanan, tingkat file, atau tingkat database.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Banyak produk dan layanan Google Cloud memiliki enkripsi data tidak aktif yang diaktifkan secara default di lapisan infrastruktur menggunakan kunci yang dikelola layanan. Kunci yang dikelola layanan ini dihasilkan atas nama pelanggan dan diputar secara otomatis.

Jika secara teknis layak dan tidak diaktifkan secara default, Anda dapat mengaktifkan enkripsi data tidak aktif di layanan GCP, atau di VM Anda di tingkat penyimpanan, tingkat file, atau tingkat database.

Catatan: Lihat dokumen ""Granularitas enkripsi untuk layanan Google Cloud"" untuk detail tambahan.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-5: Menggunakan opsi kunci yang dikelola pelanggan dalam enkripsi data tidak aktif saat diperlukan

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
3.11 SC-12, SC-28 3.4, 3.5, 3.6

Prinsip keamanan: Jika diperlukan untuk kepatuhan terhadap peraturan, tentukan kasus penggunaan dan cakupan layanan di mana opsi kunci yang dikelola pelanggan diperlukan. Aktifkan dan terapkan enkripsi data tidak aktif menggunakan kunci yang dikelola pelanggan dalam layanan.

Panduan Azure: Azure juga menyediakan opsi enkripsi menggunakan kunci yang dikelola sendiri (kunci yang dikelola pelanggan) untuk sebagian besar layanan.

Azure Key Vault HSM Standar, Premium, dan Terkelola terintegrasi secara asli dengan banyak Layanan Azure untuk kasus penggunaan kunci yang dikelola pelanggan. Anda dapat menggunakan Azure Key Vault untuk menghasilkan kunci Anda atau membawa kunci Anda sendiri.

Namun, menggunakan opsi kunci yang dikelola pelanggan memerlukan upaya operasional tambahan untuk mengelola siklus hidup kunci. Ini mungkin termasuk pembuatan kunci enkripsi, rotasi, pencabutan, dan kontrol akses, dll.

Implementasi Azure dan konteks tambahan:

Panduan AWS: AWS juga menyediakan opsi enkripsi menggunakan kunci yang dikelola sendiri (kunci master pelanggan yang dikelola pelanggan yang disimpan di AWS Key Management Service) untuk layanan tertentu.

AWS Key Management Service (KMS) terintegrasi secara asli dengan banyak layanan AWS untuk kasus penggunaan kunci master pelanggan yang dikelola pelanggan. Anda dapat menggunakan AWS Key Management Service (KMS) untuk menghasilkan kunci master atau membawa kunci Anda sendiri.

Namun, menggunakan opsi kunci yang dikelola pelanggan memerlukan upaya operasional tambahan untuk mengelola siklus hidup kunci. Ini mungkin termasuk pembuatan kunci enkripsi, rotasi, pencabutan, dan kontrol akses, dll.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Google Cloud menyediakan opsi enkripsi menggunakan kunci yang dikelola sendiri (kunci yang dikelola pelanggan) untuk sebagian besar layanan.

Google Cloud Key Management Service (Cloud KMS) terintegrasi secara asli dengan banyak layanan GCP untuk kunci enkripsi yang dikelola pelanggan. Kunci ini dapat dibuat dan dikelola menggunakan Cloud KMS, dan Anda menyimpan kunci sebagai kunci perangkat lunak, dalam kluster HSM, atau secara eksternal. Anda dapat menggunakan Cloud KMS untuk menghasilkan kunci Anda atau menyediakan kunci Anda sendiri (kunci enkripsi yang disediakan pelanggan).

Namun, menggunakan opsi kunci yang dikelola pelanggan memerlukan upaya operasional tambahan untuk mengelola siklus hidup kunci. Ini mungkin termasuk pembuatan kunci enkripsi, rotasi, pencabutan, dan kontrol akses, dll.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-6: Menggunakan proses manajemen kunci yang aman

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
T/A IA-5, SC-12, SC-28 3.6+

Prinsip keamanan: Dokumentasikan dan terapkan standar, proses, dan prosedur manajemen kunci kriptografi perusahaan untuk mengontrol siklus hidup kunci Anda. Jika terdapat kebutuhan untuk menggunakan kunci yang dikelola pelanggan dalam layanan, gunakan layanan brankas kunci yang aman untuk pembuatan, distribusi, dan penyimpanan kunci. Putar dan cabut kunci Anda berdasarkan jadwal yang ditentukan dan ketika terdapat penyusupan atau penghentian kunci.

Panduan Azure: Gunakan Azure Key Vault untuk membuat dan mengontrol siklus hidup kunci enkripsi Anda, termasuk pembuatan kunci, distribusi, dan penyimpanan. Putar dan cabut kunci Anda di Azure Key Vault dan layanan Anda berdasarkan jadwal yang ditentukan dan ketika terdapat penyusupan atau penghentian kunci. Memerlukan jenis kriptografi tertentu dan ukuran kunci minimum saat menghasilkan kunci.

Ketika terdapat kebutuhan untuk menggunakan kunci yang dikelola pelanggan (CMK) dalam aplikasi atau layanan beban kerja, pastikan Anda mengikuti praktik terbaik:

  • Gunakan hierarki kunci untuk menghasilkan kunci enkripsi data (DEK) yang terpisah dengan kunci enkripsi kunci (KEK) di brankas kunci Anda.
  • Pastikan kunci terdaftar di Azure Key Vault dan diimplementasikan melalui ID kunci di setiap layanan atau aplikasi.

Untuk memaksimalkan masa pakai dan portabilitas material utama, bawa kunci Anda sendiri (BYOK) ke layanan (yaitu, mengimpor kunci yang dilindungi HSM dari HSM lokal Anda ke Azure Key Vault). Ikuti panduan yang direkomendasikan untuk melakukan pembuatan kunci dan transfer kunci.

Catatan: Lihat hal di bawah ini untuk tingkat FIPS 140-2 untuk jenis azure Key Vault dan tingkat kepatuhan/validasi FIPS.

  • Kunci yang dilindungi perangkat lunak dalam vault (Premium & Standard SKU): FIPS 140-2 Level 1
  • Kunci yang dilindungi HSM dalam brankas (Premium SKU): FIPS 140-2 Tingkat 2
  • Kunci yang dilindungi HSM di HSM Terkelola: FIPS 140-2 Tingkat 3

Azure Key Vault Premium menggunakan infrastruktur HSM bersama di backend. Azure Key Vault Managed HSM menggunakan titik akhir layanan rahasia khusus dengan HSM khusus saat Anda memerlukan tingkat keamanan kunci yang lebih tinggi.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Gunakan AWS Key Management Service (KMS) untuk membuat dan mengontrol siklus hidup kunci enkripsi Anda, termasuk pembuatan kunci, distribusi, dan penyimpanan. Putar dan cabut kunci Anda di KMS dan layanan Anda berdasarkan jadwal yang ditentukan dan ketika ada penghentian atau penyusupan kunci.

Ketika ada kebutuhan untuk menggunakan kunci master pelanggan yang dikelola pelanggan dalam layanan atau aplikasi beban kerja, pastikan Anda mengikuti praktik terbaik:

  • Gunakan hierarki kunci untuk menghasilkan kunci enkripsi data (DEK) terpisah dengan kunci enkripsi kunci (KEK) Anda di KMS Anda.
  • Pastikan kunci terdaftar di KMS dan terapkan melalui kebijakan IAM di setiap layanan atau aplikasi.

Untuk memaksimalkan masa pakai dan portabilitas material utama, bawa kunci Anda sendiri (BYOK) ke layanan (yaitu, mengimpor kunci yang dilindungi HSM dari HSM lokal Anda ke KMS atau Cloud HSM). Ikuti panduan yang direkomendasikan untuk melakukan pembuatan kunci dan transfer kunci.

Catatan: AWS KMS menggunakan infrastruktur HSM bersama di backend. Gunakan AWS KMS Custom Key Store yang didukung oleh AWS CloudHSM saat Anda perlu mengelola penyimpanan kunci dan HSM khusus Anda sendiri (misalnya persyaratan kepatuhan terhadap peraturan untuk tingkat keamanan kunci yang lebih tinggi) untuk menghasilkan dan menyimpan kunci enkripsi Anda.

Catatan: Lihat hal di bawah ini untuk tingkat FIPS 140-2 untuk tingkat kepatuhan FIPS di AWS KMS dan CloudHSM:

  • Default AWS KMS: FIPS 140-2 Level 2 divalidasi
  • AWS KMS menggunakan CloudHSM: FIPS 140-2 Level 3 (untuk layanan tertentu) divalidasi
  • AWS CloudHSM: FIPS 140-2 Level 3 divalidasi

Catatan: Untuk manajemen rahasia (kredensial, kata sandi, kunci API, dll.), gunakan AWS Secrets Manager.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Gunakan Cloud Key Management Service (Cloud KMS) untuk membuat dan mengelola siklus hidup kunci enkripsi di layanan Google Cloud yang kompatibel dan di aplikasi beban kerja Anda. Putar dan cabut kunci Anda di Cloud KMS dan layanan Anda berdasarkan jadwal yang ditentukan dan ketika ada penghentian atau penyusupan utama.

Gunakan layanan Cloud HSM Google untuk menyediakan kunci yang didukung perangkat keras ke Cloud KMS (Key Management Service) Ini memberi Anda kemampuan untuk mengelola dan menggunakan kunci kriptografi Anda sendiri sambil dilindungi oleh Modul Keamanan Perangkat Keras (HSM) yang dikelola sepenuhnya.

Layanan Cloud HSM menggunakan HSM, yang divalidasi FIPS 140-2 Level 3 dan selalu berjalan dalam mode FIPS. FIPS 140-2 Level 3 divalidasi dan selalu berjalan dalam mode FIPS. Standar FIPS menentukan algoritma kriptografi dan pembuatan angka acak yang digunakan oleh HSM.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-7: Menggunakan proses manajemen sertifikat yang aman

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
T/A IA-5, SC-12, SC-17 3.6+

Prinsip keamanan: Dokumentasikan dan terapkan standar manajemen sertifikat perusahaan, proses dan prosedur yang mencakup kontrol siklus hidup sertifikat, dan kebijakan sertifikat (jika infrastruktur kunci publik diperlukan).

Pastikan sertifikat yang digunakan oleh layanan penting dalam organisasi Anda diinventarisasi, dilacak, dipantau, dan diperbarui tepat waktu menggunakan mekanisme otomatis untuk menghindari gangguan layanan.

Panduan Azure: Gunakan Azure Key Vault untuk membuat dan mengontrol siklus hidup sertifikat, termasuk pembuatan/impor, rotasi, pencabutan, penyimpanan, dan penghapusan menyeluruh sertifikat. Pastikan pembuatan sertifikat mengikuti standar yang ditentukan tanpa menggunakan properti yang tidak aman, seperti ukuran kunci yang tidak mencukupi, masa berlaku yang terlalu lama, kriptografi yang tidak aman, dan sebagainya. Siapkan rotasi otomatis sertifikat di Azure Key Vault dan layanan Azure yang didukung berdasarkan jadwal yang ditentukan dan kapan sertifikat kedaluwarsa. Jika rotasi otomatis tidak didukung di aplikasi frontend, gunakan rotasi manual di Azure Key Vault.

Hindari menggunakan sertifikat yang ditandatangani sendiri dan sertifikat kartubebas di layanan penting Anda karena jaminan keamanan yang terbatas. Sebagai gantinya, Anda dapat membuat sertifikat yang ditandatangani publik di Azure Key Vault. Otoritas Sertifikat (CA) berikut adalah penyedia bermitra yang saat ini terintegrasi dengan Azure Key Vault.

  • DigiCert: Azure Key Vault menawarkan sertifikat OV TLS/SSL dengan DigiCert.
  • GlobalSign: Azure Key Vault menawarkan sertifikat OV TLS/SSL dengan GlobalSign.

Catatan: Gunakan hanya CA yang disetujui dan pastikan bahwa sertifikat akar/perantara buruk yang diketahui yang dikeluarkan oleh CA ini dinonaktifkan.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Gunakan AWS Certificate Manager (ACM) untuk membuat dan mengontrol siklus hidup sertifikat, termasuk pembuatan/impor, rotasi, pencabutan, penyimpanan, dan penghapusan menyeluruh sertifikat. Pastikan pembuatan sertifikat mengikuti standar yang ditentukan tanpa menggunakan properti yang tidak aman, seperti ukuran kunci yang tidak mencukupi, masa berlaku yang terlalu lama, kriptografi yang tidak aman, dan sebagainya. Siapkan rotasi otomatis sertifikat di ACM dan layanan AWS yang didukung berdasarkan jadwal yang ditentukan dan kapan sertifikat kedaluwarsa. Jika rotasi otomatis tidak didukung di aplikasi frontend, gunakan rotasi manual di ACM. Sementara itu, Anda harus selalu melacak status perpanjangan sertifikat Anda untuk memastikan validitas sertifikat.

Hindari menggunakan sertifikat yang ditandatangani sendiri dan sertifikat kartubebas di layanan penting Anda karena jaminan keamanan yang terbatas. Sebagai gantinya, buat sertifikat yang ditandatangani publik (ditandatangani oleh Amazon Certificate Authority) di ACM dan terapkan secara terprogram di layanan seperti CloudFront, Load Balancers, API Gateway, dll. Anda juga dapat menggunakan ACM untuk menetapkan otoritas sertifikat privat (CA) Anda untuk menandatangani sertifikat privat.

Catatan: Gunakan hanya CA yang disetujui dan pastikan bahwa sertifikat root/perantara CA buruk yang diketahui yang dikeluarkan oleh CA ini dinonaktifkan.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Gunakan Google Cloud Certificate Manager untuk membuat dan mengontrol siklus hidup sertifikat, termasuk pembuatan/impor, rotasi, pencabutan, penyimpanan, dan penghapusan menyeluruh sertifikat. Pastikan pembuatan sertifikat mengikuti standar yang ditentukan tanpa menggunakan properti yang tidak aman, seperti ukuran kunci yang tidak mencukupi, masa berlaku yang terlalu lama, kriptografi yang tidak aman, dan sebagainya. Siapkan rotasi otomatis sertifikat di Certificate Manager dan layanan GCP yang didukung berdasarkan jadwal yang ditentukan dan kapan sertifikat kedaluwarsa. Jika rotasi otomatis tidak didukung di aplikasi frontend, gunakan rotasi manual di Pengelola Sertifikat. Sementara itu, Anda harus selalu melacak status perpanjangan sertifikat Anda untuk memastikan validitas sertifikat.

Hindari menggunakan sertifikat yang ditandatangani sendiri dan sertifikat kartubebas di layanan penting Anda karena jaminan keamanan yang terbatas. Sebagai gantinya, Anda dapat membuat sertifikat publik yang ditandatangani di Certificate Manager dan menyebarkannya secara terprogram di layanan seperti Load Balancer dan Cloud DNS dll. Anda juga dapat menggunakan Layanan Otoritas Sertifikat untuk menetapkan otoritas sertifikat privat (CA) Anda untuk menandatangani sertifikat privat.

Catatan: Anda juga dapat menggunakan Google Cloud Secret Manager untuk menyimpan sertifikat TLS.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):

DP-8: Memastikan keamanan repositori sertifikat dan kunci

ID CIS Controls v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
T/A IA-5, SC-12, SC-17 3.6+

Prinsip keamanan: Pastikan keamanan layanan brankas kunci yang digunakan untuk kunci kriptografi dan manajemen siklus hidup sertifikat. Perkuat layanan brankas kunci Anda melalui kontrol akses, keamanan jaringan, pengelogan, dan pemantauan serta pencadangan untuk memastikan kunci dan sertifikat selalu dilindungi menggunakan keamanan yang maksimum.

Panduan Azure: Amankan kunci dan sertifikat kriptografi Anda dengan memperkuat layanan Azure Key Vault Anda melalui kontrol berikut:

  • Terapkan kontrol akses menggunakan kebijakan RBAC di Azure Key Vault Managed HSM pada tingkat kunci untuk memastikan hak istimewa paling sedikit dan pemisahan prinsip tugas diikuti. Misalnya, pastikan pemisahan tugas diberlakukan bagi pengguna yang mengelola kunci enkripsi sehingga mereka tidak memiliki kemampuan untuk mengakses data terenkripsi, dan sebaliknya. Untuk Azure Key Vault Standard dan Premium, buat vault unik untuk aplikasi yang berbeda untuk memastikan hak istimewa dan pemisahan prinsip tugas paling sedikit diikuti.
  • Aktifkan pengelogan Azure Key Vault untuk memastikan bidang manajemen penting dan aktivitas bidang data dicatat.
  • Amankan Key Vault Azure menggunakan Private Link dan Azure Firewall untuk memastikan paparan minimal layanan
  • Gunakan identitas terkelola untuk mengakses kunci yang disimpan di Azure Key Vault di aplikasi beban kerja Anda.
  • Saat membersihkan data, pastikan kunci Anda tidak dihapus sebelum data, cadangan, dan arsip yang sebenarnya dibersihkan.
  • Cadangkan kunci dan sertifikat Anda menggunakan Azure Key Vault. Aktifkan perlindungan penghapusan sementara dan penghapusan menyeluruh untuk menghindari penghapusan kunci yang tidak disengaja. Ketika kunci perlu dihapus, pertimbangkan untuk menonaktifkan kunci alih-alih menghapusnya untuk menghindari penghapusan kunci yang tidak disengaja dan penghapusan data kriptografi.
  • Untuk kasus penggunaan bring your own key (BYOK), hasilkan kunci di HSM lokal dan impor untuk memaksimalkan masa pakai dan portabilitas kunci.
  • Jangan pernah menyimpan kunci dalam format teks biasa di luar Key Vault Azure. Kunci di semua layanan brankas kunci tidak dapat diekspor secara default.
  • Gunakan jenis kunci yang didukung HSM (RSA-HSM) di Azure Key Vault Premium dan Azure Managed HSM untuk perlindungan perangkat keras dan tingkat FIPS terkuat.

Aktifkan Microsoft Defender untuk Key Vault guna mendapatkan perlindungan ancaman tingkat lanjut dan Azure-native bagi Azure Key Vault, dengan memberikan lapisan kecerdasan keamanan tambahan.

Implementasi Azure dan konteks tambahan:

Panduan AWS: Untuk keamanan kunci kriptografi, amankan kunci Anda dengan memperkuat layanan AWS Key Management Service (KMS) Anda melalui kontrol berikut:

  • Terapkan kontrol akses menggunakan kebijakan utama (kontrol akses tingkat kunci) bersama dengan kebijakan IAM (kontrol akses berbasis identitas) untuk memastikan hak istimewa paling sedikit dan pemisahan prinsip tugas diikuti. Misalnya, pastikan pemisahan tugas diberlakukan bagi pengguna yang mengelola kunci enkripsi sehingga mereka tidak memiliki kemampuan untuk mengakses data terenkripsi, dan sebaliknya.
  • Gunakan kontrol detektif seperti CloudTrails untuk mencatat dan melacak penggunaan kunci di KMS dan memberi tahu Anda tentang tindakan penting.
  • Jangan pernah menyimpan kunci dalam format teks biasa di luar KMS.
  • Ketika kunci perlu dihapus, pertimbangkan untuk menonaktifkan kunci di KMS alih-alih menghapusnya untuk menghindari penghapusan kunci dan penghapusan data yang tidak disengaja.
  • Saat membersihkan data, pastikan kunci Anda tidak dihapus sebelum data, cadangan, dan arsip yang sebenarnya dibersihkan.
  • Untuk kasus penggunaan bring your own key (BYOK), hasilkan kunci dalam HSM lokal dan impor untuk memaksimalkan masa pakai dan portabilitas kunci.

Untuk keamanan sertifikat, amankan sertifikat Anda dengan memperkuat layanan AWS Certificate Manager (ACM) Anda melalui kontrol berikut:

  • Terapkan kontrol akses menggunakan kebijakan tingkat sumber daya bersama dengan kebijakan IAM (kontrol akses berbasis identitas) untuk memastikan hak istimewa dan pemisahan prinsip tugas paling sedikit diikuti. Misalnya, pastikan pemisahan tugas diberlakukan untuk akun pengguna: akun pengguna yang menghasilkan sertifikat terpisah dari akun pengguna yang hanya memerlukan akses baca-saja ke sertifikat.
  • Gunakan kontrol detektif seperti CloudTrails untuk mencatat dan melacak penggunaan sertifikat di ACM, dan memberi tahu Anda tentang tindakan penting.
  • Ikuti panduan keamanan KMS untuk mengamankan kunci privat Anda (dibuat untuk permintaan sertifikat) yang digunakan untuk integrasi sertifikat layanan.

Implementasi AWS dan konteks tambahan:

Panduan GCP: Untuk keamanan kunci kriptografi, amankan kunci Anda dengan memperkuat Layanan Manajemen Kunci Anda melalui kontrol berikut:

  • Terapkan kontrol akses menggunakan peran IAM untuk memastikan hak istimewa paling sedikit dan pemisahan prinsip tugas diikuti. Misalnya, pastikan pemisahan tugas diberlakukan bagi pengguna yang mengelola kunci enkripsi sehingga mereka tidak memiliki kemampuan untuk mengakses data terenkripsi, dan sebaliknya.
  • Buat cincin kunci terpisah untuk setiap proyek yang memungkinkan Anda mengelola dan mengontrol akses ke kunci dengan mudah mengikuti praktik terbaik hak istimewa paling sedikit. Ini juga memudahkan untuk mengaudit siapa yang memiliki akses ke kunci mana pada saat.
  • Aktifkan rotasi kunci otomatis untuk memastikan kunci diperbarui dan disegarkan secara teratur. Ini membantu melindungi dari potensi ancaman keamanan seperti serangan brute force atau aktor jahat yang mencoba mendapatkan akses ke informasi sensitif.
  • Siapkan sink log audit untuk melacak semua aktivitas yang terjadi dalam lingkungan GCP KMS Anda.

Untuk keamanan sertifikat, amankan sertifikat Anda dengan memperkuat Pengelola Sertifikat GCP dan Certificate Authority Service Anda melalui kontrol berikut:

  • Terapkan kontrol akses menggunakan kebijakan tingkat sumber daya bersama dengan kebijakan IAM (kontrol akses berbasis identitas) untuk memastikan hak istimewa dan pemisahan prinsip tugas paling sedikit diikuti. Misalnya, pastikan pemisahan tugas diberlakukan untuk akun pengguna: akun pengguna yang menghasilkan sertifikat terpisah dari akun pengguna yang hanya memerlukan akses baca-saja ke sertifikat.
  • Gunakan kontrol detektif seperti Log Audit Cloud untuk mencatat dan melacak penggunaan sertifikat di Pengelola Sertifikat, dan memberi tahu Anda tentang tindakan penting.
  • Secret Manager juga mendukung penyimpanan sertifikat TLS. Anda perlu mengikuti praktik keamanan serupa untuk menerapkan kontrol keamanan di Secret Manager.

Implementasi GCP dan konteks tambahan:

Pemangku kepentingan keamanan pelanggan (Pelajari selengkapnya):