Mejores prácticas para configuraciones de aplicaciones web y SaaS
El acceso a las aplicaciones publicadas y no publicadas depende de las aplicaciones y directivas de acceso configuradas en el servicio Secure Private Access.
Acceso a aplicaciones dentro de Secure Private Access para aplicaciones publicadas y no publicadas
-
Acceso a aplicaciones web publicadas y dominios relacionados:
-
Cuando un usuario final accede a un FQDN asociado a una aplicación web publicada, el acceso solo se permite si se configura una directiva de acceso de forma explícita con la acción Permitir o Permitir con restricciones para el usuario.
Nota:
Se recomienda que varias aplicaciones no compartan el mismo dominio URL de la aplicación o dominios relacionados para obtener una coincidencia exacta. Si varias aplicaciones comparten el mismo dominio URL de la aplicación o dominios relacionados, el acceso se proporciona en función de la coincidencia exacta del FQDN y de la priorización de las directivas. Para más información, consulte Equiparación y priorización de directivas de acceso.
-
Si ninguna directiva de acceso coincide con la aplicación publicada o si una aplicación no está asociada a ninguna directiva de acceso, se deniega el acceso a la aplicación de forma predeterminada. Para obtener más información sobre las directivas de acceso, consulte Directivas de acceso.
-
-
Acceso a aplicaciones web internas no publicadas y URL de Internet externas:
Para habilitar la confianza cero, Secure Private Access niega el acceso a las direcciones URL de intranet o aplicaciones web internas que no estén asociadas a una aplicación y que no tengan una directiva de acceso configurada para la aplicación. Para permitir el acceso a usuarios específicos, asegúrese de tener una directiva de acceso configurada para las aplicaciones web de la intranet.
Para cualquier URL que no esté configurada como una aplicación en Secure Private Access, el tráfico fluye directamente a Internet.
- En estos casos, el acceso a los dominios URL de las aplicaciones web de la intranet se enruta directamente y, por lo tanto, se deniega el acceso (a menos que el usuario ya esté dentro de la intranet).
- En el caso de las URL de Internet no publicadas, el acceso se basa en las reglas configuradas para las aplicaciones no autorizadas, si están habilitadas. De forma predeterminada, este acceso está permitido en Secure Private Access. Para obtener más información, consulte Configurar reglas para sitios web no autorizados.
Equiparación y priorización de directivas de acceso
Secure Private Access hace lo siguiente al hacer coincidir una solicitud de acceso:
- Haga coincidir el dominio al que se accede con el dominio de la URL de la aplicación o con los dominios relacionados para obtener una coincidencia exacta.
-
Si se encuentra una aplicación de Secure Private Access configurada con un FQDN exacto, Secure Private Access evalúa todas las directivas configuradas para esa aplicación.
- Las directivas se evalúan en orden de prioridad hasta que el contexto del usuario coincida. La acción (permitir/denegar) se aplica según la primera directiva que coincida en el orden de prioridad.
- Si ninguna directiva coincide, se deniega el acceso de forma predeterminada.
-
Si no se encuentra una coincidencia exacta de FQDN, Secure Private Access busca el dominio basándose en la coincidencia más larga (por ejemplo, una coincidencia de caracteres comodín) para buscar las aplicaciones y las directivas correspondientes.
Ejemplo 1: Tenga en cuenta las siguientes configuraciones de aplicaciones y directivas:
Aplicación URL de la aplicación Dominio relacionado Intranet https://app.intranet.local
*.cdn.com wiki https://wiki.intranet.local
*.intranet.local Nombre de directiva Prioridad Aplicaciones de usuario y asociadas PolicyA Alto Eng-User5 (Intranet) PolicyB Bajo HR-User4 (Wiki) Si
HR-User4
accedeapp.intranet.local
, ocurre lo siguiente:- Secure Private Access busca en todas las directivas una coincidencia exacta con el dominio al que se accede,
app.intranet.local
en este caso. - Secure Private Access busca
PolicyA
y comprueba si las condiciones coinciden. - Como las condiciones no coinciden, Secure Private Access se detiene aquí y no continúa comprobando las coincidencias de los comodines, aunque
PolicyB
habría coincidido (ya queapp.intranet.local
coincide en el dominio relacionado de la aplicación Wiki de*.intranet.local
) y habría dado acceso. - Por lo tanto,
HR-User4
se niega el acceso a la aplicación Wiki.
Ejemplo 2: Considere la siguiente configuración de aplicaciones y directivas en las que se usa el mismo dominio en varias aplicaciones:
Aplicación URL de la aplicación Dominio relacionado App1 xyz.com app.intranet.local App2 app.intranet.local - Nombre de directiva Prioridad Aplicaciones de usuario y asociadas PolicyA Alto Eng-User 5 (Aplicación 1) PolicyB Bajo HR-User7 (Aplicación 2) Cuando el usuario
Eng-User5
acceda aapp.intranet.local
, tanto la App1 como la App2 coincidirán en función de la coincidencia exacta del FQDN y, por lo tanto, el usuarioEng-User5
tendrá acceso a través dePolicyA
.Sin embargo, si App1 tuviera
*.intranet.local
como dominio relacionado, se habría denegado el acceso paraEng-User5
, ya queapp.intranet.local
habría coincidido exactamente conPolicyB
, a la cual el usuarioEng-User5
no tiene acceso. - Secure Private Access busca en todas las directivas una coincidencia exacta con el dominio al que se accede,
Mejores prácticas de configuración de aplicaciones
Los dominios IDP deben tener una aplicación propia
En lugar de agregar dominios de IDP como dominios relacionados en las configuraciones de las aplicaciones de intranet, le recomendamos lo siguiente:
- Cree aplicaciones independientes para todos los dominios de IDP.
- Cree una directiva para permitir el acceso a todos los usuarios que necesitan acceder a la página de autenticación de IDP y mantenga la directiva como la máxima prioridad.
- Oculte esta aplicación (seleccionando la opción No mostrar el icono de la aplicación a los usuarios) de la configuración de la aplicación para que no aparezca en el espacio de trabajo. Para obtener más información, consulte Configurar los detalles de la aplicación.
Nota:
La configuración de esta aplicación solo permite el acceso a la página de autenticación de IDP. El acceso adicional a las aplicaciones individuales sigue dependiendo de las configuraciones de las aplicaciones individuales y de sus respectivas directivas de acceso.
Ejemplo de configuración:
-
Configure todos los FQDN comunes en sus propias aplicaciones, agrupándolos cuando corresponda.
Por ejemplo, si tiene algunas aplicaciones que usan Azure AD como IdP y necesita configurar
login.microsoftonline.com
y otros dominios relacionados (*.msauth.net
), haga lo siguiente:- Cree una única aplicación común con
https://login.microsoftonline.com
como URL de la aplicación y*.login.microsoftonline.com
y*.msauth.net
como dominios relacionados.
- Cree una única aplicación común con
- Seleccione la opción No mostrar el icono de la aplicación a los usuarios al configurar la aplicación. Para obtener más información, consulte Configurar los detalles de la aplicación.
- Cree una directiva de acceso para la aplicación común y permita el acceso a todos los usuarios. Para obtener más información, consulte Configurar una directiva de acceso.
- Asigne la máxima prioridad a la directiva de acceso. Para obtener más información, consulte Orden prioritario.
- Verifique los registros de diagnóstico para confirmar que el FQDN coincide con la aplicación y que la directiva se aplica según lo previsto.
Los mismos dominios relacionados no deben formar parte de varias aplicaciones
El dominio relacionado debe ser exclusivo de una aplicación. Las configuraciones conflictivas pueden provocar problemas de acceso a las aplicaciones. Si se configuran varias aplicaciones con el mismo FQDN o alguna variación del FQDN comodín, es posible que surjan los siguientes problemas:
- Los sitios web dejan de cargarse o pueden mostrar una página en blanco.
- La página Acceso bloqueado puede aparecer al acceder a una URL.
- Es posible que la página de inicio de sesión no se cargue.
Por lo tanto, recomendamos tener un dominio relacionado único para configurarlo en una sola aplicación.
Ejemplos de configuración incorrectos:
-
Ejemplo: dominios relacionados duplicados en varias aplicaciones
Supongamos que tiene 2 aplicaciones en las que ambas necesitan acceder a Okta (example.okta.com):
Aplicación dominio URL de la aplicación Dominio relacionado App1 https://code.example.net
example.okta.com App2 https://info.example.net
example.okta.com Nombre de directiva Prioridad Aplicaciones de usuario y asociadas Denegar App1 a HR Alto Grupo de usuarios HR
paraApp1
Otorgar a todos el acceso a la aplicación 1 Medio Habilitar el acceso al grupo de usuarios Everyone to App1 Otorgue a todos el acceso a App2 Bajo Habilitar el acceso al grupo de usuarios “Todos” a App2 Problema con la configuración: aunque la intención era dar acceso a todos los usuarios a App2, el grupo de usuarios HR no puede acceder a App2. El grupo de usuarios HR se redirige a Okta, pero se bloquea debido a la primera directiva que denegó el acceso a la App1 (que también tiene el mismo dominio relacionado
example.okta.com
que App2).Este escenario es muy común para los proveedores de identidad como Okta, pero también puede ocurrir con otras aplicaciones estrechamente integradas con dominios relacionados comunes. Para obtener más información sobre la coincidencia y priorización de directivas, consulte Equiparación y priorización de directivas de acceso.
Recomendación para la configuración anterior:
- Elimine example.okta.com como dominio relacionado de todas las aplicaciones.
- Crea una nueva aplicación solo para Okta (con la URL de la aplicación
https://example.okta.com
y un dominio relacionado de*.okta.com
). - Oculta esta aplicación del espacio de trabajo.
- Asigne la máxima prioridad a la directiva para eliminar cualquier conflicto.
Práctica óptima:
- Los dominios relacionados de una aplicación no deben superponerse con los dominios relacionados de otra aplicación.
- Si esto ocurre, se debe crear una nueva aplicación publicada para cubrir el dominio relacionado compartido y después el acceso debe configurarse en consecuencia.
- Los administradores deben evaluar si este dominio relacionado compartido debe aparecer como una aplicación real en Workspace.
- Si la aplicación no debe aparecer en Workspace, al publicarla, seleccione la opción No mostrar el icono de la aplicación a los usuarios para ocultarla de Workspace.
URL de enlace profundo
Para las URL de enlace profundo, se debe agregar el dominio URL de la aplicación de intranet como dominio relacionado:
Ejemplo:
La aplicación de intranet tiene una URL configurada con https://example.okta.com/deep-link-app-1
como dominio URL de la aplicación principal y el dominio relacionado tiene el dominio URL de la aplicación de intranet, es decir, *.issues.example.net
.
En este caso, cree por separado una aplicación de IdP con la URL https://example.okta.com
y después el dominio relacionado como *.example.okta.com
.