Los dispositivos iOS, como iPads y iPhones, se están convirtiendo rápidamente en parte del paisaje informático de las empresas, en una tendencia que a veces se denomina "la consumerización de las TI". Desde el punto de vista de un profesional de la seguridad, hay una serie de factores que son motivo de preocupación, como la posibilidad de que dispositivos no gestionados o "infragestionados" accedan a datos corporativos, la variedad de dispositivos y factores de forma implicados, y el rápido ritmo de adopción, por nombrar algunos.
Los iPhones y los iPads pueden utilizar certificados digitales de forma nativa para autenticarse en redes y datos corporativos de diversas maneras:
- Redes inalámbricas corporativas (802.1X y EAP-TLS)
- Pasarelas VPN a través del cliente Cisco integrado
- Microsoft ActiveSync
- Sitios web SSL con autenticación mutua a través del navegador Safari
Cada una de ellas permite a una organización restringir el acceso a los recursos mencionados a SÓLO permitir dispositivos que hayan recibido un certificado de la PKI corporativa. Esto, combinado con controles sólidos en torno a la emisión de certificados, y la configuración de políticas organizativas como códigos de acceso y capacidades de borrado remoto (por ejemplo, a través de ActiveSync), puede empezar a aportar cierto control a la situación, y de una manera relativamente escalable. Además, el uso de certificados puede mitigar la necesidad de que cada aplicación iOS recopile y almacene el nombre de usuario y la contraseña del usuario, lo que también es positivo.
Como cualquier aplicación habilitada para PKI, una implementación adecuada requiere una planificación cuidadosa en torno al ciclo de vida del certificado. A menudo hay más aspectos, pero toda planificación de certificados debe incluir áreas como:
- Emisión: ¿Qué usuarios y/o dispositivos necesitan certificados y cuál es el proceso para conseguirlos?
- Renovación: Todos los certificados caducan, normalmente en uno o dos años. Contar con un proceso bien definido para gestionar la renovación puede evitar grandes quebraderos de cabeza en el futuro. La planificación debe definir quién es responsable de identificar los certificados que están a punto de caducar y el proceso necesario para renovarlos.
- Revocación: Si se pierde un dispositivo o se sospecha que la clave privada de un certificado está en peligro, los certificados deben revocarse para evitar que sigan siendo credenciales empresariales válidas.
- Sustitución: Si un certificado se borra accidentalmente o se pierde, hay que recuperarlo (en el caso de los certificados cifrados) o sustituirlo directamente. En este caso, los esfuerzos pueden ser similares a los utilizados para la emisión o renovación.
A la hora de emitir certificados para iPhones o iPads, existen dos opciones generales:
- Cree un archivo PKCS#12 (.pfx) que contenga el certificado y la clave privada. Esto se puede instalar en el dispositivo apuntando el navegador Safari a un servidor web con el archivo, o incluyendo el archivo .pfx en un perfil de iOS.
- Configure el dispositivo para que se inscriba para obtener un certificado mediante SCEP (Simple Certificate Enrollment Protocol) en un perfil iOS (archivo .mobileconfig). Las autoridades de certificación de Microsoft incluyen de forma nativa compatibilidad con SCEP como función añadida en los sistemas operativos Windows Server 2008 y Server 2008 R2.
Sin embargo, ambos enfoques plantean algunos problemas. CSS considera que los archivos .pfx son intrínsecamente un poco peligrosos: al ser archivos, son bastante móviles, y puede ser difícil controlar a dónde van. Además, son susceptibles de que se adivine la contraseña fuera de línea, y una vez que se ha adivinado la contraseña, la clave está comprometida. Por último, el "no repudio" de la PKI se ve debilitado: como la clave se crea de forma centralizada, es difícil garantizar con un 100% de certeza que sólo el portador del certificado ha tenido acceso a la clave privada.
La inscripción basada en SCEP es sin duda una mejor opción desde el punto de vista de la seguridad, ya que la clave privada se genera en en el dispositivo y no es exportable. El principal problema aquí es de escala: el perfil de iOS coloca el contenido del certificado, como el Asunto (Nombre Distinguido) y la contraseña de "desafío" de un solo uso SCEP dentro de la información de configuración. Por tanto, los perfiles .mobileconfig no pueden compartirse entre dispositivos: cada uno necesita el suyo propio. Es posible cambiar la configuración de la contraseña de desafío para que los desafíos puedan ser reutilizados, pero debe tenerse en cuenta que esto es un terrible la forma en que funciona SCEP, las credenciales de Active Directory no están involucradas, por lo que el desafío es realmente el único factor utilizado para autenticar la solicitud de certificado. factor utilizado para autenticar la solicitud de certificado.
Por último, independientemente del método de emisión utilizado, los certificados caducarán, y actualmente iOS no hace nada para gestionar esto automáticamente. Por lo tanto, como se ha mencionado anteriormente, será necesario poner en marcha algún tipo de proceso para gestionar la inminente expiración de los certificados.
Próximamente: Uso de la herramienta de informes de certificados de CSS para ayudar a gestionar certificados para iPads y iPhones.
