이 시나리오를 너무 많이 봤습니다. 앱이 완성됩니다. 데모가 훌륭합니다. 그런 다음 보안 체크리스트가 나타납니다: 스토리지를 공용 인터넷에서 제거하고, VNet 내에서 실행하고, 파트너 허용 목록을 위한 아웃바운드 IP를 제공하고, 올바른 서브넷만 올바른 서비스와 통신한다는 것을 증명합니다.
이 시점에서 애플리케이션 모델과 인프라 모델이 유지 관리하기 어려운 방식으로 분리되기 시작합니다.
Aspire의 새로운 Azure 엔터프라이즈 네트워킹 지원은 이 문제를 직접적으로 해결합니다. AppHost에서 해당 네트워크를 사용하는 리소스 옆에 네트워크 모양을 설명합니다.
구성 요소
각 Azure 네트워킹 개념이 무엇을 위한 것인지 요약:
| 기능 | 사용 시기 | 중요한 이유 |
|---|---|---|
| 가상 네트워크 | 프라이빗 주소 공간이 필요할 때 | 서브넷, 프라이빗 엔드포인트 및 라우팅을 위한 네트워크 경계 |
| 서브넷 | VNet 내에서 워크로드를 분리해야 할 때 | 시스템의 각 부분이 자체 주소 범위와 정책 표면을 가짐 |
| 위임된 서브넷 | 플랫폼 서비스(예: ACA)가 서브넷을 관리해야 할 때 | 서비스가 VNet에 관리되는 인프라를 안전하게 배치할 수 있음 |
| NAT 게이트웨이 | 예측 가능한 아웃바운드 공용 IP가 필요할 때 | 허용 목록 및 감사를 위한 안정적인 주소 |
| 프라이빗 엔드포인트 | PaaS 리소스에 프라이빗하게 접근하고 싶을 때 | VNet 내에 해당 서비스의 프라이빗 IP를 배치하고 공용 노출 제거 |
| NSG | 서브넷 수준의 트래픽 규칙이 필요할 때 | 서브넷별 인바운드 및 아웃바운드 트래픽에 대한 명시적 허용/거부 |
AppHost에서 설명하기
여기서 핵심 변화는 시간이 지남에 따라 앱 모델에서 멀어지는 별도의 Bicep 파일이 아니라 해당 네트워크를 사용하는 리소스 옆에 네트워크를 모델링한다는 것입니다.
AppHost에서 다음을 수행할 수 있습니다:
AddVirtualNetwork()및AddSubnet()으로 VNet 및 서브넷 만들기- 안정적인 아웃바운드 IP를 위해 서브넷에 NAT 게이트웨이 연결
- 스토리지, Key Vault, SQL 및 기타 PaaS 서비스에 대한 프라이빗 엔드포인트 만들기
- 인바운드 및 아웃바운드 보안 규칙으로 NSG 정의
- 교차 리소스 정책을 위한 네트워크 보안 경계 구성
결과적으로 azd up을 실행하면 인프라가 앱 모델이 필요하다고 말하는 것과 일치합니다. 수동으로 유지 관리되는 템플릿이 말하는 것이 아닙니다.
실제 애플리케이션에 중요한 이유
Aspire에서 네트워크가 모델링되면 훨씬 쉬워지는 몇 가지:
Key Vault 및 스토리지를 위한 프라이빗 엔드포인트 — 해당 리소스에 WithPrivateEndpoint()를 설명하면 Aspire가 DNS 영역 구성 및 엔드포인트 연결을 처리합니다. 앱은 절대 변경되지 않습니다.
일관된 아웃바운드 IP — 관련 서브넷에 NAT 게이트웨이를 추가하면 앱의 모든 아웃바운드 요청이 알려진 안정적인 IP를 통해 이동합니다. 파트너가 허용 목록에 추가할 수 있습니다. 감사자가 추적할 수 있습니다.
코드에서 NSG 규칙 — 포털을 클릭하거나 Bicep 스니펫을 유지 관리하는 대신 보안 규칙이 보호하는 리소스 옆 AppHost에 존재합니다.
이것이 데모를 흥미롭게 만들지는 않지만 프로덕션 시스템을 유지 가능하게 만드는 통합의 종류입니다.
결론
프로젝트 라이프사이클 후반에 네트워크 보안이 나타나는 것은 처음부터 앱과 함께 모델링하면 해결된 문제입니다. Aspire의 엔터프라이즈 네트워킹 지원은 별도의 인프라 트랙 없이도 이를 가능하게 합니다.
원본 게시물의 전체 내용: Securing Azure apps with Aspire enterprise networking
