www.t hales-esecurity.com

Thales e-Security

Despliegue y Protección de una Infraestructura de Llave Pública

Consideraciones críticas para proteger datos, identidades y controles de acceso

Informe Técnico octubre 2013

Despliegue y Protección de una Infraestructura de Llave Pública

¿Está usted? • Desplegando una PKI para apoyar una aplicación de negocios críticos • Inseguro en cuanto al nivel de protección que necesita su PKI • Preocupado sobre cómo cumplir con requisitos de seguridad

Aprenda a: • Proteger aplicaciones basadas en PKI y autoridades certificadoras • Determinar el nivel de seguridad apropiado para su PKI • Implementar 10 pasos básicos para mejorar la fiabilidad de su PKI

página 2

www.t hales-esecurity.com

Tabla de Contenido Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. La PKI y el papel de la CA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1. ¿Por qué son importantes las CA?. . . . . . . . . . . . . . . . . . . . . . . . . . . 6



1.2. ¿Cómo funciona? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Consideraciones de seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1. Amenazas y vulnerabilidades generales . . . . . . . . . . . . . . . . . . . . . . 10



2.2. Incidentes de seguridad y consecuencias específicas de la PKI . . . . . . 10

3. ¿Por qué es importante proteger su PKI?. . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Factores a considerar al determinar sus requisitos. . . . . . . . . . . . . . . 13

4. Construyendo una PKI segura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1. Requerimientos de la CA a nivel de sistema para una PKI de alta seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15



4.2. Prácticas adecuadas a nivel criptográfico para una PKI de alta seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Sobre Thales e-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

página 3

Despliegue y Protección de una Infraestructura de Llave Pública

Introducción Hoy en día las aplicaciones de negocios son cada vez más dependientes del uso de credenciales digitales confiables en forma de llaves y certificados para controlar la manera en que los usuarios y entidades acceden a recursos del sistema y datos críticos. Siendo el mecanismo básico que permite el uso de tecnologías tales como la firma digital y el cifrado a grandes poblaciones de usuarios, las infraestructuras de llaves públicas (PKI, por sus siglas en inglés de public key infrastructure) ofrecen los elementos esenciales necesarios para un ambiente de negocios seguro y un ecosistema confiable para el crecimiento del comercio electrónico. Las PKI ayudan a establecer la identidad de las personas, dispositivos y servicios – permitiendo el acceso controlado a sistemas y recursos, la protección de datos y la determinación de responsabilidad de entidades partícipes en transacciones. Con modelos de negocios en evolución que se vuelven cada vez más y más dependientes de interacciones electrónicas que requieren autenticación en línea y cumplimiento con regulaciones de seguridad de datos más estrictas, las aplicaciones de negocios de próxima generación están confiando más en la tecnología de la PKI para garantizar alta seguridad. Como el componente central de una PKI responsable de establecer una cadena de confianza jerárquica, las autoridades certificadoras (CA, por sus siglas en inglés de certificate authorities) emiten las credenciales digitales utilizadas para establecer la identidad de los usuarios. Las CA forman la base de la seguridad de una PKI y los servicios que éstas respalda, por lo que se han vuelto el objetivo de ataques precisos y sofisticados. A fin de mitigar el riesgo de ataques contra las CA, se hace necesario tomar controles físicos y lógicos así como mecanismos de fortificación en todos los niveles de la jerarquía de confianza para asegurar la integridad de la PKI. Este documento examina los riesgos de seguridad a los que las PKI de una empresa o entidad de gobierno están expuestos y describe cómo, en la medida en que más aplicaciones de negocios de alto valor dependen de credenciales digitales de confianza, se hace necesario soluciones de alta seguridad para mitigar estos riesgos. Analizando aspectos tales como el número de certificados en uso, la importancia y valor de las aplicaciones que éstos respaldan, y si estas aplicaciones están sujetas a niveles de examinación más elevados debido a cumplimientos normativos industriales o gubernamentales, son algunos de los factores a tener en cuenta al evaluar la medida en que una PKI puede cumplir con las demandas de una organización en base a los sistemas críticos que necesite respaldar hoy y aquellos que necesite apoyar en el futuro.

página 4

www.t hales-esecurity.com

1. La PKI y el papel de la CA Las PKI proporcionan una infraestructura que permite que tecnologías de cifrado de seguridad de datos tales como firmas y certificados digitales se desplieguen de manera efectiva a escala masiva. Como elemento básico de muchos sistemas confiables, las PKI incluso están presentes en más lugares de los que uno imaginaría; respaldando servicios de administración de identidad dentro y a lo largo de redes y formando la base de capacidades de autenticación en línea. La tecnología PKI es inherente en la capa de conexión segura (SSL, por sus siglas en inglés de secure socket layer) y la seguridad de la capa de transporte (TLS, por sus siglas en inglés de transport layer security) para proteger el tráfico de internet, así como firmas de documentos y transacciones, firmas de códigos de aplicaciones, sellos de tiempo y credenciales utilizadas para impartir identidades a dispositivos electrónicos de consumo tales como smart phones y tablets. Soluciones de bases de PKI para login, identificación ciudadana, transporte público y operaciones bancarias por móvil – que incluyen comunicaciones de campo cercano (NFC, por sus siglas en inglés de near-field communications) y soluciones de MasterCard/Visa Europay. Utilizando los principios de criptografía asimétrica, la PKI facilita el establecimiento de un intercambio de datos seguro entre usuarios – asegurando la autenticidad, confidencialidad e integridad de las transacciones. Los usuarios pueden ser usuarios finales individuales, sistemas integrados, dispositivos portátiles o programas/aplicaciones que están ejecutando procesos de negocios: para mantener la simplicidad de este documento los llamaremos “usuarios” de manera genérica. La criptografía asimétrica proporciona a los usuarios en una organización un par de llaves compuestas por un componente de llave público y uno de llave privada. Una llave pública está disponible para cualquiera en la organización y puede utilizarse para cifrado o para verificación de una firma digital. Por otro lado, la llave privada debe mantenerse en secreto y sólo es utilizada por la entidad a la que corresponde, generalmente para tareas como descifrado o la creación de firmas digitales.

Con los modelos de negocios en desarrollo cada vez más y más dependientes de transacciones electrónicas y documentos digitales, el papel de una PKI ya no está limitado a sistemas aislados tales como correo electrónico seguro, tarjetas inteligentes para acceso físico o tráfico web cifrado.

A fin de unir las llaves públicas con su usuario asociado (dueño de la llave privada), las PKI utilizan certificados digitales. Los certificados digitales son las credenciales que facilitan la verificación de identidades entre usuarios en una transacción. De manera similar a un pasaporte que certifica la identidad de alguien como ciudadano de un país, el certificado digital establece la identidad de usuarios dentro de la organización. Debido a que los certificados digitales se utilizan para identificar a los usuarios a los cuales se envían datos cifrados, o para verificar la identidad del firmante de información, la protección de la autenticidad e integridad del certificado es de suma importancia a fin de mantener la fiabilidad del sistema.

página 5

Despliegue y Protección de una Infraestructura de Llave Pública

Con los modelos de negocios en desarrollo cada vez más y más dependientes de transacciones electrónicas y documentos digitales, el papel de una PKI ya no está limitado a sistemas aislados tales como correo electrónico seguro, tarjetas inteligentes para acceso físico o tráfico web cifrado. Y con regulaciones de seguridad de datos industriales y gubernamentales más estrictas, los sistemas operativos y aplicaciones de negocios convencionales se están volviendo más y más dependientes que nunca de una PKI para garantizar la confianza.

1.1. ¿Por qué son importantes las CA? Las CA administran el ciclo vital de todas las credenciales digitales dentro de una PKI, incluyendo su creación, renovación y revocación.

Las CA administran el ciclo vital de todas las credenciales digitales dentro de una PKI, incluyendo su creación, renovación y revocación. La credencial digital, a menudo referida como un certificado X.5091, valida la propiedad de una llave pública por el sujeto nombrado del certificado. Al recibir información firmada de manera digital, el certificado permite a los usuarios (firmantes y verificadores) validar que la llave privada utilizada para crear la firma pertenece de hecho a ellos como dueños legítimos. La CA es la tercera entidad en la que confían tanto el dueño del certificado como los que lo utilizan. Debido a esta dependencia crítica, las CA forman las bases de la seguridad no solo de la PKI, sino de todas las transacciones e intercambios que están protegidos por los certificados que éstas emiten. Organizaciones de tamaño mediano y grande, así como las agencias de gobierno con frecuencia despliegan sus propias CA y emiten certificados para su propio uso. Otros a menudo utilizan servicios de CA que cobran una cuota por la emisión de certificados. Los servicios de CA pueden ser utilizados por múltiples organizaciones y el público general, y por ende también cumple con el propósito de establecer la confianza entre éstos, funcionando como una tercera entidad confiable. Ya sea a partir de despliegues privados, servicios exclusivos de CA u otros disponibles al público, los certificados emitidos por éstos deben ser confiables. De no ser así, esto pone el sistema en su totalidad en peligro, haciendo posible transacciones fraudulentas que pueden ser difíciles o imposibles de distinguir de las legítimas.

1. X.509 es un estándar de la Unión Internacional de Telecomunicaciones (ITU, por sus siglas en inglés de International Telecommunications Union) que define el formato de certificados digitales utilizados por las PKI.

página 6

www.t hales-esecurity.com

1.2. ¿Cómo funciona? La CA administra la población de certificados digitales dentro de la comunidad de usuarios a la que sirve y también utiliza certificados para realizar sus propias operaciones de emisión de certificados. La CA emite certificados de usuario al firmarlos con su propia llave privada y presenta su propia llave pública y certificado para permitir la validación de esos certificados de usuario. Para proteger a los certificados de posible falsificación es imperativo que la llave de firma de la CA sea segura y que el certificado mismo de firma de la CA sea auténtico. A fin de emitir certificados digitales correctamente de manera expandible y fiable, las organizaciones en general dependen de una cadena de confianza jerárquica que incluye una CA “raíz” y CA “subordinadas”. A lo largo de la jerarquía la cadena de confianza tiene su base en la CA raíz que proporciona el “ancla” o nivel de confianza más alto en el sistema. Este enfoque permite a la CA raíz distribuir su carga de emisión de certificado a través de las CA subordinadas para mejorar la capacidad, manejabilidad y resistencia a través del sistema. La utilización de las CA subordinadas permite la segmentación de aplicaciones, una separación regional y el apoyo a una funcionalidad especializada tal como el establecimiento de autoridades de directivas para segmentar distintas geografías o áreas organizativas, autoridades de registro y autoridades de emisión que pueden utilizarse para respaldar distintas fases en el proceso de emisión, como por ejemplo la verificación de identidad de los usuarios que piden los certificados. Una vez que los usuarios tienen la aprobación para un certificado, la credencial emitida une a su identidad del mundo real con un par de llaves del tipo público/ privado. El certificado como tal incluye el nombre del usuario para quien ha sido emitido, el componente de llave pública, un rango de fechas de validez y el nombre y la firma de la CA emisora. El nombre y la firma de la CA emisora son de suma importancia ya que se utilizan para determinar la autenticidad del certificado y por ende la fiabilidad de la identidad. El usuario para quien ha sido emitido el certificado posee entonces tanto el certificado (que incluye la llave pública) como la llave privada. En muchos casos la llave privada es generada de manera local por el usuario y la llave pública correspondiente es enviada a la CA con el pedido de certificado. Entonces el certificado que contiene la llave pública se publica en un directorio abierto mientras que la llave privada es mantenida en secreto por el usuario.

página 7

Despliegue y Protección de una Infraestructura de Llave Pública

Además de publicar los certificados, los servicios de directorio de PKI también pueden proporcionar la información de estado del certificado a los usuarios – siendo esto el aspecto más importante para determinar si cada certificado es válido, o si el mismo ha sido revocado o cancelado antes de su fecha de vencimiento natural. El no detectar que un certificado ha sido revocado puede resultar en una transacción fraudulenta. Las PKI generalmente emplean uno de dos métodos para comunicar el estado de los certificados. El primero es por medio de una lista de revocación de certificados (CRL por sus siglas en inglés de certificate revocation list) que son emitidas de manera periódica a depósitos de servicios de información de Internet en línea asociados con los directorios del certificado. Estos puntos de distribución de CRL (CDP, por su sigla en inglés de CRL distribution points) proporcionan un archivo de credenciales vencidas o revocadas en un cierto punto de tiempo. El segundo método utiliza el protocolo de estado de certificado en línea (OCSP, por sus siglas en inglés de online certificate status protocol) para proporcionar una capacidad dinámica que presenta verificación de la validez del certificado en tiempo real. Ambos métodos permiten a los usuarios validar un certificado con la expectativa de que el servicio que permite este testimonio sea fiable. En la Figura 1 se muestra una representación esquemática que describe la manera en que la función de la CA se integra en la PKI.

Figura 1 – El papel de la CA dentro de la PKI general.

página 8

www.t hales-esecurity.com

2. Consideraciones de seguridad La seguridad de las CA es primordial a fin de asegurar la fiabilidad de la PKI. Debido a la estructura jerárquica de las CAs, la raíz a menudo depende de un pequeño número de llaves firmantes para establecerse como el “pilar de confianza”. Por esta razón, poner en peligro a estas llaves puede tener ramificaciones graves. La revocación de la raíz requeriría entonces la reemisión de certificados a todos los verificadores, y dado que los certificados de raíz a menudo están ampliamente publicados e insertos en dispositivos y aplicaciones, sería muy dificil llevar a cabo el proceso. Por lo tanto, es esencial una protección robusta de las llaves de raíz. La mejor práctica para asegurar las CA de raíz incluye el desplegarlas sin conexión, de modo que estén separadas de la red y generar y proteger las llaves de firma con un módulo de seguridad de hardware (HSM, por sus sigla en inglés de hardware security module) certificado. Los HSM son dispositivos diseñados específicamente para resguardar llaves y firmar operaciones. Éstos aislan las llaves, así como las operaciones de firma del software de la CA, la plataforma del servidor y del sistema operativo – todos los cuales son vulnerables a manipulaciones y otras formas de ataque. Los HSM también ayudan a automatizar los procesos y procedimientos de control de llaves que de otro modo serían manuales y proporcionan controles para asegurar la autorización correcta para el uso de la llave raíz, así como el resgaurdo seguro de la llave de repaldo en caso de ser necesario. Por lo tanto, los HSM pueden ayudar a extender la vida de las llaves así como permitir la utilización de llaves más largas sin impacto en el rendimiento en relación al software. Además de las CA de raíz, generalmente se despliegan CA subordinadas y otros componentes dentro de la PKI en servidores físicos o virtuales a través de la organización y éstos deben ser protegidos de posibles ataques, incluyendo ataques a través de la red, malware, infiltrados maliciosos y cualquier otra amenaza que pueda comprometer o interrumpir su operación. Tal como ocurre con la CA de raíz, la utilización de HSM es recomendablecomo páctica habitual. Debido a que las CA comunmente operan durante largos períodos de tiempo, se debe prestar especial consideración a las consecuencias que pueden tener las actualizaciones y modernizaciones de hardware y sistema operativo para asegurar que los cambios realizados para mejorar las operaciones no afecten la seguridad del diseño original.

«La administración y almacenamiento de llaves para la propia CA debe implementarse utilizando un HSM capaz de protegerse de ataques lógicos y físicos. Estos dispositivos deben acreditarse adecuadamente a estándares tales como FIPS 140-2 u otro estándares nacionales equivalentes».2

2. Gartner, Inc. – Punto de Decisión para Infraestructura de llaves Públicas, Robin Wilton e Ian Glazer, 9 de Julio de 2012, documento de investigación Burton IT1 G00235111

página 9

Despliegue y Protección de una Infraestructura de Llave Pública

2.1. Amenazas y vulnerabilidades generales Una evaluación de amenazas típicas a la organización debe comenzar con los problemas que impactan la postura de seguridad de cualquier sistema TI. Esto debe enfatizar el nivel de exposición que podrían tener los servidores que serán utilizados para hospedar el software del CA y depósitos asociados de información de estado de certificados frente a las entidades internas y externas no autorizadas. La evaluación debe enfocarse en: • • • • • • • • •

 menazas e impactos de potenciales violaciones de seguridad A Controles de acceso y mecanismos de autenticación Conexiones y puertos abiertos y directivas de sintaxis Mecanismos de compartimiento y “firewalls” Mantenimiento de seguridad y prácticas de reparaciones Revisiones de códigos nuevos e implementación de procedimientos Prevención y detección de virus y malware Procesos de requerimientos de cumplimiento normativo y auditoría Análisis forense para probar la integridad del sistema

El mantenimiento es un tema particularmente importante dado que los sistemas de CA pueden volverse tan aislados de los sistemas de TI centrales que quedan excluidos del mantenimiento habitual. También está el riesgo de que la CA no se mantenga actualizada con los últimos parches de seguridad por miedo a que tal actividad pueda introducir posibles problemas. Si bien las CA, y en particular las CA de raíz, se pueden aislar de las conexiones de red directas, los parches de seguridad también deben mantenerse actualizados, asegurando siempre que la fuente de estas actualizaciones esté totalmente autenticada y el código sea estudiado a fondo de manera que no actúen como conductos de posible malware. Si bien estos vectores de ataque se aplican a cualquier sistema TI, su impacto se amplifica por el papel crucial que juegan las CA y la PKI en la organización. En la siguiente sección dedicamos nuestra atención a vulnerabilidades y consecuencias que son específicas de una CA.

2.2. Incidentes de seguridad y consecuencias específicas de la PKI Dependiendo de qué área de una PKI sea potencialmente vulnerable, puede haber distintos niveles de repercusiones a lo largo del sistema. Por ejemplo, un ataque en las llaves de firma de raíz tendrá impacto en el sistema entero ya que página 10

www.t hales-esecurity.com

pone en peligro la fiabilidad de todos y cada uno de los certificados emitidos por todas las CA subordinadas. Por lo tanto, la seguridad de la llave de firma de raíz siempre es el aspecto más importante a tener en cuenta. Aunque una brecha en la seguridad de las llaves de firma de una CA subordinada puede tener un impacto más limitado, esto depende del tamaño y la naturaleza de la comunidad a la cual ésta emite los certificados; el problema más urgente desde una perspectiva de infraestructura es asegurar que el sistema completo sea confiable. Los incidentes de seguridad a las CA pueden provenir de ataques basados en la red y en general se pueden manifestar en tres situaciones. En primer lugar, el malware puede atacar el software de CA y generar aprobaciones o pedidos fraudulentos para lo que parecerían certificados legítimos. En segundo lugar, el código o infiltrados maliciosos pueden intentar robar llaves de firma privadas que posibilitarían el proceso de aprobación de certificado y permitiría que certificados falsos parecieran legítimos y emitidos a pedido. En tercer lugar, las llaves de firma pueden sustituirse con llaves malintencionadas que son conocidas por el atacante en lugar de robadas. Cualquiera de estas situaciones de ataque tiene un claro impacto de largo alcance en la organización, destruyendo la confianza del sistema entero. Los ataques en los que el malware toma el control del software de CA pueden aprovecharse de debilidades inherentes del software – vulnerabilidades que a menudo están asociadas con la manera en que se configura el software. Una evaluación de amenazas y vulnerabilidades realizadas por un asesor independiente capacitado (QSA por sus siglas en inglés de qualified security assessor) puede identificar puntos débiles en los aspectos de infraestructura y configuración de la CA para fortalecer la postura de seguridad de la PKI. Para protegerse de estas amenazas hace falta más que un simple enfoque en proteger a las llaves de firma de la CA mientras están en uso. Se requiere una valoración de las llaves, el proceso de administración de certificado y las distintas tareas operativas que impactan su ciclo de vida. A lo largo de la última década se han establecido ampliamente una cantidad de “estándares de cuidado adecuado” para la administración de llaves. Los mismos están cubiertos más adelante en este documento y se les debe seguir para proteger la generación, uso e intercambio de llaves entre sistemas para fines de respaldo y recuperación – sujetos a mecanismos administrativos que ejecutan la separación de tareas.

A lo largo de la última década se han establecido ampliamente una cantidad de “estándares de cuidado adecuado” para la administración de llaves.

Si bien proteger las llaves de firma utilizadas por la CA es un aspecto de seguridad importante, es sólo una parte del espectro de seguridad que debe tenerse en cuenta al desplegar una PKI. Las situaciones de ataque basado en la red, tal como aquellas en las que un atacante toma el control de los servidores ejecutando el software de CA, han provocado consecuencias graves para los proveedores de credenciales. Por esta razón, es crucial que las CA subordinadas implementen niveles de protección apropiados que incluyan controles robustos para la emisión de certificados, reportes de estado y procesos de revocación. página 11

Despliegue y Protección de una Infraestructura de Llave Pública

3. ¿Por qué es importante proteger su PKI? Los sistemas que consisten solo en software (es decir, sistemas que no utilizan hardware dedicado tales como HSM para operaciones criptográficas) pueden ser por naturaleza vulnerables a muchas de las amenazas descritas anteriormente y es por ello que se debe seguir las mejores prácticas al desplegar las PKI para fortalecerlas contra ataques.

Si bien nunca se puede eliminar el riesgo de ataque, la concientización sobre las capacidades evolutivas de los atacantes, las motivaciones que pueden tener en base al valor de sus aplicaciones, los datos que procesan y el potencial en cuanto a incidentes de seguridad le permitirán evaluar y prepararse para posibles consecuencias. Considere una situación donde un servicio de administración de identidad dentro de una empresa emite tarjetas inteligentes a empleados para permitir acceso controlado a recursos físicos y virtuales del negocio. Tales tarjetas, además de llevar la imagen del usuario individual, contienen llaves privadas cifradas que permiten a los empleados certificar su identidad para ganar acceso a áreas de trabajo y servicios de computación y para firmar y ejecutar documentos y transacciones de negocios. Si una CA que emite las llaves y certificados queda comprometida y se emiten tarjetas inteligentes fraudulentas, no se puede seguir confiando en la identidad del personal dentro de la organización. Las entidades no legítimas que toman el lugar de usuarios autorizados podrían ganar acceso a recursos críticos, ejecutar transacciones que de otro modo serían no autorizadas y poner al negocio en peligro.

página 12

www.t hales-esecurity.com

Los vendedores de software que dependen de firmas digitales para dar cuenta de la autenticidad de su producto podrían ver a su negocio caer en picada si sus clientes no confiaran en que el software realmente proviene de una fuente legítima. Si bien los procesos de verificación de software suelen realizarse en segundo plano, los consumidores tienen la expectativa de que pueden confiar en lo que cargan en sus sistemas, en especial cuando se trata de actualizaciones por las que están pagando a vendedores respetados. Una CA que queda comprometida sería capaz de emitir certificados fraudulentos, lo que llevaría a clientes desprevenidos a instalar lo que parecería ser software firmado de manera legítima de una fuente falsa. Tal situación podría potencialmente infectar la plataforma del cliente, afectando la reputación del desarrollador, e incluso podría hacer fracasar el negocio. Las CA privadas cuyo negocio consiste en “vender confianza” de manera que las aplicaciones que utilizan los servicios PKI puedan considerarse fiables, deben prestar particular atención a la seguridad de sus CA. Estos tipos de servicios que respaldan facturaciones en línea y autenticación de documentos pueden perder y en algunas circunstancias han perdido la totalidad de sus negocios debido a que su CA fue comprometido.

3.1. Factores a considerar al determinar sus requisitos El número de certificados emitidos por la CA, la cantidad de aplicaciones que éstos respaldan, su valor y el nivel al cual estas aplicaciones estén sujetas a escrutinio más elevado debido a cumplimientos normativos industriales o gubernamentales, son algunos de los factores cruciales a tener en cuenta al evaluar si una PKI puede cumplir con las demandas de una organización. Otros aspectos que también pueden influir en los requisitos de seguridad incluyen: • Geografía y topología incluyendo socios y entidades externas • Procesos de aprobación incluyendo supervisión y responsabilidad • Procesos de cumplimiento normativo y auditoría • Velocidad de emisión y validación y latencias asociadas • Presupuesto disponible

página 13

Despliegue y Protección de una Infraestructura de Llave Pública

4. Construyendo una PKI segura Los factores que las organizaciones deben considerar al fortalecer su postura de seguridad, y que también deben considerarse al desplegar una PKI, incluyen aspectos de procedimiento así como técnicos. Los aspectos de procedimiento involucran directivas sobre controles de acceso, separación de tareas, longitudes de llave y mecanismos de auditoría que ayudan a mitigar los riesgos. Los aspectos técnicos incluyen la forma en que se diseñan y configuran las CAs, y la manera en que se protegen las CA y sus llaves de firma.

El CP y CPS juntos definen el nivel de confianza que la organización puede poner en el certificado.

Lo más importante a tener en cuenta desde una perspectiva de procedimiento de PKI es la importancia de la directiva de certificado y el estado de práctica de certificación (CP/CPS, por las siglas en inglés de certificate policy y certification practice statements). La preparación de estos documentos, que a menudo exigen una obligación legal, describe la manera en que se manejan los certificados dentro de la organización y por ende establecen la manera en que se implantan las soluciones técnicas para apoyar. El CP se enfoca en los certificados en sí y el CPS en las CA que emiten los certificados. Como parte del proceso de administración del ciclo de vida del certificado el CP requiere que los procesos de generación de llaves, almacenamiento de llaves, respaldo, recuperación y distribución estén bien documentados y de acuerdo con los requisitos normativos. Debido a que el CPS traduce directivas de certificado en procedimientos operativos, debe alinearse adecuadamente no solo con los aspectos de seguridad de los que debe ocuparse, sino también con los requisitos operativos y legales del negocio. Otros factores pueden incluir la manera en que la organización coordina y une a los individuos requeridos para una ceremonia de llaves de una CA de raíz o subordinada y la manera en que son elegidos para representar las partes correctas de la organización. Por lo tanto, a la hora de construir una PKI fortalisida es esencial articular un CP/CPS equilibrado, dado que el mismo describe la manera en que se emiten y administran los certificados a lo largo de su ciclo de vida. El CP y CPS juntos definen el nivel de confianza que la organización puede poner en el certificado. Estructuralmente, una organización que emite certificados a números crecientes de apliaciones de alto valor debe considerar utilizar una capacidad de revocación de certificados distribuida, de manera que no haya un punto único de falla en caso de que se produzca un incidente en el que se ponga en peligro la confianza de una CA. Cuando aumenta el volumen de los certificados pueden desplegarse las CA subordinadas para equilibrar la carga de emisión de certificados con el fin de lograr una mayor fiabilidad. Si se está utilizando un cierto número de certificados para operaciones de alto valor, los mismos se pueden ubicar en una estructura PKI/CA separada que esté reforzada con medios técnicos y procedimientos especiales que puedan proporcionar un mayor grado de capacidades de protección y respaldo para asegurar la resistencia.

página 14

www.t hales-esecurity.com

Este tipo de segmentación de las CA también facilitará los requisitos de auditoría que a menudo acompañan mayores niveles de examinación de aplicaciones de alto valor. Cuando se mantienen PKI separadas con distintos niveles de seguridad, las mismas deberán recibir similares niveles de protección para sus llaves de firma.

4.1. Requerimientos de la CA a nivel de sistema para una PKI de alta seguridad Las PKI de alta seguridad deberán diseñarse para ser confiables y resistentes. Las CA de raíz que forma la base de la confianza del sistema nunca deberán estar conectadas a la red, ni siquiera para fines de mantenimiento de rutina tales como actualizaciones de software. Los elementos críticos deberán estar siempre aislados para protegerlos de posibles ataques basados en la red, y los parches de seguridad instalados en estos sistemas deberán estar completamente revisados para asegurarse de que son auténticos y no un conducto para malware. Se deberán desarrollar e implementar planes de continuidad de negocios y recuperación de desastres; y se debe mantener documentación precisa y actualizada para asegurarse de que la configuración del sistema pueda replicarse y de que las llaves cruciales puedan respaldarse y recuperarse con seguridad de esto ser necesario. La jerarquía de la CA debe diseñarse con una redundancia integrada, de manera que no haya puntos únicos de fallas y de manera que los procesos criptográficos no representen cuellos de botella operativos que impacten el rendimiento. La CA debe asegurarse de que las llaves privadas se mantengan en secreto y sólo sean utilizadas por sus dueños o software autorizados. Las llaves públicas siempre deberán estar unidas a una identidad por medio de certificados firmados por la CA, y la información del estado del certificado debe estar protegida en todo momento durante el depósito y la distribución. La información de revocación de certificado debe ser firmada por la CA o una CA subordinada designada por una CA de alto nivel. Los procedimientos realizados para la revocación de cualquier certificado se deben documentar en el CPS. El CPS debe detallar quién puede presentar pedidos de revocación y la manera en que se los debe presentar. Para CRL estáticos, cada entrada debe detallar la hora a la que se emite a fin de asegurar un mejor control. Y si se utiliza OCSP, siempre se debe firmar las respuestas para evitar que respuestas falsas revoquen certificados válidos.

página 15

Despliegue y Protección de una Infraestructura de Llave Pública

Las organizaciones que desplieguen una PKI deben evaluar el riesgo e impacto de una violación en la infraestructura de emisión de credenciales y determinar su enfoque para la revocación de certificados en distintos niveles de la jerarquía. Cuando una organización despliega una solución de revocación robusta, la misma debe ser compatible con los procesos de auditoría que detectarán cualquier violación y desencadenarán la reemisión y revocación de credenciales.

4.2. Prácticas adecuadas a nivel criptográfico para una PKI de alta seguridad Una PKI fortalecida debe tener tecnología criptográfica de alta seguridad en su núcleo. Esta sección describe diez prácticas criptográficas adecuadas que refuerzan la seguridad de la PKI específicamente para apoyar las aplicaciones de negocios de alto valor. Cuando se trata de desplegar aplicaciones seguras basadas en una PKI, las mismas deben tenerse en cuenta por su efectividad representando los estándares de cuidado debido: 1. Saber el origen y calidad de sus llaves. Las llaves de firma cruciales deben provenir de una fuente de entropía de alta calidad que utilice números aleatorios. Los HSM ofrecen un ambiente donde las llaves se generan utilizando un proceso de generación de llaves certificado y mecanismos comprobados para proporcionar la seguridad adecuada. 2. Saber exactamente dónde están sus llaves y quién/qué sistemas pueden tener acceso a ellas en todo momento. Las llaves privadas de la CA utilizadas para firmar certificados deberán mantenerse dentro de un ambiente protegido reforzado y siempre que abandonen el dispositivo, deben cifrarse sólo con algoritmos y longitudes de llaves aprobados. Al utilizar HSM usted sabe que sus llaves están en un lugar y no dispersas a lo largo del ambiente de software, en múltiples lugares con distintas restricciones de acceso. No se debe utilizar llaves importadas no generadas por un HSM, debido a las serias dudas sobre la calidad de las llaves y el nivel de protección que puedan haber recibido durante el tránsito. 3. Asegurarse que cada llave sólo se utiliza para un fin. Las aplicaciones cruciales deberían estar gobernadas por actividades de administración de llaves distintas y específicas. Un control de llaves fortalecidas asegura un control de emisión de certificados y la posibilidad de ser capaz de probarlo es importante para fines de auditoría. Los HSM están diseñados precisamente para proporcionar estos servicios importantes que facilitan la aplicación de la política de seguridad de la organización. página 16

www.t hales-esecurity.com

4. Formalizar un plan para rotar, refrescar, retener y destruir llaves. Las llaves con demasiado uso son un riesgo, así como las llaves obsoletas. Los HSM están construidos con la finalidad de salvaguardar y administrar las llaves delicadas con seguridad a lo largo de su ciclo de vida. 5. Sólo utilizar algoritmos y longitudes de llave comprobados y aceptados globalmente. La utilización de HSM de alto rendimiento con aceleradores criptográficos integrados permitirá que se utilicen llaves de mayor tamaño (por ejemplo, RSA de 4096 bits) y funciones hash más fuertes (por ejemplo, SHA256); esto proporcionará seguridad efectiva mucho después de que las llaves más pequeñas se hayan vuelto vulnerables a ataques de procesadores más rápidos y criptoanálisis sofisticados.

Los niveles de certificación utilizados por el estándar FIPS definen los grados cualitativos de seguridad asignados a productos en base a pruebas de algoritmo, métodos de autenticación utilizados y mecanismos de protección contra alteraciones físicas. En el caso de los Common Criteria, los niveles de evaluación de seguridad están basados en la seguridad y los requisitos funcionales establecidos para la clase específica del producto. 6. Adoptar productos certificados de manera independiente cuando sea posible. Si está considerando escribir software criptográfico por su cuenta, puede estar poniendo su seguridad en riesgo. Los HSM disponibles de manera comercial en general están diseñados en cumplimiento con estándares de FIPS 140-2 y de Common Criteria, proporcionando un ambiente seguro en el que las llaves pueden estar protegidas de substracciones. 7. Implementar controles duales con una fuerte separación para todas las operaciones delicadas. Con una criptografía inquebrantable, el atacante irá por las llaves y las personas que las administran. Evitar los “súper usuarios” y puntos de ataque únicos. Los HSM permiten a las organizaciones aplicar estas directivas al implementar la supervisión de múltiples partes para las actividades administrativas, de manera que ningún individuo tenga acceso único a llaves delicadas.

página 17

Despliegue y Protección de una Infraestructura de Llave Pública

8. Asegurarse que sus llaves están respaldadas con seguridad y disponibles para sus sistemas de redundancia. Las llaves de firma privada de CA deberán ser respaldadas, almacenadas y recuperadas sólo por entidades fiables y autenticadas utilizando los mecanismos prescritos para aplicar la separación de tareas. Las copias de respaldo de las llaves de firma privadas de CA deberán estar sujetas al mismo o mayor nivel de controles de seguridad que las llaves de firma activas. También debe haber procesos de recuperación establecidos para llaves criptográficas utilizadas por cualquier aplicación de alto valor. Proteger a estas llaves de aplicación debe considerarse tan importante como proteger a las llaves CA/PKI. 9. Controlar el acceso a los sistemas y funciones criptográficas utilizando una autenticación fuerte. La seguridad depende de la consistencia; la utilización de HSM certificados y resistentes a las alteraciones mejora la confianza en cuanto a que las llaves están protegidas a lo largo de su vida útil. 10. Nunca permitir que nadie ni ningún sistema “abierto” tome posesión de una llave privada o secreta. El robo de estas llaves puede permitir que los atacantes puedan tener acceso a datos pasados y datos futuros sin ser detectados. Los HSM proporcionan separación del ambiente de TI al alejarlos de los servidores y ubicarlos en un dispositivo reforzado. Una PKI reforzada de alta seguridad proporciona un ambiente que protege a las llaves criptográficas del robo y los usos indebidos.

página 18

www.t hales-esecurity.com

4. Conclusión Al construir una PKI fortalecida, las organizaciones deben considerar las operaciones que respaldará no solo hoy, sino también en el futuro. Establezca el número de usuarios que respaldará, la movilidad que tendrán y la manera en que son autenticados. Una PKI de alta seguridad generalmente dependerá mucho más de políticas y procedimientos sólidos que de mecanismos técnicos específicos. Por lo tanto, las mejores prácticas deberán enfocarse en asegurarse que las políticas y procedimientos correctos estén vigentes antes de saltar a opciones de tecnología. Las herramientas y mecanismos específicos indudablemente pueden fortalecer la seguridad de la PKI, pero los mismos deben desplegarse una vez que se establece una base de políticas sólida. Una vez la política y práctica están listas, piense en maneras en las que se pueda fortelecer la CA para cumplir con las necesidades de seguridad de su organización. Tanto el registro, emisión y revocación de certificados como las funciones de firma asociadas que establecen la confianza en estos servicios dependen en la protección efectiva a largo plazo de llaves. Los HSM pueden proporcionar la seguridad que necesita para proteger aplicaciones de alta seguridad en los años venideros. Las prácticas tales como las detalladas en este documento proporcionan un marco para el despliegue de una PKI fortalecida para cumplir con las exigencias de seguridad de hoy y mañana.

página 19

Sobre Thales e-Security Thales e-Security es un proveedor global líder de soluciones de protección de datos. Con 40 años de experiencia en la protección de la información corporativa y gubernamental más delicada, las soluciones de cifrado y administración de llaves de Thales son un componente esencial para cualquier infraestructura de TI. Thales facilita la seguridad de aplicaciones de negocios basadas en software y reduce los costos y la complejidad asociados con la utilización de criptografía a través de la

Follow us on:

Americas – Thales e-Security Inc. 900 South Pine Island Road, Suite 710, Plantation, FL 33324 USA • Tel:+1 888 744 4976 or +1 954 888 6200 • Fax:+1 954 888 6211 • E-mail: [email protected] Asia Pacific – Unit 4101 41/F 248, Queen’s Road East, Wanchai, Hong Kong, PRC • Tel:+852 2815 8633 • Fax:+852 2815 8141 • E-mail: [email protected] página 20 East, Africa – Meadow View House, Long Crendon, Aylesbury, Buckinghamshire HP18 9EQ • Tel:+44 (0)1844 201800 • Fax:+44 (0)1844 208550 • E-mail: [email protected] Europe, Middle

©Thales e-Security • November 2012 • LH0782

empresa y en la nube. Para más información, visite www.thales-esecurity.com