Arsitektur klaster yang diatur AKS untuk PCI-DSS 3.2.1 (Bagian 2 dari 9)

Artikel ini menjelaskan arsitektur referensi untuk klaster Azure Kubernetes Service (AKS) yang menjalankan beban kerja sesuai dengan Standar Keamanan Data Industri Kartu Pembayaran (PCI-DSS 3.2.1). Arsitektur ini difokuskan pada infrastruktur dan bukanbeban kerja PCI-DSS 3.2.1.

Artikel ini adalah bagian dari beberapa seri. Baca pengantar.

Rekomendasi dan contoh diambil dari implementasi referensi dalam bahan penyerta:

GitHub: Kluster Dasar Azure Kubernetes Service (AKS) untuk Beban Kerja yang Diatur menunjukkan infrastruktur yang diatur. Implementasi ini menyediakan aplikasi layanan mikro. Aplikasi tersebut disertakan untuk membantu Anda mengalami infrastruktur dan menggambarkan jaringan dan kontrol keamanan. Aplikasi tidak mewakili atau mengimplementasikan beban kerja PCI DSS yang sebenarnya.

Unduh file Visio arsitektur ini.

Arsitektur jaringan itu 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 klaster AKS yang merupakan komponen dari pemegang kartu (CDE), dan tuan rumah yang menampung beban kerja PCI DSS. Lainnya membangun gambar mesin virtual yang digunakan untuk akses SRE terkontrol ke lingkungan.

Komponen

Berikut adalah komponen utama yang digunakan dalam arsitektur ini. Jika Anda tidak terbiasa dengan layanan ini, lihat layanan Azure terkait untuk tautan ke dokumentasi produk.

Azure Firewall

Firewall mengamankan lalu lintas jaringan. 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 publik yang menerima permintaan pengguna.

Azure Kubernetes Service (AKS)

Infrastruktur hosting, merupakan bagian penting dari data pemegang kartu (CDE). Klaster AKS digunakan sebagai klaster pribadi. 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.

Mengonfigurasi kluster

Berikut adalah beberapa perubahan signifikan dari arsitektur dasar:

Segmentasi kumpulan node

Dalam arsitektur ini, cluster memiliki dua kumpulan node pengguna dan satu kumpulan node sistem. Pilihan komputasi untuk kumpulan node tetap sama. Setiap kumpulan node berada di subnet khusus untuk memberikan batas isolasi tambahan antara tingkat komputasi.

PCI-DSS 3.2.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. Kelemahannya adalah adanya peningkatan biaya untuk infrastruktur tambahan dan biaya pemeliharaan. Implementasi ini menempatkan semua komponen dalam klaster bersama untuk kesederhanaan. Jika Anda memilih untuk mengikuti model tersebut, gunakan strategi segmentasi dalam klaster 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, pendekatan kedua ditunjukkan dengan aplikasi layanan mikro yang disebarkan 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 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.

Kontreler ingress

Pengontrol Ingress Kubernetes di dalam klaster diubah menjadi NGINX. Pada arsitektur dasar, gunakan Traefik. Perubahan ini menggambarkan bahwa komponen ini dapat diubah berdasarkan kebutuhan 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. Hal ini tidak dapat diterima dalam arsitektur ini karena PCI-DSS 3.2.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 Azure Control Plane diperbolehkan. 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 hanya mengizinkan akses SSH dari Azure Bastion di hub, dan pembatasan koneksi keluar. Kotak lompat tidak memiliki akses internet universal, dan dikendalikan oleh subnet NSG 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 di a0005-i dana0005-oruang yang disediakan pengguna. Semua ruang beban kerja harus menerapkan pembatasan NetworkPolicy. Definisi kebijakan akan bergantung pada pod yang berjalan di ruang tersebut. Pastikan Anda memperhitungkan kesiapan, keaktifan, dan pemeriksaan awal dan juga penyisihan metrik yang dikumpulkan oleh Analisis Log. Pertimbangkan standarisasi pada port di seluruh beban kerja sehingga Anda dapat menerapkan NetworkPolicy dan Azure Policy secara konsisten pada port kontainer.

Dalam kasus tertentu, ini tidak praktis untuk komunikasi antar klaster. 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.

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.

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 HTTP dari Key Vault yang diekspos dengan Private Link. Jadi, implementasi menyebarkan Key Vault dalam model hibrida. 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, lihat:

• integrasi Azure Application Gateway dengan Key Vault
• Membuat gerbang aplikasi dengan penghentian TLS menggunakan Azure CLI.

Perlindungan DDoS

Aktifkan Azure DDoS Network Protection untuk jaringan virtual dengan subnet yang berisi Application Gateway dengan IP publik. Melakukannya akan melindungi infrastruktur dan beban kerja dari penipuan massal. Permintaan tersebut dapat menyebabkan gangguan layanan atau menutupi serangan lain secara bersamaan. Azure DDoS hadir dengan biaya yang signifikan, dan biasanya diamortisasi di beban kerja yang menjangkau banyak alamat IP. Bekerjalah dengan tim jaringan Anda untuk mengoordinasikan cakupan beban kerja.

Manajemen Identitas & 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. Jadi, meskipun satu orang bertanggung jawab langsung atas klaster dan beban kerja, buat Kubernetes Anda ClusterRoles seolah-olah merupakan individu yang terpisah. Kemudian tetapkan individu tunggal itu ke semua peran yang relevan.

Minimalkan akses, terutama untuk akun berdampak tinggi, seperti interaksi SRE/Ops dengan klaster 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 bersyarat, 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 menyarankan Anda menggunakan kunci yang dikelola pelanggan untuk mengontrol 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 terbatas karena fitur ini tidak tersedia 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. Baca selengkapnya tentang 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 PersistantVolumeClaim. 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.

Microsoft Azure Backup pencadangan perlu mengklasifikasikan data dalam cadangan di dalam atau di luar klaster. Jika data berada dalam cakupan PCI DSS 3.2.1, perpanjang batas kepatuhan untuk menyertakan siklus hidup dan tujuan pencadangan, yang akan berada di luar klaster. 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

Biasanya, kebijakan Azure yang diterapkan tidak memiliki pengaturan yang disesuaikan dengan beban kerja. Dalam implementasinya, kami menerapkan standar pembatasan keamanan pod klaster Kubernetes untuk inisiatif beban kerja berbasis Linux , yang tidak memungkinkan untuk memulai 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 kebiasaan, dan semua kebijakan audit 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 terkait siklus hidup kunci, 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 klaster, tanpa harus membangun proses operasional berdasarkan kotak lompat. 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. 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, berikan hanya akses jaringan agen pembuatan ke Azure Container Registry untuk mendorong gambar kontainer, bagan kemudi, 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.

Layanan Azure terkait

Berikut adalah tautan untuk menampilkan dokumentasi beberapa komponen kunci dari arsitektur ini.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure VM Image Builder
• Kumpulan Skala Komputer Virtual Azure
• Azure Application Gateway dengan Web Application Firewall (WAF) terintegrasi
• perintah Azure Container Registry
• Azure Key Vault

Langkah berikutnya

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