Sdílet prostřednictvím

Řešení potíží se zabezpečením a řízením přístupu ve službě Azure Data Factory a Synapse Analytics

  • Článek

PLATÍ PRO: Azure Data Factory Azure Synapse Analytics

Tip

Vyzkoušejte si službu Data Factory v Microsoft Fabric, řešení pro analýzy typu all-in-one pro podniky. Microsoft Fabric zahrnuje všechno od přesunu dat až po datové vědy, analýzy v reálném čase, business intelligence a vytváření sestav. Přečtěte si, jak začít používat novou zkušební verzi zdarma.

Tento článek popisuje běžné metody řešení potíží pro zabezpečení a řízení přístupu v kanálech Azure Data Factory a Synapse Analytics.

Běžné chyby a zprávy

Problém s připojením v aktivitě kopírování cloudového úložiště dat

Příznaky

V případě problémů s připojením ve zdroji nebo úložišti dat jímky se můžou vrátit různé chybové zprávy.

Příčina

Příčinou problému je obvykle jeden z následujících faktorů:

  • Nastavení proxy serveru v uzlu místního prostředí Integration Runtime (IR), pokud používáte místní prostředí IR.

  • Nastavení brány firewall v uzlu místního prostředí IR, pokud používáte místní prostředí IR.

  • Nastavení brány firewall v cloudovém úložišti dat.

Rozlišení

  • Pokud chcete zajistit, že se jedná o problém s připojením, zkontrolujte následující body:

    • Chyba se vyvolá ze zdrojových konektorů nebo konektorů jímky.
    • Selhání je na začátku aktivity kopírování.
    • Selhání je konzistentní pro prostředí Azure IR nebo místní prostředí IR s jedním uzlem, protože může se jednat o náhodnou chybu v místním prostředí IR s více uzly, pokud problém mají jenom některé uzly.

  • Pokud používáte místní prostředí IR, zkontrolujte nastavení proxy serveru, brány firewall a sítě, protože připojení ke stejnému úložišti dat může proběhnout úspěšně, pokud používáte prostředí Azure IR. Pokud chcete tento scénář vyřešit, projděte si následující informace:

  • Pokud používáte Azure IR, zkuste zakázat nastavení brány firewall úložiště dat. Tento přístup může tyto problémy vyřešit v následujících dvou situacích:

    • IP adresy Azure IR nejsou v seznamu povolených adres.
    • Funkce Povolit důvěryhodným služby Microsoft přístup k tomuto účtu úložiště je pro Azure Blob Storage a Azure Data Lake Storage Gen2 vypnutá.
    • Nastavení Povolit přístup ke službám Azure není pro Azure Data Lake Storage Gen1 povolené.

Pokud žádná z předchozích metod nefunguje, požádejte Microsoft o pomoc.

Odstraněný nebo odmítnutý privátní koncový bod stále zobrazuje aprroved v ADF

Příznaky

Vytvořili jste spravovaný privátní koncový bod z ADF a získali jste schválený privátní koncový bod. Po pozdějším odstranění nebo odmítnutí privátního koncového bodu ale spravovaný privátní koncový bod v ADF přetrvává a zobrazuje "Schváleno".

Příčina

ADF v současné době přestane po schválení vyžádat stav privátního koncového bodu. Stav zobrazený v ADF je proto zastaralý.

Rozlišení

Po odmítnutí nebo odstranění stávajících privátních koncových bodů ze zdrojových datových sad nebo datových sad jímky byste měli odstranit spravovaný privátní koncový bod v ADF.

Problém s neplatným nebo prázdným ověřovacím klíčem po zakázání přístupu k veřejné síti

Příznaky

Po zakázání přístupu k veřejné síti pro službu vyvolá místní prostředí Integration Runtime následující chyby: The Authentication key is invalid or empty.Cannot connect to the data factory. Please check whether the factory has enabled public network access or the machine is hosted in a approved private endpoint Virtual Network.

Příčina

Příčinou problému je pravděpodobně problém s překladem DNS (Domain Name System), protože zakázání veřejného připojení a navázání privátního koncového bodu brání opětovnému připojení.

Pokud chcete ověřit, jestli se plně kvalifikovaný název domény (FQDN) služby přeloží na veřejnou IP adresu, postupujte takto:

  1. Ověřte, že jste vytvořili virtuální počítač Azure ve stejné virtuální síti jako privátní koncový bod služby.

  2. Spusťte Příkaz PsPing a Ping z virtuálního počítače Azure do plně kvalifikovaného názvu domény služby:

    psping.exe <dataFactoryName>.<region>.datafactory.azure.net:443 ping <dataFactoryName>.<region>.datafactory.azure.net

    Poznámka:

    Musíte zadat port pro příkaz PsPing. Tady se zobrazuje port 443, ale nevyžaduje se.

  3. Zkontrolujte, jestli se oba příkazy překládají na veřejnou IP adresu služby Azure Data Factory, která je založená na zadané oblasti. IP adresa by měla být v následujícím formátu: xxx.xxx.xxx.0

Rozlišení

Pokud chcete tento problém vyřešit, postupujte takto:

  • Jako možnost bychom vám chtěli navrhnout, abyste pro službu ručně přidali odkaz na virtuální síť pod zónou DNS privátního propojení. Podrobnosti najdete v článku o službě Azure Private Link . Instrukce slouží ke konfiguraci privátní zóny DNS nebo vlastního serveru DNS pro překlad plně kvalifikovaného názvu domény služby na privátní IP adresu.

  • Pokud ale nechcete konfigurovat privátní zónu DNS nebo vlastní server DNS, zkuste následující dočasné řešení:

    1. Změňte soubor hostitele ve Windows a namapujte privátní IP adresu (privátní koncový bod služby) na plně kvalifikovaný název domény služby.

      Na virtuálním počítači Azure přejděte na C:\Windows\System32\drivers\etcsoubor hostitele a otevřete ho v Poznámkovém bloku. Přidejte řádek, který mapuje privátní IP adresu na plně kvalifikovaný název domény na konci souboru, a uložte změnu.

      Snímek obrazovky s mapováním privátní IP adresy na hostitele

    2. Znovu spusťte stejné příkazy jako v předchozích krocích ověření a zkontrolujte odpověď, která by měla obsahovat privátní IP adresu.

    3. Znovu zaregistrujte místní prostředí Integration Runtime a problém by se měl vyřešit.

Příznaky

Nemůžete zaregistrovat ověřovací klíč prostředí IR na místním virtuálním počítači, protože je povolené privátní propojení. Zobrazí se tato chybová zpráva:

Nepodařilo se získat token služby ze služby ADF s klíčem *************** a časové náklady jsou: 0.1250079 sekunda, kód chyby je: InvalidGatewayKey, activityId je: XXXXXXX a podrobná chybová zpráva: IP adresa klienta není platná privátní IP adresa, protože data factory nemohla získat přístup k veřejné síti, takže se nemůže spojit s cloudem, aby bylo úspěšné připojení."

Příčina

Příčinou problému může být virtuální počítač, ve kterém se pokoušíte nainstalovat místní prostředí IR. Pokud se chcete připojit ke cloudu, ujistěte se, že je povolený přístup k veřejné síti.

Rozlišení

Řešení 1

Pokud chcete tento problém vyřešit, postupujte takto:

  1. Přejděte na stránku Továrny – aktualizace .

  2. V pravém horním rohu vyberte tlačítko Vyzkoušet .

  3. V části Parametry vyplňte požadované informace.

  4. V části Text vložte následující vlastnost:

    { "tags": { "publicNetworkAccess":"Enabled" } }

  5. Vyberte Spustit , aby se funkce spustila.

  6. V části Parametry vyplňte požadované informace.

  7. V části Text vložte následující vlastnost:

    { "tags": { "publicNetworkAccess":"Enabled" } }

  8. Vyberte Spustit , aby se funkce spustila.

  9. Ověřte, že se zobrazí kód odpovědi: 200 . Vlastnost, kterou jste vložili, by se měla zobrazit i v definici JSON.

  10. Znovu přidejte ověřovací klíč prostředí IR v prostředí Integration Runtime.

Řešení 2

Pokud chcete tento problém vyřešit, přejděte na Azure Private Link.

Zkuste povolit přístup k veřejné síti v uživatelském rozhraní, jak je znázorněno na následujícím snímku obrazovky:

Privátní zóna DNS služby přepisuje překlad DNS Azure Resource Manageru, což způsobuje chybu Nenalezena

Příčina

Azure Resource Manager i služba používají stejnou privátní zónu, která vytváří potenciální konflikt v privátním DNS zákazníka se scénářem, kdy se záznamy Azure Resource Manageru nenajdou.

Rozlišení

  1. Vyhledání Privátní DNS zón privatelink.azure.com na webu Azure Portal Snímek obrazovky s hledáním Privátní DNS zón
  2. Zkontrolujte, jestli existuje adf záznamu A. Snímek obrazovky záznamu A
  3. Přejděte na propojení virtuální sítě a odstraňte všechny záznamy. Snímek obrazovky s propojením virtuální sítě
  4. Přejděte ke službě na webu Azure Portal a znovu vytvořte privátní koncový bod pro portál. Snímek obrazovky s opětovnou vytvářením privátního koncového bodu
  5. Vraťte se do Privátní DNS zón a zkontrolujte, jestli existuje nová privatelink.adf.azure.com privátní zóny DNS. Snímek obrazovky s novým záznamem DNS

Chyba připojení ve veřejném koncovém bodu

Příznaky

Při kopírování dat s veřejným přístupem účtu služby Azure Blob Storage se kanál náhodně nezdaří s následující chybou.

Příklad: Jímka služby Azure Blob Storage používala prostředí Azure IR (veřejné, ne spravované virtuální sítě) a zdroj služby Azure SQL Database používal spravované prostředí VNet IR. Nebo zdroj/jímka používají spravované prostředí IR virtuální sítě pouze s veřejným přístupem k úložišti.

<LogProperties><Text>Invoke callback url with req: "ErrorCode=AzureBlobFailedToCreateContainer,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Unable to create Azure Blob container. Endpoint: XXXXXXX/, Container Name: test.,Source=Microsoft.DataTransfer.ClientLibrary,''Type=Microsoft.WindowsAzure.Storage.StorageException,Message=Unable to connect to the remote server,Source=Microsoft.WindowsAzure.Storage,''Type=System.Net.WebException,Message=Unable to connect to the remote server,Source=System,''Type=System.Net.Sockets.SocketException,Message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond public ip:443,Source=System,'","Details":null}}</Text></LogProperties>.

Příčina

Služba může dál používat spravované prostředí VNet IR, ale můžete narazit na takovou chybu, protože veřejný koncový bod pro Azure Blob Storage ve spravované virtuální síti není spolehlivý na základě výsledku testování a Azure Blob Storage a Azure Data Lake Gen2 se nepodporují připojení prostřednictvím veřejného koncového bodu ze spravované virtuální sítě služby v závislosti na spravovaných privátních koncových bodech spravované virtuální sítě.

Rozlišení

  • Privátní koncový bod je povolený na zdrojovém i bočním panelu jímky při použití spravovaného prostředí VNet IR.
  • Pokud stále chcete použít veřejný koncový bod, můžete místo použití spravovaného prostředí VNet IR pro zdroj a jímku přepnout na veřejné prostředí IR. I když přepnete zpátky na veřejné prostředí IR, může služba dál používat spravované prostředí VNet IR, pokud je prostředí IR spravované virtuální sítě stále k dispozici.

Vnitřní chyba při pokusu o odstranění datové továrny nebo pracovního prostoru Synapse pomocí klíče spravovaného zákazníkem (CMK) a spravované identity přiřazené uživatelem (UA-MI)

Příznaky

{\"error\":{\"code\":\"InternalError\",\"message\":\"Internal error has occurred.\"}}

Příčina

Pokud provádíte nějaké operace související s CMK, měli byste nejprve dokončit všechny operace související se službou a pak externí operace (jako jsou spravované identity nebo operace služby Key Vault). Pokud například chcete odstranit všechny prostředky, musíte nejprve odstranit instanci služby a pak odstranit trezor klíčů. Pokud nejprve odstraníte trezor klíčů, dojde k této chybě, protože služba už nemůže číst požadované objekty a nebude moct ověřit, jestli je odstranění možné nebo ne.

Rozlišení

Tento problém můžete vyřešit třemi způsoby. Jsou to následující:

  • Odvolali jste přístup služby k trezoru klíčů, ve kterém byl klíč CMK uložený. Přístup můžete znovu přiřadit k následujícím oprávněním: Get, Unwrap Key a Wrap Key. Tato oprávnění jsou nutná k povolení klíčů spravovaných zákazníkem. Informace o udělení přístupu ke klíčům spravovaným zákazníkem najdete v tématu Udělení přístupu ke klíčům spravovaným zákazníkem. Po poskytnutí oprávnění byste měli být schopni službu odstranit.

  • Zákazník odstranil službu Key Vault nebo CMK před odstraněním služby. Klíč CMK ve službě by měl mít povolenou možnost Obnovitelné odstranění a vyprázdnit ochranu, která má výchozí zásady uchovávání informací o 90 dnech. Odstraněný klíč můžete obnovit.
    Zkontrolujte, jak obnovit odstraněný klíč a odstraněnou hodnotu klíče.

  • Spravovaná identita přiřazená uživatelem (UA-MI) byla před službou odstraněna. Z toho můžete provést obnovení pomocí volání rozhraní REST API, můžete to provést v klientovi HTTP podle vašeho výběru v libovolném programovacím jazyce. Pokud jste ještě nic nenastavili pro volání rozhraní REST API s ověřováním Azure, nejjednodušší způsob, jak to udělat, je použít POSTMAN/Fiddler. Postupujte podle následujících kroků.

    1. Volání GET pomocí metody: ADRESA URL GET, například https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

    2. Potřebujete vytvořit novou identitu spravovanou uživatelem s jiným názvem (stejný název může fungovat, ale jen abyste měli jistotu, že je bezpečnější použít jiný název než ten v odpovědi GET).

    3. Upravte vlastnost encryption.identity a identity.userassignedidentities tak, aby odkazovaly na nově vytvořenou spravovanou identitu. Odeberte clientId a principalId z objektu userAssignedIdentity.

    4. Volání PUT se stejnou adresou URL předá novému textu. Je velmi důležité, abyste předali vše, co jste získali v odpovědi GET, a upravte pouze identitu. Jinak by přepsali jiná nastavení neúmyslně.

    5. Po úspěšném volání budete moct entity znovu zobrazit a zkusit je odstranit znovu.

Sdílení místního prostředí Integration Runtime

Sdílení místního prostředí IR z jiného tenanta se nepodporuje.

Příznaky

Při pokusu o sdílení místního prostředí IR z uživatelského rozhraní si můžete všimnout jiných datových továren (v různých tenantech), ale nemůžete ho sdílet mezi datovými továrnami, které jsou v různých tenantech.

Příčina

Místní prostředí IR nejde sdílet mezi tenanty.

Související obsah

Další pomoc s řešením potíží najdete v následujících zdrojích informací: