RAM is applicable to user account management and authorization in an enterprise, resource management and authorization between enterprises, and temporary authorization and management for apps running on untrusted UEs.
Account management and authorization in an enterprise
Assume that an enterprise A purchases several types of cloud resources (such as ECS instances, RDS instances, SLB instances, and OSS buckets), and its employees need to operate these resources (such as purchase, O&M, or online application). Different employees require different permissions because the employees have different responsibilities.
- For security and reliability, enterprise A does not want to disclose its account key to its employees. Enterprise A prefers to create different RAM user accounts for their employees.
- The employees can operate on resources only after they are authorized. All the fees incurred by the employees will not be charged independently but be paid by enterprise A.
- Enterprise A can revoke the permissions of a RAM user account or delete a user account at any time.
Resource management and authorization between enterprises
Assume that there are enterprises A and B and enterprise A has purchased many cloud resources (such as ECS instances, RDS instances, SLB instances, and OSS buckets) for its business requirements.
- Enterprise A wants to focus on its business systems, so it entrusts O&M, monitoring, and management for its cloud resources or grant permissions on its cloud resources to enterprise B.
- Enterprise B can assign O&M tasks to its employees. In this way, enterprise B can precisely control the employees' permissions on the cloud resources of enterprise A.
- If enterprises A and B terminate their O&M entrustment contract, enterprise A can revoke the permissions of enterprise B at any time.
Temporary authorization and management for apps running on untrusted UEs
Assume that an enterprise A has developed a mobile app and has purchased OSS for it. Then, the mobile app can upload data to and download data from the OSS.
- Enterprise A does not want the app to use the appServer to transmit data. Instead, enterprise A wants the app to directly upload data to and download data from the OSS.
- Because the mobile app runs on a UE and enterprise A cannot control the UE. For security reasons, enterprise A cannot save its key in the app.
- Enterprise A wants to minimize its security risks by, for example, giving the app an access token with the minimum permissions that the app needs to connect to the OSS and restricting the access duration to a specified period of time (for example, 30 minutes).