Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Azure Network

Support HackTricks

Podstawowe Informacje

Sieci w Azure funkcjonują jako integralna część jego platformy chmurowej, umożliwiając połączenie i komunikację między różnymi usługami i zasobami Azure. Architektura sieci w Azure jest zaprojektowana tak, aby była wysoce skalowalna, bezpieczna i dostosowywalna.

W swojej istocie, Azure zapewnia wirtualną sieć (VNet), która pozwala użytkownikom tworzyć izolowane sieci w chmurze Azure. W ramach tych VNetów można bezpiecznie hostować i zarządzać zasobami takimi jak maszyny wirtualne, aplikacje i bazy danych. Sieć w Azure wspiera zarówno komunikację wewnątrz chmury (między usługami Azure), jak i połączenie z sieciami zewnętrznymi oraz internetem.

Bezpieczeństwo jest kluczowym aspektem sieci w Azure, z różnymi narzędziami i usługami dostępnymi do ochrony danych, zarządzania dostępem i zapewnienia zgodności. Te środki bezpieczeństwa obejmują zapory ogniowe, grupy zabezpieczeń sieciowych i możliwości szyfrowania, co pozwala na wysoki poziom kontroli nad ruchem i dostępem.

Ogólnie rzecz biorąc, możliwości sieciowe Azure są zaprojektowane tak, aby oferować elastyczność, umożliwiając użytkownikom tworzenie środowiska sieciowego, które odpowiada ich specyficznym potrzebom aplikacji i obciążenia, przy jednoczesnym utrzymaniu silnego nacisku na bezpieczeństwo i niezawodność.

Wirtualna Sieć (VNET) i Podsieci

VNet w Azure to w zasadzie reprezentacja twojej własnej sieci w chmurze. Jest to logiczna izolacja chmury Azure dedykowana twojej subskrypcji. VNet pozwala na tworzenie i zarządzanie wirtualnymi sieciami prywatnymi (VPN) w Azure i może być używany do hostowania i zarządzania wieloma typami zasobów Azure, takich jak maszyny wirtualne (VM), bazy danych i usługi aplikacyjne.

VNety zapewniają pełną kontrolę nad ustawieniami sieciowymi, w tym zakresami adresów IP, tworzeniem podsieci, tablicami routingu i bramami sieciowymi.

Podsieć to zakres adresów IP w twoim VNet. Możesz podzielić VNet na wiele podsieci dla organizacji i bezpieczeństwa. Każda podsieć w VNet może być używana do izolowania i grupowania zasobów zgodnie z twoją architekturą sieciową i aplikacyjną.

Ponadto, podsieci pozwalają na segmentację VNet na jedną lub więcej podsieci, zapewniając zakres adresów IP, które mogą być używane przez zasoby.

Przykład

  • Załóżmy, że masz VNet o nazwie MyVNet z zakresem adresów IP 10.0.0.0/16. Możesz utworzyć podsieć w tym VNet, powiedzmy Subnet-1, z zakresem adresów IP 10.0.0.0/24 do hostowania swoich serwerów webowych. Inna podsieć, Subnet-2 z zakresem 10.0.1.0/24, mogłaby być używana dla twoich serwerów baz danych. Taka segmentacja pozwala na efektywne zarządzanie i kontrolę bezpieczeństwa w sieci.

Enumeracja

Aby wylistować wszystkie VNety i podsieci w koncie Azure, możesz użyć Azure Command-Line Interface (CLI). Oto kroki:

# List VNets
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List subnets of a VNet
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, addressPrefix:addressPrefix}" -o table

Network Security Groups (NSG)

W Azure, Network Security Group (NSG) pełni główną funkcję filtrowania ruchu sieciowego zarówno do, jak i z zasobów Azure w ramach Azure Virtual Network (VNet). Zawiera zestaw reguł bezpieczeństwa, które precyzyjnie określają przepływ ruchu sieciowego.

Kluczowe aspekty NSG obejmują:

  • Kontrola Ruchu: Każdy NSG zawiera reguły, które są kluczowe w zezwalaniu lub blokowaniu ruchu sieciowego przychodzącego i wychodzącego związanego z różnymi zasobami Azure.

  • Komponenty Reguł: Reguły w NSG są bardzo specyficzne, filtrując ruch na podstawie kryteriów takich jak adres IP źródła/destynacji, port i protokół. Ta specyficzność pozwala na szczegółowe zarządzanie ruchem sieciowym.

  • Wzmocnienie Bezpieczeństwa: Zapewniając, że tylko autoryzowany ruch może wchodzić lub wychodzić z zasobów Azure, NSG odgrywają kluczową rolę w umacnianiu bezpieczeństwa infrastruktury sieciowej.

Przykład

  • Wyobraź sobie, że masz NSG o nazwie MyNSG zastosowany do podsieci lub konkretnej maszyny wirtualnej w ramach VNet. Możesz tworzyć reguły takie jak:

  • Reguła przychodząca zezwalająca na ruch HTTP (port 80) z dowolnego źródła do twoich serwerów webowych.

  • Reguła wychodząca zezwalająca tylko na ruch SQL (port 1433) do określonego zakresu adresów IP.

Enumeracja

# List NSGs
az network nsg list --query "[].{name:name, location:location}" -o table

# Get NSG rules
az network nsg rule list --nsg-name <NSGName> --resource-group <ResourceGroupName> --query "[].{name:name, priority:priority, direction:direction, access:access, protocol:protocol, sourceAddressPrefix:sourceAddressPrefix, destinationAddressPrefix:destinationAddressPrefix, sourcePortRange:sourcePortRange, destinationPortRange:destinationPortRange}" -o table

Azure Firewall

Azure Firewall to zarządzana, oparta na chmurze usługa zabezpieczeń sieciowych, która chroni zasoby Twojej Azure Virtual Network. Jest to w pełni stanowy firewall jako usługa z wbudowanymi funkcjami wysokiej dostępności i skalowalności.

Azure Firewall oferuje bardziej zaawansowane funkcje niż NSG, w tym filtrowanie na poziomie aplikacji, filtrowanie na poziomie sieci, filtrowanie oparte na inteligencji zagrożeń oraz integrację z Azure Monitor do logowania i analizy. Może filtrować ruch wychodzący, przychodzący, spoke-to-spoke, VPN i ExpressRoute. Zasady firewalla mogą być tworzone na podstawie FQDN (Fully Qualified Domain Name), adresów IP i portów.

Różnice między Azure Firewall a NSG

  1. Zakres:

  • NSG: Działa na poziomie podsieci lub interfejsu sieciowego. Ma na celu zapewnienie podstawowego filtrowania ruchu przychodzącego i wychodzącego z interfejsów sieciowych (NIC), VM lub podsieci.

  • Azure Firewall: Działa na poziomie VNet, zapewniając szerszy zakres ochrony. Jest zaprojektowany do zabezpieczania zasobów wirtualnej sieci i zarządzania ruchem przepływającym do i z VNet.

  1. Możliwości:

  • NSG: Zapewnia podstawowe możliwości filtrowania na podstawie adresu IP, portu i protokołu. Nie obsługuje zaawansowanych funkcji, takich jak inspekcja na poziomie aplikacji czy inteligencja zagrożeń.

  • Azure Firewall: Oferuje zaawansowane funkcje, takie jak filtrowanie ruchu na poziomie aplikacji (warstwa 7), filtrowanie oparte na inteligencji zagrożeń, filtrowanie ruchu sieciowego i inne. Obsługuje również wiele publicznych adresów IP.

  1. Zastosowania:

  • NSG: Idealny do podstawowego filtrowania ruchu na poziomie sieci.

  • Azure Firewall: Odpowiedni do bardziej złożonych scenariuszy filtrowania, gdzie potrzebna jest kontrola na poziomie aplikacji, logowanie i inteligencja zagrożeń.

  1. Zarządzanie i monitorowanie:

  • NSG: Oferuje podstawowe logowanie i integrację z Azure Monitor.

  • Azure Firewall: Zapewnia zaawansowane możliwości logowania i analizy poprzez Azure Monitor, co jest niezbędne do zrozumienia charakteru i wzorca ruchu.

Enumeracja

# List Azure Firewalls
az network firewall list --query "[].{name:name, location:location, subnet:subnet, publicIp:publicIp}" -o table

# Get network rules of a firewall
az network firewall network-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get application rules of a firewall
az network firewall application-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get nat rules of a firewall
az network firewall nat-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

Network Virtual Appliance (NVA)

Network Virtual Appliance (NVA) w Azure to wirtualne urządzenie, które wykonuje funkcje sieciowe w ramach wirtualnej sieci. NVAs są zazwyczaj używane do funkcji sieciowych, które nie są natywnie dostępne w Azure lub gdy wymagana jest większa personalizacja. Są to zasadniczo VMs, które uruchamiają aplikacje lub usługi sieciowe, takie jak zapory ogniowe, optymalizatory WAN lub load balancery.

NVAs są używane do złożonego routingu, bezpieczeństwa i zarządzania ruchem sieciowym. Mogą być wdrażane z Azure Marketplace, gdzie wielu dostawców zewnętrznych oferuje swoje urządzenia gotowe do integracji z środowiskami Azure.

Przykład

  • Organizacja może wdrożyć NVA w Azure, aby stworzyć niestandardowe rozwiązanie zapory ogniowej. Ta NVA może uruchamiać oprogramowanie zapory ogniowej firmy trzeciej, oferując zaawansowane funkcje, takie jak wykrywanie włamań, inspekcja pakietów lub łączność VPN. NVA może być skonfigurowana do inspekcji i filtrowania ruchu przechodzącego przez nią, zapewniając wzmocnione środki bezpieczeństwa zgodnie z politykami organizacji.

Enumeracja

# Usually NVAs are named or tagged in a way to distinguish them from other VMs
az vm list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# For a specific VM identified as an NVA, list its network interfaces
az vm nic list --vm-name <VMName> --resource-group <ResourceGroupName> --query "[].{id:id}" -o table

Azure Route Tables & User Defined Routes (UDR)

Azure Route Tables to funkcja w Microsoft Azure, która pozwala na kontrolę routingu ruchu sieciowego w ramach Azure Virtual Networks (VNets). Zasadniczo definiują one, jak pakiety są przekazywane między podsieciami w ramach VNets, między VNets lub do sieci zewnętrznych. Każda tabela routingu zawiera zestaw reguł, znanych jako trasy, które określają, jak pakiety powinny być routowane na podstawie ich docelowych adresów IP.

User Defined Routes (UDR) w Azure to niestandardowe trasy, które tworzysz w ramach Azure Route Tables, aby kontrolować przepływ ruchu sieciowego w ramach i między Azure Virtual Networks (VNets) oraz do połączeń zewnętrznych. UDRs dają elastyczność w kierowaniu ruchu sieciowego zgodnie z Twoimi specyficznymi wymaganiami, zastępując domyślne decyzje routingu Azure.

Te trasy są szczególnie przydatne w scenariuszach, w których musisz routować ruch przez wirtualne urządzenie, wymusić określoną ścieżkę ze względów bezpieczeństwa lub zgodności z polityką, lub zintegrować się z sieciami lokalnymi.

Przykład

  • Załóżmy, że wdrożyłeś Network Virtual Appliance (NVA) do inspekcji ruchu między podsieciami w ramach VNet. Możesz utworzyć UDR, który kieruje cały ruch z jednej podsieci do innej podsieci przez NVA. Ten UDR zapewnia, że NVA inspektuje ruch ze względów bezpieczeństwa, zanim dotrze on do miejsca docelowego.

Enumeracja

# List Route Tables
az network route-table list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List UDRs for a table
az network route-table route list --route-table-name <RouteTableName> --resource-group <ResourceGroupName> --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIpAddress:nextHopIpAddress}" -o table

Azure Private Link

Azure Private Link to usługa w Azure, która umożliwia prywatny dostęp do usług Azure poprzez zapewnienie, że ruch między Twoją wirtualną siecią Azure (VNet) a usługą odbywa się całkowicie w ramach sieci szkieletowej Azure Microsoftu. Efektywnie wprowadza usługę do Twojego VNet. Takie ustawienie zwiększa bezpieczeństwo, nie narażając danych na publiczny internet.

Private Link może być używany z różnymi usługami Azure, takimi jak Azure Storage, Azure SQL Database, oraz niestandardowe usługi udostępniane za pośrednictwem Private Link. Zapewnia bezpieczny sposób korzystania z usług wewnątrz własnego VNet lub nawet z różnych subskrypcji Azure.

NSG nie mają zastosowania do prywatnych punktów końcowych, co wyraźnie oznacza, że skojarzenie NSG z podsiecią zawierającą Private Link nie będzie miało żadnego efektu.

Przykład

  • Rozważ scenariusz, w którym masz Azure SQL Database, do której chcesz uzyskać bezpieczny dostęp z Twojego VNet. Normalnie mogłoby to wymagać przechodzenia przez publiczny internet. Dzięki Private Link możesz utworzyć prywatny punkt końcowy w Twoim VNet, który łączy się bezpośrednio z usługą Azure SQL Database. Ten punkt końcowy sprawia, że baza danych wydaje się być częścią Twojego własnego VNet, dostępną za pośrednictwem prywatnego adresu IP, zapewniając tym samym bezpieczny i prywatny dostęp.

Enumeracja

# List Private Link Services
z network private-link-service list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List Private Endpoints
az network private-endpoint list --query "[].{name:name, location:location, resourceGroup:resourceGroup, privateLinkServiceConnections:privateLinkServiceConnections}" -o table

Azure Service Endpoints

Azure Service Endpoints rozszerzają prywatną przestrzeń adresową twojej sieci wirtualnej (VNet) oraz tożsamość twojej VNet do usług Azure przez bezpośrednie połączenie. Dzięki włączeniu punktów końcowych usług, zasoby w twojej VNet mogą bezpiecznie łączyć się z usługami Azure, takimi jak Azure Storage i Azure SQL Database, korzystając z sieci szkieletowej Azure. Zapewnia to, że ruch z VNet do usługi Azure pozostaje w sieci Azure, co zapewnia bardziej bezpieczną i niezawodną ścieżkę.

Przykład

  • Na przykład, konto Azure Storage domyślnie jest dostępne przez publiczny internet. Włączając punkt końcowy usługi dla Azure Storage w twojej VNet, możesz zapewnić, że tylko ruch z twojej VNet może uzyskać dostęp do konta storage. Zapora konta storage może być następnie skonfigurowana do akceptowania ruchu tylko z twojej VNet.

Enumeracja

# List Virtual Networks with Service Endpoints
az network vnet list --query "[].{name:name, location:location, serviceEndpoints:serviceEndpoints}" -o table

# List Subnets with Service Endpoints
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, serviceEndpoints:serviceEndpoints}" -o table

Różnice między Service Endpoints a Private Links

Microsoft zaleca używanie Private Links w dokumentacji:\

Service Endpoints:

  • Ruch z Twojego VNet do usługi Azure odbywa się przez sieć szkieletową Microsoft Azure, omijając publiczny internet.

  • Endpoint to bezpośrednie połączenie z usługą Azure i nie zapewnia prywatnego IP dla usługi w VNet.

  • Usługa jest nadal dostępna przez swój publiczny endpoint spoza Twojego VNet, chyba że skonfigurujesz zaporę usługi, aby blokować taki ruch.

  • Jest to relacja jeden do jednego między podsiecią a usługą Azure.

  • Tańsze niż Private Links.

Private Links:

  • Private Link mapuje usługi Azure do Twojego VNet za pomocą prywatnego endpointu, który jest interfejsem sieciowym z prywatnym adresem IP w Twoim VNet.

  • Usługa Azure jest dostępna za pomocą tego prywatnego adresu IP, co sprawia, że wydaje się być częścią Twojej sieci.

  • Usługi połączone za pomocą Private Link mogą być dostępne tylko z Twojego VNet lub połączonych sieci; nie ma dostępu do usługi przez publiczny internet.

  • Umożliwia bezpieczne połączenie z usługami Azure lub własnymi usługami hostowanymi w Azure, a także połączenie z usługami udostępnionymi przez innych.

  • Zapewnia bardziej szczegółową kontrolę dostępu za pomocą prywatnego endpointu w Twoim VNet, w przeciwieństwie do szerszej kontroli dostępu na poziomie podsieci z service endpoints.

Podsumowując, chociaż zarówno Service Endpoints, jak i Private Links zapewniają bezpieczne połączenie z usługami Azure, Private Links oferują wyższy poziom izolacji i bezpieczeństwa, zapewniając, że usługi są dostępne prywatnie bez narażania ich na publiczny internet. Service Endpoints są natomiast łatwiejsze do skonfigurowania w ogólnych przypadkach, gdy wymagany jest prosty, bezpieczny dostęp do usług Azure bez potrzeby prywatnego IP w VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door to skalowalny i bezpieczny punkt wejścia dla szybkiego dostarczania globalnych aplikacji webowych. Łączy różne usługi, takie jak globalne load balancing, przyspieszenie strony, SSL offloading i Web Application Firewall (WAF) w jedną usługę. Azure Front Door zapewnia inteligentne routowanie na podstawie najbliższej lokalizacji krawędziowej do użytkownika, zapewniając optymalną wydajność i niezawodność. Dodatkowo oferuje routowanie oparte na URL, hosting wielu stron, sesyjną afinitetę i bezpieczeństwo na poziomie aplikacji.

Azure Front Door WAF jest zaprojektowany, aby chronić aplikacje webowe przed atakami internetowymi bez modyfikacji kodu zaplecza. Zawiera niestandardowe reguły i zarządzane zestawy reguł, aby chronić przed zagrożeniami takimi jak SQL injection, cross-site scripting i inne powszechne ataki.

Przykład

  • Wyobraź sobie, że masz globalnie rozproszoną aplikację z użytkownikami na całym świecie. Możesz użyć Azure Front Door, aby routować żądania użytkowników do najbliższego regionalnego centrum danych hostującego Twoją aplikację, zmniejszając opóźnienia, poprawiając doświadczenie użytkownika i broniąc jej przed atakami internetowymi dzięki możliwościom WAF. Jeśli dany region doświadczy przestoju, Azure Front Door może automatycznie przekierować ruch do następnej najlepszej lokalizacji, zapewniając wysoką dostępność.

Enumeracja

# List Azure Front Door Instances
az network front-door list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List Front Door WAF Policies
az network front-door waf-policy list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

Azure Application Gateway i Azure Application Gateway WAF

Azure Application Gateway to load balancer ruchu webowego, który umożliwia zarządzanie ruchem do Twoich aplikacji webowych. Oferuje równoważenie obciążenia na warstwie 7, terminację SSL oraz funkcje zapory aplikacji webowych (WAF) w ramach Application Delivery Controller (ADC) jako usługi. Kluczowe funkcje obejmują routing oparty na URL, sesje oparte na ciasteczkach oraz offloading SSL, które są kluczowe dla aplikacji wymagających złożonych możliwości równoważenia obciążenia, takich jak globalny routing i routing oparty na ścieżkach.

Przykład

  • Rozważ scenariusz, w którym masz stronę e-commerce zawierającą wiele subdomen dla różnych funkcji, takich jak konta użytkowników i przetwarzanie płatności. Azure Application Gateway może kierować ruch do odpowiednich serwerów webowych na podstawie ścieżki URL. Na przykład, ruch do example.com/accounts może być skierowany do usługi kont użytkowników, a ruch do example.com/pay może być skierowany do usługi przetwarzania płatności. I chronić Twoją stronę przed atakami za pomocą funkcji WAF.

Enumeracja

# List the Web Application Firewall configurations for your Application Gateways
az network application-gateway waf-config list --gateway-name <AppGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, firewallMode:firewallMode, ruleSetType:ruleSetType, ruleSetVersion:ruleSetVersion}" -o table

Azure Hub, Spoke & VNet Peering

VNet Peering to funkcja sieciowa w Azure, która umożliwia bezpośrednie i bezproblemowe połączenie różnych Virtual Networks (VNets). Dzięki VNet peering, zasoby w jednym VNet mogą komunikować się z zasobami w innym VNet za pomocą prywatnych adresów IP, jakby były w tej samej sieci. VNet Peering może być również używany z sieciami on-prem poprzez skonfigurowanie site-to-site VPN lub Azure ExpressRoute.

Azure Hub and Spoke to topologia sieciowa używana w Azure do zarządzania i organizowania ruchu sieciowego. "Hub" to centralny punkt, który kontroluje i kieruje ruch między różnymi "spokes". Hub zazwyczaj zawiera wspólne usługi, takie jak network virtual appliances (NVAs), Azure VPN Gateway, Azure Firewall lub Azure Bastion. "Spokes" to VNets, które hostują obciążenia i łączą się z hubem za pomocą VNet peering, co pozwala im korzystać ze wspólnych usług w hubie. Ten model promuje czysty układ sieci, redukując złożoność poprzez centralizację wspólnych usług, z których mogą korzystać różne obciążenia w różnych VNets.

VNET pairing nie jest tranzytywne w Azure, co oznacza, że jeśli spoke 1 jest połączony ze spoke 2, a spoke 2 jest połączony ze spoke 3, to spoke 1 nie może bezpośrednio komunikować się ze spoke 3.

Przykłady

  • Wyobraź sobie firmę z oddzielnymi działami, takimi jak Sprzedaż, HR i Rozwój, każdy z własnym VNet (spokes). Te VNets wymagają dostępu do wspólnych zasobów, takich jak centralna baza danych, firewall i brama internetowa, które znajdują się w innym VNet (hub). Korzystając z modelu Hub and Spoke, każdy dział może bezpiecznie łączyć się ze wspólnymi zasobami przez hub VNet, bez narażania tych zasobów na publiczny internet lub tworzenia skomplikowanej struktury sieciowej z licznymi połączeniami.

Enumeracja

# List all VNets in your subscription
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List VNet peering connections for a given VNet
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, peeringState:peeringState, remoteVnetId:remoteVnetId}" -o table

# List Shared Resources (e.g., Azure Firewall) in the Hub
az network firewall list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

Site-to-Site VPN

Site-to-Site VPN w Azure pozwala na połączenie sieci lokalnej z Azure Virtual Network (VNet), umożliwiając zasobom takim jak VMs w Azure, aby wyglądały jakby były w lokalnej sieci. To połączenie jest ustanawiane przez bramę VPN, która szyfruje ruch między dwiema sieciami.

Przykład

  • Firma z główną siedzibą w Nowym Jorku ma lokalne centrum danych, które musi bezpiecznie połączyć się z VNet w Azure, gdzie hostowane są jej zwirtualizowane obciążenia. Poprzez skonfigurowanie Site-to-Site VPN, firma może zapewnić szyfrowane połączenie między lokalnymi serwerami a Azure VMs, umożliwiając bezpieczny dostęp do zasobów w obu środowiskach, jakby były w tej samej lokalnej sieci.

Enumeracja

# List VPN Gateways
az network vnet-gateway list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List VPN Connections
az network vpn-connection list --gateway-name <VpnGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, connectionType:connectionType, connectionStatus:connectionStatus}" -o table

Azure ExpressRoute

Azure ExpressRoute to usługa, która zapewnia prywatne, dedykowane, szybkie połączenie między infrastrukturą lokalną a centrami danych Azure. To połączenie jest realizowane przez dostawcę łączności, omijając publiczny internet i oferując większą niezawodność, szybsze prędkości, niższe opóźnienia i wyższe bezpieczeństwo niż typowe połączenia internetowe.

Przykład

  • Międzynarodowa korporacja potrzebuje stałego i niezawodnego połączenia z usługami Azure ze względu na dużą ilość danych i potrzebę wysokiej przepustowości. Firma wybiera Azure ExpressRoute, aby bezpośrednio połączyć swoje lokalne centrum danych z Azure, ułatwiając transfery dużej skali danych, takie jak codzienne kopie zapasowe i analizy danych w czasie rzeczywistym, z większą prywatnością i szybkością.

Enumeracja

# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table
Wspieraj HackTricks
PreviousAz - Virtual Machines & NetworkNextAz - Permissions for a Pentest

Last updated