Pregunta 491 de Temario Específico Técnico/a Superior Informática

Pregunta 476

CASO PRÁCTICO 2 INFRAESTRUCTURA DE CLAVE PÚBLICA EN EL MARCO DE UNA ORGANIZACIÓN SANITARIA DESCRIPCIÓN DEL CASO Para dar soporte a las necesidades de nuestra organización sanitaria, ponemos en marcha una infraestructura de clave pública ( PKI ) cuya pieza central es una autoridad de certificación ( AC ) que emite certificados para:  Personal de la organización sanitaria.  Servidores web: portal del paciente, servidores de imágenes médicas, etc.  Dispositivos IoT: monitores de pacientes, monitores de edificios, dispositivos de captación de imágenes médicas, etc. Dicha AC es totalmente autónoma, partiendo de un certificado auto- firmado. La AC tiene dos modos de emisión de certificados:  Modo 1 ( simplificado ). El titular del certificado acredita su identidad. La AC la verifica y genera una pareja de claves pública-privada para ese titular. Se emite el certificado y se le entrega conjuntamente con la clave privada.  Modo 2 ( avanzado ). El titular del certificado genera por su cuenta una pareja de claves pública-privada. Solicita el certificado acreditando su identidad y entregando la clave pública. La AC verifica la identidad y la validez de la clave, entregando al titular el certificado. Nuestra PKI también incluye un servicio para comprobar online la validez de un certificado. Se describen a continuación tres casos de uso de nuestra PKI, a los cuales corresponden las preguntas de este caso práctico. Nota importante : en todo este caso práctico se entiende que un certificado digital incluye la identidad del titular y la clave pública del mismo. La clave privada correspondiente se puede distribuir conjuntamente con el certificado (como se indica al describir el modo de emisión 1), pero no forma parte del mismo. USO 1: FIRMA DIGITAL La disponibilidad de esta PKI permite implementar procedimientos de firma digital sobre aquellos documentos digitales que lo requieran. Los procesos de firma de documentos se realizan de manera off-line (fuera del navegador web): para firmar un documento en formato PDF tiene que estar en el ordenador de un usuario/a. Dicho usuario/a utiliza programas como “Autofirma” (Gobierno de España) o “Adobe Acrobat” para generar la versión firmada del documento. Suponemos que nuestros/as usuarios/as utilizan ordenadores corporativos con Windows y tienen instalados los elementos criptográficos indicados previamente (que incluyen, pero no están limitados a, certificado del/la usuario/a, clave privada asociada, certificado de la AC). USO 2: SERVIDORES WEB HTTPS Los servidores web de la organización sanitaria han sido configurados, usando certificados emitidos para ello por nuestra AC, para que el acceso a los mismos sea siempre usando HTTPS. Todos los PCs corporativos de la organización sanitaria llevan instalado el certificado de la AC, lo que evita errores de acceso. Sin embargo, la AC no está reconocida por ordenadores no corporativos, externos a la organización sanitaria. En la organización sanitaria, el servicio web de imágenes médicas tiene como dirección (ficticia) https://imagenes.os.org. Debido al gran volumen de accesos y tráfico que tiene, dicho servicio está implementado con 8 servidores físicos, y la distribución de carga entre ellos se realiza usando round-robin DNS. Decidimos cambiar la implementación de este servicio, haciendo que el nombre "imagenes.os.org" corresponda a una única dirección IP, asociada a una máquina en la que está instalado Nginx haciendo de equilibrador de carga ( load balancer ), tal como se muestra en la figura. Detrás del equilibrador de carga están los 8 servidores físicos que implementan realmente el servicio. Implementamos un sistema Nginx SSL Termination : las comunicaciones externas con el servicio de imágenes médicas son HTTPS, las internas (la distribución de la carga a los servidores reales) son HTTP "plano" (véase la figura). Transcripción textual del esquema del caso (página 115): cliente —HTTPS→ Nginx —HTTP→ servidores internos. El texto define ocho servidores en la red privada; el dibujo solo ilustra dos. USO 3: CERTIFICADOS DE DISPOSITIVOS IoT La instalación de certificados en los dispositivos IoT permite la comunicación segura (usando TLS) entre y con dichos dispositivos. Hay que tener en cuenta que los dispositivos IoT pueden estar en lugares no fácilmente accesibles, y ser muy numerosos. USO 4: SERVIDORES PARA ALMACENAMIENTO DE DATOS AVANZADO Los servidores de la Organización sanitaria van a cumplir la funcionalidad de almacenamiento de datos generados por los distintos centros y se están planteando distintas arquitecturas para poder proporcionar distintos servicios a empleado/as y pacientes de los centros sanitarios. Responda a las siguientes preguntas PREGUNTAS: 476-500 Pregunta 476: ¿Qué ventajas tiene el modo de emisión de certificados 1 (simplificado) con respecto al 2 (avanzado)?

Pregunta 477

CASO PRÁCTICO 2 INFRAESTRUCTURA DE CLAVE PÚBLICA EN EL MARCO DE UNA ORGANIZACIÓN SANITARIA DESCRIPCIÓN DEL CASO Para dar soporte a las necesidades de nuestra organización sanitaria, ponemos en marcha una infraestructura de clave pública ( PKI ) cuya pieza central es una autoridad de certificación ( AC ) que emite certificados para:  Personal de la organización sanitaria.  Servidores web: portal del paciente, servidores de imágenes médicas, etc.  Dispositivos IoT: monitores de pacientes, monitores de edificios, dispositivos de captación de imágenes médicas, etc. Dicha AC es totalmente autónoma, partiendo de un certificado auto- firmado. La AC tiene dos modos de emisión de certificados:  Modo 1 ( simplificado ). El titular del certificado acredita su identidad. La AC la verifica y genera una pareja de claves pública-privada para ese titular. Se emite el certificado y se le entrega conjuntamente con la clave privada.  Modo 2 ( avanzado ). El titular del certificado genera por su cuenta una pareja de claves pública-privada. Solicita el certificado acreditando su identidad y entregando la clave pública. La AC verifica la identidad y la validez de la clave, entregando al titular el certificado. Nuestra PKI también incluye un servicio para comprobar online la validez de un certificado. Se describen a continuación tres casos de uso de nuestra PKI, a los cuales corresponden las preguntas de este caso práctico. Nota importante : en todo este caso práctico se entiende que un certificado digital incluye la identidad del titular y la clave pública del mismo. La clave privada correspondiente se puede distribuir conjuntamente con el certificado (como se indica al describir el modo de emisión 1), pero no forma parte del mismo. USO 1: FIRMA DIGITAL La disponibilidad de esta PKI permite implementar procedimientos de firma digital sobre aquellos documentos digitales que lo requieran. Los procesos de firma de documentos se realizan de manera off-line (fuera del navegador web): para firmar un documento en formato PDF tiene que estar en el ordenador de un usuario/a. Dicho usuario/a utiliza programas como “Autofirma” (Gobierno de España) o “Adobe Acrobat” para generar la versión firmada del documento. Suponemos que nuestros/as usuarios/as utilizan ordenadores corporativos con Windows y tienen instalados los elementos criptográficos indicados previamente (que incluyen, pero no están limitados a, certificado del/la usuario/a, clave privada asociada, certificado de la AC). USO 2: SERVIDORES WEB HTTPS Los servidores web de la organización sanitaria han sido configurados, usando certificados emitidos para ello por nuestra AC, para que el acceso a los mismos sea siempre usando HTTPS. Todos los PCs corporativos de la organización sanitaria llevan instalado el certificado de la AC, lo que evita errores de acceso. Sin embargo, la AC no está reconocida por ordenadores no corporativos, externos a la organización sanitaria. En la organización sanitaria, el servicio web de imágenes médicas tiene como dirección (ficticia) https://imagenes.os.org. Debido al gran volumen de accesos y tráfico que tiene, dicho servicio está implementado con 8 servidores físicos, y la distribución de carga entre ellos se realiza usando round-robin DNS. Decidimos cambiar la implementación de este servicio, haciendo que el nombre "imagenes.os.org" corresponda a una única dirección IP, asociada a una máquina en la que está instalado Nginx haciendo de equilibrador de carga ( load balancer ), tal como se muestra en la figura. Detrás del equilibrador de carga están los 8 servidores físicos que implementan realmente el servicio. Implementamos un sistema Nginx SSL Termination : las comunicaciones externas con el servicio de imágenes médicas son HTTPS, las internas (la distribución de la carga a los servidores reales) son HTTP "plano" (véase la figura). Transcripción textual del esquema del caso (página 115): cliente —HTTPS→ Nginx —HTTP→ servidores internos. El texto define ocho servidores en la red privada; el dibujo solo ilustra dos. USO 3: CERTIFICADOS DE DISPOSITIVOS IoT La instalación de certificados en los dispositivos IoT permite la comunicación segura (usando TLS) entre y con dichos dispositivos. Hay que tener en cuenta que los dispositivos IoT pueden estar en lugares no fácilmente accesibles, y ser muy numerosos. USO 4: SERVIDORES PARA ALMACENAMIENTO DE DATOS AVANZADO Los servidores de la Organización sanitaria van a cumplir la funcionalidad de almacenamiento de datos generados por los distintos centros y se están planteando distintas arquitecturas para poder proporcionar distintos servicios a empleado/as y pacientes de los centros sanitarios. Responda a las siguientes preguntas PREGUNTAS: 476-500 Pregunta 477: ¿Qué inconvenientes tiene el modo de emisión de certificados 1 (simplificado), con respecto al 2 (avanzado)?

Pregunta 478

CASO PRÁCTICO 2 INFRAESTRUCTURA DE CLAVE PÚBLICA EN EL MARCO DE UNA ORGANIZACIÓN SANITARIA DESCRIPCIÓN DEL CASO Para dar soporte a las necesidades de nuestra organización sanitaria, ponemos en marcha una infraestructura de clave pública ( PKI ) cuya pieza central es una autoridad de certificación ( AC ) que emite certificados para:  Personal de la organización sanitaria.  Servidores web: portal del paciente, servidores de imágenes médicas, etc.  Dispositivos IoT: monitores de pacientes, monitores de edificios, dispositivos de captación de imágenes médicas, etc. Dicha AC es totalmente autónoma, partiendo de un certificado auto- firmado. La AC tiene dos modos de emisión de certificados:  Modo 1 ( simplificado ). El titular del certificado acredita su identidad. La AC la verifica y genera una pareja de claves pública-privada para ese titular. Se emite el certificado y se le entrega conjuntamente con la clave privada.  Modo 2 ( avanzado ). El titular del certificado genera por su cuenta una pareja de claves pública-privada. Solicita el certificado acreditando su identidad y entregando la clave pública. La AC verifica la identidad y la validez de la clave, entregando al titular el certificado. Nuestra PKI también incluye un servicio para comprobar online la validez de un certificado. Se describen a continuación tres casos de uso de nuestra PKI, a los cuales corresponden las preguntas de este caso práctico. Nota importante : en todo este caso práctico se entiende que un certificado digital incluye la identidad del titular y la clave pública del mismo. La clave privada correspondiente se puede distribuir conjuntamente con el certificado (como se indica al describir el modo de emisión 1), pero no forma parte del mismo. USO 1: FIRMA DIGITAL La disponibilidad de esta PKI permite implementar procedimientos de firma digital sobre aquellos documentos digitales que lo requieran. Los procesos de firma de documentos se realizan de manera off-line (fuera del navegador web): para firmar un documento en formato PDF tiene que estar en el ordenador de un usuario/a. Dicho usuario/a utiliza programas como “Autofirma” (Gobierno de España) o “Adobe Acrobat” para generar la versión firmada del documento. Suponemos que nuestros/as usuarios/as utilizan ordenadores corporativos con Windows y tienen instalados los elementos criptográficos indicados previamente (que incluyen, pero no están limitados a, certificado del/la usuario/a, clave privada asociada, certificado de la AC). USO 2: SERVIDORES WEB HTTPS Los servidores web de la organización sanitaria han sido configurados, usando certificados emitidos para ello por nuestra AC, para que el acceso a los mismos sea siempre usando HTTPS. Todos los PCs corporativos de la organización sanitaria llevan instalado el certificado de la AC, lo que evita errores de acceso. Sin embargo, la AC no está reconocida por ordenadores no corporativos, externos a la organización sanitaria. En la organización sanitaria, el servicio web de imágenes médicas tiene como dirección (ficticia) https://imagenes.os.org. Debido al gran volumen de accesos y tráfico que tiene, dicho servicio está implementado con 8 servidores físicos, y la distribución de carga entre ellos se realiza usando round-robin DNS. Decidimos cambiar la implementación de este servicio, haciendo que el nombre "imagenes.os.org" corresponda a una única dirección IP, asociada a una máquina en la que está instalado Nginx haciendo de equilibrador de carga ( load balancer ), tal como se muestra en la figura. Detrás del equilibrador de carga están los 8 servidores físicos que implementan realmente el servicio. Implementamos un sistema Nginx SSL Termination : las comunicaciones externas con el servicio de imágenes médicas son HTTPS, las internas (la distribución de la carga a los servidores reales) son HTTP "plano" (véase la figura). Transcripción textual del esquema del caso (página 115): cliente —HTTPS→ Nginx —HTTP→ servidores internos. El texto define ocho servidores en la red privada; el dibujo solo ilustra dos. USO 3: CERTIFICADOS DE DISPOSITIVOS IoT La instalación de certificados en los dispositivos IoT permite la comunicación segura (usando TLS) entre y con dichos dispositivos. Hay que tener en cuenta que los dispositivos IoT pueden estar en lugares no fácilmente accesibles, y ser muy numerosos. USO 4: SERVIDORES PARA ALMACENAMIENTO DE DATOS AVANZADO Los servidores de la Organización sanitaria van a cumplir la funcionalidad de almacenamiento de datos generados por los distintos centros y se están planteando distintas arquitecturas para poder proporcionar distintos servicios a empleado/as y pacientes de los centros sanitarios. Responda a las siguientes preguntas PREGUNTAS: 476-500 Pregunta 478: ¿Cuál de estos protocolos permite la verificación online de la validez de un certificado digital ante la entidad emisora?

Pregunta 479

CASO PRÁCTICO 2 INFRAESTRUCTURA DE CLAVE PÚBLICA EN EL MARCO DE UNA ORGANIZACIÓN SANITARIA DESCRIPCIÓN DEL CASO Para dar soporte a las necesidades de nuestra organización sanitaria, ponemos en marcha una infraestructura de clave pública ( PKI ) cuya pieza central es una autoridad de certificación ( AC ) que emite certificados para:  Personal de la organización sanitaria.  Servidores web: portal del paciente, servidores de imágenes médicas, etc.  Dispositivos IoT: monitores de pacientes, monitores de edificios, dispositivos de captación de imágenes médicas, etc. Dicha AC es totalmente autónoma, partiendo de un certificado auto- firmado. La AC tiene dos modos de emisión de certificados:  Modo 1 ( simplificado ). El titular del certificado acredita su identidad. La AC la verifica y genera una pareja de claves pública-privada para ese titular. Se emite el certificado y se le entrega conjuntamente con la clave privada.  Modo 2 ( avanzado ). El titular del certificado genera por su cuenta una pareja de claves pública-privada. Solicita el certificado acreditando su identidad y entregando la clave pública. La AC verifica la identidad y la validez de la clave, entregando al titular el certificado. Nuestra PKI también incluye un servicio para comprobar online la validez de un certificado. Se describen a continuación tres casos de uso de nuestra PKI, a los cuales corresponden las preguntas de este caso práctico. Nota importante : en todo este caso práctico se entiende que un certificado digital incluye la identidad del titular y la clave pública del mismo. La clave privada correspondiente se puede distribuir conjuntamente con el certificado (como se indica al describir el modo de emisión 1), pero no forma parte del mismo. USO 1: FIRMA DIGITAL La disponibilidad de esta PKI permite implementar procedimientos de firma digital sobre aquellos documentos digitales que lo requieran. Los procesos de firma de documentos se realizan de manera off-line (fuera del navegador web): para firmar un documento en formato PDF tiene que estar en el ordenador de un usuario/a. Dicho usuario/a utiliza programas como “Autofirma” (Gobierno de España) o “Adobe Acrobat” para generar la versión firmada del documento. Suponemos que nuestros/as usuarios/as utilizan ordenadores corporativos con Windows y tienen instalados los elementos criptográficos indicados previamente (que incluyen, pero no están limitados a, certificado del/la usuario/a, clave privada asociada, certificado de la AC). USO 2: SERVIDORES WEB HTTPS Los servidores web de la organización sanitaria han sido configurados, usando certificados emitidos para ello por nuestra AC, para que el acceso a los mismos sea siempre usando HTTPS. Todos los PCs corporativos de la organización sanitaria llevan instalado el certificado de la AC, lo que evita errores de acceso. Sin embargo, la AC no está reconocida por ordenadores no corporativos, externos a la organización sanitaria. En la organización sanitaria, el servicio web de imágenes médicas tiene como dirección (ficticia) https://imagenes.os.org. Debido al gran volumen de accesos y tráfico que tiene, dicho servicio está implementado con 8 servidores físicos, y la distribución de carga entre ellos se realiza usando round-robin DNS. Decidimos cambiar la implementación de este servicio, haciendo que el nombre "imagenes.os.org" corresponda a una única dirección IP, asociada a una máquina en la que está instalado Nginx haciendo de equilibrador de carga ( load balancer ), tal como se muestra en la figura. Detrás del equilibrador de carga están los 8 servidores físicos que implementan realmente el servicio. Implementamos un sistema Nginx SSL Termination : las comunicaciones externas con el servicio de imágenes médicas son HTTPS, las internas (la distribución de la carga a los servidores reales) son HTTP "plano" (véase la figura). Transcripción textual del esquema del caso (página 115): cliente —HTTPS→ Nginx —HTTP→ servidores internos. El texto define ocho servidores en la red privada; el dibujo solo ilustra dos. USO 3: CERTIFICADOS DE DISPOSITIVOS IoT La instalación de certificados en los dispositivos IoT permite la comunicación segura (usando TLS) entre y con dichos dispositivos. Hay que tener en cuenta que los dispositivos IoT pueden estar en lugares no fácilmente accesibles, y ser muy numerosos. USO 4: SERVIDORES PARA ALMACENAMIENTO DE DATOS AVANZADO Los servidores de la Organización sanitaria van a cumplir la funcionalidad de almacenamiento de datos generados por los distintos centros y se están planteando distintas arquitecturas para poder proporcionar distintos servicios a empleado/as y pacientes de los centros sanitarios. Responda a las siguientes preguntas PREGUNTAS: 476-500 Pregunta 479: En el proceso de firma digital de un documento PDF mediante herramientas como Autofirma o Adobe Acrobat, ¿cuál de las siguientes afirmaciones es CORRECTA?