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 el control de aplicaciones de acceso condicional de Defender for Cloud Apps, también necesita una licencia de Azure Active Directory P1 o la licencia requerida por la solución IdP.

Funcionamiento

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 Apps, donde puede proteger los datos con el 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 del usuario se restringe en una sesión potencialmente arriesgada.

  • 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 Apps 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 de 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 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 Apps 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 Apps, en la barra de menús, seleccione el icono de configuración de engranaje de configuración. y seleccione Configuración.

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

  3. Cargue 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. Cargue la entidad de certificación raíz en 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 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 Connect. 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 que usan la información disponible en su catálogo de aplicaciones en la nube. Algunas organizaciones y usuarios personalizan 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 se deben agregar a la aplicación correspondiente en el 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 la 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 proxy inadvertidamente, que pueden ser 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 se crean para trabajar con cualquier explorador en cualquier plataforma principal en cualquier sistema operativo, se admite 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 Apps usa protocolos de seguridad de la capa de transporte (TLS) 1.2+ para proporcionar el mejor cifrado en 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 o posteriores 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
  • Slack
  • Tableau
  • Workday
  • Workiva
  • Área de trabajo desde Meta

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

Limitaciones conocidas

  • El proxy se puede omitir mediante el token de sesión insertado
    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.

  • Se puede omitir la directiva de copia o corte mediante herramientas de desarrollo
    Es posible omitir la directiva de copia y corte definida mediante las herramientas de desarrollo del explorador. Por ejemplo, en una directiva que impide la copia del contenido de 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 parámetros. Por ejemplo, es posible modificar los parámetros de dirección URL y desenrutar el servicio de forma 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 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 del 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 sesión son válidas para archivos de hasta 50 MB de tamaño
    Los archivos con un tamaño de hasta 50 MB están sujetos a directivas de sesión. Por ejemplo, un administrador puede definir una de las siguientes directivas de sesión:

    • Supervisión de descargas de archivos para la aplicación de OneDrive
    • Bloquear carga de archivos
    • Bloquear descarga\carga de archivos de malware

    En ese caso, se controlará un archivo de hasta 50 MB en función de las directivas de sesión. Para un archivo más grande, la configuración del inquilino (configuración > comportamiento predeterminado del control > de aplicaciones de acceso condicional) determina si el archivo está permitido o bloqueado, independientemente de las directivas coincidentes.

  • Las directivas de inspección para la protección de la información son válidas para archivos de hasta 30 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 de protección de la información, la inspección se realiza en archivos menores de 30 MB y más 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 los archivos que contienen el número de seguro social (SSN)
    • Protección de la descarga de archivos para archivos que contienen PHI (información de salud protegida)
    • Bloquear la descarga de archivos para con la etiqueta de confidencialidad "muy confidencial"

    En tales casos, los archivos de más de 30 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 los datos no se pueden examinar. Estos son 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á
    • un archivo de Word compuesto por imágenes y texto, tamaño de 40 MB y 400 K caracteres: no se analizará
  • Limitación de carga de archivos

    Si se aplica una directiva de sesión para bloquear la carga de archivos confidenciales, en estos escenarios, los intentos del usuario de cargar archivos o carpetas mediante & arrastrar colocar bloquearán toda la lista de archivos y carpetas:

    • una carpeta que contiene 100 o más archivos

    • una carpeta que contiene al menos un archivo y al menos una subcarpeta

    • una carpeta que contiene varias subcarpetas

    • selección de al menos un archivo y al menos una carpeta

    • una selección de varias carpetas

      Estos son algunos ejemplos:

    El administrador de seguridad define la siguiente directiva: Bloquear la carga de archivos que contienen PII en OneDrive.

    • El usuario intenta cargar una selección de 200 archivos no confidenciales mediante el cuadro de diálogo de carga de archivos. Resultado: los archivos se cargan
    • El usuario intenta cargar una selección de 200 archivos no confidenciales mediante la colocación de arrastrar & . Resultado: los archivos están bloqueados
    • El usuario intenta cargar una selección de 200 archivos, algunos son confidenciales y otros no, mediante el cuadro de diálogo de carga de archivos. Resultado: se cargan los archivos no confidenciales, se bloquean los archivos confidenciales.
    • El usuario intenta cargar una selección de 200 archivos, algunos son confidenciales y otros no, mediante la colocación de arrastrar & . Resultado: se bloquea todo el conjunto de archivos

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.