Use RAM to cloudify enterprise businesses

Case Study

For example, suppose you are the owner of Company X. You have registered an 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 figure. 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 account

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

Accounts support standard virtual MFA (VMFA). It is an easy-to-use application that can be installed on mobile devices (for example, smart phones and smart watches). After VMFA is enabled in the Account Center, when you log on to the Alibaba Cloud console, 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 VMFA 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 figure, 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 RAM users based on different user needs.

• The application "app" is only allowed to visit cloud resources through the open APIs, so you only need to create an AK 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 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 policy templates for resource management is not specific enough, you can customize policy templates in the RAM. Custom policies support fine-grained 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 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 AK may compromise the company's OSS data, you can impose constraints on data access in the OSS. This can be accomplished using the 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: Properly handle user accounts after 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, set the logon password or AK, and then add the account to the appropriate user group and authorize the account. If an employee quits, you can delete the user account in the RAM console, and the RAM automatically removes all access permissions of 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.

Additionally, you can also authorize a RAM user to issue access tokens, using STS to further delegate authority to RAM users.

Step 6: Let your account “take a good rest”

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

We also recommend that you store your account password and MFA devices in the company's safe to let them "take a good rest".