Azure Front Door를 사용하는 레거시 웹 응용 프로그램의 경우 TLS 언로드, WAF 등의 재작성 불필요 기능 없음

가상 컴퓨터에서 실행되는 웹 응용 프로그램이 하나 이상 있고, 다시 쓰기나 안전성을 실현할 시간이나 자원이 없습니다.Azure Front Door의 인프라를 활용하면 이러한 모든 기능과 더 많은 기능을 사용할 수 있습니다.
우리는 두 가지 맛을 탐색할 것이다.
1) 전면 도어가 공용 IP를 통해 VM에 요청 전달
2) 사전 도어 고급형 버전(기사 작성 시 미리 보기)은 개인 소스가 있어 사용자의 VNET에 요청을 직접 전달할 수 있으며 기기를 공공 인터넷에 노출하지 않아도 됩니다.

Azure 전면 도어 요청을 VM의 공용 IP로 전달

이 경우 Azure Front Door 백엔드를 VM에 연결된 공용 IP로 직접 설정할 수 있습니다.
다음과 같은 이점이 있습니다.

Azure Front Door classic(GA)

와 함께 사용

보다 간편한 인프라 및 구성

이런 방법의 단점은 그다지 안전하지 않다는 것이다.NSG를 사용하는 VM(서브넷/NIC 레벨)에서는 Azure 전면 도어 서비스 태그로부터의 트래픽만 허용함으로써 인터넷으로부터의 트래픽이 VM에 맞지 않도록 할 수 있습니다. 그러면 다른 모든 소스가 차단되고 두 개의 트랩이 존재합니다.
1) DDoS 공격으로 VM 액세스가 차단될 수 있음(VNET에 표준 DDoS 보호를 추가하여 완화할 수 있음)
2) 경험이 풍부하고 지식이 풍부한 공격자(내부 에이전트일 수도 있음)는 가상 기기의 공공 IP를 성공적으로 찾았다. 자신의 앞문 실례를 생성하고 이를 당신의 공공 IP를 가리키며 기존의 앞문 안전을 돌아갈 수 있다.
이러한 위협은 여전히 완화될 수 있지만, 우리는 본문에서 이 점을 탐구하지 않을 것이다.단지 고위층에서 공유하기 위해서:
전송 요청X-Azure-FDID에 추가된 헤더(고유 ID)를 확인하여 전송 데이터를 필터할 수 있습니다.그것과 서비스 라벨을 사용하면 교통이 앞문에서만 오는 것을 확보할 수 있다.
애플리케이션을 변경하지 않으려면 애플리케이션 Gateway의 인스턴스를 추가하여 트래픽을 VM으로 전송하기 전에 애플리케이션을 필터링할 수 있습니다.
만약 위협 모델링 연습을 하고 이 위험이 여전히 완화되어야 한다고 확신한다면 아래의 두 번째 옵션을 선택할 수 있습니다.

Azure Front Door Premium은 전용 링크를 통해 가상 시스템의 내부 IP로 요청을 전달합니다.

이런 방법은 당신의 안전 태세를 현저하게 개선시켰지만 원가 증가(private Origination support는 Front Door Premium이 필요), 구조와 설정이 약간 복잡하다(예를 들어 표준 부하 균형기와 같은 추가 구성 요소가 필요하면 원가와 전용 링크도 증가할 수 있다).
이 방법을 사용하면 공공 IP에서 완전히 벗어나 앞문 실례를 VNET에 직접 투사하여 DDoS와 앞문 납치의 공격 방향을 제거할 수 있습니다.
IP가 없으면 공격자는 현관문 옆에 사용할 수 있는 단점이 없고 현관문은 강화된 안전성을 가지며 WAF(웹 응용 프로그램 방화벽)를 사용하여 설정할 수 있어 몇 가지 안전 규칙을 통해 가장 흔히 볼 수 있는 공격을 줄일 수 있다.
이점:

VM에 공통 종결점이 없음

DDoS 위험 없음

앞문 납치 공격 없음

이 두 가지 옵션 모두 응용 프로그램이 프로그램을 변경하지 않고 고급 안전성을 이용할 수 있도록 한다.당신은 다음과 같은 것을 얻을 수 있습니다.

사용자 정의 도메인

에서 Azure Front Door를 사용하여 무료 TLS 인증서 제공

WAF 기능(OWASP 일반 공격 등)

동적장지 가속도

HTTP/2 활성화

여러 애플리케이션 인스턴스

가 있는 경우 로드 밸런싱을 갖춘 글로벌 HA

경로 기반 라우팅의 여러 인스턴스 사용

이제 이것을 좋아하는 척하면서 Azure Front Door 뒤에 보호해야 할 애플리케이션이 여러 개 있으며 이러한 애플리케이션 앞에 도메인을 사용하고자 합니다.

mydomain.com/app1
mydomain.com/app2
...

URL 세그먼트에 따라 모든 트래픽을 백엔드로 리디렉션하는 라우팅 규칙을 쉽게 설정할 수 있습니다.

전면 도어에 여러 개의 백엔드 풀을 설치하고 라우팅 규칙을 작성하여 트래픽을 백엔드 1로 전달합니다.

다시 한 번 웹 응용 프로그램을 변경하지 않으려는 경우 규칙을 사용하여 URL을 다시 작성하여 전달/webapp1/을 피하고 URL의 나머지 부분만 보존할 수 있습니다.

그래서 너의 응용 프로그램은 앞문을 알 필요가 없다.
만약 응용 프로그램이 사용자를 /webapp1/ 단점으로 바꾸면 어떻게 해야 합니까?
응용 프로그램이 /* 또는 /api/dosomething 를 호출했다고 가정하면 /login 보류되지 않기 때문에 앞문에서 데이터를 어떻게 인도하는지 알 수 없습니다.
다시 한 번 말하지만, 우리는 응용 프로그램을 변경할 필요가 없는 순수한 기초 구조 해결 방안을 가질 수 있다.
첫 번째 호출/webapp1에서 Azure Front Door는 응답을 변경하고 새로운 제목 값을 추가할 수 있다는 생각이다.이 헤드는 /webapp1 헤드가 되고 설정Set-Cookie 백엔드의 유일한 값이 될 수 있다.다음 호출에서 브라우저는 쿠키를 포함하고 앞문 규칙 엔진은 되돌아오는 web app 1 헤더의 내용에 따라 루트 설정을 덮어쓰고 Cookie 데이터를 /*로 전송할 수 있습니다.다음 구성을 참조하십시오.

이것은 초기 호출 시 쿠키를 올바른 백엔드로 설정합니다. 전체 헤더 값은 다음과 같습니다./webappX/*이것은 경로를 지정해야 합니다. 생략하면 쿠키가 BACKEND=backendIdentified; Domain=mydomain.com; Path=/ 특정하고 mydomain.com/webapp1/* 에 적용되지 않는다고 가정합니다.
현재, 호출 mydomain.com/* 시 행동의 규칙을 덮어씁니다.

이제 규칙 엔진 규칙을 루트 설정에 추가해야 합니다. 완성됩니다.
쿠키가 존재하지 않고 직접 요청이 있으면 오류 페이지 백엔드를 설정할 수 있습니다.
등등 인프라 시설에 대한 간단한 변경만 하면 무료 TLS와 WAF 등을 남겨진 웹 응용 프로그램에 틈새 없이 추가할 수 있고 코드를 한 줄 바꾸지 않아도 된다.