All Products
Search
Document Center

Resource Access Management:Ikhtisar peran RAM

Last Updated:Mar 07, 2026

Apa itu peran RAM?

Peran Resource Access Management (RAM) adalah identitas RAM yang dilengkapi kebijakan tertentu, mirip dengan pengguna RAM. Namun, peran tidak secara eksklusif dikaitkan dengan satu orang atau aplikasi tertentu. Sebaliknya, peran tersebut dapat diasumsikan oleh pihak tepercaya yang berwenang—seperti pengguna atau layanan lain—yang memerlukan izin tersebut. Peran tidak memiliki kredensial jangka panjang seperti kata sandi atau pasangan Kunci Akses (AccessKey pair). Ketika suatu principal mengasumsikan peran, Security Token Service (STS) akan menghasilkan kredensial keamanan sementara secara dinamis yang hanya berlaku untuk sesi tersebut.

Setiap peran RAM merupakan resource dalam akun Anda dengan Alibaba Cloud Resource Name (ARN) unik: acs:ram::<account-id>:role/<role-name>. Anda menggunakan ARN ini untuk mereferensikan peran dalam kebijakan atau panggilan API. Untuk mengetahui cara menemukan ARN suatu peran, lihat Lihat informasi tentang peran RAM.

Mengapa menggunakan peran RAM?

Peran RAM menyediakan cara yang lebih aman dan efisien untuk mengelola akses ke resource Alibaba Cloud Anda.

  • Hak istimewa sementara yang ditingkatkan: Anda dapat menggunakan peran untuk memberikan hak istimewa tingkat lebih tinggi secara sementara kepada suatu principal guna menjalankan tugas tertentu. Pendekatan ini mengurangi risiko yang terkait dengan kredensial jangka panjang berhak istimewa tinggi.

  • Akses resource cross-account: Anda dapat menggunakan peran untuk memberikan akses kepada principal di satu akun Alibaba Cloud ke resource di akun lain. Pendekatan ini memungkinkan manajemen terpusat dan berbagi resource secara aman tanpa harus membuat dan mengelola identitas duplikat.

  • Akses layanan dan aplikasi yang aman: Aplikasi yang berjalan pada instans Elastic Compute Service (ECS) atau layanan lain dapat mengasumsikan peran untuk memperoleh kredensial sementara dengan memanggil operasi AssumeRole. Hal ini menghindari penyematan pasangan Kunci Akses (AccessKey pair) secara langsung dalam kode aplikasi Anda.

Konsep utama

Pemahaman konsep-konsep berikut sangat penting untuk menggunakan peran RAM secara efektif.

image

Principal

Principal adalah identitas yang dapat mengasumsikan peran. Kebijakan kepercayaan (trust policy) peran tersebut menentukan principal mana yang dipercaya. Principal terbagi menjadi tiga jenis:

Jenis

Deskripsi

Kasus penggunaan umum

Akun Alibaba Cloud

Akun itu sendiri atau RAM user atau peran RAM lain dalam akun tersebut—dapat mengasumsikan peran tersebut. Akun tersebut bisa merupakan akun pemilik peran atau akun yang berbeda.

RAM user beralih identitas di Konsol atau memanggil operasi AssumeRole menggunakan CLI atau SDK untuk mengasumsikan peran.

Layanan Alibaba Cloud

Layanan cloud tertentu dapat mengasumsikan peran tersebut. Jenis peran ini disebut service role.

Delegasikan layanan cloud untuk bertindak atas nama Anda. Misalnya, tetapkan instance RAM role ke instans ECS sehingga aplikasi yang berjalan di dalamnya dapat mengakses data di bucket Object Storage Service (OSS).

Banyak layanan cloud juga menggunakan service-linked role—yaitu peran yang telah ditentukan sebelumnya dan dikaitkan dengan layanan tersebut—untuk mengaktifkan fungsionalitasnya.

Identity provider (IdP)

Pengguna dari IdP tertentu (yang mendukung SAML 2.0 atau OIDC) dapat mengasumsikan peran tersebut. Hal ini memungkinkan federasi identitas.

Pengguna dari IdP perusahaan Anda dapat menggunakan single sign-on (SSO) berbasis peran untuk login ke Konsol Alibaba Cloud.

Pengguna federasi dapat memanggil operasi AssumeRoleWithSAML atau AssumeRoleWithOIDC, dengan menyediakan token dari IdP (berupa pernyataan SAML atau token ID) untuk memperoleh kredensial sementara.

Catatan

Ketika akun Alibaba Cloud ditentukan sebagai principal tepercaya, setiap identitas dalam akun tersebut dapat mengasumsikan peran tersebut secara default. Anda dapat mempersempit cakupan ini dengan memodifikasi kebijakan kepercayaan peran untuk membatasi akses hanya ke pengguna RAM atau peran tertentu. Untuk informasi selengkapnya, lihat Modifikasi kebijakan kepercayaan peran RAM.

Asumsi peran

Mengasumsikan peran RAM adalah proses di mana principal tepercaya secara sementara memperoleh izin dari peran tersebut. Saat peran diasumsikan, Security Token Service (STS) menerbitkan serangkaian kredensial keamanan sementara. Tindakan ini memulai sesi peran, di mana izin identitas asli ditangguhkan. Peran yang diasumsikan dapat berasal dari akun yang sama atau akun berbeda (asumsi peran cross-account).

Anda dapat mengasumsikan peran dengan beralih identitas di Konsol atau dengan memanggil operasi API seperti AssumeRole atau AssumeRoleWithSAML / AssumeRoleWithOIDC.

Kebijakan kepercayaan

Kebijakan kepercayaan adalah dokumen wajib berformat JSON yang dilampirkan pada peran RAM. Dokumen ini menentukan principal mana saja (akun, pengguna, peran, atau layanan cloud) yang dapat mengasumsikan peran tersebut. Kebijakan ini merupakan kebijakan berbasis resource, di mana resourcenya adalah peran itu sendiri.

Fungsi utama:

  • Menentukan siapa yang dapat mengasumsikan peran: Elemen Principal dalam kebijakan kepercayaan menentukan principal tepercaya.

  • Mengontrol kondisi asumsi: Anda dapat menambahkan elemen Condition untuk membatasi lebih lanjut kapan peran dapat diasumsikan, misalnya dengan mewajibkan Autentikasi Multi-Faktor (MFA) atau alamat IP sumber tertentu.

  • Bekerja sama dengan kebijakan akses: Kebijakan kepercayaan menentukan siapa yang dapat mengasumsikan peran, sedangkan kebijakan akses yang dilampirkan pada peran menentukan apa yang dapat dilakukan oleh peran tersebut setelah diasumsikan.

Contoh:

Kebijakan kepercayaan berikut memungkinkan setiap identitas dalam akun 123456789012**** untuk mengasumsikan peran tersebut:

{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::123456789012****:root"
        ]
      }
    }
  ],
  "Version": "1"
}

Sesi peran

Ketika suatu principal mengasumsikan peran, sesi peran dimulai. Kredensial sementara yang dikeluarkan oleh STS dikaitkan dengan sesi ini. Setiap tindakan yang dilakukan menggunakan kredensial tersebut dikaitkan dengan sesi peran tersebut.

Sesi peran memiliki:

  1. Nama sesi (RoleSessionName): Identifikasi yang diberikan pengguna untuk sesi tersebut. Nama ini muncul dalam log ActionTrail sehingga Anda dapat melacak tindakan ke pengguna atau aplikasi yang mengasumsikan peran tersebut.

  2. Durasi sesi: Siklus hidup tetap; kredensial kedaluwarsa saat sesi berakhir.

Catatan

Anda dapat meneruskan kebijakan sesi inline saat mengasumsikan peran. Izin efektif dari sesi peran merupakan irisan antara kebijakan akses peran dan kebijakan sesi. Hal ini memungkinkan Anda untuk mempersempit cakupan izin peran secara dinamis untuk sesi tertentu. Untuk informasi selengkapnya, lihat parameter Policy dalam referensi API AssumeRole.

Rantai peran

Rantai peran terjadi ketika Anda menggunakan satu peran untuk mengasumsikan peran kedua. Misalnya, pengguna RAM mengasumsikan Peran A, lalu menggunakan token STS dari Peran A untuk mengasumsikan Peran B. Peran-peran tersebut dapat berada dalam akun yang sama atau berbeda.

Rantai peran umum digunakan dalam lingkungan multi-akun yang kompleks. Misalnya, developer melakukan federasi ke akun pusat "jump" (mengasumsikan Peran A), lalu dari situ mengasumsikan peran dengan hak istimewa lebih tinggi (Peran B) di akun produksi untuk menjalankan tugas tertentu.

Anda dapat merantai peran menggunakan Alibaba Cloud CLI, SDK, atau dengan beralih peran di Konsol. Untuk informasi selengkapnya, lihat Gunakan rantai peran.

Perbedaan antara peran RAM dan RAM user

Meskipun keduanya merupakan identitas RAM, peran dan pengguna memiliki tujuan yang berbeda. Tabel berikut menyoroti perbedaan utamanya.

Item perbandingan

RAM user

Peran RAM

Penggunaan

Mewakili orang atau aplikasi tertentu dan digunakan secara langsung

Mewakili seperangkat izin dan harus diasumsikan oleh principal

Kredensial

Memiliki kredensial jangka panjang (password dan/atau pasangan Kunci Akses)

Tidak memiliki kredensial jangka panjang. Kredensial sementara (token STS) dihasilkan saat peran diasumsikan

Masa berlaku kredensial

Jangka panjang (hingga diubah atau dihapus secara manual)

Sementara dan kedaluwarsa setelah durasi yang dapat dikonfigurasi

Kebijakan kepercayaan

Tidak ada

Memerlukan kebijakan kepercayaan untuk menentukan siapa yang dapat mengasumsikan peran

Untuk batasan terkait peran RAM, lihat Batasan.

Kasus penggunaan

  • Pemberian hak istimewa sementara yang ditingkatkan

    Seorang developer bekerja sehari-hari dengan pengguna RAM yang memiliki izin terbatas. Ketika perlu menjalankan operasi sensitif, seperti memodifikasi database produksi, mereka dapat mengasumsikan peran yang memberikan izin administratif yang diperlukan untuk tugas tersebut. Setelah tugas selesai, mereka berhenti menggunakan peran tersebut, dan hak istimewa mereka kembali ke set terbatas semula. Pendekatan ini mengikuti prinsip hak istimewa minimal.

    Untuk informasi selengkapnya, lihat Metode untuk mengasumsikan peran RAM.

  • Delegasi akses antar-akun

    Sebuah organisasi memiliki akun Alibaba Cloud terpisah untuk pengembangan (Akun A) dan produksi (Akun B). Untuk memungkinkan pipeline CI/CD yang berjalan di Akun A men-deploy aplikasi ke ECS di Akun B, Anda dapat:

    1. Membuat peran di Akun B yang mempercayai Akun A.

    2. Memberikan izin kepada service role CI/CD di Akun A untuk mengasumsikan peran tersebut di Akun B.

    3. Pipeline CI/CD mengasumsikan peran di Akun B untuk memperoleh kredensial guna men-deploy aplikasi.

    Untuk informasi selengkapnya, lihat Akses resource cross-account.

  • Pemberian akses ke layanan Alibaba Cloud

    Aplikasi yang berjalan pada instans ECS perlu membaca objek dari bucket OSS. Alih-alih menyematkan pasangan Kunci Akses (AccessKey pair) dalam aplikasi, Anda membuat service role untuk ECS yang memiliki izin baca ke bucket tersebut. Lalu, Anda melampirkan peran ini ke instans ECS. Aplikasi tersebut kemudian dapat menggunakan kredensial sementara yang disediakan secara otomatis untuk mengakses OSS secara aman.

    Untuk informasi selengkapnya, lihat Instance RAM roles.

  • Pemberian akses bagi pengguna federasi

    Perusahaan Anda menggunakan IdP eksternal (seperti Microsoft Entra ID atau Okta). Untuk memungkinkan karyawan mengakses Konsol Alibaba Cloud, Anda dapat mengonfigurasi federasi identitas menggunakan SAML 2.0 atau OIDC dan membuat peran RAM yang mempercayai IdP tersebut. Saat pengguna login, IdP mengotentikasi mereka dan mereka mengasumsikan peran tersebut untuk mengakses Alibaba Cloud. Pendekatan ini memungkinkan Anda mengelola pengguna secara terpusat di IdP tanpa harus membuat pengguna RAM individual di Alibaba Cloud.

    Untuk informasi selengkapnya, lihat Ikhtisar SSO berbasis peran menggunakan SAML dan Ikhtisar SSO berbasis peran menggunakan OIDC.

Referensi