AWS IAM 보안: 실제 운영에서 효과적인 실용 가이드
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, code blocks, URLs, and technical terms.
소개
대부분의 AWS 보안 가이드는 what을(를) 알려줍니다. 이 가이드는 개발자가 코드를 배포해야 하고 보안이 차단 요소가 될 수 없는 프로덕션 환경에서 보안을 how 구현하는지 보여줍니다.
최소 권한 원칙은 이론적으로는 훌륭하지만 실제로는 복잡합니다. 개발자는 작업을 위해 권한이 필요하지만 AdministratorAccess를 무작정 부여하고 최선이라고 기대할 수는 없습니다.
역할 기반 액세스
역할 기반 액세스부터 시작하고, 사용자 기반이 아니라. 실제 직무 기능에 매핑되는 IAM 역할을 생성합니다:
| 역할 | 권한 |
|---|---|
| 개발자 | 대부분의 서비스에 대한 읽기 액세스; 개발 환경에만 쓰기 액세스 |
| DevOps / SRE | 인프라 관리에 대한 높은 권한; 프로덕션 변경에 제한 |
| 보안 팀 | 모든 계정에 대한 감사 및 규정 준수 권한 |
| 재무 | 비용 분석을 위한 읽기 전용 액세스 |
권한 경계
권한 경계를 안전망으로 사용하십시오. 사용자가 과도한 권한을 부여받았더라도, 경계가 실제로 수행할 수 있는 작업을 제한합니다.
- 다음과 같은 상황을 방지하는 권한 경계를 설정하십시오:
- 역할의 업무 기능에 필요한 것보다 더 많은 권한을 부여하는 경우.
90일 권한 감사
매 분기마다 실제로 사용되고 있는 권한을 검토하세요.
AWS Access Analyzer는 이를 간단하게 만들어 줍니다—지난 90일 동안 사용된 권한을 보여줍니다.
MFA Enforcement
MFA는 절대 양보할 수 없는 정책이어야 합니다:
- IAM 사용자 – 모든 IAM 사용자마다 MFA를 활성화합니다; 예외는 없습니다.
- 정책 수준 강제 – MFA가 없으면 모든 작업을 거부하는 정책을 만들고, MFA를 활성화하는 작업은 예외로 둡니다.
- 콘솔 접근 – AWS Management Console 로그인 시 MFA를 요구합니다.
- 프로그래밍 접근 – 역할을 전환할 때 MFA를 요구합니다(액세스 키에 직접 MFA를 연결할 수는 없습니다).
개발자를 위한 MFA 패턴
- 개발자는 최소 권한을 가진 장기 자격 증명을 받습니다.
- 작업을 수행하려면 MFA가 필요한 역할을 전환합니다.
- 전환된 역할이 세션에 실제 권한을 제공합니다.
액세스‑키 회전
액세스 키는 영구 자격 증명이며 가장 흔히 유출됩니다.
- 회전 규칙: 액세스 키를 90일(분기별)마다 회전합니다.
- 자동화: AWS Config 규칙 또는 사용자 정의 스크립트를 사용하여 90일 이상된 키를 감지하고 회전을 강제합니다.
콘솔 비밀번호에도 동일한 규칙을 적용하십시오—비밀번호 정책에서 비밀번호 만료를 활성화합니다.
참고: 프로덕션 워크로드에 장기 액세스 키를 여전히 사용하고 있다면 잘못된 것입니다. 가능한 한 IAM 역할을 사용하십시오.
장기 키 대신 IAM 역할 사용
| 서비스 | 권장 인증 유형 |
|---|---|
| EC2 | 인스턴스 프로파일 (역할) |
| ECS / EKS | 작업 역할 또는 서비스 계정 |
| Lambda | 실행 역할 |
| Cross‑account | 역할 전환 (Assume role) |
| Developers | AWS SSO 또는 임시 자격 증명을 사용한 역할 전환 |
세션 기간은 1시간에서 12시간까지 설정할 수 있으며, 보다 민감한 역할은 짧은 세션을 부여받습니다.
장기 키를 피할 수 없을 때
- CI/CD 파이프라인
- 타사 도구
- 레거시 애플리케이션
이러한 경우에는 엄격한 회전 및 모니터링을 적용하십시오.
네트워크 제어
IAM은 누가 무엇을 할 수 있는지를 관리하고, 네트워크 제어는 어디서 연결할 수 있는지를 결정합니다.
- 특정 IP 범위(사무실 IP, VPN 엔드포인트, 허가된 클라우드 환경)에서의 연결을 요구하는 조건을 IAM 정책에 추가합니다.
- 그 외 모든 것을 차단합니다.
이렇게 하면 자격 증명을 탈취했지만 네트워크에 속하지 않은 공격자를 차단할 수 있습니다.
민감한 작업을 위한 VPN
유효한 자격 증명과 MFA가 있더라도 프로덕션 접근에는 VPN 연결이 필요합니다.
VPN 프로파일
| 프로파일 | 요구 사항 |
|---|---|
| 표준 작업 | Anywhere + MFA |
| 프로덕션 변경 | VPN + MFA |
| 중요 작업 (IAM 변경, 보안 수정) | VPN + 승인 워크플로 |
완전 차단 대신 마찰을 추가하여 원격 작업을 수용합니다.
Service Control Policies (SCPs)
If you use AWS Organizations, SCPs are your “nuclear option”—they override all other policies.
Common SCPs
- Prevent disabling CloudTrail or GuardDuty
- Block public S3 buckets
- Restrict instance types to an approved list
- Deny operations in unauthorized regions
로깅 및 모니터링
- CloudTrail – 모든 계정, 모든 리전에서 예외 없이 활성화합니다.
- GuardDuty 및 Security Hub – 켜고 결과를 적극적으로 검토합니다.
보안은 설정하고 잊는 것이 아니라; 지속적인 모니터링이 필수입니다.
월간 감사 체크리스트
| 영역 | 점검 항목 |
|---|---|
| 액세스 키 연령 | 90일 이상 된 키가 있나요? 삭제하거나 교체하세요. 지난 90일 동안 사용되지 않은 키가 있나요? 삭제하세요. |
| MFA 상태 | MFA가 설정되지 않은 사용자가 있나요? 적용하세요. MFA 없이 콘솔 로그인한 경우가 있나요? 조사하세요. |
| 권한 사용 | 사용되지 않은 권한을 찾기 위해 Access Analyzer를 사용하세요. 과도하게 허용된 정책(와일드카드, *)을 검토하세요. |
| 비정상 활동 | 새 IAM 사용자/역할, 핵심 리소스에 대한 권한 변경, 인증 실패 시도, 이상한 위치에서의 API 호출, 루트 계정 사용. |
개선 우선순위
| 기간 | 초점 |
|---|---|
| 1주차 | 중요한 문제 (예: MFA 누락, 과도하게 허용된 관리자 접근) |
| 2‑3주차 | 중요한 강화 작업 (예: SCP, 네트워크 제한) |
| 2개월 차 | 지속적인 강화 (키 회전 자동화, 로깅 향상) |
| 지속 | 유지보수, 지속적인 감사 및 점진적 개선 |
결론
완벽한 보안은 존재하지 않습니다. 목표는 공격자들이 더 쉬운 목표로 눈길을 돌리도록 충분히 견고한 AWS 환경을 만드는 것입니다.
- 모든 곳에서 MFA를 적용하세요.
- 자격 증명을 정기적으로 교체하세요.
- 역할 기반 접근 및 권한 경계와 함께 최소 권한 원칙을 적용하세요.
- IP 조건 및 VPN 요구 사항으로 네트워크 접근을 제한하세요.
- 지속적으로 감시하세요.
이러한 관행은 눈에 띄지는 않지만 효과적이며, 침해된 자격 증명으로 암호화폐 채굴기가 실행될 때 새벽 3시 전화에 시달리는 일을 방지해 줍니다.