Share via

Manajemen kerentanan untuk Azure Kubernetes Service (AKS)

  • Artikel

Manajemen kerentanan melibatkan mendeteksi, menilai, mengurangi, dan melaporkan kerentanan keamanan yang ada dalam sistem dan perangkat lunak organisasi. Manajemen kerentanan adalah tanggung jawab bersama antara Anda dan Microsoft.

Artikel ini menjelaskan bagaimana Microsoft mengelola kerentanan keamanan dan pembaruan keamanan (juga disebut sebagai patch), untuk kluster Azure Kubernetes Service (AKS).

Bagaimana kerentanan ditemukan

Microsoft mengidentifikasi dan menambal kerentanan dan pembaruan keamanan yang hilang untuk komponen berikut:

  • Gambar Kontainer AKS

  • Simpul pekerja sistem operasi Ubuntu 18.04 dan 22.04: Canonical memberi Microsoft build OS yang menerapkan semua pembaruan keamanan yang tersedia.

  • Simpul pekerja OS Windows Server 2022: Sistem operasi Windows Server di-patch pada hari Selasa kedua setiap bulan. SLA harus sama sesuai kontrak dukungan dan tingkat keparahannya.

  • Simpul OS Linux Azure: Azure Linux menyediakan build OS kepada AKS yang menerapkan semua pembaruan keamanan yang tersedia.

Gambar Kontainer AKS

Sementara Cloud Native Computing Foundation (CNCF) memiliki dan mempertahankan sebagian besar kode yang dijalankan AKS, Microsoft bertanggung jawab untuk membangun paket sumber terbuka yang kami sebarkan di AKS. Tanggung jawab itu termasuk memiliki kepemilikan lengkap atas proses build, pemindaian, tanda tangan, validasi, dan perbaikan, serta kontrol atas biner dalam gambar kontainer. Memiliki tanggung jawab untuk membangun paket sumber terbuka yang disebarkan pada AKS memungkinkan kami membangun rantai pasokan perangkat lunak melalui biner, dan untuk menambal perangkat lunak sesuai kebutuhan.  

Microsoft aktif dalam ekosistem Kubernetes yang lebih luas untuk membantu membangun masa depan komputasi cloud-native di komunitas CNCF yang lebih luas. Pekerjaan ini tidak hanya memastikan kualitas setiap rilis Kubernetes untuk dunia, tetapi juga memungkinkan AKS dengan cepat mendapatkan rilis Kube baru ke dalam produksi selama beberapa tahun. Dalam beberapa kasus, di depan penyedia cloud lainnya oleh beberapa bulan. Microsoft berkolaborasi dengan mitra industri lain di organisasi keamanan Kubernetes. Misalnya, Komite Respons Keamanan (SRC) menerima, memprioritaskan, dan menambal kerentanan keamanan embargo sebelum diumumkan kepada publik. Komitmen ini memastikan Kubernetes aman bagi semua orang, dan memungkinkan AKS untuk menambal dan menanggapi kerentanan lebih cepat untuk menjaga keamanan pelanggan kami. Selain Kubernetes, Microsoft telah mendaftar untuk menerima pemberitahuan pra-rilis untuk kerentanan perangkat lunak untuk produk seperti Envoy, runtime kontainer, dan banyak proyek sumber terbuka lainnya.

Microsoft memindai gambar kontainer menggunakan analisis statis untuk menemukan kerentanan dan pembaruan yang hilang di Kubernetes dan kontainer yang dikelola Microsoft. Jika perbaikan tersedia, pemindai secara otomatis memulai proses pembaruan dan rilis.

Selain pemindaian otomatis, Microsoft menemukan dan memperbarui kerentanan yang tidak diketahui oleh pemindai dengan cara berikut:

  • Microsoft melakukan audit, pengujian penetrasi, dan penemuan kerentanannya sendiri di semua platform AKS. Tim khusus di dalam Microsoft dan vendor keamanan pihak ketiga tepercaya melakukan penelitian serangan mereka sendiri.

  • Microsoft secara aktif terlibat dengan komunitas penelitian keamanan melalui beberapa program hadiah kerentanan. Program Microsoft Azure Bounty khusus menyediakan karunia yang signifikan untuk kerentanan cloud terbaik yang ditemukan setiap tahun.

  • Microsoft berkolaborasi dengan industri lain dan sumber terbuka mitra perangkat lunak yang berbagi kerentanan, penelitian keamanan, dan pembaruan sebelum rilis publik kerentanan. Tujuan dari kolaborasi ini adalah untuk memperbarui sebagian besar infrastruktur Internet sebelum kerentanan diumumkan kepada publik. Dalam beberapa kasus, Microsoft menyumbang kerentanan yang ditemukan untuk komunitas ini.

  • Kolaborasi keamanan Microsoft terjadi di banyak tingkatan. Terkadang itu terjadi secara resmi melalui program di mana organisasi mendaftar untuk menerima pemberitahuan pra-rilis tentang kerentanan perangkat lunak untuk produk seperti Kubernetes dan Docker. Kolaborasi juga terjadi secara informal karena keterlibatan kami dengan banyak proyek sumber terbuka seperti kernel Linux, runtime kontainer, teknologi virtualisasi, dan lainnya.

Node Pekerja

Simpul Linux

Pembaruan keamanan OS kanonis malam dinonaktifkan secara default di AKS. Untuk mengaktifkannya secara eksplisit, gunakan unmanagedsaluran.

Jika Anda menggunakan unmanagedsaluran, maka pembaruan keamanan kanonis malam diterapkan ke OS pada simpul. Gambar node yang digunakan untuk membuat simpul untuk kluster Anda tetap tidak berubah. Jika simpul Linux baru ditambahkan ke kluster Anda, citra asli digunakan untuk membuat simpul. Simpul baru ini menerima semua pembaruan keamanan dan kernel yang tersedia selama penilaian otomatis yang dilakukan setiap malam, tetapi tetap tidak dikirim hingga semua pemeriksaan dan mulai ulang selesai. Anda dapat menggunakan peningkatan gambar simpul untuk memeriksa dan memperbarui gambar simpul yang digunakan oleh klaster Anda. Untuk informasi selengkapnya tentang peningkatan gambar simpul, lihat Peningkatan gambar simpul Azure Kubernetes Service (AKS).

Untuk kluster AKS menggunakan saluran selain unmanaged, proses peningkatan tanpa pengawas dinonaktifkan.

Simpul Windows Server

Untuk simpul Windows Server, Windows Update tidak otomatis berjalan dan menerapkan pembaruan terkini. Jadwalkan peningkatan kumpulan simpul Windows Server di kluster AKS Anda di sekitar siklus rilis Windows Update reguler dan proses manajemen pembaruan Anda sendiri. Proses pemutakhiran ini membuat simpul yang menjalankan gambar dan patch Windows Server terbaru, lalu menghapus simpul yang lebih lama. Untuk informasi selengkapnya tentang proses ini, lihat Memutakhirkan kumpulan simpul di AKS.

Bagaimana kerentanan diklasifikasikan

Microsoft melakukan investasi besar dalam keamanan yang memperkuat seluruh tumpukan, termasuk OS, kontainer, Kubernetes, dan lapisan jaringan, selain mengatur default yang baik dan menyediakan konfigurasi yang diperkuat keamanan dan komponen terkelola. Gabungan, upaya ini membantu mengurangi dampak dan kemungkinan kerentanan.

Tim AKS mengklasifikasikan kerentanan sesuai dengan sistem penilaian kerentanan Kubernetes. Klasifikasi mempertimbangkan banyak faktor termasuk konfigurasi AKS dan pengerasan keamanan. Sebagai hasil dari pendekatan ini, dan investasi yang dilakukan AKS dalam keamanan, klasifikasi kerentanan AKS mungkin berbeda dari sumber klasifikasi lainnya.

Tabel berikut ini menjelaskan kategori tingkat keparahan kerentanan:

Tingkat keparahan Deskripsi
Kritis Kerentanan mudah dieksploitasi di semua kluster oleh penyerang jarak jauh yang tidak terauthentikasi yang menyebabkan kompromi sistem penuh.
Sangat Penting Kerentanan mudah dieksploitasi untuk banyak kluster yang menyebabkan hilangnya kerahasiaan, integritas, atau ketersediaan.
Medium Kerentanan yang dapat dieksploitasi untuk beberapa kluster di mana hilangnya kerahasiaan, integritas, atau ketersediaan dibatasi oleh konfigurasi umum, kesulitan eksploitasi itu sendiri, akses yang diperlukan, atau interaksi pengguna.
Kurang Penting Semua kerentanan lainnya. Eksploitasi tidak mungkin atau konsekuensi eksploitasi terbatas.

Bagaimana kerentanan diperbarui

AKS menambal Kerentanan dan Paparan Umum (CVE) yang memiliki perbaikan vendor setiap minggu. Setiap CVE tanpa perbaikan sedang menunggu perbaikan vendor sebelum dapat diperbaiki. Gambar kontainer tetap di-cache di build hard disk virtual (VHD) terkait berikutnya, yang juga berisi CVE yang diperbarui Ubuntu/Azure Linux/Windows yang di-patch. Selama Anda menjalankan VHD yang diperbarui, Anda tidak boleh menjalankan CVE gambar kontainer apa pun dengan perbaikan vendor yang berusia lebih dari 30 hari.

Untuk kerentanan berbasis OS di VHD, AKS juga mengandalkan pembaruan vhd gambar simpul secara default, sehingga pembaruan keamanan apa pun akan datang dengan rilis gambar simpul mingguan . Peningkatan tanpa pengawas dinonaktifkan kecuali Anda beralih ke tidak terkelola yang tidak direkomendasikan karena rilisnya global.

Memperbarui garis waktu rilis

Tujuan Microsoft adalah untuk mengurangi kerentanan yang terdeteksi dalam periode waktu yang sesuai dengan risiko yang mereka wakili. Otorisasi Provisi Tinggi microsoft Azure FedRAMP untuk Beroperasi (P-ATO) mencakup AKS dalam cakupan audit dan telah diotorisasi. Panduan Strategi Pemantauan Berkelanjutan FedRAMP dan garis besar FedRAMP Rendah, Sedang, dan Kontrol Keamanan Tinggi memerlukan remediasi kerentanan yang diketahui dalam periode waktu tertentu sesuai dengan tingkat keparahannya. Seperti yang ditentukan dalam FedRAMP RA-5d.

Bagaimana kerentanan dan pembaruan dikomunikasikan

Secara umum, Microsoft tidak secara luas mengomunikasikan rilis versi patch baru untuk AKS. Namun, Microsoft terus memantau dan memvalidasi patch CVE yang tersedia untuk mendukungnya di AKS secara tepat waktu. Jika patch penting ditemukan atau tindakan pengguna diperlukan, Microsoft memposting dan memperbarui detail masalah CVE di GitHub.

Pelaporan Keamanan

Anda dapat melaporkan masalah keamanan ke Microsoft Security Response Center (MSRC), dengan membuat laporan kerentanan.

Jika Anda lebih suka mengirimkan laporan tanpa masuk ke alat, kirim email ke secure@microsoft.com. Jika memungkinkan, enkripsi pesan Anda dengan kunci PGP kami dengan mengunduhnya dari halaman Kunci PGP Microsoft Security Response Center.

Anda akan menerima respons dalam waktu 24 jam. Jika karena alasan tertentu Anda tidak melakukannya, tindak lanjuti dengan email untuk memastikan kami menerima pesan asli Anda. Untuk informasi selengkapnya, buka Pusat Respons Keamanan Microsoft.

Sertakan informasi yang diminta berikut (sebanyak yang dapat Anda berikan) untuk membantu kami lebih memahami sifat dan cakupan kemungkinan masalah:

  • Jenis masalah (misalnya, luapan buffer, injeksi SQL, scripting lintas situs, dll.)
  • Jalur lengkap file sumber yang terkait dengan manifestasi masalah
  • Lokasi kode sumber yang terpengaruh (tag/cabang/penerapan atau URL langsung)
  • Konfigurasi khusus apa pun yang diperlukan untuk mereprodurasi masalah
  • Instruksi langkah demi langkah untuk mereproduksi masalah
  • Kode bukti konsep atau eksploitasi (jika memungkinkan)
  • Dampak masalah ini, termasuk bagaimana penyerang dapat mengeksploitasi masalah tersebut.

Informasi ini membantu kami melakukan triase masalah keamanan anda yang dilaporkan lebih cepat.

Jika Anda melaporkan hadiah bug, laporan yang lebih lengkap dapat berkontribusi pada penghargaan hadiah yang lebih tinggi. Untuk informasi selengkapnya tentang program aktif kami, lihat Program Bounty Bug Microsoft.

Kebijakan

Microsoft mengikuti prinsip Pengungkapan Kerentanan Terkoordinasi.

Langkah berikutnya

Lihat gambaran umum tentang Meningkatkan kluster Dan kumpulan simpul Azure Kubernetes Service.