Security is paramount in the cloud. Controlling security in AWS starts with AWS IAM (Identity and Access Management). AWS IAM is the central security service that controls who can access your AWS resources and what actions they can perform.
AWS IAM is often referred to as the “glue” that connects AWS services. By default, one service cannot communicate with another without explicit AWS IAM permissions. This article covers the core components of AWS IAM and the virtual firewalls that protect your network.
AWS IAM Principals: Users, Groups, and Roles
An IAM “principal” is an entity that can make requests. This includes users, groups, and roles.
- Root User: This is the account owner, created using the original email and password. The Root User has full, unrestricted access. It is a critical security best practice using the root user only for initial setup.
- IAM Users: These are individual accounts created for employees, developers, and administrators. IAM users should always be granted permissions based on the Principle of Least Privilege. This means they receive only the minimum access needed to perform their job.
- IAM Groups: Groups are collections of users. Attaching a policy to a group means all users in that group automatically inherit those permissions. This simplifies management for large teams.
- IAM Roles: Roles grant temporary permissions to AWS services or users. They are crucial for service-to-service interaction. For example, an EC2 instance can “assume” a role (via an Instance Profile) to gain temporary access to an S3 bucket. This eliminates the need to hardcode sensitive credentials.
AWS IAM Authentication
- Multi-Factor Authentication (MFA): MFA is a vital security feature that adds an extra layer of security. It requires a second verification factor, usually a one-time password (OTP) code from a mobile app. Even if a password is stolen, the account remains secure without the MFA code.
AWS IAM Policies (JSON)
Permission in AWS IAM are defined in policies, which are written in JSON format. A policy contains statements that define three key elements:
- Effect: Specifies whether the policy will Allow or Deny an action.
- Action: The API operation to be performed (e.g., s3:ListBuckets, ec2:RunInstances).
- Resource: The resource the action applies to, identified by its Amazon Resource Name (ARN).
Policy Evaluation Logic When a user attempts an action, AWS IAM evaluates all applicable policies. The rules are simple:
- Explicit Deny Always Wins: If any policy explicitly denies an action, the user cannot perform it, even if another policy explicitly allows it. Deny always takes priority.
- Explicit Allow: Permission is granted only if there is an explicit Allow statement.
- Implicit Deny: Any action not explicitly allowed is automatically (implicitly) denied.
Virtual Firewalls: Security Groups and NACLs
The AWS IAM service works alongside two types of virtual firewalls to control traffic flow.
- Security Groups (SG) A Security Group acts as a virtual firewall for your EC2 instances. It controls traffic at the instance level.
- Stateful: Security Groups are stateful. This means if you allow an inbound request (e.g., on port 80), the corresponding outbound response is automatically allowed without needing a separate outbound rule.
- Rules: SGs only contain “allow” rules. They cannot explicitly deny traffic.
- Default: By default, a new security group allows all outbound traffic but denies all inbound traffic.
- Network Access Control Lists (NACLs) are an optional security layer that acts as a firewall for controlling traffic in and out of one or more subnets.
- Stateless: NACLs are stateless. If you allow inbound traffic, you must also create an explicit outbound rule to allow the response traffic to return.
- Rules: NACLs can contain both “allow” and explicit deny rules. This is powerful for blacklisting specific IP addresses.
- Rule Evaluation: NACL rules evaluated in number order, starting with the lowest. The first rule that matches a packet is applied.
Conclusion: A Layered Approach to Security
You now hold the keys to cloud security, You’ve learned that security is a layered defense, starting with AWS IAM to control who (Users, Groups, Roles) can do what (Policies).
From there, you learned to apply virtual firewalls: stateful Security Groups at the instance level and optional, stateless NACLs at the subnet level.
With a secure network and protected instances, your final challenge is scale. How do you handle a sudden traffic spike or a server failure? In the next article, we’ll explore how to make your application truly elastic and highly available using Load Balancers, AWS Autoscaling, and DNS.
Pingback: How to Scale: AWS Autoscaling, Load Balancing, and DNS Part - 8 - AZ Innovate Hub