Mengonfigurasi jaringan kluster yang diatur AKS untuk PCI-DSS 3.2.1 (Bagian 3 dari 9)

Artikel ini menjelaskan pertimbangan jaringan 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.

Tema utama standar PCI-DSS 3.2.1 adalah keamanan. Topologi hub-spoke adalah pilihan alami untuk mendirikan lingkungan yang diatur. Lebih mudah untuk membuat infrastruktur yang memungkinkan komunikasi yang aman. Kontrol jaringan ditempatkan di kedua jaringan hub-spoke dan mengikuti model Microsoft zero-trust. Kontrol dapat disetel dengan hak istimewa paling sedikit untuk mengamankan lalu lintas, memberikan akses berdasarkan kebutuhan untuk mengetahui. Selain itu, Anda dapat menerapkan beberapa pendekatan pertahanan mendalam dengan menambahkan kontrol di setiap hop jaringan.

Saat Anda menghosting beban kerja di Kubernetes, tidak cukup mengandalkan konstruksi jaringan tradisional, seperti aturan firewall. Ada juga konstruksi asli Kubernetes yang mengontrol arus lalu lintas dalam kluster, seperti NetworkPolicy sumber daya. Kami sangat menyarankan Anda merujuk ke dokumentasi Kubernetes untuk memahami konsep inti tentang pod yang terisolasi, dan kebijakan masuk dan keluar.

Membangun dan memelihara jaringan dan sistem yang aman

Persyaratan 1Instal dan pertahankan konfigurasi firewall untuk melindungi data pemegang kartu.

Dukungan fitur AKS

AKS mendukung penyebaran kluster dalam jaringan virtual pribadi sebagai kluster pribadi. Komunikasi antara cluster dan server API Kubernetes yang dikelola AKS melalui jaringan tepercaya. Dengan kluster pribadi, Anda dapat menggunakan Azure Virtual Network, Network Security Group (NSG), dan kontrol jaringan bawaan lainnya untuk mengamankan seluruh lingkungan data pemegang kartu (CDE). Ini akan melarang akses publik yang tidak sah antara internet dan lingkungan. Untuk detail tentang cara menyediakan kluster tersebut, lihat Membuat kluster Azure Kubernetes Service pribadi.

Azure Firewall dapat diintegrasikan dengan AKS dan dapat membatasi lalu lintas keluar dari kluster, yang merupakan komponen kunci dari CDE. Konfigurasinya dipermudah dengan Tag FQDN AKS. Proses yang direkomendasikan disediakan di Gunakan Azure Firewall untuk melindungi Penyebaran Azure Kubernetes Service (AKS).

Kluster AKS memerlukan beberapa akses internet publik. Batasi lalu lintas keluar ke internet menggunakan Azure Firewall dan NSGs di subnet kluster. Untuk informasi selengkapnya, lihat Mengontrol lalu lintas keluar untuk simpul kluster di Azure Kubernetes Service (AKS).

AKS secara opsional mendukung kemampuan untuk menentukan proksi HTTP, yang dapat digunakan untuk kontrol dan pemantauan lalu lintas keluar tambahan untuk kluster. Node kluster menggunakan konfigurasi proksi HTTP yang ditentukan untuk merutekan lalu lintas keluar. Selain itu, MutatingWebhook terdaftar untuk menyuntikkan informasi proksi ke dalam pod pada waktu pembuatan, sehingga disarankan agar beban kerja dapat mewarisi informasi proksi yang sama. Pod dapat mengambil alih informasi proksi, jadi disarankan untuk menggunakan proksi HTTP selain Azure Firewall.

Kluster AKS harus dibuat dengan plugin NetworkPolicy. Di AKS, Anda memiliki opsi antara Azure atau Calico, sebagai plugin Kebijakan Jaringan Anda. Dengan Calico Network Policy, Anda dapat menggunakan Kubenet atau Azure CNI. Untuk Azure Network Policy, Anda hanya dapat menggunakan Azure CNI (bukan Kubenet). Kebijakan Jaringan untuk simpul Windows hanya didukung dengan Calico. Plugin Azure dan Calico Network Policy sumber terbuka. Untuk informasi lebih lanjut tentang Project Calico, lihat whitepaper solusi PCI komprehensif, yang membahas banyak persyaratan firewall di bawah ini.

Tanggung jawab

Persyaratan	Tanggung Jawab
Persyaratan 1.1	Menetapkan dan menerapkan standar konfigurasi firewall dan router.
Persyaratan 1.2	Buat konfigurasi perute dan firewall yang membatasi koneksi antara jaringan yang tidak tepercaya dan komponen sistem apa pun di lingkungan data pemegang kartu.
Persyaratan 1.3	Larang akses publik langsung antara Internet dan komponen sistem apa pun di lingkungan data pemegang kartu.
Persyaratan 1.4	Instal perangkat lunak firewall pribadi atau fungsi setara pada perangkat komputasi portabel (termasuk perusahaan dan/atau milik karyawan) yang terhubung ke Internet saat berada di luar jaringan (misalnya, laptop yang digunakan oleh karyawan), dan yang juga digunakan untuk mengakses CDE.
Persyaratan 1.5	Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk pemantauan dan pengujian keamanan didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.

Persyaratan 1.1

Buat dan terapkan standar konfigurasi perute dan firewall yang mencakup hal berikut:

Persyaratan 1.1.1

Proses formal untuk menyetujui dan menguji semua koneksi jaringan dan perubahan pada konfigurasi perute dan firewall

Tanggung jawab

Jangan menerapkan konfigurasi secara manual, seperti dengan menggunakan portal Microsoft Azure atau Azure CLI secara langsung. Kami sarankan menggunakan Infrastructure as Code (IaC). Dengan IaC, infrastruktur dikelola melalui model deskriptif yang menggunakan sistem penerapan versi. Model IaC menghasilkan lingkungan yang sama setiap kali diterapkan. Contoh umum IaC adalah Azure Resource Manager, Bicep atau Terraform. Jika IaC bukan pilihan, miliki proses yang terdokumentasi dengan baik untuk melacak, menerapkan, dan menerapkan perubahan aturan firewall dengan aman. Rincian lebih lanjut disediakan sebagai bagian dari Persyaratan 11.2.

Anda harus menggunakan kombinasi berbagai kontrol jaringan, termasuk Azure Firewall, grup keamanan jaringan (NSGs), dan sumber daya Kubernetes NetworkPolicy.

Minimalkan jumlah orang yang dapat mengakses dan memodifikasi kontrol jaringan. Tentukan peran dan tanggung jawab yang jelas kepada tim. Misalnya, tim jaringan organisasi akan memvalidasi perubahan sesuai kebijakan tata kelola yang ditetapkan oleh tim TI. Memiliki proses persetujuan yang terjaga keamanannya yang melibatkan orang dan proses untuk menyetujui perubahan pada konfigurasi jaringan apa pun. Proses ini harus mencakup langkah untuk menguji semua kontrol jaringan. Memiliki dokumentasi terperinci yang menjelaskan prosesnya.

Persyaratan 1.1.2

Diagram jaringan saat ini yang mengidentifikasi semua koneksi antara lingkungan data pemegang kartu dan jaringan lain, termasuk jaringan nirkabel apa pun

Tanggung jawab

Sebagai bagian dari dokumentasi Anda, pertahankan diagram alur jaringan yang menunjukkan lalu lintas masuk dan keluar dengan kontrol keamanan. Ini termasuk arus lalu lintas dari jaringan lain termasuk jaringan nirkabel ke CDE. Diagram juga harus menunjukkan aliran dalam kluster. Ada beberapa persyaratan khusus untuk diagram, mereka harus menunjukkan sensor intrusi. Kontrol untuk

Gambar ini menunjukkan diagram jaringan implementasi referensi.

Unduh file Visio dari diagram ini.

Gambar 1.1.2 - Alur jaringan

Deskripsi alur ini ada di bagian berikut.

Anda dapat melihat topologi jaringan virtual Azure jika Anda memiliki Azure Network Watcher. Anda dapat melihat semua sumber daya dalam jaringan virtual, sumber daya yang terkait dengan sumber daya dalam jaringan virtual, dan hubungan antara sumber daya.

Persyaratan 1.1.3

Diagram saat ini yang memperlihatkan semua aliran data pemegang kartu di seluruh sistem dan jaringan.

Tanggung jawab

Sebagai bagian dari dokumentasi Anda, sertakan diagram alur data yang menunjukkan bagaimana data dilindungi saat istirahat dan dalam perjalanan.

Diagram harus menunjukkan bagaimana data mengalir ke dan dari beban kerja dan informasi apa yang diteruskan dari satu sumber daya ke sumber daya lainnya. Pastikan diagram tetap terkini. Tambahkan langkah sebagai bagian dari proses manajemen perubahan, untuk memperbarui diagram aliran data.

Karena arsitektur ini difokuskan pada infrastruktur dan bukan beban kerja, kami telah menghilangkan ilustrasi di sini.

Persyaratan 1.1.4

Persyaratan untuk firewall di tiap koneksi Internet dan antara jaringan sekitar (DMZ) dan zona jaringan internal

Tanggung jawab

Memiliki definisi yang jelas tentang apa yang mendefinisikan batas DMZ. Misalnya, lingkungan data pemegang kartu (CDE) berada dalam DMZ yang diamankan oleh firewall, kebijakan jaringan, dan kontrol lainnya. Untuk informasi selengkapnya, lihat Cloud DMZ.

Untuk infrastruktur PCI DSS, Anda bertanggung jawab untuk mengamankan CDE dengan menggunakan kontrol jaringan untuk memblokir akses tidak sah masuk dan keluar dari jaringan dengan CDE. Kontrol jaringan harus dikonfigurasi dengan benar untuk postur keamanan yang kuat, dan mereka harus diterapkan pada:

• Komunikasi antara komponen yang terletak dalam kluster.
• Komunikasi antara beban kerja dan komponen lain dalam jaringan tepercaya.
• Komunikasi antara beban kerja dan internet publik.

Arsitektur ini menggunakan teknologi firewall yang berbeda untuk memeriksa lalu lintas yang mengalir di kedua arah, ke dan dari kluster yang menjadi tuan rumah CDE:

• Azure Application Gateway terintegrasi web application firewall (WAF) digunakan sebagai perute lalu lintas dan untuk mengamankan lalu lintas masuk (ingress) ke kluster.

• Azure Firewall digunakan untuk mengamankan semua lalu lintas keluar (jalan keluar) dari jaringan dan subnetnya.

  Sebagai bagian dari pemrosesan operasi transaksi atau manajemen, kluster perlu berkomunikasi dengan entitas eksternal. Misalnya, kluster mungkin memerlukan komunikasi dengan bidang kontrol AKS, mendapatkan pembaruan Windows dan paket, dan interaksi beban kerja dengan API eksternal. Beberapa interaksi tersebut mungkin melalui HTTP dan harus dianggap sebagai vektor serangan. Vektor tersebut adalah target untuk serangan man-in-the-middle yang dapat mengakibatkan eksfiltrasi data. Menambahkan firewall untuk jalan keluar mengurangi lalu lintas ancaman itu.

  Sebaiknya komunikasi pod-to-pod dienkripsi TLS. Praktik ini ditunjukkan dalam implementasi referensi dengan menggunakan mesh mTLS.

• NSG ditambahkan untuk mengamankan lalu lintas antara kluster dan komponen lain dalam infrastruktur. Misalnya, dalam implementasi referensi, ada NSGs pada subnet dengan kumpulan node yang memblokir upaya akses SSH. Hanya lalu lintas dari jaringan virtual yang diizinkan.

  Saat Anda menambahkan komponen ke arsitektur, pertimbangkan untuk menambahkan lebih banyak NSG yang memungkinkan atau menolak jenis lalu lintas pada batas subnet. Karena setiap kumpulan node berada di subnet khusus, terapkan aturan yang lebih spesifik berdasarkan pola lalu lintas yang diharapkan dari beban kerja Anda.

• KubernetesNetworkPolicy

  Secara default, tidak ada batasan pada komunikasi pod-to-pod. Anda perlu menerapkan NetworkPolicy komunikasi dalam kluster, dimulai dengan jaringan tanpa kepercayaan dan membuka jalur sesuai kebutuhan. Implementasi referensi menunjukkan jaringan zero-trust di a0005-i dan a0005-o namespace. Semua namespace (kecuali kube-system, gatekeeper-system, dan AKS-provided namespace lainnya) telah membatasi NetworkPolicy penerapan. Definisi kebijakan akan bergantung pada pod yang berjalan di ruang tersebut. Pastikan Anda membuka jalur untuk kesiapan, keaktifan, dan probe startup. Juga, buka jalur sehingga oms-agent metrik tingkat node dapat dikirim. Pertimbangkan untuk menstandardisasi port di seluruh beban kerja sehingga Anda dapat memberikan Kebijakan yang konsisten NetworkPolicy dan Azure Policy untuk port kontainer yang diizinkan.

Persyaratan 1.1.5

Deskripsi grup, peran, dan tanggung jawab untuk pengelolaan komponen jaringan.

Tanggung jawab

Anda harus memberikan kontrol pada alur jaringan dan komponen yang terlibat. Infrastruktur yang dihasilkan akan memiliki beberapa segmen jaringan, masing-masing dengan banyak kontrol, dan setiap kontrol memiliki tujuan. Pastikan dokumentasi Anda tidak hanya memiliki cakupan yang luas dari perencanaan jaringan ke semua konfigurasi tetapi juga memiliki rincian tentang kepemilikan. Memiliki garis tanggung jawab yang jelas dan peran yang bertanggung jawab untuk mereka.

Misalnya, ketahui siapa yang bertanggung jawab atas tata kelola pengamanan jaringan antara Azure dan internet. Di suatu perusahaan, tim TI bertanggung jawab atas konfigurasi dan pemeliharaan aturan Azure Firewall, Web Application Firewall (WAF), NSGs, dan lalu lintas jaringan lainnya. Mereka mungkin juga bertanggung jawab atas alokasi jaringan dan subnet virtual di seluruh perusahaan, dan perencanaan alamat IP.

Pada tingkat beban kerja, operator kluster bertanggung jawab untuk mempertahankan Zero-Trust melalui kebijakan jaringan. Selain itu, tanggung jawab mungkin termasuk komunikasi dengan bidang kontrol Azure, API Kubernetes, dan teknologi pemantauan.

Selalu mulai dengan strategi tolak-semua. Berikan izin hanya ketika ada kebutuhan bisnis atau pembenaran peran.

Persyaratan 1.1.6

Dokumentasi persetujuan dan pertimbangan bisnis untuk penggunaan semua layanan, protokol, dan port yang diperbolehkan, termasuk dokumentasi fitur keamanan yang diterapkan untuk protokol tersebut yang dianggap tidak aman.

Tanggung jawab

Memiliki dokumentasi terperinci yang menjelaskan layanan, protokol, dan port yang digunakan dalam kontrol jaringan. Tolak semua kecuali untuk port yang diizinkan secara eksplisit. Dokumen pertimbangan bisnis dan fitur keamanan didokumentasikan jika penggunaan protokol tidak aman tidak dapat dihindari. Berikut adalah beberapa contoh dari implementasi referensi untuk Azure Firewall. Aturan firewall harus jadi lingkup yang eksklusif untuk sumber daya terkait mereka. Artinya, hanya lalu lintas dari sumber tertentu yang diizinkan untuk masuk ke target FQDN tertentu. Berikut adalah beberapa kasus untuk memungkinkan lalu lintas.

Aturan	Protocol:Port	Sumber	Tujuan	Justifikasi
Memungkinkan komunikasi yang aman antara node dan bidang kontrol.	HTTPS:443	Rentang alamat IP resmi yang ditetapkan ke kumpulan node kluster	Daftar target FQDN di bidang kontrol AKS. Ini ditentukan dengan AzureKubernetesService tag FQDN.	Node memerlukan akses ke bidang kontrol untuk alat manajemen, informasi status dan konfigurasi, dan informasi tentang node mana yang dapat diskalakan.
Memungkinkan komunikasi yang aman antara Flux dan GitHub.	HTTPS:443	Kumpulan node AKS	github.com,api.github.com	Flux adalah integrasi pihak ketiga yang berjalan pada node. Ini menyinkronkan konfigurasi kluster dengan repositori GitHub pribadi.

Persyaratan 1.1.7

Persyaratan untuk meninjau rangkaian aturan perute dan firewall setidaknya setiap enam bulan.

Tanggung jawab

Memiliki proses setidaknya setiap enam bulan untuk meninjau konfigurasi jaringan dan aturan yang dicakup. Ini akan memastikan jaminan keamanan saat ini dan valid. Pastikan Anda meninjau konfigurasi ini:

• Aturan Azure Firewall.
• Aturan NSG.
• Aturan Azure Application Gateway dan WAF.
• Kebijakan jaringan Kubernetes asli.
• Kontrol firewall pada sumber daya Azure yang berlaku. Misalnya, arsitektur ini menggunakan aturan tentang Azure Container Registry yang hanya memungkinkan lalu lintas dari titik akhir privat.
• Kontrol jaringan lain yang telah Anda tambahkan ke arsitektur.

Persyaratan 1.2

Buat konfigurasi perute dan firewall yang membatasi koneksi antara jaringan yang tidak tepercaya dan komponen sistem apa pun di lingkungan data pemegang kartu.

Tanggung jawab

Dalam arsitektur ini, kluster AKS adalah komponen kunci dari lingkungan data pemegang kartu (CDE). Kami sangat menyarankan agar kluster tersebut digunakan sebagai kluster privat untuk meningkatkan keamanan. Di kluster privat, lalu lintas jaringan antara server API Kubernetes yang dikelola AKS dan kumpulan node Anda bersifat privat. Server API diekspos melalui titik akhir privat di jaringan kluster.

Namun, Anda juga dapat memilih kluster publik, tetapi desain ini tidak disarankan untuk kluster yang berisi beban kerja yang diatur. Server API akan diekspos ke internet. Catatan DNS akan selalu dapat ditemukan. Jadi, Anda perlu memiliki kontrol untuk menjaga API kluster terlindungi dari akses publik. Jika menggunakan kluster publik diperlukan, maka pendekatan yang disarankan adalah memiliki kontrol yang ketat melalui kontrol akses berbasis peran Kubernetes (RBAC), dipasangkan dengan fitur rentang IP Resmi AKS untuk membatasi siapa yang dapat mengakses AKS API Server. Namun, solusi ini tidak disarankan untuk kluster yang berisi beban kerja yang diatur.

Saat memproses data pemegang kartu (CHD), kluster perlu berinteraksi dengan jaringan yang dianggap tepercaya dan tidak tepercaya. Dalam arsitektur ini, kedua jaringan hub-spoke dalam perimeter beban kerja PCI-DSS 3.2.1 dianggap sebagai jaringan tepercaya.

Jaringan yang tidak tepercaya adalah jaringan di luar perimeter itu. Kategori ini mencakup hub dan spokes lain yang mungkin berada di infrastruktur yang sama, tetapi berada di luar perimeter beban kerja, internet publik, jaringan perusahaan, atau jaringan virtual di Azure atau platform cloud lainnya. Dalam arsitektur ini, jaringan virtual yang menjadi tuan rumah pembangun gambar tidak dipercaya karena tidak memiliki peran untuk dimainkan dalam penanganan PJK. Interaksi CDE dengan jaringan tersebut harus diamankan sesuai persyaratan. Dengan kluster privat ini, Anda dapat menggunakan Azure Virtual Network, NSG, dan fitur bawaan lainnya untuk mengamankan seluruh lingkungan.

Untuk informasi tentang kluster privat, lihat Membuat kluster Azure Kubernetes Service privat.

Persyaratan 1.2.1

Batasi lalu lintas masuk dan keluar yang diperlukan untuk lingkungan data pemegang kartu, dan tolak semua lalu lintas lainnya secara khusus.

Tanggung jawab

Secara desain, Azure Virtual Network tidak dapat langsung dijangkau oleh internet publik. Semua lalu lintas masuk (atau jalan masuk) harus melalui router lalu lintas menengah. Namun, semua komponen dalam jaringan dapat mencapai titik akhir publik. Lalu lintas keluar (atau jalan keluar) itu harus diamankan secara eksplisit yang hanya memungkinkan cipher aman dan TLS 1.2 atau nanti.

• Waf terintegrasi Azure Application Gateway mencegat semua lalu lintas ingress HTTP dan rute yang diperiksa lalu lintas ke kluster.

  Lalu lintas ini dapat berasal dari jaringan tepercaya atau tidak tepercaya. Application Gateway disediakan dalam subnet jaringan spoke dan diamankan oleh NSG. Saat lalu lintas masuk, aturan WAF memungkinkan atau menolak, dan merutekan lalu lintas ke backend yang dikonfigurasi. Misalnya, Application Gateway melindungi CDE dengan menolak jenis lalu lintas ini:

  • Semua lalu lintas yang tidak dienkripsi TLS.
  • Lalu lintas di luar rentang port untuk komunikasi pesawat kontrol dari infrastruktur Azure.
  • Permintaan probe kesehatan yang dikirim oleh entitas selain penyeimbang beban internal dalam kluster.

• Azure Firewall digunakan untuk mengamankan semua lalu lintas keluar (jalan keluar) dari jaringan tepercaya dan tidak tepercaya.

  Azure Firewall disediakan dalam subnet jaringan hub. Untuk menegakkan Azure Firewall sebagai titik keluar tunggal, rute yang ditentukan pengguna (UDR) digunakan pada subnet yang mampu menghasilkan lalu lintas keluar. Ini termasuk subnet dalam jaringan yang tidak tepercaya, seperti jaringan virtual pembuat gambar. Setelah lalu lintas mencapai Azure Firewall, beberapa aturan cakupan diterapkan yang memungkinkan lalu lintas dari sumber tertentu masuk ke target tertentu.

  Untuk informasi selengkapnya, lihat Menggunakan Azure Firewall untuk melindungi Penyebaran Azure Kubernetes Service (AKS).

• Secara opsional, dimungkinkan untuk menggunakan proksi HTTP untuk memantau dan mengamankan lalu lintas keluar (keluar), dari kluster ke sumber daya eksternal.

  Selain firewall, beberapa organisasi mungkin ingin menggunakan proksi HTTP untuk memiliki kontrol tambahan pada egress. Kami menyarankan Anda untuk tetap memiliki rute yang ditentukan pengguna, buka firewall dan untuk membatasi lalu lintas keluar untuk hanya masuk ke proksi HTTP. Dengan penyiapan ini, jika pod mencoba mengambil alih proksi, firewall masih dapat memblokir lalu lintas keluar.

  Untuk informasi selengkapnya, lihat dukungan proksi HTTP di Azure Kubernetes Service.

Kluster mungkin memerlukan akses layanan lain melalui internet publik. Jika Anda menggunakan perangkat lunak antimalware pihak ketiga, itu perlu untuk mendapatkan definisi virus dari server melalui internet publik.

Interaksi dengan titik akhir layanan Azure lainnya melalui tulang punggung Azure. Misalnya, sebagai bagian dari operasi reguler, kluster perlu mendapatkan sertifikat dari toko kunci terkelola, menarik gambar dari registri kontainer, dan sebagainya. Pastikan interaksi tersebut bersifat privat dan aman menggunakan Azure Private Link.

Selain aturan firewall dan jaringan privat, aliran NSG juga diamankan melalui aturan. Berikut beberapa contoh dari arsitektur ini di mana CDE dilindungi dengan menolak lalu lintas:

• NSGs, pada subnet yang memiliki kumpulan node, menolak akses SSH ke node-nya. Memiliki proses di tempat untuk akses darurat tepat waktu sambil tetap mempertahankan prinsip penolakan semua.
• NSG, pada subnet yang memiliki jump box untuk menjalankan alat manajemen, menyangkal semua lalu lintas kecuali dari Azure Bastion di jaringan hub.
• NSGs, pada subnet yang memiliki titik akhir privat ke Azure Key Vault dan Azure Container Registry, menolak semua lalu lintas kecuali dari penyeimbang beban internal dan lalu lintas melalui Azure Private Link.

Persyaratan 1.2.2

Amankan dan sinkronkan file konfigurasi perute.

Tanggung jawab

Memiliki mekanisme untuk mendeteksi delta antara keadaan yang digunakan yang sebenarnya dan keadaan yang diinginkan. Infrastructure as Code (IaC) adalah pilihan tepat untuk tujuan itu. Misalnya, templat Azure Resource Manager memiliki catatan status yang diinginkan.

Aset penyebaran, seperti templat ARM, harus dikontrol sumber sehingga Anda memiliki riwayat semua perubahan. Mengumpulkan informasi dari log aktivitas Azure, log alur penyebaran, dan log penyebaran Azure. Sumber-sumber tersebut akan membantu Anda menyimpan jejak aset yang digunakan.

Di kluster, kontrol jaringan seperti kebijakan jaringan Kubernetes juga harus mengikuti alur yang dikendalikan sumber. Dalam implementasi ini, Flux digunakan sebagai operator GitOps. Saat Anda menyinkronkan konfigurasi kluster seperti kebijakan jaringan, riwayat Git yang dikombinasikan dengan log Flux dan API dapat menjadi sumber riwayat konfigurasi.

Persyaratan 1.2.3

Instal firewall perimeter antara semua jaringan nirkabel dan lingkungan data pemegang kartu, serta konfigurasikan firewall ini untuk menolak atau, jika lalu lintas diperlukan untuk tujuan bisnis, mengizinkan hanya lalu lintas yang sah antara lingkungan nirkabel dan lingkungan data pemegang kartu.

Tanggung jawab

Node AKS dan kumpulan node tidak boleh dijangkau dari jaringan nirkabel. Selain itu, permintaan ke server API Kubernetes harus ditolak. Akses ke komponen tersebut dibatasi ke subnet yang diizinkan dan diamankan.

Secara umum, batasi akses dari lalu lintas lokal ke jaringan spoke.

Persyaratan 1.3

Larang akses publik langsung antara Internet dan komponen sistem apa pun di lingkungan data pemegang kartu.

Tanggung jawab

Kolam node kluster AKS beroperasi dalam jaringan virtual dan terisolasi dari jaringan publik seperti internet. Pertahankan isolasi dengan mencegah asosiasi IP publik ke node kluster, dan dengan menerapkan aturan NSG pada subnet kluster untuk memastikan lalu lintas internet diblokir. Untuk informasi tentang akses terkontrol, lihat bagian DMZ.

Kluster AKS memiliki kumpulan node sistem yang menghosting pod sistem kritis. Bahkan pada kumpulan node pengguna, ada pod yang menjalankan layanan lain yang berpartisipasi dalam operasi kluster. Misalnya, pod mungkin menjalankan Flux untuk menyinkronkan konfigurasi kluster ke repositori GitHub, atau pengontrol jalan masuk untuk merutekan lalu lintas ke pod beban kerja. Terlepas dari jenis kumpulan node, semua node harus dilindungi.

Komponen sistem penting lainnya adalah server API yang digunakan untuk melakukan tugas Kubernetes asli, seperti mempertahankan keadaan kluster dan konfigurasi. Keuntungan menggunakan kluster pribadi adalah titik akhir server API tidak diekspos secara default. Untuk informasi tentang kluster privat, lihat Membuat kluster Azure Kubernetes Service privat.

Interaksi dengan titik akhir lainnya juga harus diamankan. Salah satu caranya adalah dengan membatasi komunikasi melalui jaringan pribadi. Misalnya, mintalah gambar tarik kluster dari Azure Container Registry melalui tautan pribadi.

Persyaratan 1.3.1

Terapkan DMZ untuk membatasi lalu lintas masuk ke hanya komponen sistem yang memberikan layanan, protokol, dan port yang sah dapat diakses secara publik.

Tanggung jawab

Berikut beberapa praktik terbaik:

• Jangan mengonfigurasi alamat IP publik pada node kumpulan node.
• Gunakan Azure Policy untuk memastikan Kubernetes tidak mengekspos load balancer publik. Lalu lintas di dalam kluster harus dialihkan melalui penyeimbang beban internal.
• Hanya mengekspos penyeimbang beban internal ke Azure Application Gateway yang terintegrasi dengan WAF.
• Semua kontrol jaringan harus menentukan batasan sumber, tujuan, port, dan protokol, jika berlaku.
• Jangan mengekspos server API ke internet. Saat Anda menjalankan kluster dalam mode pribadi, titik akhir tidak terbuka dan komunikasi antara kumpulan node dan server API melalui jaringan privat.

Pengguna dapat menerapkan jaringan perimeter untuk melindungi kluster AKS. Untuk informasi, lihat Cloud DMZ.

Persyaratan 1.3.2

Batasi lalu lintas Internet masuk ke alamat IP dalam DMZ.

Tanggung jawab

Dalam jaringan kluster, memiliki NSG pada subnet dengan penyeimbang beban internal. Konfigurasikan aturan untuk hanya menerima lalu lintas dari subnet yang memiliki Azure Application Gateway yang terintegrasi dengan WAF. Di dalam kluster AKS, gunakan Kubernetes NetworkPolicies untuk membatasi lalu lintas masuk ke pod.

Persyaratan 1.3.3

Menerapkan langkah-langkah anti-spoofing untuk mendeteksi dan memblokir alamat IP sumber palsu memasuki jaringan.

Tanggung jawab Azure

Azure menerapkan pemfilteran jaringan untuk mencegah lalu lintas palsu dan membatasi lalu lintas masuk dan keluar ke komponen platform tepercaya.

Persyaratan 1.3.4

Jangan perbolehkan lalu lintas keluar yang tidak sah dari lingkungan data pemegang kartu ke Internet.

Tanggung jawab

Berikut adalah cara di mana Anda dapat memblokir lalu lintas keluar yang tidak sah:

• Terapkan semua lalu lintas keluar (keluar) dari kluster AKS untuk melalui Azure Firewall dengan menggunakan rute yang ditentukan pengguna (UDR) pada semua subnet kluster. Ini termasuk subnet dengan sistem dan kumpulan node pengguna.
• Batasi lalu lintas keluar dengan menambahkan NSGs pada subnet dengan kumpulan node.
• Gunakan Kubernetes NetworkPolicies untuk membatasi lalu lintas keluar dari pod.
• Gunakan mesh layanan untuk menangani kebijakan tambahan. Misalnya, jika Anda hanya mengizinkan lalu lintas terenkripsi TLS antar pod, proxy mesh layanan dapat menangani verifikasi TLS. Contoh itu ditunjukkan dalam implementasi ini. Envoy digunakan sebagai proxy.
• Mencegah penambahan alamat IP publik ke jaringan dalam CDE kecuali dengan subnet yang secara eksplisit diotorisasi, seperti subnet Firewall.
• Gunakan proksi HTTP, selain Azure Firewall, untuk membatasi lalu lintas keluar (keluar) dari kluster AKS ke internet.
• Gunakan Azure Monitor Private Link Service (AMPLS) untuk memiliki log dari wawasan Kontainer yang dikirim melalui koneksi privat yang aman ke Azure Monitor. Pahami dampak mengaktifkan AMPLS.

Untuk mengetahui detailnya, lihat Mengontrol lalu lintas keluar untuk node kluster di Azure Kubernetes Service (AKS).

Persyaratan 1.3.5

Izinkan hanya koneksi 'yang sudah dibangun' masuk ke jaringan.

Tanggung jawab Azure

Azure menerapkan pemfilteran jaringan untuk mencegah lalu lintas palsu dan membatasi lalu lintas masuk dan keluar ke komponen platform tepercaya. Jaringan Azure dipisahkan untuk memisahkan lalu lintas pelanggan dari lalu lintas manajemen.

Persyaratan 1.3.6

Tempatkan komponen sistem yang menyimpan data pemegang kartu (seperti database) dalam zona jaringan internal, terpisah dari jaringan sekitar dan jaringan tidak terpercaya lain.

Tanggung jawab

Mengekspos sistem penyimpanan Anda hanya melalui jaringan privat, misalnya dengan menggunakan Private Link. Juga, batasi akses dari subnet kumpulan node yang memerlukannya. Jauhkan negara dari kluster dan di zona keamanan khusus sendiri.

Persyaratan 1.3.7

Jangan mengungkapkan alamat IP pribadi dan informasi perutean kepada pihak yang tidak berwenang.

Tanggung jawab

Untuk memenuhi persyaratan ini, kluster AKS publik bukanlah pilihan. Kluster privat menyimpan catatan DNS dari internet publik dengan menggunakan zona DNS privat. Namun, masih mungkin untuk Membuat kluster AKS privat dengan alamat DNS Publik. Jadi, disarankan untuk menonaktifkan fitur ini secara eksplisit dengan mengatur enablePrivateClusterPublicFQDNfalse untuk mencegah pengungkapan alamat IP privat pesawat kontrol Anda. Pertimbangkan untuk menggunakan Azure Policy untuk memberlakukan penggunaan kluster privat tanpa catatan DNS publik.

Selain itu, gunakan zona DNS privat untuk perutean antara subnet yang memiliki Azure Application Gateway yang terintegrasi dengan WAF, dan subnet yang memiliki penyeimbang beban internal. Pastikan tidak ada tanggapan HTTP yang menyertakan informasi IP privat di header atau badan. Pastikan bahwa log yang mungkin berisi catatan IP dan DNS tidak terekspos di luar kebutuhan operasional.

Layanan Azure yang tersambung melalui Private Link tidak memiliki catatan DNS publik yang mengekspos alamat IP Anda. Infrastruktur Anda harus memanfaatkan Private Link secara optimal.

Persyaratan 1.4

Instal perangkat lunak firewall pribadi atau fungsi setara pada perangkat komputasi portabel apa pun yang terhubung ke Internet saat berada di luar jaringan, dan yang juga digunakan untuk mengakses CDE.

Tanggung jawab

Klaster privat dikelola oleh pesawat kontrol AKS. Anda tidak memiliki akses ke node secara langsung. Untuk melakukan tugas administratif, Anda harus menggunakan alat manajemen seperti kubectl dari sumber daya komputasi terpisah. Pilihannya adalah menggunakan kotak lompat dengan celah udara di mana Anda dapat menjalankan perintah. Juga lalu lintas masuk dan keluar dari kotak lompat harus dibatasi dan aman. Jika VPN digunakan untuk akses, pastikan mesin klien dikelola oleh kebijakan perusahaan dan semua kebijakan akses bersyarat sudah ada.

Dalam arsitektur ini, kotak lompat itu berada di subnet terpisah pada jaringan spoke. Akses masuk ke kotak lompat dibatasi dengan menggunakan NSG yang hanya memungkinkan akses melalui Azure Bastion melalui SSH.

Untuk menjalankan perintah tertentu pada jump box, Anda harus mencapai titik akhir publik. Misalnya, titik akhir yang dikelola oleh bidang manajemen Azure. Lalu lintas keluar itu harus aman. Mirip dengan komponen lain dalam jaringan spoke, lalu lintas keluar dari jump box dibatasi dengan menggunakan UDR yang memaksa lalu lintas HTTP untuk melalui Azure Firewall.

Persyaratan 1.5

Pastikan bahwa kebijakan keamanan dan prosedur operasional untuk pemantauan dan pengujian keamanan 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 terutama berlaku ketika Anda mengelola aturan Azure Firewall yang mengelompokkan kluaster AKS. Orang yang mengoperasikan lingkungan yang diatur harus diberi edukasi, diberi informasi, dan diberi insentif untuk mendukung jaminan keamanan. Ini sangat penting bagi orang-orang dengan akun yang diberikan hak administratif yang luas.

Persyaratan 2—Jangan gunakan default yang disediakan vendor untuk kata sandi sistem dan parameter keamanan lainnya.

Tanggung jawab

Persyaratan	Tanggung Jawab
Persyaratan 2.1	Selalu ubah default yang disediakan vendor dan hapus atau nonaktifkan akun default yang tidak perlu sebelum menginstal sistem di jaringan.
Persyaratan 2.2	Mengembangkan standar konfigurasi untuk semua komponen sistem. Pastikan bahwa standar ini mengatasi semua kerentanan keamanan yang diketahui dan konsisten dengan standar pengerasan sistem yang diterima industri.
Persyaratan 2.3	Enkripsikan semua akses administratif non-konsol menggunakan kriptografi yang kuat.
Persyaratan 2.4	Pertahankan inventaris komponen sistem yang berada dalam cakupan untuk PCI DSS.
Persyaratan 2.5	Memastikan bahwa kebijakan keamanan dan prosedur operasional untuk mengelola default vendor dan parameter keamanan lainnya didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.
Persyaratan 2.6	Penyedia hosting bersama harus melindungi lingkungan dan data pemegang kartu masing-masing entitas.

Jangan gunakan default yang diberikan vendor untuk kata sandi sistem dan parameter keamanan lainnya

Persyaratan 2.1

Selalu ubah default yang disediakan vendor dan hapus atau nonaktifkan akun default yang tidak perlu sebelum menginstal sistem di jaringan.

Tanggung jawab

Pengaturan default yang disediakan oleh vendor harus diubah. Pengaturan default adalah vektor serangan umum dan membuat sistem rentan terhadap serangan. Berikut adalah beberapa pertimbangan:

• Nonaktifkan akses administrator pada registri kontainer.
• Pastikan bahwa jump box dan build agent mengikuti prosedur manajemen pengguna, menghapus pengguna sistem yang dibutuhkan.
• Jangan membuat atau menyediakan akses kunci SSH ke node ke pengguna administrator. Jika akses darurat diperlukan, gunakan proses pemulihan Azure untuk mendapatkan akses tepat waktu.

Tanggung jawab Azure

ID Microsoft Entra memiliki kebijakan kata sandi yang diberlakukan pada kata sandi baru yang disediakan oleh pengguna. Jika Anda mengubah kata sandi, validasi kata sandi yang lebih lama diperlukan. Kata sandi reset administrator harus diubah saat login berikutnya.

Persyaratan 2.1.1

Untuk lingkungan nirkabel yang tersambung ke lingkungan data pemegang kartu atau yang mengirim data pemegang kartu, ubah SEMUA default vendor nirkabel saat penginstalan, termasuk namun tidak terbatas pada kunci enkripsi nirkabel, kata sandi, dan string komunitas SNMP default.

Tanggung jawab

Arsitektur dan implementasi ini tidak dirancang 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 2.2

Mengembangkan standar konfigurasi untuk semua komponen sistem.

Tanggung jawab

Menerapkan rekomendasi di tolok ukur keamanan Azure. Ini memberikan pandangan tunggal dan terkonsolidasi tentang rekomendasi keamanan Azure, yang mencakup kerangka kerja industri seperti CIS, NIST, PCI-DSS 3.2.1, dan lainnya. Gunakan fitur Microsoft Defender untuk Cloud dan Azure Policy untuk membantu melacak terhadap standar. Tolok ukur keamanan Azure adalah inisiatif default untuk Microsoft Defender untuk Cloud. Pertimbangkan untuk membuat pemeriksaan otomatis tambahan di Azure Policy dan Azure Tenant Security Solution (AzTS).

Dokumentasikan status konfigurasi yang diinginkan dari semua komponen dalam CDE, terutama untuk node AKS, jump box, build agent, dan komponen lain yang berinteraksi dengan kluster.

Untuk informasi selengkapnya, lihat tolok ukur keamanan Azure.

Tanggung Jawab Azure

Azure menyediakan standar konfigurasi keamanan yang konsisten dengan standar pengerasan yang diterima industri. Standar ditinjau setidaknya setiap tahun.

Persyaratan 2.2.1

Menerapkan hanya satu fungsi utama per server untuk mencegah fungsi yang memerlukan tingkat keamanan yang berbeda dari hidup berdampingan pada server yang sama. (Misalnya, server web, server database, dan DNS harus diimplementasikan pada server terpisah.)

Tanggung jawab

Strategi utamanya adalah memberikan tingkat pemisahan yang diperlukan. Cara yang disukai adalah dengan menyebarkan komponen di dalam dan di luar cakupan dalam kluster terpisah. Pahami bahwa ini menghasilkan peningkatan biaya untuk infrastruktur tambahan dan pemeliharaan overhead. Pendekatan lain adalah dengan menemukan bersama semua komponen dalam kluster bersama. Atau, gunakan strategi segmentasi untuk mempertahankan pemisahan. Misalnya, memiliki kumpulan node terpisah dalam kluster.

Dalam implementasi referensi, pendekatan kedua ditunjukkan dengan aplikasi layanan mikro yang disebarkan ke satu kluster. Aplikasi ini memiliki dua set layanan; satu set memiliki pod dalam cakupan dan yang lainnya di luar cakupan. Kedua set tersebar di dua kumpulan simpul pengguna. Dengan penggunaan noda Kubernetes, pod dalam cakupan dan di luar cakupan disebarkan ke simpul yang terpisah dan mereka tidak pernah berbagi simpul VM atau ruang IP jaringan.

Untuk teknologi kontainer, segmentasi itu disediakan secara default karena hanya satu contoh kontainer yang bertanggung jawab atas satu fungsi dalam sistem.

Beban kerja harus menggunakan identitas yang dikelola pod. Itu tidak boleh mewarisi identitas tingkat kluster atau node-level.

Gunakan penyimpanan eksternal alih-alih penyimpanan on-node (in-cluster) jika memungkinkan. Simpan pod kluster yang disediakan khusus untuk pekerjaan yang harus dilakukan sebagai bagian dari pengoperasian pemrosesan data pemegang kartu. Pindahkan operasi di luar cakupan di luar kluster. Panduan ini berlaku untuk build agents, beban kerja yang tidak terkait, atau aktivitas seperti memiliki kotak lompat di dalam kluster.

Persyaratan 2.2.2

Aktifkan hanya layanan, protokol, daemon, dll., yang diperlukan untuk fungsi sistem.

Tanggung jawab

Tinjau fitur dan implikasinya sebelum mengaktifkannya. Pengaturan default mungkin menyertakan fitur yang tidak Anda butuhkan, dan fitur tersebut mungkin memerlukan visibilitas ke dalam beban kerja. Contohnya adalah sandi dalam kebijakan SSL default untuk Azure Application Gateway. Periksa apakah kebijakan tersebut terlalu permisif. Rekomendasinya adalah membuat kebijakan khusus dengan hanya memilih sandi yang Anda butuhkan.

Untuk komponen di mana Anda memiliki kontrol penuh, hapus semua layanan sistem yang tidak perlu dari gambar (misalnya jump box dan build agent).

Untuk komponen di mana Anda hanya memiliki visibilitas, seperti node AKS, dokumentasikan apa yang diinstal Azure pada node. DaemonSets Pertimbangkan untuk menggunakan untuk menyediakan audit tambahan yang diperlukan untuk komponen yang dikendalikan cloud ini.

Persyaratan 2.2.3

Terapkan fitur keamanan tambahan untuk setiap layanan, protokol, atau daemon yang diperlukan yang dianggap tidak aman.

Tanggung jawab

Application Gateway memiliki WAF terintegrasi, dan menegosiasikan jabat tangan TLS untuk permintaan yang dikirim ke titik akhir publiknya, hanya memungkinkan sandi yang aman. Implementasi referensi hanya mendukung TLS 1.2 dan sandi yang disetujui.

Misalkan Anda memiliki perangkat lama yang perlu berinteraksi dengan CDE melalui Azure Application Gateway. Untuk itu, Application Gateway harus mengaktifkan protokol yang tidak aman. Dokumentasikan pengecualian itu dan pantau apakah protokol tersebut digunakan di luar perangkat lama tersebut. Nonaktifkan protokol itu segera setelah interaksi lama dihentikan.

Selain itu, Application Gateway tidak boleh menanggapi permintaan di port 80. Jangan melakukan pengalihan di tingkat aplikasi. Implementasi referensi ini memiliki aturan NSG tentang pemblokiran lalu lintas port 80. Aturannya ada di subnet dengan Application Gateway.

Jika beban kerja di kluster Anda tidak dapat mematuhi kebijakan organisasi di sekitar profil kepatuhan keamanan atau kontrol lainnya (misalnya, batas dan kuota), maka pastikan pengecualian didokumentasikan. Anda harus memantau untuk memastikan bahwa hanya mengharapkan fungsi yang dilakukan.

Persyaratan 2.2.4

Konfigurasikan parameter keamanan sistem untuk mencegah penyalahgunaan.

Tanggung jawab

Semua layanan Azure yang digunakan dalam arsitektur harus mengikuti rekomendasi yang disediakan oleh tolok ukur keamanan Azure. Rekomendasi ini memberi Anda titik awal untuk memilih pengaturan konfigurasi keamanan tertentu. Juga, bandingkan konfigurasi Anda dengan implementasi dasar untuk layanan tersebut. Untuk informasi selengkapnya tentang garis dasar keamanan, lihat Garis dasar keamanan untuk Azure.

Pengontrol penerimaan Open Policy Agent bekerja bersama dengan Azure Policy untuk mendeteksi dan mencegah kesalahan konfigurasi pada kluster. Misalkan ada kebijakan organisasi yang tidak memungkinkan alokasi IP publik pada node. Ketika alokasi tersebut terdeteksi, itu ditandai untuk audit atau ditolak berdasarkan tindakan yang ditentukan dalam definisi kebijakan.

Di tingkat infrastruktur, Anda dapat menerapkan pembatasan pada jenis dan konfigurasi sumber daya Azure. Gunakan Azure Policy untuk mencegah kasus tersebut. Dalam implementasi referensi ini, ada kebijakan yang menolak pembuatan kluster AKS yang tidak bersifat pribadi.

Secara rutin memastikan semua pengecualian didokumenkan dan ditinjau.

Tanggung jawab Azure

Azure memastikan bahwa hanya personel yang berwenang yang dapat mengonfigurasi kontrol keamanan platform Azure, dengan menggunakan kontrol akses multifaktor dan kebutuhan bisnis yang terdokumentasi.

Persyaratan 2.2.5

Hapus semua fungsionalitas yang tidak diperlukan, seperti skrip, driver, fitur, subsistem, sistem file, dan server web yang tidak perlu.

Tanggung jawab

Jangan menginstal perangkat lunak pada jump box atau build agents yang tidak berpartisipasi dalam pemrosesan transaksi atau memberikan pengamatan untuk persyaratan kepatuhan, seperti agen keamanan. Rekomendasi ini juga berlaku untuk entitas kluster, seperti DaemonSet dan pod. Pastikan semua instalasi terdeteksi dan dicatat.

Persyaratan 2.3

Enkripsikan semua akses administratif non-konsol menggunakan kriptografi yang kuat.

Tanggung jawab

Semua akses administratif ke kluster harus dilakukan dengan menggunakan konsol. Jangan mengekspos bidang kontrol kluster.

Tanggung jawab Azure

Azure memastikan penggunaan kriptografi yang kuat diberlakukan saat mengakses infrastruktur hypervisor. Ini memastikan bahwa pelanggan yang menggunakan Portal Manajemen Microsoft Azure dapat mengakses konsol layanan / IaaS mereka dengan kriptografi yang kuat.

Persyaratan 2.4

Pertahankan inventaris komponen sistem yang berada dalam cakupan untuk PCI DSS.

Tanggung jawab

Semua sumber daya Azure yang digunakan dalam arsitektur harus ditandai dengan benar. Tag membantu dalam klasifikasi data dan menunjukkan apakah layanan dalam lingkup atau di luar lingkup. Penandaan yang teliti akan memungkinkan Anda untuk meminta sumber daya, menyimpan inventaris, membantu melacak biaya, dan mengatur peringatan. Juga menyimpan snapshot dari dokumentasi itu secara berkala.

Hindari menandai sumber daya dalam lingkup atau di luar cakupan pada tingkat granular. Seiring berkembangnya solusi, sumber daya di luar cakupan mungkin menjadi ruang lingkup bahkan jika mereka secara tidak langsung berinteraksi atau berdekatan dengan data pemegang kartu. Sumber daya ini tunduk pada audit, dan dapat menjadi bagian dari sampel yang representatif selama audit. Pertimbangkan untuk menandai pada tingkat yang lebih tinggi, di tingkat langganan dan kluster.

Untuk informasi tentang pertimbangan penandaan, lihat Panduan penamaan sumber daya dan penandaan keputusan.

Tandai objek in-cluster dengan menerapkan label Kubernetes. Dengan cara ini Anda dapat mengatur objek, memilih kumpulan objek, dan melaporkan inventaris.

Persyaratan 2.5

Memastikan bahwa kebijakan keamanan dan prosedur operasional untuk mengelola default vendor dan parameter keamanan lainnya didokumentasikan, digunakan, dan diketahui oleh semua pihak yang terkena dampak.

Tanggung jawab

Sangat penting bagi Anda untuk memiliki dokumentasi menyeluruh tentang proses dan kebijakan. Personel harus dilatih dalam fitur keamanan dan pengaturan konfigurasi masing-masing sumber daya Azure. Orang yang mengoperasikan lingkungan yang diatur harus diberi edukasi, diberi informasi, dan diberi insentif untuk mendukung jaminan keamanan. Ini sangat penting bagi orang-orang dengan akun yang diberikan hak administratif yang luas.

Persyaratan 2.6

Penyedia hosting bersama harus melindungi lingkungan dan data pemegang kartu masing-masing entitas.

Tanggung jawab

Azure memberikan jaminan keamanan untuk komponen lingkungan yang dihosting yang dibagikan. Sangat disarankan agar Anda memperlakukan simpul AKS Anda sebagai host khusus untuk beban kerja ini. Artinya, semua komputasi harus dalam satu model penyewa dan tidak dibagikan dengan beban kerja lain yang mungkin Anda operasikan.

Jika isolasi komputasi lengkap diinginkan di tingkat infrastruktur Azure, Anda dapat Menambahkan Azure Dedicated Host ke kluster Azure Kubernetes Service (AKS). Penawaran ini menyediakan server fisik yang didedikasikan untuk beban kerja Anda, memungkinkan Anda menempatkan simpul AKS langsung ke host yang disediakan ini. Pilihan arsitektur ini memiliki dampak perencanaan biaya & kapasitas yang signifikan dan tidak khas untuk sebagian besar skenario.

Langkah berikutnya

Lindungi data pemegang kartu yang tersimpan. Enkripsikan transmisi data pemegang kartu di seluruh jaringan publik yang terbuka.

Sumber daya terkait

• Desain arsitektur Azure Kubernetes Service (AKS)
• Pengenalan kluster yang diatur AKS untuk PCI-DSS 3.2.1 (Bagian 1 dari 9)
• Arsitektur kluster yang diatur AKS untuk PCI-DSS 3.2.1 (Bagian 2 dari 9)
• Arsitektur dasar untuk klaster Azure Kubernetes Service (AKS)
• Garis besar AKS untuk kluster multiregion