우리금융그룹 AWS 클라우드 보안 아키텍처
- Terraform
- AWS Network Firewall
- AWS WAF
- AWS Shield Standard
- GuardDuty
- Security Hub
- Splunk
- Python
- AWS
- 5
- Splunk SIEM/SOAR로 연동한 보안 서비스
- 3
- 망분리를 옮긴 설계 원칙
- 1
- 다중 AWS 계정에 적용하는 Terraform 코드
다중 AWS 계정의 망분리 요건을 서브넷과 방화벽 구조로 옮기고, 보안 구성을 Terraform 코드 한 벌로 표준화했습니다.
규모: 다중 AWS 계정
개요
-
문제
그룹사들이 퍼블릭 클라우드를 처음 도입하는 단계에 Terraform이 없었고, 계정마다 담당자에 따라 보안 설정이 달랐습니다. 망분리 규정을 문서로만 지키기도 어려웠습니다.
-
접근
망분리(중요도가 다른 네트워크를 나눠 외부 위협이 내부로 바로 들어오지 못하게 하는 금융권 통제) 요건을 DMZ·Private 서브넷 분리, 백엔드 공인 IP 금지, 허용된 대상으로만 아웃바운드라는 세 원칙으로 옮겼습니다. WAF, Network Firewall, Shield Standard 구성을 Terraform으로 정의해 모든 계정에 같은 코드를 적용하고, GuardDuty와 Security Hub까지 Splunk SIEM/SOAR로 연동했습니다.
-
결과
계정이 늘어나도 같은 보안 기준이 코드로 반복되어 담당자별 정책 편차가 사라졌습니다. 다중 AWS 계정의 통신 구성은 Python 파이프라인으로 자동 수집·분석해 반복 가능한 점검이 됐습니다. IAM 권한도 Terraform으로 정의해 과도한 권한을 구조적으로 막았습니다.
-
배운 점
보안 구성이 코드가 되면 계정별 차이가 곧 코드 차이로 보인다는 점이 가장 큰 배움이었습니다. 담당자마다 콘솔에서 설정하던 때에는 어느 계정이 다른지 일일이 비교해야 했지만, 같은 Terraform 코드를 모든 계정에 적용하니 다른 부분은 코드에서 바로 드러났습니다. 망분리처럼 문서로만 존재하던 규정도 서브넷 분리, 백엔드 공인 IP 금지, 허용된 대상으로만 아웃바운드라는 세 원칙으로 바꾸고 나서야 구조로 지킬 수 있었습니다. 동시에 코드로 정의한 기준은 각 계정에서 실제로 지켜지는지 확인할 때 비로소 완성된다는 것도 알게 됐고, 통신 구성을 자동으로 수집·분석하는 파이프라인을 만든 것도 그 확인을 사람의 기억이 아닌 반복 가능한 점검으로 만들기 위해서였습니다.