데모 · 거버넌스 면역 스토리지 — Private Endpoint

이 문서는 "클라우드 거버넌스 정책이 내 스토리지를 자동으로 잠가버려도, 자동화 잡이 계속 동작하게 만드는 법" 을 하나의 Azure 아키텍처 사례로 보고, 어떤 서비스를 어떻게 조합했는지, 왜 그렇게 설계했는지를 직접 구축하려는 엔지니어 관점에서 설명합니다. (기준일: 2026-06-16 · 리전: East US 2 · 대상: moontaeyang.com의 두 디지스트 에이전트)

🎯 이 데모가 보여주는 것: 많은 대기업/규제 환경에는 중앙 거버넌스 자동화가 돌면서 "스토리지 공개 접근 차단(publicNetworkAccess=Disabled)" 같은 보안 베이스라인을 사람 몰래 주기적으로 강제합니다. 우리가 직접 켜 놔도 몇 분~하루 만에 다시 꺼집니다. 이 환경에서 공개 접근에 의존하던 자동화 잡은 어느 날 갑자기 깨집니다. 해법은 싸우는 게 아니라 사설 경로(Private Endpoint)로 우회하는 것 — 정책과 공존하면서도 잡은 끊기지 않게 만드는 설계입니다.

한눈에 보기

문제: 중앙 거버넌스(MCAPSGov-AutomationApp)가 스토리지의 publicNetworkAccess를 주기적으로 Disabled로 되돌림 → 공개 경로로 blob을 읽고 쓰던 Container Apps Job이 AuthorizationFailure로 실패.
핵심 통찰: pna=Disabled는 공개 인터넷만 막고, Private Endpoint(사설 IP) 트래픽은 항상 허용합니다. 그래서 잡을 VNet 안에 넣고 스토리지에 사설 통로(PE) 를 뚫으면, 정책이 공개를 잠가도 잡은 멀쩡합니다.
공개 사용자에게는 영향 0: 사이트의 공개 서빙은 스토리지가 아니라 Static Web Apps(moontaeyang.com) 가 담당합니다. 스토리지는 "잡이 읽고 쓰는 창고"일 뿐이라, 창고 문을 잠가도 손님(방문자)은 영향이 없습니다.
숨은 함정: 두 잡이 서로의 창고를 읽어 전체 포털을 재조립합니다 → 한쪽만 잠그면 상대가 깨집니다. 그래서 두 VNet을 Peering + DNS 교차 등록해 서로의 창고에도 사설로 접근하게 했습니다.

핵심 키워드: Private Endpoint · VNet 주입형 Container Apps · Private DNS · VNet Peering · Managed Identity(키리스) · 정책과의 공존

비즈니스 관점 — 왜 중요한가

운영 안정성: "어제까지 잘 되던 자동화가 오늘 아무도 안 건드렸는데 깨졌다"는 가장 비싼 장애입니다. 원인이 보이지 않는 정책 집행이라 디버깅에 며칠이 날아갑니다. PE 설계는 이 클래스의 장애를 구조적으로 제거합니다.
보안과 생산성의 양립: 보안팀의 "공개 접근 차단" 요구를 거스르지 않으면서(오히려 더 강한 사설 격리), 개발팀의 자동화는 그대로 돌아갑니다. 정책과 싸우는 대신 정책이 원하는 모습(공개 차단)으로 수렴시킵니다.
규제/데이터 거주: 금융·공공·반도체 등에서 "데이터는 사설 네트워크 안에서만 접근" 요건이 흔합니다. 이 패턴이 그 요건을 만족시키는 표준 빌딩블록입니다(데이터플레인이 인터넷에 노출되지 않음).

아키텍처

  [공개 사용자]                         ※ 스토리지 공개 접근(pna)이 꺼져도 영향 없음
      │ HTTPS
      ▼
  Azure Static Web Apps  ──  moontaeyang.com  (engit-daily · azure-daily 섹션)
      ▲                                   공개 서빙은 SWA가 전담
      │ swa deploy(아웃바운드)
      │
  ┌─────────────────────────── rg-english-daily ───────────────────────────┐
  │  VNet 10.60.0.0/16                                                       │
  │   ├ snet-aca /23 (위임: Microsoft.App/environments)                      │
  │   │    └ Container Apps Env (VNet 주입형, 워크로드 프로파일)              │
  │   │         └ engitdaily-job ── UAMI(키리스) ──┐                          │
  │   └ snet-pe /24                                 │ blob R/W                │
  │        └ Private Endpoint(blob) 10.60.2.4 ◀─────┘                         │
  │             │ 사설 통로                                                   │
  │             ▼                                                             │
  │        Storage engitdailyst…  (pna=Disabled 여도 PE는 통과)               │
  │   Private DNS: privatelink.blob.core.windows.net                         │
  │        engitdailyst… → 10.60.2.4   (+ azwhatsnewst… → 10.61.2.4 교차등록) │
  └──────────────────────────────┬──────────────────────────────────────────┘
                                  │  VNet Peering (양방향 Connected)
  ┌──────────────────────────────┴──── rg-azwhatsnew ───────────────────────┐
  │  VNet 10.61.0.0/16  (snet-aca /23, snet-pe /24)                          │
  │    Container Apps Env(VNet 주입형) └ azwhatsnew-job ─ UAMI ─ PE 10.61.2.4 │
  │    Storage azwhatsnewst…   ·   Private DNS(상동, engit 레코드도 교차등록)  │
  └─────────────────────────────────────────────────────────────────────────┘

  거버넌스(MCAPSGov-AutomationApp): 두 스토리지의 pna를 주기적으로 Disabled로 강제 → 그래도 잡은 PE로 동작

구성 요소와 설계 결정

1) Container Apps 환경을 "VNet 주입형"으로 — 재생성이 불가피한 이유

PE를 쓰려면 클라이언트(잡)가 VNet 안에 있어야 합니다. 그래야 스토리지 이름이 PE의 사설 IP로 해석됩니다.
함정: 기존 환경은 Consumption 전용(VNet 미통합) 이었고, 기존 ACA 환경에는 나중에 VNet을 붙일 수 없습니다. VNet은 환경 생성 시점에만 지정 가능 → 환경을 새로 만들고 잡을 옮긴 뒤 기존 환경을 삭제해야 합니다.
구현: bicep caeName을 …-caev2-…로 바꿔 신규 생성(워크로드 프로파일 + vnetConfiguration.infrastructureSubnetId). environmentId는 잡의 불변 속성이라, 재배포 전에 az containerapp job delete로 잡을 먼저 지워야 충돌이 없습니다.
UAMI(사용자 할당 관리 ID) 재사용 → 환경을 새로 만들어도 역할(Storage Blob Data Contributor 등)을 다시 부여할 필요가 없습니다. (키리스 유지)

2) Storage Private Endpoint(blob) + Private DNS

스토리지에 Microsoft.Network/privateEndpoints(groupIds=blob)를 snet-pe에 생성.
privatelink.blob.core.windows.net Private DNS zone + VNet 링크 + dnsZoneGroup → PE가 A레코드를 자동 등록.
결과: VNet 안에서 engitdailyst….blob.core.windows.net → 10.60.2.4(사설) 로 해석 → pna=Disabled여도 통과.
잡은 blob 컨테이너 URL로 읽기·쓰기하므로 blob 서브리소스 하나면 충분합니다(정적 웹 $web도 blob 엔드포인트 경유).

3) 교차 의존성 — 이 데모의 가장 중요한 교훈

포털 클로버링(서로 덮어쓰기) 방지를 위해 각 잡이 전체 포털을 재조립합니다. 즉 engit 잡이 azure-daily의 창고를, azwn 잡이 engit의 창고를 읽습니다.
그래서 한쪽 스토리지만 잠그면 상대 잡의 미러링이 깨집니다. 둘 다 잠그려면 서로의 창고에도 사설 접근이 필요: 1. VNet Peering(양방향, Connected) — 다른 VNet의 PE 사설 IP로 패킷이 라우팅되게. 2. DNS 교차 등록 — 한 VNet은 같은 이름의 zone에 1개만 링크되므로, 각 zone에 양쪽 스토리지 A레코드를 모두 넣음 (engit zone += azwhatsnewst…→10.61.2.4, azwn zone += engitdailyst…→10.60.2.4).
대안과 기각 이유: ① 단일 공유 VNet에 두 환경 주입(교차 RG 결합이 커짐) ② 공개 SWA에서 상대 섹션을 HTTP로 가져오기(이미 배포된 내용에 의존해 깨지기 쉬움). → Peering + 교차 DNS가 각 에이전트의 자기완결성을 유지하면서 가장 견고.

4) 공개 서빙은 SWA가 분리 — 창고를 잠가도 손님은 무관

pna=Disabled가 되면 스토리지 정적 웹 엔드포인트(z##.web.core.windows.net)는 404가 됩니다. 하지만 방문자는 Static Web Apps(moontaeyang.com) 로 들어오므로 공개 사이트는 24/7 정상.
덕분에 "스토리지 잠금"이라는 보안 요구와 "사이트는 살아 있어야 함"이 충돌 없이 양립합니다.
배포 스크립트의 --static-website 단계는 pna=Disabled에서 데이터플레인 호출이 실패하므로 || echo skip으로 방어.

검증 (실제로 잠그고 돌려봄)

두 스토리지를 모두 publicNetworkAccess=Disabled + defaultAction=Deny로 잠근 상태에서 양쪽 잡 실행:

확인 항목	결과
engit 잡 / azwn 잡	둘 다 Succeeded
자기 blob 쓰기	`Blob 업로드 완료 …` ✅
교차 미러(상대 창고 읽기)	`섹션 미러링 engit-daily:4 / azure-daily:8` ✅ (PE 경유)
인증 오류	0건
라이브 사이트	moontaeyang.com `/`·`/engit-daily/`·`/azure-daily/` 모두 200
알림	텔레그램 200

→ 정책이 공개를 잠근 steady-state에서도 자동화가 끊기지 않음을 실측으로 확인.

비용 / 트레이드오프

항목	값
Private Endpoint	2개 ≈ 월 $15 + 데이터 처리 소액
Private DNS / VNet / Peering	사실상 무료(동일 리전 peering, 소액 쿼리)
환경 재생성	일회성 노력(다운타임은 cron 사이 짧게)

vs A안(런타임 self-heal): 잡 시작 시 pna=Enabled로 되돌리는 방법은 더 싸고 인프라가 없지만, 정책과 계속 "밀당"하며 잠깐씩 공개가 열립니다. B안(PE) 은 공개를 영원히 닫은 채 동작 → 보안상 더 깨끗하고, 규제 환경의 "데이터플레인 비노출" 요건을 만족합니다.
거버넌스 내성: PE는 Microsoft.Network/privateEndpoints라 거버넌스의 storage/NSG 재작성 대상과 별개이고, pna=Disabled가 PE를 막지 않으므로 지속적으로 안전.

직접 만들 때 체크리스트

스토리지가 데이터플레인(잡 R/W) 용인지, 공개 서빙용인지 분리한다(서빙은 SWA/CDN로).
잡을 VNet 주입형 Container Apps 환경에 올린다(기존 환경은 재생성 필요, 잡 environmentId 불변).
UAMI를 재사용해 키리스 + 역할 재부여 최소화.
스토리지에 PE(blob) + privatelink.blob.core.windows.net Private DNS.
여러 잡이 서로의 스토리지를 읽는다면 → VNet Peering + 각 zone에 모든 스토리지 A레코드 교차 등록.
배포 스크립트의 데이터플레인 호출(--static-website 등)은 pna=Disabled 내성 처리.
실제로 잠그고(--public-network-access Disabled) 잡을 돌려 steady-state를 검증한다.

참고 코드 / 위치

인프라(IaC): agents/english-it-daily/infra/main.bicep, agents/azure-whats-new-digest/infra/main.bicep (VNet·PE·Private DNS·VNet 주입형 환경)
배포: 각 agents/*/deploy.sh (정적 웹 단계 pna 내성)
거버넌스 배경: reference/mcaps-governance-체크리스트.md (§3 스토리지 pna)
상세 노하우: playbook/CHANGELOG.md 2026-06-16

← 데모 목록 학습 포털 홈