Penilaian risiko dan aset kode untuk kluster yang diatur AKS untuk PCI DSS 4.0.1

Artikel ini menjelaskan penilaian risiko dan pertimbangan aset kode untuk kluster Azure Kubernetes Service (AKS) yang menjalankan beban kerja sesuai dengan Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS 4.0.1).

Artikel ini adalah bagian dari seri. Baca pengenalan.

Rekomendasi dan contoh diambil dari implementasi referensi dalam bahan penyerta:

Unduh file Visio dari arsitektur ini.

Penting

Panduan dan implementasi yang menyertainya dibangun pada arsitektur garis besar AKS, yang didasarkan pada topologi hub-spoke. Jaringan virtual hub berisi firewall untuk mengontrol lalu lintas keluar, lalu lintas gateway dari jaringan lokal, dan jaringan ketiga untuk akses kluster SRE (insinyur keandalan situs). Ada dua jaringan virtual saling terhubung. Satu spoke berisi kluster AKS yang merupakan komponen lingkungan data pemegang kartu (CDE), dan menghosting beban kerja PCI DSS. Lainnya membangun gambar mesin virtual yang digunakan untuk akses SRE terkontrol ke lingkungan.

Implementasi Referensi logo GitHub 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 dengan aplikasi layanan mikro untuk membantu Anda mengalami infrastruktur dan mengilustrasikan kontrol jaringan dan keamanan. Aplikasi tidak akan mewakili atau menerapkan beban kerja PCI DSS yang sebenarnya.

Unduh file Visio dari arsitektur ini.

Komponen

Di bagian ini, kami akan menyoroti perbedaan antara dua arsitektur dan pembaruan yang diperlukan untuk PCI DSS 4.0.1, termasuk segmentasi yang ditingkatkan, pemantauan berkelanjutan, dan praktik pengembangan perangkat lunak yang aman. Jika Anda tidak terbiasa dengan komponen garis besar, lihat layanan Azure terkait untuk tautan ke dokumentasi produk.

Komponen	Deskripsi
Azure Firewall	Instans firewall mengamankan lalu lintas jaringan keluar. Tanpa lapisan keamanan ini, aliran mungkin melakukan komunikasi dengan layanan pihak ketiga yang berbahaya dan dapat mengekstrak data perusahaan yang sensitif.
Azure Bastion	Arsitektur dasar menyediakan subnet untuk Azure Bastion, tetapi tidak menyediakan sumber daya. Arsitektur ini menambahkan Azure Bastion di subnet dan menyediakan akses aman ke jump box.
Azure VM Image Builder	Disediakan dalam jaringan virtual terpisah, ia membuat gambar VM dengan keamanan dan konfigurasi dasar. Dalam arsitektur ini,disesuaikan untuk membangun simpul gambar yang aman dengan alat manajemen seperti Azure CLI,`kubectl`, dan Flux CLI yang sudah diinstal sebelumnya.
Azure Virtual Machine Scale Sets untuk kotak lompat	Jaringan spoke memiliki komputasi tambahan untuk kotak lompat. Kumpulan skala ini dimaksudkan sebagai titik akses yang diatur untuk menjalankan alat terhadap klaster AKS, seperti `kubectl`, sesuai kebutuhan.
Azure Application Gateway dengan Web Application Firewall (WAF) terintegrasi	Azure Application Gateway memuat beban di Layer 7. WAF mengamankan lalu lintas dari serangan lalu lintas web umum. Instans memiliki konfigurasi IP frontend publik yang menerima permintaan pengguna.
Azure Kubernetes Service (AKS)	Infrastruktur hosting, merupakan bagian penting dari data pemegang kartu (CDE). Kluster AKS disebarkan sebagai kluster privat. Jadi, server API Kubernetes tidak terekspos ke internet publik, dan lalu lintas ke server API terbatas pada jaringan pribadi Anda.
Tugas ACR	Menyediakan cara otomatis untuk membangun dan memelihara gambar kontainer.
Azure Key Vault	Menyimpan dan mengelola rahasia yang diperlukan untuk operasi cluster, seperti sertifikat dan kunci enkripsi.

Konfigurasi kluster

Bagian berikut menyoroti perubahan signifikan dari arsitektur garis besar.

Segmentasi kumpulan node

Dalam arsitektur ini, cluster memiliki dua kumpulan node pengguna dan satu kumpulan node sistem. Pilihan komputasi untuk kumpulan simpul tetap sama seperti dalam arsitektur garis besar. Tidak seperti arsitektur garis besar, setiap kumpulan simpul berada di subnet khusus untuk menyediakan batas isolasi jaringan tambahan antara tingkat komputasi.

Nota

Pendekatan alternatif untuk perlindungan komputasi adalah komputasi rahasia Azure. AKS mendukung simpul komputasi rahasia yang memungkinkan Anda menjalankan beban kerja sensitif dalam eksekusi tepercaya (TEE) berbasis perangkat keras. Untuk detailnya, lihat Simpul komputasi rahasia di Azure Kubernetes Service (AKS).

PCI DSS 4.0.1 memerlukan isolasi beban kerja PCI dari beban kerja lain dalam hal operasi dan konektivitas.

Dalam cakupan:Beban kerja PCI, lingkungan di mana ia berada, dan operasi.
Di luar cakupan: Beban kerja lain yang mungkin berbagi layanan, tetapi diisolasi dari komponen dalam cakupan.

Strategi utamanya adalah memberikan tingkat pemisahan yang diperlukan. Cara yang disukai adalah dengan menyebarkan komponen di dalam dan di luar cakupan dalam klaster terpisah. Kelemahan menggunakan beberapa kluster adalah biaya yang lebih tinggi untuk infrastruktur tambahan dan overhead pemeliharaan. Implementasi ini menempatkan semua komponen dalam klaster bersama untuk kesederhanaan. Jika Anda memilih untuk mengikuti model kluster tunggal, gunakan strategi segmentasi dalam kluster yang ketat. Tidak peduli bagaimana Anda memilih untuk mempertahankan pemisahan, ketahuilah bahwa saat solusi berkembang, beberapa komponen di luar cakupan mungkin akan menjadi dalam cakupan.

Dalam implementasi referensi, kami menunjukkan pendekatan kluster bersama dengan menyebarkan aplikasi layanan mikro ke satu kluster. Beban kerja di dalam dan di luar cakupan disegmentasikan dalam dua kumpulan simpul pengguna yang terpisah. Aplikasi ini memiliki dua set layanan: satu set memiliki pod dalam cakupan dan yang lain di luar cakupan. Kedua set tersebar di dua kumpulan simpul pengguna. Dengan menggunakan taint Kubernetes, pod dalam cakupan dan di luar cakupan disebarkan ke simpul terpisah dan tidak pernah berbagi simpul VM atau ruang IP jaringan.

Pengontrol Ingress

Arsitektur garis besar menggunakan Traefik untuk kontrol ingress. Dalam arsitektur referensi ini, kita malah menggunakan Nginx. Perubahan ini menggambarkan bahwa komponen ini dapat diubah berdasarkan persyaratan beban kerja Anda.

Server API Kubernetes

Arsitektur dasar menyebarkan klaster AKS dalam mode publik. Ini berarti semua komunikasi dengan server API Kubernetes yang dikelola AKS dilakukan melalui internet publik. Ini tidak dapat diterima dalam arsitektur ini karena PCI DSS 4.0.1 melarang paparan publik terhadap komponen sistem apa pun. Dalam arsitektur yang diatur ini, klaster digunakan sebagai klaster pribadi. Lalu lintas jaringan ke server Kubernetes API terbatas pada jaringan pribadi Anda. Server API diekspos melalui titik akhir privat di jaringan klaster. Keamanan lebih ditingkatkan dengan penggunaan grup keamanan jaringan dan fitur bawaan lainnya. Ini dijelaskan dalam Konfigurasi jaringan.

Keamanan Pod

Saat menjelaskan kebutuhan keamanan beban kerja Anda, securityContextgunakan pengaturan yang relevan untuk kontainer Anda. Ini termasuk pengaturan dasar seperti fsGroup,runAsUser / runAsGroup, dan pengaturan allowPrivilegeEscalation ke kesalahan (kecuali diperlukan). Jelaskan tentang mendefinisikan dan menghapus kemampuan Linux dan mendefinisikan opsi SELinux Anda di seLinuxOptions.

Hindari mereferensikan gambar dengan tag dalam bentuk penerapan yang Anda buat. Sebagai gantinya, gunakan ID gambar yang sebenarnya. Dengan begitu, Anda dapat dengan andal memetakan hasil pemindaian kontainer dengan konten aktual yang berjalan di klaster Anda. Anda dapat menerapkannya melalui Azure Policy untuk nama gambar untuk menyertakan pola ID gambar dalam ekspresi reguler yang diizinkan. Ikuti juga panduan ini saat Anda menggunakan FROM instruksi Dockerfile.

Konfigurasi Jaringan

Tenpatkan semua hub-spokes di jaringan virtual terpisah, dengan masing-masing di ruang diberi alamat pribadi. Secara default, tidak ada lalu lintas yang diizinkan antara dua jaringan virtual mana pun. Dalam jaringan, segmentasi diterapkan dengan membuat subnet.

Kombinasi berbagai layanan dan fitur Azure dan konstruksi Kubernetes memberikan tingkat kontrol yang diperlukan. Berikut adalah beberapa opsi yang digunakan dalam arsitektur ini:

Keamanan subnet melalui grup keamanan jaringan (NSG)

Ada beberapa NSG yang mengontrol arus keluar masuk klaster. Berikut adalah beberapa contoh:

Kumpulan simpul klaster ditempatkan di subnet khusus. Untuk setiap subnet, ada NSG yang memblokir akses SSH ke simpul VM dan mengizinkan lalu lintas dari jaringan virtual. Lalu lintas dari kumpulan simpul dibatasi ke jaringan virtual.
Semua lalu lintas yang masuk dari internet dicegat oleh Azure Application Gateway. Misalnya, aturan NSG memastikan bahwa:
- Hanya lalu lintas HTTPS yang diizinkan masuk.
- Lalu lintas dari sarana kontrol Azure diizinkan dengan menggunakan tag layanan. Untuk informasi selengkapnya, lihat izin akses ke beberapa sumber IP.
Pada subnet yang memiliki agen Azure Container Registry, NSG hanya mengizinkan lalu lintas keluar jika diperlukan. Misalnya, lalu lintas diizinkan ke Azure Key Vault, ID Microsoft Entra, Azure Monitor, dan layanan lain yang perlu diajak bicara oleh registri kontainer.
Subnet dengan kotak lompat ditujukan untuk operasi manajemen. Aturan NSG pada subnet jump box hanya memungkinkan akses SSH dari Azure Bastion di hub, dan koneksi keluar terbatas. Jump box tidak memiliki akses internet universal, dan dikontrol di NSG subnet dan Azure Firewall.

Saat beban kerja Anda, agen keamanan sistem, dan komponen lainnya diterapkan, tambahkan lebih banyak aturan NSG yang membantu menentukan jenis lalu lintas yang diizinkan. Lalu lintas tidak boleh melintasi batas subnet tersebut. Karena setiap kumpulan simpul tinggal di subnetnya sendiri, amati pola lalu lintas, lalu terapkan aturan yang lebih spesifik.

Keamanan pod-to-pod dengan kebijakan jaringan

Arsitektur ini dapat menerapkan prinsip "zero trust" dari Microsoft sebanyak mungkin.

Contoh jaringan zero trust sebagai konsep ditunjukkan dalam implementasi dalam a0005-i namespace layanan yang disediakan pengguna dan a0005-o . Setiap namespace beban kerja harus memiliki pembatasan NetworkPolicy yang diterapkan. Definisi kebijakan akan bergantung pada pod yang berjalan di ruang tersebut. Pastikan Anda memperhitungkan kesiapan, keaktifan, dan pemeriksaan startup, dan memungkinkan metrik yang dikumpulkan oleh agen Analitik Log. Pertimbangkan untuk menstandarkan port di seluruh beban kerja Anda sehingga Anda dapat menyediakan Azure Policy yang konsisten NetworkPolicy dan Azure Policy untuk port kontainer yang diizinkan.

Dalam kasus tertentu, ini tidak praktis untuk komunikasi dalam kluster. Tidak semua ruang yang disediakan pengguna dapat menggunakan jaringan tanpa kepercayaan (misalnya, cluster-baseline-settings tidak dapat menggunakan).

Enkripsi TLS

Arsitektur dasar menyediakan lalu lintas terenkripsi TLS hingga adanya pengontrolan di klaster, tetapi komunikasi pod-to-pod tetap jelas. Dalam arsitektur ini, TLS meluas ke lalu lintas pod-to-pod, dengan validasi Certificate Authority (CA). TLS tersebut disediakan oleh jejaring layanan, yang memberlakukan koneksi dan verifikasi mTLS sebelum mengizinkan komunikasi.

Diagram memperlihatkan arus lalu lintas jaringan dan titik akhir enkripsi TLS.

Implementasi penggunaan mTLS. mTLS dapat diimplementasikan dengan atau tanpa jejaring layanan. Jika Anda menggunakan jejaring, pastikan itu kompatibel dengan penerbit sertifikat pilihan Anda. Implementasi ini menggunakan Open Service Mesh.

Pengontrol arus masuk dalam implementasi ini menggunakan sertifikat pengganti untuk menangani lalu lintas bawaan saat sumber daya masuk tidak memiliki sertifikat tertentu. Ini mungkin dapat diterima, tetapi jika kebijakan organisasi tidak mengizinkan penggunaan sertifikat pengganti, Anda perlu menyesuaikan pengontrol arus masuk agar tidak menggunakan sertifikat pengganti.

Penting

Komponen apa pun yang mendekripsi data pemegang kartu dianggap berada dalam cakupan untuk PCI DSS 4.0.1 dan tunduk pada tingkat pengamatan yang sama dengan komponen lain di lingkungan data pemegang kartu. Dalam arsitektur ini, Azure Application Gateway berada dalam cakupan karena memeriksa muatannya sebagai bagian dari fungsionalitas WAF. Opsi arsitektur alternatif yaitu menggunakan Azure Firewall Premium sebagai komponen masuk, alih-alih WAF, untuk memanfaatkan kemampuan IDPS berbasis tanda tangan Azure Firewall. Ini memungkinkan penghentian TLS pertama yang berada di klaster. Namun, tanpa WAF khusus, Anda harus menggunakan kontrol kompensasi tambahan untuk memenuhi Persyaratan 6.6.

Pembatasan jaringan Azure Key Vault

Semua rahasia, kunci, dan sertifikat disimpan di Azure Key Vault. Key Vault menangani tugas manajemen sertifikat, seperti rotasi. Komunikasi dengan Key Vault dilakukan melalui Azure Private Link. Data DNS terkait dengan Key Vault berada di zona DNS pribadi sehingga tidak dapat diselesaikan dari internet. Meskipun ini meningkatkan keamanan, namun ada beberapa batasan.

Azure Application Gateway tidak mendukung sumber sertifikat TLS untuk pendengar HTTP dari instans Key Vault yang diekspos dengan Private Link, sehingga implementasi menyebarkan Key Vault dalam model hibrid. Penggunaan Private Link sebagai koneksi yang pendukungnya, juga memungkinkan akses publik untuk integrasi Azure Application Gateway. Jika pendekatan hibrida tidak cocok untuk penerapan Anda, pindahkan proses manajemen sertifikat ke Application Gateway. Ini akan menambah beban manajemen, tetapi pada akhirnya Key Vault akan sepenuhnya diisolasi.

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Perlindungan DDoS

Jika Anda memiliki jaringan virtual dengan alamat IP publik, aktifkan Azure DDoS Network Protection. Dalam arsitektur referensi ini, subnet yang berisi Application Gateway memiliki alamat IP publik yang terlampir, sehingga berada dalam cakupan untuk perlindungan DDoS.

Azure DDoS Network Protection melindungi infrastruktur dan beban kerja dari permintaan penipuan massal. Permintaan tersebut dapat menyebabkan gangguan layanan atau menutupi serangan lain secara bersamaan. Azure DDoS Network Protection memiliki biaya yang signifikan dan biasanya diamortisasi di banyak beban kerja yang mencakup banyak alamat IP. Bekerja sama dengan tim jaringan Anda untuk mengoordinasikan cakupan beban kerja Anda.

Manajemen identitas dan akses

Tentukan peran dan atur kontrol akses sesuai dengan persyaratan peran. Petakan peran ke aksi Kubernetes dengan cakupan yang sempit dan praktis. Hindari peran dengan banyak fungsi. Jika beberapa peran diisi oleh satu orang, tetapkan orang tersebut ke semua peran yang relevan dengan fungsi pekerjaan yang setara. Bahkan jika satu orang bertanggung jawab langsung atas kluster dan beban kerja, buat Kubernetes ClusterRoleSeolah-olah ada individu terpisah, lalu tetapkan satu individu tersebut semua peran yang relevan.

Minimalkan akses berdiri, terutama untuk akun berdampak tinggi seperti interaksi SRE/Ops dengan kluster Anda. Sarana kontrol AKS mendukung Microsoft Entra ID Privileged Access Management (PAM) just-in-time (JIT) dan Kebijakan Akses Bersyarat, yang menyediakan lapisan tambahan validasi autentikasi yang diperlukan untuk akses istimewa, berdasarkan aturan yang Anda buat.

Untuk detail selengkapnya tentang menggunakan PowerShell untuk mengonfigurasi akses bersyarah, lihat New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy, dan Remove-MgIdentityConditionalAccessPolicy.

Enkripsi disk

Saat Anda mendesain enkripsi untuk data tidak aktif, pertimbangkan disk penyimpanan, VM agen simpul AKS, VM lain, dan disk sistem operasi dan sementara.

Disk penyimpanan mesin virtual

Secara default, disk Azure Storage dienkripsi pada saat istirahat dengan kunci yang dikelola Microsoft. Jika Anda menggunakan disk sistem operasi non-ephemeral atau menambahkan disk data, kami sarankan Anda menggunakan kunci yang dikelola pelanggan untuk kontrol atas kunci enkripsi. Enkripsi di luar lapisan penyimpanan dan hanya menuliskan data terenkripsi ke dalam media penyimpanan. Juga, pastikan bahwa kunci tidak berdekatan dengan lapisan penyimpanan. Untuk informasi selengkapnya, lihat Membawa kunci Anda sendiri (BYOK) dengan disk Azure.

Pertimbangkan untuk menggunakan BYOK pada disk lain yang mungkin berinteraksi dengan klaster, seperti muka kotak lompat Azure Bastion. Jika Anda memilih BYOK, pilihan SKU untuk VM dan ketersediaan regional akan dibatasi karena fitur ini tidak didukung di semua SKU atau wilayah.

Host VM

Aktifkan fitur enkripsi-di-host. Ini akan mengenkripsi host VM dan sistem operasi sementara, atau disk data yang di-cache di host VM. Untuk informasi selengkapnya, lihat Dukungan VM untuk enkripsi berbasis host.

Fitur tersebut diperluas ke data yang disimpan di host VM simpul agen AKS melalui fitur Host-Based Encryption. Mirip dengan BYOK, fitur ini mungkin membatasi pilihan wilayah dan SKU VM Anda.

Anda dapat menerapkan fitur tersebut melalui Azure Policy.

Pencadangan klaster (bagian dan sumber daya)

Jika beban kerja memerlukan penyimpanan dalam klaster, miliki proses yang kuat dan aman untuk pencadangan dan pemulihan. Pertimbangkan layanan seperti Azure Backup (untuk Azure Disks dan Azure Files), untuk pencadangan dan pemulihan apa pun PersistentVolumeClaim. Ada keuntungan jika sistem cadangan mendukung sumber daya Kubernetes. Anda dapat melengkapi metode utama Anda yang mendamaikan cluster ke keadaan terkenal, dengan sistem cadangan untuk teknik pemulihan sistem kritis. Misalnya, ini dapat membantu dalam deteksi drift dan perubahan status sistem katalog dari waktu ke waktu di tingkat sumber daya Kubernetes.

Proses pencadangan perlu mengklasifikasikan data dalam cadangan, apakah data tersebut berasal dari kluster atau berada di luar kluster. Jika data berada dalam cakupan untuk PCI DSS 4.0.1, perluas batas kepatuhan Anda untuk menyertakan siklus hidup dan tujuan cadangan, yang akan berada di luar kluster. Backup bisa menjadi vektor serangan. Saat merancang cadangan, pertimbangkan pembatasan geografis, enkripsi saat istirahat, kontrol akses, peran dan tanggung jawab, audit, pencegahan waktu-ke-hidup, dan gangguan.

Sistem pencadangan dalam-klaster diharapkan berjalan dengan hak istimewa yang tinggi selama operasi. Evaluasi risiko dan manfaat membawa agen cadangan ke dalam klaster Anda. Apakah kemampuan agen tumpang tindih dengan solusi manajemen lain di klaster? Apa set minimum yang Anda butuhkan untuk menyelesaikan tugas ini tanpa memperluas serangan?

Pertimbangan Azure Policy

Kebijakan Azure yang diterapkan biasanya tidak memiliki pengaturan yang disetel beban kerja. Dalam implementasinya, kami menerapkan standar terbatas keamanan pod kluster Kubernetes untuk inisiatif beban kerja berbasis Linux , yang merupakan salah satu inisiatif kebijakan bawaan. Inisiatif ini tidak mengizinkan penyetelan pengaturan. Pertimbangkan untuk mengekspor inisiatif ini dan menyesuaikan nilainya untuk beban kerja spesifik Anda. Anda dapat menyertakan semua kebijakan Gatekeeper deny Azure di bawah satu inisiatif kustom dan semua audit kebijakan Azure di bawah inisiatif lain. Tindakan tersebut akan mengkategorikan tindakan blokir dari kebijakan informasi saja.

Pertimbangkan untuk menyertakan kube-system dan gatekeeper-system ruang ke kebijakan dalam kebijakanaudit untuk visibilitas tambahan. Menyertakan ruang tersebut dalam kebijakan penolakan dapat menyebabkan kegagalan klaster karena konfigurasi yang tidak mendukung.

Anda dapat menerapkan enkripsi data dengan mengatur beberapa peringatan Azure Policy. Misalnya, Anda dapat menerapkan BYOK dengan peringatan yang mendeteksi klaster yang tidak ada diskEncryptionSetIDdi sumber daya klaster. Kebijakan lain dapat dideteksi jika Enkripsi Berbasis Host diaktifkan pada agentPoolProfiles. Implementasi referensi tidak menggunakan disk apa pun di klaster, dan disk sistem operasi bersifat sementara. Kedua contoh kebijakan tersebut diterapkan sebagai pengingat fitur keamanan. Kebijakan diatur ke audit, bukan block.

Mengelola gambar

Gunakan gambar dasar tanpa distribusi untuk beban kerja. Dengan gambar ini, area permukaan keamanan diminimalkan karena gambar tambahan, seperti kulit dan manajer paket, dihapus. Manfaatnya adalah pengurangan tingkat hit CVE.

Azure Container Registry mendukung gambar yang memenuhi Spesifikasi Format Gambar Open Container Initiative (OCI). Ini, ditambah dengan pengontrol arus masuk yang mendukung validasi tanda tangan, akan memastikan bahwa Anda hanya menjalankan gambar yang telah ditanda tangani dengan kunci pribadi Anda. Ada solusi sumber terbuka seperti SSE Connaisseur atau IBM Portieris yang mengintegrasikan proses tersebut.

Lindungi gambar kontainer dan artefak OCI lainnya karena itu merupakan kekayaan intelektual organisasi. Gunakan kunci yang dikelola pelanggan dan enkripsi konten registri Anda. Secara default, data dienkripsi saat istirahat dengan kunci pengelolaan layanan, tetapi kunci tersebut terkadang diperlukan untuk memenuhi standar kepatuhan peraturan. impan kunci di penyimpanan manajemen kunci terkelola seperti Azure Key Vault. Karena Anda membuat dan memiliki kunci, Anda bertanggung jawab atas operasi yang terkait dengan siklus hidup utama, termasuk rotasi dan manajemen. Untuk informasi selengkapnya, lihat Enkripsi registri menggunakan kunci yang dikelola pelanggan.

Akses operasional Kubernetes API Server

Anda dapat membatasi perintah yang dijalankan terhadap kluster tanpa harus membangun proses operasional berdasarkan jump box. Jika Anda memiliki platform otomatisasi TI berpagar IAM, manfaatkan tindakan yang telah ditentukan sebelumnya untuk mengontrol dan mengaudit jenis tindakan.

Membangun agen

Agen penyalur harus berada di luar cakupan klaster yang diatur karena proses pembangunan dapat menjadi ancaman. Misalnya, proses build sering bekerja dengan komponen yang tidak terucapkan dan tidak tepercaya.

Meskipun Kubernetes umum digunakan sebagai infrastruktur agen pembangunan, jangan jalankan proses itu dalam batas runtime beban kerja yang diatur. Agen yang dibangun seharusnya tidak memiliki akses langsung ke klaster. Misalnya, hanya berikan akses jaringan agen build ke Azure Container Registry untuk mendorong gambar kontainer, bagan Helm, dan sebagainya. Kemudian, terapkan melalui GitOps. Dalam praktiknya, alur kerja pembuatan dan rilis seharusnya tidak memiliki akses langsung ke Kubernetes Cluster API (atau simpul-nya).

Operasi pemantauan

Aktivitas dalam klaster

Pod dalam cluster omsagent yang berjalan kube-system adalah pengumpul Log Analytics. Mengumpulkan telemetri, mengikis wadah stdoutdan stderrlog, dan mengumpulkan metrik Prometheus. Anda dapat menyetel pengaturan koleksi dengan memperbarui container-azm-ms-agentconfig.yaml ConfigMap file. Dalam implementasi referensi ini, logging diaktifkan di seluruh kube-systemdan semua beban kerja. Secara mendasar, kube-system dikecualikan dari logging. Pastikan Anda menyesuaikan proses pengumpulan log untuk mencapai keseimbangan biaya, efisiensi SRE saat Anda meninjau log, dan kebutuhan pengaturan.

Pemantauan keamanan

Gunakan Defender untuk Kontainer di Microsoft Defender untuk Cloud untuk melihat dan memulihkan rekomendasi keamanan dan untuk melihat pemberitahuan keamanan pada sumber daya kontainer Anda. Aktifkan paket Microsoft Defender saat diberlakukan untuk berbagai komponen data pemegang kartu.

Integrasikan log sehingga Anda dapat meninjau, menganalisis, dan membuat kueri data secara efisien. Azure menyediakan beberapa opsi. Anda dapat mengaktifkan log diagnostik AKS dan mengirimkannya ke ruang kerja Analitik Log yang merupakan bagian dari Azure Monitor. Opsi lain adalah mengintegrasikan data ke dalam solusi security information and event management (SIEM), seperti Microsoft Sentinel.

Sesuai dengan standar, semua ruang kerja Analitik Log diatur ke periode retensi 90 hari. Pertimbangkan untuk menyiapkan ekspor berkelanjutan untuk penyimpanan jangka panjang. Jangan menyimpan informasi sensitif dalam data log, dan pastikan akses ke data log yang diarsipkan tunduk pada tingkat kontrol akses yang sama dengan data log terbaru.

Untuk perspektif lengkap, lihat Panduan Onboarding Microsoft Defender untuk Cloud Enterprise. Panduan ini membahas pendaftaran, ekspor data ke solusi SIEM, menanggapi peringatan, dan membangun otomatisasi alur kerja.

Berikut adalah tautan ke dokumentasi fitur beberapa komponen utama arsitektur ini:

Langkah selanjutnya

Menginstal dan mempertahankan konfigurasi firewall untuk melindungi data pemegang kartu. Jangan gunakan default yang disediakan vendor untuk kata sandi sistem dan parameter keamanan lainnya.

Membangun dan memelihara jaringan dan sistem yang aman

Saran dan Komentar

Apakah halaman ini membantu?

Terakhir diperbarui pada 2025-08-14