Mengamankan data dalam kluster yang diatur AKS untuk PCI-DSS 3.2.1 (Bagian 4 dari 9)

Artikel ini menjelaskan pertimbangan untuk kluster Azure Kubernetes Service (AKS) yang menjalankan beban kerja sesuai dengan Standar Keamanan Data Industri Kartu Pembayaran (PCI-DSS 3.2.1).

Artikel ini adalah bagian dari beberapa seri. Baca pengantar.

Arsitektur dan implementasi ini difokuskan pada infrastruktur dan bukan beban kerja. Artikel ini memberikan pertimbangan umum dan praktik terbaik untuk membantu Anda membuat keputusan desain. Ikuti persyaratan dalam standar PCI-DSS 3.2.1 resmi dan gunakan artikel ini sebagai informasi tambahan, jika berlaku.

Lindungi data pemegang kartu

Persyaratan 3—Melindungi data pemegang kartu yang tersimpan

Tanggung jawab

Persyaratan 3.1

Pertahankan agar penyimpanan data pemegang kartu seminimal mungkin dengan menerapkan kebijakan, prosedur, dan proses retensi dan pembuangan data yang mencakup setidaknya hal berikut untuk semua penyimpanan data pemegang kartu (CHD):

• Batasi jumlah penyimpanan data dan waktu retensi yang diperlukan untuk persyaratan hukum, peraturan, dan bisnis
• Proses untuk penghapusan data yang aman saat tidak lagi diperlukan
• Persyaratan retensi khusus untuk data pemegang kartu
• Proses triwulanan untuk mengidentifikasi dan dengan aman menghapus data pemegang kartu yang disimpan yang melebihi retensi yang ditentukan.

Tanggung jawab

Jangan simpan status di kluster AKS. Jika Anda memilih untuk menyimpan CHD, jelajahi opsi penyimpanan yang aman. Opsi termasuk Azure Storage untuk penyimpanan file, atau database seperti Azure SQL Database atau Azure Cosmos DB.

Patuhi dengan ketat panduan standar tentang jenis CHD yang dapat disimpan. Tetapkan kebijakan retensi data berdasarkan persyaratan bisnis Anda dan jenis penyimpanan yang digunakan. Beberapa pertimbangan utama adalah:

• Bagaimana dan di mana data disimpan?
• Apakah data yang disimpan dienkripsi?
• Berapa periode retensinya?
• Tindakan apa yang diizinkan selama periode retensi?
• Bagaimana cara Anda menghapus data yang disimpan setelah periode penyimpanan berakhir?

Miliki kebijakan pemerintahan seputar beberapa pilihan tersebut. Azure Policy bawaan menerapkan pilihan tersebut. Misalnya, Anda dapat membatasi jenis volume pada pod kluster atau menolak operasi penulisan pada sistem file akar.

Tinjau daftar definisi kebijakan ini dan terapkan ke kluster, jika berlaku.

Anda mungkin perlu men-cache data untuk sementara. Kami menyarankan Anda untuk melindungi data yang di-cache saat dipindahkan ke solusi penyimpanan. Pertimbangkan untuk mengaktifkan fitur enkripsi berbasis host di AKS. Tindakan ini akan mengenkripsi data yang disimpan di VM node. Untuk informasi selengkapnya, lihat Enkripsi berbasis host di Azure Kubernetes Service (AKS). Selain itu, aktifkan kebijakan Azure bawaan yang memerlukan enkripsi disk sementara dan cache untuk kumpulan node.

Saat Anda memilih teknologi penyimpanan, jelajahi fitur retensi. Misalnya, Azure Blob Storage menyediakan kebijakan retensi berbasis waktu. Pilihan lainnya adalah mengimplementasikan solusi kustom yang menghapus data sesuai dengan kebijakan retensi. Contohnya adalah Data Lifecycle Management (DLM), yang mengelola aktivitas siklus hidup data. Solusi ini telah dirancang dengan layanan seperti Azure Data Factory, MICROSOFT Entra ID, dan Azure Key Vault.

Untuk informasi selengkapnya, lihat Mengelola siklus hidup data menggunakan Azure Data Factory.

Persyaratan 3.2

Jangan menyimpan data autentikasi sensitif setelah otorisasi (bahkan jika dienkripsi). Jika data autentikasi sensitif diterima, buat semua data tidak dapat dipulihkan setelah menyelesaikan proses otorisasi.

Tanggung jawab

(BERLAKU UNTUK: Persyaratan 3.2.1, Persyaratan 3.2.2, Persyaratan 3.2.3)

Memproses dan melindungi data adalah masalah beban kerja dan berada di luar cakupan arsitektur ini. Berikut adalah beberapa pertimbangan umum.

Sesuai standar, data autentikasi sensitif terdiri dari data trek lengkap, nilai atau kode validasi kartu, dan data PIN. Sebagai bagian dari pemrosesan CHD, pastikan bahwa data autentikasi tidak diekspos di sumber seperti:

• Log yang dikeluarkan dari pod.
• Rutinitas penanganan pengecualian.
• Nama file.
• Cache.

Sebagai panduan umum, pedagang tidak boleh menyimpan informasi ini. Jika diperlukan, dokumentasikan pertimbangan bisnis.

Persyaratan 3.3

Sembunyikan PAN saat ditampilkan (enam digit pertama dan empat digit terakhir adalah jumlah digit maksimum yang akan ditampilkan), sehingga hanya personel dengan kebutuhan bisnis yang sah yang dapat melihat PAN lengkap.

Tanggung jawab

Nomor rekening utama (PAN) dianggap sebagai data sensitif, dan eksposur terhadap data ini harus dicegah. Salah satu caranya adalah dengan mengurangi digit yang ditampilkan melalui penyembunyian.

Jangan mengimplementasikan penyembunyian data dalam beban kerja. Sebagai gantinya, gunakan konstruksi tingkat database. Lini layanan Azure SQL, termasuk Azure Synapse Analytics, mendukung penyembunyian data dinamis, yang mengurangi eksposur pada lapisan aplikasi. Ini adalah fitur keamanan berbasis kebijakan yang menentukan siapa yang dapat melihat data yang tidak disembunyikan dan berapa banyak data yang diekspos melalui penyembunyian. Metode penyembunyian Kartu kredit bawaan mengekspos empat digit terakhir dari bidang yang ditentukan dan menambahkan string konstan sebagai awalan dalam bentuk kartu kredit.

Untuk informasi selengkapnya, lihat Penyembunyian data dinamis.

Jika Anda memang perlu memasukkan data yang tidak disembunyikan ke dalam kluster, sembunyikan sesegera mungkin.

Persyaratan 3.4

Membuat PAN tidak dapat dibaca di mana pun PAN disimpan (termasuk di media digital portabel, media cadangan, dan dalam log) menggunakan salah satu pendekatan berikut:

• Hash satu arah berdasarkan kriptografi yang kuat, (hash harus dari seluruh PAN)
• Pemotongan (hashing tidak dapat digunakan untuk menggantikan segmen PAN yang terpotong)
• Token indeks dan pad (pad harus disimpan dengan aman)
• Kriptografi yang kuat dengan proses dan prosedur manajemen kunci terkait.

Tanggung jawab

Untuk persyaratan ini, Anda mungkin perlu menggunakan kriptografi langsung dalam beban kerja. Panduan PCI DSS merekomendasikan penggunaan algoritma yang telah teruji di industri agar dapat bertahan dari serangan di dunia nyata. Hindari penggunaan algoritma enkripsi kustom.

Teknik penyembunyian data yang tepat juga memenuhi persyaratan ini. Anda bertanggung jawab untuk menyembunyikan semua data nomor rekening utama (PAN). Lini layanan Azure SQL, termasuk Azure Synapse Analytics, mendukung penyembunyian data dinamis. Lihat Persyaratan 3.3.

Pastikan PAN tidak terekspos sebagai bagian dari proses alur kerja Anda. Berikut adalah beberapa pertimbangan:

• Jauhkan PAN dari log, baik log alur kerja dan log penanganan pengecualian (yang terduga atau tidak terduga). Selain itu, aliran data diagnostik, seperti header HTTP, tidak boleh mengekspos data ini.

• Jangan gunakan PAN sebagai kunci pencarian cache atau sebagai bagian dari nama file apa pun yang dihasilkan oleh proses ini.

• Pelanggan Anda mungkin memberikan PAN di bidang teks bentuk bebas tanpa diminta. Pastikan bahwa validasi konten dan proses deteksi tersedia untuk semua bidang teks bentuk bebas, yang menghapus semua konten yang menyerupai data PAN.

Persyaratan 3.4.1

Jika enkripsi disk digunakan (bukan enkripsi database tingkat file atau kolom), akses logis harus dikelola secara terpisah dan independen dari autentikasi sistem operasi native dan mekanisme kontrol akses (misalnya, dengan tidak menggunakan database akun pengguna lokal atau info masuk jaringan umum). Kunci dekripsi tidak boleh dikaitkan dengan akun pengguna.

Tanggung jawab

Sebagai aturan umum, jangan simpan status di kluster AKS. Gunakan penyimpanan data eksternal yang mendukung enkripsi tingkat mesin penyimpanan.

Semua data yang tersimpan di Azure Storage dienkripsi dan didekripsi dengan menggunakan kriptografi yang kuat. Microsoft mengelola kunci terkait. Kunci enkripsi yang dikelola sendiri lebih disukai. Selalu lakukan enkripsi di luar lapisan penyimpanan dan hanya tulis data terenkripsi ke dalam media penyimpanan, untuk memastikan bahwa kunci tidak pernah berdekatan dengan lapisan penyimpanan.

Dengan Azure Storage, Anda juga dapat menggunakan kunci yang dikelola sendiri. Untuk detailnya, lihat Kunci yang dikelola pelanggan untuk enkripsi Azure Storage.

Kemampuan serupa tersedia untuk database. Untuk opsi Azure SQL, lihat Enkripsi Data Transparan Azure SQL dengan kunci yang dikelola pelanggan.

Pastikan Anda menyimpan kunci di penyimpanan kunci terkelola seperti Azure Key Vault, Azure Managed HSM, atau solusi manajemen kunci pihak ketiga.

Jika Anda perlu menyimpan data untuk sementara, aktifkan fitur enkripsi host AKS untuk memastikan bahwa data yang disimpan di node VM dienkripsi.

Persyaratan 3.5

Dokumentasikan dan terapkan prosedur untuk melindungi kunci yang digunakan untuk mengamankan data pemegang kartu tersimpan dari pengungkapan dan penyalahgunaan.

Tanggung jawab

Poin-poin ini dijelaskan dalam subbagian:

• Pertahankan praktik akses dengan hak istimewa paling sedikit untuk kunci kriptografi.
• Azure Key Vault dan ID Microsoft Entra dirancang untuk mendukung persyaratan otorisasi dan pengelogan audit. Untuk detailnya, lihat Meminta autentikasi untuk Azure Key Vault.
• Lindungi semua kunci enkripsi data dengan kunci enkripsi kunci yang disimpan di perangkat kriptografi.
• Jika Anda menggunakan kunci yang dikelola sendiri (bukan kunci yang dikelola Microsoft), miliki proses dan dokumentasi untuk mempertahankan tugas yang terkait dengan manajemen kunci.

Persyaratan 3.5.1

Persyaratan tambahan hanya untuk penyedia layanan: Pertahankan deskripsi terdokumentasi tentang arsitektur kriptografi yang mencakup:

• Detail semua algoritma, protokol, dan kunci yang digunakan untuk melindungi data pemegang kartu, termasuk kekuatan kunci dan tanggal kedaluwarsa
• Deskripsi penggunaan kunci untuk setiap kunci
• Inventaris setiap HSM dan SCD lain yang digunakan untuk manajemen kunci

Tanggung jawab

Salah satu cara untuk menyimpan informasi sensitif (kunci, string koneksi, dan lainnya) adalah dengan menggunakan sumber daya native Kubernetes Secret. Anda harus secara eksplisit mengaktifkan enkripsi saat istirahat. Atau, simpan di penyimpanan terkelola seperti Azure Key Vault. Dari kedua pendekatan tersebut, sebaiknya gunakan layanan penyimpanan terkelola. Salah satu keuntungannya adalah pengurangan overhead dalam tugas-tugas yang terkait dengan manajemen kunci, seperti rotasi kunci.

Secara default, Azure menggunakan kunci yang dikelola Microsoft untuk semua data terenkripsi, per pelanggan. Namun, beberapa layanan juga mendukung kunci yang dikelola sendiri untuk enkripsi. Jika Anda menggunakan kunci yang dikelola sendiri untuk enkripsi saat tidak aktif, pastikan Anda memperhitungkan proses dan strategi yang menangani tugas manajemen kunci.

Sebagai bagian dari dokumentasi Anda, sertakan informasi yang terkait dengan manajemen kunci seperti detail rencana pemeliharaan, kedaluwarsa, dan lokasi.

Persyaratan 3.5.2

Batasi akses ke kunci kriptografi ke jumlah penjaga paling sedikit yang diperlukan.

Tanggung jawab

Minimalkan jumlah orang yang memiliki akses ke kunci. Jika Anda menggunakan penetapan peran berbasis grup, siapkan proses audit berulang untuk meninjau peran yang memiliki akses. Saat anggota tim proyek berubah, akun yang tidak lagi relevan harus dihapus dari izin. Hanya orang yang tepat yang boleh memiliki akses. Gunakan tinjauan akses ID Microsoft Entra untuk meninjau keanggotaan grup secara teratur.

Pertimbangkan untuk menghapus izin tetap demi penetapan peran just-in-time (JIT), aktivasi peran berbasis waktu, dan aktivasi peran berbasis persetujuan. Misalnya, pertimbangkan untuk menggunakan Privileged Identity Management.

Persyaratan 3.5.3

Simpan kunci privat dan rahasia yang digunakan untuk mengenkripsi/mendekripsi data pemegang kartu dalam satu (atau lebih) bentuk berikut setiap saat:

• Dienkripsi dengan kunci enkripsi kunci yang setidaknya sekuat kunci enkripsi data, dan yang disimpan secara terpisah dari kunci enkripsi data
• Dalam perangkat kriptografi yang aman (seperti modul keamanan perangkat keras (host) (HSM) atau perangkat titik interaksi yang disetujui PTS)
• Sebagai setidaknya dua komponen kunci penuh atau bagian kunci, sesuai dengan metode yang diterima industri

Tanggung jawab

Beban kerja PCI-DSS 3.2.1 perlu menggunakan lebih dari satu kunci enkripsi sebagai bagian dari strategi perlindungan data tidak aktif. Kunci enkripsi data (DEK) digunakan untuk mengenkripsi dan mendekripsi CHD, tetapi Anda bertanggung jawab atas kunci enkripsi kunci (KEK) tambahan untuk melindungi DEK tersebut. Anda juga bertanggung jawab untuk memastikan bahwa KEK disimpan dalam perangkat kriptografi.

Anda dapat menggunakan Azure Key Vault untuk menyimpan DEK dan menggunakan Azure Dedicated HSM untuk menyimpan KEK. Untuk informasi tentang manajemen kunci HSM, lihat Apa itu Azure Dedicated HSM?.

Persyaratan 3.6

Dokumentasikan dan implementasikan sepenuhnya semua proses dan prosedur manajemen kunci untuk kunci kriptografi yang digunakan dalam enkripsi data pemegang kartu, termasuk yang berikut:

Tanggung jawab

(BERLAKU UNTUK: Persyaratan 3.6.1, Persyaratan 3.6.2, Persyaratan 3.6.3, Persyaratan 3.2.4)

Jika Anda menggunakan Azure Key Vault untuk menyimpan rahasia seperti kunci, sertifikat, dan string koneksi, lindungi dari akses yang tidak sah. Microsoft Defender untuk Key Vault mendeteksi upaya akses yang mencurigakan dan membuat peringatan. Anda dapat melihat peringatan ini di Microsoft Defender untuk Cloud. Untuk informasi selengkapnya, lihat Microsoft Defender untuk Key Vault.

Ikuti panduan NIST tentang manajemen kunci. Untuk detailnya, lihat:

• Manajemen Kunci Kriptografi.
• SP 800-133 Rev. 2, Rekomendasi untuk Pembuatan Kunci Kriptografi
• SP 800-57 Bagian 1 Rev. 5, Rekomendasi untuk Manajemen Kunci

Lihat juga Microsoft Defender untuk Key Vault.

Persyaratan 3.6.7

Pencegahan substitusi yang tidak sah dari kunci kriptografi.

Tanggung jawab

• Aktifkan diagnostik di semua penyimpanan utama. Gunakan Azure Monitor untuk Key Vault. Ini mengumpulkan log dan metrik dan mengirimkannya ke Azure Monitor. Untuk informasi selengkapnya, lihat Memantau layanan key vault Anda dengan Azure Monitor untuk Key Vault.
• Berikan izin baca-saja kepada semua konsumen.
• Tidak memiliki izin berdiri untuk pengguna manajemen atau prinsipal. Sebagai gantinya, gunakan penetapan peran just-in-time (JIT), aktivasi peran berbasis waktu, dan aktivasi peran berbasis persetujuan.
• Buat tampilan terpusat dengan mengintegrasikan log dan peringatan ke dalam solusi informasi keamanan dan manajemen peristiwa (SIEM), seperti Microsoft Sentinel.
• Ambil tindakan pada peringatan dan pemberitahuan, terutama pada perubahan yang tidak terduga.

Persyaratan 3.6.8

Persyaratan bagi kustodian kunci kriptografi untuk secara formal mengakui bahwa mereka memahami dan menerima tanggung jawab mereka sebagai kustodian kunci.

Tanggung jawab

Pertahankan dokumentasi yang menjelaskan akuntabilitas pihak-pihak yang bertanggung jawab dalam operasi manajemen kunci.

Persyaratan 3.7

Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk melindungi data pemegang kartu yang tersimpan didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terpengaruh.

Tanggung jawab

Buat dokumentasi sebagai pernyataan umum ditambah serangkaian panduan peran terkini untuk semua persona. Lakukan pelatihan karyawan baru dan pelatihan berkelanjutan.

Sangat penting bagi Anda untuk memiliki dokumentasi menyeluruh tentang proses dan kebijakan. Beberapa tim berpartisipasi dalam memastikan data dilindungi saat tidak aktif dan dalam transit. Dalam dokumentasi Anda, berikan panduan peran untuk semua persona. Peran harus mencakup SRE, dukungan pelanggan, penjualan, operasi jaringan, operasi keamanan, insinyur perangkat lunak, administrator database, dan lain-lain. Personel harus mempelajari panduan NIST dan strategi data tidak aktif untuk menjaga agar keterampilan terus diperbarui. Persyaratan pelatihan dibahas di Persyaratan 6.5 dan Persyaratan 12.6.

Persyaratan 4—Mengenkripsi transmisi data pemegang kartu di seluruh jaringan publik terbuka

Tanggung jawab

Persyaratan 4.1

Gunakan kriptografi dan protokol keamanan yang kuat (misalnya, TLS, IPSEC, SSH, dan sebagainya.) untuk melindungi data pemegang kartu sensitif selama transmisi melalui jaringan publik terbuka, termasuk yang berikut ini:

Tanggung jawab

Data pemegang kartu (CHD) yang transit melalui internet publik harus dienkripsi. Data harus dienkripsi dengan TLS 1.2 (atau yang lebih baru), dengan dukungan cipher yang dikurangi untuk semua transmisi. Jangan mendukung pengalihan non-TLS ke TLS pada layanan transmisi data apa pun.

Desain Anda harus memiliki rantai titik terminasi TLS yang strategis. Saat data melalui hop jaringan, pertahankan TLS di hop yang memerlukan inspeksi paket. Paling tidak, miliki titik terminasi TLS terakhir di sumber daya ingress kluster. Pertimbangkan untuk membawanya lebih jauh dalam sumber daya kluster.

Gunakan Azure Policy untuk mengatur pembuatan sumber daya:

• Tolak pembuatan sumber daya ingress non-HTTPS.
• Tolak pembuatan IP publik atau penyeimbang beban publik apa pun di kluster Anda, untuk memastikan lalu lintas web disalurkan melalui gateway Anda.

Untuk informasi selengkapnya, lihat Ikhtisar enkripsi Azure.

Persyaratan 4.1.1

Pastikan jaringan nirkabel mentransmisikan data pemegang kartu atau tersambung ke lingkungan data pemegang kartu, gunakan praktik terbaik industri (misalnya, IEEE 802.11i) untuk mengimplementasikan enkripsi yang kuat untuk autentikasi dan transmisi.

Tanggung jawab

Arsitektur dan implementasi ini tidak didesain untuk melakukan transaksi jaringan-ke-cloud perusahaan atau lokal melalui koneksi nirkabel. Untuk pertimbangan, lihat panduan dalam standar resmi PCI-DSS 3.2.1.

Persyaratan 4.2

Jangan pernah mengirim PAN yang tidak dilindungi oleh teknologi Olahpesan pengguna akhir (misalnya, email, pesan instan, SMS, obrolan, dll.).

Tanggung jawab

Jika beban kerja Anda mengharuskan pengiriman email, pertimbangkan untuk membuat gerbang karantina email. Validasi ini akan memberi Anda kemampuan untuk memindai semua pesan keluar untuk memastikan kepatuhannya dan memastikan bahwa data sensitif tidak disertakan. Idealnya, Anda juga harus mempertimbangkan pendekatan ini untuk pesan dukungan pelanggan.

Validasi harus dilakukan pada tingkat beban kerja dan proses kontrol perubahan. Gerbang persetujuan harus memahami persyaratan.

Untuk pertimbangan, lihat panduan dalam standar resmi PCI-DSS 3.2.1.

Persyaratan 4.3

Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk mengenkripsi transmisi data pemegang kartu didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terpengaruh.

Tanggung jawab

Sangat penting bagi Anda untuk memiliki dokumentasi menyeluruh tentang proses dan kebijakan. Hal ini terutama berlaku ketika Anda mengelola kebijakan tentang Keamanan Lapisan Transportasi (TLS). Berikut beberapa areanya:

• Titik ingress internet publik. Contohnya adalah dukungan Azure Application Gateway untuk cipher TLS.
• Jaringan melakukan hop antara jaringan sekitar dan pod beban kerja.
• Enkripsi pod ke pod (jika diimplementasikan). Ini dapat mencakup detail tentang konfigurasi mesh layanan.
• Pod ke penyimpanan (jika bagian dari arsitektur).
• Pod ke layanan eksternal, layanan Azure PaaS yang menggunakan TLS, gateway pembayaran, atau sistem deteksi penipuan.

Orang-orang yang mengoperasikan lingkungan yang diatur harus dididik, diinformasikan, dan diberi insentif untuk mendukung jaminan keamanan. Ini sangat penting bagi orang-orang yang merupakan bagian dari proses persetujuan dari perspektif kebijakan.

Langkah berikutnya

Lindungi semua sistem dari malware dan perbarui perangkat lunak atau program antivirus secara teratur. Kembangkan dan jaga keamanan sistem dan aplikasi.