Solución simulacro³n Simulacro.pdf · Solución simulacro Primeros pasos para resolver el...
Transcript of Solución simulacro³n Simulacro.pdf · Solución simulacro Primeros pasos para resolver el...
Solución simulacro Primeros pasos para resolver el ejercicio Es interesante dar un nombre al sistema. Es conveniente identificar:
● Punto de vista del negocio ○ Cuál es el principal objetivo del sistema ○ Quiénes son los “stakeholders” ○ Cuáles son las principales dificultades
● Punto de vista de la solución técnica ○ Qué tipo de sistema nos están pidiendo ○ Actores, interacciones y módulos del sistema ○ Diagrama de contexto. ○ Diagrama de módulos (opcional).
Se recomienda repartir el tiempo para resolver las cuestiones. En este caso 5 horas, dado que el examen en 2014 será de 4 horas máximo, se recomienda hacerlo en cuatro horas hasta la pregunta 12 inclusive, y una hora más para las cuestiones adicionales. Propuesta de gestión del tiempo:
● Una hora para interpretación del enunciado y primeros pasos. ● Repartir aproximadamente el tiempo restante (unos 220 minutos) entre el total
de preguntas (y 20 min para repaso). ● 12 cuestiones y 4 adicionales (en principio menos tiempo en estas últimas) ● Unos 1015 min por cuestión y 10 para las adicionales, teniendo en cuenta
que: Alguna llevará más tiempo (ej. planificación, arquitectura física, pregunta con varios apartados...).
Se puede reservar más tiempo para aquellas que se nos den mejor (sin descompensar el examen!). No es necesario contestar todos los apartados ni condición necesaria para aprobar, pero es deseable (por lo menos indicar la respuesta). Si es recomendable tener presente el reloj y los tiempos para cada apartado a lo largo del examen.
1
1. Resumen ejecutivo del proyecto, que contemple los objetivos, resultados, características y la magnitud de su impacto económico.
El resumen ejecutivo, la nota al Ministro, etc… son preguntas que en los últimos
examenes han centrado gran parte de la atención del tribunal. Si bien el enfoque que cada uno le de es muy personal, a continuación os indicamos
unas pautas a tener en cuenta que os serán de utilidad para afrontar este tipo de preguntas:
● Lo primero es identificar el objetivo perseguido por el texto solicitado. En la
mayoría de los casos el objetivo será conocer el sistema, sus ventajas y el valor que aporta el mismo.
○ Este primer paso condicional completamente el enfoque que se le de al texto.
● A continuación se debe analizar el tipo de destinatarios finales del texto. En la mayoría de los casos, se tratará de un interlocutor no técnico.
○ Esto exige orientar el texto hacia lo funcional y dejar fuera los detalles técnicos.
● A continuación, una vez conocido el objetivo e identificados los interlocutores destinatarios del texto, es importante seleccionar los aspectos del sistema a incluir, es decir, los más importantes o que aportan más valor para el contexto y los interlocutores indicados por el enunciado.
○ Resulta especialmente importante resaltar los puntos estratégicos del proyecto, encuadrándolo si es posible en el contexto que se describa en el enunciado.
● Por último, es importante tratar de contextualizar el texto que se redacte de forma que se resalten los aspectos del sistema seleccionados como relevantes.
● Redacción: ○ El estilo y la redacción son fundamentales en este tipo de preguntas. ○ En la mayoría de los casos se trata de un texto “formal”, por lo que se
ha de enfocar el texto de una forma impersonal Ej: “se va a realizar” en lugar de “vamos a realizar”.
● El tono empleado ha de ser neutro, resaltando las virtudes del sistema sin caer en la imparcialidad.
● Por último resulta esencial que la extensión del texto sea razonable. 2. Diseño de un diagrama de clases que muestre el dominio de la aplicación.
2
Es importante tener en cuenta que hay elementos que suelen repetirse en los casos de administración electrónica, como puede ser la clase expediente, la clase documento o la clase registro, si bien es cierto que pueden existir otras fórmulas. Por otro lado, el hecho de poner de manifiesto clases que modelen la realidad del problema y que expresen que se ha comprendido el peso de los diferentes elementos del enunciado, implica demostrar que se ha comprendido mejor el ejercicio.
3
Es esencial ser proporcionado en la forma del diagrama. Un exceso de atributos (por ejemplo, los presentes en el anterior diagrama quizá son demasiados) en las clases puede aportar muy poco valor para el tiempo que se pierde. Por otro lado, si lo que piden en el enunciado es establecer una gran cantidad de atributos, sí que habría que reflejarlo. Conviene indicar las cardinalidades, siempre que sea posible. En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia. Se anotan en cada extremo de la relación y éstas pueden ser: o uno o muchos: 1..* (1..n) o 0 o muchos: 0..* (0..n) o número fijo: m (m denota el número). Tener en cuenta que para las cardinalidades no siempre hay una solución única: a veces es muy claro que un operador puede consultar varios expedientes y que varios expedientes pueden ser consultados por varios operadores. Sin embargo, un expediente podría ser consultado sólo por un funcionario o no (se le da permiso a otros funcionarios a entrar), según cómo ideemos el sistema.
3. Diseño de los principales casos de uso tomando en cuenta la descripción
ofrecida.
Es importante poner de manifiesto que estos casos de uso son especialmente extensos y que ocuparían demasiado tiempo en un examen. Aún así, son un excelente ejercicio para practicar. Se puede hacer un diagrama de casos de uso en función de cada trámite, por sencillez del diagrama. O bien agrupar todos, para tardar menos, utilizando algunos casos de uso auxiliares que permitan evitar el cruce de líneas. Es importante insistir en que lo normal en un ejercicio es encontrar algo más acotado, bien por trámite o bien uno global pero algo más limitado. Aún así, podrían llegar a ser complicados (de hecho en la convocatoria 2011 lo fue) por lo que no es bueno subestimar este diagrama y de ahí la importancia de realizarlo, para practicar al máximo. Los diagramas que se han adjuntado como imágenes fuera de este documento son un buen ensayo para llegar al diagrama grande que se sitúa justo a continuación.
PUNTO DE VISTA SOLICITANTE:
4
5
PUNTO VISTA OPERADOR
PUNTO VISTA JPIT
Se debe tener en cuenta que faltaría el caso de uso relativo al instalador, que sólo puede remitir el protocolo y el boletín. Se trata de un caso de uso sencillo, un subconjunto de todo lo que podría hacer el proyectista, por lo que no se ha insistido en su representación.
6
4. Diseñe el diagrama de secuencia desde la entrega de boletín y protocolo hasta su posible descarga ya tramitados.
Diagrama de secuencia para la identificación:
Este diagrama se ha desglosado del diagrama que se pedía por motivos de claridad, si bien es cierto que es más lógico ponerlo juntos, en un sólo diagrama. En cualquier caso, se trata de algo importante a reflejar en el diagrama, puesto que sin este paso, no se podría realizar la segunda parte.
Diagrama de secuencia desde la entrega de boletín y protocolo hasta su posible descarga ya tramitados.
7
5. Arquitectura lógica:
a. Diseñe un diagrama de arquitectura lógica b. Describa los diferentes módulos y las razones concretas de su
inclusión, así las posibilidades que existen de reutilización
8
● Capa de presentación: Interfaz web que permite el acceso a los usuarios de
la aplicación mostrando una interfaz distinta en función de la autenticación del mismo (autenticación como Proyectista/Promotor, como Operador o como Funcionario).
● Capa de lógica de negocio: Cuenta con los siguientes módulos:
○ Tramitación de ICTs: ■ Módulo que alberga la lógica de negocio asociada a todos los
trámites relacionados con la presentación del proyecto de ICT realizados por parte del proyectista.
○ Comunicación Colegios:
■ Módulo encargado de la comunicación con los Colegios Oficiales de Telecomunicación para llevar a cabo la validación y descarga de los proyectos presentados ante el Minetur,
9
basándose para ello en el código de verificación. Asimismo, se encarga del intercambio de documentación con los mismos en caso de que proceda.
○ Consulta Operadores:
■ Módulo encargado de la comunicación con los Operadores para el intercambio de información en relación con la ubicación de la arqueta. Permitirá el intercambio de información necesaria para la identificación de la finca sobre la que se tramita la ICT así como la asociación al expediente correspondiente de la información que cada uno de los operadores proporcione.
○ Gestión expedientes ICTS:
■ Módulo encargado de la gestión del ciclo de vida del expediente en el “backoffice”, por parte del personal funcionario de las JPIT. Para cada uno de los trámites realizados por el proyectista/promotor u operador, se desencadenará una serie de revisiones, notificación, generación y firma de oficios (por parte del responsable de la JPIT a través del portafirma corporativo, etc.).
○ Administración:
■ Módulo transversal encargado de tareas como por ejemplo la gestión de usuarios o la configuración de la aplicación, todo ello de acuerdo con las directrices de seguridad aplicables en el Ministerio.
○ Tramitador administrativo:
■ Módulo encargado de la tramitación asociada a todos los trámites del procedimiento administrativo que respalda jurídicamente a la aplicación (procedimiento descrito en el enunciado).
○ Acceso a Datos: Permite el acceso a la capa de datos, tal y como se
describe en el siguiente punto.
○ Acceso a Servicios: Permite el acceso a la capa de servicios, tal y como se describe en el siguiente punto.
● Capa de acceso a datos:
○ Datos: Tal y como se muestra en la arquitectura física, se trata de una capa protegida para evitar su acceso indebido. Dentro de esta capa se incluyen tanto la Base de Datos (con expedientes, documentos, etc…)
10
como el gestor documental (repositorio común) para la gestión del ciclo de vida de los documentos involucrados.
○ Servicios: Engloba tanto servicios comunes propios del Ministerio (por ejemplo el Registro Electrónico) como servicios horizontales a toda la administarción (en este caso, @Firma y la Plataforma de Intermediación) o servicios ofrecidos por otros organismos a través de Servicios Web, como es por ejemplo el caso de los servicios ofrecidos por el COIT.
En cuanto a la reutilización, cabe destacar que se ha apostado por el uso del máximo número de servicios horizontales, tanto dentro del Ministerio como en el ámbito de la AGE. En cuanto a los módulos, serían fácilmente reutilizables por otras áreas de desarrollo los módulos de administración y el módulo de tramitación de expedientes, debido a su carácter común en gran parte de proyectos de eadministración.
6. Indique qué Normas Técnicas de Interoperabilidad deberían considerarse para
llevar a cabo la presente aplicación.
● Norma Técnica de Interoperabilidad de Catálogo de estándares: ○ Justificación: La Norma Técnica de Interoperabilidad de Catálogo de
estándares tiene por objeto establecer un conjunto de estándares que satisfagan lo previsto en el artículo 11 del Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.
○ Es como la base para definir los estándares que se han de usar en todo ello.
■ Esencial para que el sistema sea interoperable y reutilizable. ○ En el caso propuesto, esta NTI es importante en cuanto a que se ha de
intercambiar información con otras entidades (JPIT, Colegios de Ingenieros, AEAT…).
● Norma Técnica de Interoperabilidad de Documento Electrónico: ○ La Norma Técnica de Interoperabilidad de Documento electrónico tiene
por objeto establecer los componentes del documento electrónico, contenido, en su caso, firma electrónica y metadatos, así como la estructura y formato para su intercambio.
○ Fundamental para estructurar todos los documentos electrónicos que componen el expediente.
11
○ En el caso propuesto, existe gran cantidad de documentos participantes del procedimiento por lo que se hace importante homogenizar.
● Norma Técnica de Interoperabilidad de Expediente Electrónico: ○ La Norma Técnica de Interoperabilidad de Expediente electrónico tiene
por objeto establecer la estructura y el formato del expediente electrónico, así como las especificaciones de los servicios de remisión y puesta a disposición.
○ Esencial para la definición del Expediente del sistema. ○ En el caso propuesto, la tramitación gira entorno a un expediente
administrativo que recoge la información correspondiente a esa ICT. También es vital de cara al intercambio con otros organismos.
● Norma Técnica de Interoperabilidad de Política de Firma y de Certificados de
la Administración: ○ La Norma Técnica de Interoperabilidad de Política de firma electrónica
y de certificados de la Administración tiene por objeto establecer el conjunto de criterios comunes asumidos por la Administración pública en relación con la autenticación y el reconocimiento mutuo de firmas electrónicas basadas en certificados y que, como tales, serán desarrollados y consolidados a través de las políticas de firma electrónica basada en certificados.
○ El objetivo final de esta NTI es facilitar el uso de firmas electrónicas seguras e interoperables entre las distintas organizaciones de la Administración pública.
● Norma Técnica de Interoperabilidad de Política de Gestión de Documentos
Electrónicos: ○ La Norma Técnica de Interoperabilidad de Política de gestión de
documentos electrónicos tiene por objeto establecer las directrices para la definición de políticas de gestión de documentos electrónicos.
○ Se asocia al archivado pero debería aplicar a todo el ciclo de gestión del documento también “en vida”. Habría que acogerse a lo que tiene la organización ya establecido
● Norma Técnica de Interoperabilidad de Reutilización de recursos de la Información.
○ La Norma técnica de interoperabilidad de reutilización de recursos de información tiene por objeto establecer el conjunto de pautas básicas para la reutilización de documentos y recursos de
12
información elaborados o custodiados por el sector público a los que se refiere el artículo 3 de la Ley 37/2007.
○ Dado que la selección de la información debe basarse en su importancia en relación con su fin social y económico, datos relativos a la implantación de ICTs, el tipo de vivienda en que se realizan, tamaños de empresas en este mercado o de implicación de operadores en el proceso son absolutamente prioritarios. Esto se debe a que el modelo de ICTs ha sido pionero en el mundo y está en proceso de exportación, por lo que aportar datos que beneficien a su expansión son muy positivos para potenciar la fuerza de las empresas españolas en el mercado internacional.
○ El esquema de URI, los protocolos de seguridad y los formatos implicados, respetarán lo establecido en la NTI.
Aspectos interesantes
¿Aplicación de Norma Técnica de Interoperabilidad de Protocolos de Intermediación de Datos a los Colegios?: No le aplica necesariamente, al ser corporaciones de Derecho público, pero que se rigen por Derecho privado, aunque en aquellas cosas en las que ejercen facultades de Derecho administrativo sobre sus miembros, también les aplica el administrativo. En este caso, su labor no es administrativa, sino de entidad de verificación, que bien podría ser una empresa privada, por lo que no aplicaría.
7. Diseñe gráficamente un esquema XSD de expediente electrónico, que cumpla
con los requisitos de lo establecido en la NTI de expediente electrónico. Diseñe gráficamente el esquema XSD de los metadatos del mismo, indicando aquellos que se consideren más importantes. Indique qué tipos de firmas utilizaría para cada uno de los siguiente documentos, exponiendo los motivos:
a. Proyecto y modificaciones b. Autorizaciones entre proyectista y promotor c. Boletines, proyectos, certificados de fin de obras, protocolos y
certificados de la jefatura provincial, todos ellos firmados por el jefe provincial.
Para empezar, conviene recordar qué es un expediente electrónico:
13
A la hora de pensar en un expediente, conviene tener en cuenta algunos
elementos: Los documentos van entrando a nuestro sistema desde que se inicia el
expediente hasta etapas posteriores. Cada documento cumple con la NTI de Documento electrónico y por
tanto se ve acompañado de sus metadatos y su firma. Cada documento queda guardado, de manera que dependiendo su
naturaleza, puede quedar guardado bajo un sistema u otro. Por ejemplo, un pdf de un proyecto podría quedar guardado en un gestor documental.
El expediente no es más que una agrupación lógica de estos
documentos y sus metadatos. Para crear esa agrupación lógica, se crea un índice y se añaden unos metadatos al expediente (independientes de cada documento individual), y además se firma (el expediente).
La gestión de los metadatos puede ser enfocada de diferentes maneras,
como por ejemplo, mediante el propio gestor documental.
Para organizar esta agrupación, la NTI ofrece un sistema mediante el que establecer un índice y unos metadatos estandarizados, expresados en un esquema XSD genérico. Los metadatos identifican al expediente y asocian a diferentes elementos del mismo (autor, promotor, descripción, etc.). El índice electrónico “constituye un objeto digital que contiene la identificación sustancial de los documentos electrónicos que componen el expediente debidamente ordenada para reflejar la disposición de los documentos, así como otros datos con el fin de preservar la integridad y permitir la recuperación del mismo, en los términos del artículo 32.2 de la citada Ley 11/2007, de 22 de junio”
14
Esos metadatos mínimos obligatorios y ese índice que identifica los documentos (guardados en el repositorio en cuestión, para su posterior recuperación e intercambio) son los que se organizan en el XSD. Gracias a ello, se identificará bien al expediente, se podrá intercambiar de una forma ordenada y se garantizará su integridad y su recuperación. Para el intercambio, se envía primero el índice. Posteriormente, se enviarán los documentos que lo componen, uno a uno, y siguiendo la distribución reflejada en el contenido del Índice.
En cuanto a los esquemas que indica la NTI de expediente electrónico para su intercambio, se puede consultar en el anexo I de la guía de aplicación:
http://www.mpt.gob.es/dms/es/publicaciones/centro_de_publicaciones_de_la_sgt/GUIAS_NTI/text_es_files/Guia_expedienteelectronicoINTERNET.pdf
Se ve una serie de esquemas genéricos. Hay que tener en cuenta algunos hechos: Los metadatos mínimos obligatorios genéricos son siempre los mismos para todos los expedientes. La visualización del Índice es opcional y sirve para dar una visualización alternativa de la información del expediente, como puede ser el índice o el contenido completo de los documentos que lo conforman. Por ello, se centra el interés en dos puntos: Metadatos complementarios Índice Comenzamos con los primeros:
15
Notar que el solicitante (interesado) es un metadato mínimo obligatorio, por lo que no figura aquí. Por último, quedaría el índice. Se propone a continuación una solución, si bien existen múltiples soluciones alternativas a esto. En este caso se ha optado por mostrar únicamente dentro del índice documentos del caso práctico, pero pueden existir otros expedientes dentro del primero, así como otras carpetas, tal como indica la NTI.
16
b) En cuanto al FORMATO de firma para los DOCUMENTOS (no el índice electrónico, eso NOes lo que pide el enunciado), hay que tener en cuenta:
● Muchos documentos ya se introducen en el sistema firmados con PAdES (admitido por la NTI). Pero para garantizar 100% de intervenciones firmadas, cada solicitud y el conjunto de sus datos adjuntos es firmada con XAdES (independientemente de la firma de los proyectos antes comentada). Téngase en cuenta que así, también se firma la solicitud y otros documentos que pudieran no estar firmados.
● Se necesita garantía de firma por 15 años. ● No requiere altos requerimientos de seguridad (no nivel alto ENS). ● Se trabaja con @firma y las AC parecen relativamente estables.
○ Se puede añadir referencias a datos de verificación ○ No hace falta, en principio, por estas razones incluir los datos de
verificación de la firma (puede realizarse a través de respuestas OCSP o CRL). Esto es algo que hay que tener en cuenta ya que la NTI de política de firma hace énfasis en ser proporcionados (ver epígrafe 7.3.128 de la guía de aplicación de la NTI de política de firma).
● Esto coincide con XAdESC
17
Este tipo de firma coincide con XAdESC y daría cobertura a las medidas de firma electrónica para nivel medio del ENS (en lo relativo a Integridad y Autenticidad), lo que está por encima de las necesidades de este sistema. Esto, por otra parte, exigiría el sellado de tiempo sobre la firma, lo cual habría que detallar. http://zonatic.usatudni.es/es/aprendizaje/aprendesobreeldnie/57aspectostecnicos/208sistemasactualesdeautenticacionyfirma.html Pag 43 http://www.boe.es/boe/dias/2010/01/29/pdfs/BOEA20101330.pdf (ENS) En cuanto al TIPO de firma, la NTI admite para XAdES, dos maneras:
Cualquiera puede llegar a ser válida, si se justifica la razón para su elección, si bien XAdES internally detached es aconsejable por ser fácil de extraer del conjunto de los documentos en un expediente. Es importante insistir en no confundir con el campo firmas del expediente electrónico: el enunciado pide qué firmas se aplicarían a una serie de documentos, (a todos la misma), pero no la firma del índice del expediente.
8. Explique el mecanismo y tecnología que utilizaría el sistema para realizar el
posible trámite de verificación con el Colegio Oficial de Ingenieros de Telecomunicación, teniendo presente los datos adicionales proporcionados en el enunciado.
El proceso que siguen ahora es:
1 En el momento de adjuntar el proyecto, la aplicación utiliza el código de verificación para consultar si pertenece a un proyecto real, a través de un servicio web publicado en el colegio. Esta respuesta es síncrona y se realiza en el mismo momento del trámite: el colegio recibe un código de verificación y consulta si disponen de un proyecto registrado para el mismo.
2a En caso de resultado negativo en la etapa 1, el sistema rechaza el trámite y el solicitante no puede solicitar la ICT.
18
2b En caso de resultado positivo en la etapa 1, el sistema crea una cola con los proyectos que es necesario comprobar, procedentes de diversos expedientes, y automáticamente se lanza un proceso nocturno que realiza las descargas pendientes y almacena cada proyecto en su correspondiente expediente. Dichos proceso sigue los siguientes pasos:
1. Consulta otros dos métodos del servicio web del Colegio, para cada uno de los proyectos “en cola”:
a. El primero verifica que dicho código realmente es válido, a modo de confirmación.
b. El segundo obtiene la ruta donde se encuentra el fichero en el servidor FTP de cada colegio.
2. Una vez que se tiene el dato anterior, el MINETUR conecta con los servidores
FTP de cada Colegio (a través de un usuario con permisos) y directamente descarga los ficheros cuya ruta obtuvo en el paso anterior.
3. En caso de que exista algún problema, por ejemplo que la memoria realmente no exista (aunque el resultado del paso 2 fuese positivo) o que se produzca un problema en la descarga, se genera un log de errores y al final del proceso se remite un correo al colegio correspondiente para que solvente la incidencia detectada. El proyecto en cuestión se mantiene en la cola y al día siguiente se vuelve a intentar descargar.
19
9. Describa cómo implementaría la funcionalidad de consulta sobre la ubicación de la arqueta descrita en la Etapa 2. Esta consulta, iniciada por el proyectista e intermediada por MINETUR, deberá ser trasladada a todos los operadores que den servicio en la zona, quienes deberán dar respuesta en el plazo de un mes.
Alguna indicación sobre la solución real:
1. En el momento en que el proyectista registra la localización de la arqueta en el expediente, a través de una solicitud, se inicia el procedimiento de consulta.
2. Para localizar a los operadores a los que remitir la consulta (los que operan en
la zona), se utilizará una funcionalidad de localización geográfica, a partir de las coordenadas que introduce el proyectista (o directamente del municipio). Cada operador está obligado a indicar y mantener actualizados los municipios en los que opera.
3. En el sistema real, han aprovechado la funcionalidad de una aplicación existente (el propio Registro electrónico) para el intercambio de información entre el proyectista y los operadores. “El Registro Electrónico es un sistema externo al desarrollo encargado de crear expedientes y de realizar entradas y salidas del Registro Electrónico sobre ellos, accesible mediante servicio web”.
4. Así, el envío del proyectista desencadena la creación de un expediente en el Registro con una entrada (que es precisamente la ubicación de la arqueta) y N salidas iguales a dicha entrada, una para cada operador, que constituye la consulta en sí.
5. Los operadores disponen de un plazo de 30 días para contestar, y para ello
accederían a su interfaz (ver casos de uso) y allí podrían responder a la consulta realizada indicando la conformidad o nueva ubicación, las tecnologías con las que llegan, etc.
6. Una vez finaliza el plazo (o bien cuando hayan respondido todos los
operadores), se crean M entradas en el expediente descrito en el punto 4, una para cada operador, y una salida que agrupa estas respuestas hacia el proyectista, que recibe por tanto las distintas ubicaciones de la arqueta aconsejadas por los operadores (también por email).
El siguiente diagrama refleja los principales elementos descritos:
20
Como se puede apreciar, el operador también puede gestionar los usuarios y las
provincias/municipios (localizaciones) en las que está presente.
10. Indique cómo aplica el Esquema Nacional de Seguridad realizando el proceso de categorización del sistema y seleccionando, al menos, tres medidas de seguridad de las previstas en el ANEXO II del ENS.
Siguiendo el procedimiento de categorización del ANEXO I, se obtiene la siguiente categorización:
* Se categoriza la disponibilidad como MEDIA para que el ejemplo sea más ilustrativo. Debería ser B, ya que en el enunciado no se indica que la tramitación tenga que ser exclusivamente por medios electrónicos. Además, tampoco se indican plazos de finalización de presentación de documentación que puedan hacer más crítico el sistema a nivel de disponibilidad.
21
Para la selección de medidas es conveniente memorizar varias medidas del Anexo II del ENS que sean granulares según el nivel. Des esta forma la solución será más particularizada a los niveles definidos en el proceso de categorización.
Elegimos una que aplica por la dimensión DISPONIBILIDAD (D) = M.
5.3.4 Medios alternativos [mp.eq.9].
Se garantizará la existencia y disponibilidad de medios alternativos de tratamiento de la información para el caso de que fallen los medios habituales. Estos medios alternativos estarán sujetos a las mismas garantías de protección.
Igualmente, se establecerá un tiempo máximo para que los equipos alternativos entren en funcionamiento.
Elegimos una que aplica por la categoría MEDIA
4.1.1 Análisis de riesgos [op.pl.1].
Categoría MEDIA Se deberá realizar un análisis semiformal, usando un lenguaje específico, con un catálogo básico de amenazas y una semántica definida. Es decir, una presentación con tablas que describa los siguientes aspectos:
a) Identifique y valore cualitativamente los activos más valiosos del sistema.
b) Identifique y cuantifique las amenazas más probables.
c) Identifique y valore las salvaguardas que protegen de dichas amenazas.
d) Identifique y valore el riesgo residual.
Elegimos una que aplica por dimensión I C A T = B.
4.2.5 Mecanismo de autenticación [op.acc.5].
22
Nivel BAJO
a) Se admitirá el uso de cualquier mecanismo de autenticación: claves concertadas, o dispositivos físicos (en expresión inglesa »tokens») o componentes lógicos tales como certificados software u otros equivalentes o mecanismos biométricos.
b) En el caso de usar contraseñas se aplicarán reglas básicas de calidad de las mismas.
c) Se atenderá a la seguridad de los autenticadores de forma que:
1.º Los autenticadores se activarán una vez estén bajo el control efectivo del usuario.
2.º Los autenticadores estarán bajo el control exclusivo del usuario.
3.º El usuario reconocerá que los ha recibido y que conoce y acepta las obligaciones que implica su tenencia, en particular el deber de custodia diligente, protección de su confidencialidad e información inmediata en caso de pérdida.
4.º Los autenticadores se cambiarán con una periodicidad marcada por la política de la organización, atendiendo a la categoría del sistema al que se accede.
5.º Los autenticadores se retirarán y serán deshabilitados cuando la entidad (persona, equipo o proceso) que autentican termina su relación con el sistema.
Independientemente de la categorización de los sistemas, la mayoría de los Ministerios y algunos organismos autónomos disponen de un sistema de detección de intrusión (4.6.1 Detección de intrusión [op.mon.1]) que se corresponde con la sonda del CERT del Centro Criptológico Nacional (Se muestra en el diagrama del siguiente apartado).
Además de las medidas seleccionadas y, teniendo en cuenta la debilidad del
23
protocolo FTP ante ataques de fuerza bruta, es conveniente reforzar el sistema con medidas de seguridad adicionales. Se propone:
● Acceso por FTP seguro SFTP mediante certificados de cliente desplegados en MINETUR para conectar a cada uno de los colegios. Esta medida garantiza la confidencialidad gracias al cifrado y evita que se puedan conseguir usuarios y contraseñas.
● Conectividad VPN site to site con los colegios que dispongan de infraestructura con capacidad de establecer el túnel entre los cortafuegos. En este caso el servidor de FTP no estaría accesible para cualquier usuario desde Internet.
24
11. Infraestructura física: a. Diseñe un diagrama de infraestructura física que de soporte al sistema que se pretende implementar.
● Se identifican los agentes que acceden al sistema. ● Se separan los entornos por tipo de arquitectura y perímetro de interconexión,
teniendo en cuenta las redes privadas o públicas por las que va el tráfico.
25
● La alta disponibilidad se puede garantizar por diversos mecanismos, como balanceadores, virtualización o clúster (en los servidores de bases de datos o de ficheros).
Integración con infraestructura existente Si el enunciado no indica que es un Ministerio/Organismo de nueva creación y, en caso de pedir presupuesto, sería conveniente suponer que se dispone de infraestructura básica de red y comunicaciones (líneas, routers, switches, seguridad perimetral, etc). Se puede presuponer la existencia de un Gestor de Bases de Datos, presupuestando así sólo la parte de servidores de aplicaciones/Web adicionales. Si fuera un organismo nuevo y los plazos de implantación son cortos, se pueden plantear modalidades de infraestructura como servicio, o plataforma como servicio.
b. Con ayuda de las tablas de los anexos, dimensione las líneas de comunicación para la comunicación con los Colegios de Ingenieros de Telecomunicación, teniendo en cuenta que se prevé que un 70% de los expedientes vean adjuntado el proyecto por este medio: Tomando la gráfica 1, se puede observar que de 2014 hacia adelante, el número de expedientes anuales queda estabilizado en 2000 unidades, aproximadamente. De estos, 70% se entrega por la vía de Colegio Oficial, lo que significa un total de 1400 expedientes anuales. 1400/12≈120 expedientes mensuales. Del extracto al subdirector, se deduce que Junio es el mes peor, ya que necesitan contratar a más gente para tramitarlos (no confundir con contratación de personal para desarrollar el sistema), con un número de expedientes que puede triplicar a lo que sería la media, es decir, 360 expedientes. Se divide por el número de días. Podrían ser 30 días al mes, pues se trata de administración electrónica 24x7, pero es cierto que el grueso de los expedientes suelen entrar en días laborables, lo que añade asimismo un cierto margen de seguridad al cálculo. 360 expedientes/20 días laborables = 18 expedientes diarios. El caso peor es de unos 100 MB (a la vista de las capturas de pantalla del anexo) y esto ya supone un margen de seguridad más que suficiente en caso de picos diarios en los que haya más expedientes que la media, pues no todos los expedientes van a ser de 100 MB. Se toman 10 horas diarias para transferencia de archivos.
26
, Mbps10 horas∙3600 segundos18 expedienets∙100MB∙8bit/Byte = 0 4
Con un ancho de banda 512 kbps existe una capacidad más que suficiente para ofrecer estos servicios. Las líneas de comunicaciones englobadas dentro de un Plan Director de Comunicaciones licitado por Procedimiento Abierto (concurso). En las comunicaciones internas de los organismos se suele utilizar tecnología MPLS del operador, mientras que en la salida a Internet nos podríamos encontrar líneas dedicadas de fibra hasta el operador (100 Mbps, 1 Gbps), dependiendo del ancho de banda requerido. Es razonable tener dos y, si es posible, de operadores distintos. c. Teniendo en cuenta el tipo de documentos y el volumen de información que maneja el sistema, describa el tipo de sistema de almacenamiento que se debería utilizar: Volumen de la información dimensionado a partir de la gráfica 1 del Anexo:
A. A futuro: 15 años x 1400 ICTs/año x 100MB/ICT = 2,1 TB B. ¿A pasado? 83100 ICTs x 100MB/ICT = 8,3 TB. Se dimensiona el volumen de
la información pasada por si fuera necesario digitalizarla. Se toman los mismos datos de 100 MB/ICT, suponiendo que el proceso de digitalización genera ese volumen.
En el sistema se almacena información documental (los proyectos) y relacional en bases de datos. La información documental de los proyectos presentados tiene una tasa de accesos muy baja y no se modifica después de su recepción, mientras que la información relacional de la base de datos necesita ser almacenada en un sistema de almacenamiento con mayor capacidad de entrada/salida. Esta clasificación de información es típica en proyectos de Administración Electrónica en los que se presenta una documentación que debe permanecer inalterable con el paso del tiempo. Dentro de las clasificaciones teóricas de los sistemas de almacenamiento (la mayoría de los sistemas de almacenamiento empresarial actuales ofrecen capacidades de ambos mundos) tenemos:
● SAN Almacenamiento en bloque de alto rendimiento, alta tasa de entrada/salida (IOPs) y posibilidad de conexión de muchos servidores.
● NAS Almacenamiento en red en modo sistema de ficheros, menor capacidad de entrada/salida
27
Es razonable pensar que el Ministerio responsable de las ICTs dispone de un sistema de almacenamiento SAN/NAS y para el presente proyecto se requiere una ampliación de 10 TB de espacio neto (los algoritmos de redundancia RAID y otra información añaden un porcentaje de espacio en bruto). Se recomienda buscar información para aplicarla a los supuestos sobre:
● Conceptos de almacenamiento jerárquico (tiering), deduplicación, archivado (archiving).
● Del mismo modo, las tecnologías específicas de almacenamiento según el tipo de dispositivo, como array de memoria, Flash/SSD, Fibrechannel (FC) o SATA.
● Los fabricantes líderes en el mercado según informes de Gartner son EMC, NetApp e Hitachi.
12. Dimensione los recursos del proyecto y realice un diagrama de Gantt en el que se distingan las diferentes fases del proyecto y los hitos principales. Indicaciones:
● La duración estimada del proyecto, tras la contratación, es de 12 meses aproximadamente. No obstante, se ha paralelizado el desarrollo de módulos relacionados durante la fase CSI, por lo que este tiempo podría ser superior si se realizasen de forma secuencial (y en cualquier caso es una estimación a partir de la complejidad estimada de los módulos).
● La contratación se estima en tres meses, si bien en el último mes se
comienza con las tareas de análisis, llevadas a cabo por personal funcionario.
● Dicha contratación se realizará mediante un contrato de servicios, siguiendo el procedimiento de contratación centralizada a través del Catálogo de la D.G. de Patrimonio del Estado, ya que se trata del desarrollo de una aplicación relacionada con la implantación de la Administración electrónica y la cuantía del contrato es inferior al límite establecido.
Planificación general (con EVS y contratación) y por fases:
28
Resumen del Gantt
29
Estimación del coste Atendiendo únicamente a los recursos subcontratados, los costes del proyecto presentado son 148.106 euros, con los siguientes costes por hora.
(Nota: hay una pequeña errata porque en los gastos del analista también se ha considerado el mes en que se solapa con la fase de contratación, y esta tarea tendría que realizarla personal funcionario, y por tanto sin coste externo). PREGUNTAS ADICIONALES
a. Se ha detectado fraude en los Ayuntamientos, dado que algunos promotores han entregado el resguardo de entrega de boletín, protocolo y certificado de fin de obra como si fuera esto el certificado del MINETUR que avala la entrega y firma de estos documentos por
30
parte del Jefe Provincial. Describa el formato de resguardo que puede darse como respuesta del Registro Electrónico ante la entrega de los citados documentos, en pleno cumplimiento de la Ley 11/2007.
Para dar pleno cumplimiento a la ley 11/2007 y su desarrollo, es preciso remitirse
al artículo 30.3:
El registro electrónico emitirá automáticamente por el mismo medio un recibo firmado electrónicamente, mediante alguno de los sistemas de firma del artículo 18 de la Ley 11/2007, de 22 de junio, con el siguiente contenido: a) Copia del escrito, comunicación o solicitud presentada, siendo admisible a estos efectos la reproducción literal de los datos introducidos en el formulario de presentación. b) Fecha y hora de presentación y número de entrada de registro. c) En su caso, enumeración y denominación de los documentos adjuntos al formulario de presentación o documento presentado, seguida de la huella electrónica de cada uno de ellos. d) Información del plazo máximo establecido normativamente para la resolución y notificación del procedimiento, así como de los efectos que pueda producir el silencio administrativo, cuando sea automáticamente determinable.
Según este artículo, los más normal en la aplicación sería que devolviese el
resguardo que genera el registro y que tendría un aspecto de este tipo, junto a la copia del escrito:
31
32
Este recibo de registro, se ofrece en todas las etapas de la aplicación, salvo en la relativa a la de boletín y protocolo, puesto que junto a la copia del escrito que se da, eran entregadas en ayuntamientos como si ya fuese el boletín y el protocolo firmados por el JPIT. Por eso, para el caso de boletín y protocolo, la aplicación sólo devuelve un
33
mensaje de “entrega correcta” y no le da el resguardo. Esto podría parecer ilegal, pero no lo es, puesto que un particular podría obtener el resguardo dirigiéndose al registro electrónico del MINETUR directamente y descargando su resguardo. Sin embargo, al no entregarlo por la aplicación directamente, se ha conseguido, de manera real, disminuir el número de casos de fraude. Junto al certificado que expiden los Jefes Provinciales y que piden ya muchos ayuntamientos, este tipo de fraude está mucho más acotado. Por eso, la aplicación sólo devuelve lo siguiente:
b. En línea con la estrategia de lucha contra el fraude emprendida por el
Gobierno, desde la AEAT se emprende un proyecto de cruce de datos de facturación de autónomos. Para ello, se hace necesario que el MINETUR traslade los datos de las empresas/autónomos que realizan las ICTs para su contraste con las declaraciones trimestrales realizadas por las mismas.
Describa la arquitectura necesaria para el intercambio de datos entre la AEAT y el MINETUR. Indique la aplicación de la LOPD para este caso concreto.
Se trata de una pregunta compleja y al encontrarse en las preguntas adicionales cabe señalar que el objetivo no debe ser entrar detalle, para no restar tiempo al resto de preguntas, sino aportar un conjunto de ideas o claves sobre el problema planteado.
34
(De hecho, en este caso realizar la descripción detallada de la arquitectura por sus características organizativas, de seguridad, etc. sería muy complejo).
Aspectos a tener en cuenta en la solución:
● Siempre que se incluya un servicio con otro organismo, es positivo revisar si éste está contemplado en la plataforma de intermediación. En este caso, al tratarse de un servicio no incluido, sería necesario utilizar los disponibles en la Agencia para este caso concreto.
● De cara a la arquitectura de comunicación, es importante tener presente la Red SARA como red comunicación entre organismos. Las características básicas a tener en cuenta de cara a un diseño basado en Red SARA:
○ Red entre organismos de la AGE en modalidad “todos con todos” sin existencia de un nodo central.
○ Basado en tecnología VPLS (conexiones de nivel 2 sobre un MPLS) que permite ofrecer Calidad de Servicio.
○ Soporte 24x7 y acuerdos con SLAs definidos. ○ El tráfico circula cifrado. ○ Velocidades:
■ 1Gbps entre Ministerios y CPDs. ■ 100Mbps con CCAA.
● Respecto al proceso de intercambio en sí, existen varias posibilidades. Una de
las más probables es un Servicio Web publicado en la AEAT que se invoque periódicamente desde MINETUR (no nos indican si es síncrono, podemos asumir que no es así). También existirían otras vías posibles, como la transferencia de ficheros, FTP, etc.
● En este punto, siempre que nos indiquen que tenemos que enviar datos a otro organismo que tiene la misión de procesarlo e integrarlo en su sistema es interesante indicar que se partirá de los servicios existentes para minimizar el impacto organizativo (asumir que la AEAT recogerá datos de autónomos a más organismos y el servicio ya estará desplegado).
Respecto a las implicaciones de la LOPD:
● ¿Aplica? Dependerá de los datos a ceder a la AEAT. La LOPD no se aplica a los datos de personas jurídicas pero sí a los datos de los empresarios individuales personas físicas (por ejemplo, autónomos) y a los ficheros de empresas que tengan una relación de personas físicas de contacto, esto es, los datos del representante legal de la empresa.
35
● ¿Con qué nivel? En función del tipo de dato que fuese requerido al MINETUR aplicaría un nivel u otro de la LOPD. (si no se explica podemos hacer suposiciones). Un resumen:
● ¿Es necesario recoger el consentimiento expreso de la empresa o autónomo? Esta pregunta puede ser confusa si se asocia este trámite a otros como por ejemplo la consulta a la AEAT de si la empresa está al corriente de pagos, el cual debe autorizar expresamente para que lo intermedie el MINETUR. En este caso, dado que se trata de una investigación contra el fraude que realiza la AEAT en el ejercicio de sus competencias no parece necesario informar al ciudadano. Lo que sí se debería es cumplir la LOPD en lo relativo a cesión de datos.
● ¿Existe una cesión de datos? Según Artículo 11 de la LOPD, no se pueden comunicar datos a otras AAPP para competencias diferentes salvo que: Lo permita una Ley, Que el interesado lo consienta u otras excepciones (fines históricos o estadísticos, deatos de salud por motivos de urgencia...). En este caso se entiende que entra dentro del ejercicio de las competencias de la AEAT, recogidas en la ley.
36
c. En relación con el trámite descrito en la Etapa 1, de presentación del
proyecto inicial, en el supuesto de que no se realice a través del Colegio Oficial de Ingenieros de Telecomunicación, la persona que firme el proyecto deberá cumplir con la condición de ser “Técnico competente”. Esto se traduce en que debe estar en posesión de un título universitario válido (no inhabilitado), comprendido en un conjunto de posibles titulaciones.
∙ Describa de forma cualitativa cómo realizaría este trámite, asumiendo que el MINETUR debe realizar dicha comprobación en el momento de aceptar el proyecto.
La clave de esta cuestión es tener presente qué servicios se prestan en la plataforma de intermediación (o servicio de verificación y consulta de datos) del MINHAP: http://administracionelectronica.gob.es/ctt/verPestanaGeneral.htm?idIniciativa=svd#.Uz3IG_l_sdU El catálogo de servicios completo se encuentra en http://administracionelectronica.gob.es/ctt/resources/e9f8d35ff21f41bdb03293550ae400b9?idIniciativa=223&idElemento=361 En este caso, el servicio que se debe utilizar es el Servicio de Verificación de Datos de Títulos Oficiales (SVDT), ofrecido por el Ministerio de Educación y que consta de dos servicios:
● El Servicio de Verificación de Títulos Universitarios ● El Servicio de Verificación de Títulos No Universitarios.
Estos servicios recogen los títulos oficiales registrados para un ciudadano. En el caso de los títulos universitarios, es necesario haber pagado la Tasa de Expedición para que el servicio muestre la información relativa al título. Así, dado que MINETUR ya utiliza la plataforma de intermediación en múltiples aplicaciones, tan solo es necesario utilizar la infraestructura desplegada dando de alta esta aplicación y procedimiento. El sistema de intercambio podría realizarse a través de Servicios Web, si bien en este caso es necesario
37
realizar una comprobación manual por parte del gestor a posteriori, ya que las titulaciones aceptadas no están identificadas unívocamente y se debe analizar cada una por separado. También es muy importante señalar que será necesario recabar el consentimiento expreso del proyectista, de forma que autorice a que sea el MINETUR quien realice el trámite en su nombre (informe interesante, sobre la cesión de datos y el consentimiento del interesado http://administracionelectronica.gob.es/ctt/resources/96bb1e2cfcfa4f3d8abcef6d74174f93?idIniciativa=223&idElemento=826 )
d. En futuras fases del proyecto se valorará la incorporación de un cuadro de mando para el personal del MINETUR encargado de la gestión de las ICTs. Realice una propuesta del mismo, destacando los principales indicadores e información a incluir.
Con respecto a este apartado, cuando se pide un cuadro de mando, lo normal es tratar de de hacer una recopilación de datos que pueden ser de interés para la persona afectada, como puede ser en este caso el encargado de la gestión de las ICTs. Para él, lo más importante serán los plazos y algo que refleje que el servicio que atiende es utilizado y de una cierta importancia. Por ello los plazos y los datos de
38
ICTs que se instalan (que necesariamente reflejan que se usa su servicio) son importantes. Otros datos en este sentido podrían ser algunos relativos a incidencias de la aplicación, que no figura en el cuadro de mando, entre otras cosas porque un servicio de CAU podría estar dando respaldo a esto. Pero además, hay datos que indirectamente importan al gestor:
● Los costes de la ICT, pues si el coste por vivienda es bajo, significa que no es una carga al ciudadano y que le aporta beneficios relativos a la conexión a redes de operadores. Esto hace que la iniciativa sea “vendible” a la dirección y que siga apostando por la misma.
● Las ICTs son algo de lo que se habla internacionalmente y España es ejemplo de ella. Dar datos de los costes de los proyectos y del número de ICTs instaladas en España dan idea de la fuerza del sector, que al ser pionero mundial puede exportar su conocimiento a otros países que estén planeando explotar un modelo similar.
● El número de ICTs, los operadores que llegan a las casas y sus coberturas en lo relativo a diferentes tecnologías alimentan datos importantes para informes de Sociedad de la Información, lo que justifica al mismo tiempo que esta información pueda ser reutilizable.
Por último destacar que sólo se pide el cuadro de mando. Si se pidiese la tecnología que subyace al mismo, se trataría de ser proporcionado al fin. Un cuadro de mando sencillo puede generarse con herramientas sencillas de generación de reportes integradas en la aplicación. Si quisiese usarse una herramienta de Business Intelligence, el sistema NO justificaría la compra de una. Debería hacerse uso de tecnologías ya existentes en el Ministerio y que la aplicación sea fuente de datos de las mismas. Estas tecnologías requieren de un cierto estudio para hablar de ellas con propiedad.
39
Anexos Anexo I - Proceso de categorización de los sistemas El proceso de categorización de los sistemas que se describe a continuación es el propuesto
en el ANEXO I del Esquema Nacional de Seguridad.
1. Fundamentos para la determinación de la categoría de un sistema.
La determinación de la categoría de un sistema se basa en la valoración del impacto que
tendría sobre la organización un incidente que afectara a la seguridad de la información o de
los sistemas, con repercusión en la capacidad organizativa para:
a) Alcanzar sus objetivos.
b) Proteger los activos a su cargo.
c) Cumplir sus obligaciones diarias de servicio.
d) Respetar la legalidad vigente.
e) Respetar los derechos de las personas.
La determinación de la categoría de un sistema se realizará de acuerdo con lo establecido en
el presente real decreto, y será de aplicación a todos los sistemas empleados para la
prestación de los servicios de la Administración electrónica y soporte del procedimiento
administrativo general.
2. Dimensiones de la seguridad.
A fin de poder determinar el impacto que tendría sobre la organización un incidente que
afectara a la seguridad de la información o de los sistemas, y de poder establecer la
categoría del sistema, se tendrán en cuenta las siguientes dimensiones de la seguridad, que
serán identificadas por sus correspondientes iniciales en mayúsculas:
a) Disponibilidad [D].
b) Autenticidad [A].
c) Integridad [I].
d) Confidencialidad [C].
e) Trazabilidad [T].
3. Determinación del nivel requerido en una dimensión de seguridad.
40
Una información o un servicio pueden verse afectados en una o más de sus dimensiones de
seguridad. Cada dimensión de seguridad afectada se adscribirá a uno de los siguientes
niveles:
BAJO, MEDIO o ALTO. Si una dimensión de seguridad no se ve afectada, no se adscribirá a
ningún nivel.
a) Nivel BAJO. Se utilizará cuando las consecuencias de un incidente de seguridad que
afecte a alguna de las dimensiones de seguridad supongan un perjuicio limitado
sobre las funciones de la organización, sobre sus activos o sobre los individuos
afectados.
Se entenderá por perjuicio limitado:
1º La reducción de forma apreciable de la capacidad de la organización para
atender eficazmente con sus obligaciones corrientes, aunque estas sigan
desempeñándose.
2º El sufrimiento de un daño menor por los activos de la organización.
3º El incumplimiento formal de alguna ley o regulación, que tenga carácter de
subsanable.
4º Causar un perjuicio menor a algún individuo, que aún siendo molesto pueda
ser fácilmente reparable.
5º Otros de naturaleza análoga.
b) Nivel MEDIO. Se utilizará cuando las consecuencias de un incidente de seguridad que
afecte a alguna de las dimensiones de seguridad supongan un perjuicio grave sobre
las funciones de la organización, sobre sus activos o sobre los individuos afectados.
Se entenderá por perjuicio grave:
1º La reducción significativa la capacidad de la organización para atender
eficazmente a sus obligaciones fundamentales, aunque estas sigan
desempeñándose.
2º El sufrimiento de un daño significativo por los activos de la organización.
3º El incumplimiento material de alguna ley o regulación, o el incumplimiento
formal que no tenga carácter de subsanable.
4º Causar un perjuicio significativo a algún individuo, de difícil reparación.
5º Otros de naturaleza análoga.
c) Nivel ALTO. Se utilizará cuando las consecuencias de un incidente de seguridad que
afecte a alguna de las dimensiones de seguridad supongan un perjuicio muy grave
sobre las funciones de la organización, sobre sus activos o sobre los individuos
afectados.
Se entenderá por perjuicio muy grave:
41
1º La anulación de la capacidad de la organización para atender a alguna de sus
obligaciones fundamentales y que éstas sigan desempeñándose.
2º El sufrimiento de un daño muy grave, e incluso irreparable, por los activos de
la organización.
3º El incumplimiento grave de alguna ley o regulación.
4º Causar un perjuicio grave a algún individuo, de difícil o imposible reparación.
5º Otros de naturaleza análoga.
Cuando un sistema maneje diferentes informaciones y preste diferentes servicios, el nivel del
sistema en cada dimensión será el mayor de los establecidos para cada información y cada
servicio.
4. Determinación de la categoría de un sistema de información.
1. Se definen tres categorías: BÁSICA, MEDIA y ALTA.
a) Un sistema de información será de categoría ALTA si alguna de sus dimensiones
de seguridad alcanza el nivel ALTO.
b) Un sistema de información será de categoría MEDIA si alguna de sus dimensiones
de seguridad alcanza el nivel MEDIO, y ninguna alcanza un nivel superior.
c) Un sistema de información será de categoría BÁSICA si alguna de sus dimensiones
de seguridad alcanza el nivel BAJO, y ninguna alcanza un nivel superior.
2. La determinación de la categoría de un sistema sobre la base de lo indicado en el
apartado anterior no implicará que se altere, por este hecho, el nivel de las
dimensiones de seguridad que no han influido en la determinación de la categoría del
mismo.
42
Anexo II - Información del enunciado
Gráfico 1
Extracto de carta al subdirector
43
Capturas de pantallas de archivos en CD’s de expedientes de ICTs previos a la implementación de la aplicación
44
45