예외 하나의 대가
Landing Zone은 한 번 설계된 후 운영 중에 확장되는데, 바로 거기서 실제 이야기가 시작됩니다. 마감이 촉박한 첫 번째 프로젝트는 Policy Review가 스프린트보다 오래 걸릴 수 있다는 이유로 계층 구조 밖에 Subscription을 받습니다. 금요일 오후에 Contributor 권한으로 작업이 막혔던 외부 서비스 업체는 Management Group에서 Owner 권한을 받고, Go-live 이후에는 아무도 이를 떠올리지 않아 그 권한을 계속 유지합니다. Hub의 방화벽이 Spoke의 처리량을 제한하면, Spoke는 Hub를 우회해 직접 Peering을 구성합니다. 이러한 결정들은 각각의 시점에서 합리적이었고, 지금도 여전히 유효합니다.
그 결과는 구체적입니다. 계층 구조 밖에 있는 Subscription은 Policy를 상속받지 못하므로 Policy의 보호도 받지 못합니다. Management Group 수준의 Owner 권한은 그 아래의 모든 Subscription에 조용히 상속되며, 당시에는 존재하지도 않았던 Subscription에도 마찬가지입니다. 방화벽으로 향하는 경로가 없는 Peering은 여러분의 SOC가 볼 수 없는 네트워크 경로입니다. Azure Landing Zone Review는 Cloud Adoption Framework의 8가지 Design Area를 기준으로 설계 의도와 현재 상태를 겹쳐 보고, 편차를 발생 시점이 아닌 그 결과에 따라 정렬합니다.
Cloud Adoption Framework의 8가지 Design Area
Microsoft가 Landing Zone의 결정 사항을 8가지 Design Area로 구분한 이유는, 그렇지 않으면 대부분의 문제가 팀 간의 공백에 숨어들기 때문입니다. 네트워크 팀은 Hub를 구성하고, Identity 팀은 역할을 할당하며, Policy 예외를 승인한 사람은 어느 쪽 기록에도 남지 않습니다. 저희는 8가지 모두를 동일한 질문으로 검토합니다. 무엇이 계획되었고, 무엇이 구축되었으며, 그 차이에서 무엇이 따라오는가.
Azure Billing 및 Entra 테넌트
Enrollment, Billing 계층 구조, 그리고 모든 것이 올라가 있는 테넌트. 인수로 인해 생긴 두 번째 테넌트는 누군가가 라이선스, ID, 청구서를 통합해야 할 때까지는 거의 문제가 되지 않습니다.
Identity 및 Access Management
플랫폼 수준의 역할, Service Principal, PIM. Root Management Group의 Owner 권한은 이후에 생성되는 모든 Subscription에 조용히 상속됩니다.
Resource Organization
Management Group 계층 구조, Subscription 설계, 이름 및 태그. 잘못된 Management Group에 속한 워크로드는 잘못된 Policy를 상속받으며, 이는 감사가 시작될 때서야 드러납니다.
Network Topology 및 Connectivity
Hub-and-Spoke 또는 Virtual WAN, 하이브리드 연결, DNS, 방화벽, Private Endpoint. Hub를 우회한 Peering은 기술적으로는 깔끔하지만 SOC에게는 보이지 않습니다.
Security
Defender for Cloud, 암호화, Key Vault, 그리고 워크로드가 아닌 플랫폼에 존재하는 모든 요소. 일부 Subscription에만 활성화된 Defender 플랜은 정확히 그 범위만 보호합니다.
Management
모니터링, 로깅, 백업 및 복구. 누락된 Diagnostic Settings는 운영 중에는 드러나지 않고, 인시던트 발생 시 한 번도 기록되지 않은 로그가 필요할 때 비로소 문제가 됩니다.
Governance
Azure Policy, 이니셔티브, 예외 및 비용 관리. Exemption은 누군가가 만료일을 설정했을 때만 만료일이 존재합니다. 대부분은 그렇지 않습니다.
Platform Automation 및 DevOps
Infrastructure as Code, 파이프라인, Azure Verified Module. 포털을 통해 변경되는 플랫폼에는 두 가지 진실이 존재합니다. 리포지토리의 진실과 Azure의 진실. 유효한 것은 후자입니다.
진행 방식
- 팀 인터뷰팀 인터뷰저희는 툴이 아닌 플랫폼을 운영하는 사람들로부터 시작합니다. 아키텍처, 도구, 운영 프로세스, 전략. 이후 스캔에서 발견되는 대부분의 항목에는 배경이 있으며, 그 배경을 아는 사람만이 항목을 올바르게 평가할 수 있습니다. 의식적인 결정과 잊혀진 임시방편은 다릅니다.
- 환경 분석환경 분석그런 다음 툴링으로 환경을 읽어냅니다. Management Group, Policy 및 Exemption, 역할 할당, 네트워크 경로, Diagnostic Settings, 비용. 3년 전 기준이 아닌 현행 Cloud Adoption Framework를 기준으로 자동화된 방식으로 진행합니다.
- 발견 사항 우선순위화발견 사항 우선순위화툴이 편차를 찾아내고, 인터뷰가 그 맥락을 설명하며, 둘을 합쳐야 비로소 우선순위가 결정됩니다. 목록 상단에는 권한을 상속시키거나 로그를 차단하는 항목이, 하단에는 명명 규칙을 위반하는 항목이 위치합니다. 결과가 없는 발견 사항은 참고 사항일 뿐, 조치 대상이 아닙니다.
- 보고서 검토보고서 검토Design Area별 성숙도, 발견 사항, 권고사항이 담긴 보고서를 전달하고 함께 검토합니다. 백 가지 항목을 모두 파악하도록 하는 것이 목적이 아니라, 월요일에 어디서부터 시작할지 알 수 있도록 하는 것이 목적입니다.
우선순위가 담긴 보고서
여러분은 8가지 Design Area를 기준으로 Landing Zone을 평가한 보고서를 받게 됩니다. 영역별 성숙도, 우선순위가 정해진 발견 사항, 그리고 저희에게 묻지 않고도 플랫폼 팀이 실행할 수 있는 권고사항이 포함됩니다. 여기에 더해, 어떤 스캐너도 제공하지 못하는 구분이 있습니다. Framework에서 벗어난 항목이 의도된 결정이었는지, 아니면 실수였는지의 구분입니다. 이 보고서는 Landing Zone을 수년간 운영해온 플랫폼 팀과 IT 책임자를 대상으로 하며, 그동안 환경과 Framework가 어떻게 변화했는지 파악하고자 하는 분들에게 적합합니다. 마이그레이션을 앞두고 있다면 이전 작업보다 기반을 먼저 점검하는 것이 현명합니다. 외부 업체로부터 플랫폼을 인수받은 경우라면, 직접 구축하지 않은 사람의 시선으로 평가받는 것이 필요합니다. 구현은 포함되지 않습니다. 구현은 저희와 함께, 파트너와 함께, 또는 여러분의 팀과 함께 별도 프로젝트로 진행됩니다.
그 다음 단계
자주 받는 사전 질문
첫 번째 대화에서 나온 질문들을, 그 자리에서 답하는 방식 그대로 정리했습니다.
glueckkanja의 Landing Zone이 있어야 하나요?
아닙니다. Enterprise Scale 템플릿 기반이든, 다른 업체가 구축한 것이든, 포털에서 점진적으로 만들어진 것이든 어떤 Landing Zone이든 검토합니다. 기준은 Cloud Adoption Framework이며, 저희의 Azure Foundation이 아닙니다. 보고서 결과에 따라 Azure Foundation을 권장할 수 있지만, 그것은 선택지일 뿐 조건이 아닙니다.
Review와 Modul Azure der Preventive Services는 어떻게 다른가요?
던지는 질문이 다릅니다. Modul Azure는 공격자가 Subscription에서 제어 영역까지 어떻게 도달하는지를 묻고, 보안 강화 로드맵으로 마무리됩니다. Landing Zone Review는 플랫폼 전체가 제대로 작동하는지를 묻습니다. 조직 구조, 네트워크, Governance, 운영, 자동화, 비용. Security는 8가지 Design Area 중 하나일 뿐입니다. 둘 다 원한다면 Review부터 시작하는 것이 맞습니다. Review가 전체 지도를 제공하고, 모듈은 그 위에 경로를 그립니다.
어떤 권한이 필요한가요?
읽기 권한만 필요합니다. 분석을 위해서는 최상위 Management Group의 Reader 역할과 Cost Management 읽기 권한으로 충분합니다. 저희는 아무것도 변경하지 않으며, Review가 끝나면 접근 권한은 제거됩니다. Reader 권한만으로 Review를 진행할 수 있다는 점 자체가 이미 하나의 발견 사항입니다. 그렇지 않은 Landing Zone은 첫 번째 개선 과제를 스스로 드러낸 것입니다.
비용도 검토하나요?
예. Landing Zone에서 비용 문제는 Governance 발견 사항과 동일한 원인에서 비롯되는 경우가 많습니다. 태그가 없으면 청구서를 팀별로 귀속시킬 수 없고, 예산 알림이 없으면 잊혀진 VM은 월말에야 눈에 띄며, 아무도 관리하지 않는 예약은 아무도 쓰지 않는 용량에 비용을 지출합니다. 발견된 사항은 수치와 함께 보고서에 기재됩니다.
Review는 얼마나 걸리나요?
인터뷰와 분석은 며칠이면 충분합니다. 여러분 측에서 필요한 것은 인터뷰 일정 조율, 읽기 권한 승인, 그리고 보고서 검토 미팅뿐입니다. 더 많은 시간이 드는 부분은 그 이후 목록을 가지고 무엇을 할지이며, 그 결정은 여러분의 몫입니다.
구현도 포함되나요?
아닙니다. 의도적인 결정입니다. 자신의 후속 프로젝트를 우선시하는 Review는 Review가 아닙니다. 우선순위와 권고사항을 전달하고, 구현은 저희와 함께, 파트너와 함께, 또는 여러분의 팀과 함께 별도 프로젝트로 진행됩니다. Landing Zone을 새로 구축하고자 한다면 Azure Foundation에서 그 방법을 찾을 수 있습니다.
