Click on the Category button to get more articles regarding that product.
Azure Application Proxy (Die Eierlegende kostenlose Woll-Milch-Sau um on-premises Server extern erreichbar zu machen)
Was hört man an M365/Azure Schulungen Schönes?
Wieso macht ihr alles so kompliziert? Publiziert doch Eure in-house Server ganz einfach und schnell über einen Azure Application Proxy? Dann braucht ihr all die teure Hardware nicht mehr. Es ist kostenlos bei den meisten MS licence Suites dabei. Zwei, drei Klicks und der interne Intranet-Server steht sicher im Web. Keine DMZ Vmware Cluster, kein DMZ Veeam Server, Keine Segmentation FW keine teuren RSA FMS Lizenzen bei uns ist alles dabei!
Jahrelange sichere und stabile Konzepte sowie Strategien werden plötzlich in Frage gestellt. Dann gab es noch die Citrix Access Gateway Lücken im November 2022 und Juli 2023. Der einte oder andere fängt an zu Grübeln. Das gab es alles schon früher nur redete keiner davon und meist wussten auch niemand davon.
Das liest man über Azure Application Proxy:
- Einfach zu bedienen. Benutzer können auf die On-Premises-Anwendungen auf die gleiche Weise zugreifen, wie sie Microsoft 365 und andere SaaS-Anwendungen, die mit Azure AD integriert sind, nutzen.
- Sicher. On-Premises-Anwendungen können Azure’s Autorisierungssteuerungen und Sicherheitsanalysen nutzen, einschließlich bedingtem Zugriff und MFA (Multi-Faktor-Authentifizierung). Außerdem erfordert Application Proxy nicht, dass Sie eingehende Verbindungen über Ihre Firewall oder VPN öffnen.
- Kosteneffizient. Um Application Proxy zu nutzen, müssen Sie die Netzwerkinfrastruktur nicht ändern oder zusätzliche Geräte in Ihrer On-Premises-Umgebung installieren.
Man muss nur folgendes beachten:
Best Practices für Azure Application Proxy:
1. Installieren Sie den Connector-Server physisch in der Nähe der Anwendungsserver, um die Leistung zwischen dem Connector und der Anwendung zu optimieren.
2. Der Connector-Server und die Webanwendungsserver sollten sich im selben Active Directory-Domäne befinden oder sich über vertrauenswürdige Domänen erstrecken.
3. Installieren Sie mehrere Connector-Server lokal, um einen einzelnen Ausfallpunkt zu vermeiden.
4. Konfigurieren Sie FQDN (vollqualifizierter Domänenname) und DNS-Einträge intern und verwenden Sie keine IP-Adressen.
5. Stellen Sie sicher, dass Ihre Connector-Server uneingeschränkten Internetzugang haben und das Microsoft-Netzwerk erreichen können.
6. Verwenden Sie bedingten Zugriff, um den Zugriff auf Ihre Umgebung abzusichern.
7. Konfigurieren Sie SSO (Single Sign-On), um die Benutzererfahrung zu verbessern.
MS Links:
Alles Cloudy? Alles Ersetzen?
Was ich persönlich davon halte:
- Für gelegentlichen Zugriff auf KMU-On-Premises-Server, die ich ins Web stellen möchte, ohne komplexe DMZ-Architektur intern: OK Jederzeit (Ticket, Zugang zur Abacus Zeiterfassung, Service Portal, Intranet, irgendetwas Kleines: Super)
-
Für Unternehmen mit über 1’000+ MA, die Hauptanwendungen nutzen, landen wir dort, wo grosse Unternehmen seit Jahren mit WAN zwischen Standorten zu kämpfen haben: LATENZ / SESSION TTL Einstellungen usw. In der Regel setzte man dann im Enterprise Bereich WAN-Optimizer ein auf beiden Seiten welche jeweils den Preis eines Autos hatten.
https://www.gartner.com/reviews/market/wan-optimization (Fortinet/Cisco/Riverbed…)
https://www.inside-it.ch/vector-capital-kauft-riverbed-20230713
- Azure Application Proxy > JA, man kann mehrere Connector lokal installieren und sie bieten internes Load Balancing. Failover funktioniert, aber wenn einer ausfällt und man ihn nicht abmeldet, dann erhöht sich die Latenz++, z.B. bei RDP weil die Logik dort immer wieder versucht zu connecten. (Man lese im Web von verzweifelten Endkunden welche Citrix Accessgateway ersetzen wollten un den Effekt hatten [Wir bleiben fair: Letzte grössere Lücke Citrix AG NOV 2022 und JUL 2023])
- Das Erste, was man dann bei verschiedenen Softwareherstellern zu diesem Thema findet, ist, dass man die Timeout-Zeit erhöhen muss (Appliance, Windows Server oder in der App, sofern möglich). Das ist denen noch so recht wenn es eine kostenlose Option gibt um Ihre Lösung WAN tauglich zu machen. Nur der neueste Release ist dann auch für das optimiert?
- Ist doch nichts kostenlos, oder? Ist doch keiner so naiv und glaubt, dass es bei Microsoft etwas umsonst gibt, ausser Systernals von Mark? Das Ziel ist, dass man alles zu Microsoft bringt und dann feststellt, dass es nicht kostenlos bleibt und Latenz hat? Aber dafür gibt es eine weitere Lösung und die heissst Express Route Direct
-
Latenz? Kein Problem, sagen die Microsoft-Cloud-Sales-Evangelisten. Dafür gibt es ja den allseits bekannten Express Route Direct, für den man bis zu CHF 44’867.-/MONAT zahlen kann. Das ist ein “goldenes” Kabel zu den MS Rechenzentren mit SLA.
https://azure.microsoft.com/en-us/pricing/details/expressroute/#pricing
- Für KMU hoffen wir, dass es besser wird, wenn man es CH > CH (Standort Cloud Schweiz) routet? Für Grosskunden mit mehreren internationalen Standorten bleibt dann nur eine Lösung. MS wird nicht blöde sein und sich das Express Route Milliarden-Business kaputt machen. (Peering Traffic muss irgendjemand zahlen, lernt man bei den ISPs?)
- Aus über 25 Jahren Vergangenheit: Nicht davon ausgehen, dass jeder On-Premises-APP-Server für WAN-Zugriff gebaut ist. (Timeout/Session)
Preise Express Route, Switzerland, 13.07.2023
https://azure.microsoft.com/en-us/pricing/details/expressroute/#pricing
Das meinen andere dazu. Wunderbarer Kommentar von Michael Loftus aus den Blog eines MS Mitarbeiters der uns erzählt wir brauchen kein VPN mehr.
Source Linkedin 12.07.2023
Eine Schnellsuche zum Thema Azure Application Proxy und Probleme bringt folgendes:
Jemand intergiert in Enterprise Umgebung, probiert, Produktiv und am Schluss eine Frage im neuen FAQ/Learning bei MS.
Oder war es der Endkunde selber im M365 Admin Portal und die IT-Service Firma kann dann helfen?
Red Teams use Azure Application Proxy to publish their C2 Server
Nice writeup by Adam Chester. So we can asume that it’s “Safe” when Hacker use it. Right? Sudan agrees?
https://blog.xpnsec.com/azure-application-proxy-c2/
Why do they mention ExpressRoute so many times?
Screenshot Auszug MS KB:
