Vigilancia de seguridadImplementación de EFS: Parte 1

John Morello

Hasta ahora, todo el mundo ha oído informes acerca de datos personales o confidenciales que se pierden a causa del robo de un equipo portátil o de una mala colocación. Los equipos portátiles desaparecen de forma periódica. Con el robo de identidad en alza y el cumplimiento normativo más crítico que nunca, una protección completa de datos en los sistemas informáticos móviles es esencial.

Una respuesta es utilizar el Sistema de cifrado de archivos (EFS), incluido en Windows® desde Windows 2000, que ofrece un cifrado integrado, de gran rendimiento y basado en el disco. El EFS se integra a la perfección con el Explorador de Windows, de forma que los usuarios finales a menudo no sabrán si el archivo que utilizan está cifrado. Además, el EFS funciona igualmente bien con las tecnologías nativas de autenticación y control de acceso de Windows, así los usuarios no tienen que recordar contraseñas independientes para tener acceso a sus datos. Por último, el EFS ofrece opciones manejables para recuperar datos en caso de que un usuario pueda perder el acceso a sus claves de cifrado (como si se elimina su perfil de usuario o queda dañado o si se pierde su tarjeta inteligente).

El EFS utiliza tecnología integrada de criptografía en Windows para generar, almacenar e implementar claves de cifrado de alta seguridad para proteger los datos. En Windows XP Service Pack 1 (SP1) y versiones posteriores, el EFS utiliza el algoritmo Estándar de cifrado avanzado (AES, Advanced Encryption Standard) con una clave de 256 bits para cifrar los datos en disco. Estas claves simétricas quedan protegidas con un par de clave asimétrico (RSA). El EFS cifra cada archivo con su clave AES. A continuación, cifra esta clave con la clave RSA del usuario y almacena el resultado en el archivo. Para obtener más información sobre criptografía de EFS, consulta la barra lateral "Recursos EFS". Por ahora, no me centraré en los apuntalamientos técnicos de EFS, sino más bien en cómo implementarlo y en cómo hacerlo viable en su entorno. Por este motivo, damos por sentado que cuenta con un conocimiento previo de conceptos de criptografía de EFS.

Un nota sobre seguridad de EFS

Existen algunas aplicaciones que afirman poder piratear o interrumpir el cifrado de EFS. Ninguna de estas aplicaciones descifra en realidad el texto cifrado de AES (o Estándar de cifrado de datos, DES, o Estándar ampliado de cifrado de datos, DESX), sino que obtiene acceso a la clave privada EFS del usuario mediante el forzado de la contraseña del usuario. Lo importante que se debe tener presente acerca del cifrado de EFS es que las claves privadas utilizadas para generar y proteger los datos cifrados utilizan la API de la Protección de Datos (DPAPI). La DPAPI utiliza los derivados de las credenciales de inicio de sesión del usuario para proteger los datos de forma que el resultado sea que la protección de datos con EFS es tan buena como lo sea la contraseña de usuario. Con Windows Vista™, ahora puede almacenar certificados de cifrado de EFS en tarjetas inteligentes, lo que cambia este paradigma y aumenta en gran medida la seguridad relativa de los datos protegidos de EFS.

¿Durante cuánto tiempo tiene que resistir una contraseña a estos ataques? Dadas las capacidades actuales del hardware y los algoritmos modernos de ataque de contraseñas, se recomienda una contraseña de 11 caracteres o mayor (o, mejor dicho, una frase). Una frase de 11 caracteres o más es sumamente resistente a los métodos más avanzados de hoy en día, incluyendo ataques de hash precalculados (como la tabla de cadenas arco iris; consulte la publicación en blog "Why you shouldn't be using passwords of any kind on your Windows networks" (en inglés) incluida en la barra lateral "Recursos" para obtener más información).

¿PKI o no PKI?

Una de las equivocaciones más comunes acerca de EFS es que requiere una infraestructura de claves públicas (PKI) para funcionar. Si bien EFS se puede integrar fácilmente y se aprovecha de una PKI, si su organización tiene una, no se trata en ningún caso de un requisito. Dicho esto, la decisión relativa a si utilizar o no una PKI en la implementación de EFS afectará a muchas futuras decisiones de implementación, de modo que se debe examinar primero.

La ventaja principal de utilizar una PKI con EFS es la capacidad de llevar a cabo la recuperación y archivado de claves. Mientras que EFS admite sólo a administradores para realizar la recuperación de datos, la recuperación de claves automática está sólo disponible con una PKI, e incluso entonces, sólo al ejecutar Windows Server® 2003 Enterprise Edition como Autoridad de Certificado (CA). La recuperación de datos es el proceso por el que un usuario que pierde el acceso a su clave de cifrado puede ofrecerle sus datos cifrados a un administrador designado, conocido como Agente de Recuperación de Datos (DRA), que puede a su vez descifrar dichos datos y devolvérselos al usuario o volver a cifrarlos para su uso con una clave privada nueva. El DRA funciona como una sombra del proceso de cifrado del usuario, proceso según el cual todo que cifre el usuario con su clave se cifra también con una copia de la clave del DRA. Así, cuando se pierde la clave de usuario, el DRA puede entrar, obtener los datos del texto cifrado, aplicarle una clave de DRA para descifrarlo (o volver a cifrarlo) y, a continuación, devolver los datos al usuario. El enfoque de DRA funciona bien, pero puede ser difícil de administrar si el usuario ha cifrado cantidades grandes de datos o no tiene personal local de TI para que actúen como DRA.

La recuperación de claves, por otro lado, requiere que el CA haga una copia de la clave de cifrado del usuario durante el proceso de creación de claves y almacene de forma segura la copia de dicha clave en la base de datos de CA. Entonces, cuando un usuario pierde el acceso a archivos cifrados, el administrador de la entidad emisora sólo necesita entrar en esta base de datos y recuperar la clave de usuario. En ese punto, el usuario tendrá acceso inmediato a sus datos otra vez sin que tener que disponer de un DRA para recuperarlos. Cuándo se haga así, la recuperación de claves puede ser más rápida y más eficiente. Tenga en cuenta, sin embargo, que una práctica recomendada consiste en tener siempre DRA disponibles, incluso cuando se utilice la recuperación de claves, para ofrecer un mecanismo de copia de seguridad para eventos de pérdida de claves. Esto también admite que las organizaciones grandes tengan un sistema de recuperación distribuido donde los administradores locales de TI puedan recuperar los datos de usuarios sin tener que involucrar al grupo de administradores de PKI.

Otra prestación posible derivada del uso de PKI con EFS es facilitar un uso compartido más fácil de archivos cifrados. Recuerde que EFS no se limita únicamente a sistemas de equipo portátil; puede ser igualmente valioso en cualquier situación donde la seguridad física de un equipo no se pueda garantizar. En estas situaciones, es posible que exista la necesidad de que múltiples usuarios puedan tener acceso a los mismos datos cifrados. Si bien el soporte técnico de Windows para el uso compartido de archivos cifrados está limitado de algún modo, ya que sólo admite el uso compartido de archivos individuales, no directorios, puede ser una herramienta útil. Para facilitar el uso compartido de archivos de EFS, el usuario que comparte el archivo debe tener acceso a las claves públicas de los usuarios con los que comparte (lo que es más fácil si esos usuarios tienen un certificado EFS válido publicado en su cuenta de Active Directory®). Si bien es posible llevar a cabo esta publicación manualmente, el uso de un CA de Windows instalado en el modo Enterprise (integrado en Active Directory) automatiza el proceso completamente.

Administración de claves de EFS

Si tiene una PKI basada en Windows Server 2003 disponible para utilizar, la generación de certificados EFS del usuario es un proceso sencillo. Un CA de Windows Server 2003 viene acompañado de un conjunto predeterminado de plantillas de certificado, incluyendo una EFS básica. Sin embargo, esta plantilla es una plantilla de versión 1 y no es compatible con el archivado de claves. Por tanto, antes de ponerla disponible en el CA, querrá duplicar la plantilla para crear una nueva plantilla de versión 2 (por ejemplo, lo podría llamar EFS con archivado de claves, como se muestra en la Figura 1). En esta plantilla nueva, vaya a la ficha de manejo de solicitudes y seleccione la opción de archivado de claves de cifrado del usuario. Tenga en cuenta que tendrá que tener el archivado de claves configurado correctamente en el CA antes de habilitar esta opción. En la sección de recursos se incluye un excelente paseo por el proceso. También debe establecer esta plantilla para sustituir la EFS básica y asegurarse así de que los clientes utilicen esta nueva versión (consulte la Figura 2).

Figura 1** EFS con archivado de claves **(Hacer clic en la imagen para ampliarla)

Figura 2** Sustitución de la plantilla EFS básica **(Hacer clic en la imagen para ampliarla)

A continuación, tendrá que establecer los permisos apropiados en la plantilla para admitir que el conjunto correcto de usuarios tenga acceso de inscripción. Dado que el componente EFS en Windows solicitará automáticamente un certificado la primera vez que se utilice EFS, normalmente no tiene que admitir la inscripción automática de usuarios en relación con la plantilla EFS. De hecho, yo no le recomendaría que admita la inscripción automática para los certificados EFS a menos que esté seguro de que todos los usuarios inscritos automáticamente utilizarán EFS. En la Figura 3 se muestra la configuración de la inscripción EFS. Si emite certificados para usuarios que puede que nunca utilicen EFS aumentará el tamaño de la base de datos de CA sin finalidad alguna. Aunque el tamaño de la base de datos de CA no está limitado, puede resultar más difícil de administrar (sobre todo a través de la Microsoft Management Console o MMC) ya que aumenta el número de certificados publicados.

Figura 3** Configuración de permisos de usuario de EFS **(Hacer clic en la imagen para ampliarla)

Por último, si necesita compatibilidad con el uso compartido de archivos cifrados, puede que desee que el CA publique automáticamente el certificado de usuario en Active Directory.

Una vez haya configurado la plantilla correctamente en el CA, la primera vez que un usuario cifra un archivo con EFS, obtendrá su certificado del CA y éste archivará automáticamente su clave privada.

Administración de claves de DRA

La siguiente pregunta que se debe tener en cuenta si tiene una PKI en funcionamiento es si utilizar o no certificados de DRA generados por el CA. ¿Por qué no querría utilizar certificados de DRA del PKI? Imagine una situación donde tenga un CA emisor con un período de validez de certificado bastante corto (dos años o menos). Ese CA no podrá publicar ningún certificado con una validez más larga que la suya, lo que significaría que sus certificados de DRA tendrían (a lo más) una duración de dos años. Esto puede dar como resultado una situación significativamente más compleja de recuperación de datos. Este ejemplo hipotético se ilustra en la situación siguiente.

1. Un usuario cifra un archivo en enero de 2006; los certificados de DRA que se han insertado en su equipo a través de la Directiva de grupo tiene una duración de dos años (caducan en enero de 2008).
2. El usuario sigue trabajando con EFS, cifrando los archivos nuevos.
3. En enero de 2008, los certificados de DRA caducan y el administrador inserta certificados nuevos a través de la Directiva de grupo.
4. De aquí en adelante, cualquier operación de cifrado utiliza los certificados nuevos de DRA (incluido cualquier archivo que abra y que se hayan cifrado con los DRA antiguos; cuando se guardan, utilizarán los nuevos DRA) pero ninguno de los archivos que no se toquen quedará protegido por los DRA antiguos.
5. El usuario daña accidentalmente su perfil y requiere la recuperación de datos.
6. El administrador de TI ahora debe tener dos conjuntos de certificados de DRA: Los nuevos, para cualquier archivo tocado desde el paso 3, y el viejo, para cualquier archivo no tocado desde entonces.

Si bien es posible que el administrador de TI ejecute una secuencia de comandos después del paso 3 para actualizar todos los archivos con el DRA nuevo (mediante cipher.exe/U), puede ser un proceso engorroso. También, para ser claros, los pares de claves de DRA no son inútiles después de que hayan alcanzado su fecha de caducidad, aunque el componente EFS no admitirá operaciones nuevas de cifrado si se incluye un certificado de DRA caducado en la directiva de recuperación. Los archivos antiguos cifrados con pares de claves de DRA pueden, por supuesto, recuperarse. Por tanto, los pares de claves de DRA nunca se deben descartar, ni siquiera después de que haya caducado su periodo de validez. Simplemente no sabe cuándo necesitará utilizarlos.

Para estas razones, le recomiendo que los entornos que tengan CA con duraciones de certificado cortas empleen certificados de DRA autofirmados con vidas más largas. La utilidad de cifrado incluye un conmutador (cipher.exe/R) que crea automáticamente pares de claves del agente de recuperación de EFS con una duración de 100 años (consulte la Figura 4). El certificado de este par de claves se puede adjuntar a objetos de directiva de grupo (GPO) y se puede utilizar como DRA en toda la organización. Puesto que el componente EFS no comprueba la cadena de confianza de los certificados de DRA, estos certificados autofirmados funcionarán sin tener que realizar ningún cambio en la lista de autoridades de confianza de certificado raíz de los sistemas. Independientemente de la duración de un CA de la organización, siempre recomiendo crear por lo menos un certificado de DRA duradero y adjuntarlo a un GPO para todo el dominio. Ésta es la opción de recuperación de datos de reserva para usarla en caso de que el resto de opciones fallen. Esto es especialmente vital si utiliza claves de DRA generadas por CA en ausencia de un archivado de claves de CA. En caso de que un certificado de DRA quede comprometido, puede actualizar el GPO con un certificado nuevo y utilizar cipher.exe/U, como se ha indicado anteriormente, con el fin de actualizar sus archivos.

Figura 4** Ejecución de Ciquer /R **(Hacer clic en la imagen para ampliarla)

Recurso de EFS

Puede obtener aún más información sobre detalles de EFS y prácticas recomendadas en los sitios siguientes.

• Why you shouldn’t be using passwords of any kind on your Windows networks (en inglés)
• Implementing Key Archival Walkthrough (en inglés)
• Encrypting File System in Windows XP and Windows Server 2003 (en inglés)

Implementación de DRA y KRA

El archivado de claves ofrece la capacidad para los administradores de CA de recuperar las claves de cifrado custodiadas en nombre del usuario. Obviamente, se trata de una capacidad muy sensible y eficaz, ya que puede admitir que un administrador de CA descifre cualquier dato en la organización que utiliza una clave firmada por el CA. Por tanto, la recuperación y el archivado de claves se deben tratar con cuidado y sólo se le debe otorgar este permiso a una pequeña parte del personal de seguridad de confianza. Debido a la naturaleza sensible de la recuperación de claves, si desea depender de ello como mecanismo principal para recuperar el acceso a datos cifrados de EFS, es importante tener un proceso de derivación claramente definido para que las solicitudes de recuperación se envíen al equipo de administración de CA. Sólo después de que la solicitud se haya investigado con cuidado se debe iniciar el proceso de recuperación. Entonces, una vez que se recupera la clave, se le debe ofrecer al usuario a través de un método seguro (en otras palabras, no a través de correo electrónico) ya que la clave recuperada ofrece acceso a todos los datos protegidos por EFS del usuario.

Las claves del Agente de recuperación de claves o KRA se generan y mantienen por los administradores de CA y no se anuncian a través de la Directiva de grupo. De hecho, el propio EFS no puede determinar si se ha archivado o no una clave que utiliza. Simplemente realiza sus operaciones de cifrado como lo haría normalmente. Además, las claves de KRA creadas en el CA no son específicas de EFS de ningún modo. Un CA que utilice el archivado de claves tendrá un número n de claves de KRA adjuntas en el nivel de CA que se utilizarán para proteger cualquier clave archivada por el CA. Estas claves pueden incluir las utilizadas con EFS, correo electrónico seguro o cualquier otro fin de certificado que incluya cifrado. Las claves de KRA se deben almacenar de forma segura por los agentes de recuperación de claves individuales y debe haber al menos dos KRA que se utilicen para ofrecer una solución alternativa en caso de que se pierda una de las claves.

La primera vez que un administrador inicia sesión en el controlador de dominio de un dominio recién creado, se crea una directiva de recuperación predeterminada en el nivel de dominio mediante un certificado autofirmado y un par de claves almacenadas en el perfil del administrador del DC. Este certificado de DRA tendrá una validez de tres años. El enfoque recomendado es eliminar este certificado predeterminado y reemplazarlo con certificados autofirmados de mayor duración y publicados por su PKI. Si no elimina este certificado autofirmado predeterminado, tres años después de su creación EFS detendrá el cifrado de los archivos nuevos de todo el dominio. Esto se debe a que el certificado habrá caducado y el EFS evitará el cifrado de más datos si se incluye un certificado de DRA caducado en su directiva de recuperación. Si bien es posible utilizar Windows XP y sistemas posteriores sin ninguna directiva de agente de recuperación en funcionamiento, no se lo recomendamos en absoluto. Si lo hace y un usuario pierde el acceso a su clave de cifrado por cualquier motivo y la recuperación de claves no es posible, todos sus datos se perderán irrevocablemente.

Como he dicho, las claves de DRA pueden ser autofirmadas o las puede haber publicado un CA. En la mayoría de los casos, es mejor un enfoque híbrido, con, al menos, dos DRA autofirmados de larga duración utilizados en toda la empresa como agentes de recuperación en última instancia. Dado que los certificados de DRA se implementan a través de los objetos de directiva de grupo, poseen las mismas capacidades de herencia que otros GPO. Es decir, el algoritmo de aplicación y acumulación de GPO de unidad organizativa, dominio, ubicación y local estándar que controla la aplicación de otra configuración de GPO corresponde también a los DRA. Por tanto, una organización puede implementar fácilmente un enfoque nivelado con respecto a los DRA, donde el grupo central de TI tiene acceso de DRA a cada parte de la empresa, pero donde los grupos locales de TI también mantienen la capacidad para sus áreas específicas de responsabilidad. Esto supone una ventaja especialmente valiosa en organizaciones geográficamente dispersas y grandes, ya que alivia la necesidad de transferir cantidades grandes de datos cifrados a través de vínculos de WAN para facilitar la recuperación de datos. En la Figura 5 se muestra una implementación típica de DRA con múltiples niveles.

Figura 5** Implementación de DRA de múltiples niveles **

En este caso, un usuario de la unidad organizativa Baton Rouge acabaría con seis DRA para cada archivo cifrado: dos de sus administradores locales, dos del grupo de TI de Norteamérica y dos del nivel de dominio. De este modo, si el usuario perdiera acceso a sus datos cifrados, lo podría recuperar gracias a un DRA local en el caso de Baton Rouge o gracias al grupo de TI de Norteamérica. Como opción final, si estos cuatro DRA no estuvieran disponibles o se perdieran, los DRA de nivel de dominio podrían hacerse cargo y recuperar los datos también. Independientemente de qué DRA haya realizado la recuperación, el proceso sería esencialmente el mismo. El usuario pondría primero los datos a disposición del DRA. Es importante que el DRA realice los pasos necesarios para asegurarse de que la solicitud sea legítima y que proceda del auténtico propietario de los datos. Una vez hecho esto, el DRA cargaría el certificado de DRA, descifraría (y preferiblemente volvería a cifrar) los datos y le enviaría de nuevo los datos al usuario final. Algunas organizaciones eligen también realizar una recuperación local, donde el DRA visitaría físicamente al usuario del problema, cargaría su par de claves de DRA en el perfil y descifraría los datos y eliminaría el par de claves. El usuario tendría así acceso a los datos con formato de texto simple y podría volver a cifrarlos con una clave nueva. Se debe tener en cuenta que este enfoque es mucho menos seguro, ya que el par de claves de DRA se copia (aunque temporalmente) a la máquina local, pero puede ahorrar algún tiempo, sobre todo si se debe recuperar una gran parte de los datos.

Tenga en cuenta que si se le ofreciera al usuario una recuperación a través de la recuperación y el archivado de claves, la solicitud de recuperación se trataría independientemente de este proceso. En vez de utilizar un DRA, la solicitud de recuperación de claves del usuario pasaría a los administradores de CA, que deben investigar la solicitud, entrar al archivado y recuperar la clave privada del usuario. A continuación, pondrían esta clave a disposición del usuario de forma segura, como, por ejemplo, colocándola en un sitio Web seguro para su descarga. (Si el usuario utilizaba una tarjeta inteligente para almacenar su clave de EFS, disponible con Windows Vista, esa clave también se debe volver a publicar). El usuario cargaría esta clave en su perfil y tendría acceso inmediato a todos sus datos cifrados.

Dado que el DRA y los pares de claves se pueden utilizar para descifrar datos confidenciales, es importante que estén bien protegidos. Los pares de claves de KRA y DRA no se deben almacenar en los perfiles de administradores normales de escritorio (los perfiles en los que llevan a cabo sus tareas diarias normales). En lugar de esto, estos pares se deben almacenar de forma segura y sin conexión en un disquete, en un disco óptico o en un medio flash, y en una ubicación físicamente segura. De este modo, cuándo se necesite la recuperación, el agente de recuperación puede cargar el par de claves en una estación de trabajo desde estos medios, realizar la operación de recuperación y eliminar el par. En algunas organizaciones especialmente sensibles a la seguridad, se designan estaciones de trabajo dedicadas a la recuperación y aumento de la seguridad de estos pares de claves, aunque esto no es un requisito para todas las organizaciones.

La próxima vez

Ahora que he examinado la administración de claves, la recuperación de datos y los aspectos de Active Directory relativos a la planificación de EFS, me centraré en las preguntas de desarrollo de los clientes en la parte 2 de este tema, que se publicará el mes próximo. En ella explicaré temas tales como el control del uso de EFS a través de las directivas de grupo, la elección de qué se debe cifrar, el cifrado automático de los datos a través de secuencias de comandos de inicio de sesión y mejoras del cliente para el Explorador de Windows con el fin de trabajar con datos protegidos por EFS de forma aún más fácil.

John Morello se graduó summa cum laude en LSU y ha trabajado con Microsoft durante seis años en una amplia variedad de funciones. Como Consultor senior, ha diseñado soluciones de seguridad para empresas pertenecientes a Fortune 100 y para clientes de defensa, civiles y federales. Actualmente es Director de programa en el grupo de Windows Server que trabaja en tecnologías

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.