Jamf Concepts
Guías

Guías

Restricción del acceso para dispositivos anónimos

~6 min read

Una vez que haya habilitado el acceso para dispositivos de confianza – creando rutas seguras a sus aplicaciones y fuentes de datos locales y en la nube – ahora puede comenzar a bloquear sus fuentes de datos al prevenir el acceso de dispositivos "anónimos".

Un dispositivo anónimo es cualquier dispositivo que no está autorizado por su organización. Esto incluye:

  • La laptop de un atacante
  • Un iPhone personal que no está User Enrolled
  • La laptop de un cónyuge
  • Una PC en una cafetería

Es más importante que nunca restringir el acceso solo a dispositivos de confianza, pero esto se complica por la nube y el trabajo remoto donde el perímetro "local" ha desaparecido. Sin embargo, la solución y arquitectura de Trusted Access requiere apoyar el bloqueo de todas las fuentes de datos, incluyendo locales y en la nube.

Bloqueo de recursos locales / del centro de datos

Muchas organizaciones albergan una cantidad significativa de sus aplicaciones y datos sensibles en servidores que están bajo su control y administración directa. Estos servidores se instalan en una instalación privada o en un centro de datos debidamente asegurado.

Afortunadamente, estas aplicaciones ya están protegidas por un firewall, ocultándolas del acceso interno abierto. Sin embargo, hay algunas cosas que verificar:

  • Elimine cualquier dirección IP pública mapeada (dentro de un rango CIDR emitido por ISP) del servidor de destino. Los servidores solo deben ser accesibles a través de direcciones IP privadas.
    • Elimine cualquier excepción de NAT 1 a 1 o firewall pinhole que mapee conexiones desde una dirección IP pública a las direcciones IP internas del servidor. Esto es particularmente importante para protocolos riesgosos como HTTP y RDP.
  • Si la aplicación es particularmente sensible, configure ACL de red (listas de control de acceso) en el servidor(s) o en la LAN para permitir solo conexiones entrantes de la aplicación desde la Jamf Subnet como se define en la configuración de Encryption Domain de su interconexión IPSec.

Los usuarios de confianza y sus dispositivos accederán a estos recursos a través de una Custom IPSec Interconnect Gateway, que será fácilmente accesible con Jamf Trust implementado y activado en su dispositivo.

Bloqueo de recursos de infraestructura como servicio (IaaS)

Infrastructure as a Service se define como servicios basados en la nube proporcionados por proveedores terceros que le permiten ejecutar sus aplicaciones y almacenar sus datos sin tener que administrar la infraestructura física usted mismo. Las plataformas IaaS más comunes en el mercado son Amazon Web Services, Google Cloud Platform y Microsoft Azure.

Restringir el acceso a recursos en estos entornos es en realidad muy similar a los recursos locales / del centro de datos en que los recursos generalmente se configuran en redes virtuales privadas dentro del proveedor IaaS. Sin embargo, la gran diferencia es que es mucho más común que las aplicaciones y los recursos de datos estén disponibles públicamente. Ya sea a propósito o por accidente (¡ya que es fácil de hacer!), este acceso demasiado abierto ha sido la causa raíz de muchos hackeos significativos en años recientes.

Los usuarios y dispositivos de confianza pueden acceder a estos recursos usando cualquiera de las siguientes opciones de interconexión:

Bloqueo de recursos de software como servicio (SaaS)

Software as a Service se define como aplicaciones que ha comprado pero no posee la operación de ninguna manera. Los servicios SaaS comerciales comunes incluyen Microsoft 365, Salesforce, Slack, Box y Zoom. ¡Es probable que su organización tenga al menos una aplicación SaaS que contenga datos sensibles de la empresa!

Sin embargo, sin ningún control nativo de la infraestructura subyacente de la aplicación SaaS – incluyendo conexiones de red – está a merced del proveedor SaaS para proporcionar (o no proporcionar) controles de acceso que se puedan usar para identificar un usuario y dispositivo autorizado.

Generalmente hay dos técnicas disponibles para bloquear el acceso a aplicaciones SaaS: a través de la dirección IP de origen o del proveedor de identidad (IdP).

Usando la dirección IP de origen

Algunos proveedores de SaaS permiten que clientes individuales definan los rangos de dirección IP de origen que pueden usar para iniciar sesión en su tenant de cliente específico para acceder a la aplicación o servicio SaaS. Aunque es relativamente raro, el bloqueo por dirección IP de origen es una forma confiable de permitir el acceso solo desde dispositivos que se conectan a través de la infraestructura Jamf Private Access.

Puede usar las direcciones IP globales compartidas de Jamf o una dirección IP pública en el otro lado de una Custom IPSec Interconnect Gateway.

Un ejemplo poderoso de esto es usar Access Client Access Rules para limitar la conectividad de Microsoft Exchange solo a dispositivos habilitados para Private Access.

Usando un proveedor de identidad

La mayoría de los proveedores de SaaS admiten el inicio de sesión único, que usa el proveedor de identidad de su organización (p. ej., Okta, Azure AD) para permitir o denegar el acceso a esa aplicación, en lugar de confiar en un conjunto separado de credenciales. Aunque esto es excelente para la identidad del usuario, los proveedores de SaaS raramente proporcionan controles de acceso del dispositivo.

Afortunadamente, los proveedores de identidad sí proporcionan soporte para la conciencia a nivel de dispositivo que podemos usar para distinguir un dispositivo autorizado de uno no autorizado.

A través de la dirección IP de origen de Jamf

Los tres principales IdP del mercado admiten la definición de políticas de acceso de inicio de sesión que consideran la dirección IP de origen como criterio para poder iniciar sesión en una aplicación SaaS determinada.

Usando este criterio, puede usar las direcciones IP de la nube de Jamf como una forma de identificar si un inicio de sesión entrante se originó desde un dispositivo que tiene Private Access implementado y activo. Un dispositivo no autorizado no presentará una dirección IP perteneciente a la nube de seguridad de Jamf y, por lo tanto, será bloqueado por la política de acceso del IdP.

Para detalles sobre cómo configurar esto para su IdP, consulte estas guías:

Puede ver cómo se ve esta experiencia en el video de demostración de BYOD encontrado aquí.

A través de una aplicación/agente de punto final de IdP

Algunos IdP proporcionan aplicaciones/agentes de punto final que se pueden usar para entregar identidad de dispositivo y autenticación como parte del proceso de inicio de sesión. Si bien este método es mejor que usar direcciones IP de origen, requiere consideraciones y complejidades de implementación y activación adicionales.