AWS 리소스에 대한 보안 액세스 설계
발행: (2026년 2월 1일 오후 03:19 GMT+9)
15 min read
원문: Dev.to
Source: Dev.to
번역을 진행하려면 번역이 필요한 전체 텍스트를 제공해 주시겠어요? 텍스트를 보내주시면 요청하신 대로 한국어로 번역해 드리겠습니다.
시험 가이드: 솔루션 아키텍트 – 어소시에이트
🛡️ 도메인 1 – 보안 아키텍처 설계
📘 작업 설명 1.1
보안 액세스는 다음 질문에 명확히 답할 수 있음을 의미합니다:
- 누가 AWS에 액세스하려고 합니까?
- 무엇을 할 수 있습니까?
- 어디에서 할 수 있습니까 (어떤 계정/어떤 리소스인가요)?
- 어떻게 본인임을 증명합니까 (비밀번호, MFA, 연동)?
- 얼마나 오래 액세스가 지속되어야 합니까 (임시 vs. 장기)?
이 작업은 주로 신원 + 권한 + 멀티 계정 설정에 관한 것입니다.
Knowledge
1️⃣ 여러 계정에 걸친 액세스 제어 및 관리
회사가 성장하면 단일 AWS 계정이 복잡해집니다:
| 문제 | 영향 |
|---|---|
| 한 곳에 너무 많은 사람과 팀이 존재 | 권한이 일관되지 않고 감사하기 어려워짐 |
| 일관되지 않은 권한 | 실수가 더 큰 폭발 반경을 가짐 |
| 개발/테스트/프로덕션을 구분하기 어려움 | 운영 위험이 증가 |
멀티‑계정 전략은 다음을 도와줍니다:
- 워크로드 격리 (dev / prod)
- 보안 규칙을 일관되게 적용
- 위험 감소
일반적인 패턴
| 패턴 | 해결하는 문제 | 초보자가 이해하기 쉬운 비유 |
|---|---|---|
| AWS Organizations + Organizational Units (OUs) | 여러 계정을 하나의 가족처럼 관리 | 계정용 폴더 시스템 + 공유 규칙 |
| AWS Control Tower | 표준 방식으로 멀티‑계정 설정 | 보안이 강화된 멀티‑계정 환경을 위한 가이드형 설정 |
| SCPs (Service Control Policies) | 계정 전반에 걸친 가드레일 제공 | “관리자라도 할 수 없는” 규칙 |
Note: SCP는 권한을 부여하지 않습니다. 계정/OU에서 허용 가능한 최대 행동만 설정합니다. 실제로 작업을 허용하려면 IAM 권한이 필요합니다.
2️⃣ AWS 연합 액세스 및 아이덴티티 서비스
IAM & IAM Identity Center
모든 직원에게 AWS 사용자명을 만들기보다, 많은 조직이 연합을 사용해 기존 기업 로그인으로 로그인하도록 합니다.
| 구성 요소 | 설명 |
|---|---|
| IAM (Identity and Access Management) | 핵심 권한 엔진 – 사용자, 그룹, 역할, 정책을 포함 |
| IAM Identity Center (AWS SSO) | 여러 계정에 걸친 직원 접근을 위한 중앙 로그인 – 다중 계정과 단일 관리 지점에 이상적 |
간단 비교
| 옵션 | 가장 적합한 경우 | 왜 더 안전한가 |
|---|---|---|
| IAM Users (long‑term) | 규모가 작고 단순한 환경, 제한된 경우 | 작동은 하지만 비밀번호/키가 퍼질 수 있고 안전하게 관리하기 어려움 |
| Federation / IAM Identity Center | 팀, 기업, 다중 계정 | 중앙 로그인, 오프보딩이 쉬움, 장기 자격 증명 감소 |
Recommendation: 사람에게는 역할 + 연합을 선호하고, 장기 자격 증명이 있는 IAM 사용자를 많이 만들지 않는 것이 좋습니다.
3️⃣ AWS 글로벌 인프라스트럭처
리전 & 가용 영역
- 일부 서비스는 글로벌(예: IAM, Route 53) – 아이덴티티나 권한 개념이 널리 적용됩니다.
- 많은 리소스는 리전별 – 특정 리전에 존재합니다.
액세스 규칙에 어디서 행동이 허용되는지를 포함시킬 수 있습니다. 예:
- “eu‑west-1에서만 배포 허용”
- “승인된 리전 외부에서 리소스 생성 금지”
4️⃣ AWS 보안 모범 사례
최소 권한 원칙
최소 권한이란:
- “admin” 권한은 정말 필요할 때만 부여
- 작업에 필요한 행동만 허용
- 특정 리소스에만 접근 제한 – 가능한
Resource: "*"사용을 피함
예시
| 너무 넓은 권한 | 개선된 권한 |
|---|---|
모든 S3 버킷에 Action: "*" | 특정 버킷/폴더에 Action: "s3:GetObject" |
| 전체 EC2 관리 | 특정 인스턴스 ID에 Action: "ec2:StartInstances" / ec2:StopInstances |
Action: "*"와 같이 광범위한 권한을 보게 된다면, “최선의 답변”은 일반적으로 더 좁은 권한 + 조건을 추가하는 것입니다.
5️⃣ AWS 공유 책임 모델
| 책임 | AWS | 고객 |
|---|---|---|
| 물리적 인프라 | 데이터센터 하드웨어, 전력, 냉각 | — |
| 기본 서비스 인프라 | 컴퓨트, 스토리지, 네트워킹 | — |
| 서비스 가용성 | 서비스 가동 시간 SLA | 아키텍처 결정 (다중 AZ, 백업, DR) |
| 클라우드 보안 | 물리적 보안, 호스트 OS, 하이퍼바이저 | IAM 권한, 데이터 암호화, 네트워크 구성 |
보안은 공유됩니다:
AWS는 클라우드를 보호하고, 고객은 클라우드에 넣는 것을 보호합니다.
Skills
A – Apply Best Practices to IAM Users and Root Users
Multifactor Authentication (MFA)
- root user는 계정의 마스터 키입니다.
- root user에 MFA를 활성화하고 일상 작업에 root를 사용하지 마세요.
- 관리 작업은 역할(role)이나 제어된 아이덴티티를 사용합니다.
Scenario tip: 질문에 “root user를 매일 사용한다”는 내용이 있으면, 해결 방법은 거의 항상 MFA 활성화와 일상적인 root 사용 중단입니다.
B – Design a Flexible Authorization Model (Users, Groups, Roles, Policies)
| Element | Purpose |
|---|---|
| Policies | 권한 규칙 (허용/거부) |
| Roles | 임시 “작업 역할”을 가정함 |
| Users | 개별 로그인 (인간 또는 서비스) |
| Groups | 여러 사용자에게 동일한 정책을 한 번에 적용 |
- 사람 → Identity Center / federation을 통해 로그인 → 역할을 가정.
- 애플리케이션 / 서비스 → roles 사용 (코드에 장기 액세스 키를 두지 않음).
C – Role‑Based Access Control (RBAC) Strategy
- 접근 권한은 역할을 가정함으로써 부여되며, 영구적인 관리자 권한이 아닙니다.
AWS STS (Security Token Service)
- 임시 자격 증명을 발급 → 장기 비밀 노출을 감소시킵니다.
- 깔끔한 교차 계정 접근을 가능하게 합니다.
Cross‑Account Access
- Account A의 사용자가 Account B의 역할을 가정합니다.
- 비밀번호를 공유하지 않으며, 계정 간에 액세스 키를 복사하지 않습니다.
D – Multi‑Account Security Strategy
Control Tower & Service Control Policies
- 구조화된 계정 레이아웃 사용 (예: prod / dev / security).
- SCP를 사용해 조직 전체 가드레일을 적용하여 공유 보안 기능을 격리합니다.
SCP Mindset
| Policy type | Effect |
|---|---|
| IAM Policies | 프린시플이 할 수 있는 것 (허용/거부) |
| SCPs | 계정이 허용될 수 있는 최대 범위 (최대 경계) |
Effective permissions = IAM에서 허용 AND SCP에서 차단되지 않은 경우.
E – Determine Appropriate Use of Resource Policies
일부 AWS 서비스는 리소스 기반 정책을 지원합니다 (예: S3 버킷 정책, SNS 토픽 정책, SQS 대기열 정책). 다음과 같은 경우에 사용합니다:
- 리소스 자체에 교차 계정 접근을 직접 부여해야 할 때.
- 서비스가 여러분을 대신해 동작하도록 허용할 때 (예: Lambda가 S3 버킷을 호출).
- IAM 정책보다 리소스에 적용하기 쉬운 조건을 사용할 때.
요약
- Identify 누가, 무엇을, 어디서, 어떻게, 그리고 얼마나 오래 접근이 필요한지 식별합니다.
- Leverage 격리 및 거버넌스를 위해 멀티‑계정 설계, AWS Organizations 및 Control Tower를 활용합니다.
- Prefer 장기 IAM 사용자보다 연동 + 역할을 선호합니다.
- Apply 최소 권한 원칙, MFA 및 SCP를 적용하여 가드레일을 강제합니다.
- Use 교차 계정 또는 서비스‑간 권한을 단순화할 때 리소스 정책을 사용합니다.
이 개념들을 Design Secure Architectures 영역의 Solutions Architect – Associate 시험을 위해 손에 넣어 두세요.
리소스‑기반 정책
정의: 정책이 리소스에 직접 연결된 경우.
일반적인 예시
- S3 버킷
- SQS 대기열
- SNS 토픽
- KMS 키
- Lambda 함수
주요 사용 사례
- 버킷, 대기열 또는 토픽에 대한 교차 계정 액세스
- 서비스‑대‑서비스 권한 부여
- 조건 적용(예: “HTTPS 전용”)
Decision Table
| Goal / Question | Best tool |
|---|---|
| 사용자/역할에 일반적으로 권한 부여 | Identity‑based policy (IAM 정책) |
| 리소스에 직접 접근 제어 | Resource‑based policy |
| 교차 계정 접근을 깔끔하게 허용 | 보통 role assumption + 때때로 resource policy (서비스에 따라 다름) |
디렉터리 서비스를 IAM 역할과 연동할 시점
연동이 이상적인 경우:
- 사용자가 이미 기업 아이덴티티(Google Workspace, Okta, Azure AD, AD 등)를 보유하고 있는 경우
- 쉽고 빠른 온보딩 및 오프보딩을 원할 때
- 장기 IAM 사용자를 최소화하고 싶을 때
| Audience | Recommended approach |
|---|---|
| 워크포스 (직원/계약자) | 연동 / IAM Identity Center |
| 워크로드 (앱/서비스) | IAM 역할 |
Cheat Sheet
| 시나리오 | 추천 솔루션 |
|---|---|
| Many AWS accounts | Organizations / Control Tower + SCPs |
| Employees use corporate login | Federation / IAM Identity Center |
| Third‑party needs access | Cross‑account role + temporary credentials (STS) |
| Avoid storing keys in code | Use roles (temporary credentials) |
| Restrict actions across the org | SCP guardrails |
| Grant access to a specific resource | Resource‑based policy (or resource policy + role) |
Recap Checklist ✅
If you can explain these ideas in simple terms, you are well‑prepared for Task Statement 1.1:
- 루트 사용자는 MFA로 보호되며 일상 작업에 사용되지 않습니다
- IAM 역할은 장기 IAM 사용자보다 선호됩니다
- 최소 권한 원칙이 적용됩니다: 필요한 작업만, 필요한 리소스만
- 여러 AWS 계정이 중앙에서 관리됩니다
- 계정 간 접근은 역할 가정을 사용합니다: 임시 자격 증명
- 직원 접근은 연동 또는 IAM Identity Center를 사용합니다
- 언제 신원 기반 정책과 리소스 기반 정책을 사용해야 하는지 이해합니다
AWS 백서 및 공식 문서
이 문서들은 Task Statement 1.1 뒤에 있는 주요 AWS 문서입니다.
암기할 필요는 없으며, AWS 보안이 왜 그렇게 작동하는지 이해하는 데 활용하세요.
핵심 백서
- AWS Well‑Architected Framework – Security Pillar – 최소 권한, ID 관리, 거버넌스 등 보안 액세스 설계 원칙.
- IAM Best Practices – 사용자, 역할, 그룹, 정책; 역할 및 임시 자격 증명이 선호되는 이유.
- AWS Shared Responsibility Model – AWS가 보호하는 영역과 사용자가 직접 보호해야 하는 영역.
ID 및 연합 관련 참고 자료
- IAM User Guide – 정책, 역할, 권한 평가, 정책 충돌 등에 대한 심층 탐구.
- IAM Identity Center (AWS SSO) Documentation – 대규모 인력 접근 관리.
- AWS Security Token Service (STS) Documentation – 임시 자격 증명 및 역할 전환(교차 계정 접근에 핵심).
다중 계정 및 거버넌스 참고 자료
- AWS Organizations User Guide – 조직 단위(OU)와 계정 구조(특히 SCP 동작에 중요).
- Service Control Policies (SCPs) Documentation – SCP가 권한을 제한하는 방식(“관리자라도 … 할 수 없어야 함” 시나리오에 중요).
- AWS Control Tower Overview – 표준화된 보안 다중 계정 설정 시각화(대규모 조직이나 거버넌스 질문에 자주 언급).