Resource Access Management:Rencana respons kebocoran AccessKey

Langkah-langkah keamanan Alibaba Cloud

Alibaba Cloud terus berupaya memperkuat keamanan layanan cloud dan membantu Anda melindungi akun. Jika Alibaba Cloud mendeteksi bahwa pasangan AccessKey Anda telah diekspos secara publik—berdasarkan intelijen eksternal—Anda akan segera menerima notifikasi melalui saluran kontak terdaftar. Untuk melindungi bisnis dan data Anda, Alibaba Cloud juga menerapkan perlindungan restriktif pada pasangan AccessKey yang dikompromikan dengan memblokirnya dari pemanggilan API berisiko tinggi untuk layanan cloud tertentu. Untuk detailnya, lihat Perlindungan restriktif untuk AccessKey.

Apa yang harus saya lakukan jika kebocoran AccessKey menyebabkan RAM user tidak dapat login atau akun dibekukan?

Saat Alibaba Cloud mendeteksi bahwa AccessKey berisiko bocor, sistem keamanan secara otomatis memicu mekanisme perlindungan yang dapat membatasi RAM user terkait dari login ke konsol. Anda mungkin menemui pesan error seperti Authentication.Block.AccountFrozen atau "Akun saat ini tidak diizinkan untuk login."

Untuk mengatasi masalah ini:

1. Login ke Konsol RAM menggunakan Akun Alibaba Cloud (akun root). Segera nonaktifkan atau hapus AccessKey yang bocor, lalu buat AccessKey baru untuk menyelesaikan rotasi. Hanya menonaktifkan AccessKey mungkin tidak cukup untuk mencabut pembatasan—Anda harus menghapus atau merotasinya.

2. Setelah penanganan AccessKey selesai, jika RAM user masih tidak dapat login, kirimkan tiket untuk meminta pencabutan pembatasan kontrol risiko keamanan.

Langkah respons manual untuk dugaan kebocoran AccessKey Akun Alibaba Cloud (akun root)

• Jika AccessKey tidak lagi digunakan, buka halaman manajemen AccessKey dan segera nonaktifkan atau hapus.

• Jika AccessKey masih digunakan, buka halaman manajemen AccessKey dan segera lakukan rotasi.

  Buat AccessKey baru dan simpan Rahasia AccessKey secara aman. Ganti AccessKey lama dengan yang baru di aplikasi Anda. Setelah memastikan semuanya berfungsi dengan benar, nonaktifkan dan hapus AccessKey lama.

Langkah respons manual untuk dugaan kebocoran AccessKey RAM user

• Jika AccessKey tidak lagi digunakan, buka Konsol Resource Access Management (RAM) dan nonaktifkan atau hapus AccessKey RAM user tersebut. Untuk petunjuknya, lihat Nonaktifkan AccessKey RAM user dan Hapus AccessKey RAM user.

• Jika AccessKey sedang digunakan dan dapat segera dirotasi, lakukan rotasi sesegera mungkin.

  Buat AccessKey baru dan simpan Rahasia AccessKey secara aman. Ganti AccessKey lama dengan yang baru di aplikasi Anda. Setelah memastikan operasi normal, nonaktifkan dan hapus AccessKey lama. Untuk petunjuknya, lihat Rotasi AccessKey RAM user.

• Jika AccessKey sedang digunakan tetapi tidak dapat segera dirotasi, ikuti langkah-langkah berikut untuk membatasi potensi kerusakan. Segera lakukan rotasi setelah memungkinkan.

  Langkah 1: Kurangi izin AccessKey

  Identifikasi kebutuhan bisnis Anda dan, tanpa mengganggu operasi saat ini, segera kurangi izin untuk pasangan AccessKey yang dicurigai. Batasi izin berisiko tinggi untuk meminimalkan potensi kerusakan pada bisnis dan penagihan Anda. Pertahankan kebijakan restriktif ini hingga Anda menonaktifkan dan menghapus pasangan AccessKey tersebut.

  Izin berisiko tinggi yang direkomendasikan untuk dibatasi: mencegah RAM user membuat RAM user lain atau memberikan izin di RAM, memblokir pelepasan sumber daya ECS, RDS, OSS, atau SLS, serta menonaktifkan pengiriman SMS.

  Contoh berikut menunjukkan kebijakan kustom yang menolak aksi berisiko tinggi. Evaluasi dampaknya dan sesuaikan berdasarkan kebutuhan bisnis Anda.

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": [
          "ram:AddUserToGroup",
          "ram:AttachPolicyToGroup",
          "ram:AttachPolicyToRole",
          "ram:AttachPolicyToUser",
          "ram:ChangePassword",
          "ram:CreateAccessKey",
          "ram:CreateLoginProfile",
          "ram:CreatePolicyVersion",
          "ram:CreateRole",
          "ram:CreateUser",
          "ram:DetachPolicyFromUser",
          "ram:PassRole",
          "ram:SetDefaultPolicyVersion",
          "ram:UpdateAccessKey",
          "ram:SetPasswordPolicy",
          "ram:UpdateRole",
          "ram:UpdateLoginProfile",
          "ram:UpdateUser"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "ecs:DeleteInstance",
          "ecs:DeleteInstances",
          "ecs:DeregisterManagedInstance",
          "ecs:ReleaseDedicatedHost"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "rds:DeleteAccount",
          "rds:DeleteDatabase",
          "rds:DeleteDBInstance",
          "rds:DestroyDBInstance"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "oss:DeleteBucket",
          "oss:DeleteObject",
          "oss:PutBucketAcl",
          "oss:PutBucketPolicy"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "log:DeleteLogStore",
          "log:DeleteProject",
          "log:PutProjectPolicy",
          "log:DeleteProjectPolicy"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "dysms:CreateProductNew",
          "dysms:CreateSmsTemplateNew",
          "dysms:AddSmsTemplate",
          "dysms:SendSms",
          "dysms:SendBatchSms"
        ],
        "Resource": "*"
      }
    ]
  }

  Untuk petunjuknya, lihat Buat kebijakan kustom dan Kelola izin untuk RAM user.

  Tentukan dengan jelas izin minimum yang diperlukan untuk AccessKey dan hapus semua izin yang tidak perlu.

  Langkah 2: Aktifkan MFA untuk RAM user

  Sebagai praktik terbaik, aktifkan autentikasi multi-faktor (MFA) untuk semua RAM user di bawah Akun Alibaba Cloud (akun root) yang mengakses konsol.

  1. Wajibkan MFA untuk RAM user yang login ke konsol di bawah akun root.

     Untuk petunjuknya, lihat Kelola pengaturan login RAM user.

  2. Kaitkan perangkat MFA ke pengguna.

     Untuk petunjuknya, lihat Kaitkan perangkat MFA ke RAM user.

  Langkah 3: Periksa operasi AccessKey yang tidak normal

  Tinjau pasangan AccessKey untuk aktivitas tidak biasa dan selidiki apakah identitas lain juga mungkin dikompromikan. Fokus pada alamat IP sumber yang tidak biasa serta aksi pembuatan atau penghapusan sumber daya di luar operasi bisnis normal.

  Operasi berbahaya yang perlu diselidiki selama periode dugaan kebocoran:

  • Perubahan identitas dan izin: membuat RAM user (CreateUser), membuat AccessKey (CreateAccessKey), melampirkan kebijakan (AttachPolicyToUser), membuat peran (CreateRole), dan mengaktifkan login konsol (CreateLoginProfile). Event seperti CreateLoginProfile, AttachPolicyToUser, dan CreateUser biasanya menunjukkan bahwa penyerang sedang membuat akun backdoor atau meningkatkan hak istimewa. Perhatikan baik-baik alamat IP sumber dan UserAgent dari panggilan API tersebut.

  • Penghapusan atau pelepasan sumber daya: menghapus instance ECS (DeleteInstance), menghapus instance RDS (DeleteDBInstance), dan menghapus bucket OSS (DeleteBucket).

  • Aksi eksfiltrasi data: mengubah ACL bucket OSS (PutBucketAcl) atau kebijakan bucket (PutBucketPolicy).

  • Perilaku API tidak normal: volume besar panggilan API dalam waktu singkat, operasi dari alamat IP atau wilayah yang tidak dikenal, atau operasi batch di luar jam kerja normal.

  Untuk memeriksa: Di Konsol Resource Access Management (RAM), temukan daftar AccessKey RAM user dan tinjau catatan operasi. Atau, buka halaman AccessKey audit di Konsol ActionTrail dan masukkan ID AccessKey untuk mengkueri riwayat operasinya.

  Selain ActionTrail, Anda dapat login ke Konsol Security Center untuk melihat detail peringatan kebocoran AccessKey, termasuk nama RAM user yang dibuat secara jahat, alamat IP pemanggil yang tidak normal, dan informasi relevan lainnya.

  Fitur audit AccessKey ActionTrail menampilkan semua panggilan API yang dilakukan oleh pasangan AccessKey tertentu dalam 90 hari terakhir, termasuk waktu panggilan, nama aksi, alamat IP sumber, dan layanan cloud yang diakses. Untuk petunjuknya, lihat Pantau penggunaan AccessKey dengan ActionTrail.

  Catatan

  Untuk operasi terkait data yang tidak dicakup ActionTrail—seperti yang ada di OSS atau SLS—gunakan fitur logging layanan cloud terkait untuk investigasi.

  Untuk mengonfirmasi cakupan kebocoran: periksa notifikasi yang dikirim melalui email keamanan, pesan teks, atau pesan dalam konsol untuk mengidentifikasi ID AccessKey yang bocor secara spesifik. Jika notifikasi hanya menyebut satu AccessKey dan tidak ada peringatan lain, biasanya hanya AccessKey tersebut yang bocor.

  Periksa juga apakah RAM user atau pasangan AccessKey lain menunjukkan tanda aktivitas tidak normal di luar kunci yang diketahui dikompromikan. Jika Anda menemukan perilaku mencurigakan, konfirmasi dengan personel terkait apakah aksi tersebut sah. Jika kebocoran dicurigai, lakukan tindakan berikut:

  • Jika RAM user harus tetap aktif, segera ubah password-nya dan aktifkan autentikasi multi-faktor (MFA).

  • Jika RAM user tidak dibuat secara sah atau tidak lagi diperlukan, hapus. RAM user yang dihapus masuk ke Keranjang daur ulang. Pantau dampaknya terhadap bisnis Anda, dan pulihkan pengguna tersebut segera jika diperlukan.

  • Untuk aktivitas AccessKey yang tidak normal, batasi izin seperti dijelaskan di atas, lalu rotasi kuncinya.

  Langkah 4: Periksa biaya tidak normal

  Di Biaya dan Pengeluaran, tinjau penagihan Anda untuk biaya tak terduga. Berdasarkan temuan dari langkah sebelumnya, terapkan langkah perlindungan yang ditargetkan untuk layanan yang terdampak.

Mengapa AccessKey saya terdeteksi bocor meskipun disimpan di repositori pribadi, Nacos, atau database offline?

Meskipun Anda yakin AccessKey disimpan dengan aman, kunci tersebut masih dapat terekspos melalui jalur umum berikut:

• Repositori kode: Jika repositori pribadi sebelumnya bersifat publik, telah difork, atau kolaborator mengunggah kode ke lokasi lain, AccessKey mungkin tetap terdeteksi oleh layanan pemindaian.

• Pusat konfigurasi (seperti Nacos): Jika pusat konfigurasi tidak memiliki kontrol akses yang tepat, memiliki kerentanan yang diketahui, atau server telah dikompromikan, AccessKey yang disimpan dalam teks biasa dapat dicuri.

• Penyimpanan offline: Jika aplikasi atau skrip yang membaca AccessKey terhubung ke internet untuk memanggil API, kunci tersebut dapat dicegat selama transmisi atau direkam dalam log.

• Kerentanan aplikasi: Kerentanan eksekusi kode jarak jauh (RCE) atau pembacaan file arbitrer dapat memungkinkan penyerang mencuri AccessKey dari file konfigurasi di server.

Untuk mencegah kebocoran di masa depan:

• Gunakan tool Credentials untuk mengelola kredensial alih-alih menyematkan AccessKey secara langsung.

• Konfigurasikan pembatasan akses jaringan (daftar putih IP) untuk AccessKey.

• Hindari penyematan AccessKey langsung di kode sumber atau file konfigurasi.

Strategi pencegahan kebocoran AccessKey jangka panjang

Lihat Praktik terbaik penggunaan kredensial akses untuk memanggil Alibaba Cloud OpenAPI.

Dapatkah saya meminta penonaktifan darurat AccessKey milik akun berbeda?

Karena kebijakan perlindungan privasi dan isolasi izin, Alibaba Cloud tidak dapat langsung menonaktifkan AccessKey yang tidak termasuk dalam akun yang sedang Anda login berdasarkan laporan kebocoran. Tindakan yang direkomendasikan:

1. Jika Anda mengetahui akun pemilik AccessKey tersebut, hubungi pemilik akun dan minta mereka menanganinya.

2. Jika Anda memiliki akses ke akun yang terkait dengan AccessKey, gunakan API DeleteAccessKey atau Konsol RAM untuk menghapus kunci tersebut sendiri.

3. Untuk AccessKey milik akun lain yang tidak dapat Anda akses, koordinasikan penanganannya melalui saluran kepatuhan hukum atau keamanan.