일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 우리FISA
- spring
- 도메인
- K-디지털트레이닝
- 글로벌소프트웨어캠퍼스
- route 53
- 우리에프아이에스
- M2
- https
- sts
- AWS
- Java
- 우리에프아이에스 #
- dbeaver
- 로드밸런스
- 우리FIS아카데미
- HTTP
- 우리FIS아카데미 #
- 클라우드 서비스 개발 #
- 클라우드 서비스 개발
- 우리FISA #
- 맥OS
- jdk
- mysql
- 맥북
- springboot
- Gradle
- 리눅스
- 맥
- Today
- Total
<<개발일지>>
AWS SCP, OU, Policy 본문
개인이 AWS 계정을 사용하는 경우에는 AWS Organization을 이용해 다른 AWS 계정들을 연동시키지만 개발계, 검증계, 운영계 등과 같은 OU를 따로 생성하는 경우는 드물다. 하지만 엔터프라이즈급 기업의 경우는 다르다. 여러가지 이유로 인해 AWS Organization을 통해 다수의 AWS 계정을 활용하여 OU를 생성해 기업의 구조와 흡사한 형태로 관리해야 할 것이다.
SCP, OU에 대해 알아보고 여태껏 봐았던 IAM Policy 와는 어떻게 차이가 날까?
SCP (Service Control Policy)
- SCP는 OU 또는 AWS account 를 대상으로 적용이 가능하다.
- SCP는 하위 OU에 상속이 된다.
- SCP는 OU들에 다르게 적용 가능하다.
Permission Boundary & Policy
- 정책과 경계는 IAM User 대상으로 적용이 가능하다.
- SCP와 중첩되어야만 정책이 적용 된다.
OU (Organization Unit)
- OU는 AWS Account 들의 그룹 단위이다.
- OU는 하위 OU를 가질 수 있다. 회사 구조를 반영할 수 있다.
- 하나의 AWS 계정은 오직 하나의 OU에 속할 수 있다. 다른 OU에는 속할 수 없다.
- OU는 5단계 계층적 구조를 가질 수 있다.
management Account
- OU를 생성한 계정이다.
- 다른 AWS Account를 초대하거나 OU에서 포함시키거나 제거할 수 있다.
- 오직 하나의 마스터/루트 계정만이 존재한다.
- 이 계정은 SCP 의 영향을 받지 않는다.
Account
- OU에 초대받은 AWS 계정들이다.
- 신규 AWS 계정들은 OU에 생성되자마자 초대 가능하다.
- 기존에 존재하는 AWS 계정들도 OU에 초대받을 수 있다.
IAM Users
- AWS Account 에 속하는 IAM 사용자를 의미한다.
- Permission boundary & policy에 직접 영향을 받는다.
AWS Organization 을 이용하는 데 있어 장점
1. 중앙관리와 거버넌스의 일관성
- 다수의 AWS 계정들을 일관성 있게 관리할 수 있다. 그룹 또는 OU를 구성한 뒤 적절한 SCP를 연결해 다수의 계정들을 사용에 맞게 일관적으로 관리 가능하다.
- 다른 계정들의 다른 서버, 스토리지 및 클라우드 리소스를 효과적으로 관리할 수 있다.
- AWS 계정 구조를 기업의 구조에 맞게 구성할 수 있다.
2. 접근제어의 단순화
- 계정 그룹을 만든 다음 그룹에 SCP를 연결하여 계정 전체에 적절한 정책이 적용되도록 할 수 있다.
- 개별 AWS 서비스를 구체적으로 허용 또는 거부할 수 있다.
-> OU 또는 AWS 계정에 적절한 SCP를 연결할 수 있다. 예를 들어 운영계 OU에는 ap-northeast-2 리전 외 다른 리전에는 서비스를 생성할 수 없다. 하지만 개발계 OU의 경우에는 여러 테스트를 위해 다른 리전에서 서비스를 사용할 수 있도록 SCP를 구성했다. 이제 AWS 계정들을 개발계 또는 운영계 OU에 포함시켜주기만 하면 해당 SCP를 적용받을 수 있다.
3. 통합 결제
- AWS Organization를 사용하면 통합 결제를 통해 조직의 모든 AWS 계정에 대해 단일 결제 방법을 설정할 수 있다.
- 모든 계정에서 발생한 요금의 통합 보기를 볼 수 있다. 또한 개별적으로 계정을 추적할 수 있으며 비용 데이터는 별도의 파일로 다운로드 할 수 있다.
- 하나의 대시보드에서 모든 계정의 비용을 관리하고 감사할 수 있다.
-> 만약에 10개 정도의 AWS 계정들을 가지고 있다고 가정해 보자, 매월 결제일이 되면 10개의 계정에서 비용이 얼마나 나올지 어떤 서비스를 사용했는지 내역을 보기 위해서는 10개의 계정들에서 일일이 확인해봐야 한다. 하지만, AWS Organization으로 통합할 경우 통합적으로 비용을 관리하고 결제할 수 있다.
4. 중앙 집중식 보안 및 감사
- AWS CloudTrail을 사용하여 계정의 모든 이벤트를 감사할 수 있다.
- 권장 구성 기준을 중앙에서 정의할 수 있다.
- 리소스, AWS 리전 및 AWS Config가 있는 계정 전반에 걸쳐 AWS Control Tower를 사용하여 교차 계정 보안 감사를 설정하거나 계정 전체에 적용된 정책을 관리하고 볼 수 있따.
- GuardDuty, Firewall Manager, IAM Access Analyzer 등과 같은 보안 서비스를 중앙에서 관리하여 리소스를 보호할 수 있다.
-> 비용결제와 함께 AWS Organization을 쓰는 가장 큰 이유라고 생각한다. AWS에서는 통합 보안 툴로써 Security Hub 서비스를 제공하고 있다. 이는 각종 보안 툴로부터 통일화된 양식의 finding을 제공받아 중앙 집중식으로 관리하게 된다. 각종 보안 툴뿐만 아니라 member로 속해있는 AWS 계정들의 finding 역시 중앙 집중식으로 관리가 가능하다.
그 외 AWS 계정의 추가에 있어 필요한 역할을 가진 OU내에서 생성하기만 하면 연결된 SCP를 그대로 적용받을 수 있다는 장점이 있다.
클라우드 이전에 있어 가장 중요한 측면 중의 하나가 클라우드가 기업의 조직도를 그대로 반영할 수 있을까이다. AWS Organization, OU, SCP를 활용해 기업의 조직도를 클라우드로 녹여내는 것 역시 클라우드 보안에서 중요한 요소이다.
'클라우드 시큐리티' 카테고리의 다른 글
VPC 엔드포인트 (0) | 2025.04.16 |
---|---|
VPC 기초 (0) | 2025.04.14 |
클라우드 아키텍처 구조 파악을 통해 아키텍처 구조 이해 (0) | 2025.04.05 |