Securing Your Cloud Environment: Identity and Access Management on Alibaba Cloud

The article introduces secure-by-default practices on Alibaba Cloud, covering RAM, network security, encryption, and secrets management to prevent breaches.

Note: In all previous blogs, we've been building without mentioning one critical thing: security. A scalable system that's compromised is worse than useless—it's dangerous. This blog is about making your infrastructure secure by default.

Introduction

Security in the cloud isn't an afterthought; it's architecture.

I learned this the hard way. A few years ago, I helped a startup migrate to cloud without properly securing their infrastructure. The mistakes were subtle:

● Database accessible from anywhere

● SSH keys stored in Git

● IAM permissions set to "admin for everyone"

● No encryption on data at rest

A week later, they got hacked. The attacker didn't use sophisticated zero-days or social engineering. They simply:

Found exposed database credentials
Scanned the database
Downloaded customer data
Sold it online

This wasn't a failure of Alibaba Cloud; it was a failure of security thinking. The good news? It's completely preventable, and the patterns are straightforward.

Part 1: The Cloud Security Model

Shared Responsibility Model

Here's what Alibaba Cloud is responsible for, and what you are:

Component	Alibaba Cloud Responsibility	Your Responsibility
Infrastructure Security	Physical servers, data center security, hypervisor	✓
Network Infrastructure	VPCs, load balancers, routers	✓
Service Security	RDS engine security patches	✓
Identity & Access	IAM system	✓ Configure correctly
Application Security		✓✓✓ (Your code)
Data Encryption	Providing the tools	✓ Implementing it
Network Configuration		✓ Security groups, NACLs
Credential Management		✓✓✓ (Critical!)

Bottom line: Alibaba Cloud provides the locks; you have to use them correctly.

Part 2: Identity and Access Management (RAM)

RAM is how you control who can do what on your account. It's Alibaba Cloud's identity service.

Users vs. Roles

Root Account

● Has complete access to everything

● Like the master key to your entire cloud

● Never use for daily work

● Only use for account setup and recovery

RAM Users

● Individual identities (Developer A, Developer B)

● Have limited permissions assigned to them

● Use for daily work, automation, deployments

RAM Roles

● Groups of permissions without identity

● Assumed by users, services, or external entities

● Good for: "Web servers can read from S3" (give the role to all web servers)

The Principle of Least Privilege

What you might want to do:

Give Developer A "admin" to make life easy.

What you should do:

Give Developer A only permissions they need for their specific job:

Can read test databases ✓
Can't delete production databases ✗
Can't modify IAM settings ✗
Can deploy to test environment ✓
Can't deploy to production ✗

This seems tedious, but it's the single biggest difference between "secure" and "compromised."

Setting Up RAM Users

Step 1: Go to RAM in Alibaba Cloud Console

Navigate to: RAM & User Management → Users → Create User

Step 2: Create Users for Specific Roles

Instead of one "developer" user, create specific ones:

● terraform-deployer (CI/CD automation)

● logger-app (application that writes logs)

● database-backup (automated backup process)

● alice-dev (Alice for development work)

Step 3: Assign Minimal Permissions

For logger-app:

Permission: acs:logs:*:logs:PutLogEvents
Resources: arn:acs:logs:*:123456789:logstore/application-logs

This user can ONLY write logs to that specific log store. Nothing else.

For alice-dev:

Permission: acs:ecs:*:DescribeInstances
Permission: acs:ecs:*:ModifyInstanceAttribute
Permission: acs:ecs:*:RebootInstance
Resources: arn:acs:ecs:*:*:instance/dev-*

Alice can restart and modify dev instances, but not production instances, and certainly can't delete anything.

Access Keys

RAM users need credentials to programmatically access Alibaba Cloud. Two options:

Option 1: Access Key (for automation)

● Access Key ID (username)

● Access Key Secret (password)

● Used by applications, CI/CD pipelines

Option 2: Console Password (for humans)

● Username

● Password

● Used to log into the console

Security tips:

● Rotate access keys every 90 days

● Never store in code; use environment variables

● Never share between services

● Use one key per service

Example - correct way:

# .env (not in Git)
DB_ACCESS_KEY=AKIAU2XXXXXXXXXX
DB_ACCESS_SECRET=secret_value_here

# Application code
const client = new AlibabaCloud({
  accessKeyId: process.env.DB_ACCESS_KEY,
  accessKeySecret: process.env.DB_ACCESS_SECRET
});

Example - wrong way:

// DON'T DO THIS
const client = new AlibabaCloud({
  accessKeyId: "AKIAU2XXXXXXXXXX",
  accessKeySecret: "secret_value_here"
});
// Commit this to Git
// Attacker finds it
// Game over

Part 3: Network Security

Remember the networking blog? Now let's secure it.

Security Groups—The Firewall

Every ECS instance needs a security group. It's your firewall.

Example: Web Server Security Group

Inbound Rules:
├─ HTTP (80) from 0.0.0.0/0 ✓ (everyone can connect)
├─ HTTPS (443) from 0.0.0.0/0 ✓ (everyone can connect)
├─ SSH (22) from 10.0.0.0/8 ✓ (internal only)
└─ SSH (22) from 203.0.113.0/32 ✓ (your office IP)

Outbound Rules:
└─ All traffic to anywhere ✓ (server can reach anywhere)

Example: Database Server Security Group

Inbound Rules:
├─ MySQL (3306) from 10.0.1.0/24 ✓ (only from web tier)
└─ SSH (22) from 10.0.0.0/8 ✓ (only from internal)

Outbound Rules:
└─ All traffic to anywhere ✓ (not really needed but standard)

Notice: The database isn't accessible from the internet. Only internal servers can connect to it.

Private Subnets for Sensitive Resources

Pattern:

┌─────────────────────┐
│  Internet           │
└──────────┬──────────┘
           │
    ┌──────▼──────┐
    │ IGW (route) │
    └──────┬──────┘
           │
    ┌──────▼─────────────────┐
    │ Public Subnet           │
    │ ┌──────────────┐        │
    │ │ Web Server 1 │        │ Can reach internet
    │ │ Web Server 2 │        │ Can be reached from internet
    │ └──────────────┘        │
    └──────┬──────────────────┘
           │
    ┌──────▼─────────────────┐
    │ Private Subnet          │
    │ ┌──────────────┐        │
    │ │   Database   │        │ Cannot be reached from internet
    │ │ ┌──────────┐ │        │ Can reach internet via NAT
    │ └──────────────┘        │
    └─────────────────────────┘

The database is in a private subnet. Attackers can't reach it directly from the internet. Even if your web server is compromised, the attacker still needs to:

Know the database IP (internal only)
Have database credentials
Have database user permissions

This layering is called "defense in depth."

Part 4: Data Encryption

Encryption at Rest (Data stored on disk)

When you store sensitive data, encrypt it.

Example: RDS with Encryption

Setup:

Create RDS instance

Enable "Transparent Data Encryption (TDE)"

Alibaba Cloud manages encryption key in Key Management Service (KMS)

Database automatically encrypts all data before writing to disk

Result: Even if someone physically steals the hard drive, they can't read the data.

Example: OSS with Encryption

Setup:

Store sensitive files in OSS

Enable server-side encryption

Choose: KMS-managed key or Alibaba-managed key

All objects automatically encrypted

Encryption in Transit (Data moving over network)

Use HTTPS/TLS for all communication.

Web Server Configuration:

Generate SSL certificate (free from Let's Encrypt, or buy from Alibaba)

Configure load balancer to terminate SSL

Internal communication between LB and servers can be HTTP (trusted network)

All external communication is HTTPS

Result: User browsers connect via HTTPS. Data is encrypted over the internet. Eavesdropping doesn't work.

Key Management Service (KMS)

For encryption keys themselves, use KMS:

Setup:

Go to KMS console

Create a master key

KMS stores and manages the key

Applications request KMS to encrypt/decrypt data

Applications never see the raw key

This prevents:

● Keys from being leaked in code

● Keys from being accessible if application is compromised

● Accidental key sharing

Part 5: Secrets Management

The Problem

Many applications need secrets: database passwords, API keys, encryption keys.

Where do you store them?

Wrong places:

● ❌ Hard-coded in code (visible in Git history forever)

● ❌ Config file (might be deployed with code)

● ❌ Environment variable on one developer's laptop (not portable)

● ❌ Slack/email (searchable, forwarded, archived)

Right place:

● ✓ Secrets Management Service

Using Alibaba Cloud Secrets Manager

Setup:

Go to Secrets Manager

Create a secret: "prod/database/password"

Store: "MySecurePassword123"

Application retrieves at runtime

Application code:

const client = new AlibabaCloud({...});

// At startup
async function getDbPassword() {
  const secret = await client.getSecret({
    secretName: 'prod/database/password'
  });
  return secret.secretString;
}

const dbPassword = await getDbPassword();
const db = createConnection({
  host: 'db.internal',
  user: 'admin',
  password: dbPassword  // Retrieved securely
});

Advantages:

● Single source of truth for secrets

● Rotation: Update secret in one place, all applications use new version

● Audit: See who accessed which secrets and when

● No secrets in code, config, or environment

Part 6: Monitoring and Compliance

CloudTrail (Audit Logs)

CloudTrail records everything that happens in your account.

Who did what, when, and from where:
├─ 2024-01-15 10:32: User alice-dev modified security group
├─ 2024-01-15 10:35: Service terraform-deployer created 3 ECS instances
├─ 2024-01-15 11:00: User bob-admin created RAM user
└─ 2024-01-15 11:30: Unauthorized IP tried to assume role → FAILED

Setup:

Enable CloudTrail

Save logs to OSS

Set up alerts for suspicious activity

ActionTrail (Real-time Monitoring)

Get alerted when something suspicious happens.

Alert if:
├─ Anonymous user attempts created
├─ Security group modified
├─ Database accessed outside business hours
├─ Large data transfer from OSS
└─ Root account used for anything

Part 7: Security Checklist

Before going to production, verify:

Access Control

● Root account MFA enabled

● RAM users created with least privilege

● No root account used for daily work

● Access keys rotated every 90 days

● Old access keys deleted

Network Security

● Security groups configured restrictively

● Database in private subnet

● SSH only from trusted IPs

● No security group allows 0.0.0.0/0 except for HTTP/HTTPS

● VPC Flow Logs enabled for monitoring

Data Security

● Encryption at rest enabled for databases

● Encryption in transit (HTTPS) enforced

● Sensitive data in KMS

● Database backups encrypted

Secrets Management

● No secrets in code

● Secrets stored in Secrets Manager

● Application retrieves secrets at runtime

● Secrets rotated regularly

Monitoring & Compliance

● CloudTrail enabled

● CloudTrail logs stored in separate secure bucket

● Alerts configured for suspicious activity

● Regular security audits scheduled

● Compliance checklist reviewed (SOC2, GDPR, PCI-DSS if applicable)

Part 8: The Security Mindset

The most important thing isn't remembering every security control. It's internalizing a mindset:

Assume breach: "If this component is compromised, what can the attacker do?"
Defense in depth: Use multiple layers. Don't rely on a single control.
Least privilege: Every identity should have minimum permissions needed.
Encrypt everything: Data at rest and in transit.
Monitor everything: You can't protect what you can't see.
Automate compliance: Build security into infrastructure-as-code, not manual checklists.

Real-World Incident Response

What happens if something does go wrong?

Discovery:

CloudTrail alerts unusual activity
You investigate

Containment:

Disable compromised credentials
Isolate affected instances
Check other instances for breach signs

Eradication:

Update all secrets
Patch vulnerabilities
Rebuild affected instances from clean images

Recovery:

Monitor closely for re-attack
Restore services incrementally
Verify data integrity

Post-Incident:

Root cause analysis
Update security controls
Improve monitoring

Wrapping Up

You now understand:

✅ Shared responsibility model: Cloud provider secures infrastructure; you secure configuration

✅ Identity management: RAM users with least privilege

✅ Network security: Security groups, private subnets, defense in depth

✅ Data encryption: At rest and in transit

✅ Secrets management: Never hard-code secrets

✅ Monitoring: Audit logs and real-time alerts

✅ Security mindset: Assume breach, use defense in depth

Resources

● RAM User Guide

● Security Groups Documentation

● KMS Documentation

● Secrets Manager

● CloudTrail

● Security Best Practices

Your Turn: What's the most sensitive data in your application? How would you encrypt it and control access to it? Describe in the comments.

Next post: Automation and DevOps — Let's talk CI/CD pipelines and infrastructure as code.

Disclaimer: The views expressed herein are for reference only and don't necessarily represent the official views of Alibaba Cloud.