13. 어카운트 보안의 기본 요건
보안팀 전용
Cross-Account
Role
AWS 어카운트
크레덴셜 관리
(“Root 어카운트”)
Federation
Baseline Requirements
Actions &
Conditions
Enterprise
Role 연계
AWS
CloudTrail
14. 빌링 어카운트
• 고객 데이터 센터와
네트웍 연계 없음
• 모든 청구를 이
어카운트로 통합
• 볼륨 할인
• 필요 시, 리소스 관리
최소화
• 통합 청구 관점
고객 데이터 센터
빌링
로그 플로우
네트웍 경로
빌링
15. 보안 어카운트
• 필요 시, 고객 데이터
센터와 네트웍 연계
• CloudTrail과 보안 로그
• 보안 도구와 감사
• 크로스 어카운트 읽기 /
쓰기
• 암호화 키
빌링
보안
optional
AWS
CloudTrail고객 데이터 센터
빌링
로그 플로우
네트웍 경로
Amazon
Inspector
16. 공통 서비스 어카운트
• 고객 데이터 센터와
네트웍 연계
• DNS
• Active Directory
• 공통 서비스 VPC
• 배포 도구들
Golden AMI/패치
• 스캐닝 인프라
비 활동성 인스턴스
부적절한 태그
스냅샷 유지 보수
• 모니터링
공통 서비스
optional
빌링
보안
고객 데이터 센터
빌링
로그 플로우
네트웍 경로
17. 샌드박스 어카운트
• 고객 데이터 센터와
네트웍 연계 없음
• 신규 도입 검증(PoC)
• 실험 및 테스트
• 혁신 과제
샌드박스
optional
빌링
보안공통 서비스
고객 데이터 센터
빌링
로그 플로우
네트웍 경로
18. 스테이징 어카운트
• 고객 데이터 센터와
네트웍 연계
• 운영계와 유사
• 스테이징
• QA
• CI/CD 파이프 라인 배포
optional
스테이징
빌링
보안공통 서비스
고객 데이터 센터
샌드박스
빌링
로그 플로우
네트웍 경로
19. 운영계 어카운트
• 고객 데이터 센터
네트웍과 연계
• 운영계 어플리케이션
• 비 운영계로 부터 승급
• 제한적인 접근
운영
optional
빌링
보안공통 서비스
고객 데이터 센터
샌드박스스테이징
빌링
로그 플로우
네트웍 경로
20. 분업화된 AWS 어카운트 구조
구매/재무팀 보안/감사팀
빌링
어카운트
현업/운영팀
보안/감사유틸리티재무
통합 빌링
모든 어카운트에
대한 Read-only
접근
운영
로깅
어카운트
인사/네트웍팀
이벤트 /
상태 로깅
로그 데이터
Read-only
접근
스테이징
어카운트
샌드박스
어카운트
사용자 관리
어카운트
백업/DR
어카운트
보안/감사
어카운트
운영계
어카운트
공통 서비스
어카운트
22. 적용 전
• 400개 이상의 어카운트
• 통합 빌링 적용 안함
• 기존 사용자 관리환경과 연계 안함
• 낮은 보안 가시성
• 엔터프라이즈 써포트 이용 안함
23. 접근 방법
• 셀프 서비스
• 자동화
• 개발 중심
• 장려 vs. 통제
• 구역화 vs. 거버넌스
• 기본적으로 신뢰 관계, 주기적 검증
24. 어카운트 관리 – 통합 빌링
• 기존 어카운트들을 연결
• 한번의 청구
• 쉬운 트랙킹
• 사용량 병합
• 볼륨 할인
• 엔터프라이즈 써포트
• 공통 분석 기능
• 중앙에서 어카운트 생성
기존 어카운트들
25. 어카운트 관리 – 보안 어카운트
• 보안 팀을 위한 보안 전용
어카운트
• CloudTrail 통합
• 어플리케이션 로그 통합
• 보안 사고에 대한 대응
• 보안 감사 수행
AWS
CloudTrail
AWS
Config
26. 어카운트 관리 – 공통 서비스들
• 통합된 네트웍 서비스
Proxy, DNS, NTP
• 전용선 구성
• 엔터프라이즈 급 서비스를
위한 VPC 피어링
• 기 운용중인 Active Directory
환경과의 연계
27. 어카운트 관리 – 비지니스 단위 당 3개 어카운트
• 현업에게 자율권 부여
• 격리 수준
• 운영과 일관성
• 접근, 네트웍, 보안
• 샌드박스
• 시간과 비용의 제한을 둔
실험적인 PoC환경
• 스테이징
• 운영계 이관을 계획중인
어플리케이션들.
• 네트웍 연결.
• 좀더 엄격한 보안 통제.
• 운영계
• 네트웍 연결.
• 가장 높은 수준의 보안통제와
서비스 운영 관리
28. 어카운트 관리 – Full picture
Enterprise
Reduce Scale
빌링 보안 공통 서비스들
레거시
비지니스 A 비지니스 B 비지니스 C
샌드박스
스테이징
운영계
샌드박스
스테이징
운영계
샌드박스
스테이징
운영계
29. 어카운트 관리 – Bootstrap
• Root credential의 안전한 보관
• 통합 빌링과의 연결
• 서비스 관리 기록 생성
• 기 운영중인 ID관리 환경과 연계
초기 운영 Role 생성
• VPC 와 네트웍 셋업
Direct Connect / 공통 서비스 VPC와의 피어링
• 보안 통제와 감사 셋업
CloudTrail과 보안 운영 Role
Python (boto)
AWS
CloudFormation
AWS CloudTrail
30. Challenges…
• 실 사용 환경에서의 복잡성에 대한 이해 필요
• 고민했던 내용들 :
• 신규 계정으로 옮겨 지는 환경 들
• 서비스와 상호 작용하는 사용자 들
• 하이브리드 네트웍 연결이 필요한 어플리케이션 환경
33. 대표적인 사용 케이스
전사 보안 및 컴플라이언스 정책의 준수를 위한 AWS서비스
사용을 통제
접근 권한이 제한된 형태로 AWS 어카운트 생성 과정을 자동화
• API 결과를 받아서 후속 자동화 프로세스 진행(예, CloudFormation
템플릿 적용)
34. 2가지 관리 레벨
Billing mode
• 통합 빌링에 대한 하위 호환성
• 통합 빌링으로 묶여 있는 어카운트 패밀리는 자동으로 Billing mode로
전환됨
Full-control mode
• Billing mode를 포함
• Enables management of ALL types of OCPs
• Billing mode에서 Full-control mode 로 전환시, 적용되는 모든
Account에 초대/승낙을 받아야 함.
35. 주요 용어
Organization
• 중앙관리 하고자 하는 AWS 어카운트들의 집합
AWS 어카운트
• S3버킷, EC2인스턴스 같은 AWS 리소스들에 대한 리소스 컨테이너
• AWS IAM User/Role 단위로 제한된 리소스들에 접근
Master 어카운트
• Organization내에 다른 어카운트들에 대한 Payer 어카운트
• Organization 전체의 관리 허브
Organizational Unit (OU)
• Organization내 논리적으로 그룹핑된 AWS어카운트들의 집합
Administrative root
• OU계층 구조의 시작점
Organization Control Policy (OCP)
• 지정된 어카운트 집합에 적용할 통제항목들을 기술한 문서
• 적용 케이스 별 다른 형태의 OCP 정의
36. 신규 AWS 어카운트 생성 과정을 코딩화
• Master 어카운트만이 신규 AWS 어카운트 들을 생성함
• 생성 절차를 선택 구성
- Email address (required)
- Account name (required)
- IAM role name (optional - default name is OrganizationAccountAccessRole)
o Master어카운트로부터의 AssumeRole 접근을 허용하는 Trust 정책설정
o FULL CONTROL 퍼미션 설정
• 신규 AWS 어카운트 생성 시,
- Organization에 소속관계를 자동으로 부여
- Organization에서 제거 불가능
41. Organizational Control Policies (OCP) 적용
• 적용되는 통제에 대한 기술
• 서로 다른 다양한 경우를 기술하는 여러 유형의 OCP
• OCP의 제어를 받는 주체들
- Organization
- OUs
- AWS account
• OCP는 계층구조에서 상속기능을 제공(AWS account, OU,
organization)
43. OCP v1: Service Control Policies (SCPs)
• AWS서비스 API에 대한 접근을 통제
- 접근을 허용할 API 목록 정의 – whitelisting
- 접근을 거부할 API 목록 정의 – blacklisting
• SCP와 IAM 퍼미션은 상호 교집합으로 적용됨 (Master
어카운트에는 적용 불가)
• IAM 정책과 동일하게 작동
• 명시적 Deny > 명시적 Allow > Default Deny
• SCP는 지정된 서비스와 작업만 사용하게 하는 필터 개념으로 상위
계층에서 제한된 리소스를 하위 계층에서 다시 추가할 수 없음.
• 모든 OU, 어카운트는 ‘FullAWSAccess’라는 SCP를 가지고 있음.
• IAM Policy Simulator를 통해 SCP 테스트 가능.
45. Service Control Policies (SCP) 적용시
Allow:
EC2:*
Allow:
S3:*
Allow:
SQS:*
Allow:
EC2:*
Allow:
EC2:*
SCP IAM
Permissions
46. 모범 사례 – AWS Organizations
1. CloudTrail 상의 Master 어카운트 활동 내역을 모니터링
2. Master 어카운트에서는 리소스를 관리하지 않도록 권장
3. 최소 권한 부여 원칙 : IAM의 Service Last Accessed Data 를 활용.
4. SCP 생성 시, 별도로 OU를 생성하고 테스트용 어카운트를 가지고
간단하게 검증할 것을 권장. IAM Policy Simulator를 활용.
5. Root 노드에는 필요한 경우에만 SCP 적용
6. SCP는 권한을 제한하는 일종의 필터 개념으로 사용하고,
“whitelisting” 과 “blacklisting” 을 혼용하지 말것
7. 적법한 사유에 따른 AWS 어카운트 생성
47. AWS Organizations Limitations
1. 계층 구조는 루트와 가장 낮은 계층에 생성된 AWS 어카운트를
포함하여 5개의 레벨까지 구성.
2. OU와 AWS 어카운트는 한 번에 하나의 OU 멤버만 될 수 있음.
3. 초대장을 통해 조직에 가입한 멤버 어카운트 만 제거할 수 있고,
Organizations를 사용하여 생성한 멤버 어카운트는 제거할 수 없음.
4. Organizations는 20개의 AWS 어카운트(Master 어카운트 포함)
까지 관리 (Soft Limit)
5. AWS 어카운트에 대해 프로그래밍 방식의 MFA 설정 지원 안함.
6. 한번 지정된 Master 어카운트를 다른 AWS 어카운트로 변경할 수
없음.
48. AWS Organizations 사용 팁 및 유의점
1. 현재 버전에서, SCP는 IAM 정책과 동일한 규칙 및 문법을
따르지만, Condition을 지정할 수 없고 Resource 가 "*”으로 고정됨.
서비스와 Action만 지정 가능.
2. 빈 SCP를 계정에 연결하는 것은 모든 작업을 명시적으로 거부하는
의미임(디폴트 Deny).
3. 현재 버전에서는 Billing report에 OU 계층구조 반영 안됨.
어카운트 별로 Cost Allocation Tag 활용 권장.
50. https://www.awssummit.kr
AWS Summit 모바일 앱을 통해 지금 세션 평가에
참여하시면, 행사후 기념품을 드립니다.
#AWSSummitKR 해시태그로 소셜 미디어에
여러분의 행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 공유될 예정입니다.
여러분의 피드백을 기다립니다!
