Use RAM to migrate businesses to the cloud

Case Study

For example, suppose you are the owner of Company X.  You have registered a cloud account (company-x@aliyun.com) for your Company X, and have purchased basic infrastructure services of ECS, RDS, and  OSS. Since your company migrated its services to the cloud, business has been rapidly developing, your team expanding, and cloud resource requirements growing. All operation and management actions on resources use one shared account, which highlights the issue of system vulnerability and the importance of security. 

Suppose Company X’s organization structure is as shown in the following chart. There are three departments in total: Human Resources (HR), Research & Development (R&D), and Operation & Maintenance (O&M) Departments. The HR Department is in charge of only human resources, the R&D Department is solely responsible for resource usage, and the O&M Department is authorized to manage resources (such as starting or stopping virtual machines). 

Implementation procedure

Let’s take a look at how we use RAM to achieve security management of resource access step by step. 

Step 1: Enable Multi-Factor Authentication (MFA) for your primary account

Given the fact that you may have shared your primary account with others,  the primary account is highly vulnerable to password leaks. We strongly recommend you enable MFA (Multi-Factor Authentication)  for your primary account. 

Alibaba Cloud accounts support standard virtual MFA. It is an easy-to-use application that can be installed on mobile devices (for example, smart phones and smart watches).  After virtual MFA is enabled in the Account Center,  when you log on to Alibaba Cloud platforms, the system not only verifies your user name and password (the first security factor), but also requires you to provide the dynamic security code (the second security  factor) generated by the virtual MFA application.  These factors work together to enhance security protection for your account.

Step 2: Create user accounts and group them

Based on the preceding organization chart, you can create different user accounts for employees A, B, C, D, and E, and then create a user account for the application “app”.  Then, you can create three user groups to match the HR, R&D, and O&M Departments, respectively, and add these users to appropriate groups (note that User D belongs to both the R&D and O&M Departments). 

Furthermore, you must Create a RAM user based on different user needs.

• The application “app” is only allowed to visit cloud resources through the OpenAPI, so you only need to create an AccessKey for it.
• If an employee only requires operating on cloud resources through the console, you only need to set a logon password for the employee. 

Another consideration is that maintenance operations are typically quite sensitive. You may be concerned about the significant risks of maintenance personnel account passwords being leaked. To address this issue, you can set enforced MFA at logon of these accounts and have two different persons assigned to maintain the account passwords and MFA devices. In this way, some operations can only be fulfilled in the presence of both persons.

Step 3: Assign minimum permissions for various user groups

RAM provides multiple system authorization policy templates for you to choose from. For example, you can authorize the O&M group the full permission for ECS and RDS, authorize the R&D group the read-only permission for ECS and RDS and the full permission for OSS, and authorize the HR group the administration permission for RAM users. 

If you feel that the granularity of the default RAM system authorization policy templates for resource management is not specific enough, you can customize authorization policy templates in the RAM. Custom authorization policies support fine-tuned access management, such as using a specific API operation name and resource instance name. They also support expressions with multiple constraints for flexible management of resource operation approaches, such as limiting the source IP addresses of operation initiators. Custom authorization policies can meet your diversified and rigorous requirements on resource management to achieve minimum authorization. This will only authorize the minimal permission required. 

Take conditional authorization, for example. If you are concerned that the leak of a R&D personnel AccessKey may compromise the company’s OSS data, you can impose constraints on data access in the OSS. This can be accomplished using the authorization policies for the R&D group, such as requiring OSS operations to be conducted only at company site (using the acs:SourceIP conditional expression) during working hours (using theacs:CurrentTime conditional expression).

Step 4: Employee job transfer, onboarding, and resignation

When an employee transfers to another post, you can transfer the account of the employee to the destination group.  For a new employee, you can create a new user account for the new employee, set the logon password or AccessKey, and then add the account to the appropriate user group Attach policies to a RAM user. . If an employee quits, you can delete the user account in the RAM console, and the RAM automatically removes all access permissions for the user account. 

Step 5: Use STS to authorize a temporary user

Sometimes you may also have users (people or applications) who require ad-hoc access to your cloud resources. We term them as “temporary users”. In this scenario, you can use the Security Token  Service (STS), an extended authorization service of RAM, to issue access tokens to these users.  The permission and automatic expiration time of the tokens can be defined as required when you issue these tokens.

A benefit of using STS access tokens for temporary user authorization is for better management of user authorization. You do not need to create an RAM user account and  password for the temporary user. The RAM user password always remains valid, but temporary users do not need to access resources for the long term. 

In addition, you can also authorize an RAM user to issue access tokens, using STS to further delegate authority to RAM users.

Step 6: Let the primary account “take a good rest”

Once your employees and application systems start to use RAM user accounts,  you do not need to use the primary account for routine work anymore. We suggest that you do not create an AccessKey for your primary account to reduce the risk of leakage.

We also recommend you store your primary account password and MFA devices in the company’s safe to let them “take a good rest”.