Manajemen akses kluster dasar AKS untuk PCI-DSS 3.2.1 (Bagian 6 dari 9)

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

Artikel ini adalah bagian dari beberapa seri. Baca pengantar.

Kubernetes memiliki kontrol akses berbasis peran (RBAC) native yang mengelola izin ke API Kubernetes. Ada beberapa peran bawaan dengan izin atau tindakan khusus pada sumber daya Kubernetes. Azure Kubernetes Service (AKS) mendukung peran bawaan dan peran kustom tersebut untuk kontrol yang menyeluruh. Tindakan tersebut dapat diotorisasi (atau ditolak) kepada pengguna melalui RBAC Kubernetes.

Arsitektur dan penerapan ini tidak dirancang untuk memberikan kontrol pada akses fisik ke sumber daya atau pusat data lokal. Salah satu keuntungan menghosting CDE Anda di Azure, dibandingkan dengan platform di edge atau di pusat data Anda, adalah bahwa membatasi akses fisik sebagian besar sudah ditangani melalui keamanan pusat data Azure. Tidak ada tanggung jawab untuk organisasi dalam manajemen perangkat keras fisik.

Menerapkan pengukuran kontrol akses yang kuat

Persyaratan 7 - Membatasi akses ke data pemegang kartu menurut bisnis perlu diketahui

Dukungan fitur AKS

AKS sepenuhnya terintegrasi dengan ID Microsoft Entra sebagai IdP.

Anda tidak perlu mengelola identitas pengguna dan kredensial terpisah untuk Kubernetes. Anda dapat menambahkan pengguna Microsoft Entra untuk Kubernetes RBAC. Integrasi ini memungkinkan untuk melakukan penetapan peran kepada pengguna Microsoft Entra. Microsoft Entra RBAC mendukung definisi peran, seperti penampil, penulis, admin layanan, admin kluster sebagai peran bawaan. Anda juga dapat membuat peran kustom untuk kontrol yang lebih menyeluruh.

Secara default, RBAC Azure diatur untuk menolak semua sehingga sumber daya tidak dapat diakses tanpa izin yang diberikan. AKS membatasi akses SSH ke node pekerja AKS dan menggunakan kebijakan jaringan AKS untuk mengontrol akses ke beban kerja di pod.

Untuk informasi selengkapnya, lihat Menggunakan RBAC Azure untuk Otorisasi Kubernetes dan Mengamankan kluster Anda dengan Azure Policy.

Tanggung jawab

Persyaratan	Tanggung Jawab
Persyaratan 7.1	Batasi akses ke komponen sistem dan data pemegang kartu hanya untuk seseorang yang pekerjaannya memerlukan akses tersebut.
Persyaratan 7.2	Tetapkan sistem kontrol akses untuk komponen sistem yang membatasi akses berdasarkan hal yang perlu diketahui pengguna, dan diatur ke "tolak semua" kecuali diizinkan secara khusus.
Persyaratan 7.3	Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk membatasi akses ke data pemegang kartu didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.

Persyaratan 7.1

Batasi akses ke komponen sistem dan data pemegang kartu hanya untuk seseorang yang pekerjaannya memerlukan akses tersebut.

Tanggung jawab

Berikut adalah beberapa pertimbangan:

• Pastikan penerapan Anda sesuai dengan persyaratan organisasi, dan dengan persyaratan kepatuhan tentang manajemen identitas.
• Minimalkan izin tetap terutama untuk akun yang sangat penting.
• Ikuti prinsip akses yang tidak memiliki hak istimewa. Berikan akses yang cukup untuk menyelesaikan tugas.

Persyaratan 7.1.1

Tentukan kebutuhan akses untuk setiap peran, termasuk:

• Komponen sistem dan sumber daya data yang perlu diakses setiap peran untuk fungsi pekerjaannya
• Tingkat hak istimewa yang diperlukan (misalnya, pengguna, administrator, dll.) untuk mengakses sumber daya.

Tanggung jawab

Tetapkan peran berdasarkan tugas dan tanggung jawab yang diperlukan untuk komponen dalam cakupan dan interaksinya dengan sumber daya Azure. Anda dapat memulai dengan kategori yang luas, seperti:

• Cakupan berdasarkan grup manajemen Azure, langganan, atau grup sumber daya
• Azure Policy untuk beban kerja atau langganan
• Operasi kontainer
• Manajemen rahasia
• Membangun dan menyebarkan alur

Sementara definisi peran dan tanggung jawab di sekitar area tersebut mungkin terkait dengan struktur tim Anda, fokuslah pada persyaratan beban kerja. Misalnya, siapa yang bertanggung jawab untuk menjaga keamanan, isolasi, penyebaran, dan observabilitas. Berikut adalah beberapa contoh:

• Keputusan tentang keamanan aplikasi, RBAC Kubernetes, kebijakan jaringan, kebijakan Azure, dan komunikasi dengan layanan lain.
• Konfigurasi dan pemeliharaan Azure Firewall, web application firewall(WAF), kelompok keamanan jaringan (NSG), dan konfigurasi DNS.
• Pantau dan pulihkan keamanan server, patching, konfigurasi, dan keamanan titik akhir.
• Tetapkan arah penggunaan RBAC, Microsoft Defender untuk Cloud, strategi perlindungan Administrator, dan Azure Policy untuk mengatur sumber daya Azure.
• Tim pemantauan dan respons insiden. Selidiki dan pulihkan insiden keamanan di informasi keamanan dan manajemen peristiwa (SIEM) atau Microsoft Defender untuk Cloud.

Kemudian, bentuk definisi dengan menentukan tingkat akses apa yang diperlukan untuk peran tersebut sehubungan dengan beban kerja dan infrastruktur. Berikut adalah definisi sederhana untuk tujuan ilustrasi.

Peran	Tanggung jawab	Tingkat akses
Pemilik aplikasi	Menentukan dan memprioritaskan fitur yang sesuai dengan hasil bisnis. Pemilik aplikasi memahami bagaimana fitur memengaruhi cakupan kepatuhan beban kerja, dan menyeimbangkan perlindungan dan kepemilikan data pelanggan dengan tujuan bisnis.	Akses baca ke log dan metrik yang dikeluarkan oleh aplikasi. Pemilik aplikasi tidak memerlukan izin untuk mengakses beban kerja atau kluster.
Pengembang aplikasi	Mengembangkan aplikasi. Semua kode aplikasi tunduk pada pelatihan dan syarat kualitas yang menjunjung tinggi kepatuhan, pengesahan, dan proses manajemen rilis. Dapat mengelola alur pembangunan, tetapi biasanya bukan alur penyebaran.	Akses baca ke namespace Kubernetes dan sumber daya Azure yang berada dalam cakupan beban kerja. Tidak ada akses tulis untuk menyebarkan atau mengubah status sistem apa pun.
Operator aplikasi (atau SRE)	Memiliki pemahaman yang mendalam tentang basis kode, observabilitas, dan operasi. Melakukan triase dan pemecahan masalah situs langsung. Bersama dengan pengembang aplikasi, meningkatkan ketersediaan, skalabilitas, dan performa aplikasi. Mengelola alur penyebaran "last-mile" dan membantu mengelola alur pembangunan.	Sangat istimewa dalam cakupan aplikasi yang mencakup namespace Kubernetes dan sumber daya Azure terkait. Kemungkinan memiliki akses tetap ke bagian-bagian dari kluster Kubernetes.
Pemilik infrastruktur	Merancang arsitektur yang hemat biaya, termasuk konektivitas dan fungsionalitas komponennya. Cakupannya dapat mencakup layanan cloud dan lokal. Menentukan kemampuan retensi data, fitur kelangsungan bisnis, dan lain-lain.	Mengakses ke log platform dan data pusat biaya. Tidak ada akses yang diperlukan dalam kluster.
Operator infrastruktur (atau SRE)	Operasi yang terkait dengan kluster dan layanan dependen. Membangun, menyebarkan, dan melakukan bootstrap alur untuk kluster tempat beban kerja disebarkan. Mengatur kumpulan node target, serta persyaratan ukuran dan skala yang diharapkan. Memantau kesehatan infrastruktur hosting kontainer dan layanan yang bergantung.	Akses baca ke namespace beban kerja. Akses yang sangat istimewa untuk kluster.
Kebijakan, pemilik keamanan	Memiliki keahlian kepatuhan keamanan atau peraturan. Menentukan kebijakan yang melindungi keamanan dan kepatuhan terhadap peraturan karyawan perusahaan, asetnya, dan aset pelanggan perusahaan. Bekerja dengan semua peran lain untuk memastikan kebijakan diterapkan dan dapat diaudit melalui setiap tahap.	Akses baca ke beban kerja dan kluster. Selain itu, ada juga akses ke log dan data audit.
Operator jaringan	Alokasi jaringan virtual dan subnet seluruh perusahaan. Konfigurasi dan pemeliharaan Azure Firewall, WAF, NSG, dan konfigurasi DNS.	Sangat istimewa di lapisan jaringan. Tidak ada izin tulis dalam kluster.

Persyaratan 7.1.2

Batasi akses ke ID pengguna dengan hak istimewa hingga hak istimewa paling sedikit yang diperlukan untuk melakukan tanggung jawab pekerjaan.

Tanggung jawab

Berdasarkan fungsi pekerjaan, usahakan untuk meminimalkan akses tanpa menyebabkan gangguan. Berikut beberapa praktik terbaik:

• Identitas harus memiliki akses yang cukup untuk menyelesaikan tugas.
• Minimalkan izin tetap, terutama pada identitas penting yang memiliki akses ke komponen dalam cakupan.
• Tambahkan batasan tambahan jika memungkinkan. Salah satu caranya adalah dengan memberikan akses bersyarat berdasarkan kriteria akses.
• Lakukan tinjauan dan audit rutin terhadap pengguna dan grup yang memiliki akses di langganan Anda, bahkan untuk akses baca. Hindari mengundang identitas eksternal.

Persyaratan 7.1.3

Tetapkan akses berdasarkan klasifikasi dan fungsi pekerjaan masing-masing personel.

Tanggung jawab

Menentukan izin berdasarkan tugas pekerjaan seseorang yang ditetapkan dengan jelas. Menghindari parameter seperti sistem atau masa jabatan karyawan. Memberikan hak akses ke satu pengguna atau grup.

Berikut adalah beberapa contoh.

Klasifikasi pekerjaan	Peran
Pemilik produk menentukan cakupan beban kerja dan memprioritaskan fitur. Menyeimbangkan perlindungan dan kepemilikan data pelanggan dengan tujuan bisnis. Memerlukan akses ke laporan, pusat biaya, atau dasbor Azure. Tidak diperlukan akses untuk izin dalam kluster atau tingkat kluster.	Pemilik aplikasi
Teknisi perangkat lunak mendesain, mengembangkan, dan menyimpan kode aplikasi. Grup dengan izin baca tetap dalam cakupan yang ditentukan dalam Azure (seperti Application Insights) dan namespace beban kerja. Cakupan dan izin ini mungkin berbeda antara lingkungan pra-produksi dan produksi.	Pengembang aplikasi
Teknisi keandalan situs melakukan triase situs langsung, mengelola alur, dan menyiapkan infrastruktur aplikasi. Grup A dengan kontrol penuh dalam namespace yang dialokasikan. Izin tetap tidak diperlukan. Grup B untuk operasi sehari-hari pada beban kerja. Grup B dapat memiliki izin tetap di dalam namespace yang dialokasikan, tetapi tidak memiliki hak istimewa.	Operator aplikasi
Operator kluster mendesain dan menyebarkan kluster AKS yang andal dan aman ke platform. Bertanggung jawab untuk menjaga waktu aktif kluster. Grup A dengan kontrol penuh dalam namespace yang dialokasikan. Izin tetap tidak diperlukan. Grup B untuk operasi sehari-hari pada beban kerja. Grup B dapat memiliki izin tetap di dalam namespace yang dialokasikan, tetapi tidak memiliki hak istimewa.	Operator infrastruktur
Teknisi jaringan mengalokasikan jaringan virtual dan subnet seluruh perusahaan, konektivitas lokal ke cloud, dan keamanan jaringan.	Operator infrastruktur

Persyaratan 7.1.4

Memerlukan persetujuan terdokumentasi oleh pihak berwenang yang menentukan hak istimewa yang diperlukan.

Tanggung jawab

Memiliki proses yang terjaga untuk menyetujui perubahan peran dan izin, termasuk penugasan awal dari hak istimewa. Memastikan persetujuan tersebut didokumentasikan dan tersedia untuk inspeksi.

Persyaratan 7.2

Tetapkan sistem kontrol akses untuk komponen sistem yang membatasi akses berdasarkan hal yang perlu diketahui pengguna, dan diatur ke "tolak semua" kecuali diizinkan secara khusus.

Tanggung jawab

Setelah mengikuti Persyaratan 7.1, Anda harus menilai peran dan tanggung jawab yang berlaku untuk organisasi dan beban kerja. Semua komponen dalam arsitektur yang berada dalam cakupan harus memiliki akses terbatas. Hal ini termasuk node AKS yang menjalankan beban kerja, penyimpanan data, akses jaringan, dan semua layanan lain yang berpartisipasi dalam pemrosesan data pemegang kartu (CHD).

Berdasarkan peran dan tanggung jawab, tetapkan peran ke kontrol akses berbasis peran (RBAC) infrastruktur. Mekanisme tersebut dapat berupa:

• RBAC Kubernetes adalah model otorisasi Kubernetes native yang mengontrol akses ke sarana kontrol Kubernetes, yang diberikan melalui server API Kubernetes. Kumpulan izin ini menentukan apa yang dapat Anda lakukan dengan server API. Misalnya, Anda dapat menolak izin pengguna untuk membuat atau bahkan mencantumkan pod.
• Azure RBAC adalah model otorisasi berbasis ID Microsoft Entra yang mengontrol akses ke sarana kontrol Azure. Ini adalah asosiasi penyewa Microsoft Entra Anda dengan langganan Azure Anda. Dengan RBAC Azure, Anda dapat memberikan izin untuk membuat sumber daya Azure, seperti jaringan, kluster AKS, dan identitas terkelola.

Misalkan Anda perlu memberikan izin kepada operator kluster (dipetakan ke peran operator infrastruktur). Semua orang yang diberi tanggung jawab operator infrastruktur termasuk dalam grup Microsoft Entra. Sebagaimana ditetapkan pada 7.1.1, peran ini memerlukan hak istimewa tertinggi dalam kluster. Kubernetes memiliki peran RBAC bawaan, seperti cluster-admin, yang memenuhi persyaratan tersebut. Anda harus mengikat grup Microsoft Entra untuk operator cluster-admin infrastruktur dengan membuat pengikatan peran. Ada dua pendekatan. Anda dapat memilih peran bawaan. Atau, jika peran bawaan tidak memenuhi persyaratan Anda (misalnya, peran tersebut mungkin terlalu permisif), buat peran kustom untuk pengikatan Anda.

Penerapan referensi menunjukkan contoh sebelumnya dengan menggunakan RBAC Kubernetes native. Asosiasi yang sama dapat dilakukan dengan RBAC Azure. Untuk informasi selengkapnya, lihat Mengontrol akses ke sumber daya kluster menggunakan kontrol akses berbasis peran Kubernetes dan identitas Microsoft Entra di Azure Kubernetes Service.

Anda dapat memilih cakupan izin di tingkat kluster atau di tingkat namespace. Untuk peran yang memiliki tanggung jawab tercakup, seperti operator aplikasi, izin ditetapkan pada tingkat namespace untuk beban kerja.

Selain itu, peran juga memerlukan izin RBAC Azure agar dapat melakukan tugasnya. Misalnya, operator kluster perlu mengakses Azure Monitor melalui portal. Jadi, peran operator infrastruktur harus memiliki penugasan RBAC yang sesuai.

Terlepas dari orang dan peran mereka, sumber daya Azure dan bahkan pod dalam kluster memiliki identitas terkelola. Identitas tersebut memerlukan sekumpulan izin melalui Azure RBAC, dan harus dibatasi secara ketat berdasarkan tugas yang diharapkan. Misalnya, Azure Application Gateway harus memiliki izin untuk mendapatkan rahasia (sertifikat TLS) dari Azure Key Vault. Azure Application Gateway tidak boleh memiliki izin untuk mengubah rahasia.

Berikut beberapa praktik terbaik:

• Pertahankan dokumentasi yang cermat tentang setiap peran dan izin yang ditetapkan. Pertahankan perbedaan yang jelas tentang izin mana yang termasuk JIT dan mana yang tetap.

• Pantau peran untuk perubahan, seperti dalam perubahan penugasan atau definisi peran. Buat peringatan tentang perubahan bahkan jika mereka diharapkan untuk mendapatkan visibilitas ke niat di balik perubahan.

Persyaratan 7.2.1

Cakupan semua komponen sistem

Tanggung jawab

Berikut adalah beberapa praktik terbaik untuk mempertahankan pengukuran kontrol akses:

• Tidak memiliki akses tetap. Pertimbangkan untuk menggunakan keanggotaan grup AD Just-In-Time. Fitur ini memerlukan Microsoft Entra Privileged Identity Management.

• Siapkan Kebijakan Akses Bersyar di ID Microsoft Entra untuk kluster Anda. Hal ini semakin membatasi akses ke sarana kontrol Kubernetes. Dengan kebijakan akses bersyarat, Anda dapat memerlukan autentikasi multifaktor, membatasi autentikasi ke perangkat yang dikelola oleh penyewa Microsoft Entra Anda, atau memblokir upaya masuk yang tidak umum. Terapkan kebijakan ini ke grup Microsoft Entra yang dipetakan ke peran Kubernetes dengan hak istimewa tinggi.

  Catatan

  Pilihan teknologi akses bersyarat dan JIT memerlukan Microsoft Entra ID P1 atau P2.

• Idealnya, nonaktifkan akses SSH ke node kluster. Penerapan referensi ini tidak menghasilkan detail koneksi SSH untuk tujuan tersebut.

• Setiap komputasi tambahan, seperti jump box, harus diakses oleh pengguna yang berwenang. Jangan membuat info masuk generik yang tersedia untuk seluruh tim.

Persyaratan 7.2.2

Penugasan hak istimewa kepada seseorang berdasarkan klasifikasi dan fungsi pekerjaan.

Tanggung jawab

Berdasarkan 7.1.3, akan ada banyak peran yang terlibat dalam operasi kluster. Di luar peran sumber daya Azure standar, Anda harus menentukan tingkat dan proses akses.

Misalnya, pertimbangkan peran operator kluster. Peran operator kluster harus memiliki playbook yang jelas untuk aktivitas triase kluster. Seberapa besar perbedaan akses tersebut dari tim beban kerja? Bergantung pada organisasi Anda, mereka mungkin sama. Berikut adalah beberapa poin untuk dipertimbangkan:

• Bagaimana peran operator harus mengakses kluster?
• Sumber mana yang diizinkan untuk diakses?
• Izin apa yang harus peran operator miliki di kluster?
• Kapan izin tersebut ditetapkan?

Pastikan definisi didokumentasikan dalam dokumentasi tata kelola, kebijakan, dan materi pelatihan seputar operator beban kerja dan operator kluster.

Persyaratan 7.2.3

Pengaturan "deny-all" default.

Tanggung jawab

Saat Anda memulai konfigurasi, mulai dengan kebijakan zero-trust. Membuat pengecualian sesuai kebutuhan dan mendokumentasikan secara detail.

• RBAC Kubernetes menerapkan deny all secara default. Jangan timpa dengan menambahkan pengikatan peran kluster yang sangat permisif yang membalikkan pengaturan deny all.

• RBAC Azure juga menerapkan deny all secara default. Jangan timpa dengan menambahkan penugasan RBAC yang membalikkan pengaturan deny all.

• Semua layanan Azure, Azure Key Vault, dan Azure Container Registry, memiliki kumpulan izin deny all secara default.

• Titik akses administratif apa pun, seperti jump box, harus menolak semua akses dalam konfigurasi awal. Semua izin yang ditingkatkan harus ditentukan secara eksplisit untuk menolak semua aturan.

Persyaratan 7.3

Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk membatasi akses ke data pemegang kartu didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.

Tanggung jawab

Sangat penting bagi Anda untuk memiliki dokumentasi menyeluruh tentang proses dan kebijakan. Hal ini termasuk kebijakan RBAC Azure dan Kubernetes serta kebijakan tata kelola organisasi. Orang yang mengoperasikan lingkungan yang diatur harus diberi edukasi, diberi informasi, dan diberi insentif untuk mendukung jaminan keamanan. Ini sangat penting bagi orang-orang yang merupakan bagian dari proses persetujuan dari perspektif kebijakan.

Persyaratan 8 — Mengidentifikasi dan mengautentikasi akses ke komponen sistem

Dukungan fitur AKS

Karena integrasi AKS dan Microsoft Entra, Anda dapat memanfaatkan kemampuan manajemen dan otorisasi ID, termasuk manajemen akses, manajemen objek pengidentifikasi, dan lainnya. Untuk informasi selengkapnya, lihat Integrasi Microsoft Entra yang dikelola AKS.

Tanggung jawab

Persyaratan	Tanggung Jawab
Persyaratan 8.1	Tetapkan dan terapkan kebijakan dan prosedur untuk memastikan manajemen identifikasi pengguna yang tepat untuk pengguna dan administrator non-konsumen pada semua komponen sistem sebagai berikut:
Persyaratan 8.2	Selain menetapkan ID unik, pastikan manajemen autentikasi pengguna yang tepat untuk pengguna non-konsumen dan administrator di semua komponen sistem dengan menggunakan setidaknya salah satu metode berikut untuk mengautentikasi semua pengguna:
Persyaratan 8.3	Amankan semua akses administratif non-konsol terpisah dan semua akses jarak jauh ke CDE menggunakan autentikasi multifaktor.
Persyaratan 8.4	Dokumentasikan dan komunikasikan prosedur dan kebijakan serta prosedur autentikasi kepada semua pengguna termasuk:
Persyaratan 8.5	Jangan gunakan ID grup, bersama, atau generik, kata sandi, atau metode autentikasi lainnya sebagai berikut:
Persyaratan 8.6	Tempat mekanisme autentikasi lain digunakan (misalnya, token keamanan fisik atau logis, kartu pintar, sertifikat, dll.), penggunaan mekanisme ini harus ditetapkan sebagai berikut:
Persyaratan 8.7	Semua akses ke database yang berisi data pemegang kartu (termasuk akses oleh aplikasi, administrator, dan semua pengguna lain) dibatasi sebagai berikut:
Persyaratan 8.8	Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk identifikasi dan autentikasi didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.

Persyaratan 8.1

Tetapkan dan terapkan kebijakan dan prosedur untuk memastikan manajemen identifikasi pengguna yang tepat untuk pengguna dan administrator non-konsumen pada semua komponen sistem sebagai berikut:

• 8.1.1 Tetapkan ID unik kepada semua pengguna sebelum mengizinkan mereka mengakses komponen sistem atau data pemegang kartu.
• 8.1.2 Kontrol penambahan, penghapusan, dan perubahan ID pengguna, kredensial, dan objek pengidentifikasi lainnya.
• 8.1.3 Segera cabut akses untuk setiap pengguna yang dihentikan.
• 8.1.4 Hapus/nonaktifkan akun pengguna yang tidak aktif dalam waktu 90 hari.
• 8.1.5 Mengelola ID yang digunakan oleh pihak ketiga untuk mengakses, mendukung, atau memelihara komponen sistem melalui akses jarak jauh sebagai berikut:
  • Diaktifkan hanya selama periode waktu yang dibutuhkan dan dinonaktifkan saat tidak digunakan.
  • Dimonitor saat digunakan.
• 8.1.6 Batasi percobaan akses berulang dengan mengunci ID pengguna setelah tidak lebih dari enam percobaan.
• 8.1.7 Atur durasi penguncian ke minimum 30 menit atau hingga administrator mengaktifkan ID pengguna.
• 8.1.8 Jika sesi tidak digunakan selama lebih dari 15 menit, minta pengguna untuk mengautentikasi ulang untuk mengaktifkan kembali terminal atau sesi.

Tanggung jawab

Berikut adalah pertimbangan keseluruhan untuk persyaratan ini:

BERLAKU UNTUK: 8.1.1, 8.1.2, 8.1.3

Jangan bagikan atau gunakan kembali identitas untuk bagian CDE yang berbeda secara fungsional. Misalnya, jangan gunakan akun tim untuk mengakses data atau sumber daya kluster. Pastikan dokumentasi identitas jelas tentang tidak menggunakan akun bersama.

Perluas prinsip identitas ini ke penugasan identitas terkelola di Azure. Jangan bagikan identitas yang dikelola pengguna di seluruh sumber daya Azure. Tetapkan setiap sumber daya Azure dengan identitas terkelolanya sendiri. Demikian pula, saat Anda menggunakan ID Beban Kerja Microsoft Entra di kluster AKS, pastikan bahwa setiap komponen dalam beban kerja Anda menerima identitasnya sendiri alih-alih menggunakan identitas yang luas dalam cakupan. Jangan pernah menggunakan identitas terkelola yang sama dalam pra-produksi dan produksi.

Mengakses dan mengidentifikasi opsi untuk Azure Kubernetes Service (AKS)

BERLAKU UNTUK: 8.1.2, 8.1.3, 8.1.4

Gunakan ID Microsoft Entra sebagai penyimpanan identitas. Karena kluster dan semua sumber daya Azure menggunakan ID Microsoft Entra, menonaktifkan atau mencabut akses ID Microsoft Entra diterapkan ke semua sumber daya secara otomatis. Jika ada komponen yang tidak didukung langsung oleh ID Microsoft Entra, pastikan Anda memiliki proses untuk menghapus akses. Misalnya, kredensial SSH untuk mengakses jump box mungkin perlu dihapus secara eksplisit jika pengguna tidak lagi valid.

BERLAKU UNTUK: 8.1.5

Manfaatkan Microsoft Entra business-to-business (B2B) yang dirancang untuk menghosting akun pihak ketiga, seperti vendor, mitra, sebagai pengguna tamu. Berikan tingkat akses yang sesuai dengan menggunakan kebijakan bersyarat untuk melindungi data perusahaan. Akun ini harus memiliki izin tetap minimal dan tanggal kedaluwarsa yang wajib. Untuk informasi selengkapnya, lihat Apa itu akses pengguna tamu di Microsoft Entra B2B.

Organisasi Anda harus memiliki pola vendor dan akses serupa yang jelas dan terdokumentasi.

BERLAKU UNTUK: 8.1.6, 8.1.7, 8.1.8

Tanggung jawab

MICROSOFT Entra ID menyediakan fitur penguncian cerdas untuk mengunci pengguna setelah upaya masuk yang gagal. Cara yang disarankan untuk menerapkan penguncian adalah dengan kebijakan Microsoft Entra Conditional Access.

Terapkan penguncian untuk komponen yang mendukung fitur serupa tetapi tidak didukung dengan ID Microsoft Entra (misalnya, komputer yang diaktifkan SSH, seperti jump box). Hal ini memastikan bahwa penguncian diaktifkan untuk mencegah atau memperlambat upaya penyalahgunaan akses.

Node AKS tidak dirancang untuk diakses secara rutin. Blokir SSH langsung atau Desktop Jauh ke node kluster. Akses SSH hanya boleh dianggap sebagai bagian dari upaya pemecahan masalah tingkat lanjut. Akses harus dipantau secara ketat dan segera dikembalikan setelah selesainya peristiwa tertentu. Jika melakukan hal ini, perlu diketahui bahwa setiap perubahan tingkat node dapat menyebabkan kluster Anda tidak didukung.

Persyaratan 8.2

Selain menetapkan ID unik, pastikan manajemen autentikasi pengguna yang tepat untuk pengguna dan administrator non-konsumen di semua komponen sistem dengan menggunakan setidaknya salah satu metode berikut untuk mengautentikasi semua pengguna: Sesuatu yang Anda ketahui, seperti kata sandi atau kata kunci, Sesuatu yang Anda miliki, seperti perangkat token atau kartu pintar, Sesuatu tentang Anda, seperti biometrik.

• 8.2.1 Menggunakan kriptografi yang kuat, merender semua kredensial autentikasi (seperti kata sandi/kunci) tidak terbaca selama transmisi dan penyimpanan pada semua komponen sistem.
• 8.2.2 Verifikasi identitas pengguna sebelum mengubah kredensial autentikasi apa pun—misalnya, melakukan pengaturan ulang kata sandi, menyediakan token baru, atau membuat kunci baru.
• 8.2.3 Kata sandi/frasa harus memenuhi hal berikut:
  • Memerlukan panjang minimal setidaknya tujuh karakter.
  • Berisi karakter numerik dan alfabetis.
• 8.2.4 Ubah kata sandi/kata kunci pengguna setidaknya sekali setiap 90 hari.
• 8.2.5 Jangan izinkan seseorang mengirimkan kata sandi/kunci baru yang sama dengan salah satu dari empat kata sandi/kunci terakhir yang dia gunakan.
• 8.2.6 Atur kata sandi/kunci untuk penggunaan pertama kali dan setelah pengaturan ulang ke nilai unik untuk setiap pengguna, dan ubah secepatnya setelah penggunaan pertama.

Tanggung jawab

Siapkan Kebijakan Akses Bersyar di ID Microsoft Entra untuk kluster Anda. Hal ini semakin membatasi akses ke sarana kontrol Kubernetes.

Beberapa kumpulan persyaratan sebelumnya secara otomatis ditangani oleh ID Microsoft Entra. Berikut adalah beberapa contoh:

• Keamanan kata sandi

  MICROSOFT Entra ID menyediakan fitur yang memberlakukan penggunaan kata sandi yang kuat. Misalnya, kata sandi lemah yang termasuk dalam daftar kata sandi terlarang secara global diblokir. Kata sandi lemah bukan perlindungan yang cukup. Pertimbangkan untuk menambahkan fitur Perlindungan Kata Sandi Microsoft Entra untuk membuat daftar larangan khusus organisasi. Kebijakan kata sandi diterapkan secara default. Kebijakan tertentu tidak dapat diubah dan mencakup beberapa kumpulan persyaratan sebelumnya. Termasuk kedaluwarsa kata sandi dan karakter yang diizinkan. Untuk daftar lengkapnya, lihat Kebijakan kata sandi Microsoft Entra. Pertimbangkan untuk menggunakan fitur tingkat lanjut yang dapat diterapkan dengan kebijakan akses bersyarat, seperti yang didasarkan pada risiko pengguna, yang mendeteksi kebocoran pasangan nama pengguna dan kata sandi. Untuk informasi selengkapnya, lihat Akses Bersyarat: Akses Bersyarat berbasis risiko pengguna.

  Catatan

  Sebaiknya Anda mempertimbangkan opsi tanpa kata sandi. Untuk informasi selengkapnya, lihat Merencanakan penyebaran autentikasi tanpa kata sandi di ID Microsoft Entra.

• Verifikasi identitas pengguna

  Anda dapat menerapkan kebijakan akses bersyarat risiko kredensial masuk untuk mendeteksi jika permintaan autentikasi dikeluarkan oleh identitas yang meminta. Permintaan divalidasi terhadap sumber inteligensi ancaman. Ancaman termasuk password spray dan anomali alamat IP. Untuk informasi selengkapnya, lihat Akses Bersyarat: Akses Bersyarat berbasis risiko kredensial masuk.

Anda mungkin memiliki komponen yang tidak menggunakan ID Microsoft Entra, seperti akses ke jump box dengan SSH. Untuk kasus seperti itu, gunakan enkripsi kunci umum dengan setidaknya ukuran kunci RSA 2048. Selalu tentukan kata kunci. Gunakan proses validasi yang melacak kunci umum yang diketahui dan disetujui. Sistem yang menggunakan akses kunci umum tidak boleh terhubung ke internet. Sebagai gantinya, semua akses SSH harus diizinkan melalui perantara, seperti Azure Bastion untuk mengurangi dampak kebocoran kunci privat. Nonaktifkan akses kata sandi langsung dan gunakan solusi tanpa kata sandi alternatif.

Persyaratan 8.3

Amankan semua akses administratif non-konsol terpisah dan semua akses jarak jauh ke CDE menggunakan autentikasi multifaktor. Catatan: Autentikasi multifaktor mengharuskan minimal dua dari tiga metode autentikasi (lihat Persyaratan 8.2 untuk penjelasan metode autentikasi) digunakan untuk autentikasi. Menggunakan satu faktor dua kali (misalnya, menggunakan dua kata sandi terpisah) tidak dianggap sebagai autentikasi multifaktor.

Tanggung jawab

Gunakan kebijakan akses bersyarat untuk menerapkan autentikasi multifaktor, khususnya pada akun administratif. Kebijakan ini disarankan pada beberapa peran bawaan. Terapkan kebijakan ini ke grup Microsoft Entra yang dipetakan ke peran Kubernetes dengan hak istimewa tinggi.

Kebijakan ini dapat lebih diperketat dengan kebijakan tambahan. Berikut adalah beberapa contoh:

• Anda dapat membatasi autentikasi ke perangkat yang dikelola oleh penyewa Microsoft Entra Anda.
• Jika akses berasal dari jaringan di luar jaringan kluster, Anda dapat menerapkan autentikasi multifaktor.

Untuk informasi selengkapnya, lihat:

• Akses Bersyarat: Mewajibkan MFA untuk administrator
• Cara: Memerlukan perangkat terkelola untuk akses aplikasi cloud dengan Akses Bersyarat
• Cara: Memerlukan MFA untuk akses dari jaringan yang tidak tepercaya dengan Akses Bersyarat

Persyaratan 8.4

Dokumentasikan dan komunikasikan prosedur dan kebijakan serta prosedur autentikasi kepada semua pengguna termasuk:

• Panduan memilih kredensial autentikasi yang kuat
• Panduan tentang cara pengguna harus melindungi kredensial autentikasi mereka
• Instruksi untuk tidak menggunakan kembali kata sandi yang digunakan sebelumnya
• Instruksi untuk mengubah kata sandi jika ada kecurigaan bahwa kata sandi kemungkinan disusupi.

Tanggung jawab

Pertahankan dokumentasi tentang kebijakan yang diberlakukan. Sebagai bagian dari pelatihan onboarding identitas Anda, berikan panduan untuk prosedur pengaturan ulang kata sandi dan praktik terbaik organisasi tentang melindungi aset.

Persyaratan 8.5

Jangan gunakan ID grup, bersama, atau generik, kata sandi, atau metode autentikasi lainnya sebagai berikut:

• ID pengguna generik dinonaktifkan atau dihapus.
• ID pengguna bersama tidak ada untuk administrasi sistem dan fungsi penting lainnya.
• ID pengguna bersama dan generik tidak digunakan untuk mengelola komponen sistem apa pun.

Tanggung jawab

Jangan membagikan atau menggunakan kembali identitas untuk bagian yang berbeda secara fungsional dari kluster atau pod. Misalnya, jangan gunakan akun tim untuk mengakses data atau sumber daya kluster. Pastikan dokumentasi identitas jelas tentang tidak menggunakan akun bersama.

Nonaktifkan pengguna root di CDE. Nonaktifkan penggunaan akun lokal Kubernetes sehingga pengguna tidak dapat menggunakan akses --admin bawaan ke kluster dalam CDE.

Persyaratan 8.6

Tempat mekanisme autentikasi lain digunakan (misalnya, token keamanan fisik atau logis, kartu pintar, sertifikat, dll.), penggunaan mekanisme ini harus ditetapkan sebagai berikut:

• Mekanisme autentikasi harus ditetapkan ke masing-masing akun dan tidak dibagikan di antara beberapa akun.
• Kontrol fisik dan/atau logis harus ada untuk memastikan hanya akun yang dimaksud yang dapat menggunakan mekanisme tersebut untuk mendapatkan akses.

Tanggung jawab

Pastikan bahwa semua akses ke CDE diberikan pada identitas per pengguna, dan ini diperluas ke semua token fisik atau virtual. Hal ini termasuk semua akses VPN ke jaringan CDE, memastikan bahwa akses point-to-site perusahaan (jika ada) menggunakan sertifikat per pengguna sebagai bagian dari alur autentikasi tersebut.

Persyaratan 8.7

Semua akses ke database yang berisi data pemegang kartu (termasuk akses oleh aplikasi, administrator, dan semua pengguna lain) dibatasi sebagai berikut:

• Semua akses pengguna ke, kueri pengguna, dan tindakan pengguna pada database melalui metode terprogram.
• Hanya administrator database yang memiliki kemampuan untuk mengakses atau mengkueri database secara langsung.
• ID aplikasi untuk aplikasi database hanya dapat digunakan oleh aplikasi (dan bukan oleh setiap pengguna atau proses non-aplikasi lainnya).

Tanggung jawab

Berikan akses berdasarkan peran dan tanggung jawab. Seseorang dapat menggunakan identitas mereka, tetapi aksesnya harus dibatasi berdasarkan hal yang perlu diketahui, dengan izin tetap yang minimal. Seseorang tidak boleh menggunakan identitas aplikasi, dan identitas akses database tidak boleh dibagikan.

Jika memungkinkan, akses database dari aplikasi melalui identitas terkelola. Jika tidak, batasi akses ke string koneksi dan kredensial. Gunakan rahasia Kubernetes untuk menyimpan informasi sensitif daripada menyimpan informasi sensitif di tempat yang mudah ditemukan, seperti definisi pod. Cara lain adalah dengan menyimpan dan memuat rahasia ke dan dari penyimpanan terkelola, seperti Azure Key Vault. Dengan identitas terkelola yang diaktifkan pada kluster AKS, identitas terkelola harus mengautentikasi sendiri terhadap Key Vault untuk mendapatkan akses.

Persyaratan 8.8

Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk identifikasi dan autentikasi didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.

Tanggung jawab

Sangat penting bagi Anda untuk memiliki dokumentasi menyeluruh tentang proses dan kebijakan. Pertahankan dokumentasi tentang kebijakan yang diberlakukan. Sebagai bagian dari pelatihan onboarding identitas Anda, berikan panduan untuk prosedur pengaturan ulang kata sandi dan praktik terbaik organisasi tentang melindungi aset. Orang yang mengoperasikan lingkungan yang diatur harus diberi edukasi, diberi informasi, dan diberi insentif untuk mendukung jaminan keamanan. Ini sangat penting bagi orang-orang yang merupakan bagian dari proses persetujuan dari perspektif kebijakan.

Persyaratan 9 — Membatasi akses fisik ke data pemegang kartu

Dukungan fitur AKS

Tidak ada fitur AKS yang berlaku untuk persyaratan ini.

Tanggung jawab

Arsitektur dan penerapan ini tidak dirancang untuk memberikan kontrol pada akses fisik ke sumber daya atau pusat data lokal. Untuk pertimbangan, lihat panduan dalam standar resmi PCI-DSS 3.2.1.

Berikut adalah beberapa saran untuk menerapkan kontrol teknis:

• Sesuaikan batas waktu sesi di semua akses konsol administratif, seperti jump box di CDE, untuk meminimalkan akses.

• Sesuaikan kebijakan akses bersyarat untuk meminimalkan TTL pada token akses Azure dari titik akses, seperti portal Microsoft Azure. Untuk informasi selengkapnya, lihat artikel berikut ini:

  • Mengonfigurasi pengelolaan sesi autentikasi dengan Akses Bersyarat
  • Masa pakai token yang dapat dikonfigurasi - Platform identitas Microsoft

• Untuk CDE yang dihosting di cloud, tidak ada tanggung jawab untuk mengelola akses fisik dan perangkat keras. Andalkan kontrol fisik dan logis jaringan perusahaan.

• Minimalkan ekspor cadangan CHD ke tujuan lokal. Gunakan solusi yang dihosting di Azure untuk membatasi akses fisik ke cadangan.

• Minimalkan cadangan ke lokal. Jika ini diperlukan, perlu diketahui bahwa tujuan lokal akan berada dalam cakupan audit.

Langkah berikutnya

Lacak dan pantau semua akses ke sumber daya jaringan dan data pemegang kartu. Uji sistem dan proses keamanan secara teratur.