SPC란?
SPC를 처음 들어보신 분들은 아래 Tech 아티클을 먼저 읽어주세요
SPC 공통/ 산업 특화 Policy
SPC가 일반 랜딩존과 다른 점은 크게 두 가지, Policy와 기밀컴퓨팅(Confidential Computing) 기술입니다. 이 아티클에서는 Policy에 대한 이야기를 하려고 합니다.
SPC에는 랜딩존에 적용되어 있는 기본 Policy에 더하여 데이터 주권(Sovereignty)을 강화한 SPC Policy와 산업별 특화된 Policy가 추가로 적용됩니다.
SPC Policy = 랜딩존 기본 Policy + SPC 공통 Policy + SPC 산업 특화 Policy (공공/금융/제조 등)
그렇다면 어떻게 이러한 SPC Policy가 식별되었을까요? 그 과정을 함께 살펴보시죠.
1) 검토 법률 조사
각종 법률 규제 및 보안 컴플라이언스를 준수하는 Secure Public Cloud 랜딩존을 만들기 위해 ISO27001, ISMS-P 등의 정보보호인증심사 뿐만 아니라 개인정보보호법, 전자금융감독규정 등 24개 법률을 조사하였습니다.
검토 대상 법률 (샘플)
2) 각 법률 조항과 Policy 매핑
검토한 법률 조항별로 요구사항을 세분화하고 그에 해당하는 Azure Policy를 매핑하였습니다. Policy는 고유한 UUID를 가지며 매핑 결과 총 82개의 Policy가 식별되었습니다.
법률 조항 - 정책(UUID) 매핑
3) UUID 기반으로 Policy 중복 제거
랜딩존에 적용되어 있는 Policy와 UUID 기반으로 중복 제거를 했습니다. 23개 Policy를 중복 제거하여 총 59개로 SPC Policy가 구성되었습니다.
- 기존 Custom 정책의 기반이 되는 Built-in 정책의 id를 확인하여 중복 체크 완료
- Policy Assign 과정에서 네이밍이 중복되는 정책 체크 완료
4) Policy 그룹화
관리 편의를 위해 SPC 산업 공통 Policy 59개를 하나의 Initiative로 그룹화 하였습니다.
|
Category |
Policy(Initiative) Name |
Policy 수 |
총 873개 |
|---|---|---|---|
|
SPC Policy |
KT SPC 관리 그룹에 적용하는 SPC용 정책 |
59개 |
59개 |
|
Initiative Policy(Policy Set) |
ISO 27001:2013 |
453개 |
814개 |
|
Microsoft Cloud Security Benchmark |
225개 |
||
|
Configure Microsoft Defender for Cloud Plans |
10개 |
||
|
Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule |
4개 |
||
|
Defender for Cloud Container and Server |
10개 |
||
|
Configure SQL VMs and Arc-enabled SQL Servers to install Microsoft Defender for SQL and AMA with a user-defined LA workspace |
8개 |
||
|
Configure Linux machines to run Azure Monitor Agent and associate them to a Data Collection Rule |
4개 |
||
|
공통 Policy |
KT 관리 그룹에 적용하는 공통 정책 |
100개 |
5) Bicep 코드 패키징
Policy가 한번에 배포될 수 있도록 개별 Policy와 Initiative에 대한 Definition, Assignment에 대한 Bicep IaC 코드를 개발하였습니다.
KT 랜딩존 SPC Policy 적용
이렇게 식별된 SPC Policy를 KT 관리 그룹 최상단에 적용하여 KT 랜딩존 = SPC 랜딩존이 되었습니다.
랜딩존 전체에 Policy를 적용하는 것은 영향도가 큰 작업이기 때문에, 아래와 같은 테스트와 검토 과정을 거쳐 적용하였습니다.
1) Policy 적용 테스트
SPC용 별도 관리그룹으로 분리하고, 해당 관리 그룹에 SPC Policy를 적용
2) Policy 파라미터 검토 및 수정
관리그룹 내 서비스(3종) 구축 과정에서 이슈가 있었던 정책들의 파라미터(audit/deny)를 검토하고, 필요한 경우 정책 예외 처리
3) 랜딩존 Policy 적용
랜딩존(KT 최상단 관리그룹)에 Policy를 적용
영향도 파악을 위해 Policy Effect를 Deny가 아닌 Audit으로 적용 (추후 로그 확인을 위함)
4) Deny로 파라미터 변경 가능한 Policy 검토
Effect = Deny로 변경 가능한 Policy에 대해서 Default Effect 파라미터 협의 (w/ MS, 보안단)
5) Non-compliant 리소스 설정 변경
개별 정책의 non-compliant 상태의 리소스들을 확인
해당 리소스 설정을 변경하여 compliant 상태 유지
6) Policy 파라미터 Audit → Deny 수정
식별된 Policy의 Effect 파라미터를 Deny로 수정하여 최종적으로 SPC Policy를 랜딩존에 적용
랜딩존 배포 자동화 시연 Story
SPC가 올해 KT 랜딩존에 설계/구축되는 동시에 B2B SPC 랜딩존도 설계/자동화 패키징이 진행되었습니다.
B2B SPC 랜딩존은 KT SPC 랜딩존을 기본으로 하여 관리그룹/RBAC/Policy/네트워크/보안에 대한 표준을 마련하였고, 이에 IaC 코드 자동화를 더해서 랜딩존 전체 및 서비스 배포 자동화를 구현하였습니다.
제가 맡았던 부분은 Policy, RBAC, 관리그룹, 네트워크/보안 공통영역 자동화였는데요, 이 중 Policy 코드 패키징 Story를 공유하려고 합니다.
Policy의 경우에는 정책 식별 - 중복 제거 - 정책 수 카운팅 - 코드 패키징이 동시에 이루어지다보니 하나의 파트에서 수정 사항이 발생하면 전체가 변경되어야 하는 상황이었습니다.
특히 중복 제거와 카운팅이 정말 어려웠는데요. SPC Policy 와 기존 적용된 Policy의 교집합을 찾아서 제거한다는게 벤 다이어그램으로 머릿속에 바로 그려질만큼 간단한 작업이 아닐까 생각했지만 800개가 넘는 Policy를 비교하는 것이 쉽지 않았습니다.
특히 UUID로 구분이 되지 않는 Custom-Policy의 경우에는 이름으로 찾아야 했고 심지어 Policy Assignment 과정에서 발견되기도 했습니다..
그래서 랜딩존 배포 자동화 시연 직전에도 코드가 계속 수정되는 상황이었습니다.
협업으로 극복
하지만! 저희는 성공적으로 시연을 마칠 수 있었습니다. 정말 힘들었지만 이 과정이 빠른 시일 내에 끝낼 수 있었던 건 협업 덕분이었습니다.
800개가 넘는 전체 policy를 협업하여 리스팅하고 크로스 체크하며 중복되는 policy를 확인하였고, 한 눈에 볼 수 있게 컨플루언스에 정리하여 관리하였습니다.
또한 2주동안 IaC 코드 개발을 위해 인도에서 전문가가 투입되어 계속해서 테스트하며 코드 패키징을 진행했습니다.
SPC 랜딩존 자동화 시연 전, 회의실에서 다 같이 모여 하루 종일 준비하던 모습이 기억에 남습니다. 어려운 일도 협업을 통해 해결할 수 있다는 것을 알게 된 프로젝트였습니다.