Azure Firewall을 사용하는 경우

완료됨

Azure Firewall이 무엇이며 어떻게 작동하는지 확인했습니다. 이제 Azure Firewall 및 Azure Firewall Manager가 귀사에 적합한 선택인지 여부를 평가하는 데 유용한 몇 가지 기준이 필요합니다. 결정하는 데 도움이 되도록 다음과 같은 시나리오를 살펴보겠습니다.

  • 침입에 대해 네트워크를 보호하려고 합니다.
  • 사용자 오류로부터 네트워크를 보호하려고 합니다.
  • 비즈니스에 전자 상거래 또는 신용 카드 결제가 포함됩니다.
  • 스포크 간 연결을 구성하려고 합니다.
  • 들어오고 나가는 트래픽을 모니터링하려고 합니다.
  • 네트워크에 여러 방화벽이 필요합니다.
  • 계층형 방화벽 정책을 구현하려고 합니다.

Azure Firewall 및 Azure Firewall Manager를 평가하면서 Contoso가 이러한 몇 가지 시나리오에 직면하고 있다는 사실을 알게 되었습니다. 자세한 내용은 다음의 해당 섹션을 참조하세요.

침입에 대해 네트워크를 보호하려고 하는 경우

많은 악의적 행위자의 일반적인 목표는 네트워크를 침투하는 것입니다. 이러한 침입자는 네트워크 리소스를 사용하거나 중요한 데이터 또는 독점 소유 데이터를 검사하거나 훔치거나 삭제하려고 할 수 있습니다.

Azure Firewall은 이러한 침입을 방지하는 데 도움이 되도록 고안되었습니다. 예를 들어, 악의적인 해커가 네트워크 리소스에 대한 액세스를 요청하여 네트워크를 침투하려고 할 수 있습니다. Azure Firewall은 네트워크 패킷의 상태 저장 검사를 사용하여 이러한 요청의 컨텍스트를 검사합니다. 요청이 이전의 합법적인 활동에 대한 대응인 경우 방화벽에서 요청을 허용할 수 있습니다. 침투하려는 목적으로 요청이 전송되는 경우처럼 요청이 어디에서 왔는지 알 수 없는 경우 방화벽은 해당 요청을 거부합니다.

사용자 오류로부터 네트워크를 보호하려고 하는 경우

네트워크를 침투하거나 네트워크 컴퓨터에 맬웨어를 설치하는 가장 일반적인 방법은 네트워크 사용자가 메일 메시지의 링크를 클릭하도록 유도하는 것입니다. 이 링크는 사용자에게 맬웨어를 설치하거나 사용자가 네트워크 자격 증명을 입력하도록 유도하는 악의적인 해커 제어 웹 사이트로 사용자를 보냅니다.

Azure Firewall은 위협 인텔리전스를 통해 알려진 악의적인 도메인 및 IP 주소에 대한 액세스를 거부하여 이러한 공격을 방지합니다.

비즈니스에 전자 상거래 또는 신용 카드 결제가 포함되는 경우

비즈니스에 전자 상거래 구성 요소가 있거나 온라인 신용 카드 결제를 처리하나요? 그렇다면 귀사는 PCI DSS(결제 카드 업계의 데이터 보안 표준)을 준수해야 할 수 있습니다. PCI DSS는 PCI Security Standards Council에서 만들고 유지 관리하는 보안 표준 집합입니다. PCI 규정 준수를 위해 PCI DSS는 수십 개의 요구 사항을 나열합니다. 첫 번째 요구 사항은 다음과 같습니다.

  • 카드 소유자 데이터를 보호하도록 방화벽 구성을 설치 및 유지 관리합니다.

PCI DSS는 신뢰할 수 없는 네트워크 및 호스트의 모든 인바운드 및 아웃바운드 트래픽을 제한하는 방화벽 구성을 설정해야 한다고 지정합니다. 또한 방화벽은 결제 카드를 처리하는 데 필요한 프로토콜을 제외한 다른 모든 트래픽을 거부해야 합니다.

스포크 간 연결을 구성하려고 하는 경우

일반적인 허브 및 스포크 네트워크 토폴로지에는 다음과 같은 특성이 있습니다.

  • 중앙 연결 지점 역할을 하는 단일 가상 네트워크-’허브’
  • 허브에 피어링되는 하나 이상의 가상 네트워크-’스포크’ 이 토폴로지에서는 ExpressRoute 회로 또는 VPN Gateway를 통해 연결된 온-프레미스 네트워크도 스포크로 간주할 수 있습니다.

스포크 네트워크는 허브와 데이터를 교환할 수 있지만 스포크는 서로 직접 통신할 수 없습니다. 이러한 직접 연결은 필요할 수 있습니다. 예를 들어, 하나의 스포크 네트워크는 다른 스포크에 배포된 SQL Database의 정보를 필요로 하는 API(애플리케이션 프로그래밍 인터페이스)를 호스트할 수 있습니다.

한 가지 해결 방법은 스포크 네트워크를 서로 피어링하는 것입니다. 이러한 방식은 이와 같이 연결이 소수 있을 때는 잘 맞지만 연결 수가 증가하게 되면 너무 빠르게 커질 수 있습니다.

더 쉽고 안전한 솔루션은 Azure Firewall을 사용하여 스포크 간에 직접 연결을 설정하는 것입니다. 허브에 Azure Firewall 인스턴스를 먼저 배포하여 이 연결을 구현합니다. 그런 다음, 방화벽을 통과한 후 다른 스포크로 이동하도록 데이터를 특별히 라우팅하는 UDR(사용자 정의 경로)로 스포크 가상 네트워크를 구성합니다.

Azure Firewall을 통한 가상 머신과 SQL Database 간의 스포크 간 연결을 보여 주는 네트워크 다이어그램

들어오고 나가는 트래픽을 모니터링하려고 하는 경우

귀사에서는 인바운드 및 아웃바운드 네트워크 트래픽에 대한 상세 보고서를 분석하려고 할 수 있습니다. 규정 준수, 인터넷 사용에 대한 회사 정책 적용, 문제 해결 등을 비롯하여 이러한 보고서가 필요한 몇 가지 이유가 있습니다.

다음 네 가지 유형의 방화벽 작업에 대한 진단 로그를 유지하도록 Azure Firewall을 구성할 수 있습니다.

  • 애플리케이션 규칙
  • 네트워크 규칙
  • 위협 인텔리전스
  • DNS 프록시

예를 들어, 방화벽의 애플리케이션 규칙에 대한 로그에는 아웃바운드 요청에 대한 다음과 같은 항목이 포함될 수 있습니다.

  • 10.1.0.20:24352에서 somewebsite.com:443으로의 HTTPS 요청 작업: 허용 Rule Collection: collection100. 규칙: rule105

마찬가지로 방화벽의 애플리케이션 규칙에 대한 로그에는 인바운드 요청에 대한 다음과 같은 항목이 포함될 수 있습니다.

  • 73.121.236.17:12354에서 10.0.0.30:3389로의 TCP 요청 작업: Deny

진단 로깅을 사용하도록 설정하면 다음과 같은 방법으로 로그를 모니터링하고 분석할 수 있습니다.

  • 로그를 네이티브 JSON 형식으로 직접 검사할 수 있습니다.
  • Azure Monitor에서 로그를 검토할 수 있습니다.
  • Azure Firewall 통합 문서에서 로그를 검토하고 분석할 수 있습니다.

네트워크에 여러 방화벽이 필요한 경우

귀사의 Azure 공간이 여러 Azure 지역에 걸쳐 있는 경우 여러 인터넷 연결이 설정됩니다. 즉, 이러한 각 연결에 대해 방화벽 인스턴스를 배포해야 합니다. 이러한 방화벽은 별도로 구성하고 관리할 수 있지만 이렇게 하면 다음과 같은 여러 가지 문제가 발생합니다.

  • 여러 방화벽을 관리할 때는 많은 작업이 필요합니다.
  • 전역 규칙 및 설정 변경 내용을 모든 방화벽에 전파해야 합니다.
  • 모든 방화벽에서 일관성을 유지하는 것은 어렵습니다.

Azure Firewall Manager는 모든 Azure 지역 및 구독에 있는 모든 Azure Firewall 인스턴스에 대해 중앙 관리 인터페이스를 제공하여 이러한 문제를 해결합니다. 방화벽 정책을 만든 다음, 모든 방화벽에 적용하여 일관성을 유지할 수 있습니다. 정책에 대한 변경 내용은 모든 방화벽 인스턴스에 자동으로 전파됩니다.

계층형 방화벽 정책을 구현하려고 하는 경우

대부분의 중소기업에서는 어디에나 적합한 방화벽 정책을 사용할 수 있습니다. 즉, 중소기업은 네트워크의 모든 사용자와 리소스에 적용되는 단일 방화벽 정책을 만들 수 있습니다.

그러나 규모가 큰 회사의 경우 좀 더 미묘하고 자세한 방법이 필요합니다. 예를 들어 다음 두 가지 시나리오를 고려할 수 있습니다.

  • DevOps 상점에는 앱을 개발하기 위한 하나의 가상 네트워크, 앱을 준비하기 위한 또 다른 가상 네트워크 및 앱의 프로덕션 버전을 위한 세 번째 가상 네트워크가 있을 수 있습니다.
  • 대기업에는 데이터베이스 사용자, 엔지니어링 및 판매를 위한 별도의 팀이 있을 수 있습니다. 이러한 각 팀에는 별도의 가상 네트워크에서 실행되는 자체 애플리케이션 집합이 있습니다.

모든 항목에 공통적으로 적용되는 방화벽 규칙이 있지만 각 가상 네트워크의 사용자와 리소스에는 특정 방화벽 규칙이 필요합니다. 따라서 대기업에는 거의 항상 ‘계층형’ 방화벽 정책이 필요합니다. 계층형 방화벽 정책은 다음 두 가지 구성 요소로 구성됩니다.

  • 회사 전체에 적용해야 하는 규칙을 구현하는 단일 ‘기본 방화벽 정책’
  • 특정 앱, 팀 또는 서비스와 관련된 규칙을 구현하는 하나 이상의 ‘로컬 방화벽 정책’ 로컬 정책은 기본 방화벽 정책을 상속받은 다음, 기본 앱, 팀 또는 서비스와 관련된 규칙을 추가합니다.

Azure Firewall Manager를 사용하는 경우 기본 방화벽 정책을 설정한 후 기본 정책을 상속하고 기본 리소스용으로 고안된 특정 규칙을 구현하는 로컬 정책을 만들 수 있습니다.