Projektowanie konfiguracji usługi Azure Private Link

Przed skonfigurowaniem wystąpienia usługi Azure Private Link rozważ topologię sieci i topologię routingu DNS.

Zgodnie z opisem w artykule Używanie usługi Azure Private Link do łączenia sieci z usługą Azure Monitor konfigurowanie łącza prywatnego wpływa na ruch do wszystkich zasobów usługi Azure Monitor. Dotyczy to szczególnie zasobów usługi Application Szczegółowe informacje. Ma to również wpływ nie tylko na sieć połączoną z prywatnym punktem końcowym, ale także na wszystkie inne sieci, które współużytkuje ten sam system DNS.

Najprostsze i najbezpieczniejsze podejście:

1. Utwórz jedno połączenie łącza prywatnego z pojedynczym prywatnym punktem końcowym i jednym zakresem usługi Azure Monitor Private Link (AMPLS). Jeśli sieci są równorzędne, utwórz połączenie łącza prywatnego w udostępnionej sieci wirtualnej (lub koncentratora).
2. Dodaj do aplikacji AMPLS wszystkie zasoby usługi Azure Monitor, takie jak składniki usługi Application Szczegółowe informacje, obszary robocze usługi Log Analytics i punkty końcowe zbierania danych.
3. Blokuj jak najwięcej ruchu wychodzącego sieci.

Jeśli nie możesz dodać wszystkich zasobów usługi Azure Monitor do usługi AMPLS, nadal możesz zastosować link prywatny do niektórych zasobów, zgodnie z opisem w temacie Kontrolowanie sposobu stosowania linków prywatnych do sieci. Nie zalecamy tego podejścia, ponieważ nie zapobiega eksfiltracji danych.

Planowanie według topologii sieci

Rozważ topologię sieci w procesie planowania.

Zasada przewodnia: Unikanie przesłonięć DNS przy użyciu pojedynczej biblioteki AMPLS

Niektóre sieci składają się z wielu sieci wirtualnych lub innych połączonych sieci. Jeśli te sieci współużytkują ten sam system DNS, skonfigurowanie łącza prywatnego na dowolnym z nich spowoduje zaktualizowanie systemu DNS i wpłynie na ruch we wszystkich sieciach.

Na poniższym diagramie sieć wirtualna 10.0.1.x łączy się z usługą AMPLS1, która tworzy wpisy DNS mapujące punkty końcowe usługi Azure Monitor na adresy IP z zakresu 10.0.1.x. Później sieć wirtualna 10.0.2.x łączy się z usługą AMPLS2, która zastępuje te same wpisy DNS, mapując te same punkty końcowe globalne/regionalne na adresy IP z zakresu 10.0.2.x. Ponieważ te sieci wirtualne nie są równorzędne, pierwsza sieć wirtualna nie może teraz uzyskać dostępu do tych punktów końcowych.

Aby uniknąć tego konfliktu, utwórz tylko jeden obiekt AMPLS na system DNS.

Sieci piasty i szprych

Sieci piasty i szprych powinny używać jednego połączenia łącza prywatnego ustawionego w sieci piasty (głównej), a nie w każdej sieci wirtualnej będącej szprychą.

Uwaga

Możesz na przykład utworzyć oddzielne łącza prywatne dla sieci wirtualnych szprych, aby umożliwić każdej sieci wirtualnej dostęp do ograniczonego zestawu zasobów monitorowania. W takich przypadkach można utworzyć dedykowany prywatny punkt końcowy i adres AMPLS dla każdej sieci wirtualnej. Należy również sprawdzić, czy nie współużytkują tych samych stref DNS, aby uniknąć przesłonięć DNS.

Sieci równorzędne

Komunikacja równorzędna sieci jest używana w różnych topologiach, innych niż piasta i szprycha. Takie sieci mogą udostępniać sobie adresy IP i najprawdopodobniej współużytkować ten sam system DNS. W takich przypadkach utwórz pojedyncze łącze prywatne w sieci dostępnej dla innych sieci. Unikaj tworzenia wielu prywatnych punktów końcowych i obiektów AMPLS, ponieważ ostatecznie ma zastosowanie tylko ostatni zestaw w systemie DNS.

Izolowane sieci

Jeśli sieci nie są równorzędne, należy również oddzielić ich dns, aby korzystać z linków prywatnych. Następnie utwórz oddzielny prywatny punkt końcowy dla każdej sieci i oddzielny obiekt AMPLS. Obiekty AMPLS mogą łączyć się z tymi samymi obszarami roboczymi/składnikami lub różnymi.

Testowanie lokalne: edytowanie pliku hostów maszyny zamiast systemu DNS

Aby przetestować łącza prywatne lokalnie bez wpływu na innych klientów w sieci, pamiętaj, aby nie aktualizować systemu DNS podczas tworzenia prywatnego punktu końcowego. Zamiast tego zmodyfikuj plik hostów na maszynie, aby wysyłał żądania do punktów końcowych łącza prywatnego:

• Skonfiguruj link prywatny, ale podczas nawiązywania połączenia z prywatnym punktem końcowym wybierz opcję nieuwzintegrowania automatycznego z usługą DNS (krok 5b).
• Skonfiguruj odpowiednie punkty końcowe w plikach hostów maszyn. Aby przejrzeć punkty końcowe usługi Azure Monitor, które wymagają mapowania, zobacz Przeglądanie ustawień DNS punktu końcowego.

Nie zalecamy takiego podejścia w środowiskach produkcyjnych.

Kontrolowanie sposobu stosowania linków prywatnych do sieci

Za pomocą trybów dostępu do łącza prywatnego można kontrolować, jak łącza prywatne wpływają na ruch sieciowy. Te ustawienia mogą być stosowane do obiektu AMPLS (w celu wpływu na wszystkie połączone sieci) lub do określonych sieci połączonych z nim.

Wybór odpowiedniego trybu dostępu ma kluczowe znaczenie dla zapewnienia ciągłego, nieprzerwanego ruchu sieciowego. Każdy z tych trybów można ustawić na potrzeby pozyskiwania i zapytań, oddzielnie:

• Tylko prywatny: umożliwia sieci wirtualnej dostęp tylko do zasobów łącza prywatnego (zasobów w systemie AMPLS). Jest to najbezpieczniejszy tryb pracy. Zapobiega to eksfiltracji danych, blokując ruch z zasobów AMPLS do zasobów usługi Azure Monitor.
• Otwórz: umożliwia sieci wirtualnej uzyskiwanie dostępu do zasobów łącza prywatnego i zasobów, które nie są dostępne w systemie AMPLS (jeśli akceptują ruch z sieci publicznych). Tryb otwierania dostępu nie zapobiega eksfiltracji danych, ale nadal oferuje inne korzyści wynikające z linków prywatnych. Ruch do zasobów łącza prywatnego jest wysyłany za pośrednictwem prywatnych punktów końcowych, weryfikowanych i wysyłanych przez sieć szkieletową firmy Microsoft. Tryb otwierania jest przydatny w trybie mieszanym pracy (dostęp do niektórych zasobów publicznie i innych za pośrednictwem łącza prywatnego) lub podczas stopniowego procesu dołączania. Tryby dostępu są ustawiane oddzielnie na potrzeby pozyskiwania i zapytań. Można na przykład ustawić tryb tylko prywatny na potrzeby pozyskiwania i tryb otwierania zapytań.

Zachowaj ostrożność podczas wybierania trybu dostępu. Użycie trybu dostępu tylko do prywatnego spowoduje zablokowanie ruchu do zasobów, które nie należą do listy AMPLS we wszystkich sieciach, które współużytkują ten sam system DNS, niezależnie od subskrypcji lub dzierżawy. Wyjątkiem są żądania pozyskiwania usługi Log Analytics, co zostało wyjaśnione. Jeśli nie możesz dodać wszystkich zasobów usługi Azure Monitor do listy AMPLS, zacznij od dodania wybranych zasobów i zastosowania trybu otwierania dostępu. Przełącz się do trybu Tylko prywatny dla maksymalnego poziomu zabezpieczeń dopiero po dodaniu wszystkich zasobów usługi Azure Monitor do usługi AMPLS.

Aby uzyskać szczegółowe informacje o konfiguracji i przykłady, zobacz Używanie interfejsów API i wiersza polecenia.

Uwaga

Pozyskiwanie usługi Log Analytics używa punktów końcowych specyficznych dla zasobów. W związku z tym nie jest zgodny z trybami dostępu AMPLS. Aby zapewnić, że żądania pozyskiwania usługi Log Analytics nie mogą uzyskać dostępu do obszarów roboczych poza systemem AMPLS, ustaw zaporę sieciową, aby zablokować ruch do publicznych punktów końcowych, niezależnie od trybów dostępu AMPLS.

Ustawianie trybów dostępu dla określonych sieci

Tryby dostępu ustawione na zasobie AMPLS mają wpływ na wszystkie sieci, ale można zastąpić te ustawienia dla określonych sieci.

Na poniższym diagramie sieć VNet1 używa trybu otwierania, a sieć VNet2 używa trybu tylko prywatny. Żądania z sieci VNet1 mogą uzyskiwać dostęp do obszaru roboczego 1 i składnika 2 za pośrednictwem łącza prywatnego. Żądania mogą docierać do składnika Component 3 tylko wtedy, gdy akceptuje ruch z sieci publicznych. Żądania sieci VNet2 nie mogą nawiązać połączenia ze składnikiem 3.

Rozważ limity AMPLS

Obiekt AMPLS ma następujące limity:

• Sieć wirtualna może łączyć się tylko z jednym obiektem AMPLS. Oznacza to, że obiekt AMPLS musi zapewnić dostęp do wszystkich zasobów usługi Azure Monitor, do których sieć wirtualna powinna mieć dostęp.
• Obiekt AMPLS może łączyć się z 300 obszarami roboczymi usługi Log Analytics i 1000 składnikami aplikacji Szczegółowe informacje co najwyżej.
• Zasób usługi Azure Monitor (obszar roboczy lub aplikacja Szczegółowe informacje składnik lub punkt końcowy zbierania danych) może łączyć się z pięcioma systemami AMPLS.
• Obiekt AMPLS może łączyć się z co najwyżej 10 prywatnymi punktami końcowymi.

Uwaga

Zasoby AMPLS utworzone przed 1 grudnia 2021 r. obsługują tylko 50 zasobów.

Na poniższym diagramie:

• Każda sieć wirtualna łączy się tylko z jednym obiektem AMPLS.
• AMPLS A łączy się z dwoma obszarami roboczymi i jednym składnikiem usługi Application Insights przy użyciu dwóch możliwych 300 obszarów roboczych usługi Log Analytics i jednego z możliwych 1000 składników aplikacji Szczegółowe informacje, z którymi może się połączyć.
• Obszar roboczy 2 łączy się z usługą AMPLS A i AMPLS B przy użyciu dwóch z pięciu możliwych połączeń AMPLS.
• USŁUGA AMPLS B jest połączona z prywatnymi punktami końcowymi dwóch sieci wirtualnych (VNet2 i VNet3) przy użyciu dwóch z 10 możliwych połączeń prywatnych punktów końcowych.

Kontrolowanie dostępu sieciowego do zasobów

Obszary robocze usługi Log Analytics lub składniki Szczegółowe informacje aplikacji można ustawić na:

• Akceptowanie lub blokowanie pozyskiwania z sieci publicznych (sieci nie są połączone z zasobem AMPLS).
• Akceptowanie lub blokowanie zapytań z sieci publicznych (sieci, które nie są połączone z zasobem AMPLS).

Ten stopień szczegółowości umożliwia ustawienie dostępu zgodnie z potrzebami na obszar roboczy. Na przykład możesz zaakceptować pozyskiwanie tylko za pośrednictwem sieci połączonych za pośrednictwem łącza prywatnego (czyli określonych sieci wirtualnych), ale nadal wybierać akceptowanie zapytań ze wszystkich sieci, publicznych i prywatnych.

Blokowanie zapytań z sieci publicznych oznacza, że klienci, tacy jak maszyny i zestawy SDK poza połączonymi zestawami AMPLS, nie mogą wykonywać zapytań dotyczących danych w zasobie. Te dane obejmują dzienniki, metryki i strumień metryk na żywo. Blokowanie zapytań z sieci publicznych ma wpływ na wszystkie środowiska, które uruchamiają te zapytania, takie jak skoroszyty, pulpity nawigacyjne, szczegółowe informacje w witrynie Azure Portal i zapytania są uruchamiane spoza witryny Azure Portal.

Uwaga

Istnieją pewne wyjątki, w których te ustawienia nie mają zastosowania. Szczegółowe informacje można znaleźć w poniższej sekcji.

Punkty końcowe zbierania danych można ustawić tak, aby akceptowały lub blokowały dostęp z sieci publicznych (sieci nie są połączone z zasobem AMPLS).

Aby uzyskać informacje o konfiguracji, zobacz Ustawianie flag dostępu do zasobów.

Wyjątki

Zwróć uwagę na następujące wyjątki.

Dzienniki diagnostyczne

Dzienniki i metryki przekazane do obszaru roboczego za pośrednictwem ustawień diagnostycznych przechodzą przez bezpieczny prywatny kanał firmy Microsoft i nie są kontrolowane przez te ustawienia.

Metryki niestandardowe lub metryki gościa usługi Azure Monitor

Metryki niestandardowe (wersja zapoznawcza) zbierane i przekazywane za pośrednictwem agenta usługi Azure Monitor nie są kontrolowane przez punkty końcowe zbierania danych. Nie można ich skonfigurować za pośrednictwem łączy prywatnych.

Menedżer zasobów Azure

Ograniczenie dostępu zgodnie z wcześniejszym wyjaśnieniem dotyczy danych w zasobie. Jednak zmiany konfiguracji, takie jak włączanie lub wyłączanie tych ustawień dostępu, są zarządzane przez usługę Azure Resource Manager. Aby kontrolować te ustawienia, ogranicz dostęp do zasobów przy użyciu odpowiednich ról, uprawnień, kontroli sieci i inspekcji. Aby uzyskać więcej informacji, zobacz Role, uprawnienia i zabezpieczenia usługi Azure Monitor.

Uwaga

Zapytania wysyłane za pośrednictwem interfejsu API usługi Resource Manager nie mogą używać linków prywatnych usługi Azure Monitor. Te zapytania mogą przechodzić tylko wtedy, gdy zasób docelowy zezwala na zapytania z sieci publicznych (ustawiane za pośrednictwem okienka Izolacja sieciowa lub przy użyciu interfejsu wiersza polecenia).

Znane są następujące środowiska uruchamiania zapytań za pośrednictwem interfejsu API usługi Resource Manager:

• Logika Łącznik aplikacji
• Update Management solution (Rozwiązanie Update Management)
• Rozwiązanie do śledzenia zmian
• Szczegółowe informacje o maszynie wirtualnej
• Szczegółowe informacje o kontenerze
• Okienko Podsumowanie obszaru roboczego usługi Log Analytics (przestarzałe) (które pokazuje pulpit nawigacyjny rozwiązań)

Zagadnienia dotyczące Szczegółowe informacje aplikacji

• Musisz dodać zasoby obsługujące monitorowane obciążenia do łącza prywatnego. Na przykład zobacz Używanie prywatnych punktów końcowych dla aplikacji internetowej platformy Azure.
• Środowiska użycia innych niż portal muszą być również uruchamiane w sieci wirtualnej połączonej prywatnie, która obejmuje monitorowane obciążenia.
• Aby obsługiwać linki prywatne dla profilera i debugera, należy podać własne konto magazynu.

Uwaga

Aby w pełni zabezpieczyć Szczegółowe informacje aplikacji opartej na obszarze roboczym, należy zablokować dostęp do zasobu Szczegółowe informacje aplikacji i bazowego obszaru roboczego usługi Log Analytics.

Zagadnienia dotyczące usługi Log Analytics

Zwróć uwagę na następujące zagadnienia dotyczące usługi Log Analytics.

Pobieranie pakietów rozwiązań usługi Log Analytics

Agenci usługi Log Analytics muszą uzyskać dostęp do globalnego konta magazynu w celu pobrania pakietów rozwiązań. Konfiguracje usługi Private Link utworzone w dniu 19 kwietnia 2021 r. (lub począwszy od czerwca 2021 r. w suwerennych chmurach platformy Azure) mogą uzyskać dostęp do magazynu pakietów rozwiązań agentów za pośrednictwem łącza prywatnego. Ta możliwość jest możliwa za pośrednictwem strefy DNS utworzonej dla programu blob.core.windows.net.

Jeśli konfiguracja łącza prywatnego została utworzona przed 19 kwietnia 2021 r., nie będzie ona docierać do magazynu pakietów rozwiązań za pośrednictwem łącza prywatnego. Aby to zrobić, możesz wykonać następujące czynności:

• Utwórz ponownie adres AMPLS i prywatny punkt końcowy połączony z nim.

• Zezwól agentom na dostęp do konta magazynu za pośrednictwem publicznego punktu końcowego, dodając następujące reguły do listy dozwolonych zapory:

  Środowisko chmury	Zasób agenta	Porty	Kierunek
  Publiczna platforma Azure	scadvisorcontent.blob.core.windows.net	443	Wychodzący
  Azure Government	usbn1oicore.blob.core.usgovcloudapi.net	443	Wychodzący
  Platforma Microsoft Azure obsługiwana przez firmę 21Vianet	mceast2oicore.blob.core.chinacloudapi.cn	443	Wychodzący

Zbieranie dzienników niestandardowych i dzienników usług IIS za pośrednictwem łącza prywatnego

Konta magazynu są używane w procesie pozyskiwania dzienników niestandardowych. Domyślnie używane są konta magazynu zarządzane przez usługę. Aby pozyskiwać dzienniki niestandardowe w linkach prywatnych, musisz użyć własnych kont magazynu i skojarzyć je z obszarami roboczymi usługi Log Analytics.

Aby uzyskać więcej informacji na temat łączenia własnego konta magazynu, zobacz Konta magazynu należące do klienta na potrzeby pozyskiwania dzienników, a w szczególności Używanie linków prywatnych i Łączenie kont magazynu z obszarem roboczym usługi Log Analytics.

Automatyzacja

Jeśli używasz rozwiązań usługi Log Analytics, które wymagają konta usługi Azure Automation (takiego jak Update Management, Change Tracking lub Inventory), należy również utworzyć link prywatny dla konta usługi Automation. Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Private Link do bezpiecznego łączenia sieci z usługą Azure Automation.

Uwaga

Niektóre produkty i witryna Azure Portal udostępniają zapytania dotyczące danych za pośrednictwem usługi Resource Manager. W takim przypadku nie będą mogli wykonywać zapytań o dane za pośrednictwem łącza prywatnego, chyba że do usługi Resource Manager zostaną zastosowane również ustawienia łącza prywatnego. Aby wyeliminować to ograniczenie, możesz skonfigurować zasoby tak, aby akceptowały zapytania z sieci publicznych zgodnie z wyjaśnieniem w temacie Kontrolowanie dostępu sieciowego do zasobów. (Pozyskiwanie może pozostać ograniczone do sieci łącza prywatnego). Zidentyfikowaliśmy następujące produkty i środowiska wykonywania zapytań dotyczących obszarów roboczych za pomocą usługi Resource Manager:

• Logika Łącznik aplikacji
• Update Management solution (Rozwiązanie Update Management)
• Rozwiązanie do śledzenia zmian
• Okienko Podsumowanie obszaru roboczego (przestarzałe) w portalu (z wyświetlonym pulpitem nawigacyjnym rozwiązań)
• Szczegółowe informacje o maszynie wirtualnej
• Szczegółowe informacje o kontenerze

Zagadnienia dotyczące rozwiązania Prometheus zarządzanego

• Ustawienia pozyskiwania usługi Private Link są tworzone przy użyciu protokołu AMPLS i ustawień w punktach końcowych zbierania danych (DCE), które odwołują się do obszaru roboczego usługi Azure Monitor używanego do przechowywania metryk rozwiązania Prometheus.
• Ustawienia zapytań usługi Private Link są wykonywane bezpośrednio w obszarze roboczym usługi Azure Monitor używanym do przechowywania metryk rozwiązania Prometheus i nie są obsługiwane za pośrednictwem protokołu AMPLS.

Wymagania

Zwróć uwagę na następujące wymagania.

Rozmiar podsieci sieciowej

Najmniejsza obsługiwana podsieć IPv4 to /27 (przy użyciu definicji podsieci CIDR). Chociaż sieci wirtualne platformy Azure mogą być tak małe jak /29, platforma Azure zastrzega sobie pięć adresów IP. Konfiguracja łącza prywatnego usługi Azure Monitor wymaga co najmniej 11 więcej adresów IP, nawet jeśli łączysz się z jednym obszarem roboczym. Przejrzyj ustawienia DNS punktu końcowego, aby uzyskać listę punktów końcowych łącza prywatnego usługi Azure Monitor.

Agenci

Najnowsze wersje agentów systemu Windows i Linux muszą być używane do obsługi bezpiecznego pozyskiwania w obszarach roboczych usługi Log Analytics. Starsze wersje nie mogą przekazywać danych monitorowania za pośrednictwem sieci prywatnej.

Agenci systemu Windows usługi Azure Monitor

Agent systemu Windows usługi Azure Monitor w wersji 1.1.1.0 lub nowszej (przy użyciu punktów końcowych zbierania danych).

Agenci usługi Azure Monitor dla systemu Linux

Agent systemu Windows usługi Azure Monitor w wersji 1.10.5.0 lub nowszej (przy użyciu punktów końcowych zbierania danych).

Agent systemu Windows usługi Log Analytics (na ścieżce wycofania)

Użyj agenta usługi Log Analytics w wersji 10.20.18038.0 lub nowszej.

Agent usługi Log Analytics dla systemu Linux (na ścieżce wycofania)

Użyj agenta w wersji 1.12.25 lub nowszej. Jeśli nie możesz, uruchom następujące polecenia na maszynie wirtualnej:

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

Azure Portal

Aby korzystać z środowisk portalu usługi Azure Monitor, takich jak application Szczegółowe informacje, Log Analytics i punkty końcowe zbierania danych, należy zezwolić na dostęp do witryn Azure Portal i rozszerzeń usługi Azure Monitor w sieciach prywatnych. Dodaj tagi usługi AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty i AzureFrontdoor.Frontenddo sieciowej grupy zabezpieczeń.

Dostęp programowy

Aby użyć interfejsu API REST, interfejsu wiersza polecenia platformy Azure lub programu PowerShell z usługą Azure Monitor w sieciach prywatnych, dodaj tagiusług AzureActiveDirectory i AzureResourceManager do zapory.

Pobieranie zestawu SDK Szczegółowe informacje aplikacji z sieci dostarczania zawartości

Utwórz pakiet kodu JavaScript w skrypcie, aby przeglądarka nie próbowała pobrać kodu z usługi CDN. Przykład jest udostępniany w witrynie GitHub.

Ustawienia DNS przeglądarki

Jeśli łączysz się z zasobami usługi Azure Monitor za pośrednictwem łącza prywatnego, ruch do tych zasobów musi przechodzić przez prywatny punkt końcowy skonfigurowany w sieci. Aby włączyć prywatny punkt końcowy, zaktualizuj ustawienia DNS zgodnie z wyjaśnieniem w Połączenie do prywatnego punktu końcowego. Niektóre przeglądarki używają własnych ustawień DNS zamiast ustawionych. Przeglądarka może próbować nawiązać połączenie z publicznymi punktami końcowymi usługi Azure Monitor i całkowicie pominąć link prywatny. Sprawdź, czy ustawienia przeglądarki nie przesłaniają ani nie buforują starych ustawień DNS.

Ograniczenie zapytań: operator externaldata

• Operator externaldata nie jest obsługiwany za pośrednictwem łącza prywatnego, ponieważ odczytuje dane z kont magazynu, ale nie gwarantuje, że magazyn jest uzyskiwany prywatnie.
• Serwer proxy usługi Azure Data Explorer (serwer proxy ADX) umożliwia wykonywanie zapytań dotyczących dzienników w usłudze Azure Data Explorer. Serwer proxy ADX nie jest obsługiwany za pośrednictwem łącza prywatnego, ponieważ nie gwarantuje, że docelowy zasób jest uzyskiwany prywatnie.

Następne kroki

• Dowiedz się, jak skonfigurować link prywatny.
• Dowiedz się więcej o magazynie prywatnym na potrzeby dzienników niestandardowych i kluczy zarządzanych przez klienta.
• Dowiedz się więcej o usłudze Private Link dla usługi Automation.