Compartir a través de

Solución de problemas de seguridad y control de acceso en Azure Data Factory y Synapse Analytics

  • Artículo

SE APLICA A: Azure Data Factory Azure Synapse Analytics

Sugerencia

Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.

En este artículo se exploran los métodos comunes de solución de problemas de seguridad y control de acceso en canalizaciones de Azure Data Factory y Synapse Analytics.

Errores habituales y mensajes

Problema de conectividad en la actividad de copia del almacén de datos en la nube

Síntomas

Es posible que se devuelvan varios mensajes de error cuando se produzcan problemas de conectividad en el almacén de datos de origen o receptor.

Causa

En general, la causa del problema es uno de los siguientes factores:

  • La configuración del proxy en el nodo del entorno de ejecución de integración (IR) autohospedado, si usa un IR autohospedado.

  • La configuración del firewall en el nodo del IR autohospedado, si usa un IR autohospedado.

  • La configuración del firewall en el almacén de datos en la nube.

Solución

  • Para asegurarse de que se trate de un problema de conectividad, compruebe los puntos siguientes:

    • El error se produce desde los conectores de origen o receptor.
    • El error se produce al principio de la actividad de copia.
    • El error es uniforme para Azure IR o el IR autohospedado con un nodo, porque podría tratarse de un error aleatorio en un IR autohospedado de varios nodos si solo algunos de los nodos tienen el problema.

  • Si usa un IR autohospedado, compruebe la configuración del proxy, del firewall y de red, ya que la conexión al mismo almacén de datos puede realizarse correctamente si usa Azure IR. Para solucionar esta escenario, consulte:

  • Si usa Azure IR, pruebe a deshabilitar la configuración de firewall del almacén de datos. Este enfoque puede resolver los problemas en las dos situaciones siguientes:

    • Las direcciones IP de Azure IR no están en la lista de permitidos.
    • La característica Permitir que los servicios de Microsoft de confianza accedan a esta cuenta de almacenamiento está desactivada para Azure Blob Storage y Azure Data Lake Storage Gen2.
    • La opción Permitir el acceso a servicios de Azure no está habilitada para Azure Data Lake Storage Gen1.

Si no funciona ninguno de los métodos anteriores, póngase en contacto con Microsoft para obtener ayuda.

Un punto de conexión privado eliminado o rechazado sigue apareciendo como aprobado en ADF

Síntomas

Ha creado un punto de conexión privado administrado a partir de ADF y ha obtenido un punto de conexión privado aprobado. Pero, después de eliminar o rechazar el punto de conexión privado más adelante, en ADF el punto de conexión privado administrado no desaparece y se muestra el mensaje "Aprobado".

Causa

Actualmente, ADF deja de extraer el estado del punto de conexión privado después de que este se aprueba. Por consiguiente, el estado que se muestra en ADF está obsoleto.

Solución

Debe eliminar el punto de conexión privado administrado en ADF una vez que los puntos de conexión privados existentes se rechazan o eliminan de los conjuntos de datos del origen o receptor.

Problema de clave de autenticación vacía o no válida después de deshabilitar el acceso a la red pública

Síntomas

Después de deshabilitar el acceso a la red pública para el servicio, el entorno de ejecución de integración autohospedado produce los siguientes errores: The Authentication key is invalid or empty. o 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.

Causa

Lo más probable es que el problema se deba a una incidencia en la resolución del sistema de nombres de dominio (DNS), ya que la deshabilitación de la conectividad pública y el establecimiento de un punto de conexión privado impide la reconexión.

Para comprobar si el nombre de dominio completo (FQDN) del servicio se resuelve en la dirección IP pública, haga lo siguiente:

  1. Confirme que ha creado la máquina virtual (VM) de Azure en la misma red virtual que el punto de conexión privado del servicio.

  2. Ejecute PsPing y Ping desde la VM de Azure hasta el FQDN del servicio:

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

    Nota

    Debe especificar un puerto para el comando PsPing. Aquí se muestra el puerto 443, pero no es obligatorio.

  3. Compruebe si ambos comandos se resuelven en una dirección IP pública de Azure Data Factory que se base en una región especificada. La dirección IP debe tener el siguiente formato: xxx.xxx.xxx.0.

Solución

Para solucionar el problema, haga lo siguiente:

  • Como opción, nos gustaría sugerirle que agregue manualmente un "vínculo de Virtual Network" en la "zona DNS de vínculo privado" para el servicio. Para más información, consulte el artículo Azure Private Link. La instrucción es para configurar el servidor DNS personalizado o la zona DNS privada para resolver el FQDN del servicio en una dirección IP privada.

  • Sin embargo, si no quiere configurar ninguno de estos, pruebe la siguiente solución temporal:

    1. Cambie el archivo de host en Windows y asigne la dirección IP privada (el punto de conexión privado del servicio) al FQDN del servicio.

      En la VM de Azure, vaya a C:\Windows\System32\drivers\etc y, a continuación, abra el archivo host en el Bloc de notas. Agregue la línea que asigna la dirección IP privada al FQDN al final del archivo y guarde el cambio.

      Captura de pantalla de la asignación de la dirección IP privada al host.

    2. Vuelva a ejecutar los mismos comandos que en los pasos de comprobación anteriores para verificar la respuesta, que debe contener la dirección IP privada.

    3. Vuelva a registrar el entorno de ejecución de integración autohospedado, el problema debería haberse resuelto.

Síntomas

No se puede registrar la clave de autenticación de IR en la VM autohospedada porque la conexión privada está habilitada. Aparece el siguiente mensaje de error:

"No se pudo obtener el token de servicio del servicio de ADF con la clave *************** y un costo de tiempo de 0,1250079 segundos. Código de error: InvalidGatewayKey; activityId: XXXXXXX; mensaje de error detallado: La dirección IP de cliente no es una dirección IP privada válida porque Data Factory no pudo acceder a la red pública, por lo que no se puede comunicar con la nube para establecer la conexión correcta.

Causa

El problema puede deberse a la VM en la que está intentando instalar el IR autohospedado. Para conectarse a la nube, asegúrese de que está habilitado el acceso a la red pública.

Solución

Solución 1

Para solucionar el problema, haga lo siguiente:

  1. Vaya a la página Factories - Update.

  2. En la esquina superior derecha, seleccione el botón Pruébelo.

  3. En Parámetros, complete la información necesaria.

  4. En Cuerpo, pegue la siguiente propiedad:

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

  5. Seleccione Ejecutar para ejecutar la función.

  6. En Parámetros, complete la información necesaria.

  7. En Cuerpo, pegue la siguiente propiedad:

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

  8. Seleccione Ejecutar para ejecutar la función.

  9. Confirme que aparezca Código de respuesta: 200. La propiedad que pegó también debe aparecer en la definición de JSON.

  10. Agregue de nuevo la clave de autenticación del IR al entorno de ejecución de integración.

Solución 2

Para resolver el problema, vaya a Azure Private Link.

Pruebe a habilitar el acceso a la red pública en la interfaz de usuario, como se muestra en la siguiente captura de pantalla:

La zona DNS privada del servicio invalida la resolución DNS de Azure Resource Manager y causa el error "No encontrado".

Causa

Tanto Azure Resource Manager como el servicio usan la misma zona privada, lo que crea un posible conflicto en el DNS privado del cliente con un escenario en el que no se encontrarán los registros de Azure Resource Manager.

Solución

  1. Busque las zonas DNS privadas privatelink.Azure.com en Azure Portal. Captura de pantalla de la búsqueda de zonas DNS privadas.
  2. Compruebe si hay un registro A adf. Captura de pantalla de un registro A.
  3. Vaya a Vínculos de red virtual y elimine todos los registros. Captura de pantalla del vínculo de red virtual.
  4. Vaya al servicio en Azure Portal y vuelva a crear el punto de conexión privado para el portal. Captura de pantalla de la recreación del punto de conexión privado.
  5. Vuelva a las zonas DNS privadas y compruebe si hay una nueva zona DNS privada privatelink.adf.azure.com. Captura de pantalla del nuevo registro DNS.

Error de conexión en el punto de conexión público

Síntomas

Al copiar datos con la cuenta de acceso público de Azure Blob Storage, el siguiente error se produce de forma aleatoria en las ejecuciones de canalización.

Por ejemplo: en el receptor de Azure Blob Storage se usaba Azure IR (red virtual pública y no administrada) y en el origen de Azure SQL Database IR de red virtual administrada. O bien en el origen o el receptor solo se usa IR de red virtual administrada con acceso público de almacenamiento.

<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>.

Causa

El servicio todavía puede usar IR de red virtual administrada, pero podría encontrar este error porque el punto de conexión público para Azure Blob Storage en la red virtual administrada no es confiable según el resultado de la prueba, y no se admiten Azure Blob Storage ni Azure Data Lake Gen2 para conectarse mediante un punto de conexión público de la red virtual administrada del servicio, de acuerdo a Red virtual administrada y puntos de conexión privados administrados.

Solución

  • Habilite el punto de conexión privado en el origen y también el lado del receptor cuando se use IR de la red virtual administrada.
  • Si todavía quiere usar el punto de conexión público, puede cambiar a solo IR público en lugar de usar IR de red virtual administrada para el origen y el receptor. Incluso si cambia de nuevo a IR público, el servicio todavía puede usar IR de red virtual administrada en caso de que siga presente.

Error interno al intentar eliminar una factoría de datos o un área de trabajo de Synapse con una clave administrada por el cliente (CMK) y una identidad administrada asignada por el usuario (UA-MI)

Síntomas

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

Causa

Si está realizando alguna operación relacionada con CMK, primero debe llevar a cabo todas las operaciones relacionadas con el servicio y luego las operaciones externas (como las operaciones de identidades administradas o de Key Vault). Por ejemplo, si desea eliminar todos los recursos, primero debe eliminar la instancia de servicio y, a continuación, eliminar el almacén de claves. Si elimina primero el almacén de claves, este error se producirá porque el servicio ya no puede leer los objetos necesarios y no podrá validar si la eliminación es posible o no.

Solución

Hay tres formas posibles de solucionar el problema. Los pasos son los siguientes:

  • Ha revocado el acceso del servicio al almacén de claves donde estaba almacenada la clave de CMK. Puede volver a asignar acceso a los siguientes permisos: Obtener, Desencapsular clave y Encapsular clave. Estos permisos son necesarios para habilitar las claves administradas por el cliente. Consulte Obtención de acceso a las claves administradas por el cliente. Una vez que se ha proporcionado el permiso, se debería poder eliminar el servicio.

  • El cliente ha eliminado Key Vault o CMK antes de eliminar el servicio. CMK en el servicio debe tener habilitadas la "eliminación temporal" y la "protección de purga", que tiene una directiva de retención predeterminada de 90 días. Puede restaurar la clave eliminada.
    Vea Recuperación de clave eliminada y Valor de clave eliminado

  • La identidad administrada asignada por el usuario (UA-MI) se ha eliminado antes que el servicio. Puede recuperarse de esto mediante llamadas API de REST. Puede hacerlo en un cliente http de su elección en cualquier lenguaje de programación. Si aún no tiene nada configurado para las llamadas API de REST con autenticación de Azure, la manera más fácil de hacerlo sería mediante Fiddler. Siga estos pasos.

    1. Realización de una llamada GET mediante el método: dirección URL de GET como https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

    2. Debe crear una nueva identidad administrada de usuario con otro nombre (el mismo nombre puede funcionar, pero es más seguro usar un nombre diferente al de la respuesta GET)

    3. Modifique las propiedades encryption.identity e identity.userassignedidentities para que apunten a la identidad administrada recién creada. Quite clientId y principalId del objeto userAssignedIdentity.

    4. Realice una llamada PUT a la misma dirección URL con el nuevo cuerpo. Es importante que pase lo que haya obtenido en la respuesta GET y solo modifique la identidad. De lo contrario, se invalidarían otras configuraciones de forma involuntaria.

    5. Una vez que la llamada se realiza correctamente, se pueden ver las entidades de nuevo y volver a intentar eliminar.

Uso compartido de IR autohospedado

No se admite el uso compartido de un IR autohospedado desde un inquilino diferente

Síntomas

Es posible que observe otras factorías de datos (en diferentes inquilinos) al intentar compartir el IR autohospedado desde la interfaz de usuario, pero no puede compartirlo entre factorías de datos que se encuentran en distintos inquilinos.

Causa

El IR autohospedado no puede compartirse entre inquilinos.

Contenido relacionado

Para obtener más ayuda para solucionar problemas, pruebe los siguientes recursos: