Access Analyzer menganalisis secara terus-menerus izin identitas RAM dan aktivitas akses dalam Akun Alibaba Cloud atau direktori sumber daya Anda, serta konfigurasi izin sumber daya yang dibagikan dengan akun eksternal. Alat ini mengidentifikasi risiko keamanan seperti akses berlebihan, identitas tidak aktif, dan akses eksternal, serta memberikan saran remediasi. Topik ini menjelaskan prinsip umum untuk konvergensi izin, panduan tata kelola untuk setiap skenario, dan prosedur rollback.
Ikhtisar
Akses berlebihan terjadi ketika identitas RAM (pengguna atau peran) memiliki izin yang melebihi kebutuhan bisnisnya. Hal ini meningkatkan risiko keamanan akibat kesalahan operasional atau kebocoran kredensial, serta menyulitkan audit kepatuhan. Audit izin secara manual memakan waktu dan sulit dipertahankan.
Access Analyzer mencakup dua jenis: alat analisis akses berlebihan dan alat analisis akses eksternal. Alat analisis akses berlebihan secara otomatis mengidentifikasi dan melakukan remediasi terhadap risiko keamanan yang disebabkan oleh izin berlebihan yang diberikan kepada identitas RAM (pengguna dan peran). Alat analisis akses eksternal mengidentifikasi konfigurasi sumber daya yang memungkinkan akses dari identitas di luar zona kepercayaan Anda. Keduanya menyediakan manajemen risiko izin yang komprehensif.
Access Analyzer adalah tool bantu analisis. Temuannya didasarkan pada konfigurasi izin identitas dan sumber daya serta catatan panggilan yang dikumpulkan oleh ActionTrail. Kami menyarankan menggunakan temuan tersebut sebagai titik awal investigasi dan mengonfirmasinya dengan konteks bisnis Anda sebelum melakukan operasi tata kelola.
Prinsip tata kelola umum
Tidak peduli jenis temuannya, ikuti prinsip-prinsip berikut sebelum melakukan konvergensi izin:
Investigasi sebelum bertindak
Saran remediasi dihasilkan berdasarkan algoritma dan data akses, sehingga tidak dapat sepenuhnya memahami konteks bisnis Anda. Sebelum menerapkan rekomendasi apa pun, pastikan bahwa identitas atau sumber daya target tidak lagi memerlukan izin yang dimaksud.
-
Untuk identitas yang kritis bagi produksi (seperti peran operasional, peran CI/CD, atau peran RAM yang digunakan oleh aplikasi inti), hubungi pemilik bisnis yang bertanggung jawab untuk konfirmasi.
-
Untuk rekomendasi penghapusan kebijakan, periksa Accessed services, Granted services, dan Last accessed time pada halaman detail temuan untuk menentukan apakah izin tersebut benar-benar tidak digunakan.
-
Untuk temuan akses eksternal, periksa pihak eksternal spesifik pada halaman detail untuk mengonfirmasi apakah hubungan akses tersebut diperlukan oleh bisnis Anda.
Pilih jendela perubahan yang tepat
Konvergensi izin dapat memengaruhi beban kerja yang sedang berjalan. Kami menyarankan:
-
Hindari melakukan perubahan izin selama jam sibuk bisnis atau jendela rilis penting.
-
Untuk identitas RAM yang digunakan oleh aplikasi produksi online, verifikasi dampak perubahan izin terlebih dahulu di lingkungan pengujian.
-
Untuk sumber daya cross-account (skenario direktori sumber daya), koordinasikan jendela perubahan terlebih dahulu dengan administrator akun target.
Siapkan prosedur rollback
Sebelum melakukan operasi konvergensi izin apa pun, pastikan Anda memiliki kemampuan untuk melakukan rollback dengan cepat. Langkah-langkah spesifik meliputi:
-
Catat status sebelum perubahan: Sebelum menghapus kebijakan, catat semua kebijakan yang saat ini disambungkan ke identitas target, termasuk nama dan jenis kebijakan (sistem atau kustom).
-
Simpan salinan kebijakan kustom: Sebelum menghapus kebijakan kustom, ekspor dan backup konten kebijakan untuk mencegah kegagalan otorisasi ulang jika definisi kebijakan secara tidak sengaja dihapus.
-
Hindari menghapus identitas segera: Untuk pengguna RAM yang tidak aktif, nonaktifkan login konsol dan AccessKey terlebih dahulu. Amati selama periode tertentu sebelum memutuskan untuk menghapus, sehingga Anda dapat segera memulihkan akses jika terjadi kesalahan.
-
Ketahui perintah rollback: Untuk operasi pencabutan otorisasi yang dilakukan di konsol, Anda dapat menggunakan RAM OpenAPI (AttachPolicyToUser, AttachPolicyToRole) untuk segera memulihkan izin saat diperlukan. Untuk detailnya, lihat bagian Rollback dan pemulihan dalam topik ini.
Konsep utama
Finding
Finding adalah objek data yang dihasilkan oleh Access Analyzer yang berisi:
-
Jenis finding: Kategori temuan. Contoh:
-
super user/role
-
privileged user/role
-
inactive user/role
-
over-privileged user/role
-
-
Status: Status temuan. Nilai yang valid: Active, Resolved, dan Archived.
-
Informasi sumber daya: Nama, jenis, dan pemilik sumber daya target.
-
Timestamp: Created At, Analysis Time, dan Updated At.
-
Finding ID: Pengidentifikasi unik temuan.
Saran remediasi
Saran remediasi adalah solusi yang dihasilkan Access Analyzer untuk suatu finding:
-
Penggantian izin: Mengganti kebijakan yang memberikan izin luas dengan kebijakan yang lebih restriktif. Misalnya, Anda dapat mengganti izin super administrator (
AdministratorAccess) dengan izin administrator sistem (PowerUserAccess). -
Penghapusan izin: Menghapus kebijakan yang tidak digunakan.
-
Manajemen identitas: Menonaktifkan atau menghapus identitas yang tidak aktif.
-
Arsip finding: Mengarsipkan temuan yang terkait dengan perilaku otorisasi yang disengaja.
Logika keputusan
Access Analyzer mengklasifikasikan akses berlebihan berdasarkan prioritas berikut. Jika identitas RAM memenuhi beberapa kondisi, jenis dengan prioritas tertinggi yang berlaku.
|
Prioritas |
Jenis temuan |
Deskripsi |
|
1 |
super user/role |
Identitas RAM memiliki izin manajemen atas semua sumber daya akun. Misalnya, identitas tersebut memiliki kebijakan |
|
2 |
privileged user/role |
Identitas RAM memiliki izin operasional berisiko tinggi di luar kebijakan |
|
3 |
inactive user/role |
Identitas RAM tidak mengakses sumber daya atau data apa pun dalam periode Unused Access Age yang ditentukan (90 hari secara default), dan tidak memenuhi kondisi prioritas 1 atau 2. Catatan: Pengguna atau peran tanpa izin tidak diklasifikasikan sebagai pengguna/peran tidak aktif, meskipun tidak aktif. |
|
4 |
over-privileged user/role |
Identitas RAM memiliki izin tingkat layanan atau tingkat aksi yang tidak digunakan dalam periode Unused Access Age yang ditentukan dan tidak memenuhi kondisi sebelumnya. Catatan: Granularitas yang didukung bervariasi tergantung layanan, sebagaimana dijelaskan dalam bagian Supported granularity di Batasan. |
Memulai cepat: Penyesuaian ukuran izin
Panduan ini menggunakan Access Analyzer untuk menonaktifkan pengguna RAM yang tidak aktif.
Prasyarat
Pastikan persyaratan berikut terpenuhi:
-
Analyzer dengan tipe Over-privileged Access tersedia di konsol Access Analyzer.
-
Anda memiliki izin yang diperlukan. Kami menyarankan agar Anda memberikan kebijakan
AliyunRAMAccessAnalyzerFullAccessdanAliyunRAMFullAccesskepada operator.
Prosedur
-
Temukan temuan
-
Login ke Konsol RAM.
-
Di panel navigasi kiri, pilih .
-
Di bilah navigasi atas, pilih wilayah tempat analyzer berada.
-
Di tab , temukan temuan Active dengan tipe Inactive User dan klik angkanya.

-
-
Lihat dan terapkan saran remediasi
-
Di daftar Findings, pilih pengguna RAM yang telah Anda konfirmasi tidak lagi diperlukan, lalu klik Finding ID yang sesuai.
-
Di halaman detail Findings, klik tab Advices di kolom Actions. Setelah menunggu sebentar, sistem akan menampilkan saran Remove unused identities. Klik Go for Governance.

-
-
Anda akan diarahkan ke halaman detail pengguna di Konsol RAM. Anda dapat menonaktifkan login konsol, menonaktifkan AccessKey, atau menghapus pengguna sesuai kebutuhan bisnis Anda.
-
Verifikasi hasilnya. Kembali ke konsol Access Analyzer. Anda dapat mengarsipkan temuan tersebut. Jika tidak, statusnya akan berubah secara otomatis menjadi Resolved setelah siklus analisis berikutnya.
Panduan remediasi akses berlebihan
Gunakan panduan ini untuk menerapkan remediasi yang tepat untuk setiap jenis temuan.
Temuan dari analyzer akses berlebihan mencerminkan penggunaan izin dalam periode analisis. Beberapa izin mungkin tidak digunakan selama periode ini tetapi masih diperlukan dalam skenario tertentu (seperti penyelesaian triwulan, latihan pemulihan bencana, atau penerapan rilis). Evaluasi berdasarkan kebutuhan bisnis aktual Anda sebelum mengambil tindakan.
Remediasi super user/role: Ganti dengan izin administrator sistem
Identitas super administrator biasanya memiliki kebijakan AdministratorAccess, yang memberikan izin manajemen atas semua sumber daya dalam akun. Identitas ini memiliki tingkat risiko tertinggi — kebocoran kredensial akan berdampak pada seluruh akun. Jika identitas tersebut benar-benar memerlukan izin administrator (diharapkan), aktifkan MFA untuk pengguna RAM dan arsipkan temuannya. Jika identitas tersebut tidak memerlukan izin administrator penuh (tidak diharapkan), ganti dengan PowerUserAccess (mempertahankan semua izin manajemen kecuali izin terkait RAM dan penagihan).
-
Di tab atau , temukan entri dengan Finding Type super user/role dan klik Finding ID tertentu.
-
Di halaman detail Findings, klik tab Advices.
-
Di panel Advices, temukan saran untuk mengganti izin dengan izin administrator sistem (
PowerUserAccess). -
Lakukan operasi yang sesuai berdasarkan pemilik sumber daya:
-
Akun saat ini: Klik Apply Recommendation. Sistem secara otomatis menyambungkan kebijakan
PowerUserAccesske identitas target, lalu mencabut kebijakanAdministratorAccess.
-
Cross-account: Penerapan otomatis tidak didukung. Klik Repeat untuk menyalin URL. Kemudian, login ke akun tempat sumber daya target berada, akses URL tersebut, dan ganti izin secara manual.

-
-
(Opsional) Jika analyzer tidak memberikan saran remediasi, lihat Mengapa tidak ada saran remediasi untuk temuan saya?
Risiko dan rollback: Operasi ini mengubah izin inti. Sebelum melanjutkan, pastikan kebijakan PowerUserAccess memenuhi kebutuhan kerja harian identitas tersebut. Jika terjadi masalah setelah operasi, buka Konsol RAM dan segera berikan kembali izin AdministratorAccess kepada identitas tersebut.
Remediasi super user/role: Hapus kebijakan yang tidak digunakan
Jika kebijakan sistem atau kustom yang tidak digunakan juga disambungkan ke identitas super user, sistem merekomendasikan untuk menghapusnya. Saran terpisah dihasilkan untuk setiap kebijakan.
-
Di tab atau , temukan entri dengan Finding Type super user/role dan klik Finding ID tertentu.
-
Di halaman detail Findings, klik tab Advices di kolom Actions.
-
Di panel Advices, temukan saran untuk menghapus kebijakan tersebut.
-
Lakukan operasi yang sesuai berdasarkan pemilik sumber daya:
-
Akun saat ini: Klik Apply Recommendation. Sistem secara otomatis mencabut kebijakan tersebut.

-
Cross-account: Klik Repeat untuk menyalin URL. Login ke akun target, akses URL tersebut, dan cabut kebijakan secara manual.
-
-
(Opsional) Jika analyzer tidak memberikan saran remediasi, lihat Mengapa tidak ada saran remediasi untuk temuan saya?
Risiko dan rollback: Konfirmasi bahwa kebijakan tersebut tidak lagi diperlukan. Jika Anda secara tidak sengaja menghapusnya, berikan kembali kebijakan izin yang dihapus ke identitas tersebut di Konsol RAM.
Remediasi privileged user/role: Hapus kebijakan berisiko tinggi yang tidak digunakan
Untuk privileged user/role, saran remediasinya adalah menghapus kebijakan izin berisiko tinggi yang tidak digunakan. Prosedurnya sama dengan Remediasi super user/role: Hapus kebijakan izin yang tidak digunakan.
Remediasi inactive user/role: Nonaktifkan atau hapus identitas
Identitas tidak aktif tidak memiliki aktivitas akses dalam periode akses tidak digunakan yang ditentukan. Identitas yang lama tidak aktif namun memiliki kredensial valid merupakan potensi risiko keamanan.
Sebelum mengambil tindakan, konfirmasi: apakah identitas tersebut digunakan secara musiman atau periodik (seperti untuk penyelesaian keuangan akhir bulan atau audit triwulan); apakah itu akun cadangan atau pemulihan bencana (yang biasanya tidak aktif tetapi kritis saat failover); untuk peran RAM, apakah layanan backend hanya memanggil peran tersebut dalam kondisi luar biasa (seperti operasi darurat atau peran penanganan alert). Jika salah satu kondisi ini berlaku, arsipkan temuannya alih-alih menghapus identitas tersebut.
Jika Anda memastikan identitas tersebut tidak lagi diperlukan, praktik terbaiknya adalah menonaktifkan terlebih dahulu, amati, lalu hapus:
-
Di tab atau , temukan entri dengan tipe inactive user/role dan klik Finding ID tertentu.
-
Di halaman detail Findings, klik tab Advices di kolom Actions.
-
Di panel Advices, temukan saran untuk Remove Unused Principals.
-
Lakukan operasi yang sesuai berdasarkan pemilik sumber daya:
-
Akun saat ini: Klik Go for Governance. Anda akan diarahkan ke halaman detail pengguna atau peran di Konsol RAM. Anda dapat menghapus pengaturan login, menonaktifkan atau menghapus AccessKey, atau menghapus identitas tersebut.

-
Cross-account: Klik Copy Resource URL. Login ke akun target dan akses URL tersebut untuk memproses permintaan.

-
-
(Opsional) Jika analyzer tidak memberikan saran remediasi, lihat Mengapa tidak ada saran remediasi untuk temuan saya?
Remediasi over-privileged user/role: Hapus kebijakan yang tidak digunakan
Untuk over-privileged user/role, saran remediasinya adalah menghapus kebijakan izin yang tidak digunakan. Prosedurnya sama dengan Remediasi super user/role: Hapus kebijakan izin yang tidak digunakan.
Arsipkan temuan
Jika suatu temuan tidak memerlukan aksi, arsipkan. Setelah pengarsipan, Status dari Findings akan berubah dari Active menjadi Archived.
-
Arsipkan satu temuan: Di kolom Actions pada daftar Findings atau di panel Advices, klik Archive.
-
Untuk secara otomatis mengabaikan jenis temuan tertentu, klik Save as Archive Rule. Tetapkan kondisi aturan untuk memastikan semua temuan yang cocok di masa depan secara otomatis diarsipkan. Arsipkan temuan secara otomatis.
-
Lihat dan batalkan arsip temuan: Secara default, hanya temuan Active yang ditampilkan. Untuk melihat atau membatalkan arsip temuan Archived, atur filter Status ke Archived di halaman Findings. Untuk entri yang perlu diproses ulang, klik Unarchive. Status entri tersebut akan berubah kembali menjadi Active.

Praktik terbaik tata kelola akses eksternal
Alat analisis akses eksternal memeriksa Bucket Policy OSS, ACL, dan kebijakan kepercayaan peran RAM untuk mengidentifikasi konfigurasi sumber daya yang memungkinkan akses dari identitas di luar zona kepercayaan Anda. Tujuan utamanya adalah manajemen batas akses — memastikan hanya identitas eksternal yang dimaksudkan yang dapat mengakses sumber daya Anda.
Berbeda dengan alat analisis akses berlebihan, alat analisis akses eksternal melakukan analisis statis konfigurasi kebijakan sumber daya alih-alih statistik perilaku akses dinamis. Oleh karena itu, "dapat diakses secara eksternal" hanya berarti konfigurasi kebijakan memungkinkan akses eksternal — tidak menunjukkan bahwa sumber daya tersebut benar-benar diakses atau terjadi kebocoran data.
Alur kerja investigasi
Sebelum melakukan remediasi temuan akses eksternal, ikuti langkah investigasi berikut:
-
Identifikasi pihak eksternal: Di halaman detail temuan, periksa pihak eksternal spesifik. Untuk Bucket OSS, periksa apakah mencakup pengguna anonim (AllUsers) atau akun Alibaba Cloud tertentu. Untuk peran RAM, tinjau entitas tepercaya dalam kebijakan kepercayaan.
-
Tentukan apakah akses tersebut diperlukan bisnis: Periksa apakah akses eksternal merupakan bagian dari kolaborasi bisnis normal (seperti akses akun mitra, berbagi sumber daya lintas departemen dalam grup, atau penerapan cross-account dalam arsitektur multi-cloud).
-
Verifikasi cakupan izin sesuai: Bahkan jika akses eksternal diharapkan, periksa apakah izin yang diberikan mengikuti prinsip hak istimewa minimal. Misalnya, apakah mitra diberikan izin operasi yang terlalu luas.
-
Koordinasi lintas akun: Jika akses eksternal melibatkan akun Alibaba Cloud lain, konfirmasi ketergantungan bisnis dengan kedua pihak (pihak yang mengakses dan pemilik sumber daya) sebelum memperketat kebijakan, untuk menghindari gangguan pada bisnis mitra.
Remediasi akses eksternal Bucket OSS
Akses eksternal ke Bucket OSS biasanya disebabkan oleh konfigurasi Bucket Policy, ACL Bucket, atau tidak adanya pengaturan "Block Public Access".
Jika akses eksternal diharapkan (misalnya, mitra perlu membaca Bucket tertentu):
-
Periksa apakah otorisasi saat ini mengikuti prinsip hak istimewa minimal. Misalnya, verifikasi bahwa hanya operasi tingkat Objek yang diperlukan (seperti
GetObject) yang diberikan, bukan izin tingkat Bucket penuh. -
Persempit cakupan otorisasi dalam Bucket Policy dari wildcard (*) ke ID akun spesifik atau ARN peran RAM.
-
Arsipkan temuan untuk mencegah peringatan berulang.
Jika akses eksternal tidak diharapkan (misalnya, Bucket dikonfigurasi untuk akses publik):
-
Buka konsol OSS dan aktifkan fitur "Block Public Access" tingkat Bucket. Ini secara global mencegah akses publik ke Bucket dan merupakan langkah remediasi tercepat.
-
Tinjau Bucket Policy dan hapus konfigurasi otorisasi cross-account yang tidak disengaja atau akses anonim (Principal diatur ke *).
-
Periksa ACL Bucket untuk memastikan tidak diatur ke "Public Read" atau "Public Read/Write".
-
Setelah melakukan perubahan, tunggu alat analisis akses eksternal melakukan analisis ulang (biasanya 3–5 menit setelah perubahan kebijakan) dan konfirmasi bahwa status temuan berubah menjadi "Resolved".
Remediasi kepercayaan cross-account peran RAM
Kebijakan kepercayaan peran RAM menentukan identitas eksternal mana yang dapat mengasumsikan peran tersebut. Kebijakan kepercayaan yang terlalu permisif menciptakan risiko peningkatan hak istimewa cross-account.
Jika kepercayaan cross-account diharapkan (seperti otorisasi cross-account dalam arsitektur multi-cloud):
-
Tinjau elemen Condition dalam kebijakan kepercayaan. Tambahkan batasan jika memungkinkan (seperti menentukan rentang IP sumber atau mewajibkan MFA) untuk mengurangi dampak kebocoran kredensial.
-
Tinjau kebijakan izin yang disambungkan ke peran dan pastikan mengikuti prinsip hak istimewa minimal.
-
Arsipkan temuan.
Jika terjadi kepercayaan lintas akun yang tidak diinginkan:
-
Buka Konsol RAM, buka halaman detail peran, dan edit kebijakan kepercayaan.
-
Persempit cakupan Principal dalam kebijakan kepercayaan untuk hanya mencakup ID akun atau pengidentifikasi layanan yang diperlukan.
-
Hapus otorisasi wildcard yang tidak perlu atau otorisasi untuk akun yang sudah kadaluarsa.
-
Setelah melakukan perubahan, pantau sistem bisnis yang bergantung. Beri perhatian khusus pada aplikasi yang mengasumsikan peran ini dari akun lain — jika kebijakan kepercayaan yang diperketat menyebabkan kegagalan STS AssumeRole, segera pulihkan kebijakan tersebut.
Rollback dan pemulihan
Jika Anda menemukan masalah bisnis atau kesalahan operasional setelah melakukan konvergensi izin, gunakan metode berikut untuk segera memulihkan:
Pulihkan kebijakan izin yang dicabut
Jika Anda mencabut kebijakan menggunakan konsol Access Analyzer, gunakan perintah OpenAPI berikut untuk menyambungkannya kembali:
-
Pengguna RAM:
aliyun ram AttachPolicyToUser --PolicyType <System|Custom> --PolicyName <PolicyName> --UserName <UserName> -
Peran RAM:
aliyun ram AttachPolicyToRole --PolicyType <System|Custom> --PolicyName <PolicyName> --RoleName <RoleName> -
Grup pengguna:
aliyun ram AttachPolicyToGroup --PolicyType <System|Custom> --PolicyName <PolicyName> --GroupName <GroupName>
-
Untuk kebijakan sistem, cukup sambungkan kembali kebijakan dengan nama yang sama.
-
Untuk kebijakan kustom, jika definisi kebijakan itu sendiri telah dihapus, perintah di atas tidak dapat memulihkannya. Selalu backup konten kebijakan kustom di halaman Policies Konsol RAM sebelum menghapusnya.
Pulihkan identitas yang dinonaktifkan
-
Pengguna RAM: Jika Anda hanya menonaktifkan login konsol dan AccessKey, buat ulang konfigurasi login (CreateLoginProfile) dan aktifkan kembali AccessKey (UpdateAccessKey --Status Active).
-
Peran RAM: Jika Anda menghapus peran tanpa mencadangkan informasi kebijakan kepercayaan dan kebijakan yang disambungkan, Anda harus membuat dan mengonfigurasinya kembali secara manual.
Pulihkan kebijakan kepercayaan peran RAM yang dimodifikasi
Jika modifikasi kebijakan kepercayaan menyebabkan masalah bisnis cross-account, segera pulihkan kebijakan kepercayaan asli:
-
Buka Konsol RAM dan buka tab Trust Policy di halaman detail peran.
-
Jika Anda mencadangkan kebijakan kepercayaan asli, tempelkan kembali langsung.
-
Jika Anda tidak mencadangkan, tambahkan kembali secara manual entitas tepercaya yang salah dihapus. Untuk ID akun yang tidak pasti, kueri catatan panggilan AssumeRole terbaru di ActionTrail untuk mengidentifikasi identitas eksternal mana yang secara sah mengasumsikan peran tersebut baru-baru ini.
Pulihkan temuan yang diarsipkan
Jika temuan diarsipkan secara tidak sengaja, filter daftar temuan berdasarkan status Archived, temukan entri tersebut, dan klik Unarchive. Temuan tersebut akan kembali ke status Active.
Batasan
-
Jenis analyzer: Fitur ini hanya mendukung analyzer tipe Over-privileged Access dan tidak mendukung analyzer tipe External Access.
-
Granularitas yang didukung: Analyzer akses berlebihan menganalisis izin semua identitas RAM kecuali peran terkait layanan dalam direktori sumber daya atau akun saat ini berdasarkan informasi audit izin. Jenis kebijakan, layanan cloud, dan granularitas yang didukung sama dengan fitur audit izin, sebagaimana tercantum dalam Layanan yang kompatibel dengan fitur audit izin. Jika kebijakan berisi izin untuk layanan yang tidak didukung, analyzer tidak dapat memberikan saran remediasi untuk menghapus izin tersebut.
-
Jenis kebijakan (hanya untuk penggantian super administrator): Saran remediasi untuk mengganti izin super administrator hanya mendukung kebijakan sistem
AdministratorAccess. Kebijakan administrator kustom tidak didukung. -
Konten kebijakan: Jika kebijakan berisi pernyataan
DenyatauNotAction, analyzer tidak dapat memberikan saran remediasi untuk menghapus izin. -
Cakupan otorisasi: Jika cakupan otorisasi izin administrator adalah Resource Group alih-alih Account, identitas tersebut tidak diidentifikasi sebagai super administrator.
-
Metode otorisasi: Izin dapat diberikan langsung kepada pengguna atau peran, atau diwariskan melalui grup pengguna. Analyzer dapat mengidentifikasi kedua metode otorisasi tetapi tidak memberikan saran remediasi otomatis untuk izin yang diwariskan dari grup pengguna. Anda harus melakukan remediasi temuan ini secara manual.
-
Latensi data: Saran remediasi dihasilkan dari temuan, yang mungkin memiliki latensi data hingga 24 jam. Jika ketepatan waktu saran sangat penting, Anda dapat memicu pemindaian ulang secara manual dengan mengklik Rescan di halaman detail temuan, lalu periksa kembali sarannya.

FAQ
Dapatkah saya menerapkan saran remediasi secara batch?
Apply Recommendation batch tidak didukung. Namun, Anda dapat membuat aturan arsip untuk secara otomatis mengabaikan jenis temuan yang diharapkan.
Seberapa mutakhir data temuan?
Anda dapat melihat bidang Updated At untuk setiap temuan di daftar Findings, atau periksa waktu Analyzed At dan Updated At di halaman detail temuan untuk mengonfirmasi kebaruan datanya. Semua waktu ditampilkan dalam zona waktu lokal Anda.

Mengapa saran remediasi tidak tersedia?
Di halaman detail temuan, jika tidak ada saran yang ditampilkan saat Anda mengklik tab Advices, Anda harus melakukan remediasi temuan tersebut secara manual, misalnya dengan menghapus izin atau mengarsipkan temuan.
Alasan umum:
-
Penggantian izin super administrator: Jika identitas menggunakan izin selama periode idle yang ada dalam kebijakan
AdministratorAccesstetapi tidak ada dalam kebijakanPowerUserAccess, analyzer tidak dapat merekomendasikan downgrade. -
Penghapusan izin yang tidak digunakan: Jika identitas menggunakan beberapa layanan dalam kebijakan selama periode idle, analyzer tidak merekomendasikan penghapusannya.
-
Sistem tidak menghasilkan saran remediasi untuk izin yang diwariskan melalui grup pengguna atau untuk layanan di luar cakupan yang didukung. Batasan.
Mengapa "Accessed services" kosong? Apakah ini berarti identitas tersebut tidak pernah digunakan?
Tidak selalu. Kemungkinan penyebabnya meliputi:
-
Identitas tersebut dibuat dan digunakan sebelum tanggal mulai pelacakan (1 Februari 2024) tetapi tidak memiliki aktivitas akses baru-baru ini.
-
Akses identitas tersebut melibatkan operasi plane data atau panggilan delegasi layanan internal yang berada di luar cakupan analisis saat ini.
-
Pengiriman log ActionTrail mengalami penundaan (maksimal 24 jam).
Kami menyarankan memeriksa log ActionTrail secara langsung untuk menyelidiki lebih lanjut perilaku akses historis identitas tersebut.
Apakah "akses publik" dalam temuan akses eksternal berarti data saya telah bocor?
Tidak selalu. Alat analisis akses eksternal menentukan keberadaan akses publik berdasarkan analisis statis konfigurasi kebijakan. Alat ini tidak dapat menentukan apakah data dalam bucket benar-benar telah diunduh atau diakses. Bahkan jika kebijakan memungkinkan akses publik, risiko aktual mungkin rendah jika bucket tidak berisi data sensitif atau jalur aksesnya tidak diketahui publik. Namun, konfigurasi akses publik yang tidak disengaja harus segera diperbaiki.
Mengapa temuan tidak langsung hilang setelah saya menerapkan saran remediasi?
Setelah Access Analyzer mendeteksi perubahan izin, alat ini memerlukan waktu (biasanya 3–5 menit) untuk menganalisis ulang identitas yang terpengaruh. Selama periode ini, status temuan asli diperbarui menjadi Resolved. Jika identitas tersebut masih memenuhi kondisi risiko berdasarkan konfigurasi izin baru, temuan baru akan dihasilkan. Jika identitas tersebut tidak lagi memenuhi kondisi risiko apa pun setelah perubahan, tidak akan dihasilkan temuan baru.
Apakah ada risiko dengan remediasi batch?
Ya. Meskipun Access Analyzer mendukung remediasi sekali klik untuk beberapa temuan, operasi batch mengubah status izin beberapa identitas secara bersamaan. Jika salah satu identitas tersebut penting bagi bisnis Anda, dampaknya bisa luas. Kami menyarankan mengikuti pendekatan inkremental: konfirmasi setiap temuan secara individual dan proses satu per satu, terutama saat pertama kali menggunakan Access Analyzer untuk tata kelola.
Bagaimana cara menangani temuan untuk akun anggota dalam skenario direktori sumber daya?
Analyzer yang dibuat di cakupan direktori sumber daya menganalisis identitas RAM di semua akun anggota. Untuk temuan cross-account:
-
Saran remediasi untuk kebijakan izin yang tidak digunakan tidak dapat diterapkan langsung dari akun saat ini. Konsol menyediakan tautan sumber daya agar Anda dapat login ke akun target dan menangani temuan secara manual.
-
Penghapusan atau penonaktifan identitas yang tidak aktif juga memerlukan login ke akun target.
-
Tata kelola akses eksternal untuk bucket OSS dan peran RAM dapat menganalisis sumber daya di akun anggota, tetapi modifikasi kebijakan tetap perlu dilakukan di akun target atau konsol layanan cloud yang sesuai.
-
Kami menyarankan menyinkronkan progres tata kelola secara rutin dengan administrator akun anggota, atau menggunakan aturan arsip untuk secara otomatis mengarsipkan temuan yang diketahui dan diharapkan guna mengurangi biaya koordinasi cross-account.
Bagaimana cara menentukan apakah izin memenuhi persyaratan?
Di halaman detail temuan, periksa atribut-atribut berikut untuk menentukan apakah izin sesuai dengan kebutuhan bisnis. Jika izin melebihi kebutuhan, terapkan saran remediasi atau sesuaikan konfigurasi secara manual.
-
Accessed Services/Authorized Services:
-
Authorized Services adalah jumlah layanan yang didukung analyzer dalam kebijakan identitas. Lihat daftar Access Records untuk detailnya.
-
Accessed Services adalah jumlah layanan yang digunakan identitas selama periode idle. Layanan ini diprioritaskan dalam daftar Access Records dengan waktu akses terakhir. Anda dapat memfilter layanan yang diakses selama periode tersebut.
-
-
Performed Actions/Authorized Actions:
-
Authorized Actions adalah jumlah total izin operasional di bawah setiap layanan yang diotorisasi.
-
Performed Actions adalah jumlah aksi yang dilakukan identitas selama periode idle, sebagaimana terdeteksi oleh analyzer.
CatatanCatatan: Granularitas audit izin yang didukung bervariasi tergantung layanan cloud. Beberapa layanan tidak mendukung statistik akses tingkat aksi. Untuk layanan tersebut, kolom Performed Actions/Authorized Actions kosong. Layanan yang kompatibel dengan fitur audit izin.
-
-
Last Accessed At: Waktu setiap layanan terakhir diakses.

Untuk layanan yang mendukung audit tingkat aksi, klik View Actions di kolom Actions untuk melihat aksi yang diakses identitas dan waktu akses terakhirnya. Aksi dengan tag Privileged berisiko tinggi dan perlu diperhatikan.
