Protección de aplicaciones con el control de aplicaciones de acceso condicional de Microsoft Defender for Cloud Apps

Nota

  • Hemos cambiado el nombre de Microsoft Cloud App Security. Ahora se llama Microsoft Defender for Cloud Apps. En las próximas semanas, actualizaremos las capturas de pantalla y las instrucciones aquí y en las páginas relacionadas. Para obtener más información sobre el cambio, consulte este anuncio. Para obtener más información sobre el cambio de nombre reciente de los servicios de seguridad de Microsoft, consulte el blog seguridad de Microsoft Ignite.

  • Microsoft Defender for Cloud Apps ahora forma parte de Microsoft 365 Defender. El portal de Microsoft 365 Defender permite a los administradores de seguridad realizar sus tareas de seguridad en una ubicación. Esto simplificará los flujos de trabajo y agregará la funcionalidad de los demás servicios Microsoft 365 Defender. Microsoft 365 Defender será el hogar de la supervisión y administración de la seguridad en las identidades, los datos, los dispositivos, las aplicaciones y la infraestructura de Microsoft. Para obtener más información sobre estos cambios, consulte Microsoft Defender for Cloud Apps en Microsoft 365 Defender.

En el área de trabajo actual, a menudo no es suficiente saber lo que sucede en su entorno de nube después del hecho. Le interesa detener las infracciones de seguridad y las fugas en tiempo real, antes de que los empleados intencionadamente o por accidente pongan los datos y la organización en riesgo. Es importante permitir que los usuarios de su organización puedan sacar el máximo partido de los servicios y las herramientas disponibles para ellos en aplicaciones en la nube y permitirles que traigan sus propios dispositivos para que funcionen. Al mismo tiempo, se necesitan herramientas que permitan proteger la organización de fugas o robos de datos en tiempo real. Microsoft Defender for Cloud Apps se integra con cualquier proveedor de identidades (IdP) para ofrecer estas funcionalidades con controles de acceso y sesión. Si usa Azure Active Directory (Azure AD) como idP, estos controles se integran y simplifican para una implementación más sencilla y personalizada basada en la herramienta de acceso condicional de Azure AD.

Nota

  • Además de una licencia válida de Defender for Cloud Apps, para usar Defender for Cloud Apps Conditional Access App Control, también necesita una licencia Azure Active Directory P1 o la licencia requerida por la solución IdP.

Cómo funciona

El control de aplicaciones de acceso condicional usa una arquitectura de proxy inverso y se integra con el IdP. Al integrar con el acceso condicional de Azure AD, puede configurar aplicaciones para que funcionen con el control de aplicaciones de acceso condicional con tan solo unos pocos clics, lo que le permite aplicar de forma sencilla y selectiva controles de acceso y sesión en las aplicaciones de la organización en función de cualquier condición en el acceso condicional. Las condiciones definen a quién (usuario o grupo de usuarios) y a qué (qué aplicaciones en la nube) y dónde (a qué ubicaciones y redes) se aplica una directiva de acceso condicional. Después de determinar las condiciones, puede enrutar a los usuarios a Defender for Cloud Aplicaciones, donde puede proteger los datos con control de aplicaciones de acceso condicional mediante la aplicación de controles de acceso y sesión.

Control de aplicaciones de acceso condicional permite supervisar y controlar las sesiones y el acceso a las aplicaciones de usuario en tiempo real, en función de las directivas de acceso y de sesión. Las directivas de acceso y de sesión se usan en el portal Defender for Cloud Apps para refinar los filtros y establecer las acciones que deben realizarse en un usuario. Con las directivas de acceso y de sesión, puede:

  • Impedir la filtración de datos: puede bloquear la descarga, cortar, copiar e imprimir documentos confidenciales, por ejemplo, dispositivos no administrados.

  • Requerir contexto de autenticación: puede volver a evaluar las directivas de acceso condicional de Azure AD cuando se produce una acción confidencial en la sesión. Por ejemplo, requiere la autenticación multifactor en la descarga de un archivo altamente confidencial.

  • Proteger al descargar: en lugar de bloquear la descarga de documentos confidenciales, puede requerir que los documentos se etiqueten y cifren al integrar con Microsoft Purview Information Protection. Esta acción garantiza que el documento está protegido y el acceso de usuario está restringido en una sesión de riesgo potencial.

  • Impedir la carga de archivos sin etiquetar: antes de que otros usuarios carguen, distribuyan y usen un archivo confidencial, es importante asegurarse de que el archivo confidencial tenga la etiqueta definida por la directiva de la organización. Puede asegurarse de que los archivos sin etiqueta con contenido confidencial se bloqueen para que no se carguen hasta que el usuario clasifique el contenido.

  • Bloquear malware potencial: puede proteger su entorno frente a malware bloqueando la carga de archivos potencialmente malintencionados. Cualquier archivo que se cargue o descargue se puede examinar en contra de la inteligencia sobre amenazas de Microsoft y bloquearse de forma instantánea.

  • Supervisar las sesiones de usuario para el cumplimiento: los usuarios de riesgo se supervisan cuando inician sesión en las aplicaciones y sus acciones se registran desde dentro de la sesión. Puede investigar y analizar el comportamiento del usuario para saber dónde se deben aplicar las directivas de sesión en el futuro, y en qué condiciones.

  • Bloquear acceso: puede bloquear de forma granular el acceso a aplicaciones y usuarios específicos en función de varios factores de riesgo. Por ejemplo, puede bloquearlos si usan certificados de cliente como forma de administración de dispositivos.

  • Bloquear actividades personalizadas: algunas aplicaciones tienen escenarios únicos que conllevan riesgos, por ejemplo, el envío de mensajes con contenido confidencial en aplicaciones como Microsoft Teams o Slack. En estos tipos de escenarios, puede examinar los mensajes para detectar el contenido confidencial y bloquearlos en tiempo real.

Funcionamiento del control de sesión

Al crear una directiva de sesión con control de aplicaciones de acceso condicional, podrá controlar las sesiones de usuario redirigiendo al usuario en cuestión a través de un proxy inverso, en lugar de directamente a la aplicación. A partir de entonces, las solicitudes y respuestas de los usuarios pasan por Defender for Cloud Aplicaciones en lugar de directamente a la aplicación.

Cuando una sesión está protegida por proxy, todas las direcciones URL y cookies pertinentes se reemplazan por Defender for Cloud Apps. Por ejemplo, si la aplicación devuelve una página con vínculos cuyos dominios terminan con myapp.com, el dominio del vínculo tiene un sufijo similar *.mcas.msa , como se indica a continuación:

Dirección URL de la aplicación Dirección URL reemplazada
myapp.com myapp.com.mcas.ms

Este método no requiere que instale nada en el dispositivo, lo que lo hace ideal al supervisar o controlar sesiones de dispositivos no administrados o usuarios asociados.

Nota

  • Nuestra tecnología usa la heurística patentada de la mejor clase para identificar y controlar las actividades realizadas por el usuario en la aplicación de destino. Nuestra heurística está diseñada para optimizar y equilibrar la seguridad con facilidad de uso. En algunos escenarios poco frecuentes, cuando el bloqueo de actividades en el lado servidor representa la aplicación inutilizable, protegemos estas actividades solo en el lado cliente, lo que hace que sean potencialmente susceptibles de explotación por parte de usuarios internos malintencionados.
  • Defender for Cloud Apps aprovecha centros de datos de Azure en todo el mundo para proporcionar un rendimiento optimizado a través de la geolocalización. Esto significa que la sesión de un usuario se puede hospedar fuera de una región determinada, dependiendo de los patrones de tráfico y su ubicación. Sin embargo, para proteger su privacidad, no se almacenan datos de la sesión en estos centros de datos.
  • Nuestros servidores proxy no almacenan datos en reposo. Al almacenar en caché el contenido, seguimos los requisitos establecidos en RFC 7234 (almacenamiento en caché HTTP) y solo almacenamos en caché el contenido público.

Identificación de dispositivos administrados

La característica Control de aplicaciones de acceso condicional le permite crear directivas que tienen en cuenta si un dispositivo está administrado o no. Para identificar el estado de un dispositivo, puede configurar las directivas de acceso y de sesión para comprobar lo siguiente:

  • Microsoft Intune dispositivos compatibles [solo disponibles con Azure AD]
  • Dispositivos unidos a Azure AD híbrido (solo disponible con Azure AD)
  • Presencia de certificados de cliente en una cadena de confianza

Intune dispositivos compatibles y unidos a Azure AD híbrido

El acceso condicional de Azure AD permite pasar Intune información del dispositivo unido a Azure AD híbrido y compatible directamente a Defender for Cloud Apps. Desde allí, se puede desarrollar una directiva de sesión o acceso que use el estado del dispositivo como filtro. Para obtener más información, consulte Introducción a la administración de dispositivos en Azure Active Directory.

Nota

Algunos exploradores pueden requerir una configuración adicional, como la instalación de una extensión. Para obtener más información, consulte Compatibilidad con el explorador de acceso condicional.

Dispositivos autenticados con certificado de cliente

El mecanismo de identificación de dispositivos puede solicitar la autenticación de los dispositivos que usan certificados de cliente. Puede usar certificados de cliente existentes ya implementados en la organización o implantar nuevos certificados de cliente a los dispositivos administrados. Asegúrese de que el certificado de cliente está instalado en el almacén de usuarios y no en el almacén del equipo. Después utilizará la presencia de esos certificados para establecer directivas de acceso y sesión.

Los certificados de cliente SSL se comprueban a través de una cadena de confianza. Puede cargar una entidad de certificación (CA) raíz X.509 o intermedia con formato en el formato de certificado PEM. Estos certificados deben contener la clave pública de la ENTIDAD de certificación, que se usa para firmar los certificados de cliente presentados durante una sesión.

Una vez cargado el certificado y configurada una directiva pertinente, cuando una sesión aplicable atraviesa el control de aplicaciones de acceso condicional, el punto de conexión de Defender for Cloud Apps solicita al explorador que presente los certificados de cliente SSL. El explorador sirve los certificados de cliente SSL que se instalan con una clave privada. Esta combinación de certificado y clave privada se realiza mediante el formato de archivo PKCS #12, normalmente .p12 o .pfx.

Cuando se realiza una comprobación de certificados de cliente, Defender for Cloud Aplicaciones comprueba las condiciones siguientes:

  1. El certificado de cliente seleccionado es válido y está bajo la entidad de certificación raíz o intermedia correcta.
  2. El certificado no se revoca (si CRL está habilitado).

Nota

La mayoría de los exploradores principales admiten la realización de una comprobación de certificados de cliente. Sin embargo, las aplicaciones móviles y de escritorio suelen aprovechar los exploradores integrados que pueden no admitir esta comprobación y, por tanto, afectan a la autenticación de estas aplicaciones.

Para configurar una directiva para aprovechar la administración de dispositivos mediante certificados de cliente:

  1. En Defender for Cloud Aplicaciones, en la barra de menús, seleccione el engranaje settings icon. de configuración y seleccione Configuración.

  2. Seleccione la pestaña Identificación del dispositivo .

  3. Upload tantos certificados raíz o intermedios como necesite.

    Sugerencia

    Para probar cómo funciona esto, puede usar nuestra entidad de certificación raíz de ejemplo y el certificado de cliente, como se indica a continuación:

    1. Descargue la entidad de certificación raíz de ejemplo y el certificado de cliente.
    2. Upload la entidad de certificación raíz para Defender for Cloud Apps.
    3. Instale el certificado de cliente (password=Microsoft) en los dispositivos pertinentes.

Una vez cargados los certificados, puede crear directivas de acceso y sesión basadas en la etiqueta device y en el certificado de cliente válido.

Aplicaciones y clientes compatibles

Los controles de sesión y acceso se pueden aplicar a cualquier inicio de sesión único interactivo, mediante el protocolo de autenticación SAML 2.0 o, si usa Azure AD, también el protocolo de autenticación Open ID Conectar. Además, si las aplicaciones están configuradas con Azure AD, también puede aplicar estos controles a las aplicaciones hospedadas localmente configuradas con el proxy de aplicación de Azure AD. Además, los controles de acceso se pueden aplicar a las aplicaciones cliente móviles y de escritorio nativas.

Defender for Cloud Apps identifica las aplicaciones mediante la información disponible en su catálogo de aplicaciones en la nube. Algunas organizaciones y usuarios personalizan las aplicaciones mediante la adición de complementos. Sin embargo, para que los controles de sesión funcionen correctamente con estos complementos, los dominios personalizados asociados deben agregarse a la aplicación correspondiente del catálogo.

Nota

La aplicación Authenticator, entre otros flujos de inicio de sesión de aplicaciones cliente nativas, usa un flujo de inicio de sesión no interactivo y no se puede usar con controles de acceso.

Controles de acceso

Muchas organizaciones que eligen usar controles de sesión para aplicaciones en la nube para controlar las actividades en sesión, también aplican controles de acceso para bloquear el mismo conjunto de aplicaciones cliente móviles y de escritorio nativas, lo que proporciona una seguridad completa para las aplicaciones.

Puede bloquear el acceso a aplicaciones cliente móviles y de escritorio nativas con directivas de acceso estableciendo el filtro de aplicación cliente en Móvil y escritorio. Algunas aplicaciones cliente nativas se pueden reconocer individualmente, mientras que otras que forman parte de un conjunto de aplicaciones solo se pueden identificar como su aplicación de nivel superior. Por ejemplo, las aplicaciones como SharePoint Online solo se pueden reconocer mediante la creación de una directiva de acceso aplicada a Office 365 aplicaciones.

Nota

A menos que el filtro de aplicación cliente se establezca específicamente en Móvil y escritorio, la directiva de acceso resultante solo se aplicará a las sesiones del explorador. El motivo de esto es evitar que las sesiones de usuario de proxy inadvertidamente sean un producto derivado del uso de este filtro. Aunque la mayoría de los exploradores principales admiten la realización de una comprobación de certificados de cliente, algunas aplicaciones móviles y de escritorio usan exploradores integrados que pueden no admitir esta comprobación. Por lo tanto, el uso de este filtro puede afectar a la autenticación de estas aplicaciones.

Controles de sesión

Aunque los controles de sesión están diseñados para funcionar con cualquier navegador en cualquier plataforma principal de cualquier sistema operativo, se admiten Microsoft Edge (más reciente), Google Chrome (más reciente), Mozilla Firefox (más reciente) o Apple Safari (más reciente). El acceso a aplicaciones móviles y de escritorio también se puede bloquear o permitir.

Nota

  • Defender for Cloud Aplicaciones usa protocolos de seguridad de la capa de transporte (TLS) 1.2 y versiones posteriores para proporcionar un cifrado de la mejor clase. Las aplicaciones y exploradores cliente nativos que no admiten TLS 1.2 y versiones posteriores no serán accesibles cuando se configuren con el control de sesión. Sin embargo, las aplicaciones SaaS que usan TLS 1.1 o versiones anteriores aparecerán en el explorador como mediante TLS 1.2+ cuando se configuran con Defender for Cloud Apps.
  • Para aplicar controles de sesión a portal.office.com, debe incorporar Centro de administración de Microsoft 365. Para obtener más información sobre la incorporación de aplicaciones, consulte Incorporación e implementación del control de aplicaciones de acceso condicional para cualquier aplicación.

Aplicaciones previamente incorporadas

Cualquier aplicación web configurada con los protocolos de autenticación mencionados anteriormente se puede incorporar para trabajar con controles de acceso y sesión. Además, las siguientes aplicaciones ya están incorporadas con controles de acceso y sesión para Azure Access Directory.

Nota

Es necesario enrutar las aplicaciones deseadas para acceder a los controles de sesión y realizar un primer inicio de sesión.

  • AWS
  • Box
  • Concur
  • CornerStone on Demand
  • DocuSign
  • Dropbox
  • egnyte
  • GitHub
  • Google Workspace
  • HighQ
  • JIRA/Confluence
  • LinkedIn Learning
  • Microsoft Azure DevOps (Visual Studio Team Services)
  • Microsoft Azure Portal
  • Microsoft Dynamics 365 CRM
  • Microsoft Exchange Online
  • Microsoft OneDrive para la Empresa
  • Microsoft Power BI
  • Microsoft SharePoint Online
  • Microsoft Teams
  • Microsoft Yammer
  • Salesforce
  • ServiceNow
  • Slack
  • Tableau
  • Workday
  • Workiva
  • Área de trabajo desde Meta

Si estás interesado en que una aplicación específica se incorpore previamente, envíanos detalles sobre la aplicación. Asegúrese de enviar el caso de uso que le interesa para incorporarlo.

Restricciones conocidas

  • El proxy se puede omitir mediante el token de sesión incrustado.
    Es posible omitir el proxy en los casos en los que la propia aplicación inserta el token dentro de los vínculos. Un usuario final puede copiar el vínculo y acceder al recurso directamente en ese caso.

  • La directiva de copia y corte se puede omitir mediante herramientas de desarrollo
    Es posible omitir la directiva de copia o corte definida mediante las herramientas de desarrollo del explorador. Por ejemplo, en una directiva que impide que la copia del contenido Microsoft Word, es posible ver el contenido mediante Herramientas de desarrollo, copiar el contenido desde allí y, a continuación, omitir el proxy.

  • Un cambio de parámetro puede omitir el proxy.
    Es posible omitir la directiva de sesión definida modificando los parámetros. Por ejemplo, es posible modificar los parámetros de dirección URL y engañar al servicio de una manera que omita el proxy y habilite una descarga de un archivo confidencial.

  • Limitación del complemento del explorador
    Nuestra solución actual de aplicación de restricciones de sesión de Control de aplicaciones de acceso condicional no admite aplicaciones nativas, ya que requiere alguna modificación del código de aplicación subyacente. Las extensiones de explorador, similares a las aplicaciones nativas, están preinstaladas en el explorador, por lo que no nos permiten modificar su código según sea necesario y se interrumpirán cuando se redirijan sus tokens a través de nuestra solución de proxy. Como administrador, puede definir el comportamiento predeterminado del sistema cuando no se puede aplicar una directiva y elegir entre permitir el acceso o bloquearlo totalmente.

  • Pérdida de contexto
    En las siguientes aplicaciones, hemos encontrado escenarios en los que navegar a un vínculo puede provocar la pérdida de la ruta de acceso completa del vínculo y, normalmente, el usuario llega a la página principal de la aplicación.

    • ArcGIS
    • GitHub
    • Microsoft Dynamics 365 CRM
    • Microsoft Power Automate
    • Microsoft Power Apps
    • Microsoft Power BI
    • Microsoft Yammer
    • Área de trabajo desde Meta
  • Las directivas de inspección son válidas para archivos de hasta 5 MB de tamaño y 1 millón de caracteres

    Cuando se aplica una directiva de sesión para bloquear cargas o descargas de archivos en función de la inspección de contenido, la inspección se realiza en archivos menores de 5 MB y menos de 1 millón de caracteres.

    Por ejemplo, un administrador puede definir una de las siguientes directivas de sesión:

    • Bloquear la carga de archivos para archivos que contienen el número de seguridad social (SSN)
    • Bloquear la descarga de archivos para archivos que contienen PHI (Información de salud protegida) En tales casos, los archivos mayores de 5 MB o 1 millón de caracteres no se examinan y se tratan según la configuración de directiva de Aplicar siempre la acción seleccionada incluso si no se pueden examinar los datos.

    A continuación se muestran algunos ejemplos:

    • un archivo TXT, un tamaño de 1 MB y 1 millón de caracteres: se analizará
    • un archivo TXT, tamaño de 2 MB y 2 millones de caracteres: no se analizará
    • un archivo de Word compuesto por imágenes y texto, tamaño de 4 MB y 400 000 caracteres: se analizará
    • un archivo de Word compuesto por imágenes y texto, tamaño de 4 MB y 2 millones de caracteres: no se analizará

    El umbral de tamaño de archivo se puede configurar hasta 50 MB (hasta 5 MB). De este modo, es posible examinar archivos que contengan objetos textuales y no textuales que contengan hasta 1 millón de caracteres.

    La razón de la limitación es que se deben examinar grandes cantidades de datos para detectar información confidencial. En tales casos, la recomendación de Microsoft es probar la directiva con un número limitado de usuarios y, a continuación, expandirse a toda la organización.

Pasos siguientes

Para obtener instrucciones sobre cómo incorporar las aplicaciones, consulte el documento adecuado a continuación:

Si surgen problemas, estamos aquí para ayudarle. Para obtener ayuda o soporte técnico para el problema del producto, abra una incidencia de soporte técnico.