Omówienie i pojęcia dotyczące prywatnych punktów końcowych (wersja 2) dla usługi Azure Backup
Usługa Azure Backup umożliwia bezpieczne wykonywanie operacji tworzenia i przywracania kopii zapasowych danych z magazynów usługi Recovery Services przy użyciu prywatnych punktów końcowych. Prywatne punkty końcowe używają co najmniej jednego prywatnego adresu IP z sieci wirtualnej platformy Azure, efektywnie przenosząc usługę do sieci wirtualnej.
Usługa Azure Backup zapewnia teraz ulepszone środowisko tworzenia i używania prywatnych punktów końcowych w porównaniu z środowiskiem klasycznym (wersja 1).
W tym artykule opisano, w jaki sposób ulepszone możliwości prywatnych punktów końcowych dla funkcji usługi Azure Backup i ułatwiają wykonywanie kopii zapasowych przy zachowaniu bezpieczeństwa zasobów.
Najważniejsze ulepszenia
- Tworzenie prywatnych punktów końcowych bez tożsamości zarządzanych.
- Dla usług obiektów blob i kolejek nie są tworzone żadne prywatne punkty końcowe.
- Użycie mniejszej liczby prywatnych adresów IP.
Przed rozpoczęciem
Magazyn usługi Recovery Services jest używany zarówno przez usługę Azure Backup, jak i usługę Azure Site Recovery, ale w tym artykule omówiono używanie prywatnych punktów końcowych tylko dla usługi Azure Backup.
Możesz utworzyć prywatne punkty końcowe dla nowych magazynów usługi Recovery Services, które nie mają żadnych elementów zarejestrowanych/chronionych tylko w magazynie. Jednak prywatne punkty końcowe nie są obecnie obsługiwane w przypadku magazynów usługi Backup.
Uwaga
Nie można tworzyć prywatnych punktów końcowych przy użyciu statycznego adresu IP.
Nie można uaktualnić magazynów (zawierających prywatne punkty końcowe) utworzonych przy użyciu środowiska klasycznego do nowego środowiska. Możesz usunąć wszystkie istniejące prywatne punkty końcowe, a następnie utworzyć nowe prywatne punkty końcowe przy użyciu środowiska wersji 2.
Jedna sieć wirtualna może zawierać prywatne punkty końcowe dla wielu magazynów usługi Recovery Services. Ponadto jeden magazyn usługi Recovery Services może mieć prywatne punkty końcowe w wielu sieciach wirtualnych. Można jednak utworzyć maksymalnie 12 prywatnych punktów końcowych dla magazynu.
Prywatny punkt końcowy magazynu używa 10 prywatnych adresów IP, a liczba może wzrosnąć wraz z upływem czasu. Upewnij się, że masz wystarczającą liczbę adresów IP dostępnych podczas tworzenia prywatnych punktów końcowych.
Prywatne punkty końcowe dla usługi Azure Backup nie obejmują dostępu do identyfikatora Entra firmy Microsoft. Upewnij się, że włączono dostęp, aby adresy IP i nazwy FQDN wymagane dla identyfikatora Entra firmy Microsoft działały w regionie, mają dostęp wychodzący w stanie dozwolonym w zabezpieczonej sieci podczas wykonywania kopii zapasowych baz danych na maszynach wirtualnych platformy Azure i tworzenia kopii zapasowych przy użyciu agenta MARS. Możesz również użyć tagów sieciowej grupy zabezpieczeń i tagów usługi Azure Firewall, aby umożliwić dostęp do identyfikatora entra firmy Microsoft zgodnie z wymaganiami.
Musisz ponownie zarejestrować dostawcę zasobów usługi Recovery Services w ramach subskrypcji, jeśli zarejestrowano go przed 1 maja 2020 r. Aby ponownie zarejestrować dostawcę, przejdź do subskrypcji w dostawcy zasobów witryny Azure Portal>, a następnie wybierz pozycję Microsoft.RecoveryServices>Ponownie zarejestruj się.
Przywracanie między regionami dla kopii zapasowych baz danych SQL i SAP HANA nie jest obsługiwane, jeśli magazyn ma włączone prywatne punkty końcowe.
Usługę DNS można utworzyć w ramach subskrypcji.
Zalecane i obsługiwane scenariusze
Prywatne punkty końcowe są włączone dla magazynu, ale są używane tylko do tworzenia kopii zapasowych i przywracania obciążeń SQL i SAP HANA na maszynie wirtualnej platformy Azure, kopii zapasowej agenta MARS i programu DPM. Możesz również użyć magazynu do tworzenia kopii zapasowych innych obciążeń (nie będą one jednak wymagały prywatnych punktów końcowych). Oprócz tworzenia kopii zapasowych obciążeń SQL i SAP HANA oraz tworzenia kopii zapasowych przy użyciu agenta MARS prywatne punkty końcowe są również używane do odzyskiwania plików na potrzeby tworzenia kopii zapasowych maszyn wirtualnych platformy Azure.
W poniższej tabeli wymieniono scenariusze i zalecenia:
| Scenariusz | Zalecenie |
|---|---|
| Tworzenie kopii zapasowych obciążeń na maszynie wirtualnej platformy Azure (SQL, SAP HANA), tworzenie kopii zapasowych przy użyciu agenta MARS, serwera DPM. | Zaleca się używanie prywatnych punktów końcowych, aby umożliwić tworzenie kopii zapasowych i przywracanie bez konieczności dodawania do listy dozwolonych adresów IP/nazw FQDN dla usługi Azure Backup lub Azure Storage z sieci wirtualnych. W tym scenariuszu upewnij się, że maszyny wirtualne hostujące bazy danych SQL mogą uzyskiwać dostęp do adresów IP firmy Microsoft lub nazw FQDN. |
| Kopia zapasowa maszyny wirtualnej platformy Azure | Tworzenie kopii zapasowej maszyny wirtualnej nie wymaga zezwolenia na dostęp do żadnych adresów IP ani nazw FQDN. Dlatego nie wymaga prywatnych punktów końcowych do tworzenia kopii zapasowych i przywracania dysków. Jednak odzyskiwanie plików z magazynu zawierającego prywatne punkty końcowe byłoby ograniczone do sieci wirtualnych, które zawierają prywatny punkt końcowy dla magazynu. W przypadku korzystania z dysków niezarządzanych listy ACL upewnij się, że konto magazynu zawierające dyski zezwala na dostęp do zaufanych usługi firmy Microsoft, jeśli jest to lista ACL. |
| Kopia zapasowa usługi Azure Files | Kopie zapasowe usługi Azure Files są przechowywane na lokalnym koncie magazynu. Nie wymaga to więc prywatnych punktów końcowych na potrzeby tworzenia kopii zapasowych i przywracania. |
Uwaga
Prywatne punkty końcowe są obsługiwane tylko w programie DPM Server 2022, MABS w wersji 4 i nowszych.
Różnica w połączeniach sieciowych dla prywatnych punktów końcowych
Jak wspomniano powyżej, prywatne punkty końcowe są szczególnie przydatne w przypadku tworzenia kopii zapasowych obciążeń (SQL, SAP HANA) na maszynach wirtualnych platformy Azure i kopiach zapasowych agenta MARS.
We wszystkich scenariuszach (z prywatnymi punktami końcowymi lub bez tych punktów końcowych) zarówno rozszerzenia obciążenia (na potrzeby tworzenia kopii zapasowych wystąpień SQL i SAP HANA działających wewnątrz maszyn wirtualnych platformy Azure), jak i agent MARS wykonuje wywołania połączenia z usługą Microsoft Entra ID (do nazw FQDN wymienionych w sekcjach 56 i 59 w usłudze Microsoft 365 Common and Office Online).
Oprócz tych połączeń, gdy rozszerzenie obciążenia lub agent MARS jest instalowany dla magazynu usługi Recovery Services bez prywatnych punktów końcowych, wymagana jest również łączność z następującymi domenami:
| Service | Nazwa domeny | Port |
|---|---|---|
| Azure Backup | *.backup.windowsazure.com |
443 |
| Azure Storage | *.blob.core.windows.net *.queue.core.windows.net *.blob.storage.azure.net |
443 |
| Identyfikator usługi Microsoft Entra | *.login.microsoft.com Zezwalaj na dostęp do nazw FQDN w sekcjach 56 i 59 zgodnie z tym artykułem. |
443 Zgodnie z obowiązującymi |
Po zainstalowaniu rozszerzenia obciążenia lub agenta MARS dla magazynu usługi Recovery Services z prywatnym punktem końcowym są przekazywane następujące punkty końcowe:
| Service | Nazwa domeny | Port |
|---|---|---|
| Azure Backup | *.privatelink.<geo>.backup.windowsazure.com |
443 |
| Azure Storage | *.blob.core.windows.net *.queue.core.windows.net *.blob.storage.azure.net |
443 |
| Identyfikator usługi Microsoft Entra | *.login.microsoft.com Zezwalaj na dostęp do nazw FQDN w sekcjach 56 i 59 zgodnie z tym artykułem. |
443 Zgodnie z obowiązującymi |
Uwaga
W powyższym tekście <geo> odwołuje się do kodu regionu (na przykład eus dla wschodnich stanów USA i ne dla Europy Północnej). Zapoznaj się z następującymi listami kodów regionów:
W przypadku magazynu usługi Recovery Services z konfiguracją prywatnego punktu końcowego rozpoznawanie nazw FQDN (privatelink.<geo>.backup.windowsazure.com, *.blob.core.windows.net, *.queue.core.windows.net, *.blob.storage.azure.net) powinno zwrócić prywatny adres IP. Można to osiągnąć za pomocą:
- Prywatne strefy DNS platformy Azure
- Niestandardowe DNS
- Wpisy DNS w plikach hosta
- Warunkowe usługi przesyłania dalej do usług Azure DNS/Azure Prywatna strefa DNS stref.
Prywatne mapowania adresów IP dla konta magazynu są wyświetlane w prywatnym punkcie końcowym utworzonym dla magazynu usługi Recovery Services. Zalecamy używanie stref usługi Azure Prywatna strefa DNS, ponieważ rekordy DNS dla obiektów blob i kolejek mogą być następnie zarządzane przez platformę Azure. Po przydzieleniu nowych kont magazynu rekord DNS dla ich prywatnego adresu IP jest dodawany automatycznie w strefach usługi Azure Prywatna strefa DNS obiektów blob lub kolejki.
Jeśli skonfigurowano serwer proxy DNS przy użyciu serwerów proxy lub zapór innych firm, powyższe nazwy domen muszą być dozwolone i przekierowywane do niestandardowego systemu DNS (który ma rekordy DNS dla powyższych nazw FQDN) lub do 168.63.129.16 w sieci wirtualnej platformy Azure, która ma połączone prywatne strefy DNS.
Poniższy przykład przedstawia zaporę platformy Azure używaną jako serwer proxy DNS do przekierowywania zapytań nazw domen dla magazynu, obiektu blob, kolejek i identyfikatora Entra firmy Microsoft do wersji 168.63.129.16.
Aby uzyskać więcej informacji, zobacz Tworzenie i używanie prywatnych punktów końcowych.
Łączność sieciowa dla magazynu z prywatnymi punktami końcowymi
Prywatny punkt końcowy usługi Recovery Services jest skojarzony z interfejsem sieciowym (NIC). Aby połączenia prywatnego punktu końcowego działały, cały ruch dla usługi platformy Azure musi zostać przekierowany do interfejsu sieciowego. Można to osiągnąć, dodając mapowanie DNS dla prywatnego adresu IP skojarzonego z interfejsem sieciowym względem adresu URL usługi/obiektu blob/kolejki.
Gdy rozszerzenia kopii zapasowej obciążenia są zainstalowane na maszynie wirtualnej zarejestrowanej w magazynie usługi Recovery Services z prywatnym punktem końcowym, rozszerzenie próbuje nawiązać połączenie pod prywatnym adresem URL usług <vault_id>.<azure_backup_svc>.privatelink.<geo>.backup.windowsazure.comAzure Backup.
Jeśli prywatny adres URL nie zostanie rozwiązany, podejmie próbę publicznego adresu URL <azure_backup_svc>.<geo>.backup.windowsazure.com. Jeśli dostęp do sieci publicznej dla magazynu usługi Recovery Services jest skonfigurowany do zezwalania ze wszystkich sieci, magazyn usługi Recovery Services zezwala na żądania pochodzące z rozszerzenia za pośrednictwem publicznych adresów URL. Jeśli dostęp do sieci publicznej dla magazynu usługi Recovery Services jest skonfigurowany na wartość Odmów, magazyn usługi Recovery Services odrzuca żądania pochodzące z rozszerzenia za pośrednictwem publicznych adresów URL.
Uwaga
W powyższych nazwach <geo> domen określa kod regionu (na przykład eus dla wschodnich stanów USA i ne dla Europy Północnej). Aby uzyskać więcej informacji na temat kodów regionów, zobacz następującą listę:
Te prywatne adresy URL są specyficzne dla magazynu. Tylko rozszerzenia i agenci zarejestrowani w magazynie mogą komunikować się z usługą Azure Backup za pośrednictwem tych punktów końcowych. Jeśli dostęp do sieci publicznej dla magazynu usługi Recovery Services jest skonfigurowany na wartość Odmów, ogranicza to klientów, którzy nie są uruchomione w sieci wirtualnej, od żądania operacji tworzenia kopii zapasowej i przywracania w magazynie. Zalecamy, aby dostęp do sieci publicznej został ustawiony na Wartość Odmów wraz z konfiguracją prywatnego punktu końcowego. Ponieważ rozszerzenie i agent spróbuje najpierw prywatny adres URL, *.privatelink.<geo>.backup.windowsazure.com rozpoznawanie adresu URL w systemie DNS powinno zwrócić odpowiedni prywatny adres IP skojarzony z prywatnym punktem końcowym.
Istnieje wiele rozwiązań do rozpoznawania nazw DNS:
- Prywatne strefy DNS platformy Azure
- Niestandardowe DNS
- Wpisy DNS w plikach hosta
- Warunkowe usługi przesyłania dalej do usług Azure DNS/Azure Prywatna strefa DNS stref.
Po utworzeniu prywatnego punktu końcowego dla magazynów usługi Recovery Services za pośrednictwem witryny Azure Portal z opcją Integracja z prywatną strefą DNS wymagane wpisy DNS dla prywatnych adresów IP dla usług Azure Backup (*.privatelink.<geo>backup.windowsazure.com) są tworzone automatycznie po przydzieleniu zasobu. W innych rozwiązaniach należy ręcznie utworzyć wpisy DNS dla tych nazw FQDN w niestandardowym systemie DNS lub w plikach hosta.
Aby uzyskać ręczne zarządzanie rekordami DNS po odnajdaniu maszyny wirtualnej dla kanału komunikacji — obiekt blob lub kolejka, zobacz Rekordy DNS dla obiektów blob i kolejek (tylko dla niestandardowych serwerów DNS/plików hosta) po pierwszej rejestracji. Aby uzyskać ręczne zarządzanie rekordami DNS po pierwszej kopii zapasowej dla obiektu blob konta magazynu kopii zapasowej, zobacz Rekordy DNS dla obiektów blob (tylko dla niestandardowych serwerów DNS/plików hosta) po pierwszej kopii zapasowej.
Prywatne adresy IP nazw FQDN można znaleźć w okienku konfiguracji DNS dla prywatnego punktu końcowego utworzonego dla magazynu usługi Recovery Services.
Na poniższym diagramie pokazano, jak działa rozpoznawanie podczas używania prywatnej strefy DNS do rozpoznawania tych nazw FQDN usługi prywatnej.
Rozszerzenie obciążenia uruchomione na maszynie wirtualnej platformy Azure wymaga połączenia z co najmniej dwoma punktami końcowymi kont magazynu — pierwszy jest używany jako kanał komunikacyjny (za pośrednictwem komunikatów kolejek) i drugi do przechowywania danych kopii zapasowej. Agent MARS wymaga dostępu do co najmniej jednego punktu końcowego konta magazynu używanego do przechowywania danych kopii zapasowej.
W przypadku magazynu z włączoną obsługą prywatnego punktu końcowego usługa Azure Backup tworzy prywatny punkt końcowy dla tych kont magazynu. Zapobiega to opuszczeniu sieci przez usługę Azure Backup (ruch płaszczyzny sterowania do usługi i tworzenie kopii zapasowych danych do obiektu blob magazynu). Oprócz usług w chmurze Azure Backup rozszerzenie obciążenia i agent wymagają łączności z kontami usługi Azure Storage i identyfikatorem Microsoft Entra.
Na poniższym diagramie przedstawiono sposób działania rozpoznawania nazw dla kont magazynu przy użyciu prywatnej strefy DNS.
