Deteksi kebocoran pasangan AccessKey, kebocoran AccessKey, kebocoran kredensial, Security Center - Security Center

Security Center memantau kode sumber publik di GitHub secara real time untuk mendeteksi apakah pasangan AccessKey (selanjutnya disebut AK) milik akun Alibaba Cloud atau pengguna RAM Anda bocor, serta memberikan peringatan. Topik ini menjelaskan prinsip deteksi kebocoran pasangan AccessKey dan cara menangani kebocoran tersebut.

Cara kerja

Cakupan

Platform deteksi: Hanya mendukung deteksi kebocoran pasangan AccessKey dalam kode sumber publik di GitHub. Platform hosting kode lain tidak didukung.
Target deteksi: Pasangan AccessKey dari akun Alibaba Cloud (akun utama) dan pengguna RAM, mencakup ID AccessKey maupun Secret AccessKey.

Metode notifikasi

Security Center menggunakan metode notifikasi yang berbeda tergantung pada apakah Secret AccessKey yang bocor (selanjutnya disebut SK) masih valid:

Penting

Pihak ketiga hanya dapat mengeksploitasi pasangan AccessKey untuk mengambil alih semua resource di bawah akun Anda jika **kedua** komponen—ID AccessKey dan Secret AccessKey—telah bocor.

Kondisi notifikasi	Metode notifikasi
ID AccessKey bocor, terlepas dari apakah Secret AccessKey-nya valid atau tidak.	Peringatan pada halaman AccessKey Leak Detection
Secret AccessKey bocor dan masih valid.	Pop-up konsol: Muncul pesan pop-up saat Anda mengunjungi halaman utama konsol Alibaba Cloud atau sebagian besar konsol produk. Pemberitahuan peringatan: Dikirim melalui saluran yang telah dikonfigurasi (pesan internal, email).

Konfigurasikan notifikasi peringatan kebocoran AccessKey

Security Center mengaktifkan notifikasi peringatan kebocoran AccessKey secara default. Peringatan dapat dikirim melalui SMS, panggilan suara, email, dan pesan internal.

Ubah metode notifikasi

Akses Security Center console - System Settings - Notifications. Di bagian atas sisi kiri halaman, pilih wilayah tempat aset yang akan dilindungi berada: Chinese Mainland atau Outside Chinese Mainland.
Pada tab Email/Internal Message, temukan AccessKey Leak Detection dan pilih Notification Method yang diperlukan.

Catatan

Kebocoran AccessKey menimbulkan risiko tinggi. Untuk memastikan notifikasi diterima tepat waktu, kami merekomendasikan memilih semua metode notifikasi. Untuk informasi lebih lanjut, lihat Konfigurasikan notifikasi peringatan.

Tambahkan penerima notifikasi

Secara default, hanya kontak akun yang menerima notifikasi. Untuk menambahkan penerima lain, gunakan salah satu metode berikut:

SMS, email, dan pesan internal:

Pada halaman Basic Receiving Management, ubah penerima pesan di bagian Security Message > Cloud Shield Security Information Notification.

Catatan
Setelah Anda mengubah penerima pesan di sini, perubahan tersebut juga berlaku untuk item notifikasi lain di Security Center, serta item notifikasi produk seperti Anti-DDoS dan Web Application Firewall.

Untuk informasi lebih lanjut, lihat Konfigurasikan peringatan event.

Tangani event kebocoran pasangan AccessKey

Setelah menerima peringatan kebocoran pasangan AccessKey, artinya informasi AK dan SK akun Alibaba Cloud atau pengguna RAM Anda telah terekspos. Tangani dengan mengikuti langkah-langkah berikut:

Langkah 1: Tangani kebocoran secara manual

Security Center tidak mendukung penanganan otomatis event kebocoran pasangan AccessKey. Anda harus terlebih dahulu menyelesaikan operasi berikut secara eksternal:

Hapus atau sembunyikan konten yang bocor di GitHub: Hubungi pihak terkait untuk menghapus atau menyembunyikan file, repositori, atau kode yang berisi informasi pasangan AccessKey.
Tangani AccessKey yang bocor di konsol RAM: Hapus atau nonaktifkan AccessKey yang bocor dan buat yang baru, pastikan operasi bisnis inti tidak terganggu. Untuk informasi lebih lanjut, lihat Hapus pasangan AccessKey untuk pengguna RAM dan Nonaktifkan pasangan AccessKey untuk pengguna RAM.

Perhatikan hal berikut saat menangani AccessKey yang bocor:
- Perubahan berlaku langsung setelah Anda menonaktifkan AccessKey: Setelah Anda menonaktifkan pasangan AccessKey di konsol RAM, perubahan tersebut langsung berlaku. AccessKey tidak dapat lagi digunakan untuk pemanggilan API, sehingga langsung memblokir semua operasi yang dilakukan dengannya.
- Anda mungkin tetap menerima peringatan setelah menonaktifkan AccessKey: Setelah AccessKey dinonaktifkan, pemanggilan yang menggunakan kunci tersebut akan gagal, tetapi karena catatan kunci tersebut masih ada, Security Center mungkin terus mendeteksi risiko kebocoran dan mengirim peringatan. Jika Anda memastikan bahwa AccessKey tersebut tidak lagi digunakan, kami merekomendasikan agar Anda menghapus AccessKey tersebut setelah menonaktifkannya untuk sepenuhnya menghentikan peringatan.
- Evaluasi dampak bisnis dan rencanakan strategi rotasi: Sebelum menonaktifkan atau menghapus AccessKey, periksa apakah kunci tersebut masih digunakan oleh bisnis Anda, misalnya sebagai kredensial yang dikonfigurasi untuk kluster Kubernetes (K8s) atau layanan lain. Jika AccessKey masih digunakan, kami merekomendasikan agar Anda terlebih dahulu membuat AccessKey pengguna RAM baru, menggantikannya dalam konfigurasi bisnis terkait, dan memverifikasi bahwa kunci baru berfungsi sebagaimana mestinya sebelum menonaktifkan dan menghapus AccessKey lama. Hal ini membantu menghindari gangguan pada layanan online.
- Kontrol sementara jika rotasi tidak memungkinkan: Jika Anda tidak dapat menyelesaikan rotasi AccessKey karena alasan tertentu, Anda dapat mengonfigurasi kebijakan kontrol akses (daftar putih alamat IP) sesuai kebutuhan bisnis untuk hanya mengizinkan akses dari alamat IP bisnis tertentu, sebagai langkah mitigasi sementara.
  
  Catatan
  Daftar putih alamat IP yang disebutkan di sini merujuk pada kebijakan kontrol akses di sisi jaringan. Ini berbeda dari daftar putih peringatan (metode penanganan Add to whitelist yang dijelaskan dalam bagian “Tangani event kebocoran pasangan AccessKey” pada topik ini), yang digunakan untuk menandai event positif palsu di konsol. Jangan sampai tertukar antara keduanya.

Langkah 2: Tandai status penanganan di konsol

Setelah menyelesaikan penanganan manual, tandai status event peringatan AccessKey di konsol Security Center:

Akses Security Center console - Risk Governance - AK Leak Detection.
Klik Handle pada kolom Actions event target, pilih salah satu metode penanganan berikut, lalu klik Handle Now.

Metode penanganan	Skenario yang berlaku
Manually Deleted	AccessKey yang bocor tidak lagi digunakan dan telah dihapus.
Manually Disabled AccessKey Pair	AccessKey yang bocor masih perlu digunakan tetapi harus dinonaktifkan sementara. Setelah memilih metode ini, Anda dapat mengaktifkan kembali AccessKey di konsol RAM. Catatan Jika AccessKey telah dinonaktifkan di konsol RAM, Security Center secara otomatis menyinkronkan status nonaktif tersebut, dan status event kebocoran AccessKey berubah menjadi Manually Disabled.
Add to Whitelist	Event merupakan positif palsu atau dapat diabaikan dengan aman. Setelah memilih opsi ini, status berubah menjadi Added to Whitelist dan event dipindahkan ke daftar yang telah ditangani. Jika Anda ingin melanjutkan deteksi, buka halaman detail kebocoran pasangan AccessKey dari daftar yang telah ditangani dan hapus dari daftar putih.

Lihat catatan pemanggilan AccessKey

Dengan meninjau catatan pemanggilan AccessKey, Anda dapat menentukan apakah AccessKey yang bocor dieksploitasi oleh penyerang dan memahami cakupan dampaknya. Langkah-langkah berikut menjelaskan cara melihat event pemanggilan AccessKey secara kronologis melalui ActionTrail.

Catatan

Untuk melihat catatan pemanggilan AccessKey yang mengakses layanan cloud tertentu, Anda dapat menggunakan fitur audit AccessKey di ActionTrail. Untuk informasi lebih lanjut, lihat Kueri log pasangan AccessKey.

Di halaman Security Center console AccessKey Leak Detection, peroleh ID AccessKey yang ingin Anda kueri.
Login ke konsol ActionTrail.
Di panel navigasi kiri, pilih Events > Event Query.
Di bilah navigasi atas, pilih wilayah tempat Anda ingin mengkueri event.
Atur jenis kueri ke ID AccessKey, masukkan ID AccessKey yang ingin dikueri, dan tentukan rentang waktu.
Lihat daftar event yang dipanggil oleh ID AccessKey tersebut. Klik View Details di kolom Actions event target untuk melihat catatan event detail.

Untuk informasi lebih lanjut tentang parameter event manajemen, lihat Struktur event manajemen.

Saat meninjau catatan pemanggilan, gunakan pendekatan berikut untuk menyelidiki potensi serangan dan melacak sumbernya:
- Periksa apakah sumbernya adalah alamat IP internal: Jika alamat IP sumber pemanggilan AccessKey adalah alamat IP internal Alibaba Cloud, host cloud mungkin telah dikompromikan dan berubah menjadi zombie. Kami merekomendasikan agar Anda segera memeriksa status keamanan host cloud terkait dan memperkuat perlindungan host.
- Lacak pembuatan pengguna RAM berbahaya: Jika Anda mencurigai bahwa penyerang menggunakan AccessKey yang bocor untuk membuat pengguna RAM berbahaya, Anda dapat menggunakan detail di ActionTrail atau email peringatan (AccessKey abnormal, alamat IP, dan waktu) untuk mengonfirmasi AccessKey mana yang digunakan untuk membuat pengguna RAM melalui pemanggilan API, serta menentukan apakah pengguna RAM tersebut dibuat melalui login konsol atau pemanggilan API.
- Jenis antarmuka yang diperingatkan mungkin berbeda dari produk yang Anda harapkan: Jenis antarmuka yang ditampilkan dalam peringatan pemanggilan AccessKey abnormal (misalnya, Ecs:DescribeInstances) mungkin berbeda dari produk yang Anda harapkan (misalnya, OSS). Gunakan antarmuka yang sebenarnya ditampilkan dalam peringatan, dan kueri catatan pemanggilan produk terkait di ActionTrail. Jika tidak, Anda mungkin memeriksa log produk yang salah dan melewatkan potensi risiko.
- Batas evaluasi risiko: Jika catatan pemanggilan menunjukkan bahwa penyerang hanya menggunakan pemanggilan API untuk mengkueri informasi resource (misalnya, hanya memanggil operasi Describe), hal ini biasanya tidak langsung menyebabkan intrusi lebih lanjut. Anda dapat menggunakan informasi ini untuk mengevaluasi dampak kebocoran secara wajar.

Monitor pemanggilan AccessKey abnormal

Setelah menangani event kebocoran pasangan AccessKey, kami merekomendasikan agar Anda terus memantau pemanggilan AccessKey abnormal untuk mencegah insiden serupa, merespons dengan cepat saat terjadi kebocoran, dan meminimalkan dampaknya.

Deskripsi bidang antarmuka yang dipanggil

Antarmuka yang dipanggil adalah operasi layanan cloud spesifik yang diakses melalui pemanggilan API menggunakan AccessKey. Nama antarmuka menggunakan format {awalan Produk}:{nama API}, di mana:

Awalan produk: Sesuai dengan nama produk Alibaba Cloud. Misalnya, Ecs merujuk ke ECS, Oss merujuk ke OSS, dan Rds merujuk ke RDS.
Nama API: Sesuai dengan operasi API spesifik. Misalnya, DescribeRegions merujuk ke pengkuerian wilayah yang tersedia.

Tabel berikut mencantumkan nama antarmuka umum beserta produk terkaitnya.

Nama antarmuka	Produk	Deskripsi operasi
Ecs:DescribeRegions	ECS	Kueri wilayah yang tersedia
Oss:GetBucket	OSS	Peroleh informasi bucket
Rds:DescribeDBInstances	RDS	Kueri daftar instansiasi basis data

Deteksi pemanggilan AccessKey abnormal dari perspektif penyerang

Berdasarkan pengalaman pertahanan keamanan dan model besar, Security Center dapat mendeteksi pemanggilan AccessKey abnormal umum. Misalnya, alamat IP yang memanggil AccessKey baru-baru ini melakukan serangan, alamat IP tersebut memanggil pasangan AccessKey milik banyak pengguna secara batch di cloud, API yang dipanggil bersifat sensitif dan AccessKey sebelumnya pernah bocor. Jika pasangan AccessKey dipanggil dari alamat IP di wilayah yang tidak umum untuk mengakses API sensitif, sistem mengidentifikasi pemanggilan tersebut sebagai perilaku abnormal dan memicu peringatan. Jika Anda memastikan bahwa peringatan dipicu oleh perilaku bisnis normal, gunakan ActionTrail console untuk memeriksa catatan pemanggilan pasangan AccessKey tersebut. Setelah memverifikasi pemanggilan tersebut, atur status peringatan menjadi False positive di halaman detail peringatan. Anda tidak dapat mengonfigurasi alamat IP tepercaya untuk fitur ini.

Login ke Security Center console.
Di panel navigasi kiri, pilih Detection and Response > Alerts. Di pojok kiri atas konsol, pilih wilayah tempat aset yang akan dilindungi berada: Chinese Mainland atau Outside Chinese Mainland.

Catatan
Jika Anda telah mengaktifkan Agentic SOC, pilih Agentic SOC > Manage > Alerts.
Atur Alert Type ke Malicious Process (Cloud Threat Detection) dan periksa apakah ada peringatan pemanggilan AccessKey abnormal.

Catatan
Jika terdapat peringatan pemanggilan AccessKey abnormal, lihat detailnya dan segera konfirmasi apakah pemanggilan AccessKey tersebut merupakan perilaku normal.
(Opsional) Konfigurasikan notifikasi peringatan: buka System Configuration > Notification Settings, temukan Alert di kolom Notification Item, dan pilih metode yang Anda inginkan.

Catatan
Edisi Dasar hanya mendukung metode notifikasi pesan internal.

Monitor pemanggilan AccessKey abnormal oleh akun Alibaba Cloud Anda

ActionTrail menyediakan peringatan bawaan untuk memantau pemanggilan AccessKey oleh akun Alibaba Cloud Anda dan pemanggilan AccessKey abnormal. Aktifkan peringatan bawaan Abnormal Frequency of AccessKey Usage Alert dan Root Account AccessKey Usage Detection di konsol ActionTrail untuk menerima notifikasi saat terjadi pemanggilan AccessKey abnormal. Untuk informasi lebih lanjut, lihat Kueri event Insights.

Deteksi pemanggilan AccessKey abnormal berdasarkan perilaku historis

Fitur Insights yang disediakan oleh ActionTrail menganalisis pasangan AccessKey dengan laju pemanggilan abnormal berdasarkan perilaku historis, membantu Anda mendeteksi aktivitas mencurigakan secara tepat waktu. Untuk informasi lebih lanjut tentang cara mengaktifkan dan melihat event Insights, lihat Kueri event Insights di konsol ActionTrail.

Rekomendasi

Jangan gunakan pasangan AccessKey akun Alibaba Cloud Anda (akun utama).
Hindari hard-coding informasi AccessKey dalam kode Anda. Anda dapat mengelola pasangan AccessKey dengan mengonfigurasi variabel lingkungan. Untuk informasi lebih lanjut, lihat Praktik terbaik untuk mencegah kebocoran pasangan AccessKey.
Gunakan repositori GitHub privat untuk mengelola kode, atau siapkan sistem hosting kode internal di dalam perusahaan Anda untuk mencegah kebocoran kode sumber dan informasi sensitif.

FAQ

Apakah menguji unggah file secara lokal dengan SDK pihak ketiga menyebabkan kebocoran AccessKey?

Menggunakan SDK pihak ketiga untuk menguji unggah file secara lokal tidak secara langsung menyebabkan kebocoran AccessKey. Kebocoran AccessKey biasanya disebabkan oleh hard-coding AccessKey dalam teks biasa di kode aplikasi atau repositori kode publik, yang kemudian diperoleh oleh pihak lain.

Kami merekomendasikan agar Anda mengambil langkah-langkah berikut:

Hapus AccessKey yang bocor dan pengguna RAM terkait.
Lakukan rotasi pasangan AccessKey secara berkala.
Kelola kredensial seperti pasangan AccessKey dengan menggunakan variabel lingkungan, bukan menyimpannya dalam teks biasa di kode Anda.

Security Center:Deteksi kebocoran pasangan AccessKey