Bagikan melalui

Keamanan jaringan untuk kluster yang diatur AKS untuk PCI DSS 4.0.1

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

Artikel ini adalah bagian dari seri. Baca pengenalan.

Tema utama standar PCI DSS 4.0.1 adalah keamanan, dengan persyaratan yang diperluas untuk segmentasi jaringan, pencakupan berbasis risiko, dan pemantauan berkelanjutan. Topologi hub-spoke adalah pilihan alami untuk menyiapkan lingkungan jaringan 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 dan lapisan jaringan.

Saat Anda menghosting beban kerja di Kubernetes, tidak cukup untuk mengandalkan konstruksi jaringan tradisional, seperti aturan firewall. PCI DSS 4.0.1 menekankan penggunaan kontrol cloud-native dan Kubernetes-native untuk segmentasi dan komunikasi yang aman. Ada juga konstruksi asli Kubernetes yang mengontrol arus lalu lintas dalam kluster, seperti NetworkPolicy sumber daya. Kami sangat menyarankan agar Anda merujuk ke dokumentasi Kubernetes untuk memahami konsep inti tentang pod yang terisolasi dan kebijakan masuk dan keluar.

Penting

Panduan dan implementasi yang menyertainya dibangun pada arsitektur garis besar AKS, yang didasarkan pada topologi jaringan hub-spoke. Jaringan virtual hub berisi firewall untuk mengontrol lalu lintas egress, lalu lintas gateway dari jaringan lokal, dan jaringan ketiga untuk pemeliharaan. Jaringan virtual spoke berisi kluster AKS yang menyediakan lingkungan data pemegang kartu (CDE) dan menghosting beban kerja PCI DSS.

GitHub logoGitHub logoImplementasi Referensi Segera Hadir: Kluster dasar Azure Kubernetes Service (AKS) untuk implementasi referensi beban kerja yang diatur untuk PCI DSS 4.0.1 saat ini sedang diperbarui dan akan segera tersedia. Implementasi ini akan menunjukkan infrastruktur yang diatur yang menggambarkan penggunaan berbagai kontrol jaringan dan keamanan dalam CDE Anda. Ini termasuk kontrol jaringan asli Azure dan kontrol asli Kubernetes. Ini juga akan mencakup aplikasi untuk menunjukkan interaksi antara lingkungan dan beban kerja sampel. Fokus artikel ini adalah infrastruktur. Sampel tidak akan menunjukkan beban kerja PCI-DSS 4.0.1 yang sebenarnya.

Membangun dan memelihara jaringan dan sistem yang aman

Persyaratan 1: Menginstal dan memelihara 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). Konfigurasi ini melarang akses publik yang tidak sah antara internet dan lingkungan. Untuk detail tentang cara menyediakan kluster tersebut, lihat Membuat kluster Azure Kubernetes Service pribadi.

Anda dapat mengintegrasikan Azure Firewall dengan AKS dan membatasi lalu lintas keluar dari kluster, yang merupakan komponen utama CDE. Konfigurasi dipermudah dengan tag AKS FQDN. Proses yang direkomendasikan disediakan dalam Menggunakan 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 Anda gunakan 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 beberapa opsi untuk plugin Kebijakan Jaringan Anda, termasuk Calico, Manajemen Kebijakan Jaringan Azure, dan Cilium. Dengan kebijakan jaringan Calico, Anda dapat menggunakan Kubenet atau Azure CNI. Untuk Azure Network Policy Management, Anda hanya dapat menggunakan Azure CNI (bukan Kubenet). Plugin Azure dan Calico Network Policy sumber terbuka. Untuk informasi selengkapnya tentang Project Calico, lihat whitepaper solusi PCI komprehensif, yang membahas banyak persyaratan firewall yang diuraikan dalam PCI DSS 4.0.1.

PCI DSS 4.0.1 memperluas persyaratan untuk segmentasi jaringan, validasi cakupan berbasis risiko, dan tinjauan berkelanjutan konfigurasi firewall dan router. Gunakan alat keamanan jaringan cloud-native seperti jaringan virtual, kelompok keamanan, dan segmentasi mikro. Pastikan beban kerja dalam kontainer menggunakan isolasi namespace yang tepat dan protokol komunikasi yang aman. Menggabungkan pertahanan berlapis menggunakan kebijakan jaringan Kubernetes atau alat serupa di lingkungan kontainer.

Tanggung jawab Anda

Persyaratan Tanggung Jawab
Persyaratan 1.1 Menetapkan dan menerapkan standar konfigurasi firewall dan router, termasuk validasi cakupan berbasis risiko dan tinjauan reguler.
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 Anda

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 Bicep, templat Azure Resource Manager (templat ARM), atau Terraform. Jika IaC bukan pilihan, miliki proses yang didokumentasikan dengan baik untuk melacak, menerapkan, dan menyebarkan 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 Anda

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, termasuk bahwa mereka harus menunjukkan sensor intrusi dan kontrol apa pun yang diterapkan.

Gambar berikut menunjukkan diagram jaringan implementasi referensi:

Diagram topologi jaringan.

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 Anda

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 untuk memperbarui diagram aliran data sebagai bagian dari proses manajemen perubahan.

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

Persyaratan 1.1.4

Persyaratan untuk firewall di setiap koneksi internet dan antara zona demiliterisasi (DMZ) dan zona jaringan internal.

Tanggung jawab Anda

Memiliki definisi yang jelas tentang apa yang mendefinisikan batas DMZ. Misalnya, lingkungan data pemegang kartu (CDE) mungkin 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 yang tidak sah ke dalam dan ke luar jaringan yang berisi 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 ke dan dari kluster yang menghosting CDE:

  • Azure Application Gateway for Containers berfungsi sebagai router lalu lintas, dan firewall aplikasi web terintegrasi (WAF) mengamankan lalu lintas masuk (ingress) ke kluster.

  • Azure Firewall mengamankan semua lalu lintas keluar (keluar) dari jaringan apa pun dan subnetnya.

    Sebagai bagian dari pemrosesan transaksi atau operasi manajemen, kluster perlu berkomunikasi dengan titik akhir eksternal. Misalnya, kluster mungkin memerlukan komunikasi dengan sarana kontrol AKS, komunikasi dengan sistem operasi dan sistem pembaruan paket, dan banyak beban kerja berinteraksi 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 penggunaan autentikasi TLS bersama (mTLS).

  • NSG 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 dalam 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.

  • Objek Kubernetes NetworkPolicy digunakan untuk mengontrol komunikasi dalam kluster.

    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 layanan (kecuali kube-system, gatekeeper-system, dan namespace layanan yang disediakan AKS lainnya) memiliki kebijakan jaringan terbatas yang diterapkan. 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

Anda perlu 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 memiliki cakupan yang luas, mulai dari perencanaan jaringan hingga semua konfigurasi yang diterapkan. Ini juga harus mencakup detail tentang kepemilikan, dengan 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 perusahaan, tim TI biasanya bertanggung jawab atas konfigurasi dan pemeliharaan aturan Azure Firewall, aturan firewall aplikasi web (WAF), NSG, 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 Anda

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.

Tabel berikut ini mencantumkan contoh di mana Anda mungkin mengizinkan lalu lintas:

Peraturan Protokol:Port Sumber Tujuan Pembenaran
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 Anda

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

  • Aturan Azure Firewall.
  • Aturan NSG.
  • Azure Application Gateway untuk Kontainer dan aturan 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 ditambahkan ke arsitektur.

Jika Anda telah menghentikan beban kerja atau mengubah konfigurasi kluster sejak tinjauan sebelumnya, penting untuk memverifikasi bahwa asumsi apa pun yang Anda buat tentang pengecualian firewall yang diperlukan atau aturan NSG masih valid.

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 Anda

Dalam arsitektur ini, kluster AKS adalah komponen kunci dari lingkungan data pemegang kartu (CDE). Kami sangat menyarankan untuk menyebarkan kluster sebagai kluster privat untuk keamanan yang ditingkatkan. 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.

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, dan catatan DNS akan selalu dapat ditemukan, jadi Anda harus memiliki kontrol untuk menjaga API kluster tetap 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 4.0.1 dianggap sebagai jaringan tepercaya.

Jaringan yang tidak tepercaya adalah jaringan di luar perimeter itu. Jaringan yang tidak tepercaya meliputi:

  • Hub dan spoke lain yang mungkin berada di infrastruktur yang sama, tetapi berada di luar perimeter beban kerja.
  • Internet publik.
  • Jaringan perusahaan.
  • Jaringan virtual lainnya 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 jaringan virtual, NSG, dan fitur bawaan lainnya untuk mengamankan seluruh lingkungan.

Untuk informasi tentang kluster privat, lihat Membuat kluster Azure Kubernetes Service (AKS) 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 Anda

Secara desain, jaringan virtual Azure tidak dapat langsung dijangkau dari internet publik. Semua lalu lintas masuk (atau jalan masuk) harus melalui router lalu lintas menengah. Namun, secara default, semua komponen dalam jaringan dapat menjangkau titik akhir publik. Anda dapat menonaktifkan perilaku tersebut dengan mengonfigurasi subnet privat atau dengan menggunakan UDR untuk mengirim semua lalu lintas keluar melalui firewall. Lalu lintas keluar (atau keluar) tersebut harus diamankan secara eksplisit untuk memungkinkan hanya cipher aman dan TLS 1.2 atau yang lebih baru.

  • Azure Application Gateway untuk Kontainer dengan WAF terintegrasi mencegat semua lalu lintas masuk HTTP(S) dan merutekan lalu lintas yang telah diperiksa ke kluster.

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

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

  • Azure Firewall mengamankan semua lalu lintas keluar (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 agar Anda masih 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 (AKS).

Kluster mungkin memerlukan akses layanan lain melalui internet publik. Misalnya, jika Anda menggunakan perangkat lunak antimalware pihak ketiga, perlu 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, arus lalu lintas juga diamankan melalui aturan NSG. Contoh berikut mengilustrasikan arsitektur ini di mana CDE dilindungi dengan menolak lalu lintas:

  • NSG pada subnet yang memiliki kumpulan simpul menolak akses SSH apa pun ke simpul. Pastikan Anda memiliki proses untuk akses darurat just-in-time sambil tetap mempertahankan prinsip tolak-semua.
  • NSG pada subnet yang memiliki jump box untuk menjalankan alat manajemen menolak semua lalu lintas kecuali dari Azure Bastion di jaringan hub.
  • NSG 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 Anda

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, file Bicep atau templat Azure Resource Manager (templat ARM) mempertahankan catatan status yang diinginkan.

Aset penyebaran, seperti file Bicep, 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 Anda yang dikombinasikan dengan log Fluks dan API dapat menjadi sumber riwayat konfigurasi.

Persyaratan 1.2.3

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

Tanggung jawab Anda

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 Anda

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 status 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 (AKS) 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 Anda

Tinjau praktik terbaik berikut untuk menerapkan DMZ:

  • Jangan mengonfigurasi alamat IP publik pada simpul kumpulan simpul.
  • Gunakan Azure Policy untuk memastikan Kubernetes tidak mengekspos load balancer publik. Lalu lintas di dalam kluster harus dialihkan melalui penyeimbang beban internal.
  • Hanya paparkan load balancer internal ke Azure Application Gateway untuk Container 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 privat, titik akhir tidak terekspos dan komunikasi antara kumpulan simpul dan server API melalui jaringan privat.

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

Persyaratan 1.3.2

Batasi lalu lintas Internet masuk ke alamat IP dalam DMZ.

Tanggung jawab Anda

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 untuk Kontainer 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 izinkan lalu lintas keluar yang tidak sah dari lingkungan data pemegang kartu ke Internet.

Tanggung jawab Anda

Anda dapat memblokir lalu lintas keluar yang tidak sah menggunakan praktik terbaik berikut:

  • 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.

Nota

Anda dapat menggunakan Kubernetes NetworkPolicies untuk membatasi lalu lintas masuk dan keluar ke dan dari pod.

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 Anda

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 privat dan informasi perutean kepada pihak yang tidak berwenang.

Tanggung jawab Anda

Untuk memenuhi persyaratan ini, kluster AKS publik bukanlah pilihan. Kluster privat menyimpan catatan DNS dari internet publik dengan menggunakan zona DNS privat. Namun, masih dimungkinkan untuk Membuat kluster AKS privat dengan alamat DNS publik. Sebaiknya nonaktifkan fitur ini secara eksplisit dengan mengatur enablePrivateClusterPublicFQDN untuk false mencegah pengungkapan alamat IP privat sarana 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 untuk Kontainer yang terintegrasi dengan WAF dan subnet yang memiliki load balancer internal. Pastikan tidak ada tanggapan HTTP yang menyertakan informasi IP privat di header atau badan. Pastikan log apa pun 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 privat 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 Anda

Klaster privat dikelola oleh pesawat kontrol AKS. Anda tidak memiliki akses ke node secara langsung. Untuk 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 di jaringan spoke, lalu lintas keluar dari jump box dibatasi dengan menggunakan UDR yang memaksa lalu lintas HTTPS 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 Anda

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 Anda

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 disediakan 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 Anda

Pengaturan default yang disediakan oleh vendor harus diubah. Pengaturan default adalah vektor serangan umum dan membuat sistem rentan terhadap serangan. Pertimbangkan praktik terbaik berikut:

  • Nonaktifkan akses administrator pada registri kontainer.
  • Pastikan jump box dan agen build mengikuti prosedur manajemen pengguna, menghapus pengguna sistem yang tidak diperlukan.
  • Jangan membuat atau menyediakan akses kunci SSH ke simpul kepada 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 yang direset oleh administrator perlu diubah saat pengguna masuk berikutnya.

Persyaratan 2.1.1

Untuk lingkungan nirkabel yang terhubung ke lingkungan data pemegang kartu atau mengirimkan data pemegang kartu, ubah semua default vendor nirkabel saat penginstalan, termasuk tetapi tidak terbatas pada: kunci enkripsi nirkabel default, kata sandi, dan string komunitas SNMP.

Tanggung jawab Anda

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

Persyaratan 2.2

Mengembangkan standar konfigurasi untuk semua komponen sistem.

Tanggung jawab Anda

Terapkan rekomendasi dalam tolok ukur keamanan cloud Microsoft. Ini memberikan tampilan konsolidasi tunggal rekomendasi keamanan Azure, mencakup kerangka kerja industri seperti CIS, NIST, dan PCI DSS 4.0.1. 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 cloud Microsoft.

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 Anda

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.

Setiap pod beban kerja harus menggunakan identitasnya sendiri. 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 Anda

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 cipher dalam kebijakan TLS default untuk Azure Application Gateway untuk Kontainer. Periksa apakah kebijakan tersebut terlalu permisif. Rekomendasinya adalah membuat kebijakan khusus dengan hanya memilih sandi yang Anda butuhkan.

Untuk komponen tempat Anda memiliki kontrol penuh, hapus semua layanan sistem yang tidak perlu dari gambar. Misalnya, tinjau gambar untuk jump box dan bangun agen dan hapus komponen apa pun yang tidak diperlukan.

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 Anda

Application Gateway untuk Kontainer memiliki WAF terintegrasi dan menegosiasikan jabat tangan TLS untuk permintaan yang dikirim ke titik akhir publiknya, yang 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 memenuhi persyaratan tersebut, 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.

Application Gateway tidak boleh menanggapi permintaan pada 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 sekeliling profil kepatuhan keamanan atau kontrol lain (misalnya, batas dan kuota), pastikan pengecualian didokumenkan. Anda harus memantau untuk memastikan bahwa hanya mengharapkan fungsi yang dilakukan.

Persyaratan 2.2.4

Konfigurasikan parameter keamanan sistem untuk mencegah penyalahgunaan.

Tanggung jawab Anda

Semua layanan Azure yang digunakan dalam arsitektur harus mengikuti rekomendasi yang disediakan oleh tolok ukur keamanan cloud Microsoft. 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 kesalahan konfigurasi. Dalam implementasi referensi ini, ada kebijakan yang menolak pembuatan kluster AKS yang tidak bersifat pribadi.

Pastikan semua pengecualian didokumenkan dan ditinjau secara teratur.

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 Anda

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 Anda

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

Tanggung jawab Azure

Azure memastikan penggunaan kriptografi yang kuat diberlakukan saat mengakses infrastruktur hypervisor. Ini memastikan bahwa pelanggan yang menggunakan portal Azure dapat mengakses layanan dan konsol host mereka dengan menggunakan kriptografi yang kuat.

Persyaratan 2.4

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

Tanggung jawab Anda

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. Pemberian tag teliti memungkinkan Anda mengkueri sumber daya, menyimpan inventori, membantu melacak biaya, dan mengatur pemberitahuan. 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 inventarisasi.

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 Anda

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. Langkah-langkah ini sangat penting bagi setiap orang yang diberikan hak istimewa administratif yang luas.

Persyaratan 2.6

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

Tanggung jawab Anda

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 implikasi biaya yang signifikan dan membutuhkan perencanaan kapasitas yang cermat. Ini tidak khas untuk sebagian besar skenario.

Langkah selanjutnya

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

Lindungi data pemegang kartu

  • Last updated on