Zero Trust architecture for service-to-service workloads (workshops.aws)
Workshop Studio
catalog.us-east-1.prod.workshops.aws
어떤 이유에서인지.. Zero Trsut의 CloudFormtation이 자꾸 Error가 발생하여, 실습은 하지 않고 개념에 대해서만 알아보자!!
- ZeroTrsut는 2020년 보안 워크샵을 가면 항상 설명을 들었었는데, 그때는 관심없게 지나가다가 이제 정리해보자!
Zero Trust 란?
말 그대로 아무도 믿을 수 없는 관계를 뜻한다.
전통적인 Infra 환경에서는 크게 "외부"은 위험한 영역이고, "내부"은 안전한 영역으로 이분법적인 사고를 갖는다.
하지만, "내부" 이라고 해서 전부 다 안전한 영역일까? "내부"에서 악의적인 사용자 또는 잘못된 개발은 없을까? 하는 생각에
Zero Trsut 라는 개념이 생겨났다.
Zero Trust Model은 크게 아래 2가지 특징을 가지고 있다.
1. 내/외부를 막론하고 적절한 인증 절차 없이는 어떤 시스템이든 신뢰해서는 안되며, 시스템 접속 시 신원 확인 절차를 가져야 한다.
2. 모든 파일 또는 서비스는 잠재적 위험 요소라는 의심으로 모든 데이터를 모니터링해야 하며, 접속 시 권한을 점검해야 한다.
조금 더 알아보니, Zero Trsut라는 개념은 "Google"에서 최초 제시한 개념으로
시스템, 서비스의 안전성을 네트워크 위치에 따라 나눈것이 아니라 서비스 및 사용자 신원/권환 확인에 의존하는 개념이다.
Zero Trsut의 대전제는 아래 6가지와 같다.
1. 신원/권한 확인은 "세션"이 시작될 때뿐만 아니라 각 서비스가 요청될때마다 확인하고 승인한다.
예) 모든 API 호출은 개별적으로 인증해야 한다.
2. 서비스 신원/권한 확인은 일관된 통신 규격을 따라야한다.
예) 모든 API 서비스는 각 호출마다 권한 확인을 해야 한다.
3. 모든 API 통신 채널에는 Endpoint 암호화 기능을 적용하여 통신 채널에 관계없이 데이터를 안전하게 보호한다.
4. 불필요한 통신은 서비스 설계단계에서 차단하며, 필요한 영역에 대해서만 네트워크 제어를 하도록 한다.
5. API Gateway 등과 같은 서비스를 활용하여 API 구성요소간 통신을 관리하고 모니터링한다.
예) API Gateway를 사용하여 API 속도 제한, IAM/Auth 등 각 서비스 권한을 제어하고 로깅을 한다.
6. 모든 자산을 식별하고, 각 장치마다 올바른 권한을 제공하고 주기적인 모니터링을 실시한다.
그렇다면, AWS에서는 Zero Trust 개념을 어떻게 구현할 수 있을까?
Old Infra에서는 단순 세션(방화벽 등으로 IP/Port)에 대한 점검만 확인하였다면,
Zero Trsut에서는 각 서비스에 대한 신원/권환 확인을 해야 한다.
그러기 위해서 VPC Endpoint + API Gateway 필요에 따라서 Guarduty를 사용한다.
핵심은 APC Endponint와 API Gateway 이다!!
실습 시나리오 대전제
1. Serivce A는 API Gateway를 통해 Service B를 호출한다.
2 .다른 Service 또는 사용자가 API Gateway를 통해 Service B를 호출하는 것은 차단해야 한다.
실습 시나리오 제한 방법
1. API Gateway를 통한 Zero Trsut 개념 구현
① API Gateway를 통해 Service B 호출 API를 Service A의 IP Subnet으로 제한한다.
→ 이 경우, Service B의 API 호출은 A IP Subnet에서만 호출 가능하며, 이외 IP에서 호출하는 경우는 차단된다.
② API Gateway를 통해 Auth 방식을 AWS IAM으로 변경하여, 호출자의 IAM 권한을 확인한다.
→ Auth 방식을 AWS IAM으로 지정할 경우, API Gateway는 호출자의 IAM 권한을 확인한다.
→ 호출자가 ServiceB에 권한 호출 권한이 있을 경우에만 허용하고, 나머지는 차단한다.
2. VPC를 통한 Zero Trust 개념 구현
① VPC Policy를 수정하여, VPC를 통해 API를 호출하는 IAM Role + API Method Role을 확인한다.
→ VPC를 따로 수정하지 않는다면 *:* 이다. 즉 모든 Role에서 호출할 수 있고, 모든 API를 호출할 수 있다.
물론 위 1의 ①, ②를 통해 API Gateway에서 차단될 수 있지만, 불필요한 트래픽 생성을 방지하기 위해서는
VPC단에서 Role 등을 확인하고 차단하는 것이 바람직하다.
→ VPC에서 API Gateway를 호출한 IAM Role을 선택하고, API 중에서도 GET ARN, POST ARN을 ALLOW 할 수 있다.
즉, VPC에서 특정 IAM Role이 있는 호출자에 대해서 API Gawateway의 특정 Method ARN 호출을 제한할 수 있다.
② VPC Security Group 조정을 통해 Security Group을 보유하고 있는 서비스에 대해서만 허용한다.
아래와 같이 VPC Security Group 中 Inbound 정책에서 허용 IP Group을 Security Group ID로 지정함으로써
해당 Security Group ID를 가지고 있는 서비스 또는 EC2에 대해서는 VPC 접근을 허용한다.
즉, Zero Trsut 개념을 AWS에서 구현하기 위해서는 API Gateway + VPC가 중요한 서비스이며,
각 서비스마다 아래의 과정을 통해 Zero Trust 구현이 가능하다.
+ 필요에 따라서 차단건에 대한 모니터링을 위해서는 AWS Garuduty를 이용하면 된다. 물론 추가 비용 발생...
| 1. API Gateway를 통한 구현 방법 ① API 호출하는 서비스 또는 EC2에 대한 IP 제한 : 특정 IP에 대해서만 호출 가능 ② API 호출하는 서비스 또는 EC2 등 호출자에 대한 IAM Role 점검 : 특정 Role에서만 호출 가능 2. VPC를 통한 구현 방법 ① API 호출하는 서비스 또는 EC2에 대한 IAM + API 호출 ARN 제한 : 특정 Role에 대해서 특정 ARN 호출 가능 ② VPC 접속 서비스 또는 EC2에 대해 Security Groupe 제한 : 동일한 Security Group 보유 서비스 또는 EC2만 호출 가능 |
물론 위의 구현 방법을 보면 1. API Gateway를 통한 구현 방법만으로도 API 호출마다 서비스 또는 호출자의 Role을 점검하기에
Zero Trust를 구현할 수 있다!!
다만, 이럴 경우 불필요한 트래픽이 API Gateway까지 전달이 되고, Gateway에서 차단되기에 불필요한 과금과 지연이 발생한다.
AWS는 모두 과금방식이므로 되도록이면 불필요한 트래픽을 사전에 차단하는 것이 중요하고,
VPC를 통해서 API Gateway까지 전달되는 트래픽을 우선 점검/차단하고 API Gaweway에서 이중으로 점검하는 방식이 좋다!
'기술 이모저모 > [AWS] Workshop' 카테고리의 다른 글
| [AWS][Config] Resource를 평가하고 모니터링하는 방법 (0) | 2022.02.17 |
|---|---|
| [AWS] Security Group 인바운드 정책에 보안 그룹 ID를 넣는이유 (0) | 2022.02.13 |
| [AWS][Forensic][WAF] 내 테스트 서버에 공격이 들어오다(1/2) (0) | 2022.02.12 |
| [Secworkshop] Protecting workloads on AWS (0) | 2022.02.10 |
| [AWS][WAF] WAF 서비스 개념 및 메뉴설명 (0) | 2022.02.07 |
