English version
IAM is the starting point for AWS security. Before thinking about EC2, S3, VPC, or databases, you need to know who can sign in, who can call APIs, and what each identity is allowed to do.
The Velog note starts from a useful beginner distinction: the AWS account root user is not the same thing as an IAM user.
Root user
When an AWS account is created, it starts with one root user. AWS describes this identity as having complete access to all AWS services and resources in the account.
That power is why the root user should not be used for everyday work. Use it only for tasks that specifically require root credentials. For normal administration, create administrative identities through IAM Identity Center or IAM and use least privilege.
Practical root-user habits:
- Turn on multi-factor authentication.
- Do not create root access keys unless there is a rare, specific need.
- Do not use the root user for daily console work.
- Store root account recovery information carefully.
IAM users and permissions
An IAM user is an identity inside an AWS account. A newly created IAM user has no permissions until permissions are attached directly or through a group or role-based design.
Permissions decide what the identity can do. For example, one identity might read S3 objects, another might manage EC2 instances, and another might only view billing data.
The important lesson is least privilege. Give an identity only the permissions needed for the task. Avoid broad administrator permissions unless the role truly requires them.
Access keys
Access keys are credentials used for programmatic access to AWS APIs. They usually consist of an access key ID and a secret access key.
The old note says the secret access key must be backed up. The safer modern wording is more precise: the secret access key is shown only at creation time, so if it is lost, create or rotate to a new key. Do not store it casually in notes, screenshots, source code, or chat logs.
Operational rules:
- Prefer IAM roles or temporary credentials where possible.
- Rotate long-lived access keys.
- Never commit access keys to Git.
- Disable or delete unused keys.
- Use CloudTrail and IAM Access Analyzer to monitor access patterns.
AWS Inspector, CloudTrail, Config, and Organizations
The note also mentions several security and governance services.
Amazon Inspector helps find software vulnerabilities and unintended network exposure in supported workloads such as EC2 instances, container images, and Lambda functions.
AWS CloudTrail records API activity. When something changes in AWS, CloudTrail is often where you check who called which API and when.
AWS Config records resource configuration history and evaluates resources against rules. It is useful when you want to know how a resource changed over time or whether it violates a policy.
AWS Organizations helps manage multiple AWS accounts centrally. It is commonly used for account structure, consolidated billing, and service control policies.
EC2 key pairs
An EC2 key pair is different from IAM access keys.
A key pair is used to prove identity when connecting to an EC2 instance. AWS stores the public key on the instance side, and the user stores the private key. Losing the private key can make instance access difficult unless another access path is configured.
Korean notes
AWS 보안을 처음 볼 때 IAM부터 정리하는 게 좋다. EC2, S3, VPC를 만들기 전에 누가 로그인할 수 있고, 누가 API를 호출할 수 있고, 어떤 권한을 갖는지부터 정해야 한다.
Velog 원본 노트의 핵심은 root user와 IAM user를 구분하는 것이다.
Root user
AWS account를 만들면 처음 생기는 identity가 root user다. AWS 공식 문서 기준으로 root user는 계정 안의 모든 AWS service와 resource에 완전한 접근 권한을 가진다.
그래서 root user는 일상적인 작업에 쓰면 안 된다. Root credential이 꼭 필요한 작업에만 사용하고, 평소 운영은 IAM Identity Center나 IAM을 통해 만든 identity로 처리하는 것이 안전하다.
Root user 운영 습관은 다음과 같다.
- MFA를 켠다.
- root access key는 특별한 이유가 없으면 만들지 않는다.
- daily console 작업에 root user를 쓰지 않는다.
- 계정 복구 정보는 안전하게 관리한다.
IAM user와 permission
IAM user는 AWS account 안에 만드는 identity다. 새 IAM user는 처음에는 권한이 없다. Permission을 직접 주거나 group, role 기반 구조로 연결해야 AWS resource를 사용할 수 있다.
여기서 중요한 원칙은 least privilege다. 어떤 identity든 필요한 작업을 수행할 수 있는 최소 권한만 주는 것이 기본이다.
예를 들어 S3 read만 필요한 사용자에게 EC2 관리 권한까지 줄 필요는 없다. Billing만 보는 사용자와 production resource를 수정하는 사용자는 권한 범위가 달라야 한다.
Access key
Access key는 AWS API를 programmatic하게 호출할 때 쓰는 credential이다. 보통 access key ID와 secret access key로 구성된다.
원본 노트에는 secret access key를 백업해야 한다고 되어 있었는데, 현대적인 표현으로는 조금 더 조심해야 한다. Secret access key는 생성 시점에만 볼 수 있으므로 잃어버리면 새 key를 만들거나 rotate해야 한다. 하지만 이 값을 일반 노트, screenshot, Git, chat log에 저장하면 안 된다.
운영 규칙은 다음과 같다.
- 가능하면 IAM role이나 temporary credential을 쓴다.
- long-lived access key는 rotate한다.
- Git에 credential을 commit하지 않는다.
- 쓰지 않는 key는 disable 또는 delete한다.
- CloudTrail과 IAM Access Analyzer로 접근 패턴을 점검한다.
Inspector, CloudTrail, Config, Organizations
Amazon Inspector는 지원되는 workload의 취약점과 의도치 않은 network exposure를 찾는 데 쓰인다. EC2 instance, container image, Lambda function 같은 대상이 포함될 수 있다.
AWS CloudTrail은 API activity를 기록한다. AWS에서 무언가 변경되었을 때 누가 어떤 API를 언제 호출했는지 추적할 때 중요하다.
AWS Config는 resource configuration history를 기록하고 rule에 맞는지 평가한다. Resource가 언제 어떻게 바뀌었는지, policy를 위반하는지 확인할 때 유용하다.
AWS Organizations는 여러 AWS account를 중앙에서 관리하는 서비스다. Account 구조, consolidated billing, service control policy 같은 작업에 사용된다.
EC2 key pair
EC2 key pair는 IAM access key와 다르다.
Key pair는 EC2 instance에 접속할 때 identity를 증명하는 데 쓰인다. Public key는 instance 쪽에 저장되고, private key는 사용자가 보관한다. Private key를 잃어버리면 다른 접근 경로가 없는 경우 instance 접속이 어려워질 수 있다.
Summary
IAM의 핵심은 identity와 permission을 분리해서 보는 것이다. Root user는 강력하지만 일상 작업용이 아니고, IAM user/access key는 최소 권한과 rotation이 중요하다. CloudTrail, Config, Inspector, Organizations는 운영 단계에서 계정과 resource를 추적하고 보호하는 도구다.