Entidad Certificadora y Políticas Pertinentes

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Entidad Certificadora y Políticas Pertinentes"

José Ignacio Palma Álvarez
hace 8 años
Vistas:

1 Entidad Certificadora y Políticas Pertinentes Seguridad de Sistemas Departamento de Informática Universidad Técnica Federico Santa María Nicolás Troncoso Carrère ntroncos@alumnos.inf.utfsm.cl Valparaíso, 25 de noviembre de 2005 Resumen La mayor vulnerabilidad en las comunicaciones de hoy en días es el no poder saber a ciencia cierta con quien uno esta estableciendo contacto. Existen métodos para asegurar un canal de comunicación, sin embargo no sabemos si el canal de comunicación que hemos abierto, lo hemos abierto con quien deseamos o con algún tercero. Hasta el momento la única forma para identificarse ante alguien es a través de una tercera entidad que avale la identidad de la contra parte en la comunicación. Estos anillos de confianza están basados en las Entidades Certificadora, las que avalan la identidad de otras organizaciones o individuos. 1. Introducción SSL es el método mas común para transportar infamación confidencial, en nuestro departamento es ampliamente usado en los servicios que este presta a sus alumnos, funcionarios, profesores, y terceras entidades. El principal problema que tiene SSL es que si no esta firmado por una entidad certificadora, el servicio es muy susceptible al ataque MIM (Man in the Middle). Poseer una entidad certificadora que firme todos los certificados SSL del departamento de informática disminuye el riesgo de MIM de manera considerable. Por eso es imprescindible la instauración de dicha entidad en nuestro departamento. En el capitulo dos se explicara lo que hace una entidad certificadora y como funciona. En el capitulo tres se hará una propuesta de cuales son las mejores practicas de seguridad al poseer una Entidad Certificadora. En el capitulo cuatro se enumera las políticas especificas adicionales que deben ser implementadas en el departamento de informática. 1

Existen métodos para asegurar un canal de comunicación, sin embargo no sabemos si el canal de comunicación que hemos abierto, lo hemos abierto con quien deseamos o con algún tercero.

2 2. Entidad Certificadora La Entidad Certificadora, de ahora en adelante CA (Certificate Authority) es una entidad que emite certificados al firmar con su propia firma digital las firmas de terceros. Un CA debe guardas las llaves, certificados y un registro completo de los certificados que han sido revocados. La firma de un certificado por un CA implica que el CA esta avalando la identidad de la entidad a quien se le firma su certificado, de la misma forma que un notario lo hace en una notaría Modo de funcionamiento Las mejores practicas indican que las terceras entidades deben postular a ser certificadas, una vez que el CA ha comprobado completamente la identidad del tercero, y esta dispuesto a avalar su identidad, entonces se emite un certificado digitalmente firmado. 1. Contacto inicial. 2. verificación de identidad. 3. Emisión del certificado. Adicionalmente la firma digital de la entidad certificadora debe estar disponible para ser instalada como certificado de raíz por los usuarios Creación de un CA Para crear un CA solo se requiere del software openssl. Los detalles del la creación no serán cubiertos por este documento, ya que se encuentran ampliamente explicados en [1]. 3. Políticas de Seguridad A continuación se describen las mejores políticas de seguridad para con un CA[2] Hardware Para un CA Para estableces un CA se debe utilizar un notebook, cuya única función sera ser CA. Este notebook deberá operar con un sistema operativo Linux y deberá estar instalado openssl. Este notebook deberá proveer almacenamiento removible como; USB-Pendrive, CDRW, Floppy Disk, etc. Bajo ninguna circunstancia el notebook 2

La firma de un certificado por un CA implica que el CA esta avalando la identidad de la entidad a quien se le firma su certificado, de la misma forma que un notario lo hace en una notaría. 2.1.

3 podrá ser conectado a una red. No es necesario efectuar upgrades al sistema operativo, a menos que sea para implementar nueva funcionalidad en el CA. Toda actualización debe ser hecha offline. Físicamente el notebook debe ser almacenado en una caja fuerte a la que una única persona no tenga acceso. Se debe requerir de al menos dos llaves para accesar la caja fuerte, y estas llaves no deben ser custodiadas por una misma persona. Finalmente el notebook deberá estar rotulado con un mensaje similar al siguiente: Este notebook contiene secretos criptográficos Debe estar físicamente asegurado (caja fuerte) o custodiado por dos personas mínimo durante todo el tiempo de su operación. Cuando la vida útil haya finalizado, el disco duro de este notebook no puede ser reusado y deberá ser destruido de forma apropiada[3] Recuperación de Desastres Con la creación de CA, se debe crear un set de respaldos que incluya la llave privada del CA y el sistema operativo usado. Adicionalmente se debe incluir los procedimientos completos de como instalar, configurar y poner en operación el CA. La información de estos respaldos el altamente sensible, por lo que ella deberá estar custodiada en una caja fuerte bancaria, ya que su uso sera el mínimo, ninguno en el mejor de los casos. El medio que contenga la llave privada del CA deberá estar rotulado apropiadamente con un mensaje similar al siguiente: Este CD contiene secretos criptográficos Debe estar físicamente asegurado (caja fuerte) o custodiado por dos personas mínimo durante todo el tiempo de su operación. Cuando la vida útil haya finalizado deberá ser destruido de forma apropiada[3] Procedimientos Junto con el notebook se debe almacenar los procedimientos completos del uso del CA. Esto debe incluir los pasos y políticas propias de cada CA Terminación Cuando hayan cesado las actividades del CA el disco duro del notebook y todo los medios que contengan la llave publica deben ser destruidos apropiadamente[3]. En caso de que compromiso del CA, se debe emitir un comunicado de seguridad y revocar todos los certificados para ser recreado con una nueva CA. 3

Se debe requerir de al menos dos llaves para accesar la caja fuerte, y estas llaves no deben ser custodiadas por una misma persona.

4 4. Implementación en el DI Para implementar un CA en el Departamento de Informática se tiene que especificar varios parámetros. Para quienes emitirá certificados el DI? Sólo el dominio inf.utfsm.cl A todo quien lo solicite. El DI postulará a ser una entidad certificadora subordinada de la que actualmente existe en DCSC? Una vez resuelta las anteriores preguntas se puede hacer un delineamiento verdadero de los alcances de un CA en el departamento de informática Políticas Mandatorias recomendadas Todo sitio SSL del DI debe tener certificados validados por el CA del DI. Todo sitio del DI, que emita/reciba información sensible de hacerlo sobre SSL. En caso de que el DI sea un CA independiente se recomienda que cree dos sub CA firmados por el primero. Uno para firmar certificados pertenecientes exclusivamente al dominio inf.utfsm.cl y el segundo CA para firmar certificados que no pertenezcan al dominio antes mencionado. 5. Conclusión Es de vital importancia la pronta implementación de un CA en el Departamento de Informática, pero para hacerlo se debe tener una marco para establecer políticas de administración para dicho CA. Este documento cubre los aspectos mas relevante en cuanto seguridad y confiabilidad del CA. El correcto funcionamiento de un CA no esta dado por la capacidad técnica, sino que por la infraestructura de seguridad que lo rodea. Si existe un aparataje de seguridad aceptable, entonces la confiabilidad del CA sera aceptable. 4

Una vez resuelta las anteriores preguntas se puede hacer un delineamiento verdadero de los alcances de un CA en el departamento de informática. 4.1.

5 Referencias [1] Ralf S. Engelschall. The apache interface to openssl. org/docs/2.8/ssl_faq.html#toc24, [2] Nick Lewis. Internet2 certificate authority for the incommon federation system technical reference, [3] Department of Defense. National industrial security program operating manual. Enero NTC/LATEX 2ε 5

Internet2 certificate authority for the incommon federation system technical reference, 2004.

Documentos relacionados

Resumen de Requisitos Técnicos para incorporación de Organismos a la Plataforma Integrada de Servicios Electrónicos del Estado

Resumen de Requisitos Técnicos para incorporación de Organismos a la Plataforma Integrada de Servicios Electrónicos del Estado Ministerio Secretaría General de la Presidencia Unidad de Modernización y