2일차에는 VPC Networking을 공부하면서 Route Table, Internet Gateway, NAT Gateway의 역할과 Security Group, NACL의 차이를 정리했다.
네트워크를 통해 트래픽이 어디로 이동하는지 이해하는 과정이었다.
그런데 네트워크 연결이 정상이라고 해서 모든 작업을 수행할 수 있는 것은 아니다.
서버가 S3에 접근할 수 있는 네트워크 환경을 갖추고 있더라도, 해당 작업을 수행할 권한이 없다면 파일을 읽을 수 없다.
반대로 권한이 있다고 하더라도 네트워크 경로나 서비스 설정에 문제가 있으면 통신이 실패할 수 있다.
결국 AWS에서 서비스를 정상적으로 운영하려면 네트워크뿐 아니라 접근 권한도 함께 이해해야 한다.
그래서 3일차에는 AWS의 권한 관리 서비스인 IAM을 공부하기로 했다.
오늘 살펴본 핵심 개념은 다음과 같다.
- IAM User, Group, Role
- IAM Policy와 권한 관리
- EC2 IAM Role과 임시 자격 증명
- IAM Policy와 S3 Bucket Policy의 차이
- 최소 권한 원칙
- KMS와 Secrets Manager의 기본 역할
기존에 온프레미스에서 계정과 보안 정책을 관리했던 경험을 AWS에 연결해 보면서 하나씩 정리해 봤다.
AWS에서도 결국 누가 무엇을 할 수 있는지가 중요했다
IAM은 Identity and Access Management의 약자다.
이름 그대로 AWS 리소스에 대한 신원과 접근 권한을 관리하는 서비스다.
온프레미스 환경에서는 사용자 계정을 만들고, 그룹에 소속시키고, 시스템이나 공유 폴더에 대한 접근 권한을 부여하는 작업을 많이 한다.
회사 환경에 따라 AD 그룹이나 시스템 계정, 접근 제어 정책을 이용해 누가 어떤 자원에 접근할 수 있는지 관리한다.
AWS에서도 기본적인 목적은 비슷하다.
예를 들어 다음과 같은 상황을 생각할 수 있다.
- 운영 담당자는 EC2 인스턴스를 조회하고 시작하거나 중지할 수 있다.
- 개발 담당자는 개발 환경의 S3 버킷에 접근할 수 있다.
- 애플리케이션은 S3 파일을 읽을 수 있지만 삭제할 수는 없다.
이처럼 AWS에서는 단순히 계정을 만드는 것에서 끝나지 않는다.
각 사용자가 어떤 작업을 수행할 수 있는지, 애플리케이션이 어떤 리소스에 접근할 수 있는지까지 권한을 구체적으로 관리해야 한다.
처음에는 IAM을 AWS의 계정 관리 서비스 정도로 생각했지만, 공부하면서 AWS API 호출과 리소스 접근을 통제하는 권한 관리 체계라는 점을 다시 이해하게 됐다.
IAM User, Group, Role의 차이
오늘 가장 먼저 구분해야 했던 것은 IAM User, Group, Role이었다.
세 가지 모두 권한 관리와 관련이 있지만 역할은 서로 다르다.
IAM User — 사용자
IAM User는 AWS에서 사용자나 애플리케이션을 나타내는 신원이다.
필요한 자격 증명과 권한을 설정해 AWS 리소스에 접근하도록 할 수 있다.
온프레미스의 개별 사용자 계정과 연결해서 생각하면 이해하기 쉬웠다.
다만 AWS에서는 사람의 계정 관리에 IAM User만 사용하는 것은 아니다. 조직 환경에서는 IAM Identity Center나 외부 ID 공급자를 이용한 연동 방식도 고려할 수 있다.
우선 SAA의 기본 개념을 이해하는 단계에서는 IAM User가 어떤 역할을 하는지부터 기억하기로 했다.
IAM Group — 그룹
IAM Group은 여러 IAM User를 그룹으로 묶어 공통 권한을 관리하는 데 사용한다.
예를 들어 운영팀에 속한 사용자들이 EC2 인스턴스를 조회할 수 있어야 한다고 가정해 보자.
각 사용자에게 동일한 권한을 개별적으로 설정하는 대신 그룹에 공통 정책을 연결하면 관리가 편리해진다.
이 부분은 온프레미스에서 AD 보안 그룹을 이용해 사용자 권한을 관리했던 경험과 연결해서 이해할 수 있었다.
다만 IAM Group은 IAM User를 관리하기 위한 기능이며, IAM Role을 그룹의 구성원으로 넣는 방식은 아니다.
IAM Role — 역할
IAM Role은 오늘 공부하면서 특히 중요하다고 느낀 개념이다.
Role은 특정 사용자에게 장기간 고정된 자격 증명을 제공하는 방식과 달리, 신뢰된 주체가 역할을 맡아 해당 권한을 사용하도록 설계할 수 있다.
역할을 맡은 주체는 일반적으로 임시 보안 자격 증명을 이용해 AWS 작업을 수행한다.
Role은 사람이 맡을 수도 있고, EC2 같은 AWS 서비스나 애플리케이션이 사용할 수도 있다.
여기서 중요한 것은 Role에 단순히 권한만 설정하는 것이 아니라는 점이다.
Role에는 다음 두 가지 관점을 함께 생각해야 한다.
- 누가 이 역할을 사용할 수 있는가?
- 이 역할을 사용하면 어떤 작업을 할 수 있는가?
앞의 질문은 역할을 맡을 수 있는 주체를 결정하는 신뢰 정책(Trust Policy)과 관련이 있다.
뒤의 질문은 해당 역할에 연결된 권한 정책(Permissions Policy)과 관련이 있다.
처음부터 모든 정책 문법을 외울 필요는 없겠지만, 두 정책이 서로 다른 목적을 가진다는 점은 기억해야 할 것 같다.
EC2에 IAM Role을 연결하는 이유
오늘 공부하면서 가장 실무적으로 와닿았던 부분은 EC2와 IAM Role의 관계였다.
예를 들어 EC2에서 실행되는 애플리케이션이 S3에 저장된 파일을 읽어야 한다고 생각해 보자.
이때 애플리케이션에 AWS 액세스 키와 시크릿 액세스 키를 직접 입력하는 방법을 떠올릴 수 있다.
하지만 이런 방식은 자격 증명을 코드에 저장하거나 별도의 설정 파일로 관리해야 하므로 유출 위험과 키 교체 부담이 발생할 수 있다.
이럴 때 EC2에 IAM Role을 연결하는 방법을 사용할 수 있다.
EC2 인스턴스
|
v
IAM Role 연결
|
v
필요한 S3 권한 부여
|
v
임시 자격 증명 사용
|
v
허용된 S3 작업 수행역할에 필요한 권한을 부여하고 EC2에 연결하면, 인스턴스에서 실행되는 애플리케이션은 AWS가 제공하는 임시 자격 증명을 이용할 수 있다.
따라서 애플리케이션 코드에 장기 액세스 키를 직접 저장하지 않아도 된다.
물론 Role을 연결했다고 해서 모든 S3 버킷에 접근할 수 있게 되는 것은 아니다. 실제로 접근할 수 있는 범위는 연결된 권한 정책 등 여러 조건에 의해 결정된다.
이 부분은 SAA 문제에서 중요하게 활용할 수 있는 개념이라고 생각했다.
EC2 애플리케이션이 AWS 서비스에 접근해야 할 때는 액세스 키를 직접 저장하기보다 IAM Role을 사용하는 방법을 먼저 고려한다.
이 기준을 우선 기억해 두기로 했다.
IAM Policy는 실제 권한을 정의한다
IAM User나 Role이 존재한다는 사실만으로 모든 AWS 서비스를 자유롭게 사용할 수 있는 것은 아니다.
어떤 작업을 수행할 수 있는지는 정책(Policy)을 통해 결정한다.
정책은 일반적으로 어떤 작업을 어떤 리소스에 대해 허용하거나 거부할지를 정의한다.
정책을 이해하기 위해서는 다음 세 가지 요소를 먼저 살펴보면 된다.
Effect
허용할 것인가, 거부할 것인가
Action
어떤 작업을 할 것인가
Resource
어떤 AWS 리소스에 적용할 것인가예를 들어 특정 S3 객체를 읽는 작업을 허용하려면 s3:GetObject와 같은 작업 권한을 사용할 수 있다.
반면 객체를 삭제하는 작업에는 별도의 권한이 필요하다.
파일을 읽을 수 있다고 해서 삭제까지 가능한 것은 아니다.
이처럼 권한은 가능한 한 구체적으로 설정해야 한다.
그리고 일반적인 IAM 권한 평가에서는 명시적 거부(Deny)가 적용되면 다른 정책에 허용 규칙이 있더라도 해당 작업은 거부된다. 허용 규칙이 없으면 기본적으로 허용되지 않는다는 점도 함께 기억해야 한다.
오늘은 복잡한 정책 JSON을 작성하는 것까지 진행하지 않았다.
우선 정책이 어떤 작업을, 어떤 리소스에 대해 허용하거나 거부하는지 이해하는 데 집중했다.
IAM Policy와 S3 Bucket Policy는 무엇이 다를까?
정책을 공부하면서 헷갈리기 쉬웠던 부분은 IAM Policy와 S3 Bucket Policy의 차이였다.
둘 다 권한을 제어하지만 정책을 연결하는 위치와 접근을 바라보는 관점이 다르다.
IAM Policy
IAM Policy는 IAM User, Group 또는 Role에 연결해 사용할 수 있다.
예를 들어 EC2에 연결된 AppRole에 특정 S3 버킷의 객체를 읽을 수 있는 권한을 부여하는 방식이다.
이 경우 애플리케이션의 역할에 어떤 작업을 허용할지를 정의한다.
S3 Bucket Policy
S3 Bucket Policy는 S3 버킷에 연결하는 리소스 기반 정책이다.
예를 들어 특정 IAM Role이 해당 버킷의 객체에 접근할 수 있도록 버킷 정책에서 규칙을 설정할 수 있다.
이 경우에는 버킷이라는 리소스를 기준으로 누가 어떤 작업을 할 수 있는지 정의한다.
두 가지를 비교하면 다음과 같다.
| 구분 | IAM Policy | S3 Bucket Policy |
|---|---|---|
| 정책을 연결하는 위치 | IAM User, Group, Role 등 | S3 버킷 |
| 기본 관점 | 자격 주체가 수행할 수 있는 작업 | 리소스에 접근할 수 있는 주체와 작업 |
| 활용 예시 | 애플리케이션 Role에 S3 읽기 권한 부여 | 특정 Role의 버킷 접근 허용 |
실제 접근 가능 여부는 계정 관계와 다른 정책의 적용 여부 등에도 영향을 받을 수 있다. 따라서 두 정책 중 하나만 무조건 사용해야 한다고 생각하기보다는 요구사항에 맞는 권한 설정 방식을 이해하는 것이 중요하다.
이번에는 정책 문법을 깊게 외우기보다 정책을 누구에게 연결하는지, 어떤 리소스를 대상으로 하는지를 먼저 구분하기로 했다.
최소 권한 원칙은 AWS에서도 중요했다
보안 업무를 하면서 반복적으로 접했던 원칙 중 하나가 최소 권한 원칙이다.
영어로는 Least Privilege라고 한다.
말 그대로 사용자나 애플리케이션이 업무를 수행하는 데 필요한 최소한의 권한만 부여하는 것이다.
예를 들어 어떤 애플리케이션이 S3 버킷의 특정 경로에 있는 파일을 읽기만 하면 된다고 가정해 보자.
이때 모든 S3 버킷에 대한 전체 권한을 부여하는 것은 불필요한 권한까지 제공하는 셈이다.
필요한 버킷과 객체에 대해 읽기 작업만 허용한다면 권한이 오용되거나 자격 증명이 유출되었을 때의 영향을 줄이는 데 도움이 된다.
AWS에서도 IAM 정책을 설계할 때 최소 권한 원칙을 적용하는 것이 중요하다.
시험에서도 단순히 작업을 수행할 수 있는 방법을 고르는 데서 끝나지 않고, 불필요한 권한을 줄이면서 요구사항을 만족하는 방법을 판단해야 한다.
이 부분은 기존 보안 운영 경험과 연결되는 개념이었다.
다만 기존에 알고 있던 보안 원칙을 AWS에 적용할 때도, AWS 정책의 실제 동작 방식과 권한 평가 과정을 함께 이해해야 한다는 점을 기억하려고 한다.
KMS와 Secrets Manager의 기본 역할
오늘 마지막으로 살펴본 것은 AWS KMS와 Secrets Manager다.
두 서비스 모두 보안과 관련이 있지만 목적은 서로 다르다.
AWS KMS
AWS Key Management Service(KMS)는 암호화 키를 관리하는 서비스다.
데이터를 암호화하거나 복호화하는 작업에서 암호화 키를 관리하는 역할을 한다.
SAA에서는 데이터 암호화와 키 관리 요구사항이 나왔을 때 KMS를 떠올릴 수 있어야 한다.
AWS Secrets Manager
Secrets Manager는 데이터베이스 자격 증명, API 키와 같은 비밀 정보를 저장하고 관리하는 서비스다.
지원되는 구성에서는 비밀 정보의 교체를 자동화하는 기능도 활용할 수 있다.
예를 들어 애플리케이션이 데이터베이스에 접속할 때 사용하는 비밀번호를 소스 코드에 직접 기록하기보다는 별도의 비밀 정보 관리 기능을 이용하는 방식을 생각할 수 있다.
둘의 차이를 간단히 정리하면 다음과 같다.
KMS
→ 암호화 키 관리
Secrets Manager
→ 비밀번호, API 키 등의 비밀 정보 관리둘은 서로 대체하는 서비스가 아니다. 비밀 정보를 암호화해 저장하는 과정에서 KMS가 함께 사용될 수도 있다.
오늘은 세부 설정까지 공부하지 않고, 각 서비스가 해결하려는 문제가 무엇인지 구분하는 수준에서 정리했다.
3일차 공부를 마치며
오늘 공부하면서 느낀 점은 AWS의 권한 관리도 결국 기존 인프라와 보안 운영에서 중요하게 생각했던 원칙과 연결된다는 것이었다.
사용자와 그룹을 구분하고, 작업에 필요한 권한을 부여하고, 불필요한 접근을 제한하는 원칙은 익숙했다.
하지만 AWS에서는 IAM User, Group, Role의 용도를 구분해야 하고, 정책을 연결하는 위치에 따라 접근 제어 방식도 달라진다.
특히 EC2에 IAM Role을 연결해 임시 자격 증명을 사용하도록 하는 방식은 꼭 기억해 둘 만한 내용이었다.
앞으로 AWS를 설계할 때는 단순히 네트워크가 연결되는지뿐 아니라 애플리케이션에 어떤 권한이 필요한지도 함께 생각해야 할 것 같다.
오늘 공부한 내용을 정리하면 다음과 같다.
- IAM User는 사용자나 애플리케이션을 나타내는 신원이다.
- IAM Group은 여러 IAM User의 공통 권한을 관리하는 데 사용한다.
- IAM Role은 신뢰된 주체가 맡아 사용하는 역할이다.
- IAM Policy는 자격 주체 등이 수행할 수 있는 작업을 정의한다.
- S3 Bucket Policy는 버킷에 연결하는 리소스 기반 정책이다.
- EC2 애플리케이션에는 장기 액세스 키를 직접 저장하기보다 IAM Role을 사용하는 방법을 고려한다.
- KMS는 암호화 키 관리, Secrets Manager는 비밀 정보 관리에 초점을 둔다.
아직 IAM을 완전히 이해했다고 할 수는 없지만, 각 개념의 기본적인 차이는 정리할 수 있었다.
이번에도 많은 서비스를 한꺼번에 외우기보다는 시험에서 반복적으로 활용되는 기본 개념부터 확실히 이해하는 것을 목표로 삼았다.
다음에는 오늘 배운 내용을 문제에 적용하면서 IAM User와 Role, IAM Policy와 Bucket Policy의 차이를 실제 요구사항 속에서 구분해 보려고 한다.
정답을 빠르게 찾는 것보다 왜 그 선택이 요구사항에 맞는지 설명할 수 있는 공부를 이어가고 싶다.
3일차 복습 문제
오늘 공부한 내용을 바탕으로 다음 문제를 풀어보려고 한다.
이번 글에는 정답과 해설을 적지 않았다. 다음 학습 시간에 각 문제의 답을 직접 선택하고, 그 이유도 함께 정리할 예정이다.
문제 1
EC2에서 실행되는 애플리케이션이 S3 객체를 읽어야 한다. 애플리케이션 코드에 장기 액세스 키를 저장하지 않고 권한을 부여하는 가장 적절한 방법은 무엇인가?
A. EC2 인스턴스에 Public IP를 할당한다.
B. IAM Role을 EC2에 연결하고 필요한 S3 권한을 부여한다.
C. NACL에 S3 읽기 권한을 설정한다.
D. S3 버킷을 퍼블릭으로 공개한다.
문제 2
여러 IAM 사용자에게 공통 권한을 부여하고 편리하게 관리하려고 한다. 가장 적절한 IAM 구성요소는 무엇인가?
A. IAM Group
B. NAT Gateway
C. KMS Key
D. Subnet
문제 3
S3 버킷 자체에 특정 주체의 접근 규칙을 설정하고 싶다. 어떤 기능을 사용해야 하는가?
A. Security Group
B. NACL
C. S3 Bucket Policy
D. Route Table
문제 4
애플리케이션이 특정 S3 경로의 객체를 읽기만 하면 된다. 최소 권한 원칙에 가장 적합한 권한 설계는 무엇인가?
A. 모든 AWS 서비스에 관리자 권한을 부여한다.
B. 모든 S3 버킷에 읽기, 쓰기, 삭제 권한을 부여한다.
C. 필요한 S3 객체를 대상으로 읽기 권한만 부여한다.
D. EC2에 Public IP를 할당한다.
문제 5
IAM 정책에서 명시적으로 Deny된 작업이 다른 정책에서 Allow되어 있다. 일반적인 IAM 권한 평가 결과는 무엇인가?
A. 항상 허용된다.
B. 명시적 Deny가 적용되어 거부된다.
C. EC2에서 실행할 때만 허용된다.
D. S3 Bucket Policy가 없으면 허용된다.
문제 6
데이터베이스 비밀번호나 API 키 같은 비밀 정보를 저장하고 관리하려고 한다. 가장 직접적으로 목적에 맞는 서비스는 무엇인가?
A. AWS KMS만으로 비밀 정보를 일반 저장한다.
B. AWS Secrets Manager
C. Internet Gateway
D. IAM Group