Zabezpieczenia DNS i rozpoznawanie nazw prywatnych

W tym artykule wyjaśniono, jak zaprojektować system DNS dla sieci platformy Azure przy użyciu prywatnych stref DNS, usługi Azure DNS Private Resolver i mechanizmów zabezpieczeń DNS. Obejmuje ona wzorce rozpoznawania nazw prywatnych, hybrydowe przekazywanie DNS, integrację z usługą DNS prywatnego punktu końcowego i ochronę przed zagrożeniami w warstwie DNS.

Co opisano w tym artykule

Dns jest podstawą łączności sieciowej: każde połączenie zaczyna się od zapytania rozpoznawania nazw. W platformie Azure projektowanie DNS określa, jak obciążenia mogą się wzajemnie odnajdywać pomiędzy sieciami wirtualnymi, jak systemy lokalne rozwiązują nazwy hostowane w platformie Azure oraz jak prywatne punkty końcowe stają się dostępne pod swoimi w pełni kwalifikowanymi nazwami domenowymi (FQDN). Poza rozpoznawaniem system DNS jest również powierzchnią ataków. Tunelowanie DNS, eksfiltracja i zapytania do złośliwych domen reprezentują rzeczywiste zagrożenia, które wymagają kontroli zabezpieczeń warstwy DNS.

Ten artykuł dotyczy trzech problemów z systemem DNS:

  • Rozpoznawanie nazw prywatnych: Sposób rozpoznawania nazw maszyn wirtualnych, kontenerów i usług platformy w Azure bez uwidaczniania zapytań DNS w publicznym Internecie.
  • Hybrydowe przekazywanie DNS: Jak sieci lokalne rozpoznają prywatne nazwy platformy Azure i jak obciążenia uruchomione na platformie Azure rozpoznają nazwy lokalne.
  • Zabezpieczenia DNS: Jak blokować złośliwe zapytania DNS, zapobiegać eksfiltracji DNS i włączać filtrowanie sieci oparte na nazwach FQDN.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli:

  • Wdróż prywatne punkty końcowe (jeśli ma to zastosowanie w Twoim scenariuszu) i zadbaj o to, aby obciążenia robocze prawidłowo rozpoznawały strefy DNS privatelink.*.
  • Obsługuj środowiska hybrydowe, w których systemy lokalne muszą rozpoznawać prywatne nazwy platformy Azure (lub odwrotnie).
  • Korzystasz z usługi Azure Firewall i potrzebujesz filtrowania na podstawie nazw FQDN w regułach sieciowych.
  • Chcesz zablokować zapytania DNS do znanych złośliwych domen w warstwie rozpoznawania.
  • Zarządzanie środowiskami z wieloma sieciami wirtualnymi, w których scentralizowane rozpoznawanie nazw DNS upraszcza operacje.
  • Planuj architekturę DNS dla topologii hub-and-spoke ze współdzielonymi usługami.

Nacisk na lift-and-shift: Zachowaj dotychczasowy sposób nazewnictwa DNS podczas migracji. Użyj dwukierunkowego przekazywania zapytań między lokalnym serwerem DNS a platformą Azure, skonfiguruj warunkowe przekazywanie na potrzeby rozdzielonego rozpoznawania nazw i hostuj prywatne nazwy platformy Azure w strefach prywatnego systemu DNS, aby aplikacje zachowały bieżącą konfigurację DNS.

Modernizuj fokus: Scentralizowane rozpoznawanie nazw podczas ponownego przetwarzania obciążeń. Użyj Azure DNS Private Resolver z zestawami reguł przekazywania na potrzeby rozpoznawania hybrydowego, zintegrować strefy Prywatna strefa DNS z Private Endpoints dla usług PaaS oraz włącz proxy DNS usługi Azure Firewall, aby reguły oparte na nazwach FQDN i rozpoznawanie nazw DNS korzystały z jednej wspólnej ścieżki z pamięcią podręczną.

Koncentracja na środowiskach wielochmurowych: Zaplanuj przełączenie DNS między chmurami przed migracją obciążeń. Użyj Azure DNS Private Resolver do rozpoznawania nazw między chmurami, skonfiguruj przekazywanie warunkowe zapytań za pomocą usługi AWS Route 53 Resolver lub Google Cloud DNS oraz obniż wartości TTL przed przełączeniem, aby zmniejszyć ryzyko nieaktualnych wpisów w pamięci podręcznej.

Usługi i funkcje platformy Azure

W poniższej tabeli opisano usługi Azure i funkcje związane z zabezpieczeniami DNS i rozpoznawaniem nazw prywatnych.

Usługa/funkcja Purpose Kluczowa możliwość Kiedy stosować
Azure DNS (strefy publiczne) Autorytatywne hostowanie dla nazw domen publicznych globalna sieć anycast, integracja z mechanizmem RBAC platformy Azure, rekordy aliasowe dla zasobów platformy Azure Jesteś właścicielem domeny publicznej i chcesz hostować rekordy DNS w Azure z wysoką dostępnością.
Strefy prywatne DNS Azure Rozpoznawanie nazw w sieciach wirtualnych bez publicznej ekspozycji Łączenie sieci wirtualnej, automatyczna rejestracja nazw hostów maszyn wirtualnych, hosting strefy łącza prywatnego Wewnętrzne rozpoznawanie nazw dla obciążeń Azure. Wymagana do integracji usługi DNS z prywatnym punktem końcowym.
Prywatna rozwiązywarka Azure DNS Przekazywanie DNS między Azure i sieciami zewnętrznymi Przychodzący punkt końcowy (lokalne → Azure rozpoznawanie), wychodzący punkt końcowy (Azure → przekierowanie lokalne), zestawy reguł przesyłania dalej Środowiska hybrydowe wymagające dwukierunkowego rozpoznawania nazw DNS bez wdrażania niestandardowych maszyn wirtualnych DNS.
Azure Firewall serwera proxy DNS Scentralizowane przechwytywanie DNS do filtrowania FQDN Buforuje odpowiedzi DNS, umożliwia reguły sieciowe oparte na nazwach FQDN, zapewnia pojedynczy punkt końcowy DNS dla sieci wirtualnych typu spoke Wdrażasz Azure Firewall i potrzebujesz filtrowania FQDN w regułach sieci. Wymagane do spójnego rozpoznawania nazw FQDN.
Zasady zabezpieczeń DNS Ochrona przed zagrożeniami w warstwie DNS Blokuje rozpoznawanie znanych złośliwych domen przy użyciu kanału informacyjnego analizy zagrożeń Microsoft Chcesz zapobiec nawiązywaniu połączenia obciążeń z domenami dystrybucji poleceń i kontroli lub złośliwego oprogramowania.

pojęcia dotyczące strefy Prywatna strefa DNS

Prywatna strefa DNS strefy zapewniają rozpoznawanie nazw połączonych sieci wirtualnych bez uwidaczniania rekordów w Internecie. Kluczowe zachowania:

  • Łączenie sieci wirtualnej: Prywatną strefę DNS można połączyć z wieloma sieciami wirtualnymi. Wszystkie zasoby w połączonych sieciach VNet mogą rozwiązywać rekordy w strefie.
  • Automatyczna rejestracja: Po włączeniu linku sieci wirtualnej Azure automatycznie tworzy rekordy A dla maszyn wirtualnych wdrożonych w tej sieci wirtualnej. Azure usuwa rekordy po cofnięciu przydziału lub usunięciu maszyn wirtualnych. Automatyczna rejestracja działa tylko dla maszyn wirtualnych (tylko podstawowa karta sieciowa). Sieć wirtualna może automatycznie rejestrować się tylko w jednej prywatnej strefie DNS, ale można połączyć wiele sieci wirtualnych z tą samą strefą.
  • Dns prywatnego punktu końcowego: usługi Azure dostępne za pośrednictwem prywatnych punktów końcowych wymagają określonych stref DNS łącza prywatnego (na przykład privatelink.blob.core.windows.net w przypadku Azure Blob Storage). Bez właściwej strefy klienci rozpoznają publiczny adres IP zamiast prywatnego adresu punktu końcowego.

Architektura prywatnego resolvera DNS

Azure DNS private resolver zastępuje potrzebę niestandardowych maszyn wirtualnych DNS w scenariuszach przekazywania hybrydowego. Poniższy diagram przedstawia hybrydowy przebieg rozwiązywania nazw DNS ze środowiska lokalnego przez usługę Azure DNS Private Resolver do adresu IP prywatnego punktu końcowego.

Diagram przedstawiający przepływ hybrydowego rozwiązywania nazw DNS ze środowiska lokalnego przez przychodzący punkt końcowy usługi Azure DNS Private Resolver do prywatnej strefy DNS i adresu IP prywatnego punktu końcowego.

Program rozpoznawania używa dwóch typów punktów końcowych:

  • Punkt końcowy ruchu przychodzącego: Udostępnia adres IP, którego serwery DNS w środowisku lokalnym mogą używać jako warunkowego serwera przekazującego. Azure DNS obsługuje zapytania wysyłane na ten adres IP (w tym połączone prywatne strefy DNS). Wymaga dedykowanej podsieci delegowanej do Microsoft.Network/dnsResolvers.
  • Punkt końcowy ruchu wychodzącego: Umożliwia obciążeniom platformy Azure przekazywanie zapytań DNS do lokalnych serwerów DNS, innych dostawców usług w chmurze lub zewnętrznych resolverów. Ponadto wymaga dedykowanej podsieci. Zestawy reguł przesyłania dalej dołączone do punktu końcowego ruchu wychodzącego określają, które sufiksy domeny mają być przekazywane i które docelowe serwery DNS mają być używane.

Ważna

Punkty końcowe dla ruchu przychodzącego i wychodzącego wymagają własnej dedykowanej podsieci. Nie można wdrożyć innych zasobów w tych podsieciach. Sieć wirtualna połączona z zestawem reguł przesyłania dalej nie musi być połączona za pomocą komunikacji równorzędnej z siecią wirtualną rozpoznawania nazw. Łącza zestawu reguł działają niezależnie od komunikacji równorzędnej sieci wirtualnych.

Jak wybrać

Użyj następującego drzewa decyzyjnego, aby wybrać odpowiednie składniki DNS dla danego środowiska.

Drzewo decyzyjne

  1. Czy używasz prywatnych punktów końcowych?

    • Tak → wdróż strefy Prywatna strefa DNS z odpowiednimi privatelink.* nazwami stref. Połącz strefy z sieciami wirtualnymi, które muszą rozpoznawać prywatne adresy punktów końcowych.

  2. Czy systemy lokalne muszą rozpoznawać nazwy prywatne Azure?

    • Tak → Wdróż prywatny resolver DNS z punktem końcowym ruchu przychodzącego. Skonfiguruj lokalne serwery DNS z warunkowymi forwarderami wskazującymi na adres IP punktu końcowego ruchu przychodzącego.

  3. Czy obciążenia uruchomione na platformie Azure muszą rozwiązywać nazwy w środowisku lokalnym?

    • Tak → wdroż usługę DNS Private Resolver z punktem końcowym ruchu wychodzącego. Utwórz zestawy reguł przekazywania dla sufiksów domeny lokalnej (na przykład corp.contoso.com).

  4. Czy wdrażasz Azure Firewall i potrzebujesz filtrowania FQDN w regułach sieci?

    • Tak → Włącz proxy DNS zapory. Skonfiguruj maszyny wirtualne w sieciach spoke, aby używały prywatnego adresu IP zapory jako serwera DNS.

  5. Czy chcesz zablokować zapytania DNS do znanych złośliwych domen?

    • Tak → Włącz zasady zabezpieczeń DNS przy użyciu strumienia Microsoft Threat Intelligence w docelowych sieciach wirtualnych.

Często używane wzorce

Wzór Components Przypadek użycia
Tylko rozpoznawanie prywatnego punktu końcowego Prywatne strefy DNS + łącza sieci wirtualnych Obciążenia robocze działające wyłącznie w chmurze, które uzyskują dostęp do usług PaaS za pośrednictwem prywatnych punktów końcowych. Brak łączności hybrydowej.
Dwukierunkowa rozdzielczość hybrydowa prywatne strefy DNS + prywatny resolver DNS (ruchu przychodzącego i wychodzącego) Lokalne środowisko rozpoznaje prywatne nazwy platformy Azure; platforma Azure rozpoznaje lokalne nazwy usługi Active Directory.
Scentralizowany koncentrator DNS Prywatny resolver DNS w centralnej sieci wirtualnej i zestawy reguł przekazywania połączone z sieciami podrzędnymi Topologia hub-and-spoke, w której cały ruch związany z rozpoznawaniem nazw DNS jest kierowany przez centralny węzeł, aby zapewnić centralne rejestrowanie i kontrolę.
DNS za pośrednictwem zapory serwer proxy Azure Firewall DNS i strefy Prywatna strefa DNS Środowiska korzystające z programu Firewall do filtrowania FQDN. Zapora przechwytuje ruch DNS, umożliwiając spójne rozwiązywanie nazw FQDN na adresy IP dla reguł sieciowych.
Pełny stos zabezpieczeń Wszystkie poprzednie opcje oraz zasady zabezpieczeń DNS Środowiska przedsiębiorstwa wymagające hybrydowego rozpoznawania, filtrowania nazw FQDN i ochrony przed zagrożeniami w warstwie DNS.

Przykłady strefy DNS prywatnego punktu końcowego

W poniższej tabeli wymieniono typowe usługi Azure oraz ich wymagane nazwy stref Prywatna strefa DNS.

usługa Azure nazwa prywatnej strefy DNS
Azure Blob Storage privatelink.blob.core.windows.net
Azure SQL Database privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Azure Files privatelink.file.core.windows.net
Azure Container Registry privatelink.azurecr.io
Azure Cosmos DB (interfejs API SQL) privatelink.documents.azure.com

Note

Aby uzyskać pełną listę nazw stref Prywatna strefa DNS dla wszystkich usług Azure, zobacz Azure Konfiguracja DNS prywatnego punktu końcowego.

Prerequisites

Przed wdrożeniem zabezpieczeń DNS i rozpoznawania nazw prywatnych upewnij się, że masz:

  • Sieć wirtualna: Wszystkie funkcje DNS działają w ramach sieci wirtualnych lub w sieciach wirtualnych. Aby uzyskać podstawowe wskazówki, zobacz Sieci wirtualne i podsieci . (F1)
  • Łączność sieciowa w scenariuszach hybrydowych: Przychodzące punkty końcowe prywatnego resolwera DNS wymagają łączności sieciowej z sieci lokalnej (ExpressRoute lub VPN) do sieci wirtualnej (VNet) resolwera.
  • Dedykowane podsieci dla Prywatnego resolvera DNS: Każdy punkt końcowy (przychodzący i wychodzący) wymaga własnej podsieci delegowanej do Microsoft.Network/dnsResolvers. Zaplanuj co najmniej /28 dla każdej podsieci punktu końcowego.
  • Wdrożone prywatne punkty końcowe (jeśli używane są strefy privatelink): Prywatne strefy DNS dla nazwprivatelink.* mają sens tylko wtedy, gdy istnieją prywatne punkty końcowe. Aby uzyskać wskazówki dotyczące wdrażania, zobacz Prywatny dostęp paaS z prywatnymi punktami końcowymi . (C5)
  • Wdrożono usługę Azure Firewall (w przypadku korzystania z serwera proxy DNS): Funkcja serwera proxy DNS wymaga istniejącej instancji usługi Azure Firewall. Zobacz Azure Firewall i inspekcja ruchu. (S1)
  • Uprawnienia: Rola Współautor stref DNS do zarządzania prywatnymi strefami DNS. Współautor sieciowy wdrożenia prywatnego resolvera DNS.

Zagadnienia dotyczące zabezpieczeń

System DNS wprowadza określone wektory ataków, które wymagają dedykowanych kontrolek. W poniższych sekcjach omówiono ryzyka związane z eksfiltracją danych, blokowanie oparte na danych wywiadowczych o zagrożeniach, działanie serwera proxy DNS w zaporze oraz ograniczenia protokołu DNSSEC.

Ryzyko eksfiltracji DNS

Tunelowanie DNS koduje dane w zapytaniach DNS w celu eksfiltrowania informacji za pośrednictwem inaczej nieograniczonego protokołu. Ponieważ większość sieci zezwala na wychodzący system DNS (UDP/TCP 53), osoby atakujące używają systemu DNS jako kanału ukrywanego. Zminimalizuj to ryzyko, wykonując następujące czynności:

  • Włączenie Azure Firewall serwera proxy DNS i kierowanie całego ruchu DNS przez zaporę. Zapora rejestruje wszystkie zapytania DNS, co sprawia, że tunelowanie jest wykrywalne za pośrednictwem analizy.
  • Stosowanie zasad zabezpieczeń DNS w celu blokowania rozpoznawania domen skojarzonych ze znanymi narzędziami eksfiltracji i infrastrukturą poleceń i kontroli.
  • Monitorowanie wzorców zapytań DNS w Azure Monitor pod kątem anomalii, takich jak niezwykle długie etykiety poddomeny, duże woluminy zapytań do jednej domeny lub zapytania do niedawno zarejestrowanych domen.

Zasady zabezpieczeń DNS

Zasady zabezpieczeń DNS z Microsoft Threat Intelligence blokują rozpoznawanie nazw DNS znanych złośliwych domen na poziomie sieci wirtualnej. Gdy obciążenie próbuje rozpoznać domenę oflagowaną przez Centrum zabezpieczeń firmy Microsoft (MSRC), zasady blokują rozpoznawanie przed wystąpieniem jakiegokolwiek połączenia sieciowego. Ta kontrolka działa niezależnie od Azure Firewall i nie wymaga zmian w poszczególnych konfiguracjach obciążeń.

Kluczowe cechy:

  • Używa kanału analizy zagrożeń Microsoft pozyskiwanego z MSRC.
  • Działa w warstwie rozpoznawania nazw DNS: blokuje zapytanie, a nie ruch.
  • Stosowane dla każdej sieci VNet: włącz we wszystkich sieciach VNet zawierających obciążenia uzyskujące dostęp do Internetu.
  • W odróżnieniu od filtrowania FQDN w zaporze, polityka zabezpieczeń DNS blokuje złośliwe domeny w skali globalnej bez konieczności wdrażania zapory.

Filtrowanie serwera proxy DNS zapory i nazwy FQDN

Serwer proxy DNS usługi Azure Firewall jest wymagany do filtrowania na podstawie nazw FQDN w regułach sieciowych. Bez proxy DNS żądania DNS z maszyn wirtualnych klientów mogą być rozwiązywane w innym czasie niż po stronie zapory, powodując niespójne mapowanie adresów IP na nazwy FQDN oraz niedopasowania reguł.

Po włączeniu serwera proxy DNS:

  • Skonfiguruj maszyny wirtualne w sieciach spoke, aby używały prywatnego adresu IP zapory jako serwera DNS.
  • Zapora obsługuje zapytania w imieniu klientów i zapisuje wyniki w pamięci podręcznej (pozytywna pamięć podręczna do 1 godziny, negatywna pamięć podręczna do 30 minut).
  • Mapowania nazw FQDN na adresy IP są odświeżane co 15 sekund. Zapora usuwa nieaktualne wpisy po 15 minutach.
  • Reguły aplikacji (L7) używają wskazania nazwy serwera (SNI) na potrzeby dopasowywania nazw FQDN i nie wymagają serwera proxy DNS. Reguły sieci (L4) wymagają serwera proxy DNS na potrzeby rozpoznawania nazw FQDN.
  • Filtrowanie FQDN w regułach sieci obsługuje tylko dokładne dopasowania domen. Wzorce z symbolami wieloznacznymi nie są obsługiwane w nazwach FQDN w regułach sieciowych. Użyj reguł aplikacji do dopasowywania nazw FQDN z symbolami wieloznacznymi.

Note

Jeśli wszystkie skonfigurowane serwery DNS nadrzędne staną się niedostępne, serwer proxy DNS usługi Azure Firewall nie przełączy się na alternatywny serwer DNS. Rozpoznawanie nazw DNS kończy się niepowodzeniem, dopóki co najmniej jeden nadrzędny serwer nie zostanie odzyskany. Zaplanuj nadmiarowość serwerów DNS w konfiguracji upstream.

Caution

Jeśli włączysz proxy DNS, ale nie skonfigurujesz maszyn wirtualnych klientów tak, aby używały zapory jako serwera DNS, reguły sieciowe oparte na nazwach FQDN nie będą działać poprawnie. Klienci i zapora mogą rozpoznawać różne adresy IP dla tej samej nazwy FQDN, co powoduje nieoczekiwane spadki ruchu.

Ograniczenia protokołu DNSSEC

Azure DNS obecnie nie obsługuje weryfikacji protokołu DNSSEC dla stref prywatnych. Strefy publiczne hostowane w Azure DNS obsługują podpisywanie PROTOKOŁU DNSSEC na potrzeby autorytatywnych odpowiedzi, ale rekursywne rozpoznawanie w sieciach wirtualnych Azure nie przeprowadza walidacji protokołu DNSSEC. Jeśli wymagania dotyczące zabezpieczeń wymagają walidacji DNSSEC, rozważ użycie niestandardowego resolvera DNS, który obsługuje walidację, albo wdroż weryfikację na poziomie aplikacji.

Uwagi dotyczące projektowania

Fokus projektowania systemu DNS metodą "lift-and-shift"

  • Skonfiguruj dwukierunkowe przekazywanie DNS między lokalnymi serwerami DNS a usługą Azure DNS Private Resolver.
  • Użyj warunkowych usług przesyłania dalej, aby zapytania lokalne dotyczące nazw hostowanych na platformie Azure były rozwiązywane na platformie Azure, a zapytania z platformy Azure dotyczące nazw lokalnych były rozwiązywane za pośrednictwem istniejącej infrastruktury DNS.
  • Utwórz prywatne strefy DNS dla każdej usługi platformy Azure używanej przez zmigrowane obciążenia robocze, zwłaszcza usług korzystających z prywatnego punktu końcowego.
  • Zachowaj działanie DNS aplikacji podczas migracji, używając rekordów aliasowych lub mapowań CNAME zamiast zmieniać ustawienia resolwera klienta.

Modernizuj fokus projektu DNS

  • Scentralizuj rozwiązywanie nazw DNS w sieci centralnej przy użyciu usługi Azure DNS Private Resolver z zestawami reguł przekazywania udostępnionymi w sieciach wirtualnych typu spoke.
  • Połącz strefy Prywatna strefa DNS dla każdej usługi PaaS opartej na prywatnym punkcie końcowym, aby ponownie platformowane obciążenia automatycznie rozpoznawały nazwy prywatnych łączy.
  • Włącz serwer proxy dns Azure Firewall, aby reguły sieciowe oparte na nazwie FQDN i rozpoznawanie nazw DNS obciążenia używały spójnej, buforowanej ścieżki rozpoznawania.
  • Użyj automatycznej rejestracji i mechanizmu Azure RBAC w prywatnych strefach DNS, aby ograniczyć potrzebę ręcznego zarządzania rekordami przy wdrażaniu infrastruktury jako kodu.

Fokus projektowania DNS między chmurami

  • Użyj usługi Azure DNS Private Resolver jako punktu sterowania przekazywaniem na potrzeby rozpoznawania nazw między chmurami.
  • Skonfiguruj przekazywanie warunkowe między prywatną usługą Azure DNS, usługą AWS Route 53 Resolver i usługą Google Cloud DNS dla każdej prywatnej przestrzeni nazw, która musi być rozwiązywana między środowiskami.
  • Zaplanuj przełączenie DNS etapami: obniż wartości TTL, zweryfikuj ścieżki przekazywania, zmień rekordy CNAME lub A oraz monitoruj opóźnienia zapytań i zachowanie pamięci podręcznej.
  • Zastosuj DNSSEC w strefach autorytatywnych tam, gdzie połączone platformy go obsługują, i udokumentuj miejsca, w których prywatne ścieżki rozwiązywania nazw nie weryfikują DNSSEC.

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Kontrolowanie wychodzącego ruchu internetowego: scentralizowanie całej komunikacji wychodzącej za pośrednictwem Azure Firewall i wyłączanie domyślnego dostępu wychodzącego.

Kolejny etap procesu modernizacji:

Konfigurowanie monitorowania produkcji: włącz Network Watcher i monitor wydajności sieci na potrzeby gotowości produkcyjnej od pierwszego dnia.

Kolejny krok w Twojej wielochmurowej podróży:

Zabezpiecz ścieżkę tranzytową między chmurami: wdroż Azure Firewall w zabezpieczonym koncentratorze wirtualnym, aby inspekcjonować cały ruch między chmurami, z oddziałów i do Internetu.

  • Last updated on