Cloud Security & IAM

Cloud Security & IAM: Users, Roles, Policies, Security Groups, and Key Management

📅 Published: Feb 2026
⏱️ Estimated Reading Time: 18 minutes
🏷️ Tags: Cloud Security, IAM, Security Groups, Key Management, Access Control, AWS, Azure, GCP

Introduction: Security is Shared Responsibility

When you move to the cloud, security does not become someone else's problem. Cloud providers secure the infrastructure—the data centers, hardware, and foundational services. You are responsible for everything you put in the cloud: your data, your applications, your access controls, and your configurations.

This shared responsibility model means you must understand how to secure your cloud environment. The tools for cloud security fall into three categories:

Identity and Access Management (IAM) — Who can do what
Network Security — What traffic is allowed where
Data Protection — How data is encrypted and protected

This guide covers the foundational security services you need to protect your cloud infrastructure.

Identity and Access Management (IAM)

What is IAM?

Identity and Access Management (IAM) is the service that controls who is authenticated (signed in) and authorized (has permissions) to use cloud resources. It is the foundation of cloud security.

Think of IAM as the security system for your cloud account. It decides:

Who can enter (authentication)
What they can do once inside (authorization)
Where they can go (resource access)

IAM Across Providers

Provider	Service Name	Key Concepts
AWS	IAM	Users, Groups, Roles, Policies
Azure	Azure Active Directory	Users, Groups, Service Principals, Roles
Google Cloud	Cloud IAM	Principals, Roles, Policies

While the terminology differs, the core concepts are consistent across providers.

Users: Individual People

A user represents a person or application that needs access to your cloud resources. Each user has a unique identity with its own credentials.

When to create a user:

A developer needs access to the cloud console
An application needs API access to your resources
A service needs to authenticate to another service

Best practices for users:

Create individual users for each person—never share accounts
Use strong passwords and enforce regular rotation
Require multi-factor authentication (MFA) for all human users
Disable or delete users when they leave the organization

Groups: Organizing Users

A group is a collection of users. Instead of attaching permissions to each user individually, you attach permissions to groups, then add users to groups.

Common group structures:

Admins — Full access to all resources
Developers — Ability to create and modify application resources
Operators — Ability to deploy and monitor applications
Auditors — Read-only access to all resources
Viewers — Read-only access to specific resources

Why groups matter:

Simplify permission management
Ensure consistent access across users
Make onboarding and offboarding easier
Provide clear separation of duties

Roles: Assuming Permissions

A role is a set of permissions that can be assumed by users, applications, or services. Unlike users, roles do not have permanent credentials. Instead, they are assumed temporarily.

Think of roles as hats. You put on the appropriate hat for the task you need to perform. When you are done, you take the hat off.

Common role use cases:

Cross-account access — A user in one account needs to access resources in another account
Service-to-service access — An EC2 instance needs permission to read from S3
Temporary elevated access — A developer needs temporary admin permissions
Federated access — Employees access cloud resources using their corporate credentials

Policies: Defining Permissions

A policy is a document that defines what actions are allowed or denied on which resources. Policies are written in JSON format.

Policy Structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-bucket"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

Policy Components:

Component	Purpose	Example
Effect	Allow or deny	"Allow"
Action	What operations	"s3:GetObject"
Resource	Which resources	"arn:aws:s3:::my-bucket/*"
Condition	When the policy applies	"IP address must be within corporate range"

Types of Policies

Managed Policies
Pre-built policies created and maintained by the cloud provider. Examples:

AdministratorAccess
ReadOnlyAccess
AmazonS3FullAccess

Customer Managed Policies
Policies you create and manage yourself. These give you fine-grained control over permissions.

Inline Policies
Policies embedded directly on a user, group, or role. Use sparingly—managed policies are easier to maintain.

The Principle of Least Privilege

The most important concept in IAM is least privilege: grant only the permissions required to perform a task, and nothing more.

How to apply least privilege:

Start with minimum permissions. Begin with read-only access. Add permissions as needed.
Use groups, not individual permissions. Grant permissions at the group level.
Use conditions to restrict access. Limit by IP address, time of day, or MFA status.
Audit regularly. Review permissions quarterly. Remove unused permissions.
Use temporary credentials. Prefer roles over long-term access keys.

Security Groups: Instance-Level Firewalls

What Are Security Groups?

Security groups act as virtual firewalls for your compute resources. They control inbound and outbound traffic at the instance level.

Think of security groups as the security guards at the entrance to each building. They check every person entering and leaving against a list of rules.

Security Group Characteristics

Stateful
If you allow inbound traffic, the outbound response is automatically allowed. You do not need to specify return rules.

Allow Only
Security groups only have allow rules. You cannot explicitly deny traffic. To block traffic, you simply do not allow it.

Attached to Resources
Security groups are attached to resources like EC2 instances, RDS databases, and load balancers. A resource can have multiple security groups.

Common Security Group Configurations

Web Server Security Group

Direction	Protocol	Port	Source	Purpose
Inbound	TCP	80	0.0.0.0/0	HTTP from anywhere
Inbound	TCP	443	0.0.0.0/0	HTTPS from anywhere
Inbound	TCP	22	corporate IP	SSH from office
Outbound	All	All	0.0.0.0/0	All outbound traffic

Database Security Group

Direction	Protocol	Port	Source	Purpose
Inbound	TCP	3306	web-sg	MySQL from web servers
Inbound	TCP	22	bastion-sg	SSH from bastion host
Outbound	All	All	0.0.0.0/0	All outbound traffic

Bastion Host Security Group

Direction	Protocol	Port	Source	Purpose
Inbound	TCP	22	corporate IP	SSH from office
Outbound	All	All	0.0.0.0/0	All outbound traffic

Security Group Best Practices

Create separate security groups for each tier. Web servers, application servers, and databases should have different security groups.

Use security group references, not IP addresses. Instead of allowing traffic from 10.0.1.0/24, allow from "web-sg". This is more maintainable.

Start with deny all. Only add rules for required traffic.

Restrict administrative access. Limit SSH and RDP access to specific IP addresses. Use bastion hosts when needed.

Remove unused security groups. Regularly audit and delete security groups that are not attached to any resource.

Network ACLs: Subnet-Level Firewalls

What Are Network ACLs?

Network Access Control Lists (NACLs) act as firewalls at the subnet level. They control traffic entering and leaving entire subnets.

Think of NACLs as security checkpoints at the entrance to a neighborhood. They control all traffic entering or leaving that area.

NACL Characteristics

Stateless
You must specify both inbound and outbound rules. Return traffic is not automatically allowed.

Allow and Deny
NACLs can both allow and deny traffic. Deny rules take precedence.

Applied to Subnets
NACLs are attached to subnets, not individual resources. All resources in the subnet are affected.

Rule Evaluation
Rules are evaluated in numerical order. The first matching rule is applied.

NACL vs Security Group

Feature	Security Group	NACL
Scope	Instance	Subnet
State	Stateful	Stateless
Rules	Allow only	Allow and deny
Evaluation	All rules	Rule number order
Use Case	Instance-level firewall	Subnet-level defense

Use security groups for most access control. Use NACLs for defense in depth and to block specific traffic patterns.

Key Management: Protecting Your Data

Why Key Management Matters

All cloud storage is encrypted by default, but who holds the keys matters. If you use default encryption, the cloud provider manages the keys. If you want control over your encryption keys, you use a key management service.

Key Management Services (KMS) let you create, manage, and control encryption keys used to protect your data.

KMS Across Providers

Provider	Service Name	Features
AWS	Key Management Service (KMS)	Customer-managed keys, automatic rotation
Azure	Key Vault	Keys, secrets, certificates
Google Cloud	Cloud KMS	Hardware security module integration

Types of Keys

Customer-Managed Keys (CMK)
You create and manage the keys. You control rotation, access, and deletion. You are responsible for key security.

AWS-Managed Keys
AWS creates and manages the keys on your behalf. Rotation is automatic. You cannot control the key material.

Cloud Provider-Managed Keys
The cloud provider manages keys for specific services. These are used when you do not specify a customer-managed key.

Key Management Best Practices

Enable automatic key rotation. Rotating keys regularly limits the impact of a compromised key.

Use separate keys for different applications. If one key is compromised, only that application is affected.

Restrict key usage. Limit which services can use each key. A key for S3 should not be used by RDS.

Audit key usage. Enable logging to track when keys are used and by whom.

Plan for disaster recovery. Ensure keys are replicated across regions or have backup copies.

Security Monitoring

CloudTrail (AWS) / Activity Logs (Azure) / Audit Logs (GCP)

These services record all API activity in your cloud account. Every action—creating a resource, modifying a security group, deleting a bucket—is logged.

What to monitor:

Failed login attempts
Changes to IAM policies
Creation or deletion of security groups
Changes to encryption keys
Unusual API calls from unfamiliar IP addresses

How to monitor:

Send logs to a centralized logging system
Set up alerts for suspicious activity
Review logs weekly for anomalies

Security Services Across Providers

Service	AWS	Azure	Google Cloud
Configuration Compliance	AWS Config	Azure Policy	Security Command Center
Threat Detection	GuardDuty	Security Center	Security Command Center
Vulnerability Scanning	Inspector	Security Center	Container Analysis
Web Application Firewall	WAF	WAF	Cloud Armor

Real-World Security Scenarios

Scenario 1: Developer Access

A development team needs access to create and manage resources in a development environment.

IAM Configuration:

Create group called "Developers"
Attach policy allowing full access to development resources
Attach policy allowing read-only access to production resources
Add developers to the group
Require MFA for all developer accounts

Result: Developers can work freely in development. They can see but not change production.

Scenario 2: Production Database Security

A production database should be accessible only from application servers in the same VPC.

Security Group Configuration:

Create security group "database-sg"
Inbound rule: allow port 3306 from "application-sg"
No inbound rules from anywhere else
Outbound: allow all
Attach to database instances

Result: Only application servers can connect to the database. The database is not accessible from the internet.

Scenario 3: Encrypted S3 Bucket

An S3 bucket must be encrypted with a customer-managed key that rotates automatically.

Key Management Configuration:

Create customer-managed key in KMS
Enable automatic rotation (every year)
Restrict key usage to S3 only
Configure bucket to use the key for default encryption

Result: All objects in the bucket are encrypted with a key the organization controls. The key rotates automatically.

Scenario 4: Cross-Account Access

A central security team needs read-only access to all accounts in the organization.

IAM Configuration:

In each account, create a role called "SecurityAuditRole"
Attach read-only policies (ReadOnlyAccess, SecurityAudit)
Allow the central security account to assume this role
Security team assumes the role when needed

Result: Security team can view resources in any account but cannot make changes.

Security Best Practices Checklist

Identity and Access Management

Multi-factor authentication enabled for all human users
No root account access keys (delete them after setup)
Users organized into groups, not individual permissions
Policies grant least privilege (no wildcard actions without reason)
Regular review of IAM permissions (quarterly)
Inactive users and roles removed
Temporary credentials used for applications and services

Network Security

Security groups restrict access to required ports only
SSH/RDP access limited to specific IP addresses
Database security groups allow access only from application tiers
NACLs provide defense in depth for critical subnets
VPC flow logs enabled for security monitoring
No open access to administrative ports (22, 3389)

Key Management

Customer-managed keys used for sensitive data
Automatic key rotation enabled
Key usage restricted to specific services
Key access logs enabled
Keys replicated for disaster recovery

Monitoring

API activity logging enabled
Alerts configured for suspicious activity
Security findings reviewed regularly
Compliance scanning enabled for resources

Summary

Security Layer	Purpose	Key Tools
Identity	Who can access	Users, Groups, MFA
Authorization	What they can do	Policies, Roles
Network	What traffic is allowed	Security Groups, NACLs
Data	How data is protected	KMS, Encryption
Monitoring	What is happening	CloudTrail, Security Hub

Security in the cloud is not a one-time configuration. It is an ongoing practice of applying least privilege, monitoring for threats, and continuously improving your defenses.

Practice Questions

A developer needs access to create EC2 instances but should not be able to delete S3 buckets. How do you configure this?
A web server needs to be accessible from the internet on port 443. A database server should only be accessible from the web server. How do you configure security groups?
Your organization requires that all S3 buckets be encrypted with customer-managed keys that rotate annually. How do you implement this?
A security auditor needs read-only access to all resources in your AWS account. How do you grant this access?
You discover that an IAM user has been using an access key for three years. What security best practice has been violated?

Learn More

Practice cloud security with hands-on exercises in our interactive labs:
https://devops.trainwithsky.com/

SKY Tech – Explore Technology!