Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memulihkan eksposur untuk kluster Amazon EKS

AWSSecurity Hub dapat menghasilkan temuan eksposur untuk cluster Amazon Elastic Kubernetes Service (Amazon EKS).

Cluster Amazon EKS yang terlibat dalam temuan eksposur dan informasi pengidentifikasinya tercantum di bagian Sumber Daya dari detail temuan. Anda dapat mengambil detail sumber daya ini di konsol Security Hub atau secara terprogram dengan GetFindingsV2pengoperasian Security Hub CSPM API.

Setelah mengidentifikasi sumber daya yang terlibat dalam temuan eksposur, Anda dapat menghapus sumber daya jika Anda tidak membutuhkannya. Menghapus sumber daya yang tidak penting dapat mengurangi profil dan AWS biaya eksposur Anda. Jika sumber daya sangat penting, ikuti langkah-langkah remediasi yang direkomendasikan ini untuk membantu mengurangi risiko. Topik remediasi dibagi berdasarkan jenis sifatnya.

Temuan eksposur tunggal berisi masalah yang diidentifikasi dalam beberapa topik remediasi. Sebaliknya, Anda dapat mengatasi temuan eksposur dan menurunkan tingkat keparahannya dengan hanya membahas satu topik remediasi. Pendekatan Anda terhadap remediasi risiko tergantung pada kebutuhan organisasi dan beban kerja Anda.

Ciri salah konfigurasi untuk kluster Amazon EKS

Berikut adalah ciri kesalahan konfigurasi untuk kluster Amazon EKS dan langkah-langkah perbaikan yang disarankan.

Cluster Amazon EKS memungkinkan akses publik

Endpoint klaster Amazon EKS adalah endpoint yang Anda gunakan untuk berkomunikasi dengan server API Kubernetes klaster Anda. Secara default, titik akhir ini bersifat publik ke internet. Titik akhir publik meningkatkan area permukaan serangan Anda dan risiko akses tidak sah ke server API Kubernetes Anda, yang berpotensi memungkinkan penyerang mengakses atau memodifikasi sumber daya klaster atau mengakses data sensitif. Mengikuti praktik terbaik keamanan, AWS merekomendasikan untuk membatasi akses ke titik akhir kluster EKS Anda hanya ke rentang IP yang diperlukan.

Ubah akses titik akhir

Dalam temuan eksposur, buka sumber daya. Ini akan membuka cluster Amazon EKS yang terpengaruh. Anda dapat mengonfigurasi klaster Anda untuk menggunakan akses pribadi, akses publik, atau keduanya. Dengan akses pribadi, permintaan Kubernetes API yang berasal dari VPC klaster Anda menggunakan titik akhir VPC pribadi. Dengan akses publik, permintaan Kubernetes API yang berasal dari luar VPC klaster Anda menggunakan titik akhir publik.

Memodifikasi atau menghapus akses publik ke cluster

Untuk mengubah akses endpoint untuk klaster yang ada, lihat Memodifikasi akses endpoint cluster di Panduan Pengguna Amazon Elastic Kubernetes Service. Menerapkan aturan yang lebih ketat berdasarkan rentang IP tertentu atau grup keamanan. Jika akses publik terbatas diperlukan, batasi akses ke rentang blok CIDR tertentu atau gunakan daftar awalan.

Cluster Amazon EKS menggunakan versi Kubernetes yang tidak didukung

Amazon EKS mendukung setiap versi Kubernetes untuk jangka waktu terbatas. Menjalankan cluster dengan versi Kubernetes yang tidak didukung dapat mengekspos lingkungan Anda ke kerentanan keamanan, karena patch CVE akan berhenti dirilis untuk versi yang sudah ketinggalan zaman. Versi yang tidak didukung mungkin mengandung kerentanan keamanan yang diketahui yang dapat dieksploitasi oleh penyerang dan tidak memiliki fitur keamanan yang mungkin tersedia dalam versi yang lebih baru. Mengikuti praktik terbaik keamanan, AWS rekomendasikan agar versi Kubernetes Anda diperbarui.

Perbarui versi Kubernetes

Dalam temuan eksposur, buka sumber daya. Ini akan membuka cluster Amazon EKS yang terpengaruh. Sebelum memperbarui klaster Anda, tinjau versi yang tersedia pada dukungan standar di Panduan Pengguna Amazon Elastic Kubernetes Service untuk daftar versi Kubernetes yang saat ini didukung.

Cluster Amazon EKS menggunakan rahasia Kubernetes yang tidak terenkripsi

Rahasia Kubernetes, secara default, disimpan tanpa terenkripsi di penyimpanan data dasar server API (etcd). Siapa pun yang memiliki akses API atau dengan akses ke etcd dapat mengambil atau memodifikasi rahasia. Untuk mencegah hal ini, Anda harus mengenkripsi rahasia Kubernetes saat istirahat. Jika Rahasia Kubernetes tidak dienkripsi, mereka rentan terhadap akses yang tidak sah jika etcd dikompromikan. Karena rahasia sering berisi informasi sensitif seperti kata sandi dan token API, eksposur mereka dapat menyebabkan akses tidak sah ke aplikasi dan data lain. Mengikuti praktik terbaik keamanan, AWS merekomendasikan untuk mengenkripsi semua informasi sensitif yang disimpan dalam rahasia Kubernetes.

Enkripsi rahasia Kubernetes

Amazon EKS mendukung enkripsi rahasia Kubernetes menggunakan kunci KMS melalui enkripsi amplop. Untuk mengaktifkan enkripsi rahasia Kubernetes untuk kluster EKS Anda, lihat Enkripsi rahasia Kubernetes dengan KMS pada klaster yang ada di Panduan Pengguna Amazon EKS.

Ciri-ciri kerentanan untuk kluster Amazon EKS

Berikut adalah ciri-ciri kerentanan untuk cluster Amazon EKS.

Cluster Amazon EKS memiliki wadah dengan kerentanan perangkat lunak yang dapat dieksploitasi jaringan dengan kemungkinan eksploitasi yang tinggi

Paket perangkat lunak yang diinstal pada kluster EKS dapat terkena Common Vulnerabilities and Exposures (). CVEs Kritis CVEs menimbulkan risiko keamanan yang signifikan terhadap AWS lingkungan Anda. Pengguna yang tidak sah dapat mengeksploitasi kerentanan yang belum ditambal ini untuk membahayakan kerahasiaan, integritas, atau ketersediaan data, atau untuk mengakses sistem lain. Kerentanan kritis dengan kemungkinan eksploitasi tinggi mewakili ancaman keamanan langsung, karena kode eksploitasi mungkin sudah tersedia untuk umum dan digunakan secara aktif oleh penyerang atau alat pemindaian otomatis. Mengikuti praktik terbaik keamanan, AWS rekomendasikan untuk menambal kerentanan ini untuk melindungi instance Anda dari serangan.

Perbarui instance yang terpengaruh

Perbarui gambar kontainer Anda ke versi yang lebih baru yang menyertakan perbaikan keamanan untuk kerentanan yang diidentifikasi. Ini biasanya melibatkan membangun kembali gambar kontainer Anda dengan gambar dasar atau dependensi yang diperbarui, lalu menerapkan gambar baru ke cluster Amazon EKS Anda.

Cluster Amazon EKS memiliki wadah dengan kerentanan perangkat lunak

Paket perangkat lunak yang diinstal pada kluster Amazon EKS dapat terkena Kerentanan Umum dan Eksposur (). CVEs Nonkritis CVEs mewakili kelemahan keamanan dengan tingkat keparahan atau eksploitasi yang lebih rendah dibandingkan dengan kritis. CVEs Sementara kerentanan ini menimbulkan risiko yang kurang langsung, penyerang masih dapat mengeksploitasi kerentanan yang belum ditambal ini untuk membahayakan kerahasiaan, integritas, atau ketersediaan data, atau untuk mengakses sistem lain. Mengikuti praktik terbaik keamanan, AWS rekomendasikan untuk menambal kerentanan ini untuk melindungi instance Anda dari serangan.

Perbarui instance yang terpengaruh

Perbarui gambar kontainer Anda ke versi yang lebih baru yang menyertakan perbaikan keamanan untuk kerentanan yang diidentifikasi. Ini biasanya melibatkan membangun kembali gambar kontainer Anda dengan gambar dasar atau dependensi yang diperbarui, lalu menerapkan gambar baru ke cluster Amazon EKS Anda.

Cluster Amazon EKS memiliki wadah dengan sistem End-Of-Life operasi

Gambar kontainer Amazon EKS bergantung pada sistem end-of-life operasi yang tidak lagi didukung atau dikelola oleh pengembang asli. Ini mengekspos wadah ke kerentanan keamanan dan potensi serangan. Ketika sistem operasi mencapai end-of-life, vendor biasanya berhenti merilis nasihat keamanan baru. Penasihat keamanan yang ada juga dapat dihapus dari umpan vendor. Akibatnya, Amazon Inspector berpotensi berhenti menghasilkan temuan untuk diketahui CVEs, menciptakan kesenjangan lebih lanjut dalam cakupan keamanan.

Lihat Sistem operasi yang dihentikan di Panduan Pengguna Amazon Inspector untuk informasi tentang sistem operasi yang telah mencapai akhir masa pakai yang dapat dideteksi oleh Amazon Inspector.

Memperbarui ke versi sistem operasi yang didukung

Kami merekomendasikan memperbarui ke versi sistem operasi yang didukung. Dalam temuan eksposur, buka sumber daya untuk mengakses sumber daya yang terpengaruh. Sebelum memperbarui versi sistem operasi di image container Anda, tinjau versi yang tersedia di Sistem Operasi yang Didukung di Panduan Pengguna Amazon Inspector untuk daftar versi OS yang saat ini didukung. Setelah memperbarui image container Anda, buat kembali dan terapkan ulang container Anda ke klaster Amazon EKS.

Cluster Amazon EKS memiliki wadah dengan paket perangkat lunak berbahaya

Paket berbahaya adalah komponen perangkat lunak yang berisi kode berbahaya yang dirancang untuk membahayakan kerahasiaan, integritas, dan ketersediaan sistem dan data Anda. Paket berbahaya menimbulkan ancaman aktif dan kritis bagi kluster Amazon EKS Anda, karena penyerang dapat mengeksekusi kode berbahaya secara otomatis tanpa memanfaatkan kerentanan. Mengikuti praktik terbaik keamanan, AWS rekomendasikan untuk menghapus paket berbahaya untuk melindungi klaster Anda dari potensi serangan.

Hapus paket berbahaya

Tinjau detail paket berbahaya di bagian Referensi pada tab Kerentanan sifat untuk memahami ancaman. Hapus paket berbahaya yang teridentifikasi dari gambar kontainer Anda. Kemudian, hapus pod dengan gambar yang disusupi. Perbarui penerapan Kubernetes Anda untuk menggunakan gambar kontainer yang diperbarui. Kemudian, terapkan perubahan Anda dan terapkan ulang pod Anda.

Kluster EKS memiliki file berbahaya

File berbahaya berisi kode berbahaya yang dirancang untuk membahayakan kerahasiaan, integritas, dan ketersediaan sistem dan data Anda. File berbahaya menimbulkan ancaman aktif dan kritis bagi cluster Anda, karena penyerang dapat mengeksekusi kode berbahaya secara otomatis tanpa mengeksploitasi kerentanan. Mengikuti praktik terbaik keamanan, AWS rekomendasikan untuk menghapus file berbahaya untuk melindungi klaster Anda dari potensi serangan.

Hapus file berbahaya

Untuk mengidentifikasi volume Amazon Elastic Block Store (Amazon EBS) tertentu yang memiliki file berbahaya, tinjau bagian Sumber Daya dari detail temuan sifat tersebut. Setelah Anda mengidentifikasi volume dengan file berbahaya, hapus file berbahaya yang diidentifikasi. Setelah menghapus file berbahaya, pertimbangkan untuk melakukan pemindaian untuk memastikan bahwa semua file yang mungkin telah diinstal oleh file berbahaya telah dihapus. Untuk informasi selengkapnya, lihat Memulai pemindaian malware On-Demand GuardDuty di.