Azure Integration Services 랜딩 존 가속기 보안 고려 사항
좋은 보안은 모든 Azure 애플리케이션의 초석입니다. Azure Integration Services는 애플리케이션을 구성하는 리소스가 많고 각 리소스에 고유한 보안 고려 사항이 있으므로 특정 문제에 직면합니다. 각 서비스의 특정 고려 사항을 이해하려면 다음 보안 기준을 참조하세요.
디자인 고려 사항
보안 모델을 디자인할 때 디자인 타임 보안과 런타임 보안이라는 두 가지 디자인 영역이 있습니다.
디자인 타임 보안 에는 Azure Portal 또는 관리 API를 통해 Azure 리소스의 관리 및 생성에 대한 액세스가 포함됩니다. Azure 내에서 Microsoft Entra ID 및 RBAC(역할 기반 액세스 제어)를 사용하여 이를 달성합니다.
런타임 보안 에는 애플리케이션 흐름 중에 엔드포인트 및 리소스에 대한 액세스(예: 논리 앱을 호출하는 사용자 인증 및 권한 부여) 또는 API Management의 API 작업이 포함됩니다.
필요한 경우 초기에 결정합니다.
프라이빗 클라우드 - 모든 리소스는 VNet에 상주하며 공용 인터넷에 액세스하거나 공용 인터넷에서 액세스할 수 없는 프라이빗 주소 지정만 사용하며 VPN 또는 ExpressRoute를 통해 온-프레미스 리소스에서 사용할 수 있습니다.
퍼블릭 클라우드 - 퍼블릭 인터넷의 액세스를 제한하기 위해 잠겨 있지만 모든 공용 리소스는 공용 인터넷에 액세스할 수 있습니다.
하이브리드 - 일부 리소스는 프라이빗이며 일부는 공용입니다.
선택하는 작업은 애플리케이션에 대해 구현할 수 있는 보안 양과 함께 리소스의 비용에 모두 영향을 줍니다.
일반적인 보안 고려 사항은 다음과 같습니다.
Azure 서비스를 사용하여 수신 및 송신 트래픽을 보호합니다.
Microsoft Entra ID 및 OAuth 2.0을 사용하여 인증을 관리합니다.
Azure Policy를 사용하여 거버넌스 정책 적용
리소스에 대한 액세스 잠금(액세스 제어).
전송 중 및 미사용 데이터 암호화
리소스에 액세스하려는 모든 시도를 로깅합니다.
리소스에 대한 액세스 감사
디자인 권장 사항
네트워크 디자인 권장 사항
액세스 가능한 엔드포인트 앞에 WAF(웹 애플리케이션 방화벽)가 있는 Application Gateway(Azure 애플리케이션 Gateway 또는 Azure Front Door)의 사용을 살펴보세요. 이렇게 하면 데이터의 자동 암호화에 도움이 되며 엔드포인트를 보다 쉽게 모니터링하고 구성할 수 있습니다.
Front Door는 웹 애플리케이션을 위해 전역 부하 분산 및 사이트 가속 서비스를 제공하는 애플리케이션 배달 네트워크입니다. Front Door는 SSL 오프로드, 경로 기반 라우팅, 빠른 장애 조치(failover) 및 캐싱과 같은 계층 7 기능을 제공하여 애플리케이션의 성능과 가용성을 개선합니다.
Traffic 관리자는 고가용성과 응답성을 제공하는 동시에 전 세계 Azure 지역의 서비스에 트래픽을 최적으로 배포할 수 있는 DNS 기반 트래픽 부하 분산 장치입니다. Traffic 관리자는 DNS 기반 부하 분산 서비스이므로 도메인 수준에서만 부하를 분산합니다. 이러한 이유로 DNS 캐싱과 DNS TTL을 준수하지 않는 시스템에 대한 일반적인 문제로 인해 Front Door만큼 빠르게 장애 조치(failover)할 수 없습니다.
애플리케이션 게이트웨이는 다양한 계층 7 부하 분산 기능을 갖춘 관리되는 애플리케이션 배달 컨트롤러를 제공합니다. 애플리케이션 게이트웨이를 사용하면 CPU 집약적인 SSL 종료를 게이트웨이로 오프로드하여 웹 팜 생산성을 최적화할 수 있습니다.
Azure Load Balancer는 모든 UDP 및 TCP 프로토콜에 대한 고성능, 초저 대기 시간의 계층 4 인바운드 및 아웃바운드 부하 분산 서비스입니다. 부하 분산 장치는 초당 수백만 개의 요청을 처리합니다. 부하 분산 장치는 영역 중복이므로 가용성 영역 에서 고가용성을 보장합니다.
VNet 통합을 사용하여 Azure 프라이빗 링크 및 프라이빗 엔드포인트를 사용하는 격리된 서브넷에 배치하여 통합 서비스 리소스에 대한 네트워크 격리를 구현합니다. 이 디자인 지침에 대한 검토는 이 시리즈의 네트워크 토폴로지 및 연결 문서를 참조하세요.
Azure Firewall을 사용하여 송신 트래픽 보호
IP 필터링을 사용하여 알려진 네트워크 주소에서만 액세스할 수 있도록 엔드포인트를 잠급니다(VNet에 통합되지 않은 논리 앱에 적용 가능).
공개적으로 사용할 수 있는 리소스가 있는 경우 DNS 난독화를 사용하여 공격자를 억제합니다. 난독 처리는 사용자 지정 do기본 이름 또는 리소스의 용도 또는 소유자를 표시하지 않는 특정 Azure 리소스 이름을 의미합니다.
암호화 디자인 권장 사항
예를 들어 Azure Storage 또는 Azure SQL Server에 데이터를 저장할 때는 항상 미사용 데이터 암호화를 사용하도록 설정합니다. 이상적으로는 서비스 및 제한된 수의 관리자만 데이터에 대한 액세스를 잠급니다. 로그 데이터에도 적용됩니다. 자세한 내용은 미사용 Azure 데이터 암호화 및 Azure 암호화 개요를 참조하세요.
리소스 간에 데이터를 전송할 때는 항상 전송 중 암호화(예: TLS 트래픽)를 사용합니다. 암호화되지 않은 채널을 통해 데이터를 보내지 않습니다.
TLS 프로토콜을 사용하는 경우 항상 TLS 1.2를 사용합니다.
Azure Key Vault에 비밀을 유지한 다음, 이를 앱 설정(Functions, Logic Apps), 명명된 값(API Management) 또는 구성 항목(앱 구성)에 연결합니다.
환경에서 사용 중인 모든 키가 위험 키를 사용하는 공격을 방지하기 위해 정기적으로 회전되도록 키 회전 정책을 구현합니다.
논리 앱의 경우 난독화를 사용하여 실행 기록에서 데이터를 보호합니다.
인증 및 액세스 디자인 권장 사항
액세스 권한을 할당할 때 항상 최소 권한 원칙을 따릅니다. ID에 필요한 최소 권한을 부여합니다. 경우에 따라 사용자 지정 Microsoft Entra 역할을 만드는 작업이 포함됩니다. 필요한 최소한의 권한이 있는 기본 제공 역할이 없는 경우 이러한 권한만 사용하여 사용자 지정 역할을 만드는 것이 좋습니다.
가능하면 리소스가 서비스에 액세스해야 하는 경우 항상 관리 ID를 사용합니다. 예를 들어 논리 앱 워크플로가 비밀을 검색하기 위해 Key Vault에 액세스해야 하는 경우 논리 앱의 관리 ID를 사용하여 이 작업을 수행합니다. 관리 ID는 Azure가 사용자를 대신하여 ID를 관리하므로 리소스에 액세스하기 위한 보다 안전하고 관리하기 쉬운 메커니즘을 제공합니다.
리소스 엔드포인트 간의 인증 메커니즘으로 OAuth 2.0을 사용합니다.
Logic Apps 또는 Functions에서 모든 외부 호출자가 OAuth ID(일반적으로 Microsoft Entra ID이지만 모든 ID 공급자일 수 있음)를 사용해야 하는 간편한 인증을 사용하도록 설정합니다.
API Management에서 jwt-validation 정책 요소를 사용하여 엔드포인트에 연결하기 위한 OAuth 흐름을 요구합니다.
Azure Storage 및 Key Vault에서 액세스 정책을 설정하여 특정 ID에 대한 액세스를 제한합니다.
거버넌스 디자인 권장 사항
Azure Policy를 적극적으로 사용하여 보안 문제 또는 결함을 찾습니다. 예를 들어 IP 필터링이 없는 엔드포인트입니다.
사용 가능한 경우 클라우드용 Microsoft Defender 사용하여 리소스를 검사하고 잠재적인 약점을 식별합니다.
정기적으로 감사 로그(자동화된 도구 사용)를 검토하여 보안 공격 및 리소스에 대한 무단 액세스를 모두 식별합니다.
침투 테스트를 사용하여 보안 디자인의 약점을 파악하는 것이 좋습니다.
자동화된 배포 프로세스를 사용하여 보안을 구성합니다. 가능한 경우 Terraform과 함께 Azure DevOps와 같은 CI/CD 파이프라인을 사용하여 리소스를 배포할 뿐만 아니라 보안을 구성합니다. 이렇게 하면 리소스가 배포될 때마다 자동으로 보호됩니다.
다음 단계
중요한 디자인 영역을 검토하여 아키텍처에 대한 전체 고려 사항 및 권장 사항을 확인합니다.