it-swarm-es.com

Selección de proveedores de soluciones PKI

¿Qué buscaría en una solución PKI (X.509-) y por qué buscaría eso, dadas las siguientes restricciones:

  • El conocimiento disponible de programación/ingeniería de software es limitado (es decir, "OpenSSL con un puñado de scripts de Perl" no es un enfoque viable)
  • Los procesos se entienden razonablemente bien (por ejemplo, el ciclo de vida del certificado)
  • Algunos certificados (raíz/intermedios) tendrán un alto valor monetario y deben protegerse en consecuencia (¿HSM?)
  • Manejar "un par de diez mil" identidades en varias organizaciones con derechos de administrador delegados
  • Es probable que pronto surja como requisito una solución basada en hardware (tarjeta inteligente o de otro tipo).
  • Solución autohospedada local

He identificado algunos candidatos entre los "sospechosos habituales", pero tengo algunas dudas (¿el mercado parece haber madurado muy poco en los últimos años?). Por tanto, no nombraré a los candidatos, sino que pediré aportaciones imparciales.

9
Matthias Leisi

Divulgación completa: trabajo para Seguridad de voltaje . Creo que es mejor decirlo desde el principio, en lugar de darle una perorata de ventas y luego "accidentalmente" señalarle nuestro sitio web. Si bien esta no es una respuesta patrocinada por la empresa de ninguna manera, admito libremente que mis puntos de vista no son imparciales. Intentaré minimizar la filtración en esta respuesta, pero lea con el grado apropiado de escepticismo.

El problema fundamental con los esquemas de cifrado asimétrico no es el cifrado, sino la gestión de claves. Entonces, lo que distingue a los sistemas PKI no es la seguridad del cifrado, que es idéntico, sino la facilidad de aprovisionamiento, eliminación y administración general del sistema de usuarios.

Entonces, las preguntas que le haría a un proveedor de cifrado asimétrico son:

  1. ¿Cuál es el proceso para traer un nuevo destinatario de datos cifrados al sistema?
  2. ¿Cómo se almacenan, protegen y respaldan las claves privadas?
  3. ¿Cómo se administran las credenciales?
  4. ¿Cómo se manejan los cambios de nombre? (Por ejemplo, alguien se casa y cambia su nombre e inicio de sesión en el sistema: ¿cuáles son los impactos, si los hay?)
  5. ¿Cómo pueden los dispositivos de prevención de pérdida de datos escanear los datos cifrados para garantizar que los internos no estén utilizando la función de cifrado como una forma de contrabandear datos fuera de la empresa?

[~ # ~] editar [~ # ~]

(esto es lo que dejé originalmente, porque se sentía demasiado vendido)

Razones para hacer las preguntas anteriores:

  1. La mayoría de los sistemas PKI requieren que el destinatario cree un par de claves pública/privada antes de poder enviarles datos. Esto inhibe el uso ad-hoc del sistema, en el que las personas pueden cifrar para cualquier destinatario.
  2. Si se pierde una clave privada, se pierden los datos cifrados con la clave pública correspondiente. Fin de la historia. Cualquier sistema PKI serio tendrá algún mecanismo para recuperar claves privadas perdidas. Si se trata de una base de datos de claves, debe pensar en cómo está protegida y asegurarse de que se realice una copia de seguridad con frecuencia. También considere la replicación si la solución tiene que existir en varios centros de datos para una alta disponibilidad.
  3. Esta es fácil: los usuarios deben proporcionar algún tipo de credenciales de autenticación para obtener acceso a las claves privadas. Pregunte cómo se puede integrar esto en los métodos de autenticación existentes.
  4. Imagina que Mary Jones se casa (o se divorcia) y se convierte en Mary Smith. Utilizando las credenciales de "Mary Smith", necesita poder acceder a los datos que se habían cifrado previamente para "Mary Jones". El sistema PKI debe manejar este caso con elegancia. La alternativa es buscar todos los datos cifrados para "Mary Jones", descifrarlos y volver a cifrarlos para "Mary Smith". ¡Qué asco!.
  5. Básicamente, el dispositivo DLP debe poder acceder al texto sin formato de los datos cifrados. Pregunte cómo se puede lograr esto.
5
Dave Mulligan

PKI es un 5% de tecnología, 95% de procedimientos. Las partes básicas de los certificados X.509 son extremadamente simples: eso es solo firmas . Los primeros algoritmos utilizables para eso se describieron a fines de la década de 1970, y los detalles se habían resuelto en su mayoría a principios de la década de 1990 (eso no es para menospreciar la investigación criptográfica de las últimas dos décadas, pero en la práctica, las firmas PKCS # 1 v1.5 son suficientemente bueno).

Los procedimientos describen exactamente lo que sucede, preferiblemente al "nivel de pulsación de tecla": las operaciones delicadas como la renovación de un certificado de CA intermedio deben ser realizadas por un operador bajo el escrutinio de al menos un auditor que comprueba que no se presione ninguna tecla ni se haga clic en ningún botón a menos que se especifique explícitamente en el procedimiento. El alcance es amplio; también incluye protecciones físicas en la habitación que contiene la CA, posición de cámaras de video de vigilancia ...

Entonces, la pregunta número uno que debe hacerse es: ¿el producto viene con un manual completo de procedimientos, o al menos con plantillas de procedimientos para ser ajustadas al entorno local? Escribir estos procedimientos y hacerlos cumplir es lo que costará más en una PKI. Esto requiere saber lo que sucede "bajo el capó": no una cuestión de "programar cómo", sino más bien tener nociones claras y definidas de lo que es una clave privada y lo que puede hacer. Si no tiene este tipo de conocimiento interno, y el producto PKI tampoco viene con suficiente información sobre ese tema, entonces tendrá que contratar a un consultor, y eso no es barato (debería saberlo).


Autenticación, Gestión de Identidad y Autorización no son lo mismo. Cuando hablamos de PKI en general, a menudo tenemos en mente una serie de requisitos que se relacionan con tres distintas actividades:

  • Gestión de identidad : seguimiento de los usuarios, su nombre, ID de empleado, fecha de la última modificación, etc. Esta parte siempre es necesaria, pero puede ser "implícita" o puede ser tan simple como una hoja de cálculo de Excel si solo hay dos docenas de usuarios. Para 20k usuarios, necesitará algo más evolucionado.

  • Autenticación : asegurarse de que alguien que pretende ser el usuario [~ # ~] u [~ # ~] es efectivamente el usuario [~ # ~] u [~ # ~] .

  • Autorización : conocer y realizar un seguimiento de las operaciones que un usuario determinado [~ # ~] u [~ # ~] tiene permitido disparador, qué datos puede leer y/o escribir.

Estas actividades son distintas. Algunos productos combinan algunos o todos, y esto puede implicar restricciones incómodas. Por ejemplo, considere Active Directory : como servidor LDAP, puede usarse para la administración de identidades, pero su componente Kerberos maneja la autenticación; esto hace que sea bastante engorroso integrar la autenticación no basada en contraseña con Active Directory.

Los tres tipos de actividades deben tener un puente, pero aún así mantenerse separados. Los certificados X.509 son principalmente autenticación, pero la emisión de certificados debe alimentarse de la gestión de identidad para saber qué poner en los certificados (un certificado vincula una clave pública a una identidad). Una lección muy importante sobre PKI es que los certificados no son buenos para la autorización . Uno de los primeros errores que la mayoría de las personas comete con respecto a PKI es que intentan incrustar derechos de acceso en los certificados, pero luego falla y entienden que no deberían haberlo hecho (la razón exacta es difícil de precisar pero se relaciona con el asincronismo inherente de emisión de certificados).

Entonces, esto trae una segunda pregunta para hacerle al proveedor: ¿su producto permite la separación de la administración de identidad, la administración de certificados y la autorización, y qué puentes son compatibles entre ellos?

Como ilustración, no una recomendación de producto, considere Microsoft Forefront Identity Manager , una suite que incluye varios productos: FIM Service/Portal para la administración de identidades , FIM CM para certificados (un envoltorio alrededor de una CA, también maneja tarjetas inteligentes), Sincronización FIM para unir la gestión de identidad con servidores AD y, por lo tanto, FIM CM, ...


Si su PKI tiene un valor serio (y si no es así, ¿para qué molestarse?), Entonces querrá proteger su (s) clave (s) privada (s) de CA en un Módulo de seguridad de hardware . Preferiblemente, establezca la CA raíz fuera de línea, sobre la base de que una CA fuera de línea no puede ser pirateada desde la red. Distribuir la clave pública de la CA raíz en todos los sistemas cliente es un costo importante, y no desea hacerlo dos veces, por lo que realmente realmente no desea ver su raíz CA comprometida o perdida o ambas.

Dado que todavía tiene muchos certificados para emitir, probablemente necesite tener una CA intermedia en línea . Puede recuperarse de una pérdida o compromiso de esa CA sin tener que redistribuir una nueva clave de CA raíz en todos los sistemas cliente (ese es el punto de separar la CA raíz de la CA intermedia), pero eso no significa que sería feliz de ver su clave privada de CA intermedia robada. Entonces, un HSM para esa clave también sería genial.

Por lo tanto, pregunte a su proveedor de PKI lo siguiente: ¿son compatibles con HSM?

Tarjetas inteligentes son como pequeños HSM, pero en el lado del cliente. La compatibilidad con tarjetas inteligentes requiere cierta inicialización; en algún momento, habrá algún código específico de tarjeta inteligente ejecutándose en algunos sistemas de escritorio. Nuevamente, el producto PKI puede incluir algún soporte para eso, o no. Los proveedores de tarjetas inteligentes también pueden ayudar.


Si sus certificados son para cifrado , en lugar de firmas y autenticación, entonces querrá algunos depósito de claves . De hecho, cuando algunos datos se cifran con una clave privada y la clave privada se pierde, los datos se pierden. De ahí la necesidad de una copia de seguridad, en alguna parte. Este suele ser el caso de correos electrónicos cifrados . Tales copias de seguridad de claves son muy sensibles (son un objetivo muy tentador para los atacantes) por lo que no deben improvisarse.

Entonces: ¿la solución PKI incluye un sistema de custodia de claves?

Por otro lado, ciertamente no desea depositar las claves utilizadas para las firmas, porque esto pondrá en peligro cualquier valor legal que pueda estar asociado a estas firmas (los detalles varían según el contexto y la jurisdicción, pero como regla general claves de firma de depósito en garantía). Esto implica que los usuarios que quieran cifrar y firmas necesitarán dos claves, por lo tanto, dos certificados. De ahí otra pregunta: ¿la solución PKI admite usuarios con múltiples certificados?


Todo lo anterior se trata de PKI para X.509. Pueden existir soluciones alternativas, como criptografía basada en ID (de qué se trata "Voltage", según lo vincula @Dave), o sistemas descentralizados como OpenPGP Web of Trust . Un paso inicial necesario es escribir sus requisitos. Tienes las limitaciones; eso es bueno. Pero también debes responder a la siguiente pregunta: una PKI, sí, pero ¿para hacer qué?

4
Thomas Pornin