Skip to main content

Los requisitos legales de accesibilidad, interoperabilidad, seguridad y privacidad

Introducción​

En el diseño de nuestras soluciones o sistemas no podemos olvidar nunca, lo pregunten explícitamente o no, los componentes legales y normativos a los que estamos obligados como Administración. No se trata de conocer en profundidad todos los elementos o componentes, o en saber hacer una clasificación perfecta en el ENS del sistema. Pero si hay que tener en cuenta todos los elementos en los distintos puntos del ejercicio para, una vez más, darle coherencia:

  • La seguridad ha de ser inherente a la construcción del sistema, las medidas de seguridad típicas que ponemos han de estar adecuadas a ese nivel o explicadas al menos someramente (principio del ENS, la seguridad desde el diseño).

  • La privacidad (protección de datos) puede influir en los datos que maneja el sistema y a su vez en el nivel de ENS, cuando hay datos especialmente protegidos, ¿cómo actuar?.

  • Es habitual poner en los diagramas esas capas transversales de interoperabilidad, seguridad … pero, ¿sabemos qué funcionalidades tienen y en qué se materializa?

Accesibilidad​

NOTA

Se entiende accesibilidad como un conjunto de principios y técnicas que se deben respetar a la hora de diseñar, construir, mantener y actualizar los sitios web y las aplicaciones para dispositivos móviles.

INFO

NORMATIVA VIGENTE MÁS ACTUAL: REAL DECRETO 1112/2018 QUE DESARROLLA LA DIRECTIVA (UE) 2016/2102, DEL PARLAMENTO Y EL CONSEJO, SOBRE ACCESIBILIDAD DE LOS SITIOS WEB Y APLICACIONES PARA DISPOSITIVOS MÓVILES DEL SECTOR PÚBLICO.

Desde el 21 de diciembre de 2018, el estándar a cumplir por las Administraciones Públicas españolas en sus sitios web es el EN 301 549 v2.1.2 (2018-08) (equivalente a WCAG 2.1). En el caso de las aplicaciones móviles aplicará a partir del 23 de junio de 2021. Al hablar de la capa de presentación hay que mencionar la Accesibilidad, hacer una referencia a la normativa, del estilo:

NOTA

Para la capa de presentación realizaremos interfaz de aplicación web basada en estándares y compatible con los navegadores principales, con diseño adaptable a distintos tipos de dispositivos y que cumpla la normativa de accesibilidad según el RD 1112/2018, a un nivel mínimo de WCAG 2.1

Elementos relevantes para el apartado de accesibilidad:

  • Páginas web y texto HTML.
  • Aplicaciones para móviles.
  • Elementos audiovisuales (gráficos, logotipos, animaciones, vídeos, ficheros de audio, etc.).
  • Documentos (pdf, word, excel). Esto no es muy conocido pero también hay normas de accesibilidad para ellos.
IMPORTANTE

Unidad Responsable de la Accesibilidad Podremos hacer mención en nuestro ejercicio a la URA o Unidad Responsable de Accesibilidad, con la que podremos contar para asistir en materia de Accesibilidad, así como para las cuestiones relativas a la Contratación, revisión, obligaciones legales, etc.

¿Que implica desarrollar correctamente el apartado de Accesibilidad en la práctica?

  • Incluir en la parte de contratación del desarrollo las cláusulas de cumplimiento de los estándares de Accesibilidad. Encarece el desarrollo de forma apreciable, así que hay que tenerlo en cuenta.
  • Realizar una evaluación de la accesibilidad de la aplicación web o móvil según lo establecido por el Observatorio de accesibilidad antes de publicar la aplicación o la web. Es un proceso no trivial que puede llevar unas dos semanas de trabajo.
  • Realizar un plan de evaluación/mejora bianual.
  • Publicar la declaración de accesibilidad con los resultados de la evaluación

INTEROPERABILIDAD​

Normas de interoperabilidad​

El ENI se establece en el art. 156 de la Ley 40/2015, de Régimen Jurídico del Sector Público, que sustituye al apartado 1 del artículo 42 de la Ley 11/2007, LAECSP, derogada.

Las normas de Interoperabilidad publicadas son las siguientes:

  1. Catálogo de estándares. Incluye los estándares a observar como medio para alcanzar la interoperabilidad.
  2. Documento electrónico. Especifica un estándar XML para el almacenamiento de documentos de forma interoperable.
  3. Digitalización de documentos. Norma técnica sobre las especificaciones de digitalización para alcanzar legibilidad y formatos interoperables.
  4. Expediente electrónico. Como el documento electrónico, pero para conjuntos de documentos.
  5. Política de firma electrónica y de certificados de la Administración. Unifica los medios técnicos a emplear en los aspectos técnicos de la firma electrónica y certificados.
  6. Protocolos de intermediación de datos. Para el intercambio de datos entre organismos y Administraciones.
  7. Relación de modelos de datos. Distintos modelos de datos reutilizables para almacenar datos comunes.
  8. Política de gestión de documentos electrónicos.
  9. Requisitos de conexión a la Red de comunicaciones de las Administraciones Públicas españolas (RED SARA). Es un estándar técnico para permitir la conectividad de redes.
  10. Procedimientos de copiado auténtico y conversión entre documentos electrónicos, así como desde papel u otros medios físicos a formatos electrónicos. Impide que los cambios de formato sean una barrera para la interoperabilidad.
  11. Modelo de Datos para el intercambio de asientos entre las Entidades Registrales (SICRES v3). Permite la interoperabilidad de los registros.
  12. Reutilización de recursos de información.

Adicionalmente se han publicado guías para la aplicación de las mencionadas NTIs. También guías para la adecuación al ENI, con respecto a:

  • Reutilización y transferencia de tecnología (aplicaciones, activos, CTT…)
  • Declaración de conformidad con el ENI (adecuación al ENI, auditoria, …) así como las URL´s de esquemas XML.

Servicios y tecnologias de soporte a la interoperabilidad​

NTI de Documento y expedientes electronicos​

Para alcanzar la interoperabilidad de los expedientes y documentos, se ha definido un formato de intercambio (interoperabilidad semántica), y algunos medios técnicos para alcanzarla.

Concretamente, se pone a disposición INSIDE como solución que puede aportar varios objetivos:

  • Un repositorio de documentos como servicio en la nube y gestor de documentos y expedientes.
  • Un validador/conversor de formatos compatibles (G-INSIDE).

Plataforma de intermediación de datos (PID)​

La plataforma de intermediación permite el intercambio de documentos acreditativos entre distintos Organismos de la Administración.

Permite reducir el número de solicitudes de los interesados hacia la Administración. Su razón de ser se basa en la normativa siguiente:

  • Art. 53.1-d. Ley 39/2015 → Derecho a no presentar datos y documentos no exigidos por las normas aplicables al procedimiento de que se trate, ya se encuentren en poder de las AAPP o hayan sido elaborados por éstas.

  • Art. 28. Ley 39/2015 → Documentos aportados por los interesados al procedimiento administrativo.

Recordemos que los datos que cada organismo recaba y custodia en el ámbito de sus competencias de los ciudadanos, no puede compartirse o cederse incluso a otros organismos de la misma Administración sin una razón legal que lo justifique, también para salvaguardar los derechos de los ciudadanos.

Por ello, es necesario que para la evitar que el ciudadano tenga que recabar la información a cada organismo por su cuenta:

  • a. Exista un marco legal de autorización de cesión de la información entre organismos otorgado por el ciudadano.
  • b. Exista una base tecnológica para permitir esta transferencia de información.

Estas dos premisas las soluciona la Plataforma de Intermediación de Datos.

EJEMPLO

para optar a una subvención en el ámbito de Innovación, se requiere un certificado de estar al corriente de pagos de la Seguridad Social para esta entidad. El Ministerio de Ciencia e Innovación puede firmar un convenio de cesión de datos con el organismo cedente (GISS) para obtener este certificado de forma automática a través de la PID con el consentimiento del ciudadano. Obtendrá este certificado a través de la conexión a la PID a través de red Sara y lo incorporará al expediente correspondiente de forma automática. Si el ciudadano no quisiera permitir esta consulta, debería aportar él mismo al expediente el documento.

Las consultas a los servicios de verificación de datos se pueden realizar de dos maneras:

  • De forma automatizada desde una aplicación de gestión de un trámite, adaptadas para invocar los Webservice proporcionados por el servicio.
  • Por un empleado público autorizado mediante un cliente web (cliente ligero).
IMPORTANTE

Para el acceso a la Plataforma de Intermediación se deberá tener firmado un convenio de colaboración con la Secretaría General de Administración Digital. Para el consumo de los servicios proporcionados por la Plataforma de Intermediación, éstos deberán ser autorizados por el Organismo Cedente de los datos intermediados (existe un formulario para solicitar esta autorización). Ver PAe - CTT - área de Descargas - Servicio de Verificación y Consulta de Datos: Plataforma de Intermediación

Intermediación solo guarda la traza, no guarda los datos ni los ve en tránsito (https), e incluye un módulo de autorización. Sin embargo, tú como Organismo, para cumplir con la LOPD-RGPD, deberías guardar tu propio log.

En todos los tipos de petición de datos se valida y además con ella se comprueba si la aplicación solicitante está autorizada para realizar dicha consulta. Si todo es correcto, PID tramitará dicha consulta, garantizando la integridad y seguridad de ésta y responderá al organismo peticionario con la verificación de los datos consultados.

PID además registra todas las operaciones realizadas, firmando y sellando en tiempo para garantizar tanto la integridad del mensaje, como el momento en el que dicha petición se ha realizado.

Los requisitos que rigen la digitalización de documentos se recogen en el Esquema Nacional de Interoperabilidad y, en concreto, en la norma técnica establecida a tal efecto, desarrollada para homogeneizar esta actividad en todas las Administraciones Públicas.

¿Qué tiene que ver la interoperabilidad con la intermediación de datos?. Bueno, la primera es requisito para la segunda. Técnicamente, se ha definido el protocolo SCSP v3 para el intercambio de acreditaciones de forma electrónica, por lo que nuestro sistema deberá ser capaz de cumplir con las especificaciones necesarias para la interoperabilidad si fuera necesario.

Validación de datos de Identidad y Residencia.

Es un uso muy común el consultar estos datos. La normativa ya no exige al ciudadano aportar los datos del DNI o el certificado de residencia, por lo que a través del NIF podrían obtenerse estos datos de forma automática, que generalmente son un punto de comprobación necesario para el inicio de instrucción del procedimiento.

Técnologias de soporte​

Hay una serie de tecnologías que nos ayudarán en la interoperabilidad aunque no se hayan mencionado en el ENI:

  • Arquitecturas SOA: Protocolos SOAP O REST para intercomunicar mediante servicios nuestros sistemas (muchos de los servicios comunes y servicios de la SGAD usan SOAP y WS-Security). .
  • Tecnologías de aplicaciones web, basadas en estándares abiertos, para acceder al mayor número de dispositivos posibles, como HTML5, CSSv3, Javascript, etc.
  • Sistemas de Gestión de Bases de datos Relacionales: El lenguaje ANSI SQL, nos permitirá tener cierto grado de interoperabilidad entre distintos sistemas gestores de BBDD, ya que se trata de un estándar normalizado.

Dimensiones de interoperabilidad​

Al igual que la seguridad, la interoperabilidad no se alcanza únicamente con medios técnicos, adoptando un estándar o desarrollando ciertas soluciones tecnológicas. Incluye la conjunción de diversos aspectos que deben ser coherentes entre sí, llamados dimensiones:

  • Organizativa: referente a los roles y responsabilidades, normativa y recomendaciones a seguir por las distintas partes de la organización para lograr los objetivos.

  • Semántica: referente a la organización de la información y al significado formal que debemos darle, de tal manera que no existan distintas interpretaciones acerca del significado de la información. Por ejemplo, qué es un documento electrónico o qué se considera una firma electrónica válida, pasando por el significado y posibles estados de la información sobre el “estado civil” de una persona física.

  • Técnica: que involucra los aspectos tecnológicos que son necesarios para lograr el resultado de la interoperabilidad, como estándares, tecnologías, sistemas.

Ejemplos

Organizativa

  • La creación de los inventarios de procedimientos administrativos y servicios prestados –codificados en SIA– así como de órganos administrativos y oficinas de registro y su enlace con el de la AGE, codificados en DIR3. Notar que la dimensión organizativa es la de la obligatoriedad de un registro común de unidades y oficinas, y la técnica es la implementación a través de un sistema como DIR3.
  • La publicación de las normativas y condiciones de acceso y utilización de los servicios electrónicos a efectos de interoperabilidad entre administraciones públicas.
  • La publicación de los servicios a través de la Red de comunicaciones de las Administraciones Públicas españolas (red SARA) o de cualquier otra red equivalente o conectada a la misma;
  • La normativa y obligatoriedad de interconexión de registros de entrada y salida (a través de SIR y bajo norma SICRES 3.0)

NTIs relacionadas:

  • Política de firma electrónica y de certificados de la Administración.
  • Política de gestión de documentos electrónicos.
  • Requisitos de conexión a la Red de comunicaciones de las AAPP (SARA).
  • Modelo de Datos para el intercambio de asientos entre las Entidades Registrales.

Semantica

  • Uso de la relación de modelos de datos de intercambio que tengan el carácter de comunes y sectoriales;
  • Publicación de los modelos de datos en el Centro de Interoperabilidad Semántica NTI relacionada:
  • Modelo de Datos para el intercambio de asientos entre las Entidades Registrales.
  • Relación de modelos de datos que tengan el carácter de comunes en la Administración y aquellos que se refieran a materias sujetas a intercambio de información con los ciudadanos y otras administraciones.

Técnica

  • Las AAPP usarán estándares abiertos y estándares de uso generalizado por los ciudadanos. El uso de estándares no abiertos se reservará a las situaciones en las que no hay alternativa. Se aplicará lo previsto en la normativa sobre estándares aplicables. NTI relacionada:
  • Catálogo de estándares.
IMPORTANTE

Además de las 3 dimensiones de la interoperabilidad descritas en el ENI (organizativa, semántica y técnica), en supuestos prácticos anteriores se pedían medidas para interoperabilidad jurídica y temporal.

Seguridad​

Desde el 5 de noviembre de 2017, en que se cumplen los 24 meses de adaptación de sistemas al ENS, dado por la DT única del RD 951/2015 de modificación del RD 3/2010 del ENS en la Administración Electrónica, todos los sistemas que se realicen deben ajustarse a la plena aplicación de lo exigido en el ENS.

El Plan de Adecuación al ENS será realizado por el Responsable de Seguridad del sistema y deberá ser aprobado por los órganos superiores competentes.

El contenido del Plan de Adecuación al ENS será el siguiente:

  • Responsabilidades. (CCN-STIC 801).
  • Política de Seguridad. (CCN-STIC 805).
  • Inventario y valoración de la información afectada, incluidos los datos personales.(Anexo I ENS + CCN-STIC 803).
  • Inventario y valoración de los servicios prestados. (Anexo I ENS + CCN-STIC 803).
  • Categorización del sistema o sistemas. (Anexo I ENS + CCN-STIC 803).
  • Análisis de riesgos. (Anexo III ENS + CCN-STIC 802).
  • Declaración de aplicabilidad, el plan de seguridad, con las medidas del anexo II del ENS o compensatorias y su correspondencia (+ CCN-STIC 804).
  • Plan de Implantación de la seguridad.

Si piden un plan de adecuación se sobreentiende que son las pautas para realizarlo, ese índice de contenido, porque no hay tiempo para ese detalle en el examen, excepto que se pidan expresamente detalles o de tiempo a detallar un poco más.

De la misma forma que hay que tener en cuenta las NTIs en lo relativo a la interoperabilidad, habrá que tener en cuenta las Instrucciones Técnicas de Seguridad (ITS) que se vayan publicando.

Actualmente se han publicado:

  • ITS de conformidad con el ENS.
  • ITS de Informe de Seguridad Nacional.

Con respecto al informe del estado de la seguridad, se hacen referencias expresas a la articulación de los procedimientos necesarios para la recogida y consolidación de información. Estará bien reflejar esos procedimientos en nuestro sistema

Para categorizar un sistema segun el ENS​

Categorizar​

Para describir las medidas de seguridad a implementar, el Responsable de Seguridad categoriza el sistema de acuerdo con la criticidad de los datos que gestiona, así como el nivel de importancia que, para el sistema, tiene cada una de las dimensiones de seguridad: Autenticidad, Confidencialidad, Integridad, Disponibilidad y Trazabilidad.

Categorizacion

Para valorar las dimensiones se atenderá a lo dispuesto en la Guía CCN-STIC 803.

Medidas a implementar​

A continuación, se incluye una relación de algunas de las medidas que habrá que implantar, EN DISTINTOS MARCOS.

MARCO ORGANIZATIVO.

MARCO OPERACIONAL.

MEDIDAS DE PROTECCIÓN SEGUN LA DIMENSION

  • AUDITORÍA DE CUMPLIMIENTO DEL ENS.
    • Sistemas de Categoría Básica:
      • Autoevaluación realizada por el mismo personal que administra el sistema.
    • Sistemas de Categoría Media y Alta.
      • Auditoría completa → Realizada por entidad certificadora, con publicidad de conformidad, según la ITS de Conformidad con el ENS, de acuerdo con la CCN-STIC-809, sobre declaración y certificación de conformidad con el ENS.
  • OBJETIVOS DE LA AUDITORÍA.
    • Que la política de seguridad define los roles y Funciones de los responsables de la información, los servicios, los activos y la seguridad del sistema de información.
    • Que existen procedimientos para resolución de conflictos entre dichos responsables.
    • Que se han designado personas para dichos roles a la luz del principio de «separación de Funciones».
    • Que se ha realizado un análisis de riesgos, con revisión y aprobación anual.
    • Que se cumplen las recomendaciones de protección descritas en el anexo II, sobre Medidas de Seguridad, en Función de las condiciones de aplicación en cada caso.
    • Que existe un sistema de gestión de la seguridad de la información, documentado y con un proceso regular de aprobación por la dirección.
  • INFORME DE AUDITORIA.
    • Grado de cumplimiento del ENS.
    • Sugerir las posibles medidas correctoras o complementarias.
    • Criterios metodológicos de Auditoría utilizados.
    • Alcance y el objetivo de la Auditoría.
    • Datos, hechos y observaciones en que se basen las conclusiones formuladas.

En sistemas de categoría ALTA según el ENS, el Responsable de Sistemas podrá acordar la retirada de operación de alguna información / servicio o del sistema en su totalidad, durante el tiempo que estime prudente y hasta la satisfacción de las modificaciones prescritas.

Los informes de auditoría pueden ser requeridos por los responsables con competencias sobre seguridad de las TIC o también por el CCN-CERT.

ENFOQUE PRACTICO

es más fácil defender un nivel medio en caso de que el sistema fuera alto, que al revés. Es difícil de justificar un nivel alto, los costes son muy altos, solo sistemas de defensa, interior y algunos muy concretos tienen nivel Alto

Privacidad​

Ley Orgánica 3/2018 de Protección de Datos y Reglamento (UE) 679/2016, RGPD La protección de datos de carácter personal es un elemento a tener siempre en cuenta, máxime si hay datos especialmente protegidos en nuestro sistema. Los elementos a tener en cuenta además es si nuestro sistema deberá o no recibir un EIPD o el registro de actividades de tratamiento.

Hay que revisar y tener cuidado (COHERENCIA) entre las medidas del ENS y las de LOPD: Disposición adicional primera LOPD. Medidas de seguridad en el ámbito del sector público.

  1. El Esquema Nacional de Seguridad incluirá las medidas que deban implantarse en caso de tratamiento de datos personales para evitar su pérdida, alteración o acceso no autorizado, adaptando los criterios de determinación del riesgo en el tratamiento de los datos a lo establecido en el artículo 32 del Reglamento (UE) 2016/679.

  2. Los responsables enumerados en el artículo 77.1 de esta ley orgánica deberán aplicar a los tratamientos de datos personales las medidas de seguridad que correspondan de las previstas en el Esquema Nacional de Seguridad, así como impulsar un grado de implementación de medidas equivalentes en las empresas o fundaciones vinculadas a los mismos sujetas al Derecho privado. En los casos en los que un tercero preste un servicio en régimen de concesión, encomienda de gestión o contrato, las medidas de seguridad se corresponderán con las de la Administración pública de origen y se ajustarán al Esquema Nacional de Seguridad.

Datos especialmente protegidos Ideología, afiliación sindical, religión, creencias, origen racial o étnico, salud, vida sexual, datos genéticos y biométricos (Art. 9 del RGPD) así como datos relativos a condenas e infracciones penales (Art 10)

Evaluación de impacto en la privacidad de los datos:

  • Cuando: tratamiento con probabilidad de alto riesgo para derechos fundamentales y libertades públicas; Ej.: nuevas tecnologías (naturaleza, alcance, contexto o fines) sea de alto riesgo para los DFyLP (Ej.: Big Data, Block Chain, IoT, Targeting Advertising, …)

  • La EIPD ha de realizarse antes de la puesta en marcha del tratamiento

  • En particular: a) evaluación sistemática y exhaustiva de aspectos personales basado en un tratamiento automatizado (ej.: perfilado), y sobre cuya base se tomen decisiones con efectos jurídicos (o afecte de forma similar) para la persona b) tratamiento a gran escala de: categorías especiales de datos (art 9.1), o datos de infracciones penales (art. 10), o c) observación sistemática a gran escala de una zona de acceso público.

  • APD: Adoptar listados de tipo de operaciones de tratamientos que: ☞ SI precisan EIPD: publicación obligatoria ☞ NO precisan EIPD: publicación voluntaria (para ambos: aplicar mecanismo coherencia del art. 63 para tratamientos transfronterizos)

  • Contenido mínimo EIPD: tratamiento con probabilidad de alto riesgo para los DyLP; a) Descripción: operaciones de tratamiento, fines e interés legítimo (si lo hay). b) Evaluación (necesidad y proporcionalidad): operaciones de tratamiento vs. Finalidad. c) Evaluación (riesgos): operaciones de tratamientos vs. DyLP. d) Medidas previstas (garantías, seguridad): para afrontar los riesgos y demostrar conformidad con el RGPD (teniendo en cuenta derechos afectados y terceros).

  • Cumplimiento Códigos de Conducta (art. 40): Se tendrá en cuenta en la EIPD.

  • No será necesaria EIPD: para tratamientos basados en una norma legal (nacional o de la UE) en cuya tramitación se hubiere realizado ya una EIPD.

  • Revisión de la EIPD: cuando existan un cambio del riesgo.

  • Obligación de hacerla antes del tratamiento y siempre que haya cambios en los riesgos:

    • No obligación de EIPD para tratamientos preexistentes a 25.5.2018, pero pasada esta fecha tendrán que hacer la EIPD en cuanto haya cambios en los riesgos (ej.: automatización, externalización, cambios técnicos u organizativos, en los fines, en las bases jurídicas, etc.)