Libro Lopd V2 Alta
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Libro Lopd V2 Alta

  • 6,027 views
Uploaded on

La proteccion de datos personales

La proteccion de datos personales

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • saludos
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
6,027
On Slideshare
6,026
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
218
Comments
1
Likes
1

Embeds 1

https://twitter.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. La protección de datos personales: Soluciones en entornos Microsoft
  • 2. La protección de datos personales: Soluciones en entornos Microsoft Publicado por: Microsoft Ibérica S.R.L. Centro Empresarial La Finca Edificio 1 Paseo del Club Deportivo, 1 28223 Pozuelo de Alarcón – Madrid (España) Copyright © 2009 Microsoft Ibérica Unipersonal S.R.L. Aviso Legal: Los autores, colaboradores, organismos públicos y empresas mencionadas en este libro, no se hacen responsables de que lo contenido en este libro garantice el total cumpli- miento de los requisitos establecidos en la legislación española sobre protección de datos personales. Este libro única y exclusivamente posee un propósito informativo en relación con la legislación española sobre protección de datos de carácter personal. La información sobre los productos de Microsoft representa la visión que los autores, colaboradores y empresas mencionadas en este libro tienen sobre los mismos, por lo que no otorgan ninguna garantía, ni expresa ni implícita, en referencia a la información incluida en este libro sobre los mencionados productos. Es responsabilidad del usuario el cumplimiento de toda la legislación sobre derechos de autor y protección de datos de carácter personal que sean aplicables. Sin limitar los derechos que se deriven sobre propiedad intelectual, ninguna parte de este documento puede ser reproducida, almacenada, ni introducida en ningún sistema de recuperación, ni transmitida de ninguna forma, ni por ningún medio, ya sea electrónico, mecánico por fotocopia, grabación o de otro tipo, con ningún propósito, sin la autorización por escrito de los titulares de los derechos de propiedad intelectual de este libro. Quedan reservados todos los derechos. Los nombres de las compañías y productos reales aquí mencionados pueden ser marcas comerciales de sus respectivos propietarios. EJEMPLAR GRATUITO. PROHIBIDA SU VENTA. Depósito Legal: M-14799-2009 Coordinador Editorial: Héctor Sánchez Montenegro Diseño y maquetación: José Manual Díaz. Newcomlab S.L.L. Revisión técnica: Newcomlab S.L.L. Imprime: Impreso en España – Printed in Spain Realizado en papel reciclado. II
  • 3. Prólogo de María Garaña El derecho a la intimidad resulta tan irrenunciable como cualquier otro de los derechos que nos asisten en nuestra Constitución. Su valor ya se encuentra recono- cido en el artículo 12 de la Declaración Universal de los Derechos Humanos (1944), así como en el artículo 18 de La Constitución Española, donde se recoge literalmen- te: “Se garantiza el derecho al honor, a la intimidad personal y familiar y a la propia ima- gen”… “La Ley limitará el uso de la informática para garantizar el honor y la intimidad personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos”. Sin perdernos en demasiados tecnicismos, el concepto de intimidad y privacidad, quizá sea de los más cercanos a nuestra experiencia y sentimiento. Especialmente cuando es vulnerado nuestro derecho a poder excluir a las demás personas del conocimiento de nuestra vida personal, de nuestros sentimientos, de nuestras emociones, de nuestros datos biográficos y personales etc. Así como el derecho a controlar el quién, cuándo y cómo puede tener acceso a estos aspectos de la vida personal de cada uno. El tratamiento automatizado y masivo de datos constituye un pilar de la Sociedad del Conocimiento, sobre la cual se ha cimentado el progreso de nuestras empresas, de nuestras administraciones, e incluso de nuestro propio desarrollo como individuos del siglo XXI. Pero es evidente que la facilidad inherente al trata- miento automatizado de datos requiere una especial atención que asegure la protec- ción efectiva de nuestro derecho a la intimidad. En este sentido, la legislación específica sobre Protección de Datos es la que establece los límites y condiciones para su tratamiento. El presente libro, aunque de carácter divulgativo, está dirigido a los responsa- bles técnicos de empresas y administraciones, así como a los responsables de aplicar las salvaguardas y procesos contemplados en el Reglamento de la LOPD para el manejo de los datos de carácter personal de sus clientes, empleados, socios, etc... El libro busca su hueco en esa zona intermedia en la que necesitamos aplicar con garantías una serie de medidas técnicas, dictadas por un reglamento jurídico, pero trasladables al mundo real en la forma de conocimiento tecnológico. Es por ello por lo que la guía toma como hilo conductor todos y cada uno de los artículos contemplados en el reglamento de la LOPD, con transcendencia en el ámbito de las Tecnologías de la Información, para a continuación comentarlos de forma sencilla y detallar cual sería la configuración o recomendación técnica más adecuada para su cumplimiento desde la perspectiva de la tecnología Microsoft. Aun reconociendo la naturaleza eminentemente técnica del manual, no deja de ser una auténtica delicia el navegar por sus páginas de contenido reglamentario, que de forma amena y clara presenta con sencillez los conceptos más básicos y delicados del reglamento. La estructura del libro, aun manteniendo dos partes claramente diferenciadas (jurídica y técnica), establece un permanente vínculo entre ambas, y es en ese nexo precisamente donde reside el principal valor para los responsables técnicos de III
  • 4. La protección de datos personales: Soluciones en entornos Microsoft aplicar las medidas del reglamento para los datos almacenados utilizando software de Microsoft. Tenemos la esperanza que, este manual, en su segunda edición, sirva para facilitar a los responsables de Seguridad/Privacidad/Sistemas, el cumplimiento de los aspectos tecnológicos derivados del cumplimiento de la Ley, así como servir de vehículo de difusión de un conocimiento importante como es el relativo a nuestros derechos y obligaciones en materia de Protección de Datos. Es un ejemplo más del compromiso incuestionable de Microsoft por colaborar, decidida y eficazmente, con la administración española en el desarrollo de la Sociedad del Conocimiento en nuestro país. María Garaña Presidenta de Microsoft Ibérica S.R.L. IV
  • 5. Prólogo de Artemi Rallo Como Director de la Agencia Española de Protección de Datos, institución pública independiente, cuya labor primordial es la de velar por el cumplimiento de la normativa de protección de datos de carácter personal, supone para mí una enorme satisfacción poder presentar este libro, “La Protección de Datos Personales: soluciones en entornos Microsoft”, fruto de los trabajos realizados por entidades de la talla de Microsoft, Helas Consultores, IPSCA, Informática64 y Red.es. Debemos destacar el objetivo primordial que pretende conseguir una obra como la que en estos momentos se edita y que viene a reforzar la labor de difusión y divulgación del derecho fundamental a la protección de datos de carácter personal en nuestro país. El libro que tengo la oportunidad de prologar, una vez adaptado a la normati- va vigente en materia de protección de datos personales debe, sin lugar a dudas, convertirse en una guía de consulta, no sólo para los responsables de ficheros y tratamientos de datos personales sino también para los posibles encargados de tratamientos que pudieran contratarse como consecuencia de la necesaria presta- ción de un servicio determinado, tanto en el ámbito privado como público y que el propio RLOPD regula de manera muy detallada en su articulado. Los conceptos mencionados en este libro y las obligaciones que todo responsa- ble de un fichero o tratamiento deben cumplir dentro del marco de la protección de datos personales, analizados de una forma muy detallada a lo largo del mismo, pretenden aportar una claridad y una seguridad jurídica valiosa a la hora de inter- pretar la normativa vigente. Sin lugar a dudas, la lectura del presente texto debe servir para resolver gran parte de las posibles dudas que pudieran tener los respon- sables de ficheros o tratamientos al interpretar las normas concernientes a la protec- ción de datos de carácter personal. Principios como la calidad de los datos, la información previa que ha de ser prestada al titular de los datos para recabar su consentimiento, el deber de secreto, la seguridad de los datos recabados, la proporcionalidad que debe regir acorde con la finalidad que justifica la recogida de la información personal o la veracidad y exactitud de los datos personales tratados, son principios que han de ser respetados y considerados como una de las piedras angulares de la materia que nos ocupa. El reconocimiento de los derechos ARCO (acceso, rectificación, cancelación y oposición) en relación con el tratamiento de datos de carácter personal es uno de los pilares fundamentales de la protección de datos personales, sin duda muy vincula- do al deber de información que en ocasiones los responsables de ficheros y trata- mientos no cumplen con la minuciosidad que establece la Ley. Junto a la aplicación de los aspectos mencionados, los responsables de ficheros y tratamientos de datos personales deberán tener en cuenta las obligaciones relacio- nadas con la implementación de medidas de seguridad de índole técnica y organizativa acordes con la información personal gestionada tanto en soportes V
  • 6. La protección de datos personales: Soluciones en entornos Microsoft automatizados como no automatizados y que de manera muy detallada regula el RLOPD. Otras cuestiones, como la autorregulación o los movimientos internacionales de datos, cuya ejecución requieren de la autorización previa del Director de la Agencia Española de Protección de Datos, salvo que se destinen a países que proporcionen un nivel adecuado de protección o se trate de los supuestos excepcionados que la propia LOPD establece, deberán igualmente ser tenidas en cuenta por los responsables de ficheros y tratamientos que pudieran verse involucrados en alguna de estas situaciones. El presente libro hace alusión a los diferentes procedimientos que la Agencia Española de Protección de Datos tramita y que el RD 1720/2007, de desarrollo de la LOPD, regula de manera muy detallada en relación con la notificación de los ficheros y tratamientos por parte de sus responsables, los vinculados a la tutela del ejercicio de los derechos ARCO, los posibles procedimientos sancionadores que pudieran iniciarse con motivo de la comisión de las infracciones tipificadas en la LOPD, así como otros procedimientos relacionados con la inscripción de códigos tipo, las solicitudes de autorización para realizar una transferencia internacional de datos y otros procedimientos más excepcionales relacionados con el deber de informar y la conservación de datos para fines específicos (históricos, estadísticos o científicos). El alto nivel de competencia que rige en determinados sectores del ámbito empresarial no debe ser, de ninguna manera, una licencia que permita olvidar la existencia de una información personal que, salvo las excepciones que la propia Ley establece, son los propios titulares de esos datos personales quienes deben decidir el uso, las aplicaciones, cesiones y finalidades que se les puede dar a los mismos. La actuación empresarial, conforme a lo regulado en la Ley, debe interpretarse como un valor añadido para la empresa y para su imagen, aportando una mayor calidad y una mejor gestión de sus recursos y, en ningún caso, el cumplimiento de la normativa vigente debe entenderse como un obstáculo de difícil superación. La entidades e instituciones a las que va dirigida la normativa de protección de datos no sólo deben colaborar en la defensa de los derechos de los ciudadanos, sino que además deben ser conscientes de que el cumplimiento de la Ley redundará en una mayor seguridad propia, de sus sistemas, de la información que registren, en ocasiones muy valiosa y cuya pérdida puede suponer una secuencia irreparable de daños económicos de gran envergadura. Por todo ello, la implementación de medidas de seguridad, de carácter técnico y organizativo, acorde con la información gestionada, debe ser una prioridad y un procedimiento incorporado al quehacer diario del ámbito empresarial. La aplicación de las nuevas tecnologías, en la sociedad en la que nos encontra- mos inmersos, debe tener en cuenta la existencia de distintas modalidades de tratamiento de la información personal que permitan identificar a una persona física, en todas sus variantes (dato identificativo, imagen, fotografía, dato biométrico, voz, etc.). VI
  • 7. Debemos ser conscientes de que en muchas ocasiones el incumplimiento de la Ley se debe a una falta de conocimiento y de información de las normas, derechos y procedimientos existentes. He de destacar que la Agencia Española de Protección de Datos, como autori- dad garante de este derecho fundamental, apoyará siempre iniciativas como la que en esta ocasión han impulsado entidades como Microsoft, Helas Consultores, IPSCA y Red.es, que avanzan en el camino de una mayor concienciación y difusión de la normativa de protección de datos de carácter personal, siempre desde la perspecti- va de la prevención e información. Artemi Rallo Director de la Agencia Española de Protección de Datos VII
  • 8. La protección de datos personales: Soluciones en entornos Microsoft Prólogo de Sebastián Muriel Actualmente asistimos a un cambio del uso social de la tecnología sin prece- dentes en la historia de la humanidad. Sería difícil tratar de entender este repentino aumento de la permeabilidad social hacia lo tecnificado, sin la ubicua presencia de las tecnologías de la información y de las comunicaciones (TIC) y de todos los servicios asociados a las mismas, hasta el punto de que lo que distingue a las economías avanzadas de las economías emergentes, es la intensidad en el uso de estas tecnologías. Gracias a importantes logros como el Plan Avanza, puesto en marcha por la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información en 2005, se puede decir que España está ya en posición de liderazgo en muchos de los indicadores que miden el uso de las TIC. Un uso que es creciente en todas las actividades y áreas que se nos puedan ocurrir: en el plano profesional, en la esfera del ocio (cada vez más interactivo y más digital, donde los contenidos digitales y las redes sociales juegan un papel cada vez más relevante), en las maneras de acceder a las noticias y a la información en los medios de comunicación, en la educación, en la sanidad, en la relación de los ciudadanos y empresas con las diferentes administraciones, pero además, sobre todo, en las maneras de relacionarnos unos con otros, con nuestras familias, amigos y conocidos. Es evidente que éste es el camino y que los esfuerzos realizados suponen una ventaja comparativa como país. En este entorno es importante educar y sensibilizar a los usuarios en el buen uso de las TIC. Porque la creciente expansión del mundo digital conlleva un reto a la gestión adecuada de la privacidad. Por eso estoy convencido de que iniciativas como la segunda edición de este manual realizado por Microsoft, van a servir, gracias a su carácter divulgativo, a mejorar el cumplimiento de la LOPD y que derivará en beneficios y ventajas de inmenso valor para la empresa y Administraciones Públi- cas, además de concienciar a todos los sectores (empresas, administraciones) y a los usuarios, especialmente a los más jóvenes, de que los datos personales son un bien que debe protegerse y, por ello, deben establecerse procedimientos, normas y medidas para conseguir tal fin. Sebastián Muriel. Director General de red.es. Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información VIII
  • 9. Autores El coordinador de los contenidos de esta obra es Héctor Sánchez Montenegro, National Technology Officer de Microsoft Ibérica, y los autores de este libro son: José María Alonso Cebrián de Informática 64, Microsoft MVP en el área de Seguridad. Juan Luís García Rambla de Informática 64, Microsoft MVP en el área de Seguridad. Antonio Soto. Director de Solid Quality. David Suz Pérez. Consultor de Microsoft Ibérica. José Helguero Sainz. Director General de Helas Consultores. Economista. Miembro de la Comisión de Seguridad de ASIMELEC. María Estrella Blanco Patiño, Responsable de publicaciones de Helas Consul- tores. Miguel Vega Martín, Director de Marketing de IPS Certification Authority. Miembro de la Comisión de Seguridad de ASIMELEC. Héctor Sánchez Montenegro. National Technology Officer de Microsoft Ibérica. IX
  • 10. La protección de datos personales: Soluciones en entornos Microsoft Agradecimientos Los autores quieren agradecer a las siguientes personas, quienes sin su inesti- mable colaboración, hubiera resultado mucho más difícil la edición de este libro:  Dña. María Garaña, Presidenta de Microsoft Ibérica.  D. Artemi Rallo, Director de la Agencia de Protección de Datos Española.  D. Sebastián Muriel, Director General de Red.es.  D. Alberto Amescua de Microsoft Ibérica, programa Technet.  D Fernando Bocigas de Microsoft Ibérica.  Dña. Barbara Olagaray de Microsoft Ibérica.  D. Luis Miguel García de la Oliva de Microsoft Ibérica.  D. Francisco Camina Álvarez. Gerente de Soluciones de Microsoft Ibérica.  D. Fernando García Varela. Director Comercial de Industria. De Microsoft Ibérica.  D. Rodolfo Lomascolo Szittyay, Director General de IPS Certification Authority, S.L.  D. Ignacio de Bustos Martín, Director General de Newcomlab S.L.L.  D. Manuel Sánchez Chumillas de Informática64.  Los técnicos de la “guarida del sótano” de Informática64.  Dña. María Martín Pardo de Vera, Responsable del Departamento de Consultoría de Helas Consultores.  Dña. Carmen de Prada Hernández, Responsable del Departamento de Instituciones de Helas Consultores.  Dña. María de la Rica Ortega, Responsable del Departamento de Auditoría de Helas Consultores.  Dña. Cristina Palomino Dávila, Consultora senior en el Departamento de Consultoría de Helas Consultores.  D. Miguel Prieto Quintana, Director Comercial de Helas Consultores.  D. María Rita Helguero Sainz, Directora de Administración de Helas Consultores.  Dña. Mónica Pujadó Coll, Directora Financiera de ipsCA.  Dña. Vera Sánchez - Carpintero Rodríguez, Responsable de Marketing Internacional ipsCA.  Dña. Irene Corral López, Departamento Marketing ipsCA.  Dña. Marta Corral López, Departamento Marketing ipsCA.  D. Guillermo Alcázar, Departamento Marketing ipsCA.  D. Alfonso Dominguez, Departamento Marketing ipsCA. X
  • 11. Índice de contenidos Introducción .............................................................................................. XVII Parte I Legal ................................................................................................... 1 1. Breve historia de la protección de datos de carácter personal ..................... 3 1.1. La protección de datos personales, un derecho fundamental .............. 4 2. Legislación vigente ........................................................................................... 7 2.1. Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) ................................................................. 7 2.2. Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (RLOPD) ..... 7 2.2.1. Plazos de adaptación ................................................................... 8 3. Datos de carácter personal ............................................................................. 11 3.1. Tipos de datos personales ..................................................................... 12 3.2. Novedades RLOPD en la aplicación de algunas medidas de seguridad (Artículo 81.5 y 81.6) ...................................................... 14 3.3. Otros datos personales .......................................................................... 15 4. Obligaciones básicas ...................................................................................... 17 4.1. Con carácter previo a la recogida de los datos .................................... 17 4.1.1. La creación y notificación de ficheros ....................................... 17 4.1.2. La calidad de los datos ............................................................... 25 4.1.3. La información al interesado ..................................................... 26 4.1.4. El consentimiento del interesado .............................................. 32 4.2. Durante el tratamiento de los datos ..................................................... 37 4.2.1. La calidad de los datos ............................................................... 37 4.2.2. El deber de secreto ..................................................................... 38 4.2.3. La seguridad de los datos .......................................................... 39 4.2.4. La cesión de los datos ................................................................ 54 4.2.5. El acceso a datos por cuenta de terceros ................................... 56 4.2.6. Prestaciones de servicios sin acceso a datos personales .......... 60 4.2.7. La modificación de ficheros ....................................................... 61 4.2.8. Las transferencias internacionales de datos .............................. 61 4.3. Una vez finalizado el tratamiento ........................................................ 63 4.3.1. La cancelación y el bloqueo de los datos .................................. 63 4.3.2. La supresión de ficheros ............................................................ 63 XI
  • 12. La protección de datos personales: Soluciones en entornos Microsoft 5. Los derechos de los titulares de los datos .................................................... 65 5.1. La impugnación de valoraciones ......................................................... 65 5.2. El derecho de consulta al Registro General de Protección de Datos .. 65 5.3. El derecho de indemnización ............................................................... 66 5.4. Los derechos ARCO .............................................................................. 66 5.4.1. El derecho de acceso .................................................................. 68 5.4.2. El derecho de rectificación ......................................................... 68 5.4.3. El derecho de oposición ............................................................. 69 5.4.4. El derecho de cancelación .......................................................... 70 5.5. La tutela de los derechos ...................................................................... 70 6. Tratamientos especiales ................................................................................. 73 6.1. Prestación de servicios de información sobre solvencia patrimonial y crédito ................................................................................................. 73 6.1.1. Requisitos para la inclusión de los datos .................................. 74 6.1.2. Información previa a la inclusión .............................................. 74 6.1.3. Notificación de la inclusión ....................................................... 74 6.1.4. Conservación de los datos ......................................................... 75 6.1.5. Acceso a la información contenida en el fichero ...................... 75 6.1.6. Responsabilidad ......................................................................... 75 6.1.7. Ejercicio de los derechos ARCO ................................................ 75 6.2. Tratamientos con fines de publicidad y de prospección comercial .... 76 6.2.1. Campañas publicitarias ............................................................. 77 6.2.2. Depuración de bases de datos ................................................... 77 6.2.3. Exclusión del envío de comunicaciones comerciales ............... 77 6.2.4. Ejercicio de derechos .................................................................. 78 6.3. Sistemas de videovigilancia ................................................................. 78 7. La autorregulación: los códigos tipo ............................................................. 81 7.1. Objeto de los códigos tipo .................................................................... 83 7.2. Naturaleza de los códigos tipo ............................................................. 83 7.3. Sujetos habilitados para la adopción de códigos tipo ......................... 83 7.4. Procedimiento para la elaboración de códigos tipo ............................ 84 7.5. Contenido de los códigos tipo .............................................................. 84 7.6. Ventajas derivadas de la creación de códigos tipo .............................. 87 7.7. Garantías del cumplimiento de los códigos tipo ................................. 88 7.8. Obligaciones posteriores a la inscripción del código tipo .................. 88 7.9. Códigos tipo inscritos ........................................................................... 89 XII
  • 13. 8. Infracciones y sanciones ................................................................................ 95 8.1. Los responsables ................................................................................... 95 8.2. Las infracciones: tipos ........................................................................... 95 8.2.1. Leves ........................................................................................... 95 8.2.2. Graves ......................................................................................... 96 8.2.3. Muy graves ................................................................................. 97 8.3. Prescripción ........................................................................................... 98 8.4. La infracción continuada ...................................................................... 98 8.5. Las sanciones ......................................................................................... 99 8.5.1. Las sanciones en el sector privado ............................................ 99 8.5.2. Las sanciones en el sector público ........................................... 101 8.6. El procedimiento sancionador ........................................................... 102 8.6.1. Procedimiento sancionador ..................................................... 102 8.6.2. Procedimiento de tutela de derechos ...................................... 103 9. Los órganos de control ................................................................................. 105 9.1. La Agencia Española de Protección de Datos (AEPD) ..................... 105 9.2. Las agencias de protección de datos de las comunidades autónomas ........................................................................................... 107 9.2.1. Agencia de Protección de Datos de la Comunidad de Madrid (APDCM) ............................................................... 107 9.2.2. Agencia Catalana de Protecció de Dades (APDCAT) ............ 107 9.2.3. Agencia Vasca de Protección de Datos (AVPD) ...................... 108 9.3. Conclusiones ....................................................................................... 108 Parte II Técnico ............................................................................................ 111 10. La seguridad en sistemas Microsoft ........................................................... 113 10.1. TrustWorthy Computing (TWC). La estrategia de Microsoft ........... 114 10.2. Soluciones seguras .............................................................................. 114 10.2.1.Seguridad en el diseño ............................................................. 115 10.2.2.Seguridad predeterminada ...................................................... 115 10.2.3.Seguridad en el despliegue ...................................................... 116 10.2.4.Comunicación ........................................................................... 117 10.3. ¿Que se ha conseguido con TWC? ..................................................... 117 10.3.1.Common Criteria ..................................................................... 118 10.3.2.Evaluación de FIPS 140 (Federal Information Processing Standard) ........................................................................................ 120 10.3.3.Iniciativa de recursos compartidos ......................................... 121 XIII
  • 14. La protección de datos personales: Soluciones en entornos Microsoft 10.3.4.Programa para la cooperación de la seguridad (SCP) ........... 122 10.3.5.Seminarios de seguridad ......................................................... 122 11. La aplicación del reglamento de seguridad en los sistemas Microsoft ... 123 11.1. Tecnología de seguridad en Microsoft Windows .............................. 124 11.2. Tecnologías aplicables a medidas de nivel básico ............................. 125 11.2.1. Ficheros temporales ................................................................. 126 11.2.2. Artículo 89. Funciones y obligaciones del personal ............... 127 11.2.3. Artículo 90. Registro de incidencias ........................................ 130 11.2.4. Artículo 91. Control de acceso (puntos 1 y 3) ......................... 130 11.2.5. Artículo 91. Control de acceso (punto 2) ................................. 145 11.2.6. Artículo 91. Control de acceso (puntos 4 y 5) ......................... 146 11.2.7. Artículo 92. Gestión de soportes y documentos ..................... 146 11.2.8. Artículo 93. Identificación y autenticación (puntos 1 y 2) ..... 153 11.2.9. Artículo 93. Identificación y autenticación (punto 3) ............. 165 11.2.10. Artículo 93. Identificación y autentificación (punto 4) ........ 167 11.2.11. Artículo 94. Copias de respaldo y recuperación .................. 169 11.3. Tecnología aplicable a medidas de nivel medio ................................ 174 11.3.1. Artículo 98. Identificación y autenticación ............................. 175 11.4. Tecnología aplicable a medidas de nivel alto .................................... 176 11.4.1. Artículo 101. Gestión y distribución de soportes ................... 177 11.4.2. Artículo 102. Copias de respaldo y recuperación ................... 177 11.4.3. Artículo 103. Registro de accesos ............................................ 178 11.4.4. Artículo 104. Telecomunicaciones ........................................... 215 11.4.5. Confidencialidad en Exchange 2007 ....................................... 218 12. La aplicación del reglamento de seguridad en SQL Server ..................... 223 12.1. Artículo 91. Control de acceso ............................................................ 223 12.2. Artículo 93. Identificación y autenticación ........................................ 225 12.3. Artículo 94. Copias de respaldo y recuperación ............................... 226 12.4. Artículo 98. Identificación y autenticación ........................................ 229 12.5. Artículo 101. Gestión y distribución de soportes .............................. 230 12.6. Artículo 103. Registro de accesos ....................................................... 231 12.6.1.Auditoría en SQL Server 2008 ................................................. 231 12.7. Artículo 104. Telecomunicaciones ...................................................... 232 13. Implementación de la LOPD sobre SQL Server (SQL Server 2005-2008) 235 13.1. Introducción ........................................................................................ 235 13.2. Objetivos del documento .................................................................... 235 13.3. Ejemplo teórico ................................................................................... 236 XIV
  • 15. 13.4. Requisitos ............................................................................................ 237 13.5. Implementación .................................................................................. 238 13.5.1.Implementación del proceso de Registro de Accesos ............ 238 13.5.2.Acceso a la información de Registro de Accesos .................... 245 13.5.3.Recomendaciones en casos especiales .................................... 248 13.6. Rendimiento ........................................................................................ 248 13.6.1.Sobrecarga del proceso de traza .............................................. 248 13.6.2.Almacenamiento físico de los ficheros de traza ..................... 250 13.7. Nuevas características en SQL Server 2008 ....................................... 251 13.8. Apéndices ............................................................................................ 252 13.8.1.Implementación de trazas sobre SQL Server 2005 ................. 252 13.8.2.Posibilidades de Backup y Restore en SQL Server 2005 ........ 253 13.8.3.Seguridad en SQL Server 2005 ................................................ 253 13.8.4.Seguridad en SQL Server 2008 ................................................ 253 14. Política de seguridad .................................................................................... 255 14.1. Introducción ........................................................................................ 255 14.2. Fases fundamentales ........................................................................... 255 14.2.1.Fase 1. Organización y análisis ................................................ 256 14.2.2.Fase 2. Desarrollo de un estudio sobre las necesidades de privacidad ............................................................................ 258 14.2.3.Fase 3. Evaluación de las necesidades tecnológicas para la protección de la privacidad ................................................. 260 Parte III Anexos ............................................................................................. 263 Anexo A. Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal ................................................................................. 265 Anexo B. Real decreto por el que se aprueba el reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal .................................................................................................... .. 295 Glosario de términos ........................................................................................... 383 XV
  • 16. La protección de datos personales: Soluciones en entornos Microsoft XVI
  • 17. I Introducción El Tribunal Constitucional, en su sentencia 292/2000, define la Protección de Datos de Carácter Personal como el derecho fundamental que garantiza a toda persona “un poder de control sobre sus datos personales, sobre su uso y destino, con el propósito de impedir su tráfico ilícito y lesivo para la dignidad y derecho del afectado”. La automatización del tratamiento de datos, fruto de la aplicación y desarrollo de la informática, proporciona numerosas ventajas, aumentando la productividad y la competitividad, tanto de las personas como de las empresas. Los beneficios sobrepasan con mucho los problemas que se derivan del tratamiento de datos personales, pero debemos de poner límite al grado de intrusión en nuestra intimi- dad que las nuevas tecnologías pueden generar. La legislación sobre protección de datos establece esos límites y, por ello, afecta a todas las empresas y organismos públicos de nuestro país, porque todos -en mayor o menor medida- manejan datos de carácter personal de personas físicas (empleados, clientes, proveedores, accionistas, colaboradores…). Así pues, todos ellos deben adecuarse a la legislación actual sobre protección de datos contemplan- do una doble perspectiva: por un lado, el respeto a los derechos de los ciudadanos y, por otro, su funcionamiento interno y la seguridad de su información. Hoy en día la actividad empresarial y pública no se concibe sin el apoyo de la informática, ya que gracias a programas y aplicaciones (software) podemos manejar un gran volumen de datos. Por tanto, no son discutibles las enormes ventajas de la informática. Sin embargo, también es cierto que ésta puede conllevar cierta peligro- sidad si se hace un mal uso de ella. Pensemos en la cantidad de información que se puede obtener de una persona si miramos sus movimientos bancarios: podemos saber qué tipo de restaurantes le gustan, a qué tipo de colegio lleva a sus hijos, dónde va de vacaciones, sus gustos y aficiones, qué deporte practica, si es una XVII
  • 18. La protección de datos personales: Soluciones en entornos Microsoft persona solvente, etc. Este conocimiento ordenado de los datos puede arrojar un perfil de la persona, que quizás ni ésta misma conoce, y que puede ser utilizado, favorable o desfavorablemente, para todo tipo de actividades, como es, por ejem- plo, la selección de personal. No debemos tampoco olvidar los ficheros y los trata- mientos en formato papel, que adquieren una especial importancia con el Nuevo Reglamento aprobado mediante el Real Decreto 1720/2007 (RLOPD). Por ello, ha sido necesario establecer una serie de mecanismos que protejan al individuo de este tipo de actuaciones. La legislación actual desarrolla una serie de obligaciones que las empresas deben cumplir, y el objetivo de este libro es describir- las y facilitar a los responsables de ficheros y tratamientos la comprensión y el alcance de dichas obligaciones. Cualquier empresa o institución que tenga, mantenga, utilice o trate datos de carácter personal, en soporte informático o papel, se encuentra obligada al cumpli- miento de la normativa vigente en materia de protección de datos; por tanto, en la práctica todas las empresas e instituciones. Pero además debemos tener en cuenta que la normativa aplicable protege al titular de los datos en cada una de las fases que conlleva la utilización de los mis- mos en una empresa, y que son básicamente tres: 1. Con carácter previo a la recogida de los datos. 2. Durante el tratamiento de los datos. 3. Una vez finalizado el tratamiento. Por tanto, podemos concluir que las obligaciones de las organizaciones no se reducen a un momento en concreto; sino que el cumplimiento con la legislación es un proceso permanente que afecta a la actividad que desarrollan de manera cons- tante. Las preguntas que siempre se hace el responsable de los ficheros cuando se le plantea la necesidad de adecuar su organización a una nueva legislación son: ¿Qué beneficio obtengo de esa adecuación?, ¿No es otra vez un gasto de dinero inútil? El caso de la Protección de Datos de Carácter Personal no es ajeno a este tipo de preguntas. Como premisa importante hay que tener en cuenta que la adaptación a la legislación en materia de Protección de Datos de Carácter Personal no es, en ningún caso, un problema del departamento de Informática o de Sistemas. Para que una empresa tenga éxito en dicha adaptación debe implicar a todos los departamentos de la compañía, y si este proceso se afronta únicamente como un problema informático, el fracaso está asegurado. Las cinco principales causas por las que una empresa debe adaptarse a la legislación en materia de Protección de Datos de Carácter Personal son: XVIII
  • 19. Introducción 1. Cumplir con la legislación vigente: la adecuación a la realidad normativa es cada vez más un requisito del mercado para llevar a buen fin nuestros negocios. Las administraciones públicas y nuestros clientes demandan el cumplimiento de la legislación vigente, y el cumplimiento en materia de Protección de Datos se está ya exigiendo como un requisito indispensable en grandes áreas de negocio (informática, publicidad, sanidad, etc.). 2. Evitar sanciones de la Agencia Española de Protección de Datos (AEPD): éstas, las más elevadas de la Unión Europea, varían desde los 601,01 a los 601.012,10 €, como analizaremos más adelante en este libro. 3. Evitar el deterioro de la imagen pública: la publicación en prensa de noticias relacionadas con de la aparición en la vía pública de expedientes médicos abandonados o de currículos con anotaciones xenófobas como resultado de la selección de personal de un supermercado, causan un enorme perjuicio para los responsables de esos ficheros, que en muchas ocasiones es mayor que la sanción impuesta posteriormente por la AEPD. 4. Gestionar la información en la empresa: la adaptación a la normativa en materia de Protección de Datos ayuda a iniciar una gestión moderna de la información dentro de la empresa. La empresa española tiene en la gestión de la información una asignatura pendiente y la implementación de las normas a que nos obliga la protección de datos es, en la mayoría de los casos, el inicio de la concienciación y de la toma de medidas destinadas a la salvaguarda de uno de los mayores activos de la empresa moderna: la información. 5. Mejorar la gestión de la calidad: la integración de las medidas a implementar en materia de protección de datos en todos los departamen- tos de la empresa, debe realizarse como un proceso de mejora de nuestros sistemas de trabajo, y nunca como una traba o impedimento. Concebir la protección de datos como un proceso más dentro de la calidad de la empresa es vital para el éxito de nuestra adaptación a la LOPD y es por ello que debemos implicar a las fuerzas vivas de la empresa (Dirección, Administración, Recursos Humanos, Marketing, Informática, Comercial, Calidad, etc.), y en especial debemos tener en cuenta el factor humano, donde la formación debe tener un papel muy relevante. XIX
  • 20. XX
  • 21. Parte I Legal 1. Breve historia de la protección de datos de carácter personal 3 2. Legislación vigente 7 3. Datos de carácter personal 11 4. Obligaciones básicas 17 5. Los derechos de los titulares de los datos 65 6. Tratamientos especiales 73 7. La autorregulación: los códigos tipo 81 8. Infracciones y sanciones 95 9. Los órganos de control 105
  • 22. La protección de datos personales: Soluciones en entornos Microsoft 2
  • 23. 1 Breve historia de la protección de datos de carácter personal La evolución de la informática, que ha facilitado la gestión masiva de la información relativa a las personas, ha supuesto que se genere un nuevo derecho de las personas a la protección de los datos de carácter personal, que se ha desarrollado en un tiempo récord. Antes de adentrarnos en la evolución de la protección de datos en nuestro país, debemos hacer referencia a tres importantes declaraciones internacionales en las que se ha reconocido el derecho a la intimidad y a la protección de datos de carácter personal. Como punto de partida, el artículo 12 de la Declaración Universal de Derechos Humanos1 establece lo siguiente: “Nadie será objeto de injerencias arbitrarias en su vida privada, su familia, su domicilio o su correspondencia, ni de ataques a su honra o reputación. Toda persona tiene derecho a la protección de la ley contra tales injerencias o ataques”. Dos años después, el Convenio Europeo para la Protección de los Derechos Humanos y Libertades Fundamentales del Consejo de Europa 2 establece en su artículo 8: “Toda persona tiene derecho al respeto de su vida privada y familiar, de su domicilio y de su correspondencia”. 1. Proclamada por la Asamblea General de las Naciones Unidas el 10 de septiembre de 1948. 2. Firmado en Roma por el Consejo de Europa el 4 de noviembre de 1950. 3
  • 24. La protección de datos personales: Soluciones en entornos Microsoft En tercer lugar, el Convenio 108 del Consejo de Europa3 establece en su artículo 1: “…garantizar… a cualquier persona física… el respeto de sus derechos y libertades fundamentales, concretamente su derecho a la vida privada, con respecto al trata- miento automatizado de los datos de carácter personal correspondientes a dicha persona”. En España, la Ley Orgánica 5/1992, de 29 de octubre, de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal (LORTAD), desarrolla lo recogido en el artículo 18 de la Constitución Española de 1978 y establece, por primera vez, la limitación del uso de la informática para garantizar la intimidad personal. Posteriormente, la Directiva 95/46/CE del Parlamento Europeo y del Consejo de 24 de octubre de 1995 relativa a la Protección de las Personas Físicas en lo que respecta al Tratamiento de Datos Personales y a la libre circulación de estos datos (Directiva 95/46/CE), establece el marco jurídico en el que se desarrolla la actual legislación española en Protección de Datos de Carácter Personal. La LORTAD tardó siete años en disponer de su desarrollo reglamentario, que llegó con el Real Decreto 994/1999, de 11 de junio: Reglamento de Medidas de Seguridad de los Ficheros Automatizados que contengan Datos de Carácter Perso- nal (RMS). Pocos meses después de la aprobación de dicho reglamento se promulgó la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD), vigente en la actualidad, y que adapta la legislación española a la Directiva europea, desarrollando la protección de datos más allá de los datos informatizados, incluyendo dentro de su ámbito de aplicación los datos de carácter personal registrados en soporte físico, que los haga susceptibles de tratamiento automatizado o no, y toda modalidad de uso de los mismos. Por fin, la LOPD, tras un periodo de ocho años conviviendo con el RMS, ha visto cómo su desarrollo reglamentario ha sido plasmado mediante el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (RLOPD). 1.1. La protección de datos personales, un derecho fundamental Si bien durante muchos años ha habido muchas y enfrentadas fuentes doctrinales que discutían si el derecho a la protección de datos es un derecho independiente o se encuentra enmarcado dentro de la esfera del derecho a la intimidad, la Sentencia del Tribunal Constitucional 292/2000 expone en su fundamento jurídico 7: 3. Firmado en Estrasburgo el 28 de enero de 1981. 4
  • 25. Breve historia de la protección de datos de carácter personal “…el contenido del derecho fundamental a la protección de datos consiste en un poder de disposición y de control sobre los datos personales que faculta a la persona para decidir cuáles de estos datos proporcionar a un tercero, sea el Estado o un particular, o cuáles puede este tercero recabar, y que también permite al individuo saber quién posee esos datos personales y para qué, pudiendo oponerse a esa posesión o uso…”. Así mismo, expone que este derecho se concreta en: “…la facultad de consentir la recogida, la obtención y el acceso a los datos persona- les, su posterior almacenamiento y tratamiento, así como su uso o usos posibles, por un tercero, sea el Estado o un particular…” y considera indispensable para hacer efectivo este derecho: “…el reconocimiento del derecho a ser informado de quién posee sus datos persona- les y con qué fin, y el derecho a poder oponerse a esa posesión y uso requiriendo a quien corresponda que ponga fin a la posesión y empleo de los datos”. Por tanto, el derecho a la protección de datos es un derecho independiente porque se protege cualquier dato de carácter personal que identifique a la persona, y no sólo los datos de su esfera íntima. 5
  • 26. La protección de datos personales: Soluciones en entornos Microsoft 6
  • 27. 2 Legislación vigente 2.1. Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) Es la Ley vigente en la actualidad y que adapta la legislación española a la Directiva europea. Su ámbito de aplicación comprende todos los ficheros que contengan datos de carácter personal, con independencia de que se trate de ficheros automatizados o en formato papel. Incluye como otras novedades principales la definición del Encargado del Tratamiento, la regulación de los tratamientos de datos y las relaciones entre Responsable del Fichero y Encargado del Tratamiento, la definición de fuentes accesibles al público, el censo promocional e incorpora el nuevo derecho de oposición. 2.2. Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (RLOPD) El RLOPD (que entró en vigor el día 19 de abril de 2008) desarrolla la LOPD y consolida la doctrina reguladora establecida por la AEPD en sus instrucciones y expedientes sancionadores, así como la interpretación que de la LOPD han efectua- do los Tribunales a través de la jurisprudencia. El RLOPD incrementa la protección ofrecida a los datos de carácter personal, pero, por otra parte, establece ciertas especialidades para facilitar la implantación de medidas de seguridad, que inciden sobre todo en el ámbito de las PYMES. Este nuevo Reglamento, que sustituye al RMS 994/99, establece, entre otras cosas, las medidas de seguridad para los ficheros no automatizados, regula las 7
  • 28. La protección de datos personales: Soluciones en entornos Microsoft relaciones entre el Responsable del Fichero y el Encargado del Tratamiento (permi- tiendo además la subcontratación), introduce novedades importantes con respecto a los ficheros sobre solvencia patrimonial y crédito y respecto al ejercicio de derechos, así como otras novedades que se desarrollan en detalle en este libro más adelante. Las infracciones, sanciones o cuantía de las multas no se han modificado, pero sí se ha introducido, con respecto a las actuaciones previas al Procedimiento Sancionador de la AEPD, un límite temporal de doce meses a contar desde la fecha de la denuncia. El vencimiento del plazo sin que se haya dictado y notificado el acuerdo de inicio de procedimiento sancionador producirá la caducidad de las actuaciones previas. 2.2.1. Plazos de adaptación La Disposición transitoria segunda del RLOPD recoge los plazos de implanta- ción de las medidas de seguridad con arreglo a las siguientes reglas: 2.2.1.1. Respecto de los ficheros automatizados que existieran en la fecha de entrada en vigor del RLOPD (19 abril 2008): a) En el plazo de un año desde su entrada en vigor (19 de abril de 2009), deberán implantarse las medidas de seguridad de nivel medio exigibles a los siguientes ficheros:  Aquéllos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias.  Aquéllos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social.  Aquéllos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. b) En el plazo de un año (19 de abril de 2009) deberán implantarse las medidas de seguridad de nivel medio a aquéllos de los que sean responsa- bles los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas respecto a los datos de tráfico y a los datos de localización. c) En el plazo de dieciocho meses (19 de octubre de 2009) las de nivel alto exigibles a los ficheros que contengan datos derivados de actos de violen- cia de género. d) En los demás supuestos, cuando el RLOPD exija la implantación de una medida adicional no prevista en el RMS. Dicha medida deberá implantar- se en el plazo de un año (19 de abril de 2009). 8
  • 29. Legislación vigente 2.2.1.2. Respecto de los ficheros no automatizados que existieran en la fecha de entrada en vigor del RLOPD: a) Las medidas de seguridad de nivel básico deberán implantarse en el plazo de un año desde su entrada en vigor (19 de abril de 2009). b) Las medidas de seguridad de nivel medio deberán implantarse en el plazo de dieciocho meses desde su entrada en vigor (19 de octubre de 2009). c) Las medidas de seguridad de nivel alto deberán implantarse en el plazo de dos años desde su entrada en vigor (19 de abril de 2010). 2.2.1.3. Respecto de los ficheros creados con posterioridad a la fecha de entrada en vigor del RLOPD: Los ficheros, tanto automatizados como no automatizados, creados con poste- rioridad a la fecha de entrada en vigor del RLOPD deberán tener implantadas, desde el momento de su creación, la totalidad de las medidas de seguridad regula- das en el mismo. 9
  • 30. La protección de datos personales: Soluciones en entornos Microsoft 10
  • 31. 3 Datos de carácter personal El artículo 2.a de la Directiva 95/46/CE, relativa a la protección de las perso- nas físicas en lo que respecta al tratamiento de datos personales y a la libre circula- ción de esos datos, define el dato personal del siguiente modo: “ toda información sobre una persona identificada o identificable (...) se considerará identificable toda persona, directa o indirectamente, en particular mediante un número de identificación o uno o varios elementos específicos, característicos de su identidad física, fisiológica, psíquica, económica, cultural o social”. El artículo 3 de la LOPD utiliza una definición muy genérica de Datos de Carácter Personal: “cualquier información concerniente a personas físicas identificadas o identificables”. Esta definición ha sido ampliada por el artículo 5 del RLOPD al referirse a los mismos como: “cualquier información numérica, alfabética, gráfica, fotográfica, acústica o de cualquier otro tipo concerniente a personas físicas identificadas o identificables”. Asimismo, el RLOPD ha incluido en el Glosario de Términos la definición de persona identificable, entendiendo como tal: “toda persona cuya identidad pueda determinarse, directa o indirectamente, mediante cualquier información referida a su identidad física, fisiológica, psíquica, económica, cultural o social. Una persona física no se considerará identificable si dicha identificación requiere plazos o actividades desproporcionados”. Aun así, el término sigue siendo poco preciso. 11
  • 32. La protección de datos personales: Soluciones en entornos Microsoft 3.1. Tipos de datos personales Una vez que la organización ha comprobado que tiene datos personales, hay que clasificarlos en función de su tipología, pues no es lo mismo tratar datos mera- mente identificativos (nombre y apellidos, teléfono, dirección...), que tratar datos que puedan comprometer a la persona (enfermedades, deudas, orientación sexual...). Esta clasificación determinará el nivel de medidas de seguridad que posteriormente tenemos que aplicar a los ficheros. Legalmente, hay varios tipos de datos personales y la clasificación se puede llevar a cabo según dos criterios: 1. Según su importancia: clasifica a los datos personales en función de la relación que tienen esos datos personales con el derecho a la intimidad. Hay datos personales especialmente protegidos que están recogidos en los artículos 7 y 8 de la LOPD: los referidos a la ideología, religión, creencias, afiliación sindical, origen racial o étnico, salud, vida sexual, y comisión de infracciones penales o administrativas. El RLOPD (Art. 81.3.c) considera que también deben aplicarse medidas de seguridad de nivel Alto a los datos derivados de actos de violencia de género. Al resto de datos perso- nales no se les concede una protección especial. 2. Según su seguridad: la clasificación se realiza basándose en las medidas de seguridad que se deben cumplir cuando se posean datos personales, y existen tres niveles (Art. 81 RLOPD):  Datos de nivel Básico: Son aquellos datos personales que no se clasifican como de nivel Medio o de nivel Alto.  Datos de nivel Medio:  Los relativos a la comisión de infracciones administrativas o penales.  Los relativos a prestación de servicios de información sobre solvencia patrimonial y crédito.  Aquellos de los que sean responsables Administraciones tributarias y se relacionen con el ejercicio de sus potestades tributarias.  Aquellos de los que sean responsables las entidades financieras para finalidades relacionadas con la prestación de servicios financieros.  Aquellos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. De igual modo, aquellos de los que sean responsables las mutuas de accidentes de trabajo y enferme- dades profesionales de la Seguridad Social. 12
  • 33. Datos de carácter personal  Aquellos que contengan un conjunto de datos de carácter perso- nal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determi- nados aspectos de la personalidad o del comportamiento de los mismos.  Datos de nivel Alto:  Los que se refieran a datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual.  Los que contengan o se refieran a datos recabados para fines policiales sin consentimiento de las personas afectadas.  Aquellos que contengan datos derivados de actos de violencia de género. Datos de nivel Básico Datos de nivel Medio Datos de nivel Alto  Identificativos.  Hacienda Pública.  Salud.  Características persona-  Los de las Administracio-  Vida sexual. les. nes tributarias relaciona- Ideología. dos con el ejercicio de sus  Circunstancias sociales. potestades tributarias.   Creencias.  Académicos y profesiona- Los de las Entidades les.   Afiliación sindical. Gestoras y Servicios Comunes de la Seguridad Religión. Empleo y puestos de   trabajo. Social y se relacionen con  Violencia de género. el ejercicio de sus  Información comercial. competencia s.  Económico-financieros.  Los de las mutuas de  Transacciones. accidentes de trabajo y enfermedades profesiona- les de la Seguridad Social.  Servicios financieros.  Solvencia patrimonial y crédito.  Infracciones penales y administrativas.  Los que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. 13
  • 34. La protección de datos personales: Soluciones en entornos Microsoft 3.2. Novedades RLOPD en la aplicación de algunas medidas de seguridad (Artículo 81.5 y 81.6) Los departamentos de RR.HH suelen tener ficheros a los que hay que aplicar las medidas de seguridad de nivel alto ya que se pueden recoger datos de Nivel Alto, como Afiliación sindical (por ejemplo, para cómputos de horas sindicales, pago de la cuota en el sindicato correspondiente, etc.) o de Salud (por ejemplo, datos de minusvalías a efectos de practicar las retenciones en el IRPF, reconocimien- tos médicos, etc.). Ahora bien, en algunos casos puntuales, aunque esos datos se sigan conside- rando de Nivel Alto, pueden concurrir determinadas circunstancias que permiten adoptar las medidas de Nivel Básico:  Los ficheros o tratamientos de datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual cuando: a) los datos se utilicen con la única finalidad de realizar una transferen- cia dineraria a las entidades de las que los afectados sean asociados o miembros. b) se trate de ficheros o tratamientos no automatizados en los que de forma incidental o accesoria se contengan aquellos datos sin guardar relación con su finalidad.  Los ficheros o tratamientos que contengan datos relativos a la salud, referentes exclusivamente al grado de discapacidad o la simple declara- ción de la condición de discapacidad o invalidez del afectado, con motivo del cumplimiento de deberes públicos. Datos de salud Como consecuencia de ello, los datos relativos a una minusvalía siguen siendo datos relativos a la salud (es decir, datos de nivel alto), pero se permite adoptar medidas de seguridad de Nivel Básico cuando su uso se encuentre afectado o vinculado al cumplimiento de deberes públicos. Los supuestos más habituales en relación con los ficheros de nóminas son:  Cuando aparece un porcentaje de minusvalía para calcular el nivel de retención aplicable en nómina.  Cuando contienen información relativa a apto/no apto de un reconocimien- to médico, discapacidad (sí o no), invalidez, incapacidad laboral (sí o no y fecha), enfermedad común, accidente laboral o enfermedad profesional. Si, por el contrario, se describe, por ejemplo, la enfermedad o situación de salud concreta que la causa, o se incluye un código numérico que permita estable- cerla, hay que aplicar el Nivel Alto. 14
  • 35. Datos de carácter personal Datos relativos a la afiliación sindical Aunque siguen siendo datos de Nivel Alto, se pueden proteger únicamente con medidas de seguridad de Nivel Básico cuando se utilicen exclusivamente para realizar la detracción de la cuota sindical o la domiciliación bancaria. Por el contrario, si contiene, por ejemplo, datos de aquellos afiliados a un sindicato que han disfrutado de las llamadas “horas sindicales”, hay que aplicar el Nivel Alto. 3.3. Otros datos personales La AEPD a través de sus Resoluciones ha ido concretando qué debe entenderse por Datos de Carácter Personal, disipando dudas y ampliando los conceptos, por lo que también deberemos considerar Datos Personales los siguientes:  La imagen (fija o grabación de vídeo): “…la grabación de la imagen de una persona, ya sea trabajador o no de la empresa, es un dato personal, siendo éste el criterio de la Agencia Española de Protección de Datos…” (Resolución R/ 00035/2006, Cuestiones Generales sobre Videovigilancia).  Datos biométricos (huella, iris, etc.): “los datos biométricos tenían la condición de datos de carácter personal y que, dado que los mismos no contienen ningún aspecto concreto de la personalidad, limitando su función a identificar a un sujeto cuando la información se vincula con éste, su tratamiento no tendrá mayor trascendencia que el de los datos relativos a un número de identificación personal, a una ficha que tan solo pueda utilizar una persona o a la combinación de ambos”. (Tratamiento de la huella digital de los trabajadores. Informe AEPD 1/ 1999.)  La dirección de correo electrónico: “…no existe duda de que la dirección de correo electrónico identifica, incluso de forma directa, al titular de la cuenta, por lo que en todo caso dicha dirección ha de ser considerada como dato de carácter personal”. (Cribado de correo electrónico. Informe Jurídico 0391/2007.)  La dirección IP: “…las direcciones IP tanto fijas como dinámicas, con indepen- dencia del tipo de acceso, se consideran datos de carácter personal resultando de aplicación la normativa sobre protección de datos”. (Carácter de dato personal de la dirección IP. Informe AEPD 327/2003.) El artículo 5 del RLOPD también define como Persona Identificable a toda persona cuya identidad pueda determinarse, directa o indirectamente, mediante cualquier información referida a su identidad física, fisiológica, psíquica, económi- ca, cultural o social. Una persona física no se considerará identificable si dicha identificación requiere plazos o actividades desproporcionados. Por ello, cualquier dato que permita identificar a una persona deberá considerarse Dato Personal, y su nivel se establecerá en cada caso dependiendo de la tipología del dato y de la finalidad del fichero. 15
  • 36. La protección de datos personales: Soluciones en entornos Microsoft Por otra parte, el RLOPD no se aplica a: 1. Tratamientos de datos referidos a personas jurídicas. 2. Ficheros que se limiten a incorporar datos de personas físicas que presten sus servicios en aquéllas (nombre y apellidos, las funciones o puestos desempeñados, dirección postal o electrónica, teléfono y número de fax profesionales). 3. Datos relativos a empresarios individuales, cuando hagan referencia a ellos en su calidad de comerciantes, industriales o navieros. 4. Datos referidos a personas fallecidas. 16
  • 37. 4 Obligaciones básicas En este apartado haremos una exposición de las obligaciones principales que la normativa de protección de datos impone a los responsables de los ficheros de datos de carácter personal y demás personas que intervienen en algún momento en el tratamiento de los mismos. Para ello, y con el objetivo de aportar una visión práctica en su desarrollo, hemos dividido el transcurso del tratamiento de los datos en tres momentos princi- pales:  con carácter previo a la recogida de los datos,  durante el tratamiento de los datos y  una vez finalizado el tratamiento. De este modo, analizaremos cada una de las obligaciones, ubicándolas en el momento en el que deben ser tenidas en cuenta para una correcta aplicación de la normativa de protección de datos, ya que la propia LOPD establece en qué punto del tratamiento deben ser apreciadas unas y otras. 4.1. Con carácter previo a la recogida de los datos 4.1.1. La creación y notificación de ficheros ¿Qué es un fichero de datos de carácter personal? Debemos comenzar analizando qué es un fichero de datos de carácter personal y qué se entiende como tal a efectos de notificación. La definición legal de fichero se encuentra recogida en el artículo 3.b) de la LOPD que se expresa en los siguientes términos: 17
  • 38. La protección de datos personales: Soluciones en entornos Microsoft “todo conjunto organizado de datos de carácter personal, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso”, definición que ha sido desarrollada por el RLOPD, en su artículo 5.1.k), quedando finalmente como: “todo conjunto organizado de datos de carácter personal, que permita el acceso a los datos con arreglo a criterios determinados, cualquiera que fuere la forma o modali- dad de su creación, almacenamiento, organización y acceso”. Nos encontramos ante una definición de carácter genérico y que puede resul- tar tan amplia que en la práctica no ha sido de gran ayuda, creando incluso confu- sión en numerosas ocasiones en las que, atendiendo a la misma, no queda claro si nos encontramos ante un fichero protegido por la normativa de protección de datos personales y que, por consiguiente, debe ser declarado ante la AEPD para su ins- cripción en el RGPD o, por el contrario, podríamos estar ante varios ficheros cuya declaración debe hacerse de forma independiente. Dentro de esta definición pode- mos englobar muchos términos utilizados habitualmente, tales como base de datos, aplicación, programa, tabla, fichero... -en relación con el tratamiento informatizado-, o cajonera, armario, archivo... -si nos referimos a tratamientos no informatizados, sino manuales-. Estos términos vienen a identificar los denominados ficheros físicos. Frente a estos, existen los llamados ficheros lógicos, que podemos definir como ficheros o conjunto de ficheros físicos que contienen el mismo tipo de datos y son tratados para la misma finalidad. La AEPD ha considerado que sólo los ficheros lógicos son objeto de declara- ción. Esto significa que, una vez identificados los ficheros físicos, el responsable de los mismos podrá agruparlos en ficheros lógicos atendiendo a los criterios indica- dos. Así por ejemplo, en una empresa pueden existir diversos ficheros físicos con datos de clientes (datos bancarios, gestión de la relación comercial, marketing, gestión de impagados). Todos estos tienen datos de clientes y comparten la finali- dad consistente en gestionar la relación con los mismos, de manera que se pueden agrupar en un único fichero lógico y declararse ante la AEPD, por ejemplo, bajo el nombre de clientes. El concepto anteriormente indicado puede matizarse aún más teniendo en cuenta lo establecido en el artículo 2.c) de la Directiva 95/46/CE, dado que el mismo aclara la referencia a la forma de creación, almacenamiento, organización y acceso del fichero al indicar que el conjunto de datos tendrá esa consideración “ya sea centralizado, descentralizado o repartido de forma funcional o geográfica”. En cuanto al reparto geográfico, podemos afirmar que el concepto de fichero no va directamente vinculado a la exigencia de que el mismo se encuentre en una única ubicación. Es posible la existencia de ficheros distribuidos en lugares geográfi- cos remotos entre sí, siempre y cuando la organización y sistematización de los datos responda a un conjunto organizado y uniformado de datos, sometido a algún tipo de gestión centralizada. 18
  • 39. Obligaciones básicas La AEPD se ha pronunciado en este sentido a través de un informe jurídico4 emitido en respuesta a una consulta planteada por una entidad que disponía de diversos centros, ubicados en distintos lugares y carentes de personalidad jurídica propia, disponiendo de información sometida a tratamiento similar repartida en ficheros idénticos y alojada en servidores diferentes, dada su ubicación en los distintos centros, pero administrados y gestionados de forma centralizada. En relación con este tema, el RLOPD -artículo 56- viene a aclarar que: “la notificación de un fichero de datos de carácter personal es independiente del sistema de tratamiento empleado en su organización y del soporte o soportes emplea- dos para el tratamiento de los datos” y que “cuando los datos de carácter personal objeto de tratamiento estén almacenados en diferentes soportes, automatizados y no automatizados, o exista una copia en soporte no automatizado de un fichero automati- zado, sólo será preciso una sola notificación, referida a dicho fichero”. La creación de ficheros de datos de carácter personal. Lo primero que debemos pensar si deseamos crear un fichero que contenga datos personales, es que tenemos que enfrentarnos a un requisito, establecido en el artículo 25 de la LOPD, en virtud del cual es imprescindible que el fichero “resulte necesario para el logro de la actividad u objeto legítimos de la persona, empresa o entidad titular y se respeten las garantías que esta Ley establece para la protección de las personas”. Si bien, del respeto de las garantías establecidas en la LOPD iremos hablando a lo largo de todo este apartado, debemos analizar antes de seguir adelante el signifi- cado de la expresión “[...] resulte necesario para el logro de la actividad u objeto legítimos [...]”. Dicha “necesidad”, con frecuencia viene establecida o se deriva del cumpli- miento de la legislación aplicable a la actividad u objeto desarrollados por el res- ponsable, tanto en términos generales como fruto de alguna norma sectorial. De ahí que algunos ficheros resultan imprescindibles para el desarrollo de cualquier actividad u objeto legitimo (ya sea empresarial, comercial, profesional...) y otros resultan específicos de cada sector. Incluso, al margen de los ficheros creados por imposición, cualquier persona, empresa o entidad, puede sentir la necesidad de crear ficheros con distintas finalidades, pero para su creación siempre ha de haber una justificación directamente vinculada a la actividad u objeto legítimos, sin existir limitación alguna en relación con el número de ficheros inscribibles. En este orden de cosas, podemos poner como ejemplos más claros en los que se cumple este primer requisito para la creación de ficheros, aquellos en los que la necesidad de su creación es consecuencia directa del cumplimiento de una Norma que el titular debe aplicar para el desarrollo de su actividad u objeto legítimos, de lo que no cabe duda en ficheros como los que se describen a continuación: A. Los ficheros tradicionalmente denominados personal, empleados, gestión laboral..., permiten llevar a cabo la gestión laboral de la actividad desarro- 4. Vid. AEPD, Informe Jurídico 368/2003 Inscripción de ficheros situados en múltiples ubicacio-nes, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/inscripcion_ficheros/common/pdfs/2003- 0368_Inscripci-oo-n-de-ficheros-situados-en-m-uu-ltiples-ubicaciones.pdf. 19
  • 40. La protección de datos personales: Soluciones en entornos Microsoft llada por el responsable del fichero, así como un control detallado de las cuestiones relativas al personal laboral. En este sentido, la Ley 42/1997, de 14 de noviembre, Ordenadora de la Inspección de Trabajo y Seguridad Social, hace referencia a la conservación de información del personal laboral por parte del empleador, al disponer en su artículo 11 que “toda persona natural o jurídica estará obligada a proporcionar a la Inspección de Trabajo y Seguridad Social toda clase de datos, antecedentes o información con trascendencia en los cometidos inspectores, siempre que se deduzcan de sus relaciones económicas, profesionales, empresariales o financieras con terceros sujetos a la acción inspectora, cuando a ello sea requerida en forma”. B. Otros de los ficheros más habitualmente declarados por los responsables son los denominados gestión fiscal y contable, gestión económica, factura- ción... No cabe duda de la necesidad de estos ficheros para el logro de la actividad legítima de cualquier actividad económica. En este sentido, el artículo 142 de la Ley 58/2003, de 17 de diciembre, General Tributaria, que se expresa en los siguientes términos: “Las actuaciones inspectoras se realizarán mediante el examen de documen- tos, libros, contabilidad principal y auxiliar, ficheros, facturas, justificantes, correspondencia con trascendencia tributaria, bases de datos informatizadas, programas, registros y archivos informáticos relativos a actividades económi- cas, así como mediante la inspección de bienes, elementos, explotaciones y cualquier otro antecedente o información que debe de facilitarse a la Adminis- tración o que sea necesario para la exigencia de las obligaciones tributarias”, justifica la creación de dichos ficheros. C. Poniendo como ejemplo el sector sanitario, en el que los derechos a la intimidad y a la protección de datos tienen una relevancia especial, cualquier centro sanitario, desde las clínicas en las que un único profesio- nal desarrolla su actividad de forma autónoma hasta los grandes hospita- les, tienen la obligación de disponer de un fichero con las historias clínicas de sus pacientes, cuya finalidad es la gestión de la prestación sanitaria prestada a los mismos. Fruto de la obligación de conservación de la documentación clínica, establecida en el artículo 17.1 de la Ley 41/2002, de 14 de noviembre, reguladora básica de la autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica, se especifica que: “los centros sanitarios tienen la obligación de conservar la documentación clínica en condiciones que garanticen su correcto mantenimiento y seguridad, aunque no necesariamente en el soporte original, para la debida asistencia al paciente durante el tiempo adecuado a cada caso y, como mínimo, cinco años contados desde la fecha del alta de cada proceso asistencial”. De lo anteriormente expuesto, podemos concluir que cualquiera de estos ficheros cumple con el requisito de necesariedad para el logro de la actividad u objeto legítimos de sus responsables. A pesar de que no siempre tiene que ser así, ni 20
  • 41. Obligaciones básicas es la única justificación para que un fichero cumpla el requisito de necesariedad que venimos analizando, los más habituales surgen de la necesidad de cumplir con requisitos impuestos por diferentes legislaciones. No podemos olvidar que, fuera de estos supuestos, cualquier persona, empresa o entidad, puede necesitar crear fiche- ros con distintas finalidades, lo que no supondrá ningún problema siempre que exista una justificación directamente vinculada a su actividad u objeto legítimos. 4.1.1.1. Ficheros de titularidad privada Los ficheros de titularidad privada son definidos en el artículo 5.1.l) del RLOPD como aquellos de los que son responsables las personas, empresas o entida- des de derecho privado, independientemente de quien ostente la titularidad de su capital o de la procedencia de sus recursos económicos, así como los ficheros de los que sean responsables las corporaciones de derecho público, pero no se encuentran estrictamente vinculados al ejercicio de potestades de derecho público atribuida por su normativa específica. Para la creación de estos ficheros hay que cumplir un procedimiento formal establecido en el artículo 27 de la LOPD, siguiendo los pasos que se describen a continuación: A. Notificación previa a la AEPD, cumplimentando los modelos o formula- rios electrónicos aprobados al efecto por la AEPD en resolución de 12 de julio de 2006 y publicados en el Boletín Oficial del Estado de 31 de julio 2006, en los que se detallará necesariamente la identificación del responsa- ble del fichero, el nombre del fichero, sus finalidades y los usos previstos, el sistema de tratamiento empleado, el colectivo de personas sobre el que se obtienen los datos, el procedimiento y la procedencia de los datos, las categorías de datos, el servicio o unidad de acceso, la identificación del nivel de medidas de seguridad básico, medio o alto exigible y, en su caso la identificación del encargado de tratamiento donde se encuentre ubicado el fichero y los destinatarios de cesiones y transferencias internacionales de datos. Además, se declarará un domicilio a efectos de notificación. En función de lo establecido en el RLOPD, esta notificación podrá realizarse en diferentes soportes, tal y como se explica a continuación:  En soporte electrónico -mediante comunicación electrónica o en soporte informático-, utilizando el programa NOTA (Notificaciones Telemáticas a la Agencia) para la generación de notificaciones que la AEPD ha puesto a disposición de todos los ciudadanos.  En soporte papel, utilizando igualmente los modelos aprobados por la AEPD. Estos formularios se pueden obtener gratuitamente en la página web de la AEPD (www.agpd.es). B. Si la notificación se ajusta a los requisitos exigibles, el Director de la AEPD, a propuesta del Registro General de Protección de Datos (en adelante, RGPD), acordará la inscripción del fichero asignándole el correspondiente 21
  • 42. La protección de datos personales: Soluciones en entornos Microsoft código de inscripción. En caso contrario, dictará resolución denegando la inscripción, debidamente motivada y con indicación expresa de las causas que impiden la inscripción. El art. 59.3 del RLOPD, introduce como novedad la posibilidad del Director de la AEPD de establecer procedimientos simplificados de notificación en atención a las circunstancias que concurran en el tratamiento o el tipo de fichero al que se refiere la notificación. La notificación de la creación de ficheros de datos de carácter personal ante la AEPD es una obligación que corresponde al responsable de los mismos, de manera que cuando se tenga previsto crear un fichero del que resulten responsables varias personas o entidades simultáneamente, cada una de ellas deberá notificar, a fin de proceder a su inscripción en el RGPD, la creación del correspondiente fichero. Además, esta obligación no conlleva coste económico alguno. Es importante destacar que la inscripción de los ficheros debe encontrarse actualizada en todo momento y es meramente declarativa, sin calificar que se estén cumpliendo las restantes obligaciones derivadas de la LOPD. Como consecuencia, que el RGPD acepte la inscripción de un fichero no conlleva, en ningún caso, un reconocimiento por parte de la AEPD de cumplimiento de ninguna otra obligación establecida en la normativa vigente en materia de protección de datos. Tal y como se expresa la propia AEPD en sus notificaciones: “La inscripción de un fichero en el Registro General de Protección de Datos, únicamente acredita que se ha cumplido con la obligación de notificación dispuesta en la Ley Orgánica 15/1999, sin que se esta inscripción se pueda desprender el cumplimiento por parte del responsable del fichero del resto de las obligaciones previstas en dicha Ley y demás disposiciones reglamentarias.” No por ello, debemos restar importancia al cumplimiento de la obligación de notificar los ficheros ya que permite dar publicidad de su existencia, poniendo a disposición de todos los ciudadanos, los ficheros en los que podrían encontrarse sus datos personales, facilitándoles de este modo el conocimiento de lo siguiente:  La totalidad de ficheros en los que podrían encontrarse sus datos personales.  La identificación del fichero, sus finalidades y los usos previstos, el sistema de tratamiento empleado, el colectivo de personas sobre el que se obtienen los datos, el procedimiento y procedencia de los datos, las categorías de datos, el servicio o unidad de acceso, la identificación del nivel de medidas de seguridad básico, medio o alto exigible y, en su caso, la identificación del encargado de tratamiento donde se encuentre ubicado el fichero y los destinatarios de cesiones y transferencias internacionales de datos.  Los responsables ante los que pueden ejercitar los derechos de acceso, rectificación, cancelación u oposición. Pero las ventajas de la inscripción registral no alcanzan únicamente a los ciudadanos, sino que se extienden tanto a la AEPD como a los propios responsables de los ficheros. 22
  • 43. Obligaciones básicas En relación con la AEPD, podemos destacar que la inscripción de los ficheros le permite disponer de una relación actualizada de los ficheros inscritos, facilitándole:  el cumplimiento de la obligación de velar por la publicidad de la existen- cia de los ficheros de datos con carácter personal5,  el conocimiento de todos los ficheros que deben cumplir con las obligacio- nes establecidas en la LOPD y su normativa de desarrollo,  el ejercicio de las actividades que la normativa le encomienda como Autoridad de Control y  el ejercicio del derecho de consulta de los ciudadanos. Desde la perspectiva del responsable de los ficheros, podemos apreciar las siguientes ventajas respecto de la inscripción de ficheros en el RGPD:  Evitar la imposición de sanciones.  Mostrar el compromiso o la intención de cumplir con la normativa de protección de datos.  Facilitar a los titulares de los datos contenidos en sus ficheros el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. Como resumen de lo expuesto hasta el momento, podemos hacernos eco de los principios que rigen la inscripción de ficheros, recogidos en la Memoria de la AEPD del año 2000:  El responsable del fichero deberá efectuar una notificación de un trata- miento o de un conjunto de tratamientos.  La inscripción de un fichero de datos no prejuzga que se hayan cumplido el resto de las obligaciones derivadas de la Ley.  La notificación de ficheros implica el compromiso por parte del responsa- ble de que el tratamiento de datos personales declarados para su inscrip- ción cumple con todas las exigencias legales.  La notificación de los ficheros al Registro supone una obligación de los responsables del tratamiento, sin coste económico alguno para ellos, y facilita que las personas afectadas puedan conocer quiénes son los titula- res de los ficheros ante los que deben ejercitar directamente los derechos de acceso, rectificación, cancelación y oposición.  Toda persona o entidad que proceda a la creación de ficheros de datos de carácter personal lo notificará previamente a la AEPD.  En la notificación deberán figurar necesariamente el responsable del fichero, la finalidad del mismo, las medidas de seguridad, con indicación del nivel básico, medio o alto exigible y las cesiones de datos de carácter 5. Artículo 37.1. j) LOPD. 23
  • 44. La protección de datos personales: Soluciones en entornos Microsoft personal que se prevean realizar y, en su caso, las transferencias de datos que se prevean a países terceros.  Deberá comunicarse a la APD cualquier cambio que se produzca con respecto a la declaración inicial y particularmente en la finalidad del fichero, en su responsable y en la dirección de su ubicación.  El RGPD inscribirá el fichero si la notificación se ajusta a los requisitos exigibles. En caso contrario podrá pedir que se completen los datos que falten o se proceda a su subsanación.  Transcurrido un mes desde la presentación de la solicitud de inscripción sin que la AEPD hubiera resuelto sobre la misma, se entenderá inscrito el fichero a todos los efectos. ¿Deben inscribirse los ficheros temporales? El RLOPD recoge la primera definición legal de ficheros temporales en su artículo 5.2.g). En virtud de esta se entienden como tales los “ficheros de trabajo creados por usuarios o procesos que son necesarios para un tratamiento ocasional o como paso intermedio durante la realización de un tratamiento”. Estos ficheros no tienen que inscribirse, pero sí tiene que estar inscrito el fichero de origen. En este sentido se ha pronunciado la AEPD 6, facilitando además algunos ejemplos: “Ej. si se crea un fichero temporal para organizar las vacaciones del personal a partir del fichero de recursos humanos, tendrá que estar inscrito el fichero de recursos humanos. Respecto del fichero de vacaciones tendrán que adoptarse las medidas de seguridad correspondientes. Un fichero creado para realizar tratamien- tos de datos periódicos, SI que tendrá que inscribirse. Ej. censo agrario, preinscripción anual en un polideportivo, ….”7. 4.1.1.2. Ficheros de titularidad pública Los ficheros de titularidad pública son definidos en el artículo 5.1.m) del RLOPD como “los ficheros de los que sean responsables los órganos constitucionales o con relevancia constitucional del Estado o las instituciones autonómicas con funciones análogas a los mismos, las Administraciones públicas territoriales, así como las entidades u organis- mos vinculados o dependientes de las mismas y las Corporaciones de derecho público siempre que su finalidad sea el ejercicio de potestades de derecho público”, como por ejemplo los colegios profesionales. 6. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008. https://www.agpd.es/portalweb/jornadas/1_sesion_abierta/common/faqs_bloque_2.pdf. 7. Véase nota número 6 anterior. 24
  • 45. Obligaciones básicas En relación con estos ficheros hay que tener en cuenta las disposiciones secto- riales establecidas por la LOPD. Con base en las mismas, podemos afirmar que la creación de los ficheros de las Administraciones Públicas sólo podrá hacerse por medio de disposición general publicada en el Boletín Oficial del Estado o diario oficial correspondiente -artículo 22 LOPD-. Dicha disposición deberá indicar:  La finalidad del fichero y los usos previstos para el mismo.  Las personas o colectivos sobre los que se pretenda obtener datos de carácter personal o que resulten obligados a suministrarlos.  El procedimiento de recogida de los datos de carácter personal.  La estructura básica del fichero y la descripción de los tipos de datos de carácter personal incluidos en el mismo.  Las cesiones de datos de carácter personal y, en su caso, las transferencias de datos que se prevean a países terceros.  Los órganos de las Administraciones responsables del fichero.  Los servicios o unidades ante los que pudiesen ejercitarse los derechos de acceso, rectificación, cancelación y oposición.  Las medidas de seguridad con indicación del nivel básico, medio o alto exigible. El artículo 55 del RLOPD, establece un plazo de treinta días desde la publica- ción de su norma o acuerdo de creación en el diario oficial correspondiente, para que todo fichero de datos de titularidad pública sea notificado a la AEPD para su inscripción en el RGPD. Cuando la actividad relacionada con la finalidad del fichero no pueda ser considerada como “pública” en sentido estricto, este se considerará privado, como por ejemplo el fichero de formación de un colegio profesional, cuya finalidad es dar formación a los colegiados o terceras personas. 4.1.2. La calidad de los datos El principio de calidad de los datos, establecido en el artículo 4 de la LOPD, regirá el tratamiento de los datos de carácter personal en todas sus fases, desde el momento previo a la recogida de los mismos hasta que se cesa en su tratamiento. Con carácter previo a la recogida de los datos el responsable del fichero o trata- miento debe tener en cuenta que, únicamente, podrá recogerlos para su tratamiento, así como someterlos al mismo, cuando sean adecuados, pertinentes y no excesivos en relación con el ámbito y las finalidades determinadas, explícitas y legítimas de su obtención, estando prohibida su recogida por medios fraudulentos, desleales o ilícitos. El artículo 8 del RLOPD desarrolla los principios relativos a la calidad de los datos. En concreto, en relación con el momento previo al tratamiento de los datos podemos destacar los principios de lealtad y licitud y finalidad. En relación con 25
  • 46. La protección de datos personales: Soluciones en entornos Microsoft estos, no añade nada a lo ya dispuesto en la LOPD, recordando la prohibición de recoger datos por medios fraudulentos, desleales o ilícitos, así como la única cir- cunstancia que legitima su recogida, es decir, el cumplimiento de finalidades determinadas, explícitas y legítimas del responsable del tratamiento. 4.1.3. La información al interesado El artículo 5 de la LOPD establece uno de los principios fundamentales que, junto al consentimiento, regirá el tratamiento de los datos de carácter personal: “Derecho de información en la recogida de datos”. El derecho establecido en este principio a favor de los titulares de los datos se convierte en una obligación para los responsables de los ficheros, en virtud de la cual tiene que informar al interesado, con carácter previo a la recogida de sus datos de carácter personal sobre algunos aspectos relacionados con el tratamiento de los datos, de manera que el interesado pueda tener la suficiente información como para consentir el tratamiento de forma consciente y libre. El legislador ha considerado, con buen criterio, que para ello es necesario conocer:  La existencia de un fichero o tratamiento de datos de carácter personal.  La finalidad de la recogida de los datos.  Los destinatarios de la información.  El carácter obligatorio o facultativo de la respuesta a las preguntas plan- teadas a los titulares de los datos.  Las consecuencias de la obtención de los datos o la negativa a suministrarlos.  La posibilidad de ejercitar los derechos de acceso, rectificación, cancela- ción y oposición.  La identidad y dirección del responsable del tratamiento o, en su caso, de su representante. Debemos plantearnos que no siempre los datos son recabados del propio titular o interesado, de manera que analizaremos a continuación las vías más habituales a través de las cuales se obtienen datos personales para insertarlos en un fichero. Del propio interesado Cuando los datos son recabados de sus titulares, habrá que facilitar directa- mente a los mismos la información detallada anteriormente. De terceros Cuando los datos hayan sido facilitados por persona distinta al titular de los mismos, el responsable del fichero dispone de un plazo de tres meses desde el momento del registro de los datos para facilitarle la información que le permita consentir el tratamiento de sus datos de forma libre y consciente. Como consecuen- cia, tendrá que informarle del contenido del tratamiento, la procedencia de los 26
  • 47. Obligaciones básicas datos, la existencia de un fichero o tratamiento, la finalidad para la que se han recabado los datos, los destinatarios de la información, la posibilidad de ejercitar los derechos de acceso, rectificación y oposición, así como de la identidad y dirección del responsable del tratamiento o su representante. La propia LOPD estable excep- ciones a esta obligación, afirmando que no será de aplicación cuando: A. El interesado ya hubiera sido informado con anterioridad. B. Una Ley lo prevea expresamente. Es preciso aclarar esta excepción, ya que, en ocasiones nos encontramos con previsiones normativas que no tienen rango de Ley en las que se prevé el tratamien- to o cesión de datos de carácter personal o preceptos legales en los que la excepción del deber de informar no es fruto de la interpretación literal del artículo, ya que no se recoge expresamente. Para la correcta aplicación de esta excepción han de darse dos requisitos: que la norma en la que se prevé el tratamiento o la cesión de datos tenga rango de Ley y, además, que dicho tratamiento o cesión haya sido recogido por el legislador de forma expresa. Así se desprende de un Informe emitido por la AEPD en el año 20048, en el que concluye que la excepción del artí-culo 5.5 a la que venimos haciendo referencia será aplicable a supuestos “en que el tratamiento o cesión de los datos de carácter personal aparece recogido expresamente en una norma con rango de Ley, pero no a aquellos supuestos en que la Ley “autorice” o “habilite” la cesión de datos, pero no la recoja de modo expreso y taxativo en su articulado, sin perjuicio de que en dichos supuestos la cesión se encontrará amparada por lo dispuestos en los artículos 6.2 u 11.2 a) de la Ley Orgánica 15/1999” 9. C. El tratamiento tenga fines históricos, estadísticos o científicos. D. La información al interesado resulte imposible o exija esfuerzos desproporcionados, a criterio de la AEPD o del organismo autonómico equivalente, en consideración al número de interesados, a la antigüedad de los datos y a las posibles medidas compensatorias. Esta excepción sólo será posible a través de un acto administrativo de la AEPD en que se decida acerca de la procedencia o improcedencia de la excepción alegada en cada caso concreto. Dicho acto implicará la tramita- 8. Vid. AEPD, Informe Jurídico 60/2004 Exención del deber de informar cuando el tratamiento o la cesión están expresamente previstos en una Ley, https://212.170.242.196/portalweb/canaldocumentacion/ informes_juridicos/deber_informacion/common/pdfs/2004-0060_Exenci-oo-n-del-deber-de-informar- cuando-el-tratamiento-o-la-cesi-oo-n-est-aa-n-expresamente-previstos-en-una-Ley.pdf. 9. En el mismo sentido se pronunció la AEPD en una resolución de 8 de octubre de 2004: “El artículo 5.5. también exceptúa de la obligación de informar cuando expresamente una Ley lo Prevea. De la interpretación literal del artículo resultaría que la obligación de informar debe estar expresamente exceptuada en una Ley para que se cumplan las condiciones previstas en este supuesto. Sin embargo la Directiva 95/46/CE, que ha sido traspuesta por la Ley 15/1999, en su artículo 11.2 especifica que no existe el deber de informar en particular para el tratamiento con fines estadísticos o de investigación histórica o científica, cuando la información al interesado resulte imposible o exija esfuerzos desproporcionados o el registro o la comunicación a un tercero estén expresamente previstos por ley, por lo que ha de interpretarse este supuesto de exclusión en los términos previstos en la Directiva, quedando excluida la obligación de informar cuando la cesión esté expresamente prevista en una Ley”. 27
  • 48. La protección de datos personales: Soluciones en entornos Microsoft ción del correspondiente procedimiento administrativo, iniciado en todo caso por la propia solicitud del interesado10. De fuentes de acceso público Quizás convenga empezar preguntándose qué son fuentes de acceso público. Estas se encuentran definidas en el artículo 3.j) de la LOPD como aquellos ficheros cuya consulta puede ser realizada por cualquier persona, no impedida por una norma limitativa o sin más exigencia que, en su caso, el abono de una contraprestación. Son, exclusivamente:  El censo promocional.  Las guías de teléfonos.  Las listas de colegios profesionales que contengan únicamente los datos de nombre, título, profesión, actividad, grado académico, dirección profesional e indicación de su pertenencia al grupo. El RLOPD, en su artículo 7 determina el alcance de las siguientes expresiones:  Dirección profesional: podrá incluir los datos del domicilio postal completo, número telefónico, número de fax y dirección electrónica.  Datos de pertenencia al grupo: considera como tales los de número de colegiado, fecha de incorporación y situación de ejercicio profesional.  Los diarios y boletines oficiales.  Los medios de comunicación social. Ha planteado muchas dudas si Internet es una fuente de acceso público. Con base en la definición, únicamente, podríamos considerarlo como tal si se encontrara incluido dentro de los medios de comunicación, pero a día de hoy los únicos medios de comunicación legalmente reconocidos son la prensa, la radio y la televisión. Co- mo consecuencia de ello, podemos afirmar que Internet, como tal, no es una fuente de acceso público. No obstante, a través de Internet podemos acceder a fuentes de acceso público. Por ejemplo, la lista de los profesionales pertenecientes a un colegio profesional no dejará de ser fuente de acceso público si accedemos a los datos a través de la página web del mismo. La AEPD ha confirmado esta interpretación, afirmando que “Internet no es, a los efectos de protección de datos un “medio de comunica- ción social”, sino un “canal de comunicación”, por lo que no es fuente accesible al público”11. Cuando los datos recabados en un fichero proceden de estas fuentes, el respon- sable tiene que informar al interesado de la procedencia de sus datos, la identidad y dirección del responsable del fichero o tratamiento y de la posibilidad de ejercitar 10. Vid. AEPD, Informe Jurídico2002-0000 Procedimiento para la exención del deber de informar, https:// 212.170.242.196/portalweb/canaldocumentacion/informes_juridicos/deber_informacion/common/pdfs/ 2002-0000_Procedimiento-para-la-exenci-oo-n-del-deber-de-informar.pdf. 11. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008, https:// www.agpd.es/portalweb/jornadas/1_sesion_abierta/common/faqs_bloque_1.pdf. 28
  • 49. Obligaciones básicas sus derechos de acceso, rectificación, cancelación y oposición. Información que acompañará cada comunicación que el responsable le realice. En relación con el censo promocional o las listas de personas pertenecientes a grupos de profesionales, establece la LOPD (artículo 28) la limitación de incluir en dichas fuentes los datos estrictamente necesarios para cumplir la finalidad a que se destina cada listado, de manera que la inclusión de datos adicionales por las entida- des responsables del mantenimiento de las mismas requerirá el consentimiento del interesado, que podrá ser revocado en cualquier momento. Además, la LOPD establece los siguientes derechos a favor de los interesados:  Respecto de los datos que consten en el censo promocional, a exigir gratuitamente la exclusión de la totalidad de los mismos por las entidades encargadas de su mantenimiento.  En relación con los listados de los colegios profesionales, a que la entidad respon- sable de su mantenimiento indique gratuitamente que sus datos personales no podrán ser utilizados para fines de publicidad o prospección comercial. La atención a la solicitud de exclusión de la información innecesaria o de inclusión de la objeción al uso de los datos para fines de publicidad o venta a distancia deberá realizarse en el plazo de diez días respecto de las informaciones que se realicen mediante consulta o comunicación telemática y en la siguiente edición del listado cualquiera que sea el soporte en que se edite. Las fuentes de acceso público que se editen en forma de libro o algún otro soporte físico, perderán el carácter de fuente accesible con la nueva edición que se publique y, en el caso de que se obtenga telemáticamente una copia de la lista en formato electróni- co, en el plazo de un año, contado desde el momento de su obtención. Una vez tratada la información que debemos facilitar al titular de los datos en los supuestos más habituales de recogida de los mismos, podemos avanzar un poco más profundizando de forma muy somera pero clarificadora los extremos que, por resultar menos precisos o haber sido expresados de una forma muy genérica por el legislador, pueden dar lugar a dudas o interpretaciones erróneas. En principio, parece que no tiene porqué generar problema alguno informar acerca de la identidad y dirección del responsable del tratamiento o su representante, la existencia de un fichero o tratamiento de datos de carácter personal, el carácter obligatorio o facultativo de la respuesta a las preguntas planteadas por el titular de los datos, las consecuencias de la obtención de los datos o la negativa a suministrarlos o la posibilidad de ejercitar los derechos de acceso, rectificación, cancelación u oposición. Por el contrario, consideramos oportuno desarrollar las siguientes expresiones en aras a aportar una mayor claridad en relación con la intención del legislador. La finalidad de la recogida de los datos Cuando el responsable de un fichero recaba datos para una finalidad específi- ca, seguramente no le plantee ningún problema informar sobre la misma. No 29
  • 50. La protección de datos personales: Soluciones en entornos Microsoft obstante, en la vida comercial, empresarial o profesional, no son pocos los casos en los que resulta muy importante para el responsable del fichero el uso de los datos para finalidades que exceden de una finalidad específica y fácil de definir. Desde que se ha establecido la relación inicial con el titular de los datos, lo más habitual y con tendencia ascendente, es que el responsable del fichero desee utilizar los datos con finalidades diferentes a la inicial. Entre las más comunes se encuentran la fidelización de clientes -basada en acciones como el envío de felicitaciones en fechas tan señaladas como Navidad, Año Nuevo o cumpleaños-, ofrecer otros productos o servicios que puedan resultar de interés -a través de campañas comerciales-, valorar la calidad de los productos o servicios prestados -utilizando encuestas de calidad o satisfacción-, enviar revistas informativas destinadas a lectores con un perfil prede- terminado y hacer estudios de mercado de los gustos de los clientes. Para el uso de los datos facilitados inicialmente con todas estas finalidades, lo que permitiría al responsable del fichero sacar un mayor aprovechamiento del mis- mo, traducido normalmente en un mayor beneficio económico, resulta imprescindi- ble haber informado correctamente. Es a la hora de informar del uso de los datos para todas estas finalidades cuando el responsable del fichero puede encontrarse con problemas, principalmente, que el interesado se niegue a facilitar sus datos. La experiencia nos ha aportado soluciones prácticas para solventar este proble- ma, basadas en el redacción de cláusulas que, sin saltar las fronteras de lo legítimo, nos permiten ampliar y generalizar la finalidad para la que se recaban los datos. Los destinatarios de la información A medida que evoluciona la industria, el comercio e, incluso, la prestación de servicios por los profesionales, se extiende la colaboración con diversas personas, empresas o entidades en el desarrollo de un objeto social o actividad legítima, fruto de la necesidad de recurrir a personas o empresas especializadas para cubrir caren- cias propias o abordar proyectos de mayor envergadura a la que una sola compañía puede hacer frente. En numerosas ocasiones, estas colaboraciones llevan implícita la necesidad de facilitar datos de carácter personal que constan en un fichero propio. Si la LOPD no obligara a informar previamente al titular de los datos de los destina- tarios de los mismos, correríamos el grave riesgo de que esto se convirtiera en una cadena de cesiones desconocidas para el afectado, rompiéndose de este modo su posibilidad de decisión acerca del tratamiento de sus datos personales, quebrando el derecho a la protección de los mismos. El ejemplo más claro en el que se produ- cen constantemente este tipo de cesiones es entre las empresas pertenecientes a un mismo grupo. No obstante, tal y como ha ocurrido con la finalidad de la recogida de los datos, en la práctica se han desarrollado soluciones que permiten que no resulte necesario dar una información detallada de cada destinatario de los datos que puede llegar a intervenir en el tratamiento de los mismos -nombre o razón social-, resultando suficiente informar acerca de la categoría de los destinatarios de la información y la finalidad de las cesiones. 30
  • 51. Obligaciones básicas Esta posibilidad se ha visto reforzado por el RLOPD, en el que el legislador ha manifestado de forma expresa que: “Cuando se solicite el consentimiento del afectado para la cesión de sus datos, éste deberá ser informado de forma que conozca inequívocamente la finalidad a la que se destinarán los datos respecto de cuya comunicación se solicita el consentimiento y el tipo de actividad desarrollada por el cesionario. En caso contrario, el consenti- miento será nulo”12. Forma que se debe adoptar para facilitar la información y acreditación del cumplimiento del deber de informar La LOPD no impone a los responsables de ficheros o tratamientos forma alguna para facilitar al titular de los datos la información necesaria para el trata- miento de los mismos. Lo más habitual y sencillo, a priori, es utilizar el mismo medio que se utiliza para la recogida de los datos también para facilitar la información. Si nos traslada- mos a la práctica podemos afirmar que los sistemas de recogida de datos utilizados más frecuentemente son:  Oralmente. En principio, teniendo en cuenta que la LOPD no impone a los responsables de ficheros o tratamientos forma alguna para informar al titular de los datos, sería suficiente con prestarlo de forma oral. Una alternativa es la colocación de carteles informativos en un lugar visible para las personas que facilitan los datos.  A través de formularios. El artículo 5.2 de la LOPD establece expresamen- te que cuando se usen formularios o impresos para la recogida, figurará en los mismos la información necesaria, en forma claramente legible.  Contratos. Si el titular de los datos firma un contrato se debe incluir en el mismo la información relativa al tratamiento de sus datos.  Telefónicamente. Podría proporcionarse la información por el mismo medio, pero otra alternativa es enviar una comunicación posterior, apro- vechando por ejemplo la entrega del producto adquirido por teléfono. En la práctica, se venía recomendando adoptar siempre medios que permitan disponer de una prueba del cumplimiento de dicha obligación con fundamento en un Informe jurídico de la AEPD13. De este modo, a efectos de la Ley, será necesario que el responsable del trata- miento acredite la realización del envío, lo que sería posible tanto en el caso de que el envío se realice por el propio consultante como en caso de que el mismo se encomiende a una tercera empresa, que se certifique de algún modo la efectiva realización de los envíos, y exista un principio de prueba de que el envío efectiva- 12. Art. 12.2 RLOPD. 13. Vid. AEPD, Informe Jurídico 0111/2005 Prueba en relación con el cumplimiento del deber de información, https://www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/deber_informacion/ index-ides-idphp.php. 31
  • 52. La protección de datos personales: Soluciones en entornos Microsoft mente realizado ha llegado a su destino, lo que podría conseguirse, por ejemplo, mediante el acceso a las listas de devoluciones del servicio de correos. El RLOPD -artículo 18- ha regulado de forma novedosa la acreditación del deber de informar, estableciendo el deber de utilizar un medio que permita acredi- tar su cumplimiento, debiendo conservarse mientras persista el tratamiento de los datos del afectado. Asimismo, el responsable deberá conservar el soporte en el que conste el cumplimiento del deber de informar, pudiendo utilizar medios informá- ticos o telemáticos para el almacenamiento de los soportes. Añade el legislador que, “en particular podrá proceder al escaneado de la documentación en soporte papel, siempre y cuando se garantice que en dicha automatización no ha mediado alteración alguna de los soportes originales”. La información dirigida a los menores de edad Cuando el tratamiento se refiera a datos de menores de edad, la información dirigida a los mismos deberá expresarse en un lenguaje que sea fácilmente com- prensible por aquellos. Supuestos especiales El artículo 19 del RLOPD ha introducido como novedad lo siguiente: “En los supuestos en que se produzca una modificación del responsable del fichero como consecuencia de una operación de fusión, escisión, cesión global de activos y pasivos, aportación o transmisión de negocio o rama de actividad empresarial, o cualquier operación de reestructuración societaria de análoga naturaleza, contem- plada por la normativa mercantil, no se producirá cesión de datos, sin perjuicio del cumplimiento por el responsable de lo dispuesto en el artículo 5 de la Ley Orgánica 15/1999, de 13 de diciembre”. Consecuencia de ello, podemos afirmar que en los supuestos indicados en el precepto trascrito, habrá que informar al titular de los datos de los nuevos destina- tarios de la información, adquiriendo también especial importancia la información relativa a la finalidad, dado que en principio, el tratamiento debe limitarse a la finalidad para la que se consintió inicialmente y ésta sólo podrá ampliarse en el caso de que se facilite la información acerca de nuevas finalidades y el afectado consienta el tratamiento de sus datos para las mismas. 4.1.4. El consentimiento del interesado El principio del consentimiento del interesado, establecido en el artículo 6 de la LOPD, constituye una de las obligaciones principales en materia de protección de datos. Como norma general, el tratamiento de los datos de carácter personal reque- rirá el consentimiento inequívoco del afectado. Antes de seguir adelante, resulta conveniente detenerse en la definición de consentimiento del interesado, recogida en el artículo 3.K) de la LOPD: “toda manifestación de voluntad libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos 32
  • 53. Obligaciones básicas personales que le conciernen” y analizar el significado de libre, inequívoco, específico e informado. Para ello, nada mejor que recurrir a la interpretación de la AEPD, expresada en un Informe jurídico emitido en el año 200014.  Libre. Supone que el mismo deberá haber sido obtenido sin la interven- ción de vicio alguno del consentimiento en los términos regulados por el Código Civil.  Específico. Referido a una determinada operación de tratamiento y para una finalidad determinada, explícita y legítima del responsable del tratamiento.  Inequívoco. Implica que no resulta admisible deducir el consentimiento de los meros actos realizados por el afectado (consentimiento presunto), siendo preciso que exista expresamente una acción u omisión que impli- que la existencia del consentimiento.  Informado. Requiere que el afectado conozca con anterioridad al trata- miento la existencia del mismo y las finalidades para las que el mismo se produce. Precisamente por ello, el artículo 5.1 de la LOPD impone el deber de informar a los interesados de una serie de extremos que en el mismo se contienen. De este modo, el consentimiento se encuentra ínti- mamente relacionado con la información para la recogida de los datos, ya que para que se cumplan los requisitos del mismo el responsable del fichero o tratamiento debe informar previa y correctamente al titular de los datos de la existencia del fichero o tratamiento y de las finalidades para las que se destinarán los datos. Como consecuencia de ello, la solici- tud de consentimiento debe referirse a un tratamiento o serie de trata- mientos concretos, con delimitación de la finalidad para la que se recaban los datos y las restantes condiciones que concurran en el tratamiento o serie de tratamientos. Así lo ha recogido el RLOPD en su artículo 12.1. No obstante, la propia LOPD establece excepciones a la obligación de obtener el consentimiento para el tratamiento de los datos de carácter personal, en concreto: A. Que la Ley disponga otra cosa. B. Que los datos de carácter personal se recojan para el ejercicio de las funciones propias de las Administraciones Públicas en el ámbito de sus competencias. C. Que los datos se refieran a las partes de un contrato o precontrato de una relación negocial, laboral o administrativa y sean necesarios para su mantenimiento o cumplimiento. D. Que el tratamiento de los datos tenga por finalidad proteger un interés vital del interesado, cuando dicho tratamiento resulte necesario para la prevención o el diagnóstico médicos, la prestación de asistencia sanitaria 14. Vid. AEPD, Informe Jurídico 2000-0000 Caracteres del consentimiento definido por la LOPD, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/consentimiento/index-ides-idphp.php. 33
  • 54. La protección de datos personales: Soluciones en entornos Microsoft o tratamientos médicos o la gestión de servicios sanitarios, siempre que dicho tratamiento de datos se realice por un profesional sanitario sujeto al secreto profesional o por otra persona sujeta asimismo a una obligación equivalente de secreto. E. Que los datos figuren en fuentes accesibles al público y su tratamiento sea necesario para la satisfacción del interés legítimo perseguido por el responsable del fichero o por el del tercero a quien se comuniquen los datos, siempre que no se vulneren los derechos y libertades fundamenta- les del interesado. En estos casos, en los que no sea necesario el consentimiento del afectado para el tratamiento de los datos de carácter personal y, siempre que una Ley no disponga lo contra- rio, la LOPD concede al mismo la posibilidad de oponerse a su tratamiento cuando existan motivos fundados y legítimos relativos a una concreta situación personal. Revocación del consentimiento El derecho del titular de los datos a revocar el consentimiento prestado para el tratamiento de sus datos ha sido reconocido por el legislador en la LOPD, a través de los artículos 6.3, en el que se recoge expresamente este derecho15 y 16.1, en el que se establece la obligación para el responsable del tratamiento de hacer efectivo el derecho del titular de los datos a que sean cancelados, lo que conlleva la imposibili- dad para el responsable de continuar en el tratamiento consentido anteriormente. Asimismo, en el artículo 11.4 se reconoce expresamente el derecho del titular de los datos a revocar el consentimiento prestado para la cesión de los mismos 16. El RLOPD -artículo 17- ha desarrollado la revocación del consentimiento en relación con la forma de llevarlo a cabo, estableciendo la posibilidad de realizarlo a través de un medio sencillo, gratuito y que no implique ingreso alguno para el responsable del fichero o tratamiento. En concreto, reconoce como medios adecua- dos un envío franqueado al responsable del tratamiento o, incluso, la llamada a un número de teléfono gratuito o a los servicios de atención al público establecidos por el mismo. Por el contrario, no se considerarán conformes a lo dispuesto en la LOPD, los supuestos en que el responsable establezca como medio para que el interesado pueda manifestar su negativa al tratamiento el envío de cartas certificadas o envíos semejantes, la utilización de servicios de telecomunicaciones que implique una tarificación adicional al afectado o cualesquiera otros medios que impliquen un coste adicional al interesado. Las consecuencias que implica la revocación del consentimiento para el res- ponsable del tratamiento se detallan a continuación: 15. Art. 6.3 de la LOPD: “El consentimiento a que se refiere el artículo podrá ser revocado cuando exista causa justificada para ello y no se le atribuyan efectos retroactivos”. 16. Art. 11.4 de la LOPD: “El consentimiento para la comunicación de los datos de carácter personal tiene también un carácter revocable”. 34
  • 55. Obligaciones básicas  Cesar en el tratamiento de los datos del interesado en un plazo máximo de diez días a contar desde la fecha de la recepción de la revocación.  Si el interesado hubiera solicitado la confirmación del cese en el tratamien- to de sus datos, deberá responder expresamente a la solicitud.  Si los datos hubieran sido cedidos previamente, deberá comunicar la revocación del consentimiento a los cesionarios, en el plazo indicado en el punto anterior, para que éstos cesen en el tratamiento de los datos en caso de que aún lo mantuvieran. Forma de prestar el consentimiento Teniendo en cuenta que la LOPD establece la necesidad de manifestar el consentimiento de forma expresa y por escrito, únicamente, para el tratamiento de algunos tipos de datos, podemos afirmar que, como norma general, admite el consentimiento tácito. Dentro del consentimiento inequívoco que exige para el tratamiento de los datos de carácter personal, distingue tres categorías de consenti- miento en función de los datos objeto de tratamiento:  Tácito. Suficiente para el tratamiento de todos los datos, salvo los espe- cialmente protegidos -ideología, afiliación sindical, religión, creencias, origen racial, salud y vida sexual-. En este sentido se ha pronunciado la AEPD en un informe jurídico recien- te17 afirmando que: “El consentimiento, salvo cuando el tratamiento se refiera a los datos especial- mente protegidos, regulados por el artículo 7 de la Ley Orgánica, podrá obtenerse de forma expresa o tácita, es decir, tanto como consecuencia de una afirmación específica del afectado en ese sentido, como mediante la falta de una manifestación contraria al tratamiento, para la que se hayan concedido mecanismos de fácil adopción por el afectado y un tiempo prudencial para dar la mencionada respuesta negativa”.  Expreso. En función de lo establecido en el artículo 7.2 de la LOPD, los datos de carácter personal que revelan la ideología, afiliación sindical, religión y creencias del afectado sólo podrán ser tratados con su consenti- miento expreso y por escrito, salvo en los casos de ficheros mantenidos por los partidos políticos, sindicatos, iglesias, confesiones o comunidades religiosas y asociaciones, fundaciones y otras entidades sin ánimo de lucro, cuya finalidad sea política, filosófica, religiosa o sindical, en cuanto a los datos relativos a sus asociados o miembros.  Expreso y por escrito. Los datos de carácter personal que hagan referencia al origen racial, a la salud y a la vida sexual sólo podrán ser recabados, 17. Vid. AEPD, Informe Jurídico 93/2008 Formas de obtener el consentimiento mediante web: Consentimientos tácitos, https://www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/ consentimiento/index-ides-idphp.php. 35
  • 56. La protección de datos personales: Soluciones en entornos Microsoft tratados y cedidos cuando, por razones de interés general, así lo disponga una Ley o el afectado consienta expresamente. Así se desprende del artículo 7.2 de la LOPD. Teniendo en cuenta que corresponde al responsable del tratamiento la prueba de la existencia del consentimiento del titular de los datos para su tratamiento, por cualquier medio de prueba admisible en derecho, a pesar de no resultar necesario, lo más recomendable es disponer del consentimiento expreso y por escrito. El responsable del tratamiento podrá solicitar el consentimiento del interesado para el tratamiento de sus datos de carácter personal a través del procedimiento establecido en el artículo 14 del RLOPD, salvo cuando la Ley exija al mismo la obtención del consentimiento expreso para el tratamiento de los datos, en virtud del cual, una vez que el responsable ha informado al afectado, deberá concederle un plazo de treinta días para manifestar su negativa al tratamiento, advirtiéndole de que en caso de no pronunciarse a tal efecto se entenderá que consiente el tratamien- to de sus datos de carácter personal. En concreto, cuando se trate de responsables que presten al afectado un servicio que genere información periódica o reiterada, o facturación periódica, la comunicación podrá llevarse a cabo de forma conjunta a esta información o a la facturación del servicio prestado, siempre que se realice de forma claramente visible. En todo caso, será necesario que el responsable del tratamiento pueda conocer si la comunicación ha sido objeto de devolución por cualquier causa, en cuyo caso no podrá proceder al tratamiento de los datos referidos a ese interesado. Finalmente, el RLOPD establece que cuando se solicite el consentimiento del interesado a través de este procedimiento, no será posible solicitarlo nuevamente respecto de los mismos tratamientos y para las mismas finalidades en el plazo de un año a contar desde la fecha de la anterior solicitud. Consentimiento para el tratamiento de los datos de menores de edad Una novedad importante del RLOPD es la regulación del consentimiento para el tratamiento de los datos de menores de edad -ya que nada se regula al respecto en la LOPD-, estableciendo la edad de catorce años para poder consentir en el tratamiento de los datos de carácter personal, salvo en aquellos casos en los que la Ley exija para su prestación la asistencia de los titulares de la patria potestad o tutela. En el caso de los menores de catorce años se requerirá el consentimiento de los padres o tutores. No obstante, se establece una limitación para el responsable del fichero o tratamiento en relación con los datos que se pueden obtener del menor, ya que en ningún caso podrán recabarse a través de este datos que permitan obtener informa- ción sobre los demás miembros del grupo familiar o las características del mismo, como los datos relativos a la actividad profesional de los progenitores, información económica, datos sociológicos o cualesquiera otros, sin el consentimiento de los titulares de tales datos. Únicamente podrán recabarse los datos de identidad y dirección del padre, madre o tutor con la única finalidad de recabar la autorización de los mismos para el tratamiento de los datos. 36
  • 57. Obligaciones básicas Finalmente, se impone al responsable del fichero o tratamiento la obligación de articular los procedimientos que garanticen que se ha comprobado de modo efecti- vo la edad del menor y la autenticidad del consentimiento prestado en su caso, por los padres, tutores o representantes legales. En algunos supuestos, como el de ob- tención de los datos a través de una página web, parece difícil articular un sistema que permita al responsable disponer de esta garantía. Para este caso concreto la AEPD ha propuesto y admitido como válida la opción de poner una casilla en la que se deba indicar la edad en la que resulte imposible introducir una fecha más antigua a dieciocho años desde la fecha 18. 4.2. Durante el tratamiento de los datos 4.2.1. La calidad de los datos De nuevo está presente el principio de calidad de los datos que, si bien no se puede olvidar en ninguna de las fases en las que hemos dividido el tratamiento de los mismos, adquiere especial relevancia en este momento. En virtud de lo establecido en el artículo 4 de la LOPD, los datos personales:  no pueden usarse para finalidades incompatibles con aquellas para las que se han recogido,  tienen que ser exactos y puestos al día, de forma que respondan con veracidad a la situación actual de su titular y  tienen que ser almacenados de forma que permitan el ejercicio del derecho de acceso. El uso de los datos en relación con la finalidad para la que se obtuvieron En virtud de lo establecido en el artículo 4 de la LOPD, los datos de carácter personal objeto de tratamiento no pueden usarse para finalidades incompatibles con aquellas para las que los datos hubieran sido recogidos y no se considerarán como tales el tratamiento posterior de éstos con fines históricos, estadísticos o científicos. Después de esta afirmación, parece casi inevitable detenerse a analizar la expresión “finalidades incompatibles”, utilizada por primera vez en la LOPD, supo- niendo un cambio de redacción respecto del artículo 4 de la LORTAD, en el que se establecía que los datos no podrían usarse para “finalidades distintas” a aquellas para las que hubieran sido recogidos. La utilización del término incompatibles puede suponer un peligro para el respeto al derecho a la protección de datos por parte de los responsables de los ficheros y tratamientos, ya que interpretando el término incompatible en su sentido estricto, pocas finalidades resultarían incompatibles con aquella para la que se obtuvieron los datos. 18. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008, https:// www.agpd.es/portalweb/jornadas/1_sesion_abierta/index-ides-idphp.php. 37
  • 58. La protección de datos personales: Soluciones en entornos Microsoft Debemos seguir interpretando este principio como la imposibilidad de uso de los datos para finalidades distintas, tal y como se recogía en la LORTAD, ya que así lo ha interpretado el Tribunal Constitucional, en su Sentencia 292/2000, de 30 de noviembre, que viene a identificar el citado término con “fines distintos”. Así, dispone la citada sentencia en su Fundamento Jurídico 5 que “La garantía de la vida privada de la persona y de su reputación poseen hoy una dimensión positiva que excede el ámbito propio del derecho fundamental a la intimidad (art. 18.1 CE), y que se traduce en un derecho de control sobre los datos relativos a la propia persona. La llamada «libertad informática» es así derecho a controlar el uso de los mismos datos insertos en un programa informático («habeas data») y comprende, entre otros aspectos, la oposición del ciudadano a que determinados datos personales sean utilizados para fines distintos de aquel legítimo que justificó su obtención (SSTC 11/1998, F. 5, 94/1998, F. 4)”. Asimismo, la sentencia vuelve a interpretar este precepto cuando indica que “la cesión de los mismos (datos) a un tercero para proceder a un tratamiento con fines distintos de los que originaron su recogida, aun cuando puedan ser compatibles con éstos (art. 4.2 LOPD), supone una nueva posesión y uso que requiere el consentimiento del interesado”19. La AEPD reproduce esta interpretación en su informe jurídico 0078/2005: “Tratamiento de datos para fines incompatibles”20. La propia LOPD afirma que no se considerará incompatible el tratamiento posterior de los datos con fines históricos, estadísticos o científicos y el artículo 9 RLOPD desarrolla el tratamiento de los datos con estos fines, estableciendo que para la determinación de los mismos se estará a la legislación que en cada caso resulte aplicable y, en particular, a lo dispuesto en la Ley 12/1989, de 9 de mayo, Reguladora de la función estadística pública, la Ley 16/1985, de 25 junio, del Patrimonio histórico español y la Ley 13/1986, de 14 de abril de Fomento y coordi- nación general de la investigación científica y técnica y sus respectivas disposiciones de desarrollo, así como a la normativa autonómica en estas materias. Exactitud de los datos Los datos de carácter personal objeto de tratamiento tienen que ser exactos y puestos al día de forma que respondan con veracidad a la situación actual de su ti- tular, de manera que si los datos registrados resultan inexactos, en todo o en parte, o incompletos, el responsable del fichero o tratamiento se verá obligado a cancelarlos y sustituirlos de oficio por los correspondientes datos rectificados o completados 21. Ejercicio del derecho de acceso Los datos de carácter personal tienen que ser almacenados de forma que permitan el ejercicio del derecho de acceso, salvo que sean legalmente cancelados. Este derecho será desarrollado en el apartado 5.4.1. 19. Este argumento es reiterado en el posterior Fundamento Jurídico 14. 20. Vid. AEPD, Informe Jurídico 0078/2005 Tratamiento de datos para fines incompatibles, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/consentimiento/index-ides-idphp.php. 38
  • 59. Obligaciones básicas 4.2.2. El deber de secreto El deber de secreto es uno de los principios básicos en materia de protección de datos de carácter personal, establecido en el artículo 10 de la LOPD. Al margen del deber de secreto profesional establecido en relación con algunas profesiones, tales como la abogacía o la medicina, la LOPD establece una obligación de guardar secreto que afecta, no sólo al responsable del fichero, sino a todas las personas que intervienen en cualquier fase del tratamiento de los datos de carácter personal, con independencia de la actividad profesional de cada una de ellas. En concreto, establece el sometimiento al secreto profesional respecto de los datos de carácter personal y al deber de guardarlos. Al margen de las sanciones en materia de protección de datos en las que pudiera derivar la vulneración de este principio, es importante tener en cuenta que la revelación de secretos se encuentra tipificada como delito en el Código Penal - artículos 197 a 200-, castigando el apoderamiento, utilización o modificación de datos de carácter personal o familiar de un tercero que se encuentren registrados en ficheros o soporte informáticos, electrónicos o telemáticos o en cualquier otro tipo de archivo o registro público o privado, sin autorización y en perjuicio de tercero. Del mismo modo, se castiga a los que accedan a los mismos por cualquier medio, sin autorización, así como a quien los altere o utilice en perjuicio del titular de los datos o de un tercero. Para evitar sanciones de la AEPD como consecuencia de la vulneración de este principio por parte de los usuarios de los datos, se recomienda al responsable del fichero o tratamiento establecer por escrito una política de información y formación con el objetivo de ponerles en conocimiento de sus funciones y obligaciones en materia de protección de datos personales. 4.2.3. La seguridad de los datos Este principio, establecido en el artículo 9 de la LOPD, impone al responsable del fichero, todos los posibles encargados del tratamiento y todas las personas que inter- vienen en el mismo, la obligación de adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos de carácter personal y eviten su alteración, pérdida, tratamiento o acceso no autorizado, habida cuenta del estado de la tecnología, la naturaleza de los datos almacenados y los riesgos a que están expuestos, ya provengan de la acción humana o del medio físico o natural. De este modo, no se podrán registrar datos de carácter personal en ficheros que no reúnan 21. La Jurisprudencia ha tenido ocasión de analizar el alcance de este principio en las siguientes sentencias: Sentencia de la Sala de lo Contencioso Administrativo de la Audiencia Nacional, de 6 de julio de 2001; Sentencia de la Sección Novena de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 5 de noviembre de 1998; Sentencia de la Sección Octava de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 18 de octubre de 2000; Sentencia de la Sección Octava de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 26 de mayo de 1999; Sentencia de la Sala de lo Contencioso Administrativo de la Audiencia Nacional, de 19 de enero de 2001; Sentencia de la Sección Octava de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 9 de febrero de 2000; Sentencia de la Sala de lo Contencioso Administrativo de la Audiencia Nacional, de 9 de marzo de 2001. 39
  • 60. La protección de datos personales: Soluciones en entornos Microsoft las condiciones determinadas por el RLOPD con respecto a su integridad y seguridad y a las de los centros de tratamiento, locales, equipos, sistemas y programas. El RLOPD dedica todo su Título VIII al desarrollo de las medidas de seguridad en el tratamiento de datos de carácter personal, estableciendo unas disposiciones generales -relativas a todos los ficheros o tratamientos de datos de carácter perso- nal, independientemente del soporte en el que se encuentren- y las medidas de seguridad aplicables con carácter específico a los ficheros y tratamientos automati- zados y manuales, respectivamente. Las medidas de seguridad exigibles a los ficheros y tratamientos se clasifican en tres niveles (básico, medio y alto), definidos en función del tipo de datos conteni- dos en dichos ficheros o sometidos a tratamiento. Las medidas incluidas en cada uno de estos niveles tienen la condición de mínimos exigibles, sin perjuicio de las disposiciones legales o reglamentarias específicas vigentes que pudieran resultar de aplicación en cada caso o las que por propia iniciativa adoptase el responsable del fichero. A. Nivel básico. Todos los ficheros o tratamientos de datos de carácter personal deberán adop- tar las medidas de seguridad calificadas de nivel básico. Las medidas de seguridad aplicables para los ficheros y tratamiento de datos de nivel básico son las que se detallan a continuación: 1. Para todos los ficheros (automatizados o no). 1.a. Personal.  Definir las funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios.  Definir las funciones de control y las autorizaciones delegadas por el responsable.  Difundir entre el personal, de las normas que les afecten y las consecuencias por su incumplimiento. 1.b. Incidencias.  Llevar un registro de incidencias en el que se detalle: tipo, momento de su detección, persona que la notifica, efectos y medidas correctoras.  Elaborar un procedimiento de notificación y gestión de las incidencias. 1.c. Control de acceso.  Disponer de una relación actualizada de usuarios y accesos autorizados. 40
  • 61. Obligaciones básicas  Controlar los accesos permitidos a cada usuario según las funcio- nes asignadas.  Implantar mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.  Conceder permisos de acceso sólo el personal autorizado.  Adoptar las mismas medidas para personal ajeno con acceso a los recursos de datos. 1.d. Gestión de soportes.  Crear un inventario de soportes.  Identificar el tipo de información que contienen los soportes.  Restringir el acceso al lugar de almacenamiento de los soportes.  Autorizar las salidas de soportes (incluidas a través de e-mail).  Implantar medidas para el transporte y el desecho de soportes. 2. Solo para ficheros automatizados. 2.a. Identificación y autenticación.  Implantar mecanismos de identificación y autenticación personalizada de los usuarios.  Crear un procedimiento de asignación y distribución de contraseñas.  Almacenar las contraseñas de forma ininteligible.  Cambiar las contraseñas con una periodicidad mínima de 1 año. 2.b. Copias de respaldo.  Hacer una copia de respaldo semanal.  Establecer procedimientos de generación de copias de respaldo y recuperación de datos.  Verificar semestralmente los procedimientos.  Reconstruir los datos a partir de la última copia o grabarlos manualmente en su caso, si existe documentación que lo permita.  Realizar copia de seguridad y aplicar el nivel de seguridad correspondiente, si se realizan pruebas con datos reales. 3. Solo para ficheros no automatizados. 3.a. Criterios de archivo.  El archivado de documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 41
  • 62. La protección de datos personales: Soluciones en entornos Microsoft 3.b. Almacenamiento.  Dotar a los dispositivos de almacenamiento de mecanismos que obstaculicen su apertura. 3.c. Custodia de soportes.  Establecer criterios de diligente y custodia de la documentación por parte de la persona a cargo de la misma, durante su revisión o tramitación, para evitar accesos no autorizados. B. Nivel medio. Además de las medidas de seguridad de nivel básico, deberán implantarse las de nivel medio, en los siguientes ficheros o tratamientos de datos de carácter personal:  Los relativos a la comisión de infracciones administrativas o penales.  Los relacionados con la prestación de servicios de información sobre solvencia patrimonial y crédito.  Aquellos de los que sean responsables Administraciones tributarias y se relacionen con el ejercicio de sus potestades tributarias.  Aquellos de los que sean responsables las entidades financieras para finalidades relacionadas con la prestación de servicios financieros.  Aquellos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. De igual modo, aquellos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social.  Aquellos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la persona- lidad o del comportamiento de los mismos. Las medidas de seguridad aplicables para los ficheros y tratamiento de datos de nivel medio son las que se detallan a continuación: 1. Para todos los ficheros (automatizados o no). 1.a. Personal.  Definir las funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios.  Definir de las funciones de control y las autorizaciones delegadas por el responsable  Difundir entre el personal, de las normas que les afecten y las consecuencias por su incumplimiento. 42
  • 63. Obligaciones básicas 1.b. Incidencias.  Llevar un registro de incidencias en el que se detalle: tipo, momento de su detección, persona que la notifica, efectos y medidas correctoras  Elaborar un procedimiento de notificación y gestión de las incidencias. 1.c. Control de acceso.  Disponer de una relación actualizada de usuarios y accesos autorizados.  Controlar los accesos permitidos a cada usuario según las funcio- nes asignadas.  Implantar mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.  Conceder permisos de acceso sólo el personal autorizado.  Adoptar las mismas medidas para personal ajeno con acceso a los recursos de datos. 1.d. Gestión de soportes.  Crear un inventario de soportes.  Identificar el tipo de información que contienen los soportes.  Restringir el acceso al lugar de almacenamiento de los soportes.  Autorizar las salidas de soportes (incluidas a través de e-mail).  Implantar medidas para el transporte y el desecho de soportes. 1.e. Auditoría.  Realizar una auditoría, interna o externa, al menos cada dos años.  Realizar una auditoría ante modificaciones sustanciales en los sistemas de información con repercusiones en seguridad, pese a no haber transcurrido el plazo indicado en el punto anterior.  Verificar y controlar la adecuación de las medidas de seguridad implantadas.  Emitir un informe de las detecciones de deficiencias y propuestas correctoras.  Analizar el informe del responsable de seguridad y remitir las conclusiones al responsable del fichero. 2. Sólo para ficheros automatizados. 2.a. Gestión de soportes.  Registrar la entrada y salida de soportes en el que se detalle: documento o soporte, fecha, emisor/destinatario, número, tipo 43
  • 64. La protección de datos personales: Soluciones en entornos Microsoft de información, forma de envío, responsable autorizada para recepción/entrega. 2.b. Identificación y autenticación.  Implantar mecanismos de identificación y autenticación personalizada de los usuarios.  Crear un procedimiento de asignación y distribución de contraseñas.  Almacenar las contraseñas de forma ininteligible.  Cambiar las contraseñas con una periodicidad mínima de 1 año. 2.c. Copias de respaldo.  Hacer una copia de respaldo semanal.  Establecer procedimientos de generación de copias de respaldo y recuperación de datos.  Verificar semestralmente los procedimientos.  Reconstruir los datos a partir de la última copia o grabarlos manualmente en su caso, si existe documentación que lo permita.  Realizar copia de seguridad y aplicar el nivel de seguridad correspondiente, si se realizan pruebas con datos reales. 3. Solo para ficheros no automatizados. 3.a. Criterios de archivo.  El archivado de documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 3.b. Almacenamiento.  Dotar a los dispositivos de almacenamiento de mecanismos que obstaculicen su apertura. 3.c. Custodia de soportes.  Establecer criterios de diligente y custodia de la documentación por parte de la persona a cargo de la misma, durante su revisión o tramitación, para evitar accesos no autorizados. C. Nivel alto. En los siguientes ficheros o tratamientos de datos de carácter personal, ade- más de las medidas de nivel básico y medio, se aplicarán las medidas de nivel alto:  Los que se refieran a datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual.  Los que contengan o se refieran a datos recabados para fines policiales sin consentimiento de las personas afectadas. 44
  • 65. Obligaciones básicas  Aquéllos que contengan datos derivados de actos de violencia de género. Las medidas de seguridad aplicables para los ficheros y tratamiento de datos de nivel básico son las que se detallan a continuación: 1.- Para todos los ficheros (automatizados o no). 1.a. Personal.  Definir las funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios.  Definir de las funciones de control y las autorizaciones delegadas por el responsable  Difundir entre el personal, de las normas que les afecten y las consecuencias por su incumplimiento. 1.b. Incidencias.  Llevar un registro de incidencias en el que se detalle: tipo, momento de su detección, persona que la notifica, efectos y medidas correctoras  Elaborar un procedimiento de notificación y gestión de las incidencias. 1.c. Control de acceso.  Disponer de una relación actualizada de usuarios y accesos autorizados.  Controlar los accesos permitidos a cada usuario según las funcio- nes asignadas.  Implantar mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.  Conceder permisos de acceso sólo el personal autorizado.  Adoptar las mismas medidas para personal ajeno con acceso a los recursos de datos. 1.d. Gestión de soportes.  Crear un inventario de soportes.  Identificar el tipo de información que contienen los soportes, utilizando un sistema de etiquetado que dificulte la identifica- ción para las personas diferentes de los usuarios.  Restringir el acceso al lugar de almacenamiento de los soportes.  Autorizar las salidas de soportes (incluidas a través de e-mail).  Implantar medidas para el transporte y el desecho de soportes.  Cifrar los datos en la distribución de soportes. 45
  • 66. La protección de datos personales: Soluciones en entornos Microsoft  Cifrar la información en dispositivos portátiles fuera de las instalaciones (evitar el uso de dispositivos que no permitan cifrado, o adoptar medidas alternativas). 1.e. Auditoría.  Realizar una auditoría, interna o externa, al menos cada dos años.  Realizar una auditoría ante modificaciones sustanciales en los sistemas de información con repercusiones en seguridad, pese a no haber transcurrido el plazo indicado en el punto anterior.  Verificar y controlar la adecuación de las medidas de seguridad implantadas.  Emitir un informe de las detecciones de deficiencias y propuestas correctoras.  Analizar el informe del responsable de seguridad y remitir las conclusiones al responsable del fichero. 2.- Solo para ficheros automatizados. 2.a. Registro de accesos. (No resulta de aplicación si el responsable del fichero es una persona física y es el único usuario.)  Llevar un registro de accesos en el que se haga constar: usuario, hora, fichero, tipo de acceso, autorizado o denegado.  Revisar el responsable de seguridad el registro de accesos men- sualmente.  Conservar la información del registro de accesos al menos 2 años. 2.b. Gestión de soportes.  Registrar la entrada y salida de soportes en el que se detalle: documento o soporte, fecha, emisor/destinatario, número, tipo de información, forma de envío, responsable autorizada para recepción/entrega. 2.c. Identificación y autenticación.  Implantar mecanismos de identificación y autenticación personalizada de los usuarios.  Crear un procedimiento de asignación y distribución de contraseñas.  Almacenar las contraseñas de forma ininteligible.  Cambiar las contraseñas con una periodicidad mínima de 1 año. 2.d. Copias de respaldo.  Hacer una copia de respaldo semanal.  Establecer procedimientos de generación de copias de respaldo y recuperación de datos. 46
  • 67. Obligaciones básicas  Verificar semestralmente los procedimientos.  Reconstruir los datos a partir de la última copia o grabarlos manualmente en su caso, si existe documentación que lo permita.  Realizar copia de seguridad y aplicar el nivel de seguridad correspondiente, si se realizan pruebas con datos reales.  Conservar una copia de respaldo en lugar diferente del que se encuentren los equipos informáticos que los tratan. 3. Solo para ficheros no automatizados. 3.a. Control de acceso.  Limitar el acceso al personal autorizado.  Establecer mecanismos que permitan identificar los accesos a documentos accesibles por múltiples usuarios. 3.b. Criterios de archivo.  El archivado de documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 3.c. Almacenamiento.  Dotar a los dispositivos de almacenamiento de mecanismos que obstaculicen su apertura.  Localizar los armarios, archivadores u otros elementos donde se almacenen los ficheros en áreas con acceso protegido con puertas con llave u otro dispositivo equivalente. 3.d. Custodia de soportes.  Establecer criterios de diligente y custodia de la documentación por parte de la persona a cargo de la misma, durante su revisión o tramitación, para evitar accesos no autorizados. 3.e. Copia o reproducción.  Limitar la posibilidad de realización a los usuarios autorizados.  Destruir las copias desechadas. Como resumen de las medidas de seguridad aplicables a los ficheros o trata- mientos de datos de carácter personal, haremos uso de un cuadro extraído de la Guía de Seguridad creada por la AEPD en abril de 200822. 22. Vid. AEPD Guía de Seguridad, https://www.agpd.es/portalweb/canalresponsable/guia_documento/ common/pdfs/guia_seguridad.pdf. 47
  • 68. La protección de datos personales: Soluciones en entornos Microsoft NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Responsable  El responsable del seguridad fichero tiene que designar a uno o varios responsables de seguridad (no es una delegación de responsabilidad).  El responsable de seguridad es el encargado de coordinar y controlar las medidas del docu mento. Personal  Funciones y obliga- ciones de los diferentes usuarios o de los perfiles de usuarios claramente definidas y documen- ta da s.  Definición de las funciones de control y las autorizaciones delegadas por el responsable.  Difusión entre el personal, de las normas que les afecten y de las consecuencias por incumplimiento. Incidencias  Registro de inciden- SOLO FICHEROS cias: tipo, momento AUTOMATIZADOS de su detección, persona que la  Anotar los procedi- notifica, efectos y mientos de recupera- medidas correctoras. ción, persona que lo ejecuta, datos  Procedimiento de restaurados, y en su notificación y gestión caso, datos grabados de las incidencias. manu a lmente.  Autorización del responsable del fichero para la recuperación de da tos. 48
  • 69. Obligaciones básicas NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Control de  Relación actualizada SOLO FICHEROS SOLO FICHEROS acceso de usuarios y accesos AUTOMATIZADOS AUTOMATIZADOS autorizados.  Control de acceso  Registro de accesos:  Control de accesos físico a los locales usuario, hora, fichero, permitidos a cada donde se encuentren tipo de acceso, usuario según las ubicados los sistemas autorizado o funciones asignadas. de información. denega do.  Mecanismos que  Revisión mensual del eviten el acceso a registro por el datos o recursos con responsable de derechos distintos de seguridad. los autorizados.  Conservación 2 años.  Concesión de permisos de acceso  No es necesario este sólo por personal registro si el respon- autoriza do. sable del fichero es una persona física y  Mismas condiciones es el único usuario. para personal ajeno con acceso a los SOLO FICHEROS NO recursos de datos. AUTOMATIZADOS  Control de accesos autorizados.  Identificación accesos para documentos accesibles por múltiples usuarios. Identificación y SOLO FICHEROS SOLO FICHEROS autenticación AUTOMATIZADOS AUTOMATIZADOS  Identificación y  Límite de intentos autenticación reiterados de acceso personalizada. no autorizado.  Procedimiento de asignación y distribución de contra señas.  Almacenamiento ininteligible de las contra señas.  Periodicidad del cambio de contrase- ñas (>1 año). 49
  • 70. La protección de datos personales: Soluciones en entornos Microsoft NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Gestión de  Inventario de SOLO FICHEROS SOLO FICHEROS soportes soportes. AUTOMATIZADOS AUTOMATIZADOS  Identificación del tipo  Registro de entrada y  Sistema de etiquetado de información que salida de soportes: confidencial. contienen, o sistema documento o soporte, de etiquetado. fecha, emisor/  Cifrado de datos en la destinatario, número, distribución de  Acceso restringido al soportes. lugar de almacena- tipo de información, miento. forma de envío,  Cifrado de informa- responsable autoriza- ción en dispositivos  Autorización de las da para recepción/ portátiles fuera de las salidas de soportes entrega. instalaciones (evitar (incluidas a través de el uso de dispositivos e-mail). que no permitan  Medidas para el cifrado). transporte y el desecho de soportes. Copias de SOLO FICHEROS SOLO FICHEROS respaldo AUTOMATIZADOS AUTOMATIZADOS  Copia de respaldo  Copia de respaldo y semana l. procedimientos de recuperación en lugar Procedimientos de diferente del que se  generación de copias encuentren los de respaldo y equipos. recuperación de da tos.  Verificación semestral de los procedimien- tos.  Reconstrucción de los datos a partir de la última copia. Grabación manual en su caso, si existe documentación que lo permita.  Pruebas con datos reales. Copia de seguridad y aplica- ción del nivel de seguridad correspon- diente. 50
  • 71. Obligaciones básicas NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Criterios de SOLO FICHEROS NO archivo AUTOMATIZADOS  El archivo de los documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos ARCO. Almacenamiento SOLO FICHEROS NO SOLO FICHEROS NO AUTOMATIZADOS AUTOMATIZADOS  Dispositivos de  Armarios, archivado- alma cenamiento res,… de documentos dotados de mecanis- en áreas con acceso mos que obstaculicen protegido con puertas su apertura. con llave. Custodia SOLO FICHEROS NO soportes AUTOMATIZADOS  Durante la revisión o tramitación de los documentos, la persona a cargo de los mismos debe ser diligente y custodiar- la para evitar accesos no autorizados. Copia SOLO FICHEROS NO o reproducción AUTOMATIZADOS  Sólo puede realizarse por los usuarios autorizados.  Destrucción de copias desechadas. 51
  • 72. La protección de datos personales: Soluciones en entornos Microsoft NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Auditoría  Al menos cada dos años, interna o externa.  Debe realizarse ante modificaciones sustanciales en los sistemas de informa- ción con repercusio- nes en seguridad.  Verificación y control de la adecuación de las medidas.  Informe de detección de deficiencias y propuestas correcto- ras.  Análisis del responsa- ble de seguridad y conclusiones al responsable del fichero. Telecomunica- SOLO FICHEROS ciones AUTOMATIZADOS  Transmisión de datos a través de redes electrónicas cifrada. Traslado de SOLO FICHEROS NO documentación AUTOMATIZADOS  Medidas que impidan el acceso o manipulación. El RLOPD establece, además, algunos supuestos especiales en relación con las medidas de seguridad aplicables a los ficheros o tratamientos, en concreto, relativas a los siguientes: A. Ficheros de los que sean responsables los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas. Respecto a los datos de tráfico y a los datos de localización, se aplicarán, además de las 52
  • 73. Obligaciones básicas medidas de seguridad de nivel básico y medio, la medida de seguridad de nivel alto contenida en el artículo 103 del RLOPD: “Registro de accesos”23. B. Ficheros o tratamientos de datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual. En relación con estos, será suficiente la implantación de las medidas de seguridad de nivel básico cuando:  Los datos se utilicen con la única finalidad de realizar una transferen- cia dineraria a las entidades de las que los afectados sean asociados o miembros. Por ejemplo, la detracción de la cuota sindical de la nómi- na a petición del empleado.  Se trate de ficheros o tratamientos no automatizados en los que de forma incidental o accesoria se contengan aquellos datos sin guardar relación con su finalidad. AEPD ha emitido un Informe Jurídico, relativo a las medidas de seguri- dad en los ficheros de nóminas y demás especialidades, en respuesta a la consulta planteada por un responsable de ficheros 24. C. Ficheros o tratamientos que contengan datos relativos a la salud refe- rentes exclusivamente al grado de discapacidad o la simple declaración de la condición de discapacidad o invalidez del afectado. Del mismo modo que en el caso anterior, resultará suficiente la implantación de las medidas de seguridad de nivel básico, en los ficheros o tratamientos que contengan este tipo de datos, únicamente, con motivo del cumplimiento de deberes públicos (desarrollado en el apartado 3.2). 23. Artículo 103 del RLOPD: “Registro de accesos. 1. De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 2. En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido. 3. Los mecanismos que permiten el registro de accesos estarán bajo el control directo del responsable de seguridad competente sin que deban permitir la desactivación ni la manipulación de los mismos. 4. El período mínimo de conservación de los datos registrados será de dos años. 5. El responsable de seguridad se encargará de revisar al menos una vez al mes la información de control registrada y elaborará un informe de las revisiones realizadas y los problemas detectados. 6. No será necesario el registro de accesos definido en este artículo en caso de que concurran las siguientes circunstancias: a) Que el responsable del fichero o del tratamiento sea una persona física. b) Que el responsable del fichero o del tratamiento garantice que únicamente él tiene acceso y trata los datos personales. La concurrencia de las dos circunstancias a las que se refiere el apartado anterior deberá hacerse constar expresamente en el documento de seguridad.” 24. Vid. AEPD, Informe Jurídico 0156/2008 Medidas de seguridad en los ficheros de nóminas y demás especialidades, https://www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/common/pdfs/ 2008-0156_Medidas-de-seguridad-en-los-ficheros-de-n-oo-minas-y-dem-aa-s-especialidades.pdf. 53
  • 74. La protección de datos personales: Soluciones en entornos Microsoft Con el fin de facilitar la implantación de las medidas de seguridad, cuando en un sistema de información existan ficheros o tratamientos que en función de su finalidad o uso concreto o de la naturaleza de los datos que contengan, requieran la aplicación de un nivel de medidas de seguridad diferente al del sistema principal, el propio RLOPD otorga al responsable del fichero la posibilidad de segregar este último, siendo de aplicación en cada caso el nivel de medidas de seguridad corres- pondiente y siempre que puedan delimitarse los datos afectados y los usuarios con acceso a los mismos. Productos de software. En relación con las medidas de seguridad aplicables a los ficheros de datos de carácter personal, la disposición adicional única del RLOPD introduce una nove- dad, imponiendo una obligación a las empresa que desarrollan productos de software destinados al tratamiento automatizado de datos personales, que deberán incluir en su descripción técnica el nivel de seguridad, básico, medio o alto, que permitan alcanzar dichos productos. Por ello, todas las aplicaciones de software que utilicemos en nuestras organi- zaciones para el tratamiento de ficheros de datos de carácter personal deberán acreditar el nivel de seguridad que permiten alcanzar y deberemos evaluar si el mismo es suficiente de acuerdo con el nivel de seguridad que requiera cada fichero. Si no es así, deberemos sustituir la aplicación por otra que sí nos permita implementar las medidas de seguridad adecuadas. Asimismo, esta materia deberá ser incluida en la Auditoría bienal de aquellas organizaciones que posean ficheros de nivel medio o alto. 4.2.4. La cesión de los datos Como punto de partida, debemos saber que la LOPD -artículo 3.i)- define la cesión o comunicación de datos como “toda revelación de datos realizada a una persona distinta del interesado”, regulándola en su artículo 11. Como principio rector, los datos de carácter personal sólo podrán cederse si se cumplen dos requisitos:  Que se realice para el cumplimiento de fines directamente relacionados con las funciones legítimas del cedente y del cesionario.  Consentimiento previo del interesado. No obstante, existen algunos supuestos en los que no se exige el segundo requisito: consentimiento del interesado. El apartado segundo del citado precepto los recoge expresamente:  Cuando la cesión está autorizada en una Ley. Tradicionalmente, se ha discutido mucho sobre la posibilidad de interpre- tar esta excepción en sentido amplio, considerando que la cesión de datos puede encontrarse amparada por una norma con rango inferior al de Ley, pero la AEPD ha sentado a través de numerosos informes y resoluciones el 54
  • 75. Obligaciones básicas criterio de que la interpretación de la misma ha de hacerse en sentido estricto y, únicamente, admite la aplicación de esta excepción cuando la cesión se encuentra recogida en una norma con rango de Ley o superior. El RLOPD -artículo 10.2.a)- ha desarrollado esta excepción añadiendo la posibili- dad de que se encuentra autorizada en una norma de derecho comunitario y, en particular, cuando concurra uno de los supuestos siguientes: “El tratamiento o la cesión tengan por objeto la satisfacción de un interés legítimo del responsable del tratamiento o del cesionario amparado por dichas normas, siempre que no prevalezca el interés o los derechos y libertades fundamentales de los interesados previstos en el artículo 1 de la Ley Orgánica 15/1999, de 13 de diciembre. El tratamiento o la cesión de los datos sean necesarios para que el responsable del tratamiento cumpla un deber que le imponga una de dichas normas.”  Cuando se trate de datos recogidos de fuentes accesibles al público. En virtud de lo establecido en el artículo 10.2.b) del RLOPD podrá reali- zarse una cesión amparada en esta excepción cuando el tercero a quien se comuniquen los datos tenga un interés legítimo para su tratamiento o conocimiento, siempre que no se vulneren los derechos y libertades fundamentales del interesado. No obstante, las Administraciones públicas sólo podrán comunicar al amparo de la misma los datos recogidos de fuentes accesibles al público a responsables de ficheros de titularidad privada cuando se encuentren autorizadas para ello por una norma con rango de ley. n Cuando el tratamiento responda a la libre y legítima aceptación de una relación jurídica cuyo desarrollo, cumplimiento y control implique necesa- riamente la conexión de dicho tratamiento con ficheros de terceros. En este caso la comunicación sólo será legítima en cuanto se limite a la finalidad que la justifique.  Cuando la comunicación que deba efectuarse tenga por destinatario al Defensor del Pueblo, el Ministerio Fiscal o los Jueces o Tribunales o el Tribunal de Cuentas, en el ejercicio de las funciones que tiene atribuidas. Tampoco será preciso el consentimiento cuando la comunicación tenga como destinatario a instituciones autonómicas con funciones análogas al Defensor del Pueblo o al Tribunal de Cuentas.  Cuando la cesión se produzca entre Administraciones Públicas y tenga por objeto el tratamiento posterior de los datos con fines históricos, estadísticos o científicos. En relación con esta excepción, el RLOPD -artículo 10.4- ha recogido dos nuevos supuestos:  Que los datos de carácter personal hayan sido recogidos o elaborados por una Administración pública con destino a otra. 55
  • 76. La protección de datos personales: Soluciones en entornos Microsoft  Que la comunicación se realice para el ejercicio de competencias idénticas o que versen sobre las mismas materias.  Cuando la cesión de datos de carácter personal relativos a la salud sea necesaria para solucionar una urgencia que requiera acceder a un fichero o para realizar los estudios epidemiológicos en los términos establecidos en la legislación sobre sanidad estatal o autonómica. Añade el artículo 10.5 del RLOPD que: “En particular, no será necesario el consentimiento del interesado para la comunicación de datos personales sobre la salud, incluso a través de medios electrónicos, entre organismos, centros y servicios del Sistema Nacional de Salud cuando se realice para la atención sanita- ria de las personas, conforme a lo dispuesto en el Capítulo V de la Ley 16/2003, de 28 de mayo, de cohesión y calidad del Sistema Nacional de Salud.” Es importante indicar que el destinatario o cesionario, definido en el propio RLOPD como la persona física o jurídica, pública o privada, órgano administrativo o ente sin personalidad jurídica que actúa en el tráfico como sujeto diferenciado al que se revelen los datos, se obliga, por el solo hecho de la comunicación, al cumpli- miento de la LOPD y su normativa de desarrollo. Cesión o comunicación de datos entre empresas del mismo grupo. Respecto de los grupos de empresas, es importante aclarar que la AEPD considera que las comunicaciones de datos realizadas entre las empresas integran- tes de un mismo grupo se consideran cesiones a terceros, sometidas a los requisitos descritos. Como consecuencia, no se considera válido el consentimiento obtenido mediante cláusulas genéricas que se limiten a recoger el consentimiento para la cesión de datos a empresas del grupo. La AEPD emitió en el año 2004 un informe jurídico25, como respuesta a una consulta en la que se planteaba si resultaba conforme a derecho el tratamiento y comunicación de datos entre las empresas de un mismo grupo con fines de publici- dad y promoción, en el que tras analizar la cláusula utilizada para la obtención del consentimiento, concluye considerar la cesión como ajustada a derecho porque dicha cláusula incluía todos los requisitos exigidos en el artículo 5.1 de la LOPD, lo que implica que el consentimiento ha sido otorgado válidamente. 4.2.5. El acceso a datos por cuenta de terceros La LOPD define al encargado de tratamiento en el artículo 3.g) como: “La persona física o jurídica, autoridad pública, servicio o cualquier otro organismo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsa- 25. Vid. AEPD, Informe Jurídico 325/2004 Comunicación de datos entre empresas de un mismo grupo, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/cesion_datos/common/pdfs/2004- 0325_Comunicaci-oo-n-de-datos-entre-empresas-de-un-mismo-grupo.pdf. 56
  • 77. Obligaciones básicas ble del tratamiento” y el artículo 5.1.i) del RLOPD se expresa en los siguientes términos: “La persona física o jurídica, pública o privada, u órgano administrativo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsa- ble del tratamiento o del responsable del fichero, como consecuencia de la existencia de una relación jurídica que le vincula con el mismo y delimita el ámbito de su actuación para la prestación de un servicio”. La AEPD reproduce la doctrina de la Audiencia Nacional sobre el alcance de este concepto en su Informe jurídico 0309/2008 26, clarificando el significado de encargado de tratamiento y su alcance. Así, la Sentencia de 28 de septiembre de 2005 recuerda que: “La diferencia entre encargado del tratamiento y cesión en algunos casos reviste cierta complejidad, pero como ha señalado esta Sección en la reciente sentencia de 12 de abril de 2005 (recurso 258/2003) lo típico del encargo de tratamiento es que un sujeto externo o ajeno al responsable del fichero va a tratar datos de carácter personal pertenecientes a los tratamientos efectuados por aquél con objeto de prestarle un servicio en un ámbito concreto..... Siendo esencial para no desnaturali- zar la figura, que el encargado del tratamiento se limite a realizar el acto material de tratamiento encargado, y no siendo supuestos de encargo de tratamiento aque- llos en los que el objeto del contrato fuese el ejercicio de una función o actividad independiente del encargado. En suma, existe encargo de tratamiento cuando la transmisión o cesión de datos está amparada en la prestación de un servicio que el responsable del tratamiento recibe de una empresa externa o ajena a su propia organización, y que ayuda en el cumplimiento de la finalidad del tratamiento de datos consentida por el afectado”. En consecuencia, para determinar si nos encontramos en presencia de un encargado del tratamiento deberá analizarse si su actividad se encuentra limitada a la mera prestación de un servicio al responsable, sin generarse ningún vínculo entre el afectado y el supuesto encargado. Además, será preciso que corresponda al responsable el poder de decisión sobre la finalidad que justifica el tratamiento, de manera que si el tratamiento procede de la voluntad del encargado, este tendrá en todo caso la condición de responsable. Se entenderá que una empresa es encargada del tratamiento cuando no puede decidir sobre el contenido, finalidad y uso del tratamiento y siempre que su activi- dad no le reporte otro beneficio que el derivado de la prestación de servicios propia- mente dicha, sin utilizar los ficheros generados en modo alguno en su provecho, puesto que en ese caso pasaría a ser responsable del fichero. El artículo 12 de la LOPD regula el acceso a datos por cuenta de terceros. En cumplimiento de lo establecido en el mismo, las prestaciones de servicios al respon- 26. Vid. AEPD, Informe Jurídico 0309/2008 Los ensobrados y recepción de direcciones de personas físicas para efectuar envíos configura a la empresa como encargado de tratamiento, https://212.170.242.196/ portalweb/canaldocumentacion/informes_juridicos/conceptos/common/pdfs/2008-0309_Los-ensobrados-y- recepci-oo-n-de-direcciones-de-personas-f-ii-sicas-para-efectuar-env-ii-os-configura-a-la-empresa-como- encargado-del-tratamiento.pdf. 57
  • 78. La protección de datos personales: Soluciones en entornos Microsoft sable de los ficheros que impliquen un acceso a datos de carácter personal conteni- dos en los mismos, deben regularse a través de un contrato escrito en el que se establezcan los términos en los que se producirá el citado acceso o tratamiento de datos personales. El servicio prestado podrá tener o no carácter remunerado y ser temporal o indefinido. El contrato deberá recoger, como mínimo, el siguiente contenido:  Obligación del encargado del tratamiento de tratar los datos conforme a las instrucciones del responsable del fichero o tratamiento.  Prohibición de utilizar los datos con fin distinto al que figura en el contrato.  Prohibición de comunicar los datos a terceras personas, ni siquiera para su conservación.  Medidas de seguridad que, en virtud del Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la LOPD (en adelante, RLOPD), el encargado del tratamiento está obligado a cumplir en el tratamiento de los datos personales.  Obligación de devolver los datos al responsable del fichero o destruirlos una vez concluida la prestación contractual.  Responsabilidades del encargado del tratamiento por incumplimiento de las anteriores obligaciones, en cuyo caso será considerado también respon- sable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. El RLOPD recoge que se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado, así como la obligación del responsable del trata- miento de velar por que el encargado del mismo reúna las garantías para el cumpli- miento de lo dispuesto en dicho cuerpo normativo. Esto se traducirá en la práctica en la necesidad de que el responsable del fichero articule algún sistema que le permita llevar un control de la actividad desarrollada por su prestador de servicios. Por ejemplo, establecer en el contrato de acceso y tratamiento de datos la posibili- dad del responsable del fichero de solicitar el informe de las auditorías realizadas. En el caso de que el encargado del tratamiento destine los datos a otra finali- dad, los comunique o los utilice incumpliendo las estipulaciones del contrato en el que se ha regulado el acceso a datos, se considerará responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. No obstante, el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero desig- nado por aquél, al que hubiera encomendado la prestación de un servicio. Posibilidad de subcontratación de los servicios. La LOPD no establece nada en relación con la posibilidad de subcontratación de los servicios por parte del encargado de tratamiento. 58
  • 79. Obligaciones básicas En su Memoria del año 2000, la AEPD realizaba la interpretación que se recoge a continuación, al analizar la figura del encargado de tratamiento: “En lo referente a la cesión de los datos, de lo establecido en la el artículo 12.2 se desprende que no se producirá esa cesión, de forma que los datos habrán de ser entregados única y exclusivamente al responsable del fichero. Ello implica, a nuestro juicio, la posibilidad de proceder a una subcontratación de este tipo de servicios por parte del encargado del tratamiento, debiendo siembre el responsable ser parte de la relación jurídica, ya que cualquier transmisión de los datos a un tercero que no corresponda al responsable del fichero habrá de ser considerada cesión”. No obstante, la AEPD consciente de que la subcontratación de servicios es una realidad y que prohibirla originaría muchos problemas en la práctica, establece en la citada Memoria fórmulas a través de las cuales se podría realizar y, además, la Memoria de 2001 admitió la subcontratación cuando se cumplieran determinados requisitos. El Artículo 21 del RLOPD regula por primera vez la posibilidad de subcontratar servicios por parte del encargado de servicios, sentando como regla general la prohibición del encargado del tratamiento de subcontratar con un tercero la realización de ningún tratamiento que le hubiera encomendado el responsable del mismo, salvo que hubiera obtenido de éste autorización para ello. En este caso, la contratación se efectuará siempre en nombre y por cuenta del responsable del tratamiento. No obstante, admite la posibilidad de subcontratar sin necesidad de autoriza- ción siempre y cuando se cumplan los siguientes requisitos:  Que se especifiquen en el contrato los servicios que puedan ser objeto de subcontratación y, si ello fuera posible, la empresa con la que se vaya a subcontratar.  Cuando no se identificase en el contrato la empresa con la que se vaya a subcontratar, será preciso que el encargado del tratamiento comunique al responsable los datos que la identifiquen antes de proceder a la subcontratación.  Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero. Que el encargado del tratamiento y la empresa subcontratista formalicen el contrato, en los términos previstos en el artículo anterior.  En este caso, el subcontratista será considerado encargado del tratamiento y, como tal tendrá que cumplir las obligaciones que la normativa le impone. Si durante la prestación del servicio resulta necesario subcontratar una parte del mismo y dicha circunstancia no hubiera sido prevista en el contrato, deberán someterse al responsable del tratamiento los extremos señalados. 59
  • 80. La protección de datos personales: Soluciones en entornos Microsoft Conservación de los datos por el encargado del tratamiento. Si bien el artículo 22 del RLOPD regula la conservación de los datos por el encargado de tratamiento, establece unas obligaciones que resultan sumamente confusas. En su primer apartado establece que, una vez cumplida la prestación contrac- tual, los datos de carácter personal deberán ser destruidos o devueltos al responsa- ble del tratamiento o al encargado que éste hubiese designado, al igual que cual- quier soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento y a continuación que no procederá la destrucción de los datos cuando exista una previsión legal que exija su conservación, en cuyo caso deberá procederse a la devolución de los mismos garantizando el responsable del fichero dicha conservación. También establece la obligación para el encargado de trata- miento de conservar, debidamente bloqueados, los datos en tanto pudieran derivar- se responsabilidades de su relación con el responsable del tratamiento. Pensemos que aquí es donde se puede crear la confusión, dado que si se cumple esta obliga- ción, el encargado de tratamiento no podrá destruir o devolver los datos, cumplien- do la obligación impuesta en el primer apartado. Las medidas de seguridad en relación con el encargado del tratamiento. El artículo 82 del RLOPD establece algunas obligaciones en relación con este tema, en concreto:  Cuando un encargado de tratamiento preste sus servicios en los locales del responsable, esto deberá constar en el documento de seguridad del responsable, comprometiéndose el personal del encargado al cumplimien- to de las medidas de seguridad previstas en el mismo.  Cuando el acceso sea remoto, habiéndose prohibido al encargado incorpo- rar los datos objeto de tratamiento a sistemas o soportes distintos de los del responsable, este deberá dejar constancia de ello en su documento de seguridad, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento.  Cuando un encargado de tratamiento preste los servicios contratados en sus propios locales, deberá elaborar un documento de seguridad o com- pletar el que ya tuviera, identificando el fichero o tratamiento y el respon- sable del mismo e incorporando las medidas de seguridad a implantar en relación con dicho tratamiento.  En todo caso, el acceso a los datos por el encargado del tratamiento estará sometido a las medidas de seguridad contempladas en el RLOPD. 4.2.6. Prestaciones de servicios sin acceso a datos personales El RLOPD regula una figura novedosa en materia de protección de datos: las prestaciones de servicios sin acceso a datos personales, estableciendo la obligación 60
  • 81. Obligaciones básicas para el responsable del fichero o tratamiento de adoptar las medidas adecuadas para limitar el acceso del personal a datos personales, a los soportes que los conten- gan o a los recursos del sistema de información, para la realización de trabajos que no impliquen el tratamiento de datos personales. Dispone, además, que cuando se trate de personal ajeno, el contrato de presta- ción de servicios recogerá expresamente la prohibición de acceder a los datos personales y la obligación de secreto respecto a los datos que el personal hubiera podido conocer con motivo de la prestación del servicio, no resultando necesario firmar un contrato de acceso y tratamiento de datos, en los términos establecidos en el artículo 12 de la LOPD. ¿En las prestaciones sin acceso a datos existen obligaciones de seguridad? La respuesta de la AEPD a esta pregunta se encuentra al alcance de todos los ciudadanos a través de su página web27: “Cualquier actividad que suponga un contacto directo o indirecto con el sistema de información y/o su entorno físico o lógico puede ser susceptible de poner en riesgo la seguridad de los datos:  Limpieza.  Seguridad.  Mantenimiento o reparación de instalaciones (que no se refiera al propio sistema de información). Incluye servicios de destrucción o almacenamiento de soportes cuando el prestador desconozca el criterio de archivo o no pueda recuperar dato alguno.” 4.2.7. La modificación de ficheros Siguiendo lo dispuesto en el artículo 58 del RLOPD y, dado que la inscripción de un fichero de datos de carácter personal que obra en el RGPD debe encontrarse actualizada en todo momento, cualquier modificación que afecte al contenido de la misma deberá ser previamente notificada a la AEPD o a las autoridades de control autonómicas competentes, a fin de proceder a su inscripción en el RGPD. Cuando se trate de un fichero de titularidad pública debe adoptarse, con carácter previo a la notificación, la correspondiente norma o acuerdo en los términos previstos al tratar la creación de ficheros. 4.2.8. Las transferencias internacionales de datos La norma general no permite al responsable de los ficheros realizar transferen- cias internacionales de datos de carácter personal que hayan sido objeto de trata- 27. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008, https:// www.agpd.es/portalweb/jornadas/1_sesion_abierta/common/faqs_bloque_1.pdf. 61
  • 82. La protección de datos personales: Soluciones en entornos Microsoft miento o hayan sido recogidos para someterlos a dicho tratamiento con destino a países que no proporcionen un nivel de protección equiparable al que presta LOPD, salvo que cumplan los siguientes requisitos:  Se haya observado lo dispuesto en la LOPD.  Se obtenga autorización previa del Director de la AEPD. El carácter adecuado del nivel de protección que ofrece el país de destino se evaluará por la AEPD atendiendo a todas las circunstancias que concurran en la transferencia o categoría de transferencia de datos. En la actualidad se consideran países con nivel de protección adecuado al que presta la LOPD los Estados Miembros de la Unión Europea, Islandia, Liechtenstein, Noruega y los Estados que la Comisión Europea ha declarado que garantizan un nivel de protección adecuado: Suiza, Argentina, Guernsey, Isla de Man, las entida- des estadounidenses adheridas a los principios de Puerto Seguro 28, Canadá respecto de las entidades sujetas al ámbito de aplicación de la ley canadiense de protección de datos y los datos personales incluidos en los registros de nombres de los pasaje- ros que se transfieren al Servicio de aduanas y protección de fronteras de los Esta- dos Unidos de América. La propia LOPD reconoce algunas excepciones a la norma general, de manera que no será necesaria la autorización previa del Director de la AEPD en los siguien- tes supuestos:  Cuando la transferencia internacional de datos de carácter personal resulte de la aplicación de tratados o convenios en los que sea parte España.  Cuando la transferencia se haga a efectos de prestar o solicitar auxilio judicial internacional.  Cuando la transferencia sea necesaria para la prevención o para el diag- nóstico médicos, la prestación de asistencia sanitaria o tratamiento médi- cos o la gestión de servicios sanitarios.  Cuando se refiera a transferencias dinerarias conforme a su legislación específica.  Cuando el afectado haya dado su consentimiento inequívoco a la transfe- rencia prevista.  Cuando la transferencia sea necesaria para la ejecución de un contrato entre el afectado y el responsable del fichero o para la adopción de medi- das precontractuales adoptadas a petición del afectado.  Cuando la transferencia sea necesaria para la celebración o ejecución de un contrato celebrado o por celebrar, en interés del afectado, por el res- ponsable del fichero y un tercero. 28. La lista de entidades estadounidenses adheridas a los principios de Puerto Seguro se encuentra accesible en www.export.gov/safeharbor. 62
  • 83. Obligaciones básicas  Cuando la transferencia sea necesaria o legalmente exigida para la salva- guarda de un interés público. Tendrá esta consideración la transferencia solicitada por una Administración fiscal o aduanera para el cumplimiento de sus competencias.  Cuando la transferencia sea precisa para el reconocimiento, ejercicio o defensa de un derecho en un proceso judicial.  Cuando la transferencia se efectúe, a petición de persona con interés legítimo, desde un Registro Público y aquélla sea acorde con la finalidad del mismo.  Cuando la transferencia tenga como destino un Estado miembro de la Unión Europea, o un Estado respecto del cual la Comisión de las Comuni- dades Europeas, en el ejercicio de sus competencias, haya declarado que garantiza un nivel de protección adecuado. El RLOPD introduce una novedad al definir la transferencia internacional de datos como el “Tratamiento de datos que supone una transmisión de los mismos fuera del territorio del Espacio Económico Europeo, bien constituya una cesión o comunicación de datos, bien tenga por objeto la realización de un tratamiento de datos por cuenta del respon- sable del fichero establecido en territorio español.” Esto supone un cambio ya que, si bien realizando una interpretación literal de la LOPD un movimiento de datos a países de la Unión Europea supone una transfe- rencia internacional de datos para la que no se necesita autorización previa del Director de la AEPD, de la definición aportada por el RLOPD se desprende que dicho movimiento de datos no se considera transferencia internacional. 4.3. Una vez finalizado el tratamiento 4.3.1. La cancelación y el bloqueo de los datos En función de lo establecido en el artículo 4.5. de la LOPD, el responsable de ficheros se verá obligado a cancelar los datos de carácter personal cuando hayan dejado de ser necesarios o pertinentes para la finalidad para la cual hubieran sido recabados o registrados, de manera que no podrá conservarlos en forma que permi- ta la identificación del interesado durante un período superior al necesario para los fines en base a los cuales los hubiera recabado o registrado. El RLOPD recuerda la obligación de cancelar los datos cuando dejan de ser necesarios o pertinentes para la finalidad para la cual han registrados o recabados, añadiendo que, no obstante, podrán conservarse durante el tiempo en que pueda exigirse algún tipo de responsabilidad derivada de una relación u obligación jurídica o de la ejecución de un contrato o de la aplicación de medidas precontractuales solicitadas por el interesado. Una vez cumplido el período al que se refieren los párrafos anteriores, los datos sólo podrán ser conservados previa disociación de los mismos, sin perjuicio 63
  • 84. La protección de datos personales: Soluciones en entornos Microsoft de la obligación de bloqueo prevista en la LOPD y el RLOPD. En este sentido, debemos saber que un procedimiento de disociación es todo tratamiento de datos personales que permita la obtención de datos disociados. 4.3.2. La supresión de ficheros Cuando el responsable de un fichero decida su supresión, deberá notificarla a AEPD o a las autoridades de control autonómicas competentes, a fin de proceder a la supresión del mismo en el RGPD. Cuando se trate de un fichero de titularidad pública debe adoptarse con carácter previo a la notificación la correspondiente norma o acuerdo en los mismos términos que en los casos de creación y modificación de ficheros, ya tratados ante- riormente. Una vez tramitado el procedimiento establecido, el Director de la AEPD dictará resolución acordando la cancelación de la inscripción del fichero. Hasta ahora hemos hablado de la supresión de ficheros a instancia de parte, pero el artículo 61 del RLOPD establece la posibilidad de que sea el propio Director de la AEPD quien, en ejercicio de sus competencias, acuerde de oficio la cancelación de la inscripción de un fichero. Para ello, han de concurrir circunstancias que acrediten la imposibilidad de que exista y ha de seguirse el mismo procedimiento que en los casos de supresión a instancia del responsable del fichero. 4.3.2.1. El deber de secreto El deber de secreto, es una obligación que subsistirá en relación con los usua- rios de los datos, aun después de finalizar sus relaciones con el titular del fichero o, en su caso, con el responsable del mismo. 64
  • 85. 5 Los derechos de los titulares de los datos 5.1. La impugnación de valoraciones En función de lo establecido en el artículo 13.1 de la LOPD: “Los ciudadanos tienen derecho a no verse sometidos a una decisión con efectos jurídicos, sobre ellos o que les afecte de manera significativa, que se base únicamen- te en un tratamiento de datos destinados a evaluar determinados aspectos de su personalidad”. Como consecuencia de ello, el titular de los datos puede impugnar los actos administrativos o decisiones privadas que impliquen una valoración de su compor- tamiento, cuyo único fundamento sea un tratamiento de datos de carácter personal que ofrezca una definición de sus características o personalidad, disponiendo del derecho a obtener información del responsable del fichero sobre los criterios de valoración y el programa utilizados en el tratamiento que sirvió para adoptar la decisión en que consistió el acto. Finalmente, recoge que la valoración sobre el comportamiento de los ciudada- nos basada en un tratamiento de datos, únicamente podrá tener valor probatorio a petición del afectado. 5.2. El derecho de consulta al Registro General de Protección de Datos El artículo 14 de la LOPD reconoce el derecho de consulta al RGPD, en virtud del cual: “Cualquier persona podrá conocer, recabando a tal fin la información oportuna del Registro General de Protección de Datos, la existencia de tratamientos de datos de 65
  • 86. La protección de datos personales: Soluciones en entornos Microsoft carácter personal, sus finalidades y la identidad del responsable del tratamiento. El Registro General será de consulta pública y gratuita”. 5.3. El derecho de indemnización El artículo 19 de la LOPD reconoce el derecho a indemnización. Con base en este, todos los interesados que, como consecuencia del incumplimiento de lo dis- puesto en la LOPD por el responsable o el encargado del tratamiento, sufran daño o lesión en sus bienes o derechos tendrán derecho a ser indemnizados. Cuando se trate de ficheros de titularidad pública, la responsabilidad se exigirá de acuerdo con la legislación reguladora del régimen de responsabilidad de las Administraciones Públicas. En el caso de los ficheros de titularidad privada, la acción se ejercitará ante los órganos de la jurisdicción ordinaria. 5.4. Los derechos ARCO De acuerdo con lo dispuesto en los artículos 15, 16 y 17 de la LOPD y 23 a 26 del RLOPD, los titulares de los datos de carácter personal tienen una serie de derechos personalísimos en relación con sus datos de carácter personal, que pueden ejercitar ante el responsable del fichero o ante el encargado del tratamiento. Ejercicio de los derechos Los derechos podrán ser ejercitados por:  el afectado acreditando su identidad,  su representante legal que habrá de acreditar tal condición, cuando el afectado se encuentre en situación de incapacidad o minoría de edad que le imposibilite el ejercicio personal de estos derechos,  el representante voluntario expresamente designado para el ejercicio del derecho, junto con copia del Documento Nacional de Identidad o docu- mento equivalente del representado y la representación conferida por aquél. No es necesario poder notarial general o especial. Atención a las solicitudes Las solicitudes de acceso, rectificación, cancelación y oposición deben atenderse con independencia de que figuren o no datos personales del afectado en los ficheros del responsable y aun cuando el afectado no hubiese utilizado el proce- dimiento establecido específicamente por el responsable del fichero siempre que haya utilizado un medio que permita acreditar el envío y la recepción de la solicitud y ésta contenga lo siguiente: 66
  • 87. Los derechos de los titulares de los datos  Nombre y apellidos del interesado; fotocopia de su documento nacional de identidad, o de su pasaporte u otro documento válido que lo identifi- que y, en su caso, de la persona que lo represente, o instrumentos electró- nicos equivalentes; así como el documento o instrumento electrónico acreditativo de tal representación. La utilización de firma electrónica identificativa del afectado eximirá de la presentación de las fotocopias del DNI o documento equivalente.  Petición en que se concreta la solicitud.  Dirección a efectos de notificaciones, fecha y firma del solicitante.  Documentos acreditativos de la petición que formula, en su caso. Cuando la solicitud no reúna alguno de los requisitos, el responsable del fichero solicitará la subsanación en un plazo de diez días. Una vez realizada la subsanación, empieza el plazo para contestar por el responsable. Cuando se hace referencia a plazos por días, son días hábiles y cuando el plazo sea por meses, se computa de fecha a fecha. Corresponde al responsable del tratamiento la prueba del cumplimiento del deber de respuesta, debiendo conservar la acreditación del cumplimiento del mencionado deber (de la respuesta). El responsable del fichero adoptará las medidas para garantizar que las personas de su organización con acceso a datos de carácter personal puedan infor- mar del procedimiento a seguir por el afectado para el ejercicio de sus derechos. Cuando el responsable del fichero disponga de servicios de atención al público o el ejercicio de reclamaciones por el servicio prestado o productos ofertados, podrá concederse la posibilidad al afectado de ejercer dichos derechos a través de esos servicios. En tal caso, la identidad del interesado se considerará acreditada por los medios establecidos para la identificación de los clientes del responsable en la prestación de sus servicios o contratación de sus productos. Cuando se ejerciten los derechos ante un encargado del tratamiento, el encar- gado deberá dar traslado de la solicitud al responsable, a fin de que por el mismo se resuelva, a menos que en la relación existente con el responsable del tratamiento se prevea que el encargado atenderá, por cuenta del responsable, las solicitudes de ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación u oposición. Los derechos se pueden ejercitar a través de correo electrónico y de llamadas a teléfonos gratuitos. Para comprobar la identidad del afectado se pueden pedir datos adicionales que sólo el afectado conozca o bien grabar las llamadas (informando de ello) para comprobar que se trata de la misma persona. Los derechos serán denegados cuando la solicitud sea formulada por persona distinta del afectado y no se acredite la representación. 67
  • 88. La protección de datos personales: Soluciones en entornos Microsoft Estos derechos son los siguientes:  Derecho de acceso.  Derecho de rectificación.  Derecho de cancelación.  Derecho de oposición al tratamiento o cese en el tratamiento. 5.4.1. El derecho de acceso El derecho de acceso es el derecho del afectado a obtener información sobre si sus propios datos de carácter personal están siendo objeto de tratamiento, la finali- dad del tratamiento que, en su caso, se esté realizando, así como la información disponible sobre el origen de dichos datos y las comunicaciones realizadas o previs- tas de los mismos. El afectado podrá obtener del responsable del tratamiento información relativa a datos concretos, a datos incluidos en un determinado fichero o a la totalidad de sus datos sometidos a tratamiento. El responsable del fichero responderá la solicitud de acceso en el plazo máxi- mo de un mes a contar desde la recepción de la solicitud. Transcurrido el plazo sin que de forma expresa se responda a la petición de acceso, el interesado podrá interponer una reclamación ante la AEPD y, en el caso de que no disponga de datos de carácter personal de los afectados, deberá igualmente comunicárselo en el mismo plazo. Si la solicitud fuera estimada y el responsable no acompañase a su comunica- ción la información solicitada, el acceso se hará efectivo durante los diez días siguientes a dicha comunicación. La información que se proporcione comprenderá todos los datos de base del afectado, los resultantes de cualquier elaboración o proceso informático, así como la información disponible sobre el origen de los datos, los cesionarios de los mismos y la especificación de los concretos usos y finalidades para los que se almacenaron los datos. El responsable del fichero o tratamiento podrá denegar el acceso a los datos de carácter personal cuando el derecho ya se haya ejercitado en los doce meses anterio- res a la solicitud, salvo que se acredite un interés legítimo al efecto. En todo caso, el responsable del fichero informará al afectado de su derecho a recabar la tutela de la AEPD o, en su caso, de las autoridades de control de las Comunidades Autónomas. 5.4.2. El derecho de rectificación El afectado puede ejercitar su derecho de rectificación, solicitando la modifica- ción de los datos inexactos o incompletos relativos a su persona que estén incluidos 68
  • 89. Los derechos de los titulares de los datos en ficheros. La solicitud debe indicar a qué datos se refiere, la corrección que haya de realizarse e ir acompañada de la documentación justificativa de lo solicitado. El responsable del fichero resolverá sobre la solicitud en el plazo máximo de 10 días a contar desde la recepción de la misma, tanto si se dispone de datos del afectado o no. Si los datos rectificados han sido cedidos previamente, el responsable del fichero debe comunicar la rectificación efectuada al cesionario en el mismo plazo para que éste, también en 10 días contados desde la recepción de dicha comunica- ción, proceda a rectificar los datos. 5.4.3. El derecho de oposición Mediante el derecho de oposición, el afectado solicita que no se lleve a cabo el tratamiento de sus datos personales o el cese en el mismo cuando:  no sea necesario su consentimiento para el tratamiento, como consecuen- cia de la concurrencia de un motivo legítimo y fundado, referido a su concreta situación personal, que lo justifique, siempre que una Ley no disponga lo contrario. La solicitud deberá recoger los motivos fundados y legítimos que lo justifiquen.  se trate de ficheros que tengan por finalidad la realización de actividades de publicidad y prospección comercial.  el tratamiento tenga por finalidad la adopción de una decisión referida al afectado y basada únicamente en un tratamiento automatizado de sus datos de carácter personal (destinado a evaluar determinados aspectos de su personalidad tales como su rendimiento laboral, crédito, fiabilidad o conducta). El responsable del fichero resolverá sobre la solicitud de oposición en el plazo máximo de diez días a contar desde la recepción de la solicitud, tenga o no datos personales del afectado. El responsable del fichero o tratamiento deberá excluir del tratamiento los datos relativos al afectado que ejercite su derecho de oposición o denegar motivadamente la solicitud del interesado en el plazo de diez días a contar desde la recepción de la solicitud. Se podrán conservar los mínimos datos imprescindibles de los afectados que hayan manifestado su negativa a recibir publicidad, con el fin de poder identificar- los y adoptar las medidas necesarias que eviten el envío de publicidad. Cuando el afectado manifieste su oposición a recibir publicidad, se le deberá informar de la existencia de ficheros comunes de exclusión generales o sectoriales, así como de la identidad de su responsable, su domicilio y la finalidad del trata- miento. 69
  • 90. La protección de datos personales: Soluciones en entornos Microsoft Antes de realizar un tratamiento de datos con fines publicitarios o de prospec- ción comercial, será necesario consultar los ficheros comunes de exclusión que pudieran afectar a esta actuación, con el fin de evitar que sean objeto de tratamiento datos de afectados que hubieran manifestado su oposición o negativa al mismo. 5.4.4. El derecho de cancelación Mediante el ejercicio del derecho de cancelación el afectado solicita la cancela- ción de los datos que resulten ser inadecuados o excesivos indicando a qué datos se refiere, aportando en su caso, la documentación que lo justifique. El responsable del fichero resolverá sobre la solicitud en el plazo máximo de 10 días a contar desde la recepción de la solicitud, tanto si se dispone o no de datos personales del afectado. La cancelación implica el bloqueo de los datos, consistente en la identificación y reserva de los datos con el fin de impedir su tratamiento excepto para su puesta a disposición de las Administraciones públicas, Jueces y Tribunales, para la atención de las posibles responsabilidades nacidas del tratamiento y sólo durante el plazo de prescripción de dichas responsabilidades. Transcurrido ese plazo deberá procederse a la supresión de los datos. Si los datos cancelados hubieran sido cedidos previamente, el responsable del fichero comunicará la cancelación efectuada al cesionario, en idéntico plazo, para que éste, también en el plazo de diez días contados desde la recepción de dicha comunicación, proceda a cancelar los datos. Cancelación versus revocación del consentimiento La cancelación de los datos se puede solicitar siempre y cuando los datos resulten inadecuados o excesivos, por lo que es necesario justificar o motivar dicha inadecuación o exceso. La revocación se puede pedir cuando se ha consentido previamente al tratamien- to de los datos y se quiere retirar dicho consentimiento; por lo que no es necesario aportar justificación, se revoca sin más el consentimiento a tratar los datos y no se le puede pedir al afectado más de lo que se le pidió para recabar su consentimiento. Cancelación de datos relativos a personas fallecidas Las personas vinculadas al fallecido, por razones familiares o análogas, podrán dirigirse a los responsables de los ficheros o tratamientos que contengan datos de éste con la finalidad de notificar el óbito, aportando acreditación suficiente del mismo, y solicitar la cancelación de datos cuando haya lugar a ello. 5.5. La tutela de los derechos El artículo 18 de la LOPD regula la tutela de derechos, estableciendo las siguientes normas: 70
  • 91. Los derechos de los titulares de los datos  Las actuaciones contrarias a lo dispuesto en la presente Ley pueden ser objeto de reclamación por los interesados ante la AEPD.  El interesado al que se deniegue, total o parcialmente, el ejercicio de los derechos de oposición, acceso, rectificación o cancelación, podrá ponerlo en conocimiento de la AEPD, en su caso, del Organismo competente de cada Comunidad Autónoma, que deberá asegurarse de la procedencia o improcedencia de la denegación. El plazo máximo en que debe dictarse la resolución expresa de tutela de derechos será de seis meses y contra las resoluciones de la AEPD procederá recurso contencioso-administrativo. En el apartado 8.6.2 veremos el procedimiento de tutela de los derechos de acceso, rectificación, cancelación y oposición. 71
  • 92. La protección de datos personales: Soluciones en entornos Microsoft 72
  • 93. 6 Tratamientos especiales La normativa de protección de datos de carácter personal regula determinados tratamientos de datos que se consideran especiales por la finalidad de los ficheros que los contienen y los requisitos necesarios para la inclusión de datos en los mis- mos. 6.1. Prestación de servicios de información sobre solvencia patrimonial y crédito Para comenzar a hablar del régimen aplicable a los ficheros de solvencia patrimonial y crédito es necesario definir primero las partes intervinientes en este tipo de tratamiento de datos. En primer lugar encontramos al “responsable del fichero común” que será aquella entidad que acuerda la creación del fichero de información sobre solvencia patrimo- nial y crédito. Estos ficheros, según lo establecido en el artículo 29 de la LOPD, pueden incluir datos de carácter personal obtenidos de los registros y las fuentes accesibles al público o procedentes de informaciones facilitadas por el interesado o con su consentimiento. Asimismo, podrán incorporar datos relativos al cumplimien- to o incumplimiento de obligaciones dinerarias facilitados por el acreedor o por quien actúe por su cuenta o interés. En segundo lugar, y enlazando con el párrafo anterior, tendríamos a las “enti- dades que facilitan los datos al fichero común”. Dichas entidades serán las acreedoras que comunican datos relativos al incumplimiento de obligaciones dinerarias. En tercer lugar, es necesario hacer referencia a las “entidades participantes en el sistema” o terceros que serán aquellas que pueden consultar el fichero común accediendo a datos suministrados por otras entidades o procedentes de registros, fuentes accesibles al público o del propio interesado. 73
  • 94. La protección de datos personales: Soluciones en entornos Microsoft Por último, estaría el “interesado” o deudor, que tendrá derecho a ser informa- do del tratamiento de sus datos así como a ejercitar sus derechos ARCO. De esta forma, cuando lo solicite, el responsable del fichero común le comunicará los datos, las evaluaciones y apreciaciones que sobre el mismo hayan sido comunicadas durante los últimos seis meses, y el nombre y dirección de la persona o entidad a quien se hayan revelado los datos. Sólo se podrán registrar y ceder los datos de carácter personal que sean determinantes para enjuiciar la solvencia económica de los interesados y que no se refieran, cuando sean adversos, a más de seis años, siempre que respondan con veracidad a la situación actual de aquellos. Los artículos 37 a 44 del RLOPD desarrollan las características especiales de estos ficheros, derechos de los interesados y obligaciones del responsable y entida- des participantes en el sistema. 6.1.1. Requisitos para la inclusión de los datos Para poder incorporar datos de carácter personal en este tipo de ficheros será necesario: a) Que exista una deuda cierta, vencida, exigible, que haya resultado impa- gada y respecto de la cual no se haya entablado reclamación judicial, arbitral o administrativa, o tratándose de servicios financieros, no se haya planteado una reclamación en los términos previstos en el Reglamento de los Comisionados para la defensa del cliente de servicios financieros, aprobado por Real Decreto 303/2004, de 20 de febrero. b) Que no hayan transcurrido seis años desde la fecha en que hubo de procederse al pago de la deuda o del vencimiento de la obligación o del plazo concreto si aquélla fuera de vencimiento periódico. c) Requerimiento previo de pago a quien corresponda el cumplimiento de la obligación. En todo caso el acreedor, o quien actúe por su cuenta o interés, deberá conservar a disposición del “responsable del fichero común” y de la AEPD la documentación que acredite el cumplimiento de estos requisitos. 6.1.2. Información previa a la inclusión El acreedor deberá informar al deudor, en el momento en que se celebre el contrato y, en todo caso, al tiempo de efectuar el requerimiento previo de pago, que en caso de no producirse el pago en el término previsto para ello, los datos relativos al impago podrán ser comunicados a ficheros relativos al cumplimiento o incumpli- miento de obligaciones dinerarias. 6.1.3. Notificación de la inclusión El “responsable del fichero común” deberá enviar una notificación respecto de los datos incluidos y la posibilidad de ejercitar los derechos ARCO, en el plazo de 74
  • 95. Tratamientos especiales treinta días desde el registro de los datos. Dicha notificación se deberá realizar a través de un medio fiable, auditable e independiente de la entidad notificante, por cada deuda concreta y determinada con independencia de que ésta se tenga con el mismo o con distintos acreedores. Si la notificación ha sido objeto de devolución, no se podrá proceder al tratamiento de los datos referidos a ese interesado salvo que se trate de una devolución en la que el destinatario haya rehusado recibir el envío. 6.1.4. Conservación de los datos Puesto que sólo podrán conservarse en el fichero común datos que respondan con veracidad a la situación de la deuda en cada momento concreto, el pago o cumplimiento de la deuda implicará la cancelación inmediata de todos los datos relativos a la misma. Con independencia de esta obligación, en todo caso, los datos deberán ser cancelados cuando se hubieran cumplido seis años contados desde el vencimiento de la obligación. 6.1.5. Acceso a la información contenida en el fichero Los datos contenidos en el fichero común sólo podrán ser consultados por terceros cuando precisen enjuiciar la solvencia económica del afectado. Así pues el fichero podrá ser consultado en los siguientes supuestos: a) Que el afectado mantenga con el tercero algún tipo de relación contractual que aún no se encuentre vencida. b) Que el afectado pretenda celebrar con el tercero un contrato que implique el pago aplazado del precio. c) Que el afectado pretenda contratar con el tercero la prestación de un servicio de facturación periódica. No obstante, en los últimos dos supuestos los terceros deberán informar a los interesados de su derecho a consultar el fichero 6.1.6. Responsabilidad El acreedor deberá asegurarse de la concurrencia de los requisitos anterior- mente expuestos siendo responsable de la inexistencia o inexactitud de los datos que haya facilitado para su inclusión en el fichero. 6.1.7. Ejercicio de los derechos ARCO A pesar de que existen disposiciones comunes que regulan el ejercicio de los derechos ARCO, en el caso de ficheros de solvencia patrimonial y crédito, el RLOPD ha establecido algunas particularidades. En relación con el ejercicio del derecho de acceso, habrá que distinguir dos supuestos: 75
  • 96. La protección de datos personales: Soluciones en entornos Microsoft 1º La solicitud se dirige al responsable del fichero común, que deberá comu- nicar al interesado todos los datos relativos al mismo que obren en el fichero así como las evaluaciones y apreciaciones que sobre el afectado se hayan comunicado en los últimos seis meses y el nombre y dirección de los cesionarios. 2º La solicitud se dirige a cualquier otra entidad participante en el sistema, que deberá comunicar al interesado todos los datos relativos al mismo a los que ella pueda acceder, así como la identidad y dirección del responsa- ble del fichero común. Sin embargo, en relación con el ejercicio de los derechos de rectificación y cancelación encontraríamos tres supuestos distintos: 1º La solicitud se dirige al responsable del fichero común, que debe trasladar dicha solicitud a la entidad que haya facilitado los datos, para que ésta la resuelva. Si no recibiese contestación por parte de la entidad en el plazo de siete días, deberá proceder a la rectificación o cancelación cautelar de los mismos. 2º La solicitud se dirige a quien haya facilitado los datos al fichero común que procederá a la rectificación o cancelación de los mismos en sus fiche- ros y a notificarlo al responsable del fichero común en el plazo de diez días, dando asimismo respuesta al interesado en los plazos establecidos por la LOPD. 3º La solicitud se dirige a otra entidad participante en el sistema, que no hubiera facilitado al fichero común los datos, por lo que deberá informar en el plazo máximo de diez días al interesado sobre este hecho, así como de la identidad y dirección del responsable del fichero común. 6.2. Tratamientos con fines de publicidad y de prospección comercial La LOPD es su artículo 30 establece que quienes se dediquen a la recopilación de direcciones, reparto de documentos, publicidad, venta a distancia, prospección comercial y otras actividades análogas, utilizarán nombres y direcciones u otros datos de carácter personal cuando los mismos figuren en fuentes accesibles al público o cuando hayan sido facilitados por los propios interesados u obtenidos con su consentimiento. El RLOPD desarrolla este artículo estableciendo que sólo podrán utilizar nombres y direcciones u otros datos de carácter personal cuando los mismos se encuentren en uno de los siguientes casos: a) Figuren en alguna de las fuentes accesibles al público definidas en la LOPD y el interesado no haya manifestado su negativa u oposición a que 76
  • 97. Tratamientos especiales sus datos sean objeto de tratamiento para las actividades descritas en este apartado. b) Hayan sido facilitados por los propios interesados u obtenidos con su consentimiento para finalidades determinadas, explícitas y legítimas relacionadas con la actividad de publicidad o prospección comercial, habiéndose informado a los interesados sobre los sectores específicos y concretos de actividad respecto de los que podrá recibir información o publicidad. En el primer supuesto, es decir, cuando los datos proceden de fuentes accesi- bles al público, habrá que informar al interesado en cada comunicación que se le dirija del origen de los datos y de la identidad del responsable del tratamiento así como de los derechos que le asisten. 6.2.1. Campañas publicitarias Cuando una entidad quiere realizar una campaña publicitaria entre sus clien- tes, en principio será necesario el consentimiento de los mismos para recibir este tipo de comunicaciones. La campaña publicitaria puede ser realizada directamente por la entidad pero en múltiples ocasiones la entidad decide contratar a un tercero la realización de la misma, encomendándole el tratamiento de determinados datos. Así nos podríamos encontrar con diferentes supuestos: a) Cuando los parámetros identificativos de los destinatarios de la campaña sean fijados por la entidad que contrate la campaña, ésta será Responsable del tratamiento de los datos. b) Cuando los parámetros fueran determinados únicamente por la entidad o entidades contratadas, dichas entidades serán las Responsables del tratamiento. c) Cuando en la determinación de los parámetros intervengan ambas entida- des, serán ambas Responsables del tratamiento. 6.2.2. Depuración de bases de datos El RLOPD ha regulado asimismo una práctica tan habitual como es la depura- ción de las bases de datos. De este modo, se considerará que existe una cesión o comunicación de datos, cuando dos o más entidades decidan constatar, sin consenti- miento de los afectados, con fines de promoción o comercialización de sus produc- tos o servicios y mediante un tratamiento cruzado de sus ficheros, quiénes ostentan la condición de clientes de una u otra o de varios de ellos. 6.2.3. Exclusión del envío de comunicaciones comerciales Tampoco se ha querido desaprovechar la oportunidad de regular la creación de ficheros de exclusión del envío de comunicaciones comerciales. De esta forma, 77
  • 98. La protección de datos personales: Soluciones en entornos Microsoft los responsables a los que el titular de los datos o interesado haya manifestado su negativa a recibir publicidad podrán conservar los mínimos datos imprescindibles para identificarlo y adoptar las medidas necesarias que eviten el envío de publici- dad. Asimismo, permite la creación de listas Robinson o ficheros comunes, de carácter general o sectorial, en los que sean objeto de tratamiento los datos de carácter personal que resulten necesarios para evitar el envío de comunicaciones comerciales a los interesados que manifiesten su negativa u oposición a recibir publicidad. 6.2.4. Ejercicio de derechos En los tratamientos para actividades de publicidad y prospección comercial también el Reglamento prevé algunas particularidades en el ejercicio de los dere- chos ARCO. Los interesados tendrán derecho a oponerse, previa petición y sin gastos, al tratamiento de los datos que les conciernan, en cuyo caso serán dados de baja del tratamiento, cancelándose las informaciones que sobre ellos figuren en aquél, a su simple solicitud. Deberá establecerse un medio sencillo y gratuito para oponerse al tratamiento, admitiendo su ejercicio mediante la llamada a un número telefónico gratuito o la remisión de un correo electrónico, o mediante los servicios de cualquier índole para la atención a sus clientes o el ejercicio de reclamaciones. En relación con los derechos de acceso, rectificación, cancelación y oposición, si el derecho se ejercitase ante una entidad que hubiese encargado a un tercero la realización de una campaña publicitaria, aquélla estará obligada, en el plazo de diez días, desde la recepción de la comunicación de la solicitud de ejercicio de derechos del afectado, a comunicar la solicitud al responsable del fichero a fin de que el mismo otorgue al afectado su derecho en el plazo de diez días desde la recepción de la comunicación, dando cuenta de ello al afectado. 6.3. Sistemas de videovigilancia El tratamiento de imágenes comprende la captación, grabación, transmisión, conservación y almacenamiento de las mismas, tanto a través de soportes físicos de carácter digital, como mediante soportes analógicos estructurados con arreglo a criterios personales. Con el fin de cumplir con lo dispuesto en la legislación vigente en materia de protección de datos de carácter personal en relación con el tratamiento de imágenes a través de cámaras o videocámaras con la finalidad de vigilancia, se seguirán las indicaciones que se detallan a continuación:  Inscripción del fichero: la grabación y conservación de imágenes captadas por cámaras o videocámaras de vigilancia, implica la creación de un fichero. Consecuencia de ello, se declarará ante la AEPD, con carácter previo a su puesta en funcionamiento, y quedará inscrito en el RGPD. 78
  • 99. Tratamientos especiales  Información a los interesados: se colocarán en emplazamientos claramente visibles de las zonas videovigiladas tantos distintivos informativos como sean necesarios para garantizar que en todo momento los afectados conocen la existencia de videocámaras. Asimismo, se deberá tener a disposición de los interesados ejemplares de la nota informativa de VIDEOVIGILANCIA.  Conservación de las imágenes: las imágenes captadas sólo podrán ser almacenadas hasta que termine la finalidad para la que fueron captadas y nunca por un plazo superior a un mes desde que fueron capturadas.  Facilitación del ejercicio de los derechos a los interesados: si el afectado quiere ejercitar alguno de sus derechos (acceso, rectificación, cancelación u oposición), deberá remitir a la Compañía una solicitud en la que haga constar su identidad, a la que deberá adjuntar una fotografía reciente. MODELO DE CARTEL DE VIDEOVIGILANCIA (con grabación) NOMBRE ORGANIZACIÓN ZONA VIDEOVIGILADA LEY ORGÁNICA 15/1999, DE 13 DE DICIEMBRE, DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL NOMBRE ORGANIZACIÓN le informa de los siguientes aspectos: 1. Por motivos de seguridad se han instalado cámaras de seguridad en el recinto de NOMBRE ORGANIZACIÓN. 2. Las imágenes grabadas formarán parte de un fichero que ha sido declarado ante la Agencia Española de Protección de Datos, utilizándose con la única finalidad de mantener la seguridad y controlar el acceso las instalaciones, cancelándose en el plazo máximo de un mes. Asimismo, sus datos podrán ser cedidos a las Fuerzas y Cuerpos de Seguridad del Estado. 3. Usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición mediante solicitud por escrito y fotografía reciente dirigida a NOMBRE ORGANIZACIÓN, c/ XXXXXXXXXXX, CP XXXXX, CIUDAD. NOMBRE ORGANIZACIÓN le agradece su colaboración. Fecha, firma y sello 79
  • 100. La protección de datos personales: Soluciones en entornos Microsoft 80
  • 101. 7 La autorregulación: los códigos tipo La aplicación de las obligaciones impuestas por la normativa vigente en materia de protección de datos de carácter personal no está resultando fácil. Las empresas, independientemente de la actividad que desarrollan, y, dentro de éstas, tanto los responsables de los ficheros que contienen datos personales como sus usuarios, se enfrentan, continuamente, a realidades complejas e importantes proble- mas a la hora de aplicar dicha normativa, suponiendo un gran esfuerzo hallar soluciones prácticas que permitan el desarrollo eficaz de su actividad. La autorregulación es una vía que puede resultar de gran ayuda para los responsables de los ficheros o tratamientos de datos de carácter personal inmersos en este confuso panorama, tratando de adaptar la aplicación de la normativa de protección de datos a las peculiaridades propias de cada sector de actividad a través de los denominados códigos tipo. La elaboración de estos códigos, así como la adhesión a los mismos por parte de los responsables de tratamientos, debe ser cada día más frecuente en todos los sectores. Pese a ello, en la actualidad, existe un desconocimiento generalizado en relación con estos códigos y, más en concreto, su existencia, qué son realmente y su naturaleza. Con carácter genérico y, en una primera aproximación, podríamos definir los códigos tipo como conjunto de normas de buena conducta, adoptados por entida- des, generalmente pertenecientes al mismo sector, como modelos a seguir para el desarrollo de sus actividades profesionales; asimilables a los códigos deontológicos o de buena práctica profesional. Éstos constituyen una forma de complementar la regulación o, en algunos casos, suplir las lagunas o carencias de aquella, establecien- do, normalmente, medidas que no sólo respetan las previsiones legales sino que suponen garantías adicionales, reforzando el espíritu y finalidad de la Ley. 81
  • 102. La protección de datos personales: Soluciones en entornos Microsoft Las actividades objeto de regulación por los códigos pueden ser de muy diversa naturaleza, dado que el fin perseguido en su elaboración se centra en predefinir pautas o estándares de actuación generales a tener en cuenta por los sujetos pertenecientes a un determinado sector. Al margen de los códigos tipo reguladores de otras materias concretas, se analizarán en este caso, aquellos que pretenden regular de forma unitaria, los tratamientos de datos de carácter personal realizados por personas físicas o jurídi- cas englobadas en el mismo sector de actividad. En este ámbito, la Directiva 95/46/CE, utilizando la denominación de códigos de conducta, establece la posibilidad de adoptar este tipo de códigos, requiriendo a la Comisión Europea y a los Estados miembros para fomentar su desarrollo: “los Estados miembros y la Comisión alentarán la elaboración de códigos de conducta destinados a contribuir, en función de las particularidades de cada sector, la correcta aplicación de las disposiciones nacionales adoptadas por los Estados miembros en aplicación de la presenta Directiva”. El Grupo de Trabajo Sobre la Protección de las Personas Físicas, en un Docu- mento de Trabajo adoptado el 14 de enero de 1998 29, estableció una definición para este tipo de códigos, denominándolos, en ese caso, códigos de autorregulación y expresándose en los siguientes términos: “cualquier conjunto de normas de protección de datos que se apliquen a una pluralidad de responsables del tratamiento que pertenezcan a la misma profesión o al mismo sector industrial, cuyo contenido haya sido determinado fundamental- mente por miembros del sector industrial o profesión en cuestión”. La LOPD, que contempla también la posibilidad de elaborar códigos tipo cuyo ámbito de aplicación se circunscriba a una sola empresa, se refiere a los códigos tipo en su artículo 32, indicando que son aquellos en los que se “establezcan las condicio- nes de organización, régimen de funcionamiento, procedimientos aplicables, normas de seguridad del entorno, programas o equipos, obligaciones de los implicados en el tratamiento y uso de la información personal, así como las garantías en su ámbito, para el ejercicio de los derechos de las personas con pleno respeto de los principios y disposiciones de la presenta Ley y sus normas de desarrollo”. Establece, además, la posibilidad de que contengan o no reglas operacionales detalladas de cada sistema particular y estándares técnicos de aplicación, de mane- ra que, en el supuesto de que tales reglas no se incorporen directamente a los códigos, las instrucciones u órdenes que los establezcan deberán atenerse a los principios en ellos previstos. 29. Documento de Trabajo: Evaluación de la autorregulación industrial: ¿En qué casos realiza una contribución significativa al nivel de protección de datos en un país tercero ?, http:// europa.eu.int/comm/justice_home/fsj/privacy/docs/wpdocs/1998/wp7_es.pdf. 82
  • 103. La autorregulación: los códigos tipo Analizaremos a continuación el objeto, la naturaleza, los sujetos habilitados para la adopción, el procedimiento de elaboración, el contenido, las ventajas, las garantías de cumplimiento, las obligaciones posteriores a su publicación, las ventajas que puede conllevar su adopción, así como los códigos que, a día de hoy, se encuentran registrados en el RGPD. 7.1. Objeto de los códigos tipo Los códigos tipo en materia de protección de datos de carácter personal tienen por objeto adecuar lo establecido en la normativa vigente en este ámbito a las peculiaridades de los tratamientos efectuados por quienes se adhieren a los mismos. A tal efecto, contendrán reglas o estándares específicos que permitan armoni- zar los tratamientos de datos efectuados por los adheridos, facilitar el ejercicio de los derechos de los afectados y favorecer el cumplimiento de lo dispuesto la LOPD y el RLOPD. 7.2. Naturaleza de los códigos tipo En relación con esta cuestión, la propia LOPD establece, únicamente, la posibi- lidad de formular códigos tipo y reconoce el carácter de códigos deontológicos o de buena práctica profesional de los mismos. Con base en ello, ya podíamos afirmar que su implementación y la adscripción a los mismos por parte de los profesionales son voluntarias. A pesar de constituir un instrumento de gran ayuda para cumplir la normativa vigente en materia de protección de datos, no son normas jurídicas vinculantes. Por su parte, el RLOPD nos recuerda este carácter de códigos deontológicos o de buena práctica profesional y que, únicamente, serán vinculantes para quienes se adhieran a los mismos. Debemos detenernos en este punto aclarando que los responsables de ficheros no están obligados a participar en la elaboración de este tipo de códigos y, una vez elaborados e inscritos, están, del mismo modo, facultados para elegir libremente sobre su adhesión o suscripción, además de no implicar dicha adhesión el cumpli- miento de la LOPD y su normativa de desarrollo. No obstante, si un responsable se adhiere a un código tipo concreto, a partir de ese momento, queda obligado al cumplimiento de las disposiciones incluidas en el mismo y su incumplimiento podría ser sancionado por la entidad creada a estos efectos. Consecuencia de ello, el responsable suscriptor o adherido estará sometido a un control periódico por parte del citado órgano, que deberá verificar que cada una de las obligaciones aceptadas voluntariamente continúan siendo objeto de cumplimiento, resultando frecuente la creación de comités de control orientados a velar por el buen funcionamiento y aplicabilidad del código tipo. 83
  • 104. La protección de datos personales: Soluciones en entornos Microsoft 7.3. Sujetos habilitados para la adopción de códigos tipo La Directiva 95/46/CE, además de autorizar a las asociaciones de profesiona- les, deja abierta la posibilidad a cualquier organización representante de otras categorías de responsables de tratamientos y, en transposición de ésta, el legislador español ha conferido dicha posibilidad a todos los responsables de tratamientos, ya sean de titularidad pública o privada, así como a las organizaciones en las que se agrupen, siempre que lo efectúen mediante acuerdos sectoriales, convenios admi- nistrativos o decisiones de empresas. Esto ha supuesto un cambio fundamental respecto de lo establecido en la LORTAD, dado que, si bien ésta no hacía alusión expresa a los sujetos habilitados para la adopción de códigos tipo, sí hacía referencia a los responsables de ficheros de titularidad privada, quedando excluidos, por tanto, todos los responsables de tratamientos de titularidad pública. El RLOPD no introduce ninguna novedad en este sentido, reconociendo igualmente la posibilidad de creación de códigos tipo por iniciativa de empresas, grupos de entidades pertenecientes a un mismo sector y Administraciones públicas y corporaciones de derecho público. 7.4. Procedimiento para la elaboración de códigos tipo La LOPD no contempla ningún procedimiento específico para la adopción de códigos tipo, existiendo por ello una laguna en este punto, posiblemente motivada por la propia naturaleza de estos códigos, cuya implementación es totalmente voluntaria, laguna que no ha sido cubierta por el RLOPD. Como consecuencia de ello, salvo los requisitos formales establecidos por la Ley 30/1992, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común (artículos 68 y 70) para la solicitud de inscripción de los códigos tipo, su procedimiento de elaboración se ajustará, en cada caso, a la voluntad de los sujetos intervinientes en el mismo. No obstante, el artículo 32.3 de la LOPD establece una obligación que se debe cumplir tras su elaboración, expresándose en los siguientes términos: “ser depositados e inscritos en el RGPD y, cuando corresponda, en los creados a estos efectos por las Comunidades Autónomas”. El Registro podrá denegar su inscripción cuando considere que no se ajusta a las disposiciones legales y reglamentarias sobre la materia, requiriendo, en este caso, el Director de la AEPD a los solicitantes a fin de que efectúen las correcciones oportunas. El RLOPD ha desarrollado la obligación de depósito y publicidad de los códigos tipo, estableciendo que para que estos puedan considerarse como tales deberán depositarse e inscribirse en el RGPD o, cuando corresponda, en el registro que fuera creado por las comunidades autónomas, que darán traslado para su inclusión al RGPD, así como la obligación de la AEPD de dar publicidad a los códigos tipo inscri- tos, preferentemente a través de medios informáticos o telemáticos. 84
  • 105. La autorregulación: los códigos tipo 7.5. Contenido de los códigos tipo La LOPD no regula el contenido que tienen que tener estos códigos. Ante esta laguna la AEPD recogió en su página web los aspectos de fondo del contenido de estos códigos30. Se relaciona a continuación el contenido mínimo que, a tenor de lo expresado por la AEPD, deberían recoger:  Introducción. Se expresarán las razones que han conducido al desarrollo del código, enumerando los valores añadidos que aporta su cumplimien- to, a través de una exposición de motivos.  Ámbito de aplicación. El ámbito de aplicación responderá a la actividad de los responsables de ficheros que los suscriben, debiendo quedar perfec- tamente delimitado.  Principios específicos del sector que representa. El código tipo deberá incluir la aplicación de principios específicos en el sector que mejoren las previsiones legales, acotando estos principios y desarrollando el procedi- miento de aplicación de los principios generales de protección de datos al caso concreto del sector representado.  Definiciones específicas. Deberá incluir las definiciones que amplíen conceptos de la Ley y, especialmente, definiciones de carácter técnico del sector involucrado.  Condiciones de organización y procedimientos. Entre otros aspectos, deberá singularizar los datos personales a tratar, identificar los posibles destinatarios de cesiones o transferencias internacionales y las leyes o previsiones que las amparan en el sector, delimitar las fuentes de recogida de los datos, permitir el ejercicio de los derechos de acceso, rectificación, cancelación y oposición en condiciones más favorables, estableciendo para ello el procedimiento que corresponda, así como incluir modelos para el ejercicio de estos derechos y cláusulas informativas para su introducción en los cuestionarios de recogida de los datos. Además, podrá incluir un sello de garantía identificativo del código tipo, que hará referencia a la vinculación al mismo.  Medidas de seguridad. Deberá indicar el nivel mínimo de medidas de seguridad que se van a aplicar y hacer una enumeración de las mismas, pudiendo establecer el compromiso de cumplimiento de un nivel de medidas de seguridad mas alto que el correspondiente a los ficheros objeto de tratamiento en el sector que elabora el código tipo.  Comunicaciones y transferencias internacionales de datos. Deberá analizar las diferentes situaciones que se puedan dar en el sector y el ámbito legal en el que se producen. 30. Vid. AEPD, Aspectos de fondo del contenido de un código tipo, https://www.agpd.es/ index.php?idSeccion=242. 85
  • 106. La protección de datos personales: Soluciones en entornos Microsoft  Procedimiento de autorregulación y control. En relación con éste, resulta destacable el deber de aclarar que supone una vía opcional y que siempre se podrá acudir a la AEPD para presentar una reclamación ante el incum- plimiento de la LOPD.  Régimen sancionador. Tendrá que establecer el régimen de sanciones por incumplimiento del código tipo.  Relación de adheridos. Contendrá la relación de adheridos, así como el compromiso del titular del código de comunicar altas, bajas o modificacio- nes de asociados a la Agencia.  Marco normativo. Deberá establecer el marco normativo general y el específico del sector, incluyendo todas las instrucciones y recomendacio- nes que sean aplicables al sector.  Conclusiones. Deberá contener un resumen de ventajas y/o garantías que ofrece el código a los titulares de los datos, modelos para el ejercicio de los derechos y un resumen de obligaciones que deben cumplir los responsa- bles de los ficheros. El RLOPD ha cubierto la laguna de la LOPD, regulando el contenido mínimo que deben incluir los códigos tipo, tal y se detalla a continuación:  La delimitación clara y precisa de su ámbito de aplicación, las actividades a que el código se refiere y los tratamientos sometidos al mismo.  Las previsiones específicas para la aplicación de los principios de protec- ción de datos.  El establecimiento de estándares homogéneos para el cumplimiento por los adheridos al código de las obligaciones establecidas en la Ley Orgánica 15/1999, de 13 de diciembre.  El establecimiento de procedimientos que faciliten el ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación y oposición.  La determinación de las cesiones y transferencias internacionales de datos que, en su caso, se prevean, con indicación de las garantías que deban adoptarse.  Las acciones formativas en materia de protección de datos dirigidas a quienes los traten, especialmente en cuanto a su relación con los afectados.  Los mecanismos de supervisión a través de los cuales se garantice el cumplimiento por los adheridos de lo establecido en el código tipo.  Cláusulas tipo para la obtención del consentimiento de los afectados al tratamiento o cesión de sus datos. 86
  • 107. La autorregulación: los códigos tipo  Cláusulas tipo para informar a los afectados del tratamiento, cuando los datos no sean obtenidos de los mismos.  Modelos para el ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación y oposición.  Modelos de cláusulas para el cumplimiento de los requisitos formales exigibles para la contratación de un encargado del tratamiento, en su caso. Este contenido deberá estar redactado en términos claros y accesibles y con suficiente grado de precisión. Al margen del contenido mínimo indicado, los códigos tipo podrán incluir cualquier otro compromiso adicional que asuman los adheridos para un mejor cumplimiento de la legislación vigente en materia de protección de datos. Además podrán contener cualquier otro compromiso que puedan establecer las entidades promotoras y, en particular, sobre:  La adopción de medidas de seguridad adicionales a las exigidas por la LOPD y el RLOPD.  La identificación de las categorías de cesionarios o importadores de los datos.  Las medidas concretas adoptadas en materia de protección de los menores o de determinados colectivos de afectados.  El establecimiento de un sello de calidad que identifique a los adheridos al código. Finalmente, en virtud de lo establecido en el artículo 76 del RLOPD, se deberá incorporar a los códigos tipo un anexo con la relación de adheridos, que tendrá que mantenerse actualizada y a disposición de la AEPD. En el plazo de un año desde la entrada en vigor del RLOPD deberán notificarse a la AEPD las modificaciones que resulten necesarias en los códigos tipo inscritos en el RGPD para adaptar su contenido a lo expuesto anteriormente. 7.6. Ventajas derivadas de la creación de códigos tipo Uno de los aspectos que debe tener en cuenta todo responsable de ficheros son las ventajas de distinta índole que la adopción de este tipo de códigos puede conlle- var, como garantía frente a los titulares de los datos de carácter personal y a la propia AEPD, así como, de forma interna, a la organización del responsable del tratamiento. En primer lugar, para los titulares de datos personales -ya consten en los ficheros del responsable del tratamiento o se trate de sujetos que, potencialmente, pueden estar interesados en la actividad desarrollada por el mismo-, la adhesión a 87
  • 108. La protección de datos personales: Soluciones en entornos Microsoft un código tipo en materia de protección de datos podrá ser interpretada como síntoma de conocimiento de las obligaciones impuestas por la normativa reguladora de esta materia y el modo más adecuado de llevarlas a la práctica en su sector concreto, demostrando el respeto por el derecho de los particulares a preser- var sus datos personales. En aras a la consecución de la confianza de los titulares de los datos, lo más frecuente es que la suscripción por parte de los responsables de tratamientos de datos de carácter personal a estos códigos traiga como consecuencia la posibilidad de utilizar un sello de garantía que los identificará como tales, con la finalidad de que produzca en los titulares de los datos el efecto anteriormente expuesto. En relación con la AEPD, dado que, como ya se ha reflejado anteriormente, los códigos tipo deben ser inscritos en el RGPD, previa revisión de su adecuación a las disposiciones legales y reglamentarias sobre la materia, si con posterioridad la Agencia considera que una actuación acorde con lo establecido en el código tipo suscrito es sancionable, el responsable podrá argumentar la doctrina de los actos propios, a fin de que dicha práctica no sea considerada como contraria a la Ley. Del mismo modo, la adhesión a un código tipo tiene repercusiones internas para el propio responsable del tratamiento de datos, facilitándole información acerca de la manera de actuar en el proceso de tratamiento de los datos personales, especialmente, en relación con aquellos aspectos que generan a todos los profesio- nales una mayor inseguridad en sus actuaciones. 7.7. Garantías del cumplimiento de los códigos tipo El RLOPD establece la obligación de incluir en los códigos tipo procedimientos de supervisión independientes para garantizar el cumplimiento de las obligaciones asumidas por los adheridos, y establecer un régimen sancionador adecuado, eficaz y disuasorio. Estos procedimientos deberán garantizar:  La independencia e imparcialidad del órgano responsable de la supervisión.  La sencillez, accesibilidad, celeridad y gratuidad para la presentación de quejas y reclamaciones ante dicho órgano por los eventuales incumpli- mientos del código tipo.  El principio de contradicción.  Una graduación de sanciones que permita ajustarlas a la gravedad del incumplimiento. Esas sanciones deberán ser disuasorias y podrán impli- car la suspensión de la adhesión al código o la expulsión de la entidad adherida. Asimismo, podrá establecerse, en su caso, su publicidad.  La notificación al afectado de la decisión adoptada. Del mismo modo, podrán contemplar procedimientos para la determinación de medidas reparadoras en caso de haberse causado un perjuicio a los afectados como consecuencia del incumplimiento del código tipo. 88
  • 109. La autorregulación: los códigos tipo 7.8. Obligaciones posteriores a la inscripción del código tipo Una vez publicado un código tipo, las entidades promotoras o los órganos, personas o entidades que al efecto se designen en el mismo tendrán que cumplir las siguientes obligaciones establecidas en el RLOPD:  Mantener accesible al público la información actualizada sobre las entida- des promotoras, el contenido del código tipo, los procedimientos de adhesión y de garantía de su cumplimiento y la relación de adheridos a la que se refiere el artículo anterior. Esta información deberá presentarse de forma concisa y clara y estar permanentemente accesible por medios electrónicos.  Remitir a la AEPD una memoria anual sobre las actividades realizadas para difundir el código tipo y promover la adhesión a éste, las actuaciones de verificación del cumplimiento del código y sus resultados, las quejas y reclamaciones tramitadas y el curso que se les hubiera dado y cualquier otro aspecto que las entidades promotoras consideren adecuado destacar. Cuando se trate de códigos tipo inscritos en el registro de una autoridad de control de una comunidad autónoma, la remisión se realizará a dicha autoridad, que dará traslado al RGPD.  Evaluar periódicamente la eficacia del código tipo, midiendo el grado de satisfacción de los afectados y, en su caso, actualizar su contenido para adaptarlo a la normativa general o sectorial de protección de datos exis- tente en cada momento. 7.9. Códigos tipo inscritos A día de hoy, únicamente se han inscrito doce códigos tipo, constando dos de ellos en el RGPD con anterioridad a la entrada en vigor de la LOPD y en su totali- dad con carácter previo a la entrada en vigor del RLOPD. A continuación, analizare- mos brevemente cada uno de ellos, centrándonos en su objeto y ámbito de aplica- ción, dado que es suficiente para conocer su espíritu y entrar en más detalles nos obligaría a extendernos demasiado. Para ello, se seguirá un orden cronológico por fecha de inscripción del más antiguo al más reciente. Código Tipo de Telefónica de España, S.A. Fecha Inscripción: 20/12/1994 (modificado en diciembre de 2003). Siendo el primer código inscrito en el RGPD, concretó su objeto en establecer los principios a los que se sujeta la actuación de Telefónica de España en materia de protección de datos, regulando las condiciones organizativas y técnicas de los ficheros existentes en la actualidad o que puedan crearse en el futuro, así como las condiciones para la recogida y utilización de los datos, determinando el procedi- miento a seguir en el ejercicio de los derechos de acceso, rectificación, cancelación y 89
  • 110. La protección de datos personales: Soluciones en entornos Microsoft oposición por los afectados, así como los derechos específicos de los usuarios en el sector de las telecomunicaciones. Este código resulta aplicable a los tratamientos de datos de carácter personal que se efectúen en España por Telefónica de España, sirviendo de punto de referen- cia para el resto de las empresas del Grupo, como parámetros deseables a los que se debe tender aun cuando no exista legislación de protección de datos en los países en los que estén establecidas. Código Tipo de Asociación Multisectorial de la Información (ASEDIE). Fecha de inscripción: 15/09/1999. Constituye el objeto de este código establecer las condiciones de organización, régimen de funcionamiento, procedimientos aplicables, normas de seguridad del entorno, obligaciones de los implicados en el tratamiento y uso de la información personal, así como las garantías para el ejercicio de los derechos de las personas, en su ámbito; resultando de aplicación a las relaciones que mantengan las empresas asociadas a la ASEDIE (Sector de Información Comercial) con las personas objeto de informes comerciales, con los usuarios de los mismos, así como a las relaciones que dichos asociados mantengan entre sí y con terceras personas, empresas, entidades u organismos relacionados de forma directa o indirecta con el ejercicio de la actividad de información comercial. Del mismo modo, se aplica a los ficheros automatizados que contengan datos de carácter personal y de los que sean responsables las empresas asociadas a ASE- DIE, cuya finalidad sea la prestación de servicios de información sobre la solvencia patrimonial y crédito. Código Tipo de Fichero Histórico de Seguros del Automóvil (UNESPA). Fecha de inscripción: 11/10/2000. En relación con su objeto, este código se expresa en los términos que se recogen a continuación: “El Fichero Histórico, cumple con la finalidad descrita en el artículo 24.3, párrafo segundo de la Ley 33/1995 en cuanto a fichero de colaboración estadístico actuarial para la tarificación y selección de riesgos, recogiendo información sobre los contra- tos de seguros del automóvil que el tomador ha suscrito en los últimos cinco años así como de los siniestros vinculados a dichos contratos. Igualmente, el Fichero contribuirá a promover la transparencia en el mercado del seguro del automóvil y la aplicación equitativa y suficiente de las tarifas a los riesgos asegurados. Los asegurados tendrán un mayor acceso al conjunto de ofertas del sector y podrán buscar la que más se adecue a sus necesidades al permitírsele tener conocimiento de sus propios datos de siniestralidad, factor esencial para el cálculo de la prima del seguro. Por su parte las entidades aseguradoras tendrán una información exacta y precisa del riesgo que complementará la facilitada por el tomador en la solicitud de seguro, en su deber de declaración del riesgo. 90
  • 111. La autorregulación: los códigos tipo Se entiende por siniestro el acaecimiento del hecho que, previsto en el contrato, es susceptible de dar lugar al pago de la indemnización por la entidad aseguradora con cargo a la póliza suscrita por el tomador.” Su ámbito de aplicación se extiende al responsable del fichero, la empresa de servicios de tratamiento automatizado y todas las entidades aseguradoras autoriza- das para operar en España en el ramo de responsabilidad civil de automóviles, sean o no asociadas a UNESPA, teniendo como único requisito imprescindible que estén inscritas en el Registro Especial de la Dirección General de Seguros. Código Tipo de La Asociación Nacional de Fabricantes (ANF). Fecha de inscripción: 21/12/2001. El presente código arbitra un sistema, cuyo seguimiento asegura a los adheri- dos al mismo el pleno cumplimiento de sus obligaciones en materia de protección de datos de carácter personal. Podrán suscribir este código todas las empresas o profesionales adheridos a la ANF, resultando aplicable a los datos de carácter personal contenidos en ficheros sobre clientes. Código Tipo de Agrupación Catalana de Establecimientos Sanitarios (ACES). Fecha de inscripción: 28/12/2001. La ACES es una asociación empresarial que tiene como finalidad el asesoramien- to, defensa y representación de sus miembros, procurando en todo momento la optimización de métodos de trabajo y objetivos, en general, tendiendo fundamental- mente a la promoción de sus intereses sociales, laborales, profesionales y culturales. Atendiendo a dicha finalidad se creó este código, cuyo ámbito de aplicación abarca tanto a sus socios de número -personas físicas o jurídicas que siendo de titularidad privada desarrollen su actividad principal dentro del sector sanitario- como a los socios de honor -personas o entidades que presten o hayan prestado a la Agrupación o a la Sanidad ayudas o colaboraciones destacadas-, siempre previo acuerdo de la Asamblea General de ACES a propuesta de la Junta Directiva. Código Tipo de Unió Catalana D’Hospitals (UNIÓ). Fecha de inscripción: 12/07/2002 (modificado en julio de 2004). La indiscutible y, legalmente reconocida, naturaleza sensible de los datos personales concernientes a la salud unida a la posibilidad de establecer códigos tipo, arrastraron a la UNIÓ a utilizar este instrumento con la finalidad de que los adheridos a este código preserven de cualquier violación la privacidad de las personas físicas y garanticen su autodeterminación informativa. En relación con su ámbito subjetivo de aplicación, podemos afirmar que éste se extiende, no sólo a los asociados que manifiesten de forma expresa su adhesión al mismo, sino también a aquellas entidades no asociadas pero que, reuniendo las condiciones para poder serlo, con implantación territorial en cualquier territorio del estado, manifiesten su voluntad de adhesión al código de forma expresa. 91
  • 112. La protección de datos personales: Soluciones en entornos Microsoft Por su parte, el ámbito objetivo se centra en el tratamiento de datos de carácter personal contenidos en los ficheros de pacientes/historia clínica, sea cual sea su soporte y modalidad de tratamiento. Código Tipo de Comercio Electrónico y Publicidad Interactiva (AUTOCONTROL-AECE-IAB SPAIN). Fecha Inscripción: 07/11/2002. Nos encontramos ante un sector extremadamente dinámico y en permanente evolución, donde las posibilidades de obsolescencia normativa son mayores que en cualquier otro. Adaptarse a los cambios previendo soluciones a estos problemas de regulación es uno de los objetivos que inspiran el presente código, aplicable a la publicidad y al comercio electrónico realizados a través de medios electrónicos de comunicación a distancia, por personas físicas o jurídicas con establecimiento permanente en España o dirigidos de forma específica al mercado español. Código Tipo de Odontólogos y Estomatólogos de España. Fecha de inscripción: 12/07/2004. Mediante la elaboración de este código el Ilustre Consejo de Colegios Oficiales de Odontólogos y Estomatólogos de España pretende ofrecer garantías para las personas cuyos datos de carácter personal se traten por los profesionales colegiados en los Colegios Oficiales de Odontólogos y Estomatólogos de España, fijando reglas específicas para el tratamiento de datos de carácter personal en el ámbito del ejercicio de esta profesión; todo ello, sin perjuicio de la aplicación de las obligacio- nes y deberes genéricos establecidos por las normas vigentes en materia de protec- ción de datos de carácter personal aplicables a todas las personas, entidades o empresas titulares de ficheros que contengan datos personales. Su ámbito de aplicación se extiende a todos los servicios profesionales presta- dos por odontólogos y estomatólogos colegiados en los Colegios Oficiales de Odontólogos y Estomatólogos españoles, que se adhieran al código, ya sean presta- dos en clínicas y/o consultorios dentales individuales o colectivos. Código Tipo Universidad de Castilla-La Mancha. Fecha de inscripción: 14/07/2004. Esta institución académica, que ha mostrado siempre una especial sensibilidad por los temas relacionados con la seguridad informática y el respeto a todo lo relacionado con la protección de datos de carácter personal, ha sido la primera institución pública en implementar un código tipo en esta materia, con la pretensión de cumplir de la forma más sencilla y segura con la legislación, a través de un documento único que reúna todos los documentos esenciales, y servir de referente al resto de universidades españolas, contribuyendo, al mismo tiempo, al conoci- miento de este derecho fundamental. Se ha establecido como objeto de éste código garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los dere- 92
  • 113. La autorregulación: los códigos tipo chos fundamentales de las personas físicas y, especialmente, de su honor e intimi- dad personal y familiar, resultando de aplicación a los datos de carácter personal que figuren en ficheros automatizados de la Universidad de Castilla-La Mancha y a toda modalidad de uso posterior de estos datos. Código Tipo de la Asociación Catalana de Recursos Asistenciales (ACRA). Fecha de inscripción: 27/12/2004. Este código ha establecido la siguiente distinción en relación con su objeto: A. Respecto a los responsables de los ficheros: las condiciones de utilización y conservación de los datos de carácter personal, el régimen de cesión o comunicación, las directrices de la normativa interna de los asociados adheridos al código, la creación de un Comité de protección de datos en el seno de la ACRA y un régimen de infracciones y sanciones. B. Respecto a los titulares de los datos de carácter personal: definir y delimi- tar los procedimientos para ejercer los derechos de los titulares de los datos de carácter personal en aras a obtener las mayores garantías de estos derechos, tanto en lo que ser refiere a su difusión como a su ejercicio y la protección, en lo que concierne al tratamiento de los datos de carácter personal, de las libertades públicas y los derechos fundamentales de los residentes en cualquiera de los centros o establecimientos asociados y adheridos al código, así como, su derecho al honor e intimidad personal y familiar. En términos generales, es aplicable a los datos de carácter personal de los residentes registrados en soportes automatizados o no, que los hagan susceptibles de tratamiento, y a toda modalidad de uso posterior de los mismos, de los que sean responsables los asociados de ACRA que se adhieran al código tipo. Código Tipo del Sector de la Intermediación Inmobiliaria. Asociación Empre- sarial de Gestión Inmobiliaria (AEGI). Fecha de inscripción: 29/12/2004. La AEGI, conocedora de la problemática que en cuanto al tratamiento de datos de carácter personal presenta el sector de la gestión inmobiliaria, consideró impres- cindible el establecimiento de un marco que recoja un conjunto de normas de auto- rregulación que garantice que el sector cumple con las previsiones que la LOPD y sus reglamentos establecen, lo que debe traducirse en un beneficio de imagen y gestión hacia el cliente, estableciendo como ámbito de aplicación, en general, los tratamientos efectuados por las empresas adheridas para la prestación de sus servi- cios de gestión inmobiliaria y, en concreto, los siguientes tratamientos: a) Tratamien- tos de datos destinados a captar clientes para compra, venta o alquiler de inmuebles (cliente potencial), b) tratamientos de datos involucrados directamente en operacio- nes de compraventa y/o alquiler de inmuebles o destinadas a la concreción futura de las mismas (fases previas o de reserva e intermediación concretada o no), c) tratamientos de datos relacionados en todo o en parte con la gestión inmobiliaria, 93
  • 114. La protección de datos personales: Soluciones en entornos Microsoft como pudieran ser la gestión de la contratación de los suministros necesarios para la vivienda, de la financiación necesaria para la adquisición o arrendamiento de un inmueble (sea como mera intermediación o servicio propio), prestación de servicios de rehabilitación u obras en inmuebles, d) aquellos derivados de operaciones de promoción o construcción inmobiliaria en la parte que concierne a las acciones destinadas a la venta o arrendamiento de las viviendas construidas y e) cualesquie- ra comprendidos en el ámbito de la gestión inmobiliaria. Código Tipo Veraz-Persus. Soluciones Veraz ASNEF-EQUIFAX, S. L. Fecha de inscripción: 19/12/2006. El objeto de este código tipo es establecer las condiciones de organización y régimen de funcionamiento del fichero Veraz-Persus, con el objeto de ofrecer a los beneficiarios unas garantías más amplias que las contenidas en la normativa dicta- da en materia de protección de datos de carácter personal. El fichero Veraz-Persus, es un fichero de auto-inclusión en el que cualquier persona, por si misma, o a través de su tutor legal, podrá solicitar su incorporación con el objeto de evitar el uso fraudulento de sus datos personales por terceros en perjuicio de su identidad, solvencia y patrimonio económico. Después de este análisis de la figura de los códigos tipo en materia de protec- ción de datos y, ya para finalizar, debemos insistir en que, si bien éstos no tienen carácter normativo, sino, como ya se ha indicado, de códigos deontológicos o de buena práctica profesional, constituyen un importante instrumento para facilitar el cumplimiento de la normativa de protección de datos de carácter personal, que como decíamos al comienzo, está resultando muy complejo y requiriendo un gran esfuerzo por parte de las entidades o personas físicas a las que les resulta de obliga- do cumplimiento la citada normativa. 94
  • 115. 8 Infracciones y sanciones 8.1. Los responsables El artículo 5 de la LOPD define como Responsables a los Responsables de los Ficheros y los Encargados de los Tratamientos, que estarán sujetos al régimen sancionador. Es Responsable del Fichero o del Tratamiento la “persona física o jurídi- ca, de naturaleza pública o privada, u órgano administrativo, que sólo o conjuntamente con otros decida sobre la finalidad, contenido y uso del tratamiento, aunque no lo realizase materialmente. Podrán ser también responsables del fichero o del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados.” Es Encargado del Tratamiento la “persona física o jurídica, de naturaleza pública o privada, u órgano administrativo, que sólo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento o responsable del fichero, como consecuencia de la existencia de una relación jurídica que le vincula con el mismo y delimita el ámbito de su actuación para la prestación de un servicio. Podrán ser también encargados del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados.” 8.2. Las infracciones: tipos En materia de Protección de Datos, la LOPD (Art. 44) define tres tipos de infracciones: leves, graves y muy graves. 8.2.1. Leves Son infracciones leves: A. No atender, por motivos formales, la solicitud del interesado de rectifica- ción o cancelación de los datos personales objeto de tratamiento cuando legalmente proceda. 95
  • 116. La protección de datos personales: Soluciones en entornos Microsoft B. No proporcionar la información que solicite la AEPD en el ejercicio de las competencias que tiene legalmente atribuidas, en relación con aspectos no sustantivos de la protección de datos. C. No solicitar la inscripción del fichero de datos de carácter personal en el RGPD, cuando no sea constitutivo de infracción grave. D. Proceder a la recogida de datos de carácter personal de los propios afecta- dos sin proporcionarles la información que señala el artículo 5 de la LOPD. E. Incumplir el deber de secreto establecido en el artículo 10 de la LOPD, salvo que constituya infracción grave. 8.2.2. Graves Son infracciones graves: A. Proceder a la creación de ficheros de titularidad pública o iniciar la recogi- da de datos de carácter personal para los mismos, sin autorización de disposición general, publicada en el «Boletín Oficial del Estado» o diario oficial correspondiente. B. Proceder a la creación de ficheros de titularidad privada o iniciar la recogida de datos de carácter personal para los mismos con finalidades distintas de las que constituyen el objeto legítimo de la empresa o entidad. C. Proceder a la recogida de datos de carácter personal sin recabar el consen- timiento expreso de las personas afectadas, en los casos en que éste sea exigible. D. Tratar los datos de carácter personal o usarlos posteriormente con concul- cación de los principios y garantías establecidos en la LOPD o con incum- plimiento de los preceptos de protección que impone el RLOPD, cuando no constituya infracción muy grave. E. El impedimento o la obstaculización del ejercicio de los derechos de acceso y oposición y la negativa a facilitar la información que sea solici- tada. F. Mantener datos de carácter personal inexactos o no efectuar las rectifica- ciones o cancelaciones de los mismos que legalmente procedan cuando resulten afectados los derechos de las personas que la LOPD ampara. G. La vulneración del deber de guardar secreto sobre los datos de carácter personal incorporados a ficheros que contengan datos relativos a la comisión de infracciones administrativas o penales, Hacienda Pública, servicios financieros, prestación de servicios de solvencia patrimonial y 96
  • 117. Infracciones y sanciones crédito, así como aquellos otros ficheros que contengan un conjunto de datos de carácter personal suficientes para obtener una evaluación de la personalidad del individuo. H. Mantener los ficheros, locales, programas o equipos que contengan datos de carácter personal sin las debidas condiciones de seguridad que estable- ce el RLOPD. I. No remitir a la AEPD las notificaciones previstas en esta Ley o en sus disposiciones de desarrollo, así como no proporcionar en plazo a la misma cuantos documentos e informaciones deba recibir o sean requeridos por aquél a tales efectos. J. La obstrucción al ejercicio de la función inspectora. K. No inscribir el fichero de datos de carácter personal en el RGPD, cuando haya sido requerido para ello por el Director de la AEPD. L. Incumplir el deber de información que se establece en los artículos 5, 28 y 29 de la LOPD, cuando los datos hayan sido recabados de persona distinta del afectado. 8.2.3. Muy graves Son infracciones muy graves: A. La recogida de datos en forma engañosa y fraudulenta. B. La comunicación o cesión de los datos de carácter personal, fuera de los casos en que estén permitidas. C. Recabar y tratar datos de ideología, afiliación sindical, religión y creencias cuando no medie el consentimiento expreso del afectado; recabar y tratar datos de origen racial, a la salud y a la vida sexual cuando no lo disponga una Ley o el afectado no haya consentido expresamente, o violentar la prohibición de crear ficheros con la finalidad exclusiva de almacenar datos de carácter personal que revelen la ideología, afiliación sindical, religión, creencias, origen racial o étnico, o vida sexual. D. No cesar en el uso ilegítimo de los tratamientos de datos de carácter personal cuando sea requerido para ello por el Director de la AEPD o por las personas titulares del derecho de acceso. E. La transferencia temporal o definitiva de datos de carácter personal que hayan sido objeto de tratamiento o hayan sido recogidos para someterlos a dicho tratamiento, con destino a países que no proporcionen un nivel de protección equiparable sin autorización del Director de la AEPD. 97
  • 118. La protección de datos personales: Soluciones en entornos Microsoft F. Tratar los datos de carácter personal de forma ilegítima o con menosprecio de los principios y garantías que les sean de aplicación, cuando con ello se impida o se atente contra el ejercicio de los derechos fundamentales. G. La vulneración del deber de guardar secreto sobre los datos de carácter personal de ideología, afiliación sindical, religión, creencias, origen racial, salud y vida sexual, así como los que hayan sido recabados para fines policiales sin consentimiento de las personas afectadas. H. No atender, u obstaculizar de forma sistemática el ejercicio de los dere- chos de acceso, rectificación, cancelación u oposición. I. No atender de forma sistemática el deber legal de notificación de la inclusión de datos de carácter personal en un fichero. 8.3. Prescripción El artículo 47 de la LOPD establece los plazos de prescripción:  Las infracciones muy graves prescribirán a los tres años, las graves a los dos años y las leves al año.  El plazo de prescripción comenzará a contarse desde el día en que la infracción se hubiera cometido.  Interrumpirá la prescripción la iniciación, con conocimiento del interesa- do, del procedimiento sancionador, reanudándose el plazo de prescripción si el expediente sancionador estuviere paralizado durante más de 6 meses por causa no imputable al presunto infractor. 8.4. La infracción continuada Se considera Infracción Continuada aquella infracción en las que su consuma- ción se proyecta en el tiempo más allá de los hechos iniciales, extendiéndose hasta los finales. Es decir, que hasta que deja de producirse la lesión de los derechos del afectado que se comete mientras se mantienen datos de carácter personal inexactos en un registro, y el periodo de prescripción no comienza hasta que son eliminados o rectificados. Según la sentencia de la Audiencia Nacional de 7 de noviembre de 2002, la infracción es la prevista en el artículo 44.3.f): “Mantener datos de carácter personal inexactos o no efectuar las rectificaciones o cancelaciones de los mismos que legal- mente procedan cuando resulten afectados los derechos de las personas que la presente Ley ampara.” El plazo de prescripción comienza a contarse desde el día en que la infracción se hubiera cometido, y la Audiencia Nacional considera que “…la infracción se 98
  • 119. Infracciones y sanciones comete mientras se mantienen los datos en el registro, quebrando la correspondencia que debe mediar entre dichos datos y la situación real del afectado…”. 8.5. Las sanciones 8.5.1. Las sanciones en el sector privado 8.5.1.1. Las sanciones de la lopd En materia de Protección de Datos, la LOPD (Art. 45) define 3 tipos de sanciones:  Las infracciones leves serán sancionadas con multa de 601,01 € a 60.101,20 €.  Las infracciones graves serán sancionadas con multa de 60.101,20 € a 300.506,10 €.  Las infracciones muy graves serán sancionadas con multa de 300.506,10 € a 601.012,10 €. La cuantía de las sanciones se graduará atendiendo a la naturaleza de los derechos personales afectados, el volumen de los tratamientos efectuados, los beneficios obtenidos, el grado de intencionalidad, la reincidencia, los daños y perjuicios causados a las personas interesadas y a terceras personas, y a cualquier otra circunstancia que sea relevante para determinar el grado de antijuridicidad y de culpabilidad presentes en la concreta actuación infractora. También hay que tener en cuenta que habitualmente en un Procedimiento Sancionador se recogen varias infracciones, por lo que las sanciones son acumulativas, lo que implica que el importe total de las sanciones puede superar los 601.012,10 €. ¿Cuándo se aplica la posible rebaja del Art. 45.5 de la LOPD? Si, en razón de las circunstancias concurrentes, se apreciara una cualificada disminución de la culpabilidad del imputado o de la antijuridicidad del hecho, el órgano sancionador establecerá la cuantía de la sanción aplicando la escala relativa a la clase de infracciones que preceda inmediatamente en gravedad a aquella en que se integra la considerada en el caso de que se trate. La Audiencia Nacional31 establece que “sólo en los casos en los que la culpabilidad y la antijuricidad resulten sustancialmente atenuadas atendidas las circunstancias del caso concreto, de forma que repugne a la sensibilidad jurídica… la imposición de la sanción correspondiente al grado… lo cual puede darse, por excepción, en casos muy extremos y concretos.” Inmovilización de ficheros. Existe una sanción adicional desarrollada por el RLOPD (Art. 121) que estable- ce que en caso de infracción muy grave por la utilización o cesión ilícita de los datos 31. Sentencia de la Audiencia Nacional, Sala de lo Contencioso-Administrativo, Sección 1ª, de 15 de noviembre 2002 (RJCA 2003, 16). 99
  • 120. La protección de datos personales: Soluciones en entornos Microsoft de carácter personal en la que se impida gravemente o se atente de igual modo contra el ejercicio de los derechos de los ciudadanos y el libre desarrollo de la personalidad que la Constitución y las leyes garantizan, el Director de la AEPD podrá, en cualquier momento del procedimiento, requerir a los responsables de ficheros o tratamientos de datos de carácter personal, tanto de titularidad pública como privada, la cesación en la utilización o cesión ilícita de los datos. Este requerimiento deberá ser atendido en el plazo improrrogable de tres días, durante el cual el responsable del fichero podrá formular las alegaciones que tenga por convenientes en orden al levantamiento de la medida. Si el requerimiento fuera desatendido, el Director podrá, mediante resolución motivada, acordar la inmovilización de tales ficheros o tratamientos, a los solos efectos de restaurar los derechos de las personas afectadas. TABLA EVOLUCIÓN DE LAS SANCIONES Y LOS PROCEDIMIENTOS 2002-2007. Fuente: Memorias de la AEPD 2002-2007. Elaboración: HELAS CONSULTORES. 8.5.1.2.Las sanciones de la LSSICE El artículo 6 de la Ley 56/2007, de 28 de diciembre, de Impulso de la Sociedad de la Información (LISI) establece como autoridad sancionadora del incumplimien- to de algunos preceptos de la Ley 34/2002, de 11 de julio, de Servicios de la Socie- dad de la Información y de Comercio Electrónico (LSSICE) a la AEPD. En particular, corresponderá a la AEPD la imposición de sanciones por la comisión de las infrac- ciones tipificadas en los artículos 38.3, c), d) i) y 38.4 d) g) h) de la LSSICE, que se detallan a continuación: 100
  • 121. Infracciones y sanciones Infracciones Graves:  El envío masivo de comunicaciones comerciales por correo electrónico u otro medio equivalente, o el envío en 1 año de más de 3 comunicaciones comerciales no solicitadas o consentidas.  El incumplimiento de establecer procedimientos para la revocación del consentimiento.  El incumplimiento de las obligaciones de información o de establecimien- to de un procedimiento de rechazo de tratamiento de datos (Art. 22.2). Infracciones Leves:  El envío de comunicaciones comerciales por correo electrónico u otro medio de comunicación electrónica equivalente cuando en dichos envíos no se cumplan los requisitos establecidos (derechos de los destinatarios de comunicaciones comerciales, Art. 21) y no constituya infracción grave.  El incumplimiento de las obligaciones de información o de establecimien- to de un procedimiento de rechazo del tratamiento de datos (validez y eficacia de los contratos celebrados por vía electrónica, Art. 22), cuando no constituya una infracción grave.  El incumplimiento de la obligación del prestador de servicios en relación con los procedimientos para revocar el consentimiento prestado por los destinatarios cuando no constituya infracción grave. 8.5.2. Las sanciones en el sector público La LOPD (Art. 46) desarrolla las infracciones de las Administraciones Públicas, donde la peculiaridad principal es que no conllevan sanción económica, diferen- ciándose así de las entidades privadas.  Cuando las infracciones fuesen cometidas en ficheros de los que sean responsables las Administraciones Públicas, el Director de la AEPD dictará una resolución estableciendo las medidas que procede adoptar para que cesen o se corrijan los efectos de la infracción. Esta resolución se notificará al responsable del fichero, al órgano del que dependa jerárquicamente y a los afectados si los hubiera.  El Director de la AEPD podrá proponer también la iniciación de actuacio- nes disciplinarias, si procedieran. El procedimiento y las sanciones a aplicar serán las establecidas en la legislación sobre régimen disciplinario de las Administraciones Públicas.  El Director de la AEPD comunicará al Defensor del Pueblo las actuaciones que efectúe y las resoluciones que dicte al amparo de los apartados ante- riores. 101
  • 122. La protección de datos personales: Soluciones en entornos Microsoft 8.6. El procedimiento sancionador La LOPD establece que el procedimiento sancionador se desarrollará por vía reglamentaria, y el RLOPD establece los procedimientos relativos al ejercicio de la potestad sancionadora. Cualquier actuación que sea contraria a las exigencias contenidas en la LOPD puede ser objeto de reclamación ante la Agencia, sin perjuicio de que se pueda interponer denuncia ante los Tribunales de Justicia. 8.6.1. Procedimiento sancionador El procedimiento sancionador se inicia normalmente como consecuencia de una denuncia. La práctica habitual es que previamente se informe a la empresa responsable de los ficheros de la inspección a realizar, indicando día y hora en que se personarán los inspectores, pero sin explicar el motivo de la denuncia ni identificar al denunciante. En empresas pequeñas, para no favorecer la eliminación de información, las inspecciones se realizan sin previo aviso. Los inspectores, que tienen la considera- ción de autoridad pública, deben acreditar su personalidad y mostrar la autoriza- ción de entrada expedida por el Director de la AEPD. Por su parte, el responsable del fichero tiene la obligación de facilitar la actividad inspectora, siendo una infrac- ción grave su obstrucción. También se han iniciado procedimientos sancionadores cuando tras una denuncia que afecta a una administración pública, la AEPD ha recabado informa- ción de dicho organismo, sin realizar inspección presencial, y basándose en las respuestas ha deducido que se habían realizado actividades susceptibles de ser sancionables. Los inspectores (siempre dos, inspector y subinspector) podrán solicitar la exhibición de documentos, inspeccionar equipos físicos y lógicos, y acceder a los locales donde se encuentren instalados. La inspección termina con el Acta de Inspección que ha de firmar el responsable del fichero. Es importante revisar el contenido de dicha acta, porque el expediente sancionador se basará en ella. Si tras la inspección, se comprueba que se ha cometido alguna infracción, se abrirá procedimiento sancionador por acuerdo del Director de la Agencia Española de Protección de Datos. El contenido de este acuerdo debe ser el siguiente:  Designación de instructor, con la indicación de la posibilidad de su recusa- ción.  Identificación el presunto responsable o responsables, concretando los hechos y la infracción que supuestamente ha cometido.  Las sanciones que se pudieran imponer.  Las medidas cautelares a adoptar, en su caso. 102
  • 123. Infracciones y sanciones El acuerdo de inicio de expediente se comunica al instructor, se notifica al denunciante y al presunto responsable informándole de su derecho a formular las alegaciones que estime oportunas, así como a utilizar los medios de defensa proce- dentes. El procedimiento sancionador concluye con la resolución del Director de la Agencia, contra la que cabe recurso de reposición potestativo ante él mismo. Contra su resolución, cabe recurso contencioso-administrativo ante la Audiencia Nacional. CUADRO EXPLICATIVO PROCEDIMIENTO SANCIONADOR DE LA AEPD. 8.6.2. Procedimiento de tutela de derechos El procedimiento de tutela de derechos se inicia siempre a instancia del intere- sado, cuando éste considera que se ha vulnerado alguno de sus derechos, mediante un escrito de reclamación ante la Agencia. En este escrito se debe indicar cuál es el contenido de la reclamación y los artículos de la Ley que se consideran vulnerados. La AEPD da traslado de la misma al responsable del fichero (empresa titular), para que realice las alegaciones que estime oportunas en el plazo de 15 días. Después de dar audiencia al afectado y al responsable del fichero, el Director de la AEPD 103
  • 124. La protección de datos personales: Soluciones en entornos Microsoft resolverá en el plazo máximo de 6 meses, comunicándolo a los afectados. La resolución puede ser:  “No ha lugar”, en cuyo caso se cierra el procedimiento.  “Sí ha lugar“, en cuyo caso se tutela el derecho vulnerado y se decide si se abre o no el procedimiento sancionador. Contra esta decisión cabe recurso contencioso-administrativo. 104
  • 125. 9 Los órganos de control 9.1. La Agencia Española de Protección de Datos (AEPD) Es el órgano que se encarga de velar por el control y cumplimiento de la normativa sobre Protección de Datos. Es un ente de Derecho Público, con personali- dad jurídica propia y capacidad pública y privada, que actúa con independencia de las Administraciones Públicas en el ejercicio de sus funciones, pero dependiente del Ministerio de Justicia. Actualmente se rige por lo dispuesto en la LOPD y en su Estatuto, aprobado por Real Decreto 428/1993, de 26 de marzo. En defecto de lo que establezcan la LOPD y sus disposiciones de desarrollo, la AEPD actuará de conformidad con la Ley de Procedimiento Administrativo. Los ficheros de titularidad privada son de exclusiva competencia de la Agencia Estatal. La AEPD se estructura de la siguiente forma:  Director.  Consejo Consultivo.  Subdirección General del Registro General de Protección De Datos.  Subdirección General de Inspección de Datos.  Subdirección General de Secretaría General. Entre sus competencias y funciones, cabe destacar las siguientes:  Vigilar en el territorio español del cumplimiento de la legislación sobre protección de datos (excepto las funciones asumidas por las Agencias Autonómicas de Protección de Datos). 105
  • 126. La protección de datos personales: Soluciones en entornos Microsoft  Controlar la aplicación de la legislación sobre protección de datos y, especialmente, lo relativo a los derechos de acceso, rectificación, oposición y cancelación (derechos ARCO).  Dictar Instrucciones sobre determinados aspectos de la protección de datos de carácter personal.  Atender a las peticiones, reclamaciones y consultas que formulen los titulares de los datos personales.  Proporcionar información a los titulares de datos personales sobre sus legítimos derechos en materia de protección de datos personales.  Señalar a las entidades que gestionen datos personales, las medidas que deberían implantar para la adecuación de sus actuaciones con la legisla- ción sobre protección de datos personales.  Ordenar a las entidades que gestionen datos personales, el cese de deter- minadas actuaciones que no se ajustan a la legislación sobre protección de datos.  Ejercer la potestad inspectora. El artículo 40 de la LOPD detalla los siguientes:  La AEPD podrá inspeccionar los ficheros con datos personales de las entidades que gestionan dichos tipos de datos.  Podrán solicitar e inspeccionar documentación, equipos físicos, lógicos y locales relacionados con datos personales.  Los funcionarios que actúen bajo esta función se consideran Autori- dad Pública y poseen, como obligación, deber de secreto.  Ejercer la potestad sancionadora (ver apartado 8.6).  Informar previamente los proyectos de disposiciones generales sobre protección de datos personales.  Recabar de las entidades que gestionan datos personales la ayuda e información que necesite para el ejercicio de sus funciones.  Comprobar la publicidad de los ficheros con datos personales. En este sentido, deberá publicar periódicamente la relación de ficheros con datos personales inscritos en ella.  Controlar y autorizar movimientos internacionales de datos personales.  Velar por determinados aspectos de la Ley de la Función Estadística.  Cooperar internacionalmente en materia de protección de datos personales. 106
  • 127. Los órganos de control  Redactar una Memoria anual y remitirla al Ministerio de Justicia.  Otras funciones que sean atribuidas a la Agencia por vía legal o por vía reglamentaria (como por ejemplo las sancionadoras asignadas por la LSSICE). Toda persona tiene derecho a consultar en el Registro General de la AEPD qué ficheros existen inscritos. El Registro es de consulta pública y gratuita; se puede ejercitar cuantas veces se quiera, se puede realizar desde su página web (www.agpd.es) y nos proporcionará la identidad del responsable del fichero, la dirección y la finalidad. Si lo que queremos saber es qué datos tiene una empresa de nosotros, tendremos que dirigirnos al responsable del fichero mediante el ejercicio del derecho de acceso. Con la medida introducida en la Ley de Acompañamiento de los Presupuestos de 2004, la AEPD puede hacer públicas, a partir del 1 de enero de 2004, las resoluciones que adopta. 9.2. Las agencias de protección de datos de las comunidades autónomas En la actualidad existen tres Agencias autonómicas de Protección de Datos (Agencia de Protección de Datos de la Comunidad de Madrid, Agencia Vasca de Protección de Datos y Agencia Catalana de Protección de Datos) aunque algunas Comunidades Autónomas, como la de Valencia, ya han anunciado su voluntad de constituir su propio organismo de control. 9.2.1. Agencia de Protección de Datos de la Comunidad de Madrid (APDCM) Es la primera agencia autonómica en estar operativa y tiene su autoridad sobre los organismos públicos e instituciones de la Comunidad de Madrid. Es la más activa de las agencias autonómicas, tanto en su labor inspectora como en el desarro- llo normativo y edición de publicaciones en materia de Protección de Datos. Es de destacar el Premio anual a las Mejores prácticas de las Administraciones Públicas europeas en materia de Protección de Datos. La APDCM se rige por la Ley 8/2001, de 13 de julio, de Protección de Datos de Carácter Personal en la Comunidad de Madrid. (BO. Comunidad de Madrid 25 julio 2001) y por el Decreto 40/2004, de 18 de marzo, por el que se aprueba el Estatuto de la Agencia de Protección de Datos de la Comunidad de Madrid (BO. Comunidad de Madrid 25 marzo 2004). 9.2.2. Agencia Catalana de Protecció de Dades (APDCAT) La APDCAT se rige por la Llei 5/2002, de 19 d’abril, de L’Agència Catalana de Protecció de Dades y tiene su autoridad sobre los organismos públicos e institucio- nes de la Comunidad Autónoma de Cataluña. 107
  • 128. La protección de datos personales: Soluciones en entornos Microsoft 9.2.3. Agencia Vasca de Protección de Datos (AVPD) La AVPD se regula por la Ley 2/2004 del Parlamento Vasco, de 25 de febrero, de Ficheros de Datos de Carácter Personal de Titularidad Pública y de Creación de la Agencia Vasca de Protección de Datos, y tiene su autoridad sobre los organismos públicos e instituciones de la Comunidad Autónoma del País Vasco. 9.3. Conclusiones Cuando las organizaciones se enfrentan a un proceso de adaptación a una nueva concepción de la seguridad, la sensación es que falta tanto por hacer que no se sabe por dónde comenzar. El punto de partida para la implantación de un sistema de gestión de la seguridad de la información y los datos personales, debe ser el conocimiento del riesgo al que la organización se está enfrentando. Analizados los aspectos más importantes que afectan a las organizaciones españolas a la hora de enfrentarse a medidas que la adapten a la legislación sobre Protección de Datos, podemos exponer un decálogo de conclusiones que ayuden al empresario a tomar las decisiones más acertadas:  El uso generalizado de la informática ha hecho que los estados legislen para salvaguardar la intimidad de sus ciudadanos. España ha reaccionado imponiendo estrictos requisitos y fuertes sanciones, por lo que las organi- zaciones, tanto públicas como privadas, deben de optar por una gestión prudente de los datos personales que obran en su poder.  Debemos tener en cuenta que no sólo nos deben preocupar los datos de carácter personal procesados por nuestro sistemas informáticos, sino el uso y tratamiento que damos a los datos plasmados en papel, fuente actual de las mayores infracciones en materia de protección de datos.  La necesidad de definir una Política de Seguridad para la empresa se hace imprescindible, siendo la protección de datos el mejor inicio de una gestión integral de la información en la empresa. Debemos ser activos en adecuar nuestra organización a la protección de datos, y evitar actuar como reacción a un incidente, porque entonces será demasiado tarde y el riesgo de sanción y de pérdida de imagen pública demasiado elevado.  Desde el momento en que la protección de datos implica a todos y cada uno de los departamentos de la organización, sabemos que nos enfrenta- mos a un proyecto complejo. La creación de una Comisión de Seguridad con espíritu constructivo y formada por miembros con conocimiento en la materia, es vital para el éxito en la protección de datos.  La seguridad sólo se consigue implementando medidas tecnológicas y organizativas. Hay que huir del síndrome de la panacea: una medida 108
  • 129. Los órganos de control técnica puede quedar obsoleta en cuestión de minutos, por lo que nunca es la solución definitiva de nuestros problemas.  Las medidas que implementemos en nuestra organización son parte de un proceso; no son un producto y no admiten excepciones. La excepción es la puerta abierta a graves problemas.  Enfocar nuestra adaptación a la legislación en materia de protección de datos como un proceso de mejora continuada de la calidad en nuestra organización.  Sin la formación de nuestros empleados, cualquier medida que se intente implementar en la organización será papel mojado. La concienciación de todos los que forman la organización a es la base fundamental de una buena adaptación a la protección de datos, y el primer escalón de una Política de Seguridad en un nivel más amplio.  En una evaluación de nuestros riesgos de seguridad, hay que evaluar tanto los riesgos externos (virus, hacking, craking, etc.) como los internos (usuarios autorizados). En la actualidad son los riesgos internos los que ocasionan un mayor número de incidentes en materia de protección de datos.  Por último, conviene tener siempre presente que los servicios de consultoría externos complementan, asisten y ayudan al empresario a una más rápida y personalizada adaptación a la legislación sobre Protección de Datos, pero nunca le sustituirán en su responsabilidad de cumplimien- to de la normativa implementada en su compañía. Este Libro es una guía de actuaciones y, aunque los autores han tratado de elaborarla de la forma más rigurosa posible para tener la absoluta certeza de que su empresa está cumpliendo con la legislación en materia de Protección de Datos, verifique que cumple con lo que se especifica en la LOPD y el RLOPD. 109
  • 130. La protección de datos personales: Soluciones en entornos Microsoft 110
  • 131. Parte II Técnico 10. La seguridad en sistemas Microsoft 113 11. La aplicación del reglamento de seguridad en los sistemas Microsoft 123 12. La aplicación del reglamento de seguridad en SQL Server 223 13. Implementación de la LOPD sobre SQL Server (SQL Server 2005-2008) 235 14. Política de seguridad 255
  • 132. La protección de datos personales: Soluciones en entornos Microsoft 112
  • 133. 10 La seguridad en sistemas Microsoft En estos últimos años, el concepto de seguridad ha cambiado considerable- mente en las empresas. Ya nadie cuestiona la importancia que ésta implica para los sistemas y la información. Sin embargo, la falta de rigor y los malos hábitos han provocado que no se aplicasen adecuadamente las medidas, aún disponiendo de medios para ello. Microsoft se ha planteado éste como uno de sus mayores retos: conseguir que los medios disponibles para mejorar la seguridad sean aplicados correctamente y a la par ir fomentando esa necesaria cultura de la seguridad informática. Ha decidi- do romper definitivamente con frases incorrectas pero habituales, como “la seguri- dad informática es un mito”. Transmitir la necesidad de asegurar nuestros siste- mas e información son cuestiones importantes e imperativas. Para el profesional, todas estas cuestiones toman aún mayor peso cuando son otros los que depositan su confianza en nosotros para el mantenimiento de la seguridad de su información en niveles apropiados. Evidentemente, de todo lo anterior nace toda una serie de necesidades. La necesidad de proteger los datos, la de poder contar con ellos ante una eventuali- dad no deseada, o evitar que caigan en malas manos, así como que las comunica- ciones de datos sean seguras, son algunos ejemplos críticos de necesidades que deben ser atendidas. En muchas circunstancias, toda esa operativa es totalmente transparente para el usuario. Éste deposita la confianza en los desarrolladores de productos. Se parte de la base de que ese primer escalón presenta una seguridad estable y apropiada. Lógicamente, éste no es más que un primer escalón, el resto se debe ir construyen- do con la participación de todos. Aunque se planifique y se disponga de los meca- nismos necesarios para aplicar la adecuada securización de los sistemas, es necesa- rio utilizarlos posteriormente con correspondencia. 113
  • 134. La protección de datos personales: Soluciones en entornos Microsoft Microsoft es consciente de estas cuestiones. Son muchos los usuarios que depositan la confianza en sus productos. Su compromiso no puede ser otro que el de crear la solidez de la infraestructura desde ese primer peldaño, y facilitar las herramientas para construir cualquier infraestructura, independientemente de su complejidad, con la solidez y seguridad apropiadas. 10.1. TrustWorthy Computing (TWC). La estrategia de Microsoft Fruto de las necesidades que planteaban los usuarios, y con objeto de solidifi- car los mecanismos de seguridad, nace a principios de 2002 en Microsoft una iniciativa que modificará significativamente tanto la forma de ver como la de plantear los sistemas TI existentes: TrustWorthy Computing. Esta iniciativa presenta los pilares sobre los que se sustentan los mecanismos de Microsoft para proporcio- nar sistemas seguros. Abarca un amplio espectro de funciones que van desde determinar los ciclos de vida de desarrollo de seguridad de un software, a generar y estudiar tecnologías innovadoras que lideren iniciativas de prevención de nuevas formas de violaciones de seguridad (que pueden aparecer de las formas más insos- pechadas), junto otras muchas. Desde el nacimiento de la iniciativa de TrustWorthy Computing, numerosas aplicaciones han nacido bajo su paraguas. Éstas se han establecido bajo las siguiente cuatro directrices SD3+C: “Secure by Design”, “Secure by Default”, “Secure by Deployment” y “Communication” (Seguro por diseño, Seguro por definición, Seguro en distribución y Comunicaciones). Desde el nacimiento de una aplicación existe un criterio para establecer el mayor nivel de seguridad exigible: implementar procesos que de una forma confiable puedan establecer una mayor seguridad. Estos procesos deben ser diseña- dos con objeto de minimizar los fallos de seguridad presentes, tanto en el diseño de una solución, como en su programación. Una vez puesta en marcha ésta, los proce- sos de trabajo deben igualmente establecer los mecanismos de depuración adecua- dos. En todos y cada uno de estos procedimientos y apartados, un grupo de especia- listas de Microsoft en seguridad se encuentran presentes en todas las fases del ciclo de vida de desarrollo de la seguridad de los productos Microsoft. Además éstos no culminan la labor con el lanzamiento del producto, sino que continúan con el centro de respuestas de seguridad de Microsoft. La tecnología de TrustWorthy Computing va aún más allá, puesto que definen también los mecanismos para la inversión de seguridad en los equipos de desarro- llo, la formación de la comunidad TI, evaluaciones externas, y otros muchos aspec- tos relacionados. 10.2. Soluciones seguras Como hemos comentado anteriormente, la necesidad de implementar elemen- tos de seguridad se debe abordar desde la perspectiva de plantear mecanismos que 114
  • 135. La seguridad en sistemas Microsoft observen la iniciativa SD3+C comentada. Bajo este marco de trabajo debe operar cada solución planteada en las diferentes fases por las que pasa un desarrollo, hasta los procesos de implantación del mismo, y la posterior puesta en práctica de los diferentes elementos software necesarios para una empresa. 10.2.1. Seguridad en el diseño Debemos considerar el objetivo de securización desde la parte inicial del diseño. En esta etapa se establecen los mecanismos que nos permiten reducir las posibles superficies de ataque en un contexto global a la hora de generar una solución de Software. Una consideración fundamental a tener en cuenta es que, aunque el software no consiga un entorno de seguridad total, todos aquellos elementos que sean utili- zados de forma habitual, se instalen y se ejecuten con el menor privilegio posible. Evitaremos con ello, antes que el producto vea la luz, que posteriormente puedan aparecer vulnerabilidades de seguridad. De igual modo, también esto nos permitirá ir agregando otros elementos que incrementen la seguridad global del mismo. Otra evolución significativa asociada a esta iniciativa, y que implica una mejora en cuanto a los niveles de securización, es evitar que determinados servicios que antes requerían de privilegios administrativos muy elevados, ahora en sus equivalentes actuales demandan un nivel de privilegios considerablemente inferior. Se minimizan, de este modo, las posibles amenazas de seguridad que la situación original podía implicar. 10.2.2. Seguridad predeterminada Bajo este epígrafe abordamos la necesidad de que un sistema instalado “por defecto” reduzca su posible superficie de ataque no habilitando aquellos servicios que no sean necesarios. Evidentemente, esto requiere que un administrador que desee una determinada función, y ésta se encuentre asociada a un servicio no insta- lado por defecto, la tenga que instalar a propósito. Esto no implica ninguna pérdida de funcionalidad; simplemente por seguridad se limita la automatización en el despliegue de servicios que, sin embargo, no por ello dejan de estar disponibles. Una mala práctica habitual por parte de los administradores cuando se lleva a efecto la instalación de una plataforma o solución es desconocer o no interesarse por los elementos que han sido instalados. Si esta circunstancia se da, no se tendrá en cuenta qué elementos demandan un mantenimiento y cuáles de ellos implican riesgos de seguridad, o si es necesario aplicar medidas concretas de securización. Como ejemplo de la nueva filosofía que comentamos, la plataforma Windows Server 2008 establece un sistema por defecto con las mínimas características y funciones. A partir de éste, es tarea del administrador determinar los roles y las características que son necesarios para el servidor. Es por ello que aquellos adminis- tradores que no tengan la necesidad de hacer uso de determinados servicios no tendrán que plantearse cómo mantener su seguridad, ni conocer cómo deshabilitarlos y en qué medida puede afectar al resto del entorno. Por otro lado, 115
  • 136. La protección de datos personales: Soluciones en entornos Microsoft aquel que sí necesite un determinado servicio deberá conocer cuál es su funciona- miento, preocupándose de mantener su seguridad, y de aplicar las mejores condi- ciones posibles para su entorno en explotación. De esta forma, conociendo cómo vamos configurando una solución en función de nuestras necesidades y partiendo de una base predeterminada más segura, llegamos a un mejor conocimiento de la plataforma que implementamos. Esto revierte forzosamente en mejoras en la seguridad de la misma. 10.2.3. Seguridad en el despliegue Una de las fases operativas que se antoja como más crítica es la puesta en producción de un producto y el inicio de la actividad continuada sobre el mismo. En función de esta consideración, Microsoft plantea determinadas iniciativas y programas dirigidos a la comunidad TI, con el objeto de que los profesionales conozcan cómo adaptar y configurar los mecanismos de seguridad necesarios y disponibles sobre sus elementos en explotación. Desde los programas STPP (Strategic Technology Protection Program), hasta los actuales mecanismos de Forefront, Microsoft aporta herramientas y elementos que permiten beneficiarse de ellos y elevar el nivel de seguridad en los sistemas. Microsoft plantea estrategias en relación a tres elementos fundamentales:  Personas. La formación de los administradores y usuarios TI es un aspec- to crítico en los mecanismos de seguridad, que no debe descuidarse. De nada vale disponer de los sistemas más eficaces y seguros, si las malas prácticas o el desconocimiento crean huecos de seguridad que con los conocimientos oportunos no existirían. Eventos, laboratorios de seguridad, o las diferentes formaciones plantea- dos en los Centros de Formación Microsoft, entre otros, se ofrecen como alternativas cuyo objetivo es formar a administradores y usuarios en el manejo de las características de seguridad de sus entornos, mostrando además posibles soluciones que pudieran ser desconocidas para ellos.  Procesos. Plantear procedimientos de aplicación de modelos de seguridad y establecer los mecanismos de seguridad a utilizar son una referencia a considerar en todo momento. Estos procedimientos pueden establecerse y plantearse mediante diferentes guías de seguridad ( http:// www.microsoft.com/spain/technet/security/guidance/default.mspx), mediante mecanismos e instrucciones que permiten que los administradores gestio- nen sus sistemas con mayor facilidad, a través del centro de respuestas de seguridad de Microsoft (http://www.microsoft.com/spain/technet/security/ bulletin/notify.mspx), o mediante procedimientos de alerta a los usuarios (http://alerts.live.com/Alerts/Default.aspx). Estas y otras series de medidas van a suministrar el apoyo necesario al profesional de TI que le permita plantear procesos con los que aportar soluciones a cuestiones que se puedan dar en sus entornos operativos. 116
  • 137. La seguridad en sistemas Microsoft  Tecnología. Para completar los ciclos de seguridad, además de poseer los conocimientos, debe contarse con una serie de herramientas que faciliten la administración de la seguridad y sean capaces de reducir la dedicación de tiempos administrativos. Microsoft proporciona diferentes herramientas y soluciones que facultan a los administradores para aplicar las correspondientes actualizaciones de seguridad mediante SCCM 2007 (System Center Configuration Manager), WSUS (Windows Server Update Services) o Microsoft Update. Suministra, de igual modo, herramientas para la evaluación de mecanismos de seguri- dad, tales como el MBSA 2.1 (Microsoft Baseline Security Analyzer), con los que establecer una auditoría de caja blanca, herramientas de elimina- ción de software malintencionado, o los servicios de Windows Rights Management, para aplicar gestión de derechos, entre otras posibilidades (http://www.microsoft.com/spain/technet/seguridad/herramientas/default.mspx). 10.2.4. Comunicación El cuarto elemento dentro de la arquitectura SD3+C establece la necesidad de crear un cauce de comunicaciones hacia el usuario de tal forma que se minimice el impacto de las vulnerabilidades, proporcionando guías y soluciones que mitiguen los posibles impactos en la seguridad. 10.3. ¿Que se ha conseguido con TWC? La iniciativa empezó a dar sus frutos rápidamente, y el primer balance signifi- cativo y positivo lo podemos hacer un año después de la aparición de la plataforma Windows 2003. Comparando sus números de seguridad con el mismo período de tiempo transcurrido desde la aparición de su antecesor Windows 2000, las mejoras son evidentes. Aunque por aquella época Microsoft no había categorizado las vulnerabilidades, con posterioridad se han evaluado los boletines de seguridad aplicados a Windows 2000 para asemejarlos al período actual y poder realizar una comparativa coherente. Durante el primer año de rodaje de ambos Sistemas Operativos, Windows 2000 presentó 62 boletines de seguridad importantes y críticos, frente a los 24 que tuvo Windows 2003. Además, el dato es más significati- vo aún si tenemos en cuenta que el índice de datos reportados al CERT (Computer Emergency Response Team), fue considerablemente más alto en el año 2003-04 que en el período 2000-01 (www.cert.org/stats/cert_stats.html). La evolución de las cifras, hasta las actuales, implica una considerable mejora. Gran cantidad de productos Microsoft presentan bajos índices de incidencias de seguridad desde su aparición. Internet Information Server 6.0 y 6.7, Windows Vista o Windows Server 2008, se encuentran dentro de estas tecnologías nacidos bajo el paraguas de TWC. Todos ellos han demostrado su eficacia, y se encontrarían dentro de esos productos con bajos niveles de incidencia que mencionamos. 117
  • 138. La protección de datos personales: Soluciones en entornos Microsoft 10.3.1. Common Criteria Un gran problema subjetivo con el que nos encontramos en muchas circuns- tancias, es el de cuantificar el nivel de seguridad de una determinada aplicación o sistema operativo. Hablamos de subjetividad porque evidentemente cada cual lo verá desde su punto de vista y en función de la experiencia propia. Además, nos encontramos con los famosos “mitos de la seguridad”, que en ningún momento son analizados ni con números, ni teniendo en cuenta los factores que pueden llegar a deducirse de los mismos. Con objeto de determinar si un Sistema Operativo es o no seguro, éste debe poder ser cuantificado con datos objetivos y desde diversas perspectivas. El abanico de posibilidades es amplio, desde la perspectiva de una organización de tipo independiente, hasta la que puede tener cualquier compañía desarrolladora, junto a otras. Este sistema cuantificado debe aportar unos factores objetivos pudiendo medir así el nivel de seguridad ofrecido por el sistema. Esto es Common Criteria (ISO_IEC 15408). La importancia de encontrarse dentro del marco de Common Criteria queda establecida al ceñirse a una serie de parámetros de seguridad, aceptados en la actualidad por 24 de los países más industrializados en todo el mundo. Estos criterios de seguridad se utilizan como elementos de medida en entornos tan importantes como la administración y la banca, junto a otros. Dentro de esos 24 países, España actualmente participa directamente dentro del Common Criteria, y además es uno de los nueve miembros con capacidad de emisión, a través del Centro Nacional de Inteligencia, siendo el Centro Criptográfico el encargado de evaluarlo (http://www.commoncriteriaportal.org/members.html). La certificación Common Criteria ha tenido un largo camino hasta llegar a ser lo que conocemos hoy en día. Desde siempre, los diferentes estamentos administra- tivos han visto la necesidad de plantear una serie de juicios de valoración que pudieran dictaminar lo seguro que podían ser los sistemas. Desde principio de los años 80 en Estados Unidos se recogen una serie de criterios de seguridad que quedan unificados bajo el epígrafe TCSEC (Trusted Computer System Evaluation Criteria), siendo publicados a través del famoso “Libro Naranja” en el año 1985. La organización europea homónima, el ITSEC (Information Technology Security Evaluation Criteria), publica en junio de 1991 una serie de normas de seguridad consensuadas por Francia, Alemania, Holanda y el Reino Unido. A principios de 1993 en Canadá se desarrollan los criterios CTCPEC (Canadian Trusted Computer Product Evaluation) aunando criterios tanto de TCSEC como de ITSEC, a la vez que en Estados Unidos el NIST (Nacional Institute of Standards and Technology) y la NSA (National Security Agency) desarrollaron conjuntamente los FC (Federal Criteria) para la seguridad en la Tecnología de la Información versión 1.0. Se preten- de combinar los conceptos tomando criterios de evaluación tanto de América del Norte como de Europa. Era evidente que tal cantidad de criterios y asociaciones necesitaban establecer una estandarización internacional para adoptar los criterios comunes que deben 118
  • 139. La seguridad en sistemas Microsoft normalizar la seguridad. Así nació la ISO-IEC 15408, que determina el marco de la normalización para establecer pruebas y criterios que tienen como resultado la parametrización de sistemas seguros: Common Criteria. La valoración que Common Criteria realiza de los diferentes sistemas informáticos queda categorizada mediante Evaluation Assurance Level (EAL). Los niveles posibles van desde EAL1 a EAL7, en función de las diferentes pruebas a las que se somete a los sistemas en una serie de laboratorios y escenarios. Dentro de esta graduación, los niveles comprendidos entre el EAL5 y EAL7 están orientados principalmente a productos con técnicas y objetivos muy especializados, por lo que no suelen emitirse para productos que puedan ser distribuidos comercialmente. Actualmente, los Sistemas Operativos Windows Vista y Windows Server 2008 se encuentran en proceso de evaluación, para la adquisición del nivel “EAL4 con argumentos de certificación ALC_FLR.3, AVA_VLA.3” (http://www.niap- ccevs.org/cc-scheme/in_evaluation). Para este proceso de evaluación, es necesario desarrollar una serie de trámites, así como superar múltiples pruebas realizadas en más de 20 escenarios tipo, planteados por el SAIC (Science Aplications Internacio- nal Corp’s). Con anterioridad a la puesta en marcha del proceso de evaluación de Windows Server 2008 o Windows Vista, otros productos Microsoft ya han superado estas pruebas, adquiriendo la certificación EAL4:  Certificate Server 2003 (EAL4+).  Exchange Server 2003 Enterprise Edition (EAL4+).  Groove Workspace (EAL2+).  Internet Security and Acceleration Server 2004 (EAL4+).  Internet Security and Acceleration Server 2004 Enterprise Edition & Service Pack 2 (EAL4+).  ISA Server 2000 with Service Pack 1 and Feature Pack 1 (EAL2+).  SQL Server 2005 Database Engine Enterprise Edition (English) SP1 (EAL1).  Windows 2000 Professional Server & Advanced Server (EAL4+).  Windows 2003 and Microsoft Windows XP (EAL4+).  Windows 2003/XP with x64 Hardware Support (EAL4+).  Windows Mobile 5.0 MSFP (EAL2+).  Windows Mobile 6 (EAL2+).  Windows Rights Management Services (RMS) 1.0 SP2 (EAL4+). 119
  • 140. La protección de datos personales: Soluciones en entornos Microsoft  Windows Server 2003 and Microsoft Windows XP (EAL4+).  Windows Server 2003 Certificate Server (EAL4+).  Windows Server 2003 SP2 including R2 Standard, Enterprise & Itanium Editions, Windows XP Professional SP2 & x64 SP2, Windows XP Embedded SP2 (EAL4+).  Internet Security and Acceleration Server 2006 (EAL4+).  Windows Mobile 6.1 (EAL2+).  SQL Server 2005 SP2 Database Engine (EAL4+).  Exchange Server 2007 SP1 x64 (EAL4+).  SQL Server 2008 Database Engine (EAL1+).  Vista SP1/Windows Server 2008 (EAL1+).  Vista SP1/Windows Server 2008 (EAL4+).  OpenXML SDK v1.0 (EAL1). La acreditación EAL4 es el nivel más elevado que puede ser otorgado a un sistema operativo de tipo comercial que no haya sido construido específicamente para cumplir los niveles EAL5-7. El agregado ALC_FLR.3 certification, identifica que también quedan evaluados los procedimientos que establece el fabricante para el seguimiento y la corrección de defectos que pueden surgir con el paso del tiempo. En el caso de Microsoft, el MSRC (Microsoft Security Response Center). La información de Sistemas Operativos y otros productos, así como el nivel de seguridad adquirido, puede ser consultada en la siguiente URL: http:// www.commoncriteriaportal.org/products_OS.html. Las guías de producto Common Criteria y los informes de Evaluación Técnica (ETR) para los productos Windows XP y Windows 2003, se encuentran disponibles a través de la siguiente URL de TechNet: http://www.microsoft.com/technet/security/ prodtech/windowsserver2003/ccc/default.mspx. Una vez que hayan sido evaluados Windows Server 2008 y Windows Vista, serán generadas y publicadas también las guías correspondientes. 10.3.2. Evaluación de FIPS 140 (Federal Information Processing Standard) FIPS 140-1 y su sucesor FIPS 140-2 proporcionan una serie de estándares de Estados Unidos para la cuantificación de los servicios criptográficos del software. Aquí se establecen los procedimientos recomendados para implementar los algorit- mos de cifrado, el control de los búferes de datos y el manejo de material de clave, así como la integración con el sistema operativo. Determinadas agencias de los 120
  • 141. La seguridad en sistemas Microsoft Estados Unidos sólo compran productos que hayan superado las especificaciones de FIPS 140-1 o FIPS 140-2 (según proceda). En el año 2008, siete componentes de seguridad han completado y superado los componentes de evaluación FIPS 140-2:  Proveedor Criptográfico avanzado de Windows Vista DSS y Diffie- Hellman (DSSENH).  Proveedor Criptográfico avanzado de Windows Vista (RSAENH).  Librerías de Primitivas Criptográficas de Microsoft Windows (bcrypt.dll).  Interfaz Proveedor de soporte de seguridad del Modo del Kernell para Windows Vista (ksecdd.sys).  Librería de Integridad de código (ci.dll).  Cargador de Sistema Operativo de Windows Vista (winload.exe).  Gestor de Arranque de Windows Vista (bootmgr). A través de las siguientes direcciones, pueden obtenerse las políticas de seguri- dad de los diferentes componentes certificados:  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp894.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp893.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp892.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp891.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp890.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp889.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp888.pdf 10.3.3. Iniciativa de recursos compartidos Esta iniciativa pretende establecer el equilibrio, haciendo disponible el código fuente y defendiendo los derechos de propiedad intelectual. Cada uno de los programas de licencias del código fuente se adapta a las necesidades específicas de cada una de las comunidades que comprende Microsoft. Como evolución de esta iniciativa, y en la búsqueda de un compromiso con la seguridad, se genera el Programa de Seguridad para Gobiernos (GSP), con el que se pretende aportar a gobiernos e instituciones públicas la capacidad de acceder al código fuente de Windows, pudiéndose así establecer una serie de procesos de depuración y herramientas de criptografía, cuyo objetivo final no es otro que establecer una mejor protección en los sistemas. Frutos de estos acuerdos aparecen toda una serie de iniciativas conjuntas para mejorar aspectos de la seguridad informática. En España, a modo de ejemplo, el 121
  • 142. La protección de datos personales: Soluciones en entornos Microsoft Centro Nacional de Inteligencia y Microsoft colaboran conjuntamente para la elaboración de plantillas de seguridad para diferentes entornos de trabajo de la Administración. 10.3.4. Programa para la cooperación de la seguridad (SCP) En el año 2005, Microsoft establece un acuerdo de cooperativa global, por el que numerosas entidades públicas de 44 países reciben por parte de la corporación información y colaboración para contribuir al aumento de la seguridad de los entornos informáticos públicos: desde información detallada sobre vulnerabilidades informáticas, nuevas actualizaciones de seguridad o políticas generales de seguri- dad de los productos de Microsoft, hasta un canal de comunicación directa y cons- tante con los expertos de la compañía en esta área, para la identificación conjunta de problemas, así como el estudio de los mejores procesos de respuesta ante incidentes. En el año 2007, a través de acuerdos con INTECO, y 2008, a través del CCN- CERT (Capacidad de respuesta ante Incidentes de Seguridad de la Información del Centro Criptológico Nacional), adscrito al Centro Nacional de Inteligencia, España entra en el programa constituyendo el país número 45 en este acuerdo de coopera- ción. Con este acuerdo de cooperación, se pretende prevenir, mitigar y anticipar los efectos de incidentes y ataques a los sistemas de la administración. 10.3.5. Seminarios de seguridad Adicionalmente a las guías y herramientas de seguridad, proporcionadas a todos los usuarios de los sistemas de información, Microsoft planifica y ejecuta toda una serie de eventos, seminarios y sesiones técnicas cuyo objetivo es acercar las diferentes tecnologías al usuario final. A través de presentaciones y escenarios, se pretende aportar conocimientos, metodologías y posibilidades de resolución de diversas situaciones que pueden presentarse. Se capacitará a los asistentes a los diversos eventos para poner en marcha las diferentes tecnologías tratadas de forma segura. Aunque muchos de los seminarios son de tipo presencial, otros, como por ejemplo los Webcasts, se encuentran disponibles en fórmulas no presenciales, tanto en formato online, como en modo offline, permitiendo este último un seguimiento del mismo aunque ya se haya realizado. Dentro de este tipo de seminarios y en el área de seguridad, se incluye una serie de ellos donde se han evaluado desde un punto de vista técnico diferentes normas y reglamentos aplicables a las Tecnologías de la información. Entre ellos se encuentran los elementos de aplicación sobre la Ley Orgánica de Datos de Carácter Personal y su Reglamento en vigor. El acceso a dichas sesiones técnicas puede realizarse a través de la siguiente dirección: http://www.microsoft.com/spain/technet/jornadas/webcasts/ webcasts_ant.aspx?id=13. 122
  • 143. 11 La aplicación del reglamento de seguridad en los sistemas Microsoft Uno de los objetivos fundamentales a resolver por parte de los responsables de seguridad informática, es materializar el cumplimiento de las normas de seguridad. Sus soluciones deben observar múltiples factores, aunando la protección de datos, los sistemas de correo electrónico, las funcionalidades de los sistemas operativos, junto a otros criterios de actuación. Sin una referencia clave de cómo actuar, sus circunstancias operativas son realmente complejas. El nuevo Reglamento de Seguridad de desarrollo de la Ley Orgánica de Protección de Datos de Carácter Personal se publica con fecha de 19 de enero de 2008. Corresponde al Real Decreto 1720/2007 y entra en vigor el 19 de abril de 2008, fecha en la cuál los sistemas tendrán que haberse adaptado a las condiciones exigi- das en este nuevo reglamento, habiendo acometido los cambios técnicos necesarios. Este manual tiene como objetivo dar respuesta a esas incertidumbres, estableciendo los criterios básicos para el cumplimiento de la norma y los mecanismos técnicos de aplicación en escenarios de utilización de Sistemas Microsoft. Abarcar en profundidad todos los aspectos de la seguridad demandaría un trabajo mucho más extenso. En el presente documento nos centraremos principal- mente en todos aquellos elementos que la norma cita y que deben cuidarse para establecer unos mecanismos de seguridad consecuentes, tales como ficheros que puedan contener datos, la protección de los datos almacenados, el control de acce- sos y la protección de los medios de correo electrónicos, junto a otros. Considerando que el elemento aglutinador fundamental de los entornos son los sistemas operativos, se contemplarán inicialmente las características de seguri- dad que aportan los mismos, centrándonos en un aspecto fundamental como son 123
  • 144. La protección de datos personales: Soluciones en entornos Microsoft las directivas de seguridad, para ir con posterioridad ampliando funcionalidades que pueden reportar otros productos tales como Microsoft Exchange Server 2007 o Microsoft Office 2007, como plataformas importantes dentro de las empresas y organismos y que sustentan documentos e información objeto de atención para la norma. En la actualidad, estas plataformas desempeñan labores críticas en las empresas y su uso es exhaustivo, por lo que tenemos que tener en cuenta los facto- res que marcan la norma con respecto a ellas, considerando que éstas presentan medidas propias que pueden ser utilizadas para salvaguardar la información y que serán tenidas en cuenta también en esta guía. 11.1.Tecnología de seguridad en Microsoft Windows La norma establece una serie de criterios básicos y fundamentales a considerar. Evidentemente, a partir de ahí, aplicar más o menos medidas de seguridad será un criterio del administrador, que dependerá también de los mecanismos disponibles en las organizaciones. La norma establece que debe ser salvaguardada aquella información “con datos de carácter personal”, indistintamente si ésta se encuentra almacenada localmente en un sistema o bien si la información se desplaza en cualquier proceso de comunicación. También será necesario valorar la existencia de información temporal generada por la utilización de ficheros, independientemente de cual sea su formato. La norma establece también que este tipo de ficheros temporales deben disponer de las mismas medidas de seguridad que el fichero original a partir del cuál se han creado. Bajo el término de seguridad informática englobamos un amplio espectro de elementos que se observan tanto a nivel local de una máquina, como a la totalidad de un sistema de red. Evidentemente, ni la norma, ni esta guía de aplicación, pretenden establecer todas las medidas posibles (que podrían ser interminables), sino una serie de características básicas que deben tenerse en cuenta y que pueden afectar fundamentalmente a los datos personales. Desde este criterio podemos indicar para un entorno Windows, que la gestión básica de la seguridad parte de las directivas de seguridad. Éstas establecen configuraciones para elementos críticos en la seguridad de un sistema y, por tanto, son parte fundamental para asegurar que estamos aplicando correctamente la norma. Tanto Windows Server 2008 como Windows Vista cuentan con sus directivas de seguridad. Éstas realmente lo que hacen es modificar la base de datos de seguridad del sistema, que se encuentra ubicada en la siguiente ruta: %systemroot%securityDatabasesecedit.sdb. Las directivas pueden definirse en un nivel local para una máquina concreta mediante las políticas locales, o bien, cuando los sistemas se encuentran ubicados en el marco de un domino, desplegarse para todo un entorno de red, mediante una estructura centralizada a través de las directivas de seguridad de dominio. La ventaja que nos aporta la utilización del Directorio Activo de Windows Server 2008 es la de permitirnos definir una configuración de la seguridad más controlada para todos los equipos de una red, minimizando los costes de administración. Esta 124
  • 145. La aplicación del reglamento de seguridad en los sistemas Microsoft administración centralizada puede desplegar la base de datos en diferentes contene- dores, sin necesidad de tener que desplazarse físicamente a cada uno de ellos. Además, la disposición jerarquizada dentro del Directorio Activo, basada en conte- nedores, permite establecer diferentes medidas de control de seguridad en función de los diferentes niveles que se quieran aplicar. Eso sí, no debe confundirse nunca las Directivas de Seguridad con las Políticas de Grupo (GPO), ya que estas últimas son objetos aplicados sobre Sitios, Dominios o Unidades Organizativas, que modifi- can mediante las Directivas los estados de los usuarios y equipos de un domino. Hay que matizar que las directivas de seguridad son, por tanto, una parte más de todo el conjunto de una GPO. Todo aquel que quiera llegar a aspectos más avanzados en la implementación de la seguridad cuenta con una serie de guías y procedimientos que Microsoft ha dispuesto para tal fin, basados en buenas prácticas, fruto de experiencias reales. Estas guías abordan aspectos fundamentales como pueden ser la gestión de las actualizaciones, la guía de administración de riesgos, y las guías de seguridad y operaciones para diferentes sistemas operativos. El acceso a dicha información puede realizarse a través del siguiente enlace: http://www.microsoft.com/spain/technet/ security/guidance/default.mspx. 11.2.Tecnologías aplicables a medidas de nivel básico Como indicábamos anteriormente, uno de los elementos fundamentales para la aplicación de los mecanismos de seguridad en los entornos Windows, son las directivas de seguridad. Agrupadas bajo el “Security Configuration Manager”, Microsoft ha establecido una serie de pautas, plantillas y mecanismos para estable- cer de forma conveniente la aplicación de estas medidas básicas de seguridad. Están basadas en el análisis de la configuración de seguridad y la aplicación de plantillas tanto a nivel local como a nivel de dominio o unidades organizativas. También aquí se determinan aspectos fundamentales para establecer los criterios de auditoría y el establecimiento de un patrón de seguridad para la asignación de permisos sobre objetos a través de las plantillas de seguridad. Para conocer las directivas de seguridad aplicadas sobre una máquina es necesario considerar diversos factores para determinar cuáles están siendo efectivas sobre la misma. Este resultante vendrá definido por la suma de directivas locales y los posibles objetos de políticas de grupo que pudieran estar afectándole, tanto en el nivel de dominio, como de unidades organizativas de las que pudiera depender el objeto equipo. En determinadas circunstancias, cuando no ha quedado muy claro qué directivas se encuentran aplicadas o realmente cómo ha quedado la seguridad de una máquina, podemos hacer uso de una herramienta denominada Conjunto Resultante de Directivas (RSoP, Resultant Set of Policy). Esta herramienta nos permite realizar esta comprobación o bien simular las configuraciones de directivas que se aplican a los equipos mediante directiva de grupo, evaluando así cómo podría quedar la seguridad si le aplicáramos otra directiva con anterioridad a hacer efectiva la nueva configuración. 125
  • 146. La protección de datos personales: Soluciones en entornos Microsoft A todos los efectos, la aplicación de directivas de seguridad en el nivel de GPO por la inclusión de un equipo en Directorio Activo tiene dos efectos importantes. La centralización de la aplicación de directivas, que nos suministra la capacidad de generar contenedores para la aplicación de seguridad en equipos con características similares, y el avance en ciertas características de seguridad como el uso del proto- colo Kerberos para los mecanismos de autenticación en la red o la posibilidad de utilizar los mecanismos de PKI (Public Key Infraestructure), con el despliegue automático de certificados a través de los mecanismos integrados en el Directorio Activo. Otro de los posibles mecanismos que modifican tanto aspectos básicos en la configuración como otros más avanzados, lo encontramos en Windows Server 2008 con la utilidad del Asistente para la configuración de seguridad (SCW). Esta herra- mienta nos permite, a través de una serie de asistentes, establecer una configuración de seguridad más global para el fortalecimiento de los servidores. SCW, además de posibles configuraciones de funciones de directivas de seguridad, nos permite esta- blecer la configuración del Firewall, tanto de entrada como de salida, que incorpora Windows Server 2008, controlar los servicios que pudieran estar ejecutándose y controlar las autentificaciones y configuraciones de seguridad en el nivel de red. 11.2.1. Ficheros temporales Un aspecto importante en la protección de datos consiste en tener controlados todos aquellos ficheros que pudieran contener información que debe encontrarse sujeta a la norma. Recordemos que también están sujetos a la norma los ficheros temporales generados a partir de otros ficheros que pudiéramos tener abiertos. Estos temporales se generan con propósitos especiales, como el de mantener una copia de la información ante posibles contingencias del fichero original; otras veces supone un fichero para el paso y análisis de la información; y en otras circunstan- cias, cuando se está realizando algún proceso de implantación o instalación, supone el proceso de descompresión de ficheros antes de que sean procesados finalmente. En función de lo anterior, Microsoft, consciente de la importancia de mantener la seguridad sobre los ficheros temporales en los entornos Windows, marca una operativa en la que cuando un fichero de este tipo se genera adquiere los mismos permisos del original. Esto asegura la garantía de confidencialidad, proporcionando solamente derechos sobre el temporal a aquellos usuarios que los poseyeran sobre el fichero original. Como medida de protección en esta misma línea, de forma automática cada vez que un fichero es cerrado, el fichero temporal desaparece, evitando de esta forma tener que estar pendiente de los temporales generados automáticamente. Aún así, puede suceder que algún suceso no controlado, como un corte de luz que ocasiona un apagado inesperado, pudiera conllevar que el fichero temporal queda- se abierto. Este factor dependerá del tipo de aplicación sobre la que se estuviera trabajando. De todas formas, la protección anterior basada en la herencia de permi- sos protege contra accesos no permitidos a este fichero temporal. Para eliminar estos posibles residuos de nuestra máquina, podemos utilizar una herramienta que 126
  • 147. La aplicación del reglamento de seguridad en los sistemas Microsoft incorpora el sistema: Liberador de espacio en disco. Además, esta herramienta puede programarse para que realice las operaciones de forma periódica y automáti- ca, liberándonos de estar atentos a esta tarea administrativa. Ficheros temporales. Otro aspecto también observado es el uso de la memoria virtual y los datos que puedan quedar aquí almacenados. El fichero de paginación es realmente una extensión de una parte del disco duro para ser utilizada como memoria RAM cuando se supera el tamaño de la memoria física instalada. Windows mueve parte del contenido a esta memoria virtual, liberando espacio y permitiendo disponer en memoria RAM de nueva información. Los datos almacenados en la memoria virtual son recuperables cuando sean necesarios. En todo ese movimiento de infor- mación de lectura y escritura sobre el fichero de paginación, es posible que queden también ficheros con datos personales aquí almacenados. Cuando el sistema está en activo, no se permite el acceso al mismo, por lo que los datos que se puedan encon- trar estarían protegidos. El problema puede surgir cuando un atacante potencial tiene acceso físico a la máquina y ésta se encuentra apagada, pudiendo hacerse mediante algún método con dicho fichero. Con objeto de evitar este problema, Windows plantea la posibilidad, mediante una directiva de seguridad, de borrar el contenido del fichero de memoria virtual cuando se apaga la máquina. Para ello, dentro de las Directivas de Seguridad en Opciones de Seguridad deberíamos habi- litar la opción de apagado: “borrar el archivo de páginas de la memoria virtual”. 11.2.2. Artículo 89. Funciones y obligaciones del personal 1. Las funciones y obligaciones de cada uno de los usuarios o perfiles de usuario con acceso a los datos de carácter personal y a los sistemas de información estarán claramente definidas y documentadas en el documento de seguridad. También se definirán las funciones de control o autorizaciones delegadas por el responsable del fichero o tratamiento. 127
  • 148. La protección de datos personales: Soluciones en entornos Microsoft 2. El responsable del fichero o tratamiento adoptará las medidas necesarias para que el personal conozca de una forma comprensible las normas de seguridad que afecten al desarrollo de sus funciones, así como las consecuencias en que pudiera incurrir en caso de incumplimiento. Dentro de este articulado, el reglamento exige el cumplimiento de unos meca- nismos para que los usuarios que hagan uso de ficheros de datos de carácter perso- nal conozcan cómo deben manejar este tipo de datos, y cuáles serán sus derechos y obligaciones. Evidentemente, parte del artículo, y concretamente el punto 1, establece que esta necesidad debe quedar plasmada en el documento de seguridad que la empre- sa generará con respecto a este tipo de datos. Adicionalmente, en el punto 2 se establece la necesidad de que los usuarios puedan conocer de forma comprensible las normas de seguridad que afectan al desarrollo de sus funciones, y en este sentido la forma de comunicación puede ser de múltiples tipos. Por tanto, queda claro que uno de los aspectos fundamentales para la protec- ción de datos es la necesidad de que los usuarios conozcan que existen unas normas de seguridad al respecto, y que de una u otra forma están supeditados a ellas. Se hace de este modo necesario que éstos estén debidamente informados. Una de las posibilidades de asegurarse que los usuarios van ser conscientes de esta circunstan- cia, es la aparición de un texto con anterioridad al inicio de sesión de forma interactiva. Mediante las directivas de seguridad, es posible establecer un título y un texto que será presentado antes de que el usuario pueda iniciar su sesión, tanto en el dominio como localmente. En dicho texto se puede establecer una información para el usuario de que existe una norma de seguridad que le afecta, así como informarle de una ubicación donde pueda localizar datos más exhaustivos que le permitan conocer con detalle, si lo creyera oportuno, lo establecido en dicha norma. Funciones y obligaciones; directiva de aplicación. 128
  • 149. La aplicación del reglamento de seguridad en los sistemas Microsoft La definición de dicho aviso legal se puede generar mediante la conjunción de las siguientes directivas de seguridad, en sus opciones de seguridad correspondientes:  Inicio de sesión interactivo: título del mensaje para los usuarios que intentan iniciar una sesión.  Inicio de sesión interactivo: texto del mensaje para los usuarios que intentan iniciar una sesión. En este texto podrían incluirse, además de la información preceptiva de notificación para el cumplimiento de la Ley Orgánica y de su correspondiente Reglamento, las posibles direcciones URL de consulta en la página de la intranet. En ella, los usuarios podrán conocer de forma particular los textos donde se describen las funciones y obligaciones que les atañen. También pueden quedar descritas aquellas acciones y procedimientos que deben acometer en caso de que se haya producido una incidencia. Funciones y obligaciones; mensaje en pantalla. Muchas empresas han optado por utilizar la solución de gestión documental Ms Office SharePoint 2007 como mecanismo para el almacenamiento y la publica- ción de textos y anexos, descritos en el documento de seguridad. Este servicio aporta dos funcionalidades importantes aplicables a éste y otros articulados del reglamento existente:  Publicación de documentos, como los planteados en este artículo, que permitan que los afectados por el documento de seguridad conozcan sus obligaciones y los procedimientos que pueden emplear, a quién dirigirse, o el canal de notificación a utilizar.  Flujo documental, que permite establecer un canal de gestión de docu- mentos, consiguiendo por ejemplo, que aquellos que detecten una inci- dencia en ficheros afectados por la LOPD, puedan notificar al responsable 129
  • 150. La protección de datos personales: Soluciones en entornos Microsoft del fichero dicha incidencia, mediante un procedimiento declarado a través del mismo sistema Ms Office SharePoint 2007. La aplicación de permisos en los diferentes documentos a través de Ms Sharepoint garantizará que sólo aquellos que se vean afectados por el documento de seguridad o participen en el sistema de gestión de datos de carácter personal, puedan acceder a la documentación existente. 11.2.3. Artículo 90. Registro de incidencias Deberá existir un procedimiento de notificación y gestión de las incidencias que afecten a los datos de carácter personal y establecer un registro en el que se haga constar el tipo de incidencia, el momento en que se ha producido, o en su caso, detectado, la persona que realiza la notificación, a quién se le comunica, los efectos que se hubieran derivado de la misma y las medidas correctoras aplicadas. A través de este artículo, el reglamento expresa la necesidad de plantear un procedimiento para que los usuarios puedan notificar cualquier incidencia que haya podido afectar a los ficheros que contengan datos de carácter personal. Por incidencia, el mismo reglamento establece su definición en el apartado i) dentro del artículo 5: Incidencia: cualquier anomalía que afecte o pudiera afectar a la seguridad de los datos. Dentro de estas anomalías podremos incluir la eliminación, pérdida o modifi- cación de la información que contuviera un fichero de carácter personal. Los mecanismos para el registro de la información deben quedar definidos en el documento de seguridad y ser comunicados a los usuarios, que de una u otra forma tendrán que notificar las incidencias para establecer por parte del responsa- ble del fichero las medidas correctoras oportunas. Al igual que en el caso anterior, el procedimiento de notificación puede ser implementado a través del Microsoft Office SharePoint, que permitirá un flujo de trabajo de la información, permitiendo disponer una metodología bajo gestión documental para la notificación de dichas incidencias y su posterior resolución por parte del Responsable del Fichero. Aunque existe la posibilidad de establecer un procedimiento para el descubri- miento de incidencias a través de los diferentes sistemas de auditoría existentes para los servicios y sistemas Windows, tal tratamiento sólo es exigible de forma directa para los datos de nivel alto. En función de ello, los sistemas de registro de acceso serán tratados posteriormente en el capítulo dedicado a las tecnologías aplicables a datos de nivel alto. 11.2.4. Artículo 91. Control de acceso (puntos 1 y 3) 1. Los usuarios tendrán acceso únicamente a aquellos recursos que precisen para el desarrollo de sus funciones. 3. El responsable del fichero establecerá mecanismos para evitar que un usuario pueda acceder a recursos con derechos distintos de los autorizados. 130
  • 151. La aplicación del reglamento de seguridad en los sistemas Microsoft 11.2.4.1. Control de acceso en Windows Vista y Windows Server 2008 Uno de los mecanismos más importantes que deben considerarse a la hora de establecer un sistema de seguridad aplicable a ficheros sujetos a LOPD, es la deci- sión y puesta en práctica de procedimientos que garanticen el acceso de los usuarios exclusivamente a aquellos datos que les corresponden por sus funciones. Evidente, el tratamiento de los datos dependerá de los sistemas de almacena- miento y servicios utilizados. Nosotros centraremos la valoración en los servidores de ficheros, los servidores de correo y el sistema documental de Ms Office. Cuando una aplicación bajo la acción de un usuario intenta acceder a un recurso con objeto de realizar una operación (este factor dependerá del objeto: fichero, carpeta, impresora, objetos del directorio activo, etc.), intervienen una serie de mecanismos contemplados en los descriptores de seguridad. Estos descriptores de seguridad los conforman por una parte las SACL (System Control Access List), de las que se tratarán posteriormente, y por otro lado un elemento importante, las DACL (Discretionary Access Control List). Cuando queremos establecer un control para acceder a un objeto, en Windows Server 2008 y Windows Vista se realiza a nivel del objeto, estableciendo diferentes niveles de permisos y accesos. Cuando se quiere asignar un control a un objeto, estos se establecen sobre los descriptores de seguridad, de tal forma que cada vez que un usuario intenta acceder al objeto el subsistema de seguridad del sistema operativo comprueba las autorizaciones para realizar las acciones sobre dicho objeto. Estos controles son asignados a través del descriptor de seguridad mediante la aplicación de DACL. Realmente, un descriptor de seguridad es una estructura de datos binaria que contiene los siguientes elementos:  Cabecera. Contiene un número de revisión y un conjunto de atributos que describen las características de seguridad del descriptor.  Propietario. Determina quién es el propietario del objeto mediante el SID del mismo. Este propietario puede modificar permisos y conceder a otros principales de seguridad la posibilidad de tomar posesión.  Grupo Primario. Contiene el SID del grupo primario del propietario. Este dato para compatibilidad sólo tiene validez en subsistemas POSIX, pero en el resto de Windows Vista es ignorado.  DACL. Lista las entradas de control de acceso (ACEs), que permiten o deniegan a un SID una funcionalidad.  SACL. Si las anteriores controlaban los accesos a objetos, éstas auditan las acciones efectuadas. Cuando un proceso intenta acceder a un objeto asegurable, el sistema determi- na si se concede o no dicho acceso. Si el objeto no tuviera un DACL, el sistema 131
  • 152. La protección de datos personales: Soluciones en entornos Microsoft permite el acceso; para cualquier otra circunstancia, el sistema busca las ACEs correspondientes para dicho objeto y determinará el resultado final. Cada ACE contiene los derechos que se permiten o deniegan para un principal de seguridad o una sesión validada. Cada ACE incluye la siguiente información:  Un SID que identifica a un usuario o grupo.  Una máscara de acceso que determina los derechos.  Unas marcas de atributo que determinan cuándo un objeto hijo puede heredar esta ACE.  Un identificador que indica el tipo de ACE. Windows 2008 soporta 6 tipos de ACEs: 3 para todos los objetos (acceso denegado, acceso permitido y sistema auditado) y 3 específicos para objetos del directorio activo, donde se permiten, deniegan o auditar los accesos sobre propiedades, conjuntos de propiedades y herencias sobre los objetos del directorio activo. Cuando se intenta realizar un acceso, el sistema compara cada ACE con el Access Token que ha obtenido cada aplicación. Este Access Token contiene los SIDs que identifican al usuario y a los grupos a los que perteneciera, además del SID de validación que identifica la sesión actual. El resultado final de un acceso queda determinado pues por la suma de derechos asignados al usuario más los derechos concedidos a los grupos a los que perteneciera. Hay que tener en cuenta que las denegaciones prevalecen sobre la permisividad, por lo que si un usuario tiene todos los permisos pero pertenece a un grupo al que le deniegan el acceso, este no accede- ría. De la misma forma ocurriría si todos los grupos a los que pertenece un usuario tienen concedidos los derechos pero al usuario se los han denegado. Windows Vista y Windows Server 2008 implementan mecanismos para asegu- rar a nivel local el poder acceder a los datos mediante DACL. Para la utilización de estas DACL será necesario que el sistema de ficheros donde se aloja la información esté establecido en NTFS. La utilización de este sistema de ficheros puede realizarse durante la instalación del sistema operativo, o si en su momento fue instalado haciendo uso de los sistemas FAT o FAT32, se puede llamar a la aplicación convert.exe para convertir el sistema de fichero a NTFS. Este proceso es irreversible. La asignación de los permisos en todo caso es labor del administrador o el propietario de los ficheros y carpetas. El sistema operativo establece unos permisos predeterminados basados en la herencia sobre los objetos hijo. Habrá que tener siempre en cuenta todos los factores para determinar los permisos reales que tendrá un usuario sobre un objeto sumando los derechos tanto suyos como de los grupos a los que perteneciera. De cara a realizar una administración más cómoda, habría que pensar en establecer una administración de los permisos basados en los Grupos de Seguridad, de tal forma que el establecimiento de los mismos conlleve el menor coste administrativo posible. No es lo mismo ir asignando un permiso de lectura a 50 usuarios, permitirles imprimir a esos mismo 50 usuarios en una impresora determinada y concederles poder ver una serie de propiedades sobre otros objetos 132
  • 153. La aplicación del reglamento de seguridad en los sistemas Microsoft del Directorio Activo, que incluirlos a todos en un grupo y conceder los derechos sobre el grupo. No sólo es más fácil la administración, pues sólo bastaría con incluir a un usuario en el grupo para obtener esos privilegios, sino que se gana en comodi- dad de cara a comprobar los permisos en los controles de seguridad. Si por algún motivo a uno de esos usuarios no quisiéramos concederle uno de los derechos, bastaría con denegarle el correspondiente permiso o sacarlo del grupo y concederle explícitamente los permisos que necesitara. Otro aspecto importante relacionado con los derechos de acceso es quién tiene la posibilidad de concederlos. Hay que tener en cuenta que un usuario, por ser el propietario de un objeto, tiene derechos para poder modificarlo aunque explícita- mente se le hubieran denegado, por lo cual hay que tener este dato en cuenta de cara a conceder o no este derecho. Por defecto, el grupo de administradores tiene el derecho de toma de posesión, es decir, podría modificar el SID del elemento propie- tario del descriptor de seguridad correspondiente para sobrescribirlo por el suyo. Mediante directivas se puede conceder una directiva que permite tomar posesión sobre ficheros u objetos a principales de seguridad. Sobre los derechos de usuario habría que conceder el de tomar posesión de archivos y otros objetos en la máquina que se deseara. Aunque la implementación de los permisos de seguridad aplicables sobre carpetas y ficheros para Windows Vista mantiene en su sistema básico el mismo planteamiento asignable a los sistemas en Windows XP y 2003, existe una serie de cambios que deben conocerse, puesto que condicionan algunos de los aspectos funcionales de los permisos de seguridad. Uno de los aspectos principales que se han modificado por defecto en Windows Vista son las ACL (Listas de control de acceso) predeterminadas para Windows XP. En este sentido, uno de los elementos de cambio más notables es la desaparición de los permisos asignados al grupo “Todos”, sustituidos por la asigna- ción al grupo de “Usuarios Autentificados”. Adicionalmente, en muchas de las ubicaciones originales, como por ejemplo las carpetas raíz de las particiones NTFS existentes, se han mejorado notablemente dichas ACL. Otro elemento significativamente diferente lo constituyen los permisos y propietario existentes en la carpeta Windows, así como todos los archivos y subcarpetas que ésta contiene. En las versiones anteriores a Windows Vista, el propietario de dicha carpeta era el grupo de administradores. Esta condición ha cambiado, para lo que Microsoft ha creado una nueva figura: “TrustedInstalled”, que permite establecer mecanismos adicionales de integridad del sistema, siendo esta cuenta la propietaria de la carpeta del sistema. Esto posibilita que un proceso que trabaje como administrador o cuenta del sistema pueda sustituir o eliminar una librería o aplicación existente en la máquina. Con los permisos asignados actualmente al grupo de administradores, éstos deben tomar posesión sobre un objeto, y aplicar unos nuevos permisos para poder eliminar un fichero o carpeta existente. También se han modificado algunas de las ACE (Access Control Entries, Entradas de control de acceso) funcionales de carpetas que han cambiado en su nomenclatura con respecto a las versiones anteriores. Aparece la carpeta “Usuarios” 133
  • 154. La protección de datos personales: Soluciones en entornos Microsoft que sustituye a la antigua carpeta “Documents and settings”. Por funcionalidad, ésta se mantiene, aunque sólo en aquella vista en la que habilitamos las carpetas y ficheros ocultos del sistema. Igualmente, se ha mantenido por compatibilidad para aquellas aplicaciones que utilizaban dicha ruta a través de la variable de entorno “%userprofile%”, manteniendo una ACE que permite el acceso a través del objeto “Documents and Settings”, actualmente no una carpeta sino un punto de unión, si un objeto buscado se encuentra realmente en la ruta buscada; en caso contrario, devolverá un mensaje de denegación del acceso. Por ejemplo, si solicitamos un fichero que se encuentra en la siguiente ruta: “C:documents and settingsjlMy Documentsfichero.doc” el sistema nos permitirá abrir el fichero, cuando éste se encuentre en la ubicación referida; de lo contrario, nos devolverá un mensaje de error, denegándonos el acceso. Obviando estas modificaciones, el sistema de asignación de permisos, aunque cambia la perspectiva de la generación y aplicación de ACE a través de la consola, adaptándolo a la implementación del sistema de UAC (User Account Control), en su base mantiene las mismas pautas de aplicación que en los sistemas anteriores. Por tanto, la asignación según la aplicación del reglamento viene deter- minada por lo dispuesto en el Documento de Seguridad de la organización. Será labor del responsable del fichero que se establezcan de acuerdo a un criterio de asignación coherente para el desarrollo de las funciones del personal implicado. En muchas circunstancias, las anidaciones de grupos y los sistemas de membresía existentes en una organización pueden hacer complejo el conocer qué permisos finales tiene un usuario sobre un fichero que pudiera contener datos de carácter personal. Para dar una solución a esta posible problemática, tenemos la posibilidad de utilizar la herramienta de permisos efectivos que nos proporciona la visión de derechos finales que tendrá concedido un usuario o un grupo específico sobre un determinado objeto. Para iniciar este proceso se accederá a las propiedades de seguridad del objeto en cuestión. Permisos efectivos. 134
  • 155. La aplicación del reglamento de seguridad en los sistemas Microsoft 11.2.4.2. Control de acceso en Microsoft Exchange 2003 Exchange Server 2007 cambia el modelo de permisos con respecto a versiones anteriores y crea nuevos roles de administración que permiten delegar de una forma más flexible. En Exchange Server 2003 existían tres tipos de administradores:  Exchange Full Administrator.  Exchange Administrator.  Exchange View Only Administrator. Ahora, con Exchange 2007 se crean los siguientes roles de administradores:  Exchange Organization Administrators.  Exchange Recipient Administrators.  Exchange View-Only Administrators.  Exchange Public Folder Administrators. Durante la fase de preparación de Directorio Activo y de los dominios, el asistente de instalación crea los roles de administrador en una nueva unidad organizativa de Exchange denominada Microsoft Exchange Security Group. Exchange Server 2007 implementa los llamados conjuntos de propiedades, los cuales son agrupaciones de atributos de Directorio Activo y cuyo control de acceso se realiza mediante ACE (entrada de control de acceso) al grupo, en lugar de confi- gurar una ACE por cada propiedad. Gracias a estos conjuntos de propiedades, se puede realizar una delegación de acceso más detallado y flexible que en versiones anteriores. Además, Exchange 2007 incluye varias mejoras:  Los conjuntos de propiedades han dejado de basarse en los conjuntos de propiedades de Directorio Activo, por lo que se elimina la incertidumbre de cambios en las versiones futuras de los conjuntos de propiedades de Directorio Activo.  Los atributos creados por la extensión de esquema de Exchange son los únicos miembros de los conjuntos de propiedades específicos de Exchange.  Los conjuntos de propiedades específicos de Exchange permiten la crea- ción y la implementación de un modelo de permisos de seguridad delega- do, que es específico para la administración de los datos de destinatarios de correo de Exchange. Dado que los atributos se trasladan entre conjuntos de propiedades, se debe actualizar la estructura de permisos de destinatarios de Exchange 2003 al implementar Exchange 2007 en un entorno heredado. Esto se hace ejecutando el comando setup.exe /PrepareLegacyExchangePermissions. 135
  • 156. La protección de datos personales: Soluciones en entornos Microsoft Los administradores de Exchange 2007 pueden administrar tres tipos de datos:  Datos globales. Los datos globales se encuentran almacenados en un contenedor de configuración de Directorio Activo y no están asociados a ningún servidor en particular. Entre los datos que se incluyen dentro de este grupo están las directivas de buzón, listas de direcciones y la configu- ración de mensajería unificada y, en general, los datos globales de organi- zación de Exchange, por lo que se recomienda que sólo a los usuarios de confianza se les permita el acceso a esta información.  Datos de destinatarios. En este grupo se incluye información de destina- tarios, grupos de distribución, contactos habilitados para correo, buzones y otros tipos de destinatarios como carpetas públicas.  Datos de servidor. Se encuentran almacenados en los nodos de cada uno de los servidores Exchange en el Directorio Activo. En este grupo se encuentra la información particular de conectores de recepción, directo- rios virtuales, configuraciones por servidor y datos de grupos de almace- namiento y buzones. La función de administradores de la organización de Exchange ofrece a los administradores acceso completo a todas las propiedades y objetos de Exchange en la organización de Exchange. Cuando se instala Exchange 2007, se agrega la función Administradores de la organización de Exchange como miembro del grupo local de administradores en el equipo donde esté instalando Exchange. La función de administradores de destinatarios de Exchange tiene permisos para modificar cualquier propiedad de Exchange en un usuario, contacto, grupo, lista de distribución dinámica u objeto de carpeta pública de Directorio Activo. Los usuarios que son miembros de esta función de administrador de destinatarios de Exchange no tienen permisos sobre los dominios en los que no se ha ejecutado Setup.exe /PrepareDomain. La función de administradores de servidores de Exchange sólo tiene acceso a los datos de configuración de Exchange del servidor local, ya sea en Directorio Activo o en el equipo físico en el cual está instalado Exchange 2007. La función de administradores de sólo vista de Exchange tiene permiso de sólo lectura en todo el árbol de la organización de Exchange en el contenedor de configu- ración de Directorio Activo y permiso de sólo lectura en todos los contenedores de dominio de Windows que tienen destinatarios de Exchange. La función de Administradores de carpetas públicas de Exchange tiene permi- sos administrativos para administrar todas las carpetas públicas. Esta función de administrador tiene concedido el derecho extendido “Crear carpeta pública de alto nivel”. Los miembros de esta función pueden crear y eliminar carpetas públicas y administrar configuraciones de carpeta pública como réplicas, cuotas, límites de edad, permisos administrativos y permisos de cliente. 136
  • 157. La aplicación del reglamento de seguridad en los sistemas Microsoft Con respecto a los destinatarios de correo, Exchange otorga de forma predeter- minada permisos completos y permiso de enviar como al propietario del buzón. Ningún otro destinatario tiene permisos en otro buzón que no sea el suyo propio, ni siquiera el administrador de la organización. Estos permisos se gestionan en dos niveles: permisos del buzón y permisos de Directorio Activo. Permisos del buzón Dentro de los permisos del buzón se encuentra el permiso de acceso completo al buzón (Full Access). Cuando se le otorga a un usuario el acceso completo al buzón de otro usuario, éste adquiere la capacidad de abrir y leer el contenido de todo el buzón; sin embargo, no puede enviar mensajes como si fuera el otro usuario. Este diseño de seguridad lo implementa por defecto Exchange Server 2007 para evitar que, debido a la necesidad de acceder a un buzón, se pueda suplantar la identidad de otra persona, garantizando así la procedencia de los mensajes en la organización Exchange. Para otorgar permisos de enviar como otro usuario, existe el permiso indepen- diente ReceiveAs a nivel de Directorio Activo. La lista de permisos aplicables a nivel de buzón es la siguiente:  FullAccess.  SendAs.  ExternalAccount.  DeleteItem.  ReadPermission.  ChangePermission.  ChangeOwner. Permisos de Directorio Activo El permiso SendAs o enviar como permite que un usuario envíe mensajes desde el buzón de otro usuario como si fuera el propietario del buzón. En ocasiones, algunos roles de personas requieren disponer de esta capacidad. Sin embargo, si se realiza sin el consentimiento del propietario se podría estar vulnerando su privacidad y confidencialidad. Otro de los permisos importantes es el de ReceiveAs o recibir como. Este permiso otorga privilegios de inicio de sesión en todos los buzones de la base de datos en donde se aplica el permiso. También se puede otorgar a nivel de grupo de almace- namiento; en este caso se heredaría a todas las bases de datos del grupo. Por ejem- plo, es posible que desee conceder acceso a la base de datos de buzones para el acceso móvil o para una revisión legal. 137
  • 158. La protección de datos personales: Soluciones en entornos Microsoft La lista de permisos aplicables a nivel de Directorio Activo es la siguiente:  CreateChild.  DeleteChild.  ListChildren.  Self.  ReadProperty.  WriteProperty.  DeleteTree.  ListObject.  ExtendedRight.  Delete.  ReadControl.  GenericExecute.  GenericWrite.  GenericRead.  WriteDacl.  WriteOwner.  GenericAll.  Synchronize.  AccessSystemSecurity. 11.2.4.3. Control de acceso a archivos de Microsoft Office 2007 Normalmente consideramos los ficheros generados a través de Ms Office System como ficheros convencionales, y como tal podemos emplear mecanismos a través de las DACL, descritas anteriormente. Éstos permiten extender dicha funcionalidad, asignando derechos digitales mediante el uso de la tecnología IRM (Information Rights Management). IRM supone una extensión de RMS (Rights Management Services). Este sistema se basa en conexiones de confianza que estable- ce una implementación basada en el uso de certificados. Los mecanismos de seguri- dad quedan establecidos mediante reglas de uso, donde los usuarios reciben una licencia capaz de interpretar dichas reglas. 138
  • 159. La aplicación del reglamento de seguridad en los sistemas Microsoft IRM: aplicación de restricción. Para la realización de la protección y autentificación de los documentos RMS emite una serie de certificados de cuenta de permisos que se encuentran asociados a cuentas de usuario y equipos específicos. Las licencias de uso van a permitir que los usuarios puedan utilizar contenido protegido con RMS. Los certificados de cuenta de permisos contienen la clave pública del usuario, que se utiliza para cifrar los datos que irán destinados a un usuario específico. Los elementos que intervienen en todo el proceso de funcionalidad de los mecanismos de RMS son:  Certificados emisores de licencias de servidor. Se expiden a servidores para que puedan emitir licencias para la publicación, de uso, certificados emisores de licencia de clientes y la generación de plantillas de permisos. El certificado emisor de licencias de servidor que se concede a un servidor de licencias contiene la clave pública del servidor de licencias, mientras que el certificado emisor de licencias de servidor que se concede al servi- dor de certificación raíz contiene la clave pública del servidor de certifica- ción raíz.  Certificados emisores de licencias de clientes. Se utilizan para otorgar a un usuario que pueda publicar contenido protegido mediante los meca- nismos de RMS sin estar conectado a la red corporativa. Contiene las claves pública y privada del certificado; esta última cifrada con la clave pública del usuario que solicitó el certificado. Contiene, asimismo, la clave pública del servidor que emitió el certificado.  Certificados de equipo RMS. Otorga la confianza a equipos o dispositi- vos para el servicio de RMS. Contiene la clave pública del equipo activa- do. La clave privada correspondiente se encuentra en la caja de seguridad del equipo. Esta caja de seguridad es única para cada equipo y se recibe 139
  • 160. La protección de datos personales: Soluciones en entornos Microsoft cuando se instala y activa el cliente RMS. Se basa en un identificador hardware y contiene la clave privada del equipo activado.  Certificados de cuentas de permiso. Identifica a un usuario con un equipo o dispositivo específico. Contiene las claves pública y privada del usuario, esta última cifrada con la clave pública del equipo activado.  Licencias de publicación. Contienen los permisos específicos que se aplican a los datos protegidos mediante RMS. Contiene la clave de conte- nido simétrica necesaria para descifrar el contenido que está cifrado con la clave pública del servidor que ha emitido la licencia.  Licencias de uso. Especifica los permisos que se aplican a contenido protegido con RMS en el contexto de un usuario autenticado. Contiene la clave de contenido simétrica necesaria para descifrar el contenido, que se encuentra cifrada con la clave pública del usuario. Los certificados que se pueden emitir pueden ser en función del tiempo de validez de utilización para el certificado. Estos tipos de certificados son permanen- tes, donde de forma predeterminada el valor de validez es de 365 y los certificados temporales presentan una duración de 15 minutos, y están especificados para equipos de uso múltiple y evitar que se pueda tener acceso a la información de dicho equipo. En la operativa de funcionalidad del sistema, cuando un usuario intenta acceder por primera vez a un documento que presenta asignados derechos digita- les, el sistema se conecta al servidor de Licencias, donde se verifican las credenciales y se permite la descarga de una licencia para su uso. Ésta, como hemos comentado anteriormente, puede ser permanente o temporal. Mientras no dispongamos de esta licencia, no podremos acceder al documento. Una vez que la información se en- cuentra disponible, Microsoft Office envía las credenciales al servidor RMS, donde se comprobará si éstas son las necesarias para la apertura del documento. En el caso de que ya tuviéramos el certificado instalado en la máquina, sería necesario solamente comprobar si tenemos las credenciales correspondientes para acceder al documento, libro o presentación, así como qué derechos de los existentes tendremos sobre el mismo. Microsoft Office 2007 puede garantizar los derechos a diferentes tipos de documentos, así como a mensajes de correo electrónico mediante la tecnología IRM. Los documentos que admiten una posible implementación de la tecnología de IRM son los siguientes: Ficheros de Word Tipo de fichero Extensión Documento .doc Documento .docx 140
  • 161. La aplicación del reglamento de seguridad en los sistemas Microsoft Documento con macros habilitadas .docm Plantilla .dot Plantilla .dotx Plantilla con macros habilitadas .dotm Ficheros de Excel Tipo de fichero Extensión Libro .xls Libro .xlsx Libro con macros habilitadas .xlsm Plantilla .xlt Plantilla .xltx Plantilla con macros habilitadas .xltm Libro binario No-XML .xlsb Complemento .xla Complemento con macros habilitadas .xlam Ficheros de PowerPoint Tipo de fichero Extensión Presentación .ppt Presentación .pptx Presentación con macros habilitadas .pptm Plantilla .pot Plantilla .potx Plantilla con macros habilitadas .potm Presentación .pps Presentación .ppsx Presentación con macros habilitadas .ppsm Tema de Office .thmx Adicionalmente a la información antes citada, Ms Outlook 2007 también presenta una extensión para la tecnología IRM, con objeto de asignar derechos digitales sobre los correos gestionados a través de este cliente de correo, ofreciendo además soporte de IRM para los diferentes archivos anteriormente citados. 141
  • 162. La protección de datos personales: Soluciones en entornos Microsoft En caso de querer implantar esta tecnología, hay que tener presente que como mínimo es necesario que se encuentre instalado el cliente RMS Service Pack 1. Esta condición no es demandada en Windows Vista, puesto que dicha extensión ya se encuentra instalada por defecto. Para Word 2007, Excel 2007 y PowerPoint 2007, IRM permite que una cuenta asociada al servicio pueda asignar 3 tipos de permisos básicos a los documentos: lectura, cambio y control total. Una vez asignados estos derechos, sólo aquellos que tengan privilegios pueden acceder a dicho documento independientemente de donde pueda encontrarse o a donde haya podido llegar. Un usuario con permiso de lectura puede abrir el fichero, pero no modificarlo, copiar o imprimir el contenido. Un usuario con permisos de cambio puede leer, editar y guardar cambios en el fichero, pero no imprimirlo. Adicionalmente a estos tres permisos básicos, IRM permite la asignación de otros más especiales:  Establecer una fecha de caducidad para el documento.  Permitir imprimir el documento.  Permitir que usuarios con sólo lectura puedan copiar el contenido.  Permitir acceder al contenido del documento mediante programación. IRM: propiedades de permiso restringido. Cuando los permisos se establecen a mensajes de correo electrónico a través de Outlook 2007, se pueden controlar los destinatarios de estos, y que puedan ser copiados, reenviados o impresos. Además, una de las características que consiguen los mensajes de correo mediante el uso de IRM es el cifrado automático de los mismos, mediante los mecanismos de clave pública-privada de los destinatarios. El sistema permite, mediante un complemento para Internet Explorer, que documentos protegidos mediante la tecnología de IRM puedan ser visibles a través 142
  • 163. La aplicación del reglamento de seguridad en los sistemas Microsoft del navegador, siempre y cuando el receptor de los mismos tuviera permisos de lectura sobre los documentos. El uso de esta tecnología en un escenario de aplicación de normativas de LOPD, garantizará el control del acceso independientemente del lugar desde donde haya podido llegar la información, y garantizará no solamente el control de acceso, sino la confidencialidad de los datos mediante el cifrado de los mismos. IRM: permiso restringido. La tecnología IRM puede combinarse con el uso de una solución como Microsoft Office SharePoint Server 2007 (MOSS 2007), permitiendo esta arquitectura el mantenimiento de la infraestructura y uso de la gestión de Derechos Digitales. En este sentido, MOSS 2007 permite el establecimiento de IRM para listas o bibliotecas, incluyendo protectores para los siguientes tipos de archivos:  Formularios de Microsoft Office InfoPath.  Formatos de archivo 97 a 2003 para los siguientes programas de Microsoft Office: Word, Excel y PowerPoint.  Formatos XML abiertos de Office para Microsoft Office Word 2007, Microsoft Office Excel 2007 y Microsoft Office PowerPoint 2007.  Formato XPS (XML Paper Specification). Las siguientes URLs presentan guías donde se describen paso a paso los proce- dimientos y mecanismos para implementar una solución de RMS con Microsoft Office SharePoint Server 2007. La primera en un escenario con RMS Service Pack 2 y la segunda con el servicio de Windows Server 2008 de Directorio Activo RMS. http://www.microsoft.com/downloads/details.aspx?FamilyID=7bab2321-71e6-4cf2- 8bcd-0880e0d1cda3&DisplayLang=en 143
  • 164. La protección de datos personales: Soluciones en entornos Microsoft http://technet2.microsoft.com/windowsserver2008/en/library/07133490-20fe-4bb3- 9870-ced0cd01f5f61033.mspx?mfr=true Adicionalmente a los mecanismos que permiten realizar las implementaciones de derechos con IRM, Office 2007 proporciona otros mecanismos de seguridad para garantizar los accesos sobre los documentos. Entre estas características podemos citar como importantes la posibilidad de establecer procedimientos de cifrado para Office Access, Excel, Powerpoint y Word 2007, como trataremos con posterioridad, y la aplicación de listas de publicadores de confianza y firmas digitales, que permi- ten garantizar la integridad de la información disponible. Además de esta capacidad común, las diferentes aplicaciones de Office presen- tan funcionalidades específicas para la protección de documentos. En el caso de Word 2007, estas características para la protección de documentos se pueden activar desde el menú Revisar bajo el epígrafe de “proteger documento”. La activación y desactivación de estas configuraciones se establece bien por contraseña, bien por usuarios autentificados. Éstas son las diferentes restricciones que pueden aplicarse:  Restricción de formato. Limita los estilos que pueden aplicarse al docu- mento.  Restricción de edición. El sistema admite sólo determinados tipos de edición: para cambios realizados (permite que los usuarios efectúen cambios pero los resalta para que el autor los controle y determine si son aceptados o los rechaza), comentarios (permite que un revisor especifique comentarios para cambiar el contenido del documento), formularios (protege el documento ante cambios, excepto en aquellos formularios o secciones no protegidos) o sin cambios (modo de solo lectura). Estas restricciones pueden aplicarse a usuarios y grupos, pudiendo establecerse combinaciones. Excel 2007 presenta también funcionalidades para la protección de elementos. Los elementos que son posibles proteger son:  Proteger hoja. Protege celdas seleccionadas dentro de una hoja de cálculo, impidiendo la modificación de las celdas estén o no bloqueadas. Esta protección permite también otorgar acceso a operaciones específicas dentro de la hoja.  Permitir que los usuarios modifiquen rangos. Establece rangos que pueden ser desprotegidos mediante contraseña para que puedan ser modificados. Se permitirá además que usuarios, grupos y equipos puedan modificar una celda sin necesidad de establecer la contraseña.  Proteger libro. Especifica los elementos dentro del libro que deben ser protegidos: estructuras y ventanas. Adicionalmente se puede especificar una contraseña que debe ser utilizada para quitar esta protección.  Proteger y compartir libro. Esta función hace que el libro sea compartido y activa el control de cambios. Se pueden realizar modificaciones sobre el 144
  • 165. La aplicación del reglamento de seguridad en los sistemas Microsoft libro, pero se requiere el control de los mismos. Adicionalmente se puede especificar una contraseña que debe ser utilizada para quitar esta protec- ción. Access 2007 incluye un conjunto de funcionalidad para establecer protección sobre la base de datos y los objetos contenidos en ella.  Mostrar u ocultar objeto en la Base de datos. Permite ocultar objetos pero no va a impedir que un usuario pueda mostrar objetos que se encuentran ocultos.  Seguridad a nivel de usuario. Access 2007 permite el establecimiento de diferentes niveles de acceso a objetos sensibles. Para ello se establece una contraseña y un identificador para cada usuario. Cuando los usuarios abren la base de datos tendrán que introducir la contraseña, que junto con el identificador asigna las credenciales necesarias para acceder a determi- nados objetos únicamente.  Access 2007 admite el cifrado de la base de datos, haciendo ilegible su contenido. El cifrado se establece mediante contraseña y se puede invertir el procedimiento. Aunque el mecanismo es seguro, debería combinarse con la asignación de derechos, puesto que cualquiera que conociera la contraseña podría acceder a todos los objetos que tuviera.  También se admite el firmado digital en Access 2007. Cuando un usua- rio firma una base de datos se genera un hash para el proyecto VBA y las macros contenidas en la base de datos. El sistema permite garantizar mediante el uso de contraseñas la apertura o no de un documento, libro, presentación o base de datos, o bien si ésta es posible lle- varla a efecto en modo sólo lectura exclusivamente. Aunque esta protección es váli- da en muchos escenarios, nos encontramos que no podemos implementarla obser- vando la LOPD. En este sentido, el reglamento exige actualmente la existencia de cuentas diferenciadas para cada usuario que tenga acceso a la información de carác- ter personal, cuestión que no cumpliríamos mediante la aplicación de esta contrase- ña simplemente, por ser única para todo aquel que intentara abrir el documento. 11.2.5. Artículo 91. Control de acceso (punto 2) 2. El responsable del fichero se encargará de que exista una relación actualizada de usuarios y perfiles de usuarios, y los accesos autorizados para cada uno de ellos. Desde la ventana de seguridad, tanto en Windows Server 2008 como en Windows Vista, para cada uno de los objetos fruto del control de acceso, el sistema proporciona la capacidad para ver cuáles son los usuarios y grupos que tienen acceso y cuáles serán los derechos asignados. Debido a que el resultado final de los derechos resulta de la suma de permisos asignados al usuario más a aquellos grupos a los que perteneciera, en Windows 145
  • 166. La protección de datos personales: Soluciones en entornos Microsoft Server 2008 y Windows Vista se pueden examinar los permisos efectivos que quedan sobre el objeto para los usuarios o grupos que se especifiquen. Dentro de las utilidades externas a Microsoft, Dumpsec de SystemTools es una herramienta gratuita que nos va a permitir realizar volcados de las ACL de objetos administrables, con lo que nos permite además facilitar la información de cara a la realización de informes o un dossier de seguridad. 11.2.6. Artículo 91. Control de acceso (puntos 4 y 5) 4. Exclusivamente el personal autorizado para ello en el documento de seguridad podrá conceder, alterar o anular el acceso autorizado sobre los recursos, conforme a los criterios establecidos por el responsable del fichero. 5. En caso de que exista personal ajeno al responsable del fichero que tenga acceso a los recursos, deberá estar sometido a las mismas condiciones y obligaciones de seguridad que el personal propio. Como ya definimos en su momento, la asignación de los permisos se establece a través de las DACL, y será una capacidad inherente al creador del fichero o aquel para el que se establezca, tanto el control como la asignación de dichos permisos. Esta labor de asignación de permisos se realiza desde la pestaña de seguridad con las capacidades para cambiar los permisos y tomar la posesión si correspondiera. 11.2.7. Artículo 92. Gestión de soportes y documentos 1. Los soportes y documentos que contengan datos de carácter personal deberán permitir identificar el tipo de información que contienen, ser inventariados y sólo deberán ser accesibles por el personal autorizado para ello en el documento de seguridad. Se exceptúan estas obligaciones cuando las características físicas del soporte imposibiliten su cumplimiento, quedando constancia motivada de ello en el docu- mento de seguridad. 2. La salida de soportes y documentos que contengan datos de carácter personal, incluidos los comprendidos y/o anejos a un correo electrónico, fuera de los locales bajo el control del responsable del fichero o tratamiento deberá ser autorizada por el responsable del fichero o encontrarse debidamente autorizada en el documento de seguridad. 3. En el traslado de la documentación se adoptarán las medidas dirigidas a evitar la sustracción, pérdida o acceso indebido a la información durante su transporte. 4. Siempre que vaya a desecharse cualquier documento o soporte que contenga datos de carácter personal deberá procederse a su destrucción o borrado, mediante la adopción de medidas dirigidas a evitar el acceso a la información contenida en el mismo o su recuperación posterior. Para el control de la información y teniendo en cuenta la posibilidad existente de que los datos puedan salir fuera de la organización, hay que tener previstos una serie de mecanismos que permitan: 146
  • 167. La aplicación del reglamento de seguridad en los sistemas Microsoft  Establecer los procedimientos de comunicación y autorización de datos fuera del control del responsable del fichero.  Garantizar que en el transporte no se pueda producir un acceso o manipu- lación de la información contenida en los soportes. Al igual que ya hemos comentado anteriormente, MOSS 2007 puede estable- cerse como mecanismo para garantizar los procesos de comunicación de estos procedimientos, así como para el almacenamiento de la información correspondien- te a la salida de los soportes. En el otro sentido, cuando determinamos la seguridad que establece el uso de mecanismos de autentificación y acceso controlado a recursos, estamos establecien- do procedimientos para asegurar esta información mediante los métodos conven- cionales que permiten llegar a los datos compartidos. Pero si alguien tuviera acceso físico, bien al depósito de datos o incluso a las copias de seguridad o las máquinas físicas que guardarán la información, podrían llegar a acceder a dicha información no utilizando los métodos convencionales, por lo cual la información se encontraría comprometida. Cómo evitar estos mecanismos de acceso físicos en muchas ocasiones puede ser complejo o inviable; se puede realizar un proceso de cifrado para los datos que garanticen que éstos, independientemente de quien haya podido obtenerlos, van a encontrarse salvaguardados por los mecanismos de encriptación. En los diferentes puntos que hemos ido viendo, nos hemos encontrado ya algunas de estas funcionalidades de cifrado, como el caso de la tecnología IRM, que perfectamente podrían servir para cubrir las necesidades para cumplir este artículo. Aunque de forma más generalizada para todo tipo de archivos, tanto Windows Vista como Windows Server 2008 nos ofrecen dos procedimientos que garantizan la confidencialidad de los ficheros:  El Sistema de ficheros cifrados (EFS o Encripted File System).  Bitlocker. EFS es un mecanismo que proporciona un sistema de cifrado totalmente transparente para el usuario y no ofrece integridad en los datos o autentificación, por lo que no deberán obviarse otros mecanismos de seguridad. EFS utiliza el sistema de certificados estándar X509 para las credenciales de acceso. Cada fichero que se protege es encriptado con una clave de encriptación de fichero (FEK) genera- da aleatoriamente mediante algoritmo AES. EFS posteriormente utilizará mecanis- mos de clave pública para cifrar la FEK. Cada usuario que accede a un fichero protegido mediante EFS debería tener una clave privada que corresponda a una de las claves públicas con las que se cifra la FEK, y así poder acceder a él. EFS presenta 4 operaciones: abrir, leer, escribir y convertir ficheros, que utilizan como cualquier otra aplicación las APIs Win32.  Abrir. La aplicación que intenta acceder a los ficheros comprimidos utiliza la API CreateFile() u Openfile(). Cuando el fichero es abierto, EFS estable- 147
  • 168. La protección de datos personales: Soluciones en entornos Microsoft ce los mecanismos para proporcionar la clave de encriptación y crea los diferentes elementos para la desencriptación y encriptación de los datos. EFS: esquema de cifrado.  Lectura. Las aplicaciones utilizan las APIs ReadFile(), ReadFileEx() y RealFileScatter() para leer los ficheros encriptados. Cuando se lee un fichero cifrado, los datos son cargados en memoria y EFS los desencripta. Los datos descifrados son devueltos a la aplicación. Cuando la aplicación requiere que un fichero encriptado sea mapeado en memoria, los datos son desencriptados antes de ser mapeados en memoria.  Escritura. Las aplicaciones utilizan las APIs WriteFile(), WriteFileEx() y WriteFileScatter(). Cuando se escribe sobre un fichero cifrado, EFS encripta los datos donde se encuentren y posteriormente se escriben en el disco. Cuando una aplicación requiere que un fichero deje de estar mapeado en memoria, los datos mapeados son encriptados antes de ser escritos en el disco.  Convertir. Cuando se realiza el proceso de conversión de un fichero, se realizan una serie de procedimientos que comienzan con un chequeo de los datos y la comprobación de si existe espacio de disco suficiente. EFS genera posteriormente la clave de encriptación y realiza el cifrado con la clave pública del usuario activo. Una vez creada la FEK, EFS genera los metadatos que contienen el campo de desencriptación de datos (DDF), el cual mantendrá las claves públicas de los usuarios que puedan acceder al fichero. EFS genera un fichero temporal donde copia los datos del fichero de origen para propósitos de recuperación. Cada dato en el fichero origi- nal es truncado a longitud cero, devolviendo la longitud original y elimi- nando los datos. EFS escribe los metadatos en el fichero original que se encuentra vacío y marcado como encriptado y los datos en el fichero temporal. Para finalizar, EFS lee los datos del fichero temporal y los 148
  • 169. La aplicación del reglamento de seguridad en los sistemas Microsoft escribe en el original de forma encriptada, realiza las comprobaciones para la coherencia de datos y elimina el fichero temporal. Si por algún motivo dado la encriptación no fuera satisfactoria, EFS devolvería el fichero al estado original. En caso de necesitar establecer una recuperación para los ficheros cifrados, debido a que el usuario propietario o la clave de desencriptación se han eliminado, existen mecanismos para la recuperación de dichos datos. Ésta dependerá de si el equipo se encuentra o no integrado en el dominio. EFS: agente recuperador de datos cifrados. Si la máquina está integrada en el dominio, se establece una política de recupe- ración que es automáticamente habilitada para todas las máquinas en el dominio, siendo distribuida a través de las políticas de grupo. Cuando se genera una política de recuperación, todas las FEKs son cifradas con las claves públicas de los agentes de recuperación de claves. EFS reescribe el campo de recuperación de datos (DRF) cada vez, para asegurarse que se utiliza la política de recuperación más actualizada. Cuando el administrador del dominio se valida por primera vez, en el contro- lador de dominio se genera un certificado de recuperación de EFS y se almacena en el perfil local, siendo además añadido a la política de recuperación. Además, cual- quier administrador de dominio puede crear agentes de recuperación de datos en el dominio y generar certificados de EFS para estos agentes de recuperación pudiendo ser añadidos a las políticas de recuperación. En el caso de utilizar una máquina que no es miembro del dominio, el sistema no crea ningún agente recuperador de datos cifrados inicialmente y requiere que sea el administrador el que modifique la política y realice los procedimientos necesarios. Cuando estemos utilizando los mecanismos de cifrado de EFS tendremos que tener en cuenta que si una aplicación genera un temporal en base a un fichero cifrado mediante EFS, éste no se encontrará necesariamente encriptado, si no que dependerá de si hemos establecido el cifrado sobre la carpeta donde se creara. Para asegurarnos de que los ficheros temporales de ficheros cifrados mediante EFS tienen 149
  • 170. La protección de datos personales: Soluciones en entornos Microsoft la misma seguridad, deberíamos habilitar EFS sobre la carpeta y no solamente sobre los ficheros. Con objeto de preservar los mecanismos de seguridad en las copias de seguri- dad, cuando se realice una copia de seguridad de ficheros cifrados mediante meca- nismos de EFS, con herramientas certificadas por Microsoft, se garantiza que estos ficheros de respaldo mantienen su condición de cifrado mediante EFS. Esto también sucederá con los sistemas de medios extraíbles que utilicen NTFS y que son gestio- nados por el sistema operativo. Como estos medios no migran ni las claves de cifrado ni la de los agentes de recuperación de datos cifrados, la garantía de seguri- dad es muy alta. EFS: propiedades de un fichero cifrado. EFS: copia de seguridad de clave de cifrado. El otro mecanismo de implementación de sistemas de cifrado, viene proporcio- nado por el uso de la tecnología Bitlocker. Este nuevo sistema, disponible únicamen- te en los Sistemas Operativos Windows Vista (en sus versiones Enterprise y Ultimate) y Windows Server 2008, implementa mecanismos para el cifrado de 150
  • 171. La aplicación del reglamento de seguridad en los sistemas Microsoft disco, a diferencia de EFS que basaba su funcionalidad en el cifrado de ficheros. Bitlocker utiliza AES (Advance Encription Standard) como algoritmo de cifrado en modo CBC (Cypher Block Chaining) y con objeto de evitar los ataques por manipu- lación de datos cifrados incorpora un difusor adicional independiente de AES-CBC. Los mecanismos de seguridad implementados por Bitlocker se complementan mediante unas nuevas especificaciones de seguridad hardware: Trusted Platform Module (TPM). Este nuevo chip TPM proporciona una plataforma segura para el almacenamiento de claves, contraseñas o certificados, dificultando el ataque contra las mismas. Aunque nuestros equipos no dispusieran de este mecanismo de seguri- dad, las especificaciones de Bitlocker admiten su funcionalidad sin el chip TPM. Bitlocker: configuración de cifrado. Bitlocker proporciona un filtro en el stack del sistema de Windows Vista encar- gado de realizar los procesos de cifrado y descifrado de una forma totalmente trans- parente, cuando se escribe o se lee en un volumen protegido. Este mismo mecanis- mo interviene también cuando el equipo entra en el modo de hibernación. De este modo se garantiza también la seguridad del fichero de paginación, los ficheros temporales y el resto de elementos que puedan contener información sensible. Una vez que el mecanismo de cifrado ha sido puesto en marcha, la clave de cifrado es eliminada del disco y posteriormente almacenada en el Chip TPM. Con objeto de evitar un posible ataque al sistema hardware por posibles vulnerabilidades, se pro- porcionan mecanismos de autentificación mediante sistemas adicionales tales como el uso de Token (llave USB) o una password (PIN) para evitar esta posibilidad. El uso combinado de mecanismos hardware y software evita determinados ataques que tienen como objetivo la modificación de datos que, aunque cifrados, podrían provocar una vulnerabilidad en el sistema, siendo explotada posteriormen- te para disponer de acceso al sistema. La implementación de Bitlocker requiere de la existencia de condiciones para ello. Un factor importante es que el sistema necesita dos particiones NTFS, una de las cuales, la partición activa, que albergará el sistema de arranque, no se encontrará cifrada. Bitlocker también proporciona mecanismos para garantizar que no se han producido modificaciones en el arranque del sistema, tales como aquellas que pueden proceder de ataques tipo malware, que pudieran producir una agresión colateral o el control del acceso al sistema. 151
  • 172. La protección de datos personales: Soluciones en entornos Microsoft A la hora de establecer un sistema de implementación para el cifrado de la unidad de disco para Bitlocker, Microsoft tuvo en cuenta determinados factores y evaluó la posibilidad de incorporar algunos sistemas de implementación de cifrado. Uno de los elementos que se tuvieron en cuenta es que Bitlocker no debería consistir solamente en un elemento de cifrado, sino que debería garantizar, gracias a la autenticación de datos, el evitar que mediante una manipulación de los datos cifrados pudiera introducirse una modificación a ciegas en el código del sistema operativo, provocando una debilidad en el mecanismo de arranque con Bitlocker o conseguirse una escalada de privilegios en el sistema. Además, debería evitar la predicción de la función de cifrado mediante la manipulación de datos cifrados y la obtención de datos en texto plano. El mecanismo natural de implementación de cifrado para evitar estos mecanis- mos de ataque es la utilización de MAC (Message Autenthication Code) para cada bloque de datos del disco. El problema que plantea el uso de este mecanismo es que necesitaríamos establecer una reserva de sectores para almacenar el MAC, con lo cual tendríamos un uso limitado en la capacidad de almacenamiento de hasta un 50 %. Además, bajo las condiciones actuales de implementación de este mecanismo en sistemas de alto procesamiento de datos con accesos de lectura y escritura, podre- mos encontrarnos con problemas de rendimiento o corrupción de sectores. Si no queremos escribir en sectores x, sin dañar x+1 x-1 en procesos de caída del sistema no controlados o por pérdida de energía, tendremos que tener en cuenta que en el caso de escribir en un sector x el sistema deberá leer el sector, desencriptarlo, encriptarlo y nuevamente escribir todos los sectores que correspondan al bloque. Si falla el sistema cuando se escriben sectores en el bloque nuevo pero quedan pen- dientes otros, todo el bloque puede quedar corrompido. Poor-man consiste en otro de los posibles mecanismos para la implementación de seguridad que permite generar bloques cifrados con un tamaño que oscila entre los 512 bytes y los 8192 bytes, de tal forma que una leve modificación en uno de los caracteres del bloque modifica de forma aleatoria todo el bloque. Con objeto de evitar el mecanismo de secuenciación moviendo datos cifrados de un sector a otro, se generan cambios del algoritmo para cada sector. De esta forma, aunque el potencial atacante tuviera acceso a los datos tanto cifrados como en texto plano, la variedad del mecanismo de secuenciación y los cambios en el algoritmo evitan posibilidades de predicción del sistema de cifrado. Por mecanismos de rendimiento el mejor sistema que se puede emplear para el cifrado de datos de disco es AES-CBC, pero ya advertimos anteriormente el riesgo de posibles ataques al utilizar únicamente este mecanismo. La decisión finalmente establecía la utilización de AES-CBC para la encriptación primaria y una clave difusora independiente para texto plano. Este difusor tiene como objetivo fortificar frente a los ataques de manipulación, mejor que lo que puede realizar de forma única el algoritmo de AES-CBC. Inicialmente, la implementación de Bitlocker en Windows Vista sólo admitía el cifrado de la partición donde estaba instalado el Sistema Operativo, aunque desde 152
  • 173. La aplicación del reglamento de seguridad en los sistemas Microsoft la salida de Windows Vista SP1, el sistema admite además el cifrado de otras particiones de datos, siempre y cuando no sea la de arranque. 11.2.8. Artículo 93. Identificación y autenticación (puntos 1 y 2) 1. El responsable del fichero o tratamiento deberá adoptar las medidas que garanti- cen la correcta identificación y autenticación de los usuarios. 2. El responsable del fichero o tratamiento establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado. 11.2.8.1. Autentificación Windows Vista y Windows Server 2008 Cuando definimos la capacidad para acceder a un objeto, lo realizamos claro está en función de los usuarios especificados para ello. Con objeto de evitar la confusión de usuarios, los sistemas presentan diferentes mecanismos con objeto de identificar quienes son. Tanto Windows Server 2008 como Windows Vista, utilizan para los procedimientos cuentas de usuario con diferentes procedimientos para la autentificación, sin que existan para ello procedimientos anónimos. Por tanto, independientemente de si los usuarios acceden a un recurso a través de la red o lo hacen localmente, ejecutan un proceso en una máquina o mediante un servicio de Terminal; cada una de estas acciones estará controlada y auditada para el usuario que la realizó. Una de las modificaciones más importante que ha tenido el Reglamento de Seguridad viene definida precisamente en este artículo. Por un lado, la necesidad de identificar de forma inequívoca y personalizada aquellos usuarios que accedan al sistema, y por otro la obligatoriedad del cambio de contraseña que como mínimo será anual. En este sentido, el reglamento limita el uso de cuentas genéricas (cues- tión que en el anterior reglamento sólo era requerido para los Datos de Nivel Me- dio), impidiendo su uso y requiriendo que cada usuario tenga su cuenta y la utilice con los fines para las que fue generada verificando por lo tanto su autorización. De cara a coordinar este proceso de identificación de los usuarios, Windows presenta una serie de mecanismos para poder autentificar los usuarios que intentan iniciar un proceso de validación de cuenta. En este sentido, este procedimiento podrá variar si el procedimiento es local o bien se realiza en un dominio. Cuando el procedimiento de autentificación se realiza localmente, existe un archivo local donde se depositan los datos para cotejar los datos de autentificación: SAM (Security Account Manager). Cuando la validación se realiza en un dominio, éste se establece contra los Controladores de Dominio. Aunque en ambos sistemas se ofrecen mecanismos para el control de usuarios, la administración en un sistema de red basado solo en cuentas locales, sería mucho más complicado de administrar que utilizando los mecanismos proporcionados en el Directorio Activo. Como en toda base de datos, y no debemos perder el punto de vista que tanto la SAM como el Directorio Activo lo son, existen una serie de identificadores con 153
  • 174. La protección de datos personales: Soluciones en entornos Microsoft objeto de evitar incongruencias en los datos que se manejan. De cara a estas cuentas de usuario ambos sistemas presentan un único identificador de seguridad (SID) para cada cuenta de usuario, aunque hay que tener presente que el Directorio Activo presenta una flexibilidad de la que carece la base de datos local de un equi- po. Este SID, que identifica inequívocamente a un usuario, presenta una serie de atributos que se asociarán al mismo, tales como nombres, contraseñas, descripcio- nes, etc. La definición de los atributos para los objetos usuarios definen muchas más propiedades para el Directorio Activo que para la SAM, por lo que se permite asociar un mayor número de datos a una cuenta. Otra de las ventajas que ofrecen los mecanismos del Directorio Activo es poder capacitar o delegar a otros usuarios acceder a determinadas o todas las propiedades de otra cuenta; por ejemplo, cono- cer las extensiones del teléfono del trabajo u otro dato que pudiera ser necesario. Los sistemas Windows Server 2008 y Windows Vista utilizan dentro de los procedimientos de autentificación un sistema basado en el modelo de autentifica- ción local: LSA (Local Security Authority). La LSA es la encargada de recoger las credenciales facilitadas para el inicio de sesión. Para ello, soporta unos paquetes de autentificación personalizables, que son los encargados de inicializar las subrutinas de autentificación. Estos paquetes admiten la extensión en los mecanismos de autentificación, por ejemplo para utilizar una tarjeta tipo ATM y un número de identificación personal (PIN), como mecanismos para presentar las credenciales necesarias con las que iniciar una sesión sustituyendo al clásico sistema de valida- ción basado en usuario y contraseña. Además, estos paquetes de autentificación son los encargados a través de la LSA de inicializar unos mecanismos que tendrán como resultado cotejar la información facilitada con las bases de datos que le pudieran corresponder. Estos mecanismos pueden ser tan variados como utilizar ticket de sesión Kerberos o utilizar certificados de sesión de cliente. Una vez que se ha realizado satisfactoriamente este proceso de autentificación, el correspondiente paquete de autentificación crea un inicio de sesión y devuelve la información a la LSA que la utilizará para crear un testigo para el nuevo usuario. Este testigo, entre otras características, incluye un identificador único local (LUID) que se llama formalmente LogonID. La sesión de validación (Logon Session) comienza cuando la autentificación se ha realizado satisfactoriamente y finalizará cuando el usuario cierra la sesión. En el caso de que la autentificación no haya sido satisfactoria, el paquete de autentifica- ción no creará la sesión de validación. Como hemos dicho anteriormente, la LSA nos facilita los mecanismos para el proceso de validación. Estos procedimientos quedan divididos según el tipo de autentificación que se intente:  Autentificación interactiva.  Autentificación no interactiva. La autentificación interactiva se produce cuando a un usuario se le solicita que proporcione las credenciales para la autentificación. En este procedimiento para los 154
  • 175. La aplicación del reglamento de seguridad en los sistemas Microsoft sistemas anteriores a Windows Vista, intervenían dos componentes esenciales: Winlogon y GINA (Graphical Identification aNd Authentication). Los sistemas actuales han cambiado GINA por un nuevo proveedor de servicios de credenciales de seguridad (CredSSP) disponible a través del SSPI (Security Support Provider Interface). En el nuevo modelo de autentificación, los módulos LogonUI y Winlogon hablan entre ellos directamente. Si en el sistema tenemos un Módulo de Proveedor de Credenciales (como un servicio de autentificación basado en SmartCard) externo, la información de autentificación es requerida por LogonUI para comunicarse con el Proveedor de autentificación externa. Después de que el proveedor de autentifica- ción devuelve las credenciales de validación al módulo de LogonUI, éstas son enviadas a Winlogon. En este sentido, el proveedor de credenciales es totalmente transparente para Winlogon. En Windows Vista, al contrario que en versiones anteriores, no es necesario cambiar la pantalla de autentificación y se admite que puedan implementarse múltiples proveedores de servicio de autentificación, pudiendo ser seleccionados por el usuario. Por defecto, Windows proporciona proveedores de autentificación para acceso mediante usuario/password y la autenticación mediante Smartcard. Adicionalmente, mediante el Proveedor de seguridad, el sistema permite reutilizar las credenciales mediante el módulo CredUI. Sistema de autentificación en Windows Vista. La autentificación no interactiva se produce cuando ya previamente se ha producido una sesión interactiva, con lo cual no se solicitan nuevamente credencia- les, sino que se utilizan aquellas previamente proporcionadas. Este tipo de autentifi- cación es la típica cuando se produce un acceso a un recurso de red. Cuando una aplicación intenta acceder a un recurso de red, entonces en el proceso de autentificación no intervienen ni los procesos del nuevo proveedor CredSSP ni del módulo de Winlogon, sino que el proceso que interviene es la SSPI (Security Support Provider Interface) y el paquete de seguridad encargado de establecer la conexión segura a la red. La SSPI es una interfaz que se posiciona entre 155
  • 176. La protección de datos personales: Soluciones en entornos Microsoft la capa de transporte y de aplicación que permite hacer las llamadas a los proveedo- res de seguridad. Un ejemplo lo tenemos con la SSPI que interviene en los procesos de envíos de datos entre Microsoft Remote Procedure Call (RPC), y el proveedor de seguridad Windows Distributed Security. El procedimiento de trabajo sería el siguiente: una aplicación de un cliente inicia la llamada a la SSPI que requiere la autentificación a través de la conexión de red. La petición del cliente es procesada por un paquete de seguridad. Éste autenti- fica al usuario mediante una llamada a la LSA y el paquete de autentificación específico proporcionando las credenciales de Usuario existente. El resultado de la autentificación se pasa a través de la LSA al paquete de seguridad y finalmente a la SSPI. Ésta finalmente notifica a la aplicación cliente el resultado de la petición. Una vez que hemos visto los dos tipos de procedimientos para la autentifica- ción, solicitando o no credenciales, y los mecanismos que la implementan, el otro factor importante es dónde se produce la confrontación de la autentificación y los mecanismos utilizados para asegurar el paso de los datos de autentificación. Los mecanismos en este caso dependerán de si accedemos mediante cuentas locales o, por el contrario, utilizamos los mecanismos de dominio. Cuando se produce una validación contra la base de datos de seguridad local, la cuenta que se valida debe estar en la SAM de la máquina en la que se intenta autentificar. La SAM local se encuentra protegida en el registro de la máquina y como paquete de autentificación es utilizado MSV1_0. La LSA llama al MSV1_0 para recoger los datos proporcionados a través de GINA para el proceso de Winlogon. MSV1_0 realiza la comprobación en la base de datos SAM. Si los datos proporcionados son satisfactorios, se genera un Principal de Seguridad válido y se devuelve el resultado de validación a la LSA. Cuando se produce el paso de la contraseña para la verificación, ésta no se realiza directamente, sino mediante una clave secreta generada mediante una función Hash. Se trata de una fórmula mate- mática mediante la cual, a través de una cadena de caracteres, se obtiene un resulta- do único. La modificación de un carácter implica la generación de una nueva cadena, con lo cual no puede calcularse la cadena de caracteres que lo genera. Cuando la SAM recibe una petición de autentificación de un usuario, genera una función Hash sobre la contraseña que tiene almacenada, comparando el resultado con el hash recibido de la autentificación. El resultado es devuelto a la LSA que devuelve el resultado del procedimiento de verificación de la contraseña. Cuando la autentificación se realiza en un dominio Windows 2008, la metodo- logía cambia con respecto a lo expuesto anteriormente. En este caso se utiliza como SSP Kerberos V.5, aunque soporta la autentificación NTLM para clientes anteriores a Windows 2000. Para utilizar Kerberos V5 como protocolo de autentificación, Windows 2008 presenta una librería que es la encargada de elegir la autentificación: Kerberos.dll. Después de que la LSA establece un contexto de seguridad para la autentificación interactiva del usuario, se carga otra instancia de Kerberos para procesar en el contexto de seguridad del usuario, la firma y el envío de los mensa- jes. Kerberos es utilizado como metodología para la autentificación mutua entre el cliente y el servidor. Para todo el procedimiento de autentificación en Kerberos 156
  • 177. La aplicación del reglamento de seguridad en los sistemas Microsoft intervienen los siguientes elementos: claves simétricas, objetos encriptados y servicios Kerberos. En el caso de Kerberos, los mecanismos de autentificación están basados en tickets necesarios para tener acceso a los servicios de red. Estos Tickets mantienen las claves de sesión para establecer comunicaciones cifradas cliente-servidor que garantizan la seguridad en los procesos de autentificación. La ventaja es que los servidores no tienen que almacenar la clave de sesión, sino que es el cliente el responsable de guardar el ticket en su caché y lo presentará cuando desee acceder al servidor. Cuando el servidor recibe el ticket utiliza la clave secreta para desencriptar el ticket y extraer la clave de sesión necesaria. El servicio encargado de mantener los mecanismos de funcionalidad de Kerberos son los Centros de Distribución de Claves (KDC). Este servicio se ejecuta en cada controlador de dominio de un Directorio Activo. El mecanismo de autenti- ficación Kerberos tiene los siguientes mecanismos de funcionalidad: 1. El usuario realiza un proceso de autentificación en el KDC mediante una contraseña o una tarjeta inteligente, a través de una trama de solicitud de autentificación que contiene los datos de pre-autenticación (PADATA). Este sistema de PADATA generada a partir de un algoritmo de cifrado, contiene una clave derivada de la contraseña, además de un sello de tiempo que evita determinados ataques de predicción de la contraseña. 2. El KDC se encarga de emitir un Ticket especial para la concesión de Ticket (TGT). Este ticket que sólo puede ser leído por un KDC, presenta el objetivo de tener acceso a las credenciales de un usuario, las claves de sesión y otros servicios. Se utiliza para el servicio de autentificación y para la petición de tickets de servicios; para ello, contiene una copia de la clave de sesión para el servicio de comunicación del KDC con el cliente. 3. Mediante el TGT, el cliente tendrá acceso al Servicio de Concesión de Ticket (TGS). Éste concede un Ticket de Servicio que va a permitir enviar las credenciales de usuario al servidor o servicio correspondiente de forma segura. 4. Los tickets solicitados también van a facultar el poder acceder a los servi- cios locales de la máquina en la cual se está o ha validado un usuario. 5. El servicio de Seguridad Genérico (GSS) establecerá posteriormente, a través de la Interfaz de programación de aplicación GSS (GSS-API) y el Proveedor de Soporte de negociación (GSS_SPNEGO), los mecanismos para la negociación segura que establecen el envío de mensajes entre cliente y servidor utilizando las claves derivadas del intercambio de Tickets Previos. Cuando se está realizando una validación en el dominio, la LSA será la encar- gada de recoger este Ticket y validarlo, creando un Token de seguridad asociándolo con el SID del usuario. 157
  • 178. La protección de datos personales: Soluciones en entornos Microsoft Una de las mejoras introducidas en Windows Vista y Windows Server 2008 respecto al sistema de Autentificación Kerberos, es la implementación mejorada de los sistemas de cifrado, mediante el uso de AES (Advanced Encription Standard).  Soporte base de implementación Kerberos. AES es utilizado para la encriptación de TGTs, Tickets de Servicios y Claves de sesión.  Soporte AES para GSS (Generic Security Services). Además del uso base, los mensajes GSS para la comunicación entre cliente Windows Vista y servidor son protegidos mediante AES. Puesto que los sistemas previos no implementaban tal mecanismo, sino RC4 o DES, el siguiente cuadro establece qué mecanismos de encriptación se definen en función del Cliente, Servidor y Centro de Distribución de Tickets Kerberos existente. Cliente Servidor KDC Encriptación Sistema Operativo Sistema Operativo Windows Server 2008 TGT puede encriptar previo a Windows previo a Windows con una política Vista Server 2008 basada en AES Sistema Operativo Windows Server 2008 Windows Server 2008 Ticket de Servicio previo a Windows cifrado con AES Vista Windows Vista Windows Server 2008 Windows Server 2008 Todos los tickets y GSS cifrados con AES Windows Vista Windows Server 2008 Sistema Operativo GSS cifrado con AES previo a Windows Server 2008 Windows Vista Sistema Operativo Windows Server 2008 AS-REQ/REP y TGS- previo a Windows REQ/REP cifrado con Server 2008 AES Sistema Operativo Windows Server 2008 Sistema Operativo Sin soporte AES previo a Windows previo a Windows Vista Server 2008 Windows Vista Sistema Operativo Sistema Operativo Sin soporte AES previo a Windows previo a Windows Server 2008 Server 2008 Sistema Operativo Sistema Operativo Sistema Operativo Sin soporte AES previo a Windows previo a Windows previo a Windows Vista Server 2008 Server 2008 158
  • 179. La aplicación del reglamento de seguridad en los sistemas Microsoft Otra de las mejoras de implementación en Windows Server 2008 con respecto al sistema de autentificación Kerberos, corresponde al mecanismo implementado con los Controladores de Dominio de Sólo Lectura (RODC) de Windows Server 2008. Puesto que se considera que en este escenario el procedimiento puede entra- ñar riesgo por la exposición posible, los RODC tienen una única cuenta KRBTGT que no tiene todas las capacidades de las cuentas estándar de un Controlador de Dominio. Lo que en caso de compromiso de dicha cuenta, estaría limitada a ser utilizada en este servidor RODC exclusivamente. En el caso de que las metodologías anteriormente expuestas para establecer los mecanismos de autentificación en el dominio no fueran posibles, alternativamente existe la posibilidad de utilizar las credenciales cacheadas localmente para iniciar una sesión local en la máquina con cuentas de usuario del dominio. Este mecanismo es utilizado en clientes itinerantes para facultarles el acceso localmente con creden- ciales de dominio. Como opción a través de las directivas de seguridad puede limitarse el uso de este mecanismo impidiendo que se guarden las credenciales localmente o limitarlas a un número determinado. Para realizar estas operaciones dentro de las opciones de seguridad podremos modificar el inicio de sesión interactivo y el número de inicios de sesión previos en la caché (en caso de que los controladores de dominio no estén disponibles). El valor predeterminado es de 10 inicios de sesión. 11.2.8.2. Autentificación en Microsoft Office 2007 Poco a poco, los sistemas ofimáticos han ido adquiriendo un valor muy impor- tante en las empresas y por correspondencia en la aplicación de mecanismos de seguridad para asegurar la protección documental. Microsoft Office 2007 presenta la tecnología IRM (Information Right Management), como una medida para contro- lar los usuarios que pueden o no acceder a los documentos así como la forma en la cual pueden utilizarla. Además, como ya se incluía desde Microsoft Office XP, el sistema presenta la posibilidad de firmar digitalmente la tecnología Microsoft Authenticode para permitirle firmar digitalmente un archivo mediante el uso de certificados. Este certificado utilizado para crear esta firma garantiza que la macro o el documento se han originado por el firmante y la firma establece que no se ha modificado. Al esta- blecer el nivel de seguridad de las macros, se pueden ejecutar macros en función de que estén firmadas digitalmente por un programador de la lista de confianza. El sistema funciona generando una huella digital (hash) única que representa un bloque de datos. Este hash se cifra con la clave privada de quien lo firma, de tal forma que todo aquel que posea la clave pública del que establece la firma pueda descifrarlo. Esta huella se genera mediante un algoritmo de cifrado en base a los datos que se desean firmar. La ventaja que ofrece es que es imposible modificar los datos sin cambiar el valor de hash. Además, el sistema genera una suma de compro- bación de los datos (CRC) con objeto de comprobar si los datos han sido modifica- dos, que al ser firmados digitalmente se refuerza el mecanismo de seguridad. 159
  • 180. La protección de datos personales: Soluciones en entornos Microsoft Cuando se quiere establecer el control de la firma, el destinatario comprueba el certificado del remitente para comprobar el período de caducidad y la validez de las firmas. Se realiza la comprobación mediante la clave pública del remitente del CRC obtenido del certificado del cliente. Si la comprobación es válida, se puede aseverar que los datos no han sido modificados desde el origen. Este mecanismo de seguridad permite establecer seguridad sobre archivos, documentos, presentacio- nes, plantillas y otros archivos de datos. Si el archivo entero es firmado, la firma garantiza que el archivo no sea modificado desde su aplicación. Además, el sistema admite la firma de código. Este término se refiere al uso de firmas en código ejecutable (incluyendo controladores de Microsoft ActiveX y macros). La firma de código se utiliza cuando se firman controladores para verificar que el código no haya sido cambiado desde el momento original de su creación. Los mecanismos de funcionalidad son similares a los utilizados para las firmas digitales. En el caso de que se desee firmar las macros y los archivos, estos procedi- mientos pueden realizarse por separado. 11.2.8.3. Autentificación en Exchange 2007 El correo electrónico constituye un modelo de intercambio de información, entre la que habitualmente pueden figurar datos de carácter personal. El problema lo encontramos en el hecho no sólo de que pueda ser utilizado como mecanismo de intercambio, sino también como sistema de almacenamiento, con lo cual tiene que cumplir unas pautas de seguridad al igual que tenemos en el resto de elementos que conforman los sistemas informáticos involucrados por la LOPD. Existen mejoras importantes de seguridad en los procesos de comunicación entre los diferentes roles de servidor disponibles en Exchange Server 2007. En una organización Exchange Server 2007 se pueden implantar los siguientes roles de servidor:  Servidor concentrador de transporte.  Servidor de acceso de clientes.  Servidor de mensajería unificada.  Servidor de buzones.  Servidor de transporte perimetral. La comunicación entre todos estos roles de servidor se realiza de forma autenticada y cifrada por defecto, incluso en un sistema recién instalado. Esto quiere decir que el administrador o responsable de seguridad puede garantizar desde el primer momento que las comunicaciones entre servidores están completa- mente securizadas. Para garantizar esta seguridad, Microsoft Exchange Server 2007 se apoya en Kerberos como protocolo de autenticación para aquellos equipos que son miembros 160
  • 181. La aplicación del reglamento de seguridad en los sistemas Microsoft del dominio de Directorio Activo. De hecho, ninguno de estos roles acepta conexio- nes que no vayan previamente autenticadas, con la excepción del servidor de transporte perimetral. El servidor de transporte perimetral se encarga del envío y recepción de mensajes desde y hacia Internet; por tanto, debe estar configurado para aceptar conexiones anónimas de sesiones SMTP. Para incrementar el nivel de seguridad, este servidor no forma parte del dominio ni tiene comunicación con el Directorio Activo. Al no formar parte del dominio, no puede utilizar el protocolo Kerberos como protocolo de autenticación. Entonces, ¿cómo es capaz de autenticarse cuando va a iniciar una conexión contra un servidor concentrador de transporte? Arquitectura de comunica- ción entre roles de servidor Exchange 2007. Este problema lo resuelve la utilización de certificados X.509v3 de autentica- ción de máquina. Cuando se instala Exchange Server 2007, tanto el rol de concentrador de transporte como el rol de transporte perimetral, generan un certifi- cado autofirmado que se utiliza en las comunicaciones del protocolo SMTP. Dicho certificado incluye el nombre del equipo y la clave pública que se enviará al servi- dor que lo solicite. Posteriormente, el administrador, mediante el proceso de sus- cripción perimetral, hace que el certificado del concentrador de transporte y el transporte perimetral se intercambien, estableciendo lo que se denomina confianza 161
  • 182. La protección de datos personales: Soluciones en entornos Microsoft mutua por certificados. Esto se realiza durante el proceso EdgeSync o sincronización de perímetro. El procedimiento de suscripción se realiza mediante cmdlet de PowerShell new- edgesuscription, tanto en el servidor de transporte perimetral, para generar el fichero .XML de suscripción, como en el servidor concentrador de transporte para importar dicho fichero de suscripción. Procedimiento de suscripción del servidor perimetral. De esa forma, el servidor concentrador de transporte comienza a confiar en el equipo cuyo certificado ha sido incluido en la lista de confianza, y viceversa. Cada vez que el servidor de transporte perimetral necesita iniciar una nueva conexión con el servidor concentrador de transporte, utiliza su certificado para autenticarse y enviar su identidad de máquina. Además, aprovechando la capacidad que aportan los certificados X.509 para realizar un intercambio de claves simétricas, se crea un canal seguro basado en TLS en todas las comunicaciones SMTP entre servidores de transporte en general. Replicación de datos hacia ADAM. 11.2.8.4. Autenticación de clientes en Exchange Server 2007 Otros mecanismos de autenticación se dan cuando un cliente accede a su buzón o envía un mensaje de correo electrónico. En este caso, hay que diferenciar si el cliente se conecta a través de una aplicación web como el caso de OWA, un cliente POP3/SMTP o con el cliente nativo Outlook 2007.  Autenticación de clientes OWA, ActiveSync y Outlook Anywhere. Todos estos tipos de cliente tienen algo en común y es que todos utilizan aplicaciones web para acceder al buzón del usuario. Estas aplicaciones se 162
  • 183. La aplicación del reglamento de seguridad en los sistemas Microsoft instalan en el rol de servidor de Acceso de Cliente o CAS. El CAS actúa como un proxy para este tipo de conexiones y, por defecto, utiliza el protocolo https. Al igual que con el rol de servidor anterior, el proceso de instalación del servidor de acceso de cliente genera un certificado autofirmado para comprobar la identidad del servidor y cifrar las comunicaciones con SSL. Si bien este certificado es técnicamente totalmente válido, funcionalmente no es viable para entornos en producción, ya que al ser autofirmado, los clientes no confían en dicho certificado y, por tanto, no ofrece las garantías de seguridad adecuadas. Para resolver este problema es necesario utilizar en todas las conexiones de clientes OWA, ActiveSync y Outlook Anywhere, certificados que hayan sido previamente emitidos por entidades de certificación (CA) de confian- za para los usuarios. De esta forma, al iniciar una nueva conexión, el servidor nos envía su certificado y el usuario puede verificar la validez e identidad del equipo al cual se está conectando. Para este propósito, se pueden emplear tanto entidades públicas comer- ciales, como entidades privadas de la propia organización. Además, si la entidad de certificación privada de la organización es de empresa, es decir, integrada en Directorio Activo, podremos disponer de ventajas adicionales de administración y reducción de TCO ya que todos los equipos y usuarios del dominio van a confiar automáticamente en dicha entidad y las solicitudes de nuevos certificados se van a tramitar de forma transparente y utilizando la seguridad integrada de Kerberos y grupos de seguridad del Directorio Activo. Los usuarios también deben autenticarse contra el servidor para poder acceder a los servicios publicados. Esta labor la realiza la aplicación web o el propio servidor Internet Information Services. Los usuarios de OWA utilizan por defecto la autenticación basada en formularios, introduciendo sus credenciales en un formulario de inicio de sesión en la aplicación. En este escenario, es la propia aplicación la que realiza el proceso de autenticación contra el Directorio Activo. El formulario de inicio de sesión utiliza una cookie donde se almacenan las credenciales cifradas del usuario en el navegador del cliente. El segui- miento de esta cookie permite que Exchange monitorice la actividad de OWA en equipos públicos y privados. Si la sesión estuviera inactiva durante más tiempo del permitido, se solicitarían nuevamente las creden- ciales. Para los equipos públicos, la sesión se establece en 15 minutos, mientras que para los equipos privados es de 24 horas. Para mejorar la seguridad, cuando el usuario cierra el navegador o pulsa cerrar sesión en OWA, la cookie se elimina automáticamente. Las creden- 163
  • 184. La protección de datos personales: Soluciones en entornos Microsoft ciales se envían al servidor únicamente durante el primer inicio de sesión; posteriormente se utiliza la cookie para continuar con la sesión iniciada. Aunque los tiempos máximos de inactividad reducen el riesgo de acceso no autorizado en escenarios como por ejemplo equipos compartidos, no eliminan dichos riesgos por completo; por tanto, es recomendable que los usuarios tomen precauciones adicionales como asegurarse de cerrar la sesión una vez finalizada su actividad con OWA. En el caso de disponer de un servidor avanzado de seguridad, como Microsoft ISA Server 2006, éste se puede configurar para que sea el propio ISA Server el que realice la autenticación del usuario, antes incluso de iniciar una conexión al servidor CAS. De este modo reducimos el riesgo de explotación de vulnerabilidades utilizando conexiones directas y no controladas al servidor CAS. Este modo de publicación de servicios se denomina Protocolo de Puente SSL en terminología de ISA Server y se puede utilizar para cualquiera de los servicios web disponibles en Microsoft Exchange Server 2007. Los clientes que utilizan PDAs con ActiveSync u Outlook Anywhere envían sus credenciales al servidor IIS, el cual se encarga de autenticarlas contra el Directorio Activo. En ambos casos, es habitual utilizar autenticación básica, por motivos de compatibilidad con cualquier escenario de movili- dad y red de acceso. Por ello, durante el proceso de instalación del servi- dor CAS, se configura automáticamente la opción de requerir canal seguro SSL para todas las conexiones de cliente en el sitio web predeterminado de Internet Information Services. Una forma de incrementar la seguridad para los usuarios móviles consiste en solicitar certificados de cliente al establecer nuevas conexiones. Los certificados de cliente actúan de forma similar a los certificados de servi- dor, salvo que en esta ocasión sirven para identificar al usuario. Por ejemplo, los usuarios de ActiveSync podrían enviar su certificado de cliente almacenado en el dispositivo móvil en el momento en que el servidor lo solicita, y mediante autenticación EAP – TLS se procede a iniciar sesión en el servicio ActiveSync.  Autenticación de clientes Outlook 2007. Los clientes que utilicen Outlook 2007 para conectarse a su buzón y estén en la intranet utilizan por defecto conexiones MAPI/RPC y autenticación basada en Kerberos. Además, si se ha iniciado sesión en el dominio en el equipo cliente, se utiliza el TGT obtenido desde el centro de distribución Kerberos para realizar un proceso de inicio de sesión único (Single Sign On); por tanto, no se requiere que el usuario introduzca de nuevo sus credenciales. 164
  • 185. La aplicación del reglamento de seguridad en los sistemas Microsoft Los procesos de inicio de sesión únicos reducen el envío de credenciales en la red y, en consecuencia, el riesgo de captura de dichas credenciales. Además, mejoran la experiencia del usuario al no requerir recordar múltiples credenciales de autenticación para diferentes servicios. Si en algún escenario no estuviera disponible el servicio Kerberos para la autenticación del cliente Outlook, entonces se utilizaría como alternativa el protocolo NTLM v2, aunque estas opciones son configurables en el perfil de conexión del cliente. 11.2.9. Artículo 93. Identificación y autenticación (punto 3) 3. Cuando el mecanismo de autenticación se base en la existencia de contraseñas, existirá un procedimiento de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad. Como veremos posteriormente, los sistemas salvaguardan la información relativa a la contraseña para evitar que pueda ser robada. Estos mecanismos de protección evitarán el robo de la misma, pero será necesario que los usuarios establezcan esa contraseña de forma que sólo ellos sean conocedores de la misma para evitar que nadie pueda usurpar sus funcionalidades si la conocen. Con tal motivo, cuando se crea una nueva cuenta de usuario, el administrador podrá asignarle una contraseña, pero le podrá obligar a cambiarla en el primer inicio de sesión y de esta forma establecer una que solo él conocerá. Este procedi- miento podrá también establecerse si el usuario olvida la contraseña y solicita que el administrador se la cambie, quedando siempre como objetivo principal que sea el usuario el único conocedor de la misma. También mediante los mecanismos prede- terminados del sistema, la información de las contraseñas es cifrada mediante los mecanismos de Syskey que se analizarán con posterioridad. Este mecanismo saca fuera del sistema de ficheros la clave utilizada para realizar el cifrado de las contra- señas haciendo más inaccesible esta información. Nivel de autenticación de red. 165
  • 186. La protección de datos personales: Soluciones en entornos Microsoft Cuando la información viaja por la red, ésta también debe encontrarse protegi- da. Cuando estamos en el marco de un dominio y utilizamos los mecanismos de Kerberos, ya vimos en el apartado anterior los mecanismos de defensa para salva- guardar dicha información, a la vez que se garantiza la integridad de los datos. Pero en función del tipo de cliente, si no tenemos un directorio activo, o se ha efectuado una autentificación local o entre dominios donde no se ha efectuado una relación de confianza, entonces las autentificaciones en la red vienen implementadas por el NTLMSSP (NTLM Security Support Provider). Este proveedor de seguridad pro- porciona mecanismos para el cifrado mediante desafío-respuesta y la firma digital de mensajes haciendo uso de una firma simétrica llamada MAC (Message Authentication Code). Con objeto de mantener la compatibilidad con sistemas más antiguos pero sin despreciar los avances en seguridad, el paquete NTLMSSP admite la autentificación con tres tipos de protocolos:  LM (Lan Manager).  NTLM.  NTLMv2. Cada uno estos protocolos presenta diferentes mecanismos de protección en los procesos de autentificación, siendo NTLMv2 el más robusto de los 3. En el sistema de LM no se distinguen mayúsculas de minúsculas y se puede generar una contraseña de un máximo de 14 caracteres. NTLM supone una evolución de LM donde se genera un hash a partir de una contraseña de un máximo de 128 caracte- res, diferenciándose entre mayúsculas y minúsculas. NTLMv2 supone una mejora en la protección del tráfico de red frente a NTLM. La elección y limitación de los mecanismos de autentificación para el paquete NTLMSSP en Windows Server 2008 y Windows Vista pueden configurarse mediante las directivas locales. Las posibilidades que nos ofrece el sistema son las siguientes:  Nivel 0. Enviar respuestas de LM y NTLM: los clientes utilizan autentica- ción LM y NTLM, y nunca usan seguridad de sesión NTLMv2; los servi- dores aceptan autenticación LM, NTLM y NTLMv2.  Nivel 1. Enviar LM y NTLM. Usar la seguridad de sesión NTLMv2 si se negocia: los clientes utilizan autenticación LM y NTLM, y seguridad de sesión NTLMv2 si lo admite el servidor; los servidores aceptan autentica- ción LM, NTLM y NTLMv2.  Nivel 2. Enviar sólo respuesta NTLM: los clientes utilizan autenticación NTLM únicamente y seguridad de sesión NTLMv2 si lo admite el servi- dor; acepta autenticación LM, NTLM y NTLMv2.  Nivel 3. Enviar sólo respuesta NTLMv2: los clientes utilizan autenticación NTLMv2 únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; los servidores aceptan autenticación LM, NTLM y NTLMv2. 166
  • 187. La aplicación del reglamento de seguridad en los sistemas Microsoft  Nivel 4. Enviar sólo respuestas NTLMv2 y rechazar LM: los clientes utilizan autenticación NTLMv2 únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; rechazan LM (sólo aceptan autentica- ción NTLM y NTLMv2).  Nivel 5. Enviar sólo respuestas NTLMv2 y rechazar LM y NTLM: los clientes utilizan autenticación NTLMv2 únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; rechazan LM y NTLM (sólo aceptan autenticación NTLMv2). Evidentemente, de todas las posibles configuraciones, el Nivel 5 proporciona los métodos más seguros, pero el uso de estos mecanismos dependerá del tipo de sistema operativo que estemos utilizando. El sistema predeterminado para Windows Vista y Windows Server 2008 es utilizar NTLMv2. 11.2.10. Artículo 93. Identificación y autentificación (punto 4) 4. El documento de seguridad establecerá la periodicidad, que en ningún caso será superior a un año, con la que tienen que ser cambiadas las contraseñas que, mien- tras estén vigentes, se almacenarán de forma ininteligible. Cuando planteamos como objetivo securizar un entorno empresarial, uno de los primeros aspectos que se tratan de cubrir es plantear los mecanismos necesarios para asegurar que los usuarios utilicen contraseñas, forzando a que la implementación de la misma se base en una serie de características definidas para la empresa. Tanto en la figura de las cuentas locales, como las cuentas de dominio, pode- mos plantear a través del establecimiento de las políticas de seguridad el estableci- miento de un patrón de seguridad para las cuentas de usuarios de la empresa. Como en otras funcionalidades, el uso del Directorio Activo reduce los costes de administración cuando queremos establecer estos valores a un número importante de cuentas. Estas características de las contraseñas son aplicables a nivel de las directivas de cuenta en la subcarpeta correspondiente a las directivas de contraseña: entre las características encontramos la longitud mínima en caracteres para la misma, la posibilidad de forzar a utilizar complejidad para la misma, y la necesidad de cambiarla periódicamente a la vez que se puede establecer un tiempo mínimo antes de que pueda ser cambiada, para evitar junto al histórico de contraseña que se pueda establecer un ciclo corto de cambio de contraseña para reiterarla. Aunque por seguridad el sistema mantiene el almacenamiento de hash para las contraseñas, en circunstancias y por motivos de compatibilidad con las aplica- ciones que utilizan protocolos que requieren conocer la contraseña del usuario para la autenticación, será necesario activar la directiva que permite el almacenamiento de contraseñas con cifrado reversible; equivale básicamente a establecer el almace- namiento de versiones de texto simple de las contraseñas. Esta directiva no debe 167
  • 188. La protección de datos personales: Soluciones en entornos Microsoft habilitarse nunca, a excepción de aquellas circunstancias para los que los requisitos de la aplicación sean más importantes que la necesidad de proteger la información de las contraseñas. Como habíamos definido con anterioridad, la información de las contraseñas quedará almacenada bien en el registro de la base de datos de la SAM cuando se establezca una autenticación local o en los controladores de dominio cuando realice- mos la autenticación a través del Servicio de Directorio. Uno de los objetivos pri- mordiales será el establecer aquellas medidas que permitan proporcionar una línea de defensa adicional para evitar los ataques. Microsoft proporciona la utilidad Sys- key para proporcionar una seguridad mayor al almacenamiento de las contraseñas. Contraseñas de directiva de dominio. Syskey tiene como objetivo realizar una encriptación de los datos importantes de la máquina mediante una clave denominada “startup key”. Este sistema que ya viene habilitado por defecto puede ser invocado ejecutando el comando Syskey, y nos permitirá definir en qué modo es almacenada dicha clave. Para realizar el cambio en la operación del Syskey hay que pulsar el botón de actualización, con lo que nos aparece una plantilla donde podremos elegir las siguientes opciones:  Inicio con contraseña. Para este mecanismo, el sistema genera una clave aleatoria que se almacena de forma cifrada en el equipo local. Además, esta clave estará protegida por una contraseña que proporciona el admi- nistrador. Durante el arranque de la máquina se solicitará también esta clave para continuar con el proceso de arranque.  Contraseña generada por el sistema y almacenada la clave de inicio localmente. Se genera una clave aleatoria y se almacena una versión cifrada de la clave en el equipo local. En el inicio de la máquina no se requiere ninguna contraseña para iniciar los procesos de arranque.  Contraseña generada por el sistema y almacenada la clave de inicio en un disco. Mediante este mecanismo se genera nuevamente una clave de 168
  • 189. La aplicación del reglamento de seguridad en los sistemas Microsoft forma aleatoria, pero es almacenada en un disco, de tal forma que no será solicitada durante el proceso de inicio de la máquina. Si se utiliza este mecanismo, se recomienda realizar una copia de respaldo del mismo para evitar posibles contingencias no previstas. En caso de que el sistema protegido por contraseña o disco nos fallara por falta de ese elemento necesario para inicializar el sistema, nos quedaría la posibilidad de restaurar el registro a un estado anterior de la utilización de la protección del sistema mediante uno de esos mecanismos. Una de las novedades significativas incorporadas en dominios nativos Windows Server 2008 es el establecimiento de granularidad para las contraseñas. Este sistema nos permite evitar una restricción existente hasta ahora, que impedía que usuarios de un mismo dominio fueran obligados a implementar tipos de contraseñas diferenciados en función de sus características, utilización de recursos o simplemente del valor de los datos manejados. A una empresa le podría interesar que el personal informático u otros usuarios con privilegios administrativos tuvieran, por ejemplo, una longitud de contraseña mayor que otros usuarios de la organización. Esta posibilidad no se encontraba disponible hasta Windows Server 2008, que a través del objeto de Configuración de Contraseñas en el Directorio Activo permite esta granularidad de las contraseñas. Inicialmente, el procedimiento para establecer esta característica seguía un proceso que implicaba la creación del objeto a nivel del Editor de Objetos ADSI, aunque actualmente ya se están desarrollando herramientas gráficas como “Specops Pass- word Policy Basic” que permiten una implementación más sencilla de la misma. Así, todos aquellos usuarios que de una u otra forma pudieran verse afecta- dos, por una implementación de seguridad del Reglamento de Seguridad de la LOPD, podrían tener un tipo de contraseñas diferentes del resto de la empresa. 11.2.11. Artículo 94. Copias de respaldo y recuperación 1. Deberán establecerse procedimientos de actuación para la realización como mínimo semanal de copias de respaldo, salvo que en dicho período no se hubiera producido ninguna actualización de los datos. 2. Asimismo, se establecerán procedimientos para la recuperación de los datos que garanticen en todo momento su reconstrucción en el estado en que se encontraban al tiempo de producirse la pérdida o destrucción. Únicamente, en el caso de que la pérdida o destrucción afectase a ficheros o trata- mientos parcialmente automatizados, y siempre que la existencia de documentación permita alcanzar el objetivo al que se refiere el párrafo anterior, se deberá proceder a grabar manualmente los datos quedando constancia motivada de este hecho en el documento de seguridad. 3. El responsable del fichero se encargará de verificar cada seis meses la correcta definición, funcionamiento y aplicación de los procedimientos de realización de copias de respaldo y de recuperación de los datos. 169
  • 190. La protección de datos personales: Soluciones en entornos Microsoft 4. Las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros con datos de carácter personal no se realizarán con datos reales, salvo que se asegure el nivel de seguridad correspondiente al trata- miento realizado y se anote su realización en el documento de seguridad. Si está previsto realizar pruebas con datos reales, previamente deberá haberse realizado una copia de seguridad. Tan importante a veces es tener la información, como recuperarla en caso de desastres, y eso es uno de los elementos que más cuida el reglamento de seguridad. Los procedimientos de copia de seguridad y restauración quedan contemplados dentro del reglamento como una de las operaciones importantes a tener en cuenta. Windows Server 2008 y Windows Vista incorporan herramientas para la realización de copias de seguridad y la restauración en caso de contingencias no previstas. Para la realización tanto de las tareas de copia de seguridad como de la restauración de los datos, los usuarios deben tener los derechos correspondientes para su realiza- ción. Estos privilegios se conceden a través de las directivas asignables en los derechos de usuario. En principio, sólo los usuarios pertenecientes a los grupos de operadores de copia, de servidor y de administradores poseen esta capacidad. Desde el punto de vista más formal en el documento trataremos el sistema de copia de seguridad implementado en Windows Server 2008, por considerar que el alma- cenamiento de datos y, por tanto, el establecimiento de la copia de seguridad se efectuarán normalmente en un sistema servidor. Copia de seguridad. Instalación de la herra- mienta en Windows Server 2008. El sistema de copia de seguridad ha sufrido una profunda reestructuración con respecto al sistema empleado en las anteriores versiones de Windows Server. El sistema de copia de seguridad de Windows Server 2008 proporciona mecanismos de copiado basados en bloques y volúmenes, que lo diferencian de las versiones anteriores que estaban basadas en la copia de ficheros. Esta nueva característica 170
  • 191. La aplicación del reglamento de seguridad en los sistemas Microsoft permite una mejor integración con la funcionalidad de las Instantáneas de Volumen, que comentaremos posteriormente, y que además limita el impacto en los sistemas de almacenamiento. La desventaja, sin embargo, es que la aplicación no permite la copia de ficheros o carpetas individuales. Copia de seguridad. La herramienta Copia de seguridad permite el volcado de copias sobre unida- des de disco, unidades de red y DVD, pero no admite el almacenamiento directo en sistemas de cinta. Para esto último necesitaremos alguna aplicación de terceros, que vuelque las copias de seguridad en cintas. La herramienta de copia de seguridad está compuesta además de la propia aplicación, de funcionalidades controlables a través de PowerShell. Ambas caracte- rísticas no vienen implementadas por defecto y requieren ser activadas en Windows Server 2008. La consola de administración de copias de seguridad no permite la gestión de copias realizadas por NTBackup, aunque Microsoft ha desarrollado una herramienta que se puede implementar en Windows Server 2008 para la gestión de las copias de seguridad realizadas con dicha herramienta. http://www.microsoft.com/downloads/details.aspx?displaylang= es&FamilyID=7da725e2-8b69-4c65-afa3-2a53107d54a7 En cuanto a las tareas de administración y gestión, además de las funcionalida- des aportadas por la consola y PowerShell, se ha definido una implementación mediante comandos con la aplicación Wbadmin. Además de estas herramientas, la aplicación cuenta con el servicio WBengine.exe que corresponde a la función servi- dor de la herramienta, siendo las anteriores citadas los componentes clientes del servicio. La herramienta Copia de seguridad de Windows permite realizar copias de seguridad programadas o manuales. Independientemente de la opción deseada, el sistema nos permite configurar mediante un asistente el tipo de copia a realizar: 171
  • 192. La protección de datos personales: Soluciones en entornos Microsoft  Volúmenes a copiar.  Para el volumen de sistema o aquellos que contengan componentes del sistema operativo, se puede implementar también la recuperación del sistema.  Destino de la copia: local o remota. El destino de la copia nunca puede ser un volumen que contenga datos del sistema operativo.  Para finalizar, en opciones avanzadas nos permite determinar el sistema de Instantánea de Volumen (VSS) que queremos utilizar.  Copia de seguridad completa de VSS.  Copia de seguridad de copia de VSS. Compatible con otras herra- mientas de copia de seguridad de servicios y aplicaciones. En todas las circunstancias, Windows Server utiliza el servicio de instantáneas de volumen. Cuando determinamos que queremos realizar una copia completa, lo primero que hace el sistema es una instantánea de todos los volúmenes. Posterior- mente, realiza la copia de los bloques del volumen, en el destino, creando una imagen VHD (Virtual Hard Disk) de cada volumen. Este sistema de VHD es el mismo que emplean los sistemas de virtualización de Virtual Server y Virtual PC; de hecho, podrían montarse directamente en una máquina virtual. Copia de seguridad de fichero VHD. Una vez realizada la copia completa, el sistema se basa en la generación de instantáneas incrementales, que permite realizar un seguimiento de los bloques dentro del volumen que han sido modificados. Puesto que el uso de copias incrementales es más rápido pero puede impactar en el rendimiento general, nos permite establecer mecanismos de optimización de rendimiento, mediante 3 posi- 172
  • 193. La aplicación del reglamento de seguridad en los sistemas Microsoft bles opciones relacionadas con VSS que pueden ser implementadas en función de la carga del volumen a copiar.  Copia completa. Sistema de copia más lento pero no impacta en el rendi- miento general.  Copia incremental. El sistema de copia es más rápido pero tiene mayor impacto en el rendimiento.  Copia personalizada. Permite determinar qué tipo de copia queremos para cada volumen de disco. Copia de seguridad: optimización del rendimiento. El proceso de restauración mediante esta nueva herramienta es más rápido que los implementados anteriormente, pues al utilizar las instantáneas no es necesario que se carguen todas las copias incrementales como sucedía con la herramienta de copia de seguridad anterior. La restauración de una copia permite desde la restauración comple- ta a la restauración de un único fichero. Para el proceso de restauración, se utiliza un asistente que nos guía en el proceso de recuperación de datos. Dicho asistente consta de una serie de pasos:  En primer lugar, seleccionaremos la fecha de la copia de seguridad que queremos utilizar para la restauración.  Determinaremos posteriormente qué deseamos restaurar: ficheros o carpetas, aplicaciones registradas con la herramienta de copia de seguridad o volúme- nes completos.  En función de la opción anterior, se establece qué elementos deseamos recuperar. 173
  • 194. La protección de datos personales: Soluciones en entornos Microsoft  Para finalizar, determinaremos el destino de la restauración, si sobrescribimos los posibles ficheros existentes, los mantenemos y si deseamos además mantener la configuración de seguridad. Copia de seguridad: restauración. A través de la consola de copia de seguridad de Windows, se mantienen los mensajes de estado y un histórico de procedimientos de copia de seguridad y restauraciones, donde quedan detallados todos los elementos copiados o recupera- dos. Adicionalmente, el servicio de copia genera una serie de registros detallados en la siguiente ruta: %systemroot%logsWindowsServerBackup Aunque queda establecido para las copias de seguridad un sistema de ACL, que impide el acceso a usuarios no administradores, se puede complementar mediante un mecanismo de cifrado de carpeta a través de EFS, que impediría que un acceso de tipo Offline fuera utilizado para la recuperación de los datos almace- nados. Además de esta herramienta de copia de seguridad, Microsoft a través de la gama de productos System Center, proporciona otra herramienta para la realización de copias de seguridad de ficheros y carpetas y también de diferentes servicios Microsoft como SQL Server, Exchange Server o SharePoint. Esta funcionalidad la aporta Data Protection Manager. http://www.microsoft.com/spain/dpm/default.mspx 11.3.Tecnología aplicable a medidas de nivel medio Para el establecimiento de las medidas de seguridad a datos en un nivel medio, además de aquellas de carácter básico que hemos valorado con anterioridad, deberán disponerse otros controles adicionales. A diferencia de lo que ocurría en el 174
  • 195. La aplicación del reglamento de seguridad en los sistemas Microsoft anterior reglamento en vigor, las medidas incluidas en este nivel son menores, principalmente porque la mayoría de requerimientos han sido ya incluidos en las medidas de seguridad de tipo básico. La mayoría de las condiciones que se demandan actualmente a datos de carácter personal que afecten al tipo medio, lo constituyen medidas orgánicas y el establecimiento de controles, mecanismos y registros de la información. Claros ejemplos de ello son los artículos 97 de Gestión de Soporte y Documentos y el 100 de Registro de Incidencias. Para el flujo de dicha información, es óptima la utiliza- ción de Microsoft Office SharePoint Server 2007, como sistema de registro y almace- namiento de la información. A continuación se comentarán aquellos mecanismos técnicos exigibles para datos de tipo medio. 11.3.1. Artículo 98. Identificación y autenticación El responsable del fichero o tratamiento establecerá un mecanismo que limite la posibilidad de intentar reiteradamente el acceso no autorizado al sistema de infor- mación. Con objeto de evitar aquellos ataques por reintentos que pudieran dar con la contraseña de un usuario, el sistema ofrece la posibilidad de establecer el bloqueo de cuentas para evitar esta amenaza. Este mecanismo se habilita mediante directi- vas, bien con ámbito local, bien mediante políticas de grupo en un dominio de Directorio Activo. Cuando se habilitan los bloqueos de cuenta, se decide el número de intentos a disponer por parte del “supuesto” usuario, antes de que dicha cuenta quede bloqueada dentro de un tiempo específico, también configurable. Directiva de bloqueo de cuenta. Una vez que la cuenta se encuentre bloqueada no se podrá acceder a ella aunque se proceda a introducir de forma correcta la contraseña. Los mecanismos de desbloqueo se establecerán por espacio temporal, o bien el desbloqueo deberá 175
  • 196. La protección de datos personales: Soluciones en entornos Microsoft realizarse manualmente por un administrador. A pesar de que el coste administrati- vo es más elevado cuando el desbloqueo es manual, el administrador tendrá cons- tancia de que se ha intentado un ataque por reiteración y podrá establecer otras medidas adicionales, enfocadas a detectar posibles usos fraudulentos de cuentas. Si el desbloqueo se produce automáticamente transcurrido un tiempo, es posible que el ataque quede disfrazado y ni el usuario propietario de la cuenta ni un adminis- trador sean conscientes con absoluta certeza de dicho intento de acceso reiterado y no autorizado. La implementación de estas características puede realizarse mediante la aplicación de Políticas de grupo, aunque esto, como en otras circunstancias, lo haría extensible a otros usuarios de la organización. Al igual que pasaba con aquellos aspectos referentes a los mecanismos de autentificación en Windows Server 2008 para usuarios y contraseñas, ya citados en el artículo 93 de Identificación y Autenti- ficación, puede establecerse también un sistema de Granularidad que permita afectar de forma independiente a todos los usuarios de una organización. Esto permitirá asimismo adecuar las necesidades de implementación de defensa frente a ataques reiterados, en función de las diferentes características de los usuarios u organizativas que pudiera determinar la empresa. Cabe destacar que aunque el bloqueo de cuentas se establece como un meca- nismo para el cumplimiento de este articulado, la agencia no nos limita al uso exclusivo de este mecanismo, sino que permite el uso de otros, siempre que impi- dan los intentos reiterados. En entornos web pueden implementarse procedimientos que sin llegar a necesitar el bloqueo de las cuentas (cuestión importante en caso de acceso externo, para evitar otro tipo de ataque que pudiera conllevar a una denegación del servi- cio), pueden imponerse criterios automatizados para el filtrado de direcciones IP o sesiones en caso de la existencia de un ataque por reiteración, como es el empleado por las técnicas de fuerza bruta, para la obtención de cuentas y contraseñas con las que acceder a la organización. Aunque no se cita en el presente articulado, debemos considerar la necesidad de considerar esta amenaza de forma global. Aunque un servicio que presta un mecanismo de acceso a datos de tipo medio o alto pudiera estar securizado frente a ataques por reiteración, las cuentas podrían encontrarse en situación de riesgo en caso de que otro servicio, aunque no estuviera relacionado con datos de carácter personal pero que sí fuera utilizado por las mismas cuentas, no se encontrase protegido frente a ataques de fuerza bruta. La seguridad de los datos de carácter personal, aunque de forma indirecta, pueden ser accesibles a personas ajenas a la organización. 11.4.Tecnología aplicable a medidas de nivel alto Dentro de las tecnologías para la adopción de medidas de seguridad, éstas son lógicamente las que exigen un mayor esfuerzo por parte del personal de TI y las que pueden llevar un mayor coste de administración y de implantación. Aunque 176
  • 197. La aplicación del reglamento de seguridad en los sistemas Microsoft algunas medidas como las de la auditoría ya fueron comentadas con anterioridad como una posibilidad de control, es ahora cuando se apliquen las medidas de nivel alto cuando es exigible su aplicación. 11.4.1. Artículo 101. Gestión y distribución de soportes 1. La identificación de los soportes se deberá realizar utilizando sistemas de etique- tado comprensibles y con significado que permitan a los usuarios con acceso autorizado a los citados soportes y documentos identificar su contenido, y que dificulten la identificación para el resto de personas. 2. La distribución de los soportes que contengan datos de carácter personal se realizará cifrando dichos datos o bien utilizando otro mecanismo que garantice que dicha información no sea accesible o manipulada durante su transporte. Asimismo, se cifrarán los datos que contengan los dispositivos portátiles cuando éstos se encuentren fuera de las instalaciones que están bajo el control del responsa- ble del fichero. 3. Deberá evitarse el tratamiento de datos de carácter personal en dispositivos portátiles que no permitan su cifrado. En caso de que sea estrictamente necesario, se hará constar motivadamente en el documento de seguridad y se adoptarán medidas que tengan en cuenta los riesgos de realizar tratamientos en entornos desprotegidos. Unificando los clásicos mecanismos de EFS para el cifrado de ficheros en soportes que admitan el sistema de ficheros NTFS y la tecnología IRM en documen- tos de Office y correo electrónico podremos asegurar que esta información sea inteligible una vez que ha salido de nuestros sistemas. A estos mecanismos hay que sumarles el sistema Bitlocker ya mencionado anteriormente, que garantizará el cifrado de disco en sistemas, tanto para Windows Vista como para Windows Server 2008, garantizando la máxima confidencialidad de la información. Adicionalmente, en los sistemas de correo podremos utilizar los mecanismos de S-Mime para el cifrado y la firma del correo electrónico. También Office presenta los mecanismos necesarios, para que a través de la ficha de seguridad podamos establecer el cifrado de los documentos mediante cualquier proveedor CriptoApi que se encuentre instalado en el sistema, pudiendo para los diferentes tipos de proveedores especificar la longitud de la clave y si quedan cifradas también las propiedades del documento. 11.4.2. Artículo 102. Copias de respaldo y recuperación Deberá conservarse una copia de respaldo de los datos y de los procedimientos de recuperación de los mismos en un lugar diferente de aquel en que se encuentren los equipos informáticos que los tratan, que deberá cumplir en todo caso las medidas de seguridad exigidas en este título, o utilizando elementos que garanticen la integri- dad y recuperación de la información, de forma que sea posible su recuperación. 177
  • 198. La protección de datos personales: Soluciones en entornos Microsoft Como ya vimos anteriormente, los mecanismos de copia de seguridad permi- ten realizar copias de seguridad sobre diferentes medios, permitiendo la portabilidad de los mismos que a su vez podrán se protegidos mediante los meca- nismos de implementación de EFS o Bitlocker. 11.4.3. Artículo 103. Registro de accesos 1. De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 2. En el caso de que el acceso haya sido autorizado, será preciso guardar la informa- ción que permita identificar el registro accedido. 3. Los mecanismos que permiten el registro de accesos estarán bajo el control directo del responsable de seguridad competente sin que deban permitir la desactivación ni la manipulación de los mismos. 4. El período mínimo de conservación de los datos registrados será de dos años. 5. El responsable de seguridad se encargará de revisar al menos una vez al mes la información de control registrada y elaborará un informe de las revisiones realiza- das y los problemas detectados. 6. No será necesario el registro de accesos definido en este artículo en caso de que concurran las siguientes circunstancias: a) Que el responsable del fichero o del tratamiento sea una persona física. b) Que el responsable del fichero o del tratamiento garantice que únicamente él tiene acceso y trata los datos personales. La concurrencia de las dos circunstancias a las que se refiere el apartado anterior deberá hacerse constar expresamente en el documento de seguridad. Para la aplicación de los mecanismos de auditoría, las empresas deben ser conscientes de que tal registro debe ser observado tanto en un nivel informático como en la documentación no informatizada. Tanto Windows Server 2008 como Windows Vista garantizan medidas de auditorías para elementos únicamente informáticos; por tanto, debería preverse la necesidad de plantear otro sistema adicional para los elementos no informatizados. Tanto Windows Server 2008 como Windows Vista poseen un potente sistema de registro de información asociable a diferentes auditorías que deben contemplarse para el cumplimiento de la norma. Aunque la norma no establece cuál debe ser el nivel de registro para todos los posibles sucesos que pueden repercutir en la infor- mación de tipo personal, sí lo hace para los niveles más restrictivos. Además de los sistemas de auditoría e información recogida de los diferentes tipos de eventos relativos al registro de Windows accesibles a través del Visor de sucesos, tanto Windows Vista como Windows Server 2008 ofrecen otro potente sistema de registro de aplicaciones y servicios que proporcionan información 178
  • 199. La aplicación del reglamento de seguridad en los sistemas Microsoft adicional para la resolución de incidencias. Aspectos tan importantes como el estado del Kernell, servicios como UAC o Terminal Services, pueden ser controla- dos a través de estos registros. El establecimiento de estas auditorías lo llevamos a efecto nuevamente me- diante las directivas de seguridad, pudiendo realizarse tanto a nivel local como a nivel de dominio. El resultado final de estas auditorías quedará registrado en logs accesibles mediante la herramienta Visor de sucesos que acompaña a ambos siste- mas operativos. Es necesario indicar que cada máquina tendrá constancia de los sucesos que le corresponden. Por ejemplo, si estamos interesados en conocer posi- bles inicios de sesión erróneos de determinados usuarios del dominio, dicha infor- mación quedará registrada en los controladores y no en las máquinas locales, puesto que la autentificación en el dominio se realiza ante la base de datos del mismo situada en los mencionados controladores. Ante la necesidad de auditar alguna acción, se nos ofrecen dos posibilidades: auditorías correctas y auditorías erróneas.  Una auditoría correcta es aquella que emite resultados satisfactorios cuando se han cumplido todas las condiciones para que el hecho se pudiera dar. Por ejemplo, un usuario que inicia una sesión utiliza correcta- mente el usuario para el inicio de la sesión y su contraseña correspondien- te, o cuando un usuario modifica un fichero porque tiene los permisos correspondientes para poder hacerlo.  Una auditoría errónea es aquella que emite resultados cuando no se dan las condiciones establecidas. Siguiendo los ejemplos anteriores, cuando la contraseña o el nombre de inicio de sesión no son los correctos y el sistema nos deniega el inicio de sesión, se habrá producido una auditoría errónea, o cuando el usuario intenta modificar un fichero y no tiene la posibilidad de hacerlo al no disponer de los permisos correspondientes, se producirá nuevamente una auditoría errónea. Windows Server 2008 y Windows Vista incorporan el nuevo sistema de even- tos, Windows Eventing 6.0, que permite una mejora para la gestión de eventos de seguridad y establecer mecanismo de correlación para los mismos. Entre los ele- mentos destacados, Windows Eventing presenta una nueva consola, que permite la generación de vistas personalizadas y un texto descriptivo mejorado. El sistema de Windows Eventing 6.0 basa su funcionalidad en un motor de XML, lo que permite una mayor escalabilidad y accesibilidad. Almacenar la infor- mación en formato XML permite que soluciones particulares puedan acceder a dicha información aprovechando las características y potencia del sistema en XML. Otra de las características que otorgan una potencia mayor al servicio consiste en la capacidad de establecer asociaciones administrativas frente a eventos específicos. Esto nos permite disponer de un sistema reactivo ante determinados tipos de incidencias. El sistema que permite estos desencadenadores es una integración del Servicio Recopilador de Eventos y el nuevo sistema del Programador de tareas. 179
  • 200. La protección de datos personales: Soluciones en entornos Microsoft A través del nuevo asistente contextual para cualquier evento generado en el Visor de sucesos, se permite iniciar un programa, enviar un correo electrónico o generar un mensaje, cuando se da un tipo de evento específico. Cuando establecemos auditorías a través de directivas, se especifican una serie de categorías para determinar diferentes evaluadores en lo referente a la seguridad, de tal forma que debemos plantear si necesitamos o no habilitar las auditorías correctas y erróneas para cada una de las circunstancias que se pudiesen producir. Tanto Windows Server 2008 como Windows Vista presentan las siguientes catego- rías para establecer registros:  Inicio de sesión.  Inicio de sesión de cuenta.  Administración de cuentas.  Acceso a objetos.  Accesos del servicio de directorio.  Usos de privilegios.  Seguimiento de procesos.  Sucesos del sistema.  Cambio de directivas. Auditoría política. Un problema frecuente que planteaban las auditorías de los sistemas operativos anteriores a Windows Vista, es que las nueve categorías que pueden habilitarse respecto de los sistemas de control establecían condiciones genéricas a 180
  • 201. La aplicación del reglamento de seguridad en los sistemas Microsoft elementos aglutinados, no permitiendo realizar auditorías de elementos específicos. Por ejemplo, cuando establecíamos una auditoría para los eventos de inicio de sesión, no podía establecerse una diferenciación entre el inicio o el cierre de sesión, estando obligados a auditar ambas subcategorías. Para los sistemas operativos actuales, se establece una nueva funcionalidad: las directivas de auditoría granular (GAP), de tal forma que pueden habilitarse o deshabilitarse diferentes subcategorías, para los elementos principales de auditoría. Este sistema permite sobre todo filtrar la información importante de la que no lo es para la empresa, limitando la cantidad de información recibida a la estrictamente necesaria. Las diferente subcategorías en las que han quedado definidas las categorías principales son:  Sistema.  Cambio de estado de seguridad.  Extensión del sistema de seguridad.  Integridad del sistema.  Controlador IPsec.  Otros eventos del sistema.  Inicio/cierre de sesión.  Inicio de sesión.  Cierre de sesión.  Bloqueo de cuenta.  Modo principal de IPsec.  Modo rápido de IPsec.  Modo extendido de IPsec.  Inicio de sesión especial.  Otros eventos de inicio y cierre de sesión.  Servidor de directivas de redes.  Acceso de objetos.  Sistema de archivos.  Registro.  Objeto de kernel.  SAM.  Servicios de certificación. 181
  • 202. La protección de datos personales: Soluciones en entornos Microsoft  Aplicación generada.  Manipulación de identificadores.  Recurso compartido de archivos.  Filtrado de paquetes.  Filtrados de conexión.  Otros eventos de acceso a objetos.  Uso de privilegios.  Uso de privilegio confidencial.  Uso de privilegio no confidencial.  Otros eventos de uso de privilegio.  Seguimiento detallado.  Creación del proceso.  Finalización del proceso.  Actividad DPAPI.  Eventos de RPC.  Cambio de plan.  Cambio en la directiva de auditoría.  Cambio de la directiva de autenticación.  Cambio de la directiva de autorización.  Cambio de la directiva del nivel de reglas de MPSSVC.  Cambio de la directiva de Filtering Platform.  Otros eventos de cambio de directivas.  Administración de cuentas.  Administración de cuentas de usuario.  Administración de cuentas de equipo.  Administración de grupos de seguridad.  Administración de grupos de distribución.  Administración de grupos de aplicaciones.  Otros eventos de administración de cuentas.  Acceso Servicio de Directorio.  Acceso del servicio de directorio. 182
  • 203. La aplicación del reglamento de seguridad en los sistemas Microsoft  Cambios de servicio de directorio.  Replicación de servicio de directorio.  Replicación de servicio de directorio detallada.  Inicio de sesión de la cuenta.  Validación de credenciales.  Operaciones de vales de servicio Kerberos.  Otros eventos de inicio de sesión de cuentas.  Servicio de autenticación Kerberos. El control de las categorías y las auditorías que se activarán o no se realiza a través de la aplicación auditpol.exe, ejecutada a través del símbolo del sistema con privilegios administrativos. Entre otras posibilidades, la herramienta permite realizar una copia de seguridad de la directiva de auditoría, así como una recupera- ción posterior en caso de una manipulación incorrecta de los parámetros asignables. En el caso de querer vaciar la configuración de directivas de la auditoría predeter- minada se utilizará la siguiente sentencia: Auditpol /clear Para habilitar una auditoría o deshabilitarla se utilizará esta otra sentencia: Auditpol /set /subcategory:”subcategoría” /success:enable /failure:enable En el caso de querer establecer una acción que implemente los mecanismos de gestión de auditorías, basados en categorías y subcategorías, en dominios existentes de Windows 2000 y Windows 2003, Microsoft ha generado un procedimiento que puede consultarse a través de la siguiente dirección: http://support.microsoft.com/kb/921469/ Auditoría de fichero. 183
  • 204. La protección de datos personales: Soluciones en entornos Microsoft A continuación pasaremos a detallar los diferentes tipos de identificadores y su correspondencia con cada una de las categorías. 11.4.3.1. Eventos de inicio de sesión El resultado de auditar este evento tiene como objetivo determinar cuándo una instancia de un inicio o cierre de sesión se ha establecido en un equipo determinado. Existe una diferencia importante entre este tipo de eventos con los que veremos posteriormente referidos al inicio de sesión de cuenta. Los eventos de sesión de cuenta establecen los sucesos de cuentas para el dominio, quedando reflejados en los controladores de dominio. Por tanto, si tenemos habilitadas ambas categorías, cuando un usuario establezca un inicio de sesión, quedará registrado como un evento de inicio de sesión en la máquina local, y como un inicio de sesión de cuenta en los controladores de dominio. Cuando se establece la auditoría tanto a nivel correcto como erróneo, se generan una serie de identificadores que determinan la acción bajo la que queda establecida la auditoría. Se detallan a continuación todos los sucesos agrupados por las subcategorías correspondientes. Auditoría de evento de inicio de sesión y cuenta. Categoría: Inicio/Cierre Subcategoría: Bloqueo de cuentas 4625 Una cuenta falló al iniciar sesión. Subcategoría: Modo extendido IPsec 4978 Durante negociación del Modo Extendido, IPsec recibió un paquete de negociación no válida. 4979 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 184
  • 205. La aplicación del reglamento de seguridad en los sistemas Microsoft 4980 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 4981 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 4982 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 4983 Una negociación Modo Extendido de IPsec falló. Se ha eliminado la asociación de seguridad correspondiente del modo principal. 4984 Una negociación Modo Extendido de IPsec falló. Se ha eliminado la asociación de seguridad correspondiente del modo principal. Subcategoría: Modo principal de IPsec 4646 Modo iniciado IKE DoS-prevention. 4650 Se estableció una asociación de seguridad Modo principal de IPsec. El modo extendido no está habilitado. No se utilizó la autenticación de certificados. 4651 Se estableció una asociación de seguridad del Modo principal de IPsec. El modo extendido no está habilitado. Un certificado se utilizó para la autenticación. 4652 Una negociación del Modo principal de IPsec falló. 4653 Una negociación del Modo principal de IPsec falló. 4655 Una asociación de seguridad del Modo principal de IPsec finalizó. 4976 Durante la negociación del modo principal, IPsec recibió un paquete de negociación no válido. 5049 Se eliminó un Asociación de seguridad de IPsec. 5453 Una negociación IPsec con un equipo remoto fracasó porque no se inicia el servicio IKE y los Módulos de IPsec de AuthIP (IKEEXT). Subcategoría: Modo Rápido de IPsec 4654 Una negociación Modo rápido de IPsec falló. 4977 Durante la negociación de Modo rápido, IPsec recibió un paquete de negociación no válida. 5451 Se estableció una asociación de seguridad Modo rápido de IPsec. 5452 Una asociación de seguridad Modo rápido de IPsec finalizó. Subcategoría: Cierre de sesión 4634 Se cerró la sesión de una cuenta. 4647 Un usuario inició el cierre de sesión. 185
  • 206. La protección de datos personales: Soluciones en entornos Microsoft Subcategoría: Inicio de sesión 4624 Una cuenta inició una sesión correctamente. 4625 Una cuenta falló al iniciar sesión. 4648 Se intentó un inicio de sesión utilizando credenciales explícitas. 4675 Se filtró el SID. Subcategoría: Servidor de red de directiva 6272 Servidor de Directiva de red concedió acceso a un usuario. 6273 Servidor de Directiva de red denegó acceso a un usuario. 6274 Servidor de Directiva de red descartó la solicitud para un usuario. 6275 Servidor de Directiva de red descartó la solicitud de administración de cuentas para un usuario. 6276 Servidor de Directiva de red puso un usuario en cuarentena. 6277 Servidor de Directiva de red concedió acceso a un usuario pero lo colocó en pruebas porque el host no cumplió con la directiva de estado definido. 6278 Servidor de Directiva de red concedió acceso total a un usuario porque el host cumplió la directiva de estado definido. 6279 Servidor de Directiva de red bloqueó la cuenta de usuario debido a intentos de error repetidos de autenticación. 6280 Servidor de Directiva de red desbloqueó la cuenta de usuario. Los eventos de la subcategoría Servidor de Directiva de Red están disponibles solamente para Windows Vista Service Pack 1 y Windows Server 2008. Subcategoría: Otros eventos Inicio/Cierre 4649 Se detectó un ataque de reiteración. 4778 Se volvió a conectar una sesión de Windows. 4779 Se desconectó una sesión de Windows. 4800 Se bloqueó la estación de trabajo. 4801 Se desbloqueó la estación de trabajo. 4802 Se llamó al protector de pantalla. 4803 Se canceló el protector de pantalla. 5378 La delegación de credenciales solicitadas no fue permitida por directiva. 5632 Se realizó una solicitud autenticada en una red inalámbrica. 5633 Se realizó una solicitud que autentica una red cableada. 186
  • 207. La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Inicio de sesión especial 4964 Los grupos especiales se han asignado a un inicio de sesión nuevo. Los identificadores anteriores nos van a permitir visualizar diferentes circuns- tancias, como pueden ser intentos de acceso no autorizados con cuentas de usuarios que pueden no encontrarse en la empresa o se encuentran en desuso, intentos de validación con la cuenta de administrador, o accesos a recursos de red no autoriza- dos. También pueden determinarse otras posibles restricciones como intentos de conexión en equipos no autorizados o restricciones horarias. También cobra impor- tancia en lo relacionado con los ataques por reiteración, contra los que es necesario implementar a partir del nivel medio todos los eventos relacionados con este tema a través de la Subcategoría: Servidor de red de directiva, además de la correspondien- te a la Subcategoría: bloqueo de cuentas. Determinados eventos, como los relaciona- dos con IPSEC, será solo necesario habilitarlos en caso de utilizarlo para el cifrado de las comunicaciones. En el caso de uso de conectividad inalámbrica también es importante la identificación de determinados eventos que podemos encontrar en la Subcategoría: Otros eventos Inicio/Cierre. 11.4.3.2. Eventos de inicio de sesión de cuenta Estos identificadores establecen las instancias de inicio o cierre de sesión de cuenta en otro equipo distinto del utilizado para validar la cuenta. Cuando un usuario establece una validación en un dominio, se genera un evento de inicio de sesión de cuenta en un controlador de dominio. En el caso de que se quiera establecer un control global de los inicios de sesión de cuenta, procederemos a la visualización de los identificadores de sesión de las auditorías de todos los controladores de dominio, ya que la autentificación de una cuenta de dominio se puede haber realizado en cualquiera de ellos. Adicionalmente, el sistema nos reportará todos aquellos sucesos relacionados con la autentificación tipo Kerberos, mostrando aquellos sucesos críticos relaciona- dos con este servicio para la autentificación y gestión de credenciales en un dominio Windows Server 2008. Subcategoría: Validación de credenciales 4774 Una cuenta se asignó para inicio de sesión. 4775 Una cuenta no se puede asignar para inicio de sesión. 4776 El controlador intentó validar las credenciales de una cuenta. 4777 El controlador de dominio no puede validar las credenciales de una cuenta. Subcategoría: Servicio de autenticación Kerberos 4768 Se solicitó un ticket (TGT) de autenticación Kerberos. 187
  • 208. La protección de datos personales: Soluciones en entornos Microsoft 4771 La preautenticación Kerberos falló. 4772 Una solicitud de ticket de autenticación Kerberos produjo un error. Subcategoría: Kerberos atiende operaciones de Tickets 4769 Se solicitó un Ticket de servicio Kerberos. 4770 Se renovó un Ticket de servicio Kerberos. Estos sucesos, al igual que ocurre con los de inicios de sesión, pueden indicar intentos de acceso no autorizados en el dominio y los controles en los servicios de terminal. También se pueden indicar desajustes horarios de más de cinco minutos (valor predeterminado) entre las estaciones clientes y los controladores de dominio. Es necesario controlar especialmente los eventos 4774 y 4771 que indicarán los sucesos correctos y erróneos de autentificación en el dominio. 11.4.3.3. Eventos de administración de cuenta Cuando se establece una auditoria es importante saber quién está realizando cambios en los planes de cuenta con objeto de determinar posibles eliminaciones de huellas ante posibles ataques, cambios en la pertenencia de grupos de seguridad o uso indebido de credenciales de tipo administrativo. Aunque específicamente el reglamento de seguridad no establece la obligatoriedad de realizar este control de cuentas, el uso de las buenas prácticas y la necesidad de controlar el acceso a cuentas críticas, hacen recomendables la activación de este mecanismo de auditoría. Los siguientes eventos identifican cambios en las cuentas de usuarios, grupos y equipos, así como posibles bloqueos. Subcategoría: Aplicación Administración de Grupo 4783 Se creó un grupo de aplicación básica. 4784 Se cambió un grupo de aplicación básica. 4785 Un miembro se agregó a un grupo de aplicación básica. 4786 Un miembro se quitó de un grupo de aplicación básica. 4787 Un no-miembro se agregó a un grupo de aplicación básica. 4788 Un no-miembro se quitó de un grupo de aplicación básica. 4789 Se eliminó un grupo de aplicación básica. 4790 Se creó un grupo de consulta LDAP. Subcategoría: Administrar cuenta de equipo 4742 Se modificó una cuenta de equipo. 4743 Se eliminó una cuenta de equipo. 188
  • 209. La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Administración de grupo de distribución 4744 Se creó un grupo local con seguridad deshabilitada. 4745 Se cambió un grupo local con seguridad deshabilitada. 4746 Un miembro se agregó a un grupo local con seguridad deshabilitada. 4747 Un miembro se quitó de un grupo local con seguridad deshabilitada. 4748 Se eliminó un grupo local con seguridad deshabilitada. 4749 Se creó un grupo global con seguridad deshabilitada. 4750 Se cambió un grupo global con seguridad deshabilitada. 4751 Un miembro se agregó a un grupo global con seguridad deshabilitada. 4752 Un miembro se quitó de un grupo global con seguridad deshabilitada. 4753 Se eliminó un grupo global con seguridad deshabilitada. 4759 Se creó un grupo universal con seguridad deshabilitada. 4760 Se cambió un grupo universal con seguridad deshabilitada. 4761 Un miembro se agregó a un grupo universal con seguridad deshabilitada. 4762 Un miembro se quitó de un grupo universal con seguridad deshabilitada. Subcategoría: Otros sucesos de administración de cuentas 4739 Se cambió Directiva de dominio. 4782 Se tuvo acceso al hash de contraseña de una cuenta. 4793 Se llamó a la API Comprobar de Directiva de contraseñas. Subcategoría: Administración de grupo de seguridad 4727 Se creó un grupo global con seguridad habilitada. 4728 Un miembro se agregó a un grupo global con seguridad habilitada. 4729 Un miembro se quitó de un grupo global con seguridad habilitada. 4730 Se eliminó un grupo global con seguridad habilitada. 4731 Se creó un grupo local con seguridad habilitada. 4732 Un miembro se agregó a un grupo local con seguridad habilitada. 4733 Un miembro se quitó de un grupo local con seguridad habilitada. 4734 Se eliminó un grupo local con seguridad habilitada. 4735 Se cambió un grupo local con seguridad habilitada. 4737 Se cambió un grupo global con seguridad habilitada. 189
  • 210. La protección de datos personales: Soluciones en entornos Microsoft 4754 Se creó un grupo universal con seguridad habilitada. 4755 Se cambió un grupo universal con seguridad habilitada. 4756 Un miembro se agregó a un grupo universal con seguridad habilitada. 4757 Un miembro se quitó de un grupo universal con seguridad habilitada. 4758 Se eliminó un grupo universal con seguridad habilitada. 4764 Se cambió un tipo groupÆs. Subcategoría: Administración de cuentas de usuario 4720 Se creó una cuenta de usuario. 4722 Una cuenta de usuario se ha habilitado. 4723 Se intentó cambiar la contraseña de una cuenta. 4724 Se intentó restablecer la contraseña de una cuenta. 4725 Una cuenta de usuario se ha deshabilitado. 4726 Se eliminó una cuenta de usuario. 4738 Se cambió una cuenta de usuario. 4740 Se bloqueó una cuenta de usuario. 4765 Se agregó Historial SID a una cuenta. 4766 Al intentar agregar un Historial SID a una cuenta se produjo un error. 4767 Se desbloqueó una cuenta de usuario. 4780 La ACL se estableció en cuentas que son los miembros de grupo de administradores. 4781 Se cambió el nombre de una cuenta: 4794 Se intentó establecer al Modo de restauración de servicios de directorio. 5376 Se modificaron las credenciales de Administrador de credenciales. 5377 Las credenciales de Administrador de credenciales se restauraron a partir de una copia de seguridad. A través de estos identificadores, procederemos a controlar los cambios en las cuentas (contraseñas, pertenencias a grupos, eliminación de las mismas, etc.). Por otro lado, también sería aconsejable no olvidar los posibles bloqueos de cuenta que pudieran identificar intentos de prueba-fallo sobre las cuentas de dominio, como posibles intentos para hacerse con cuentas de usuario o elevar privilegios adminis- trativos a una cuenta para realizar operaciones, enmascaradas bajo cuentas no privilegiadas. Los usos indebidos de cuenta pueden ser descubiertos bajo procedi- mientos como los que resultan de habilitar una cuenta deshabilitada, establecer una nueva contraseña para la misma, realizar posteriormente una validación con la misma y finalmente volver a deshabilitar la cuenta. 190
  • 211. La aplicación del reglamento de seguridad en los sistemas Microsoft Son especialmente importantes en este sentido tanto la Subcategoría: Adminis- trar grupo de seguridad, como la Subcategoría: Administración de cuentas de usuario. La primera es crítica, puesto que muchas empresas basarán la administra- ción para el acceso a objetos relacionados con Datos de Carácter Personal, en un sistema de grupos y membresía. De esta manera podremos controlar si algún usuario es agregado o eliminado de un grupo que disponga de acceso a datos aunque originalmente no era así. En el caso de la administración de cuentas es todavía más obvia, ya que aquí radica el control de las cuentas con privilegios de accesos importantes para una organización. 11.4.3.4. Eventos de acceso a objetos El sistema habilita mediante la auditoría de acceso a objetos la posibilidad de supervisar cuándo se produce un acceso a un objeto del sistema siempre y cuando se tengan habilitadas las Listas de control de acceso al sistema (SACL). Antes de haber habilitado las SACL, se necesita que previamente se hayan habilitado las auditorías sobre los accesos a objetos. Este sistema de control queda encuadrado dentro de las clases del espacio de nombres System.Security.AccessControl que nos van a permitir, mediante programación, establecer las listas de control de acceso discrecionales (DACL), los accesos a recursos mediante permisos, y las SACL, que establecen las auditorías del sistema. Estos controles deben ser considerados como un tema crítico a tratar, ya que nos van a servir para poder controlar los procedimientos de trabajo realizados sobre ficheros, carpetas, impresoras, registro, el servicio de certificados o el directorio activo, pudiendo así poder determinar quién realiza una acción determinada, de tal forma que, cuando un usuario acceda a un objeto que tiene asociada una SACL se genere una auditoría correcta, y si el usuario no logra tener acceso al objeto se genere una auditoría errónea. Auditoría de manipulador de objeto; apertura y acceso. 191
  • 212. La protección de datos personales: Soluciones en entornos Microsoft En este sentido es muy importante determinar qué tipos de acceso deben ser auditados, puesto que en muchas circunstancias unos llevan implícitos a otros, aunque cada uno de ellos generará sus propios eventos con lo que emitirá demasia- da información, que en la mayor parte de circunstancias será superflua. Observados desde el punto de vista de registro de la información se deberían auditar para el acceso a carpetas y ficheros los siguientes elementos a través de las SACL asociadas:  Recorrer carpeta / Ejecutar archivos.  Crear archivos / Escribir datos.  Eliminar subcarpetas y archivos.  Eliminar.  Cambiar permisos.  Tomar posesión. Los dos últimos elementos de la auditoría no constituyen una exigencia desde el punto de vista del reglamento de seguridad, pero proporcionan una ayuda administrativa importante enfocada a evitar cambios en los planes de seguridad planteados por la organización. El resultado de las diferentes auditorías quedará reflejado en el Visor de sucesos a través de los siguientes identificadores. Auditoría del evento de eliminación de fichero. Estos mecanismos de control van a permitirnos también determinar qué es lo que sucede con los objetos del Directorio Activo. Cada objeto del Directorio Activo lleva también asociada una SACL que puede ser controlada desde las propiedades avanzadas de seguridad de los objetos. Lo único que hay que tener presente es que determinados objetos pueden generar un volumen tal de datos normales de control, que podrían llegar a enmascarar sucesos realmente importantes. 192
  • 213. La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Aplicación generada 4665 Se intentó crear un contexto de aplicaciones cliente. 4666 Una aplicación intentó una operación. 4667 Se eliminó un contexto de aplicaciones cliente. 4668 Se inicializó una aplicación. Subcategoría: Servicios de certificación 4868 El administrador de certificados denegó una petición de certificado pendiente. 4869 El Servicio de Certificados recibió una solicitud de certificado reenvia- da. 4870 El Servicio de Certificados revocó un certificado. 4871 El Servicio de Certificados recibió una solicitud para publicar la lista de revocaciones de certificados (CRL). 4872 El Servicio de Certificados publicó la lista de revocaciones de certifica- dos (CRL). 4873 Se cambió una extensión de solicitud de certificado. 4874 Uno o más atributos de solicitud de certificado cambió. 4875 El Servicio de Certificados recibió una solicitud para cerrarse. 4876 Se inició una copia de seguridad del Servicio de Certificados. 4877 Copia de seguridad completada del Servicio de Certificados. 4878 Se inició la restauración del Servicio de Certificados. 4879 Restauración completada del Servicio de Certificados. 4880 Se inició el Servicio de Certificados. 4881 Se detuvo el Servicio de Certificados. 4882 Se cambiaron los permisos de seguridad para el Servicio de Certifica- dos. 4883 El Servicio de Certificados recuperó una clave archivada. 4884 El Servicio de Certificados importó un certificado en su base de datos. 4885 Se cambió el filtro de auditoría para el Servicio de Certificados. 4886 El Servicio de Certificados recibió una solicitud de certificado. 4887 El Servicio de Certificados aprobó una solicitud de certificado y emitió un certificado. 4888 El Servicio de Certificados denegó una petición de certificado. 193
  • 214. La protección de datos personales: Soluciones en entornos Microsoft 4889 El Servicio de Certificados estableció el estado de una solicitud de certificado a pendiente. 4890 Las configuraciones de administrador de certificados para el Servicio de Certificados cambiaron. 4891 Una entrada de configuración se cambió en el Servicio de Certificados. 4892 Una propiedad en el Servicio de Certificados cambió. 4893 El Servicio de Certificados archivó una clave. 4894 El Servicio de Certificados importó y archivó una clave. 4895 El Servicio de Certificados publicó el certificado de entidad emisora en el Servicio de Dominios de Directorio Activo. 4896 Una o más filas se han eliminado de la base de datos de certificados. 4897 Habilitada la separación de funciones. 4898 El Servicio de Certificados cargó una plantilla. Subcategoría: Compartido de archivos 5140 Se tuvo acceso a un objeto de recurso compartido de red. Subcategoría: Sistema de archivos 4664 Se intentó crear un vínculo fuerte. 4985 El estado de una transacción ha cambiado. 5051 Un archivo fue virtualizado. Subcategoría: Filtrado de conexión 5031 El servicio Servidor de seguridad de Windows bloqueó una aplicación para no aceptar conexiones entrantes en la red. 5154 El Firewall de Windows ha permitido conexiones entrantes a una aplicación o a un servicio. 5155 El Firewall de Windows ha bloqueado a una aplicación o a un servicio. 5156 El Firewall de Windows ha permitido una conexión. 5157 El Firewall de Windows ha bloqueado una conexión. 5158 El Firewall de Windows ha permitido un enlace a un puerto local. 5159 El Firewall de Windows ha bloqueado un enlace a un puerto local. Subcategoría: Filtrado de paquetes 5152 El Firewall de Windows bloqueó un paquete. 5153 Un filtro más restrictivo del Firewall de Windows ha bloqueado un paquete. 194
  • 215. La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Manipulación de identificadores 4656 Se solicitó un identificador de un objeto. 4658 Se cerró el identificador de un objeto. 4690 Se realizó un intento que duplica un identificador de un objeto. Subcategoría: Otros eventos de acceso a objetos 4671 Una aplicación intentó obtener acceso a un ordinal bloqueado a través del TBS. 4691 Se solicitó el acceso indirecto a un objeto. 4698 Se creó una tarea programada. 4699 Se eliminó una tarea programada. 4700 Una tarea programada se ha habilitado. 4701 Una tarea programada se ha deshabilitado. 4702 Se actualizó una tarea programada. 5888 Se modificó un objeto en el catálogo COM+. 5889 Se eliminó un objeto del catálogo COM+. 5890 Un objeto se agregó al catálogo COM+. Subcategoría: Registro 4657 Se modificó un valor de Registro. 5039 Una clave de Registro fue virtualizada. Subcategoría: Subcategoría de uso especial múltiple 4659 Se solicitó un identificador de un objeto con intención para eliminar. 4660 Se eliminó un objeto. 4661 Se solicitó un identificador de un objeto. 4663 Se intentó que se tenga el acceso a un objeto. El control de ficheros y carpetas en una organización que pueda manejar datos críticos consignados como de tipo alto reviste de una gran importancia, por lo que para los sucesos que se relacionen con los mismos debe prestarse una gran atención. En este sentido es importante conocer cómo Windows Vista y Windows Server 2008 nos indican a través del Visor de sucesos la información relativa a sucesos con los objetos implicados. Tienen para ello especial significación todos los eventos relacionados con la Subcategoría: Manipulación de identificadores, que indica el inicio de un proceso sobre un fichero o carpeta, así como su finalización. 195
  • 216. La protección de datos personales: Soluciones en entornos Microsoft Entre ambos procesos se realizan una serie de eventos relacionados con la eliminación, escritura, etc. Aunque significativamente estos últimos eventos son los que revelan las acciones realizadas, nos encontramos con las circunstancias que no revelan el fichero o carpeta sujeta a la acción, sino la aplicación que ha llevado a efecto dicho procedimiento (generalmente la utilidad explorer.exe). Es por eso que será necesario correlacionar a través del mismo identificador el proceso que abre el evento y la acción realizada, así como conocer cuándo se cierra el evento y, por tanto, queda libre el identificador para poder ser utilizado posteriormente para otros procesos. El valor, por tanto, que es necesario controlar a través de estos eventos es el Id. de identificador que correlacionará un mismo proceso. En caso de utilizar una herramienta para la consolidación de logs, será necesario utilizar reglas de correla- ción para un seguimiento correcto de la información. 11.4.3.5. Eventos de uso de privilegios Con el fin de realizar operaciones, los usuarios tienen concedidos una serie de derechos y privilegios para poder interactuar con el sistema. Los siguientes eventos relacionan cuándo se ha utilizado o se ha intentado utilizar un privilegio Subcategoría: Uso de privilegios confidencial. 4672 Los privilegios especificados se agregaron a un token de acceso del usuario. Este suceso se genera cuando un usuario inicia una sesión. 4673 Se ha utilizado un privilegio sobre un objeto. 4674 Un usuario intentó realizar una operación de servicio del sistema con privilegios. 11.4.3.6. Eventos de seguimiento de procesos En ciertas circunstancias, y con objeto de tener control y de utilizarse en depuraciones de aplicaciones, es necesario habilitar la auditoría de seguimiento de procesos con objeto de determinar cuándo se inician o cierran los procesos que puede utilizar una aplicación. Hay que tener cuidado al habilitar esta auditoría, pues genera una gran cantidad de datos que pueden saturar la base de datos. Las auditorías para el seguimiento de procesos deberían habilitarse solamente para depuración de aplicaciones u obtención de información de control sobre procesos. Una vez que se haya establecido el control de los procesos, puede ser recomendable deshabilitarlas nuevamente. Subcategoría: Actividad DPAPI 4692 Se intentó una copia de seguridad de la clave maestra de protección de datos. 4693 Se intentó recuperar la clave maestra de protección de datos. 4694 Se intentó la protección de datos protegidos auditables. 196
  • 217. La aplicación del reglamento de seguridad en los sistemas Microsoft 4695 Se intentó una protección de datos protegidos auditables. Subcategoría: Creación de proceso 4688 Se ha creado un proceso 4696 Un identificador primario se asignó al procesarlo. Subcategoría: Terminación de proceso 4689 Ha terminado un proceso Subcategoría: Eventos RPC 5712 Se intentó llamar a un procedimiento remoto. 11.4.3.7. Eventos de sucesos del sistema Esta auditoría controla cuándo se inicia o se apaga un equipo o todos aquellos sucesos relacionados con la seguridad del sistema o el propio registro de seguridad. Este último cobra una gran importancia, ya que nos proporciona información relativa a la limpieza del registro de seguridad y qué usuario la ha realizado. Frente a otros tipos de sucesos, se aconseja en este caso que las auditorías, tanto correctas como erróneas para estos eventos, se encuentren siempre habilitadas de cara a las buenas prácticas de la seguridad, aunque no son requeridas desde el punto de vista de la LOPD. Subcategoría: Controlador IPsec 4960 IPsec eliminó un paquete entrante que no superó una comprobación de integridad. 4961 IPsec eliminó un paquete entrante que no superó una comprobación de reproducción. 4962 IPsec eliminó un paquete entrante que no superó una comprobación de reproducción. 4963 IPsec eliminó un paquete de texto sin cifrar entrante que se debería haber asegurado. 4965 IPsec recibió un paquete desde un equipo remoto con un Índice de Parámetro de Seguridad (SPI) incorrecto. 5478 El servicio de IPsec se ha iniciado correctamente. 5479 Se ha cerrado el servicio de IPsec satisfactoriamente. 5480 El servicio de IPsec no puede obtener la lista completa de interfaz de red en el equipo. 5483 El servicio de IPsec no puede inicializar el servidor RPC. 5484 El servicio de IPsec ha experimentado un error crítico y se ha cerrado. 197
  • 218. La protección de datos personales: Soluciones en entornos Microsoft 5485 El servicio de IPsec no puede procesar algunos filtros IPsec sobre un evento plug-and-play para la interfaz de red. Subcategoría: Otros sucesos de sistema 5024 El servicio Servidor de seguridad de Windows se ha iniciado correcta- mente. 5025 Se ha detenido el servicio Servidor de seguridad de Windows. 5027 El servicio Servidor de seguridad de Windows no puede recuperar la directiva de seguridad del almacenamiento local. El servicio continua- rá utilizando la directiva actual. 5028 El servicio Servidor de seguridad de Windows no puede analizar la directiva de seguridad nueva. El servicio continuará con la directiva actualmente utilizada. 5029 El servicio Servidor de seguridad de Windows no puede inicializar el controlador. El servicio continuará utilizando la directiva actual. 5030 No se puede iniciar el servicio Servidor de seguridad de Windows. 5032 Firewall de Windows no pudo notificar qué bloqueó una aplicación de conexiones entrantes en la red al usuario. 5033 El Controlador de Windows Firewall se ha iniciado correctamente. 5034 Se ha detenido el Controlador de Windows Firewall. 5035 El Controlador de Windows Firewall no se ha podido iniciar. 5037 El Controlador de Windows Firewall detectó errores de tiempo de ejecución críticos. Se interrumpe. 5058 Operación de archivo de clave. 5059 Operación de migración clave. Subcategoría: Cambio de estado de la seguridad 4608 Se está iniciando Windows. 4609 Se está cerrando Windows. 4616 La hora de sistema se cambió. 4621 El Administrador recuperó un sistema de fallo de auditoría. Se permi- tirá ahora que los usuarios que no son los administradores inicien sesión. No se puede registrar ninguna actividad auditable. Subcategoría: Extensión de sistema de seguridad 4610 Un paquete de autenticación ha sido cargado por la Autoridad de seguridad local. 198
  • 219. La aplicación del reglamento de seguridad en los sistemas Microsoft 4611 Un proceso de inicio de sesión de confianza se ha registrado en la Autoridad de seguridad local. 4614 Un paquete de notificación ha sido cargado por el Administrador de cuentas de seguridad. 4622 Un paquete de seguridad ha sido cargado por la Autoridad de seguri- dad local. 4697 Un servicio se ha instalado en el sistema. Subcategoría: Integridad de sistema 4612 Los recursos internos asignados para la cola de mensajes de auditoría se han saturado resultando la pérdida de algunas auditorías. 4615 Uso no válido de puerto LPC. 4618 Se ha producido un patrón de eventos de seguridad supervisada. 4816 RPC detectó una infracción de integridad en un mensaje entrante. 5038 La integridad de código determinó que el hash de imagen de un archivo no es válido 5056 Se realizó una prueba criptográfica. 5057 En una operación de primitiva criptográfica se produjo un error. 5060 En una operación de comprobación se produjo un error. 5061 Operación criptográfica. 5062 Se realizó una prueba del modo de núcleo criptográfico. Son especialmente útiles en seguridad todos los eventos relativos al módulo de firewall, que permiten reportar intentos de ataque o accesos de aplicaciones no permitidos. A destacar también las operaciones reportadas por los diferentes even- tos de la subcategoría de cambio de estado de la seguridad, que reflejan los inicios y cierres de Windows y cuándo el administrador ha permitido que se inicie sesión de los usuarios, aunque no puedan realizarse auditorías por hallarse llenos los ficheros de eventos, ya que no se permite sobreescribirlos. 11.4.3.8. Eventos de cambios de directivas Para establecer un control más exhaustivo sobre los derechos otorgados a los usuarios del sistema es importante tener controlados los cambios en las directivas de asignación de derechos de usuario, de auditoría o de confianza que se puedan realizar. Esto nos va a reportar información de cuándo se ha podido producir un incidente que puede estar enmascarado mediante algún cambio en las directivas, bien a nivel de dominio o en la máquina local. Los procedimientos de control de directivas son un núcleo principal de la seguridad de una organización. Muchos de los controles establecidos se refieren a 199
  • 220. La protección de datos personales: Soluciones en entornos Microsoft directivas, y en especial a las directivas de auditoría. Un buen sistema de auditoría podría quedar muy mermado si alguien pudiera deshabilitarlo y habilitarlo, sin que se hubiese generado ninguna acción que reportara dicho proceso. Subcategoría: Cambio de directiva de auditoría 4715 Se cambió la directiva de auditoría (SACL) en un objeto. 4719 Se cambió directiva de auditoría de sistema. 4902 Se creó la tabla de usuario de directiva de auditoría. 4904 Se realizó un intento que registra un origen de evento de seguridad. 4905 Se realizó un intento que anula el registro de un origen de eventos de seguridad. 4906 El valor de CrashOnAuditFail ha cambiado. 4907 Se cambiaron las configuraciones de auditoría en objeto. 4908 Tabla modificada especial de Inicio de sesión de Grupos. 4912 Se cambió la Directiva de auditoría por usuario. Subcategoría: Cambio de directiva de autenticación 4706 Una confianza nueva se creó en un dominio. 4707 Se quitó una confianza a un dominio. 4713 Se cambió la directiva Kerberos. 4716 Se modificó la información de dominio de confianza. 4717 El acceso de seguridad a sistema se concedió a una cuenta. 4718 Se eliminó acceso de seguridad a sistema de una cuenta. 4864 Se detectó una colisión de espacio de nombres. 4865 Se agregó una entrada de información de bosque de confianza. 4866 Se quitó una entrada de información de bosque de confianza. 4867 Se modificó una entrada de información de bosque de confianza. Subcategoría: Cambio de directiva de autorización 4704 Se asignó un derecho de usuario. 4705 Se quitó un derecho a un usuario. 4714 Se cambió la directiva de recuperación de datos cifrados. Subcategoría: Filtrar cambio de directiva de plataforma 4709 Se iniciaron los Servicios de IPsec. 4710 Se deshabilitaron los Servicios de IPsec. 200
  • 221. La aplicación del reglamento de seguridad en los sistemas Microsoft 4711 Puede contener cualquiera de los siguientes:  Motor PAStore almacenó una copia de almacenamiento de la directiva IPsec del Directorio Activo en la caché del equipo.  Motor PAStore aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo.  Motor PAStore almacenó en el Registro local la directiva de IPsec en el equipo.  Motor PAStore no puede copiar la directiva IPsec de Directorio Activo en la caché del equipo local.  Motor PAStore no almacenó en el Registro local la directiva de IPsec en el equipo.  Motor PAStore no aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo.  Motor PAStore no puede aplicar algunas reglas de la directiva IPsec activa en el equipo.  Motor PAStore no puede cargar el directorio de directivas IPsec en el equipo.  Motor PAStore cargó el directorio de directivas IPsec en el equipo.  Motor PAStore no puede cargar el almacenamiento local de directi- vas IPsec en el equipo.  Motor PAStore cargó el almacenamiento local de directivas IPsec en el equipo.  Motor PAStore realizó un sondeo de cambios de la directiva IPsec activa y no detectó ningún cambio. 4712 El servicio de IPsec encontró un error potencialmente grave. 5040 Se ha hecho un cambio en la configuración IPsec. Se agregó una Auten- ticación. 5041 Se ha hecho un cambio en la configuración IPsec. Se modificó una Autenticación. 5042 Se ha hecho un cambio en la configuración IPsec. Se eliminó una Autenticación. 5043 Se ha hecho un cambio en la configuración IPsec. Se agregó una Regla de Seguridad de Conexión. 5044 Se ha hecho un cambio en la configuración IPsec. Se modificó una Regla de Seguridad de Conexión. 5045 Se ha hecho un cambio en la configuración IPsec. Se eliminó una Regla de Seguridad de Conexión. 201
  • 222. La protección de datos personales: Soluciones en entornos Microsoft 5046 Se ha hecho un cambio en la configuración IPsec. Se agregó una entra- da Criptográfica. 5047 Se ha hecho un cambio en la configuración IPsec. Se modificó una entrada Criptográfica. 5048 Se ha hecho un cambio en la configuración IPsec. Se eliminó una entrada Criptográfica. 5440 La llamada siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5441 El filtro siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5442 El proveedor siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5443 El contexto siguiente de proveedor estuvo presente cuando se inició el Motor de Firewall de Windows. 5444 La sub-capa siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5446 Se ha cambiado una llamada al Proveedor de filtrado de Windows. 5448 Se ha cambiado el Proveedor de filtrados de Windows. 5449 Se ha cambiado un contexto del Proveedor de filtrado de Windows. 5450 Se ha cambiado una sub-capa del Proveedor de Filtrado de Windows. 5456 El motor PAStore aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo. 5457 El motor PAStore no aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo. 5458 El motor PAStore almacenó localmente una copia de almacenamiento de la directiva IPsec del Directorio Activo en la caché del equipo. 5459 El motor PAStore no pudo almacenar una copia de almacenamiento de la directiva IPsec del Directorio Activo en la caché del equipo. 5460 El motor PAStore almacenó en el Registro local la directiva IPsec del equipo. 5461 El motor PAStore no almacenó en el Registro local la directiva IPsec del equipo. 5462 El motor PAStore no pudo aplicar algunas reglas de la directiva IPsec activa en el equipo. 5463 El motor PAStore realizó un sondeo de cambios de la directiva IPsec activa y no detectó ningún cambio. 202
  • 223. La aplicación del reglamento de seguridad en los sistemas Microsoft 5464 El motor PAStore realizó un sondeo de cambios de la directiva IPsec activa, detectó cambios y los aplicó al Servicio de IPsec. 5465 El motor PAStore recibió un control para volver a cargar la directiva IPsec y procesó el control correctamente. 5466 El motor PAStore realizó un sondeo de cambios de la directiva y determinó que no se puede alcanzar el Directorio Activo y que en su lugar utilizará la copia almacenada en la caché de la directiva IPsec del Directorio Activo. 5467 El motor PAStore realizó un sondeo de cambios de la directiva y determinó que no se puede alcanzar el Directorio Activo y no se puede utilizar la copia almacenada en la caché de la directiva IPsec del Directorio Activo. 5468 El motor PAStore realizó un sondeo de cambios de la directiva IPsec, determinó que se puede alcanzar el Directorio Activo, que encontró cambios de la directiva y que aplicó aquellos cambios. Ya no se utiliza la copia almacenada en caché de la directiva IPsec del Directorio Activo. 5471 El motor PAStore cargó el almacenamiento local de directivas IPsec en el equipo. 5472 El motor PAStore no puede cargar el almacenamiento local de directi- vas IPsec en el equipo. 5473 El motor PAStore cargó el almacenamiento de directorio de directivas IPsec en el equipo. 5474 El motor PAStore no pudo cargar el almacenamiento de directorio de directivas IPsec en el equipo. 5477 Motor PAStore no pudo agregar un filtro de modo rápido. Subcategoría: Cambio de directiva a nivel de regla MPSSVC 4944 La directiva siguiente estuvo activa cuando se inició el Firewall de Windows. 4945 Una regla se mostró cuando se inició el Firewall de Windows. 4946 Un cambio se ha realizado en la lista de excepciones del Firewall de Windows. Se agregó una regla. 4947 Un cambio se ha realizado en la lista de excepciones del Firewall de Windows. Se modificó una regla. 4948 Un cambio se ha realizado en la lista de excepciones del Firewall de Windows. Se eliminó una regla. 4949 Las configuraciones del Firewall de Windows se han restaurado a los valores predeterminados. 203
  • 224. La protección de datos personales: Soluciones en entornos Microsoft 4950 Se ha cambiado una configuración del Firewall de Windows. 4951 Una regla se ha omitido porque su número de versión principal no fue reconocido por el Firewall de Windows. 4952 Las partes de una regla se han omitido porque su número de versión secundaria no fue reconocido por el Firewall de Windows. Se exigirán las otras partes de la regla. 4953 Una regla ha sido omitida por el Firewall de Windows porque no podía analizar la regla. 4954 Las configuraciones de Directiva de grupo de Firewall de Windows han cambiado. Se han aplicado las nuevas configuraciones. 4956 El Firewall de Windows ha cambiado el perfil activo. 4957 El Firewall de Windows no aplicó la regla siguiente: 4958 El Firewall de Windows no aplicó la regla siguiente porque la regla hizo referencia a elementos no configurados en este equipo. Subcategoría: Otros eventos de cambio de directiva 4909 Se cambiaron las configuraciones de directiva local para el TBS. 4910 Se cambiaron las configuraciones de directiva de grupo para el TBS. 5063 Se intentó una operación del proveedor de cifrado. 5064 Se intentó una operación de contexto de cifrado. 5065 Se intentó una modificación de contexto de cifrado. 5066 Se intentó una operación de función criptográfica. 5067 Se intentó una modificación de función criptográfica. 5068 Se intentó una operación de proveedor de función criptográfica. 5069 Se intentó una operación de propiedad de función criptográfica. 5070 Se intentó una modificación de propiedad de función criptográfica. 5447 Se ha cambiado un filtro del la Plataforma de filtrado de Windows. 6144 La directiva de seguridad en los objeto de directiva de grupo se ha aplicado correctamente. 6145 Se encontró uno o más errores mientras se procesaban las directivas de seguridad en los objetos de directiva de grupo. Subcategoría: Subcategoría de uso special Nota. El suceso siguiente puede ser generado por cualquier adminis- trador de recursos cuando su subcategoría está habilitada. Por ejemplo, el suceso siguiente puede ser generado por el administrador de recur- 204
  • 225. La aplicación del reglamento de seguridad en los sistemas Microsoft sos de Registro o por el administrador de recursos del sistema de archivos. 4670 Se cambiaron los permisos de un objeto. 11.4.3.9. Protección de los registros Como hemos visto, las auditorías presentan una valiosa información de cara a descubrir posibles incidencias relacionadas con la seguridad. Con objeto de impedir problemas con los datos y que alguien los pudiera borrar, el sistema aplica unos permisos predeterminados sobre el fichero de registro SecEvent.Evt, fichero donde queda almacenada dicha información. Estos permisos pueden ajustarse según las necesidades de la empresa. Sobre este fichero se va a poder efectuar también un registro de auditoría con objeto de determinar accesos y modificaciones. Otro aspecto a tener en cuenta también, es el relacionado con su tamaño y la cantidad de sucesos que puede almacenar. Este fichero, al igual que todos los de registro, tiene un tamaño específi- co que se puede modificar. Si se alcanza el tamaño máximo para dicho fichero, el sistema no permite:  Sobrescribir los sucesos cuando sean necesarios. Se irían eliminando los sucesos según su antigüedad.  Sobrescribir los sucesos que tengan más de un número de días. Sólo se eliminarán sucesos si es necesario que hayan superado el número de días especificados.  No sobrescribir sucesos. Los sucesos no se eliminarán automáticamente, sino que se requiere la intervención manual del administrador. En caso que se hubiera alcanzado el tamaño máximo del fichero y no se pudieran sobrescribir sucesos, el sistema impediría el acceso local a usuarios que no sean administradores, con objeto de impedir que un problema de seguridad queda- ra enmascarado por no sobrescribir los sucesos que los relaciona. Para proceder a la realización de cambios en estas configuraciones, tendremos que recurrir a las propiedades del registro de seguridad en el visor de sucesos. De cara a mejorar la administración y mediante la configuración de políticas de grupo en el Directorio Activo, se puede gestionar toda la configuración del fichero de registro mediante directivas de grupo. Al objeto de asegurar la información que genera la auditoría, se determina que la responsabilidad queda depositada en el administrador para evitar incidentes sobre los datos de auditoría. En el caso de los sistemas operativos Windows Vista y Windows Server 2008, el sistema protege por defecto el fichero secevent.evt donde se depositan las auditorías del sistema, permitiendo que sólo los administradores y la cuenta de sistema tengan acceso a dicho fichero. En el caso de que alguna perso- na más tuviera que tener acceso a este fichero, habría que concederle permisos explícitos. 205
  • 226. La protección de datos personales: Soluciones en entornos Microsoft Auditoría: propiedades del registro. Otro problema que se puede plantear es qué pasaría si el registro de seguridad se llena. Evidentemente, este hecho podría ocasionar que no se registraran eventos importantes, o bien que se acabaran eliminando otros. Para evitar estas posibles circunstancias, el sistema prevé que se pueda apagar el sistema en caso de que se llene el registro de seguridad; esta capacidad puede ser habilitada desde las directi- vas de seguridad en las opciones de seguridad en auditoría: apagar el sistema de inmediato si no puede registrar auditorías de seguridad. De todas formas, con el fin de evitar este procedimiento en sistemas que necesiten una alta disponibilidad, se debería establecer la necesidad de ampliar el tamaño para el almacenamiento de registros y plantear una estrategia para realizar una copia de seguridad de los datos contenidos en el fichero (estableciendo protec- ción sobre el mismo), y vaciando posteriormente el contenido del mismo. 11.4.3.10. Consolidación de Logs Aunque los datos recogidos evidentemente reflejan una importante informa- ción, nos podemos encontrar que ésta puede ser tan ingente que puede ser difícil distinguir los datos realmente relevantes de aquellos que puedan resultar super- fluos. Por tanto, debería adoptarse algún tipo de metodología para la gestión de dichos logs y la información que queda reflejada en ellos. Diferentes empresas han implementado herramientas que en este sentido permiten la recopilación de logs de los diferentes tipos de registros y, por tanto, hacer un seguimiento más exacto de la información y permitir la generación de informes de acuerdo a las incidencias detectadas. La solución Microsoft, Ms. System Center Operation Manager 2007, cumple de forma óptima la funcionalidad para la consolidación de logs y generación de informes con los datos recopilados. ACS Collector (Audit Collection Service), 206
  • 227. La aplicación del reglamento de seguridad en los sistemas Microsoft constituye el Rol, encargado de la recogida de la información procedente de los agentes correspondientes (ACS Forwarder) y de almacenar la información en el servicio de Base de Datos correspondiente (ACS Database). Además de la gestión de la información, el servicio presenta una serie de infor- mes pregenerados, proporcionando algunos de los datos más importantes relaciona- dos con la seguridad general de los sistemas de información de una empresa:  Gestión de cuentas.  Accesos no autorizados.  Cambios en la política.  Integridad del sistema. No obstante, el servicio permite la generación de nuevos informes que pueden ajustarse a las necesidades de informes mensuales estipulados por el Reglamento de Seguridad que debe elaborar el responsable de seguridad. 11.4.3.11. Auditoría en Exchange 2007 Hoy en día, la auditoría de sistemas Exchange se considera una tarea crucial dentro de las labores de administración y gestión diarias, y como tal no sólo es aplicable en escenarios donde sea de aplicación la normativa LOPD. La auditoría nos permite conocer cómo se están comportando nuestros servidores y detectar posibles problemas o fallos de seguridad. Además, las organizaciones requieren que sus sistemas sean auditables, con el fin de cumplir con la legislación vigente o normativas internas de la propia organización. Aunque existen diversos programas de terceros en el mercado para realizar auditorías tanto de sistema operativo como de Exchange Server, en este apartado se exponen las herramientas que el propio Exchange Server 2007 proporciona para realizar una auditoría de su organización. Exchange Server 2007 incluye importantes mejoras en el ámbito de la recolección de datos y auditoría .Podemos dividir las áreas de auditoría en las siguientes:  Eventos de aplicación.  Auditoría de cambios de configuración.  Registro de Diario.  Logs de transporte.  Seguimiento de mensajes.  Acceso a buzones e inicios de sesión. Eventos de aplicación Exchange Server 2007 registra de forma predeterminada los eventos básicos como aquellos que son críticos para el sistema o alertas de funcionamiento. Si se 207
  • 228. La protección de datos personales: Soluciones en entornos Microsoft requiere elevar el nivel de registro para realizar un seguimiento detallado, auditar el adecuado funcionamiento o comprobar fallos del sistema, se puede realizar median- te el cmdlet de Powershell Set-EventLogLevel. Elevar el nivel de registro puede ayudar a resolver un problema o auditar el uso que los usuarios realizan de la mensajería. Se pueden establecer los niveles 0 (inferior), 1 (bajo), 3 (medio), 5 (alto) y 7 (experto). El nivel de registro predetermi- nado es 0 (inferior). Prácticamente todos los procesos de Exchange se pueden configurar con otros niveles de registro diferentes al predeterminado. La lista completa de procesos se puede consultar en la siguiente dirección: http://technet.microsoft.com/es-es/ library/bb201661(EXCHG.80).aspx Auditoría de cambios de configuración Es importante controlar los cambios que re realizan en la configuración de la organización Exchange, quién los ha realizado y en qué momento. Para ello debe- mos apoyarnos en las capacidades de auditoría de Windows Server mediante la funcionalidad de auditoría de los cambios en los objetos del Directorio Activo, debi- do a que la mayor parte de la configuración de Exchange se almacena en la parti- ción de configuración del Directorio Activo. Por tanto, se replica en todos los contro- ladores de dominio y se puede cambiar en cualquier Controlador de Dominio. Mediante una GPO, se debe habilitar la directiva de auditoría denominada Auditoría del acceso al servicio de Directorio en los Controladores de Dominio. Para obtener toda la información de acceso, se debe habilitar tanto el error como el éxito. Una vez hecho esto, se registrarán en el visor de eventos de seguridad de los Controladores de Dominio los cambios y accesos realizados a los objetos de Directo- rio Activo, entre los que se encuentran los de Exchange Server. Registro de diario El registro en diario facilita que las organizaciones cumplan con la legislación y normas de control de la información. Además, Exchange Server 2007 ayuda a proteger la información que contienen los informes de registro en diario del acceso no autorizado. El registro en diario es la capacidad de registrar todas las comunicaciones, incluyendo las de correo electrónico. Debido a las nuevas normativas, muchas organizaciones se ven obligadas a mantener los registros de la comunicación entre los empleados cuando realizan las tareas de administración diarias. Entre estas normativas se encuentran la Directiva de protección de datos de la Unión Europea (EUDPD) o la propia Ley Orgánica de Protección de Datos que estamos tratando. Exchange cuenta con un agente de transporte denominado agente de registro en diario, el cual se encarga de cumplir con las reglas configuradas de registro cuan- do el mensaje cumple con las condiciones establecidas. Exchange 2007 proporciona dos opciones de registro en diario para satisfacer los requisitos de la organización: 208
  • 229. La aplicación del reglamento de seguridad en los sistemas Microsoft  Diario estándar. Se configura a nivel de base de datos y hace que el agente registre en el diario todos los mensajes enviados y procedentes de los destinatarios y remitentes ubicados en una base de datos de buzones específica.  Registro en diario Premium. Se configura con reglas de diario y permite que se especifique el destinatario o grupo del cual se registrarán los mensajes enviados o recibidos. Para utilizar esta característica se requiere una licencia CAL. Los buzones de registro en diario contienen información muy confidencial; por ello, se deben proteger los buzones de registro en diario porque reúnen mensajes que se envían hacia y desde destinatarios de su organización, y porque estos mensa- jes pueden formar parte de procedimientos legales o estar sujetos a requisitos normativos. Hay varias leyes que requieren que los mensajes permanezcan sin manipulación antes de que se envíen a una autoridad de investigación. Un informe de diario es el mensaje que genera Microsoft Exchange cuando un mensaje coincide con una regla de diario y debe enviarse al buzón de registro en diario. Exchange 2007 admite sólo el registro en diario de sobres. Mediante el registro en diario de sobres, el mensaje original que coincide con la regla de diario se incluye sin modificaciones como dato adjunto al informe de diario. El cuerpo de un informe de diario contiene la dirección de correo electrónico del remitente, el asunto, el Id. de mensaje y las direcciones de correo electrónico de los destinatarios contenidos en el mensaje original. Cuando el agente de registro en diario registra un mensaje, dicho agente intenta capturar todos los detalles posibles sobre el mensaje original. Esta informa- ción es muy importante a la hora de determinar la intención del mensaje, sus destinatarios y sus remitentes. Logs de transporte Los registros de transporte están disponibles en los servidores con la función de transporte perimetral o concentrador de transporte. Se pueden dividir en las siguientes categorías:  Registro de conectividad. Registro de la actividad de conexión SMTP de las colas de entrega de mensajes salientes al servidor de buzones, host inteligente o dominio de destino. De forma predeterminada, el registro de conectividad está deshabilitado.  Registro de protocolo. Registro de la actividad de los conectores de envío SMTP entre servidores de mensajería. De forma predeterminada, el registro de protocolo está deshabilitado.  Registro de seguimiento de mensajes. Registro detallado de la actividad de transporte de mensajes durante la transferencia de un equipo Exchange a otro. Por defecto, el seguimiento de mensajes está habilitado. 209
  • 230. La protección de datos personales: Soluciones en entornos Microsoft  Registro de agente. Registro de las acciones que los agentes antivirus y contra correo electrónico no deseado de Exchange 2007 realizan en un mensaje. De forma predeterminada, el registro de agente está habilitado.  Registro de tabla de enrutamiento. Registro de las tablas de enrutamiento que los servidores de transporte utilizan para entregar mensajes. De forma predeterminada, el registro de tabla de enrutamiento está habilitado. Seguimiento de mensajes La herramienta de seguimiento de mensajes que incorpora Exchange Server 2007 ha sido mejorada para permitir búsquedas con criterios de filtrado más flexi- bles y potentes. El seguimiento de mensajes es fundamental para realizar auditorías de transporte de mensajes o resolver incidencias de usuarios en el envío o recepción de mensajes. El seguimiento de mensajes está habilitado por defecto en los servidores de transporte y de buzones de la organización Exchange, por lo que pueden realizarse consultas en cualquiera de estos roles de servidor. La convención de nomenclatura de los archivos de registro del directorio de registro de seguimiento de mensajes depende de la función del servidor que esté instalada. En un servidor de transporte de concentradores o en un servidor de transporte perimetral, los archivos de registro se denominan MSGTRKyyyymmdd- nnnn.log. En un servidor Buzón de correo, los archivos de registro se denominan MSGTRKMyyyymmdd-nnnn.log. De forma predeterminada, los archivos de registro de seguimiento de mensajes se encuentran en C:Archivos de programaMicrosoftExchange ServerTransportRolesLogsMessageTracking. La herramienta de seguimiento de mensajes se encuentra en la sección del centro de herramientas de la consola de Administración Exchange, aunque también se pueden ejecutar utilizando el Shell de Administración con el cmdlet Get- MessageTrackingLog. El seguimiento de mensajes depende del servicio de búsqueda de registros de transporte de Microsoft Exchange, por lo que si éste se deshabilita, no se registrarán los eventos de transporte de los mensajes. Con la herramienta de seguimiento, se pueden consultar los siguientes eventos de transporte: BADMAIL Se ha enviado un mensaje mediante el directorio de recogida o el directorio de repetición que no se puede entregar o devolver. DELIVER Se ha entregado un mensaje a un buzón. DEFER Se ha retrasado la entrega del mensaje. DSN Se ha generado una notificación de estado de entrega (DSN). EXPAND Se ha ampliado un grupo de distribución. FAIL Error al entregar el mensaje. 210
  • 231. La aplicación del reglamento de seguridad en los sistemas Microsoft POISONMESSAGE Se ha incluido o quitado un mensaje de la cola de mensajes dudosos. RECEIVE Se ha recibido un mensaje y se ha confirmado para la base de datos. REDIRECT Se ha redirigido un mensaje a un destinatario alternativo tras una búsqueda en el servicio de directorio de Directorio Activo. RESOLVE Los destinatarios de un mensaje se han resuelto para una direc- ción de correo electrónico distinta tras una búsqueda en Directo- rio Activo. SEND Se ha enviado un mensaje mediante el Protocolo simple de transferencia de correo (SMTP) a otro servidor. SUBMIT Se ha enviado un mensaje mediante un equipo de Exchange 2007 que tiene instalada la función del servidor Buzón de correo a un equipo Exchange 2007 con la función del servidor Transpor- te de concentradores o la función del servidor Transporte perimetral. Los registros de seguimiento de mensajes que se generan con la función del servidor Buzón de correo sólo contie- nen eventos de ENVÍO. TRANSFER Los destinatarios se han movido a un mensaje bifurcado debido a la conversión del contenido, los límites de destinatarios de mensajes o los agentes. Asimismo, los filtros de consultas más comunes son:  Recipients: campo de dirección del destinatario.  Sender: campo de remitente.  Server: servidor Exchange 2007 que contiene los registros de seguimiento de mensajes que se van a buscar.  EventID: Id. de evento, especificado en la tabla anterior.  MessageID: Id. de mensaje que se especifica en el encabezado Message- ID.  InternalMessageID: Id. de mensaje interno. Es un número entero identificador de mensaje que asigna el servidor de Exchange 2007 que está procesando el mensaje.  Subject: Asunto del mensaje.  Reference: (referencia) contiene información adicional para tipos de eventos específicos. Para un evento DSN, el campo de referencia contiene el MessageID: del mensaje que provocó el DSN. Para un evento SEND, el campo de referencia contiene el MessageID: de cualquier mensaje DSN. 211
  • 232. La protección de datos personales: Soluciones en entornos Microsoft Para un evento TRANSFER, el campo de referencia contiene el MessageID: del mensaje que se transfiere.  Inicio y Fin: intervalo de fecha y hora para buscar entradas de seguimien- to. De forma predeterminada, no se almacena ningún contenido de mensaje en el registro de seguimiento de mensajes; sin embargo, sí se almacena el asunto del mensaje. Es posible deshabilitar este registro si la organización lo requiere mediante el cmdlet de PowerShell Set-MailboxServer. Acceso a buzones e inicios de sesión Otra de las áreas de auditoría que se debe tener en cuenta es el acceso a los buzones que realizan los usuarios y los procesos de inicio de sesión, en los que se incluyen los inicios de sesión MAPI, POP e IMAP. Mediante el cmdlet de PowerShell get-mailboxstatistics se puede extraer informa- ción valiosa como el tamaño del buzón, el número de mensajes que contiene y la última vez que se inició sesión en él. Si se requiere tener una visualización en tiempo real de la actividad de los usuarios que se conectan vía MAPI a sus buzones, se pude descargar la herramienta Microsoft Exchange Server User Monitor desde http://www.microsoft.com/downloads/ details.aspx?FamilyID=9a49c22e-e0c7-4b7c-acef-729d48af7bc9&DisplayLang=en . Exchange: Exchange User Monitor. ExMon recopila de forma predeterminada información a intervalos de un minuto y se almacena en trazas de actividad en formato ETL (Event Trace Log) en el directorio de instalación de ExMon. Posteriormente se puede exportar la información contenida en la Traza de auditoría a un archivo de texto separado por comas (CSV) mediante línea de co- mandos con la propia utilidad Exmon.exe –SU. 212
  • 233. La aplicación del reglamento de seguridad en los sistemas Microsoft Pero ExMon sólo registra los accesos realizados mediante clientes MAPI. Para otro tipo de accesos como POP o IMAP, Exchange dispone de registros internos que se pueden habilitar. Por defecto, el registro de conexiones POP e IMAP está deshabilitado. Mientras que los accesos MAPI se realizan y se registran directamen- te en los servidores de buzones, los accesos POP e IMAP se realizan y se registran en los servidores de Acceso de Cliente (CAS). Para ello se deben modificar los siguien- tes archivos:  Microsoft.Exchange.Pop3.exe.config.  IMAP4 Microsoft.Exchange.Imap4.exe.config. Los dos archivos se encuentran en C:Archivos de programaMicrosoft Exchange ServerClientAccessPopImap. Se trata de dos archivos en formato XML que definen el comportamiento de cada uno de los protocolos a los que hacen referencia. Para habilitar el registro del protocolo se debe cambiar el valor de la entrada ProtocoLog de False a True. La información que se registra de los protocolos POP3 e IMAP4 se divide en campos separados por comas, e incluye los siguientes campos: Date-time La fecha y hora del evento del protocolo. El valor tiene la forma aaaa-mm-ddhh:mm:ss.fffZ, donde aaaa = año,  mm = mes,  dd = día, hh = hora,  mm = minuto,  ss = segundo,  fff = fracciones  de  segundo,  y  Z indica Zulú. Zulú es otra forma de indicar la Hora universal coordina- da (UTC). Connector-id Este campo no se usa en el registro de los protocolos POP3 e IMAP4. Session-id Un GUID que es exclusivo para cada sesión de SMTP, pero que es el mismo para cada evento que está asociado a la sesión de SMTP. Sequence-number Contador que se inicia en 0 y que aumenta para cada evento dentro de la misma sesión. Local-endpoint El extremo local de una sesión de POP3 o IMAP4. Se compone de una dirección IP y un número de puerto TCP que está formateado como <Dirección IP>:<puerto>. Remote-endpoint El extremo remoto de una sesión de POP3 o IMAP4. Se compone de una dirección IP y un número de puerto TCP que está formateado como <Dirección IP>:<puerto>. Evento Un único carácter que representa el evento del protocolo. Los valores posibles para el evento son los siguientes:  +  Conectar.  -   Desconectar.  >  Enviar. 213
  • 234. La protección de datos personales: Soluciones en entornos Microsoft  <  Recibir.  *  Información. Datos Información de texto asociada al evento de POP3 o IMAP4. Contexto No se usa en el registro de los protocolos POP3 e IMAP4. Otra posibilidad de registro de protocolo está disponible en los conectores de envío y recepción del protocolo SMTP. Por defecto, el registro del protocolo en dichos conectores está deshabilitado. El registro de protocolo graba las conversacio- nes del Protocolo simple de transferencia de correo (SMTP) que se producen entre servidores de correo electrónico como parte de la entrega de mensajes y se produce en los servidores de transporte de la organización. Tanto los clientes POP3/IMAP, los cuales envían sus mensajes a través de SMTP, como el transporte entre servidores, se registran habilitando el logging de los conectores. Los archivos del registro de protocolo se encuentran en las siguientes ubicaciones:  Archivos del registro de protocolo del conector de recepción: C:Archivos de programaMicrosoftExchange ServerTransportRolesLogsProtocolLogSmtpReceive.  Archivos del registro de protocolo del conector de envío: C:Archivos de programaMicrosoftExchange ServerTransportRolesLogsProtocolLogSmtpSend. Los archivos de registro de protocolos, tanto SMTP como POP3 e IMAP, son archivos de texto que contienen datos en el formato de valores separados por comas (CSV). Además, en cada servidor con la función de concentrador de transporte existe un conector de envío especial denominado conector de envío dentro de la organiza- ción. Este conector se crea implícitamente, es invisible y no necesita administración. El conector de envío dentro la organización se usa para retransmitir mensajes a los siguientes destinos:  A los demás servidores de transporte de concentradores de la organiza- ción de Exchange.  A servidores Exchange Server 2003 de la organización de Exchange.  A servidores de transporte perimetral de la organización de Exchange. De forma predeterminada, el registro de protocolo del conector de envío dentro de la organización también está deshabilitado. Con el cmdlet Set- TransportServer y el parámetro IntraOrgConnectorProtocolLoggingLevel, se habilita el registro de este conector de envío. El registro tendrá lugar en los registros de proto- colo del conector de envío que estén configurados en el servidor transporte de concentradores. 214
  • 235. La aplicación del reglamento de seguridad en los sistemas Microsoft 11.4.4. Artículo 104. Telecomunicaciones Cuando, conforme al artículo 81.3 deban implantarse las medidas de seguridad de nivel alto, la transmisión de datos de carácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros. Los planteamientos de seguridad, cuando se realiza una transmisión de datos, deben quedar también reflejados cuando se establecen los envíos de datos. Evitar que se puedan robar los datos en tránsito es algo complejo, pero sí se pueden disponer para que los datos queden cifrados y para cualquiera que pudiera robar- los, resulten totalmente ininteligibles. Windows Vista y Windows Server 2008 implementan una serie de mecanismos que va a hacer posible esos mecanismos de cifrado, pudiendo realizarse a diferentes niveles y en función de los elementos empleados. IPSEC, directiva de cifrado. En caso de cualquier tipo de comunicación, tanto a nivel local como en co- nexiones a través de Internet, los mecanismos de Seguridad IP (IPSEC) garantizan la integridad, la confidencialidad y la autentificación para los datos transmitidos. Enrutado como tráfico IP quedan establecidos los mecanismos de funcionamiento del sistema de seguridad mediante unas series de reglas y de filtros que son aplica- das mediante las directivas de seguridad, bien a nivel local o a través del dominio. Windows Vista y Windows Server 2008 utiliza 3DES como algoritmo de cifrado de datos. IPSEC implementa dos posibles mecanismos de seguridad: cabecera de auten- tificación (AH) y cabecera ESP (Encapsulation Security Payload). AH permite garantizar la integridad de los datos y la autentificación, aunque no va a garantizar que no se pueda ver el contenido de la transmisión. De cara a la 215
  • 236. La protección de datos personales: Soluciones en entornos Microsoft integridad de datos, el ICV (Integrity Check Value) se calcula mediante algoritmos SHA-1 y MD5. Los mecanismos de autentificación admiten el uso de Kerberos, mecanismos de PKI o claves compartidos. ESP garantiza la confidencialidad de los datos mediante algoritmos 3DES, aunque admite DES por compatibilidad. ESP puede combinarse con AH para establecer niveles más altos de seguridad, garantizando así el envío de datos al sistema correcto e impidiendo que si estos son modificados en tránsito sean admiti- dos como válidos. La funcionalidad de IPSEC entre dos máquinas quedará determi- nada por el proceso de negociación (ISAKMP) entre ambos sistemas, donde se establecen en función de las directivas, los mecanismos de autentificación, de firmado y de cifrado. IPSEC: captura de conversación sin IPsec. IPSEC: captura de conversación con IPsec. 216
  • 237. La aplicación del reglamento de seguridad en los sistemas Microsoft Este sistema de implementación es admitido entre sistemas independiente- mente de si pertenecen o no a un dominio, puesto que los mecanismos de autentifi- cación basados en secreto compartido o los de certificados permiten esa compatibili- dad. IPsec proporciona además mecanismos para el envío de datos en modo túnel que permiten el envío de datos cifrados entre redes a través de Internet, cifrando los datos únicamente en la parte pública de la comunicación. Aunque para los procedimientos de configuración de IPSec pueden utilizarse los mecanismos tradicionales de configuración, en las nuevas versiones de los sistemas operativos, esta funcionalidad queda integrada en el módulo de Firewall, con lo cual pueden combinarse ambas características para dar una mayor consisten- cia general en la seguridad. Por consiguiente, IPsec puede ganar las funcionalidades aportadas por el Firewall en las características avanzadas, como por ejemplo, determinar el comportamiento para el cifrado en base al tipo de red en el que pueda encontrarse la máquina: pública, privada o dominio. Además de los mecanismos de comunicación basados en IPsec, Windows Server 2008 soporta la funcionalidad de servidor VPN para establecer comunicacio- nes remotas a través de túneles de encapsulamiento en la capa 2 a través del Servi- cio NAS (Network Access Service) o bien la implementación con ISA Server 2006 de clientes VPN y conexiones entre sitios. Windows Server 2008 e ISA Server 2006 permiten implementar túneles de VPN mediante PPTP y L2TP. En el caso de L2TP, se utilizan las implementaciones de IPSEC para establecer un sistema de túneles mejorados, estableciendo de esta forma los túneles L2TP/IPSEC donde se utilizan los mecanismos de ESP como medida de seguridad. Windows Vista funciona como cliente VPN dentro de la arquitectura. VPN: propiedades de conexión. Un mecanismo adicional y complementario, sólo disponible en Windows Server 2008, permite garantizar el estado de salud de las máquinas, previniendo una posible intrusión de máquinas que no se encuentren dentro de unos criterios de 217
  • 238. La protección de datos personales: Soluciones en entornos Microsoft seguridad que haya establecido la organización. Este servicio, denominado NAP (Network Access Protection), implica una arquitectura cliente (Windows Vista, Windows XP SP3) y servidor (Windows Server 2008), donde basándose en unos diferentes patrones de control, se establece a través de diferentes servicios, entre los que figuran los Servicios NAS y de autenticación Wireless, si una máquina se incorpora a una red de cuarentena cuando no ha cumplido los criterios previamente establecidos. Las comunicaciones inalámbricas que cada vez están cobrando una importan- cia mayor, también permiten mecanismos de seguridad que permiten tanto el cifrado de los datos como garantizar los mecanismos de autentificación. Además de la adopción de mecanismos tipo WEP o WPA, Microsoft presenta dos soluciones de seguridad para estos tipos de redes:  Solución EAP-TLS donde se utilizan los mecanismos de certificados de clientes para autenticar clientes inalámbricos.  Solución PEAP donde se utilizan contraseñas y el protocolo de autentica- ción extensible protegido (PEAP) para autenticar clientes inalámbricos. Microsoft proporciona una guía para la implantación de sistemas de comuni- caciones seguros a través de redes inalámbricas. Dicha guía puede obtenerse en la siguiente URL: http://www.microsoft.com/spain/technet/security/guidance/cryptographyetc/ peap_1.mspx. 11.4.5. Confidencialidad en Exchange 2007 Cuando hablamos de confidencialidad en un sistema de mensajería, no sólo nos referimos a las conexiones, sino también al contenido de la transmisión y los propios mensajes. Bajo tal perspectiva, podemos definir confidencialidad como la característica que tiene un mensaje para que solamente sea leído por las personas o servicios autorizados. Si dicho mensaje pudiera ser leído o accedido en algún momento del transporte, depósito o con posterioridad, se estaría vulnerando su confidencialidad. Exchange Server 2007 proporciona tecnologías para mantener la confidencialidad de la información, las cuales van desde el establecimiento de conexiones seguras con TLS/SSL, hasta el soporte para formato S/MIME y gestión de derechos de información (WRM). Los permisos de acceso a los buzones en un organización Exchange Server 2007 preservan el derecho a la confidencialidad. Por defecto, sólo los propios usuarios pueden acceder a su buzón en donde se encuentran sus mensajes de correo electrónico. Ni siquiera el administrador del sistema tiene permisos establecidos para visualizar el contenido de los buzones de los usuarios. Si bien es cierto que dichos permisos se pueden modificar para ajustarse a las necesidades de cada organización, por ejemplo, la relación entre un director y su secretaria, este proceso para otorgar acceso a un buzón de otro usuario debe ser 218
  • 239. La aplicación del reglamento de seguridad en los sistemas Microsoft previamente solicitado y autorizado mediante un procedimiento oficial de la propia organización. A pesar de ello, la información como tal, por defecto no se almacena cifrada en las bases de datos de mensajes de los servidores Exchange. Resultaría una carga de trabajo adicional para los servidores si tuvieran que estar cifrando y descifrando continuamente el contenido de cientos o miles de usuarios de una organización. Es posible que no todos los usuarios requieran los mismos criterios de seguri- dad y confidencialidad. Para aquellos buzones sensibles, los cuales requieren medidas adicionales para preservar la confidencialidad, se puede implantar el formato S/MIME para cifrar los mensajes que se envían o reciben. Cuando un usuario envía un mensaje a otro destinatario en Internet, no puede controlar de qué forma se va a transmitir, ni si los canales de comunicación están cifrados o no. Ya sabemos que el transporte entre servidores Exchange dentro de la misma organización sí está cifrado por defecto; sin embargo, una vez que el mensa- je sale del servidor perimetral, no es posible saber de antemano cómo se transmitirá dicho mensaje. Por ello, el usuario que necesite un nivel de confidencialidad más alto, puede configurar su cliente de correo para que cifre el mensaje y se transmita cifrado independientemente del medio de transmisión. Para ello se requiere un certificado de cliente, emitido por una Entidad Certifi- cadora de confianza. El certificado se utilizará para firmar el mensaje con la clave privada del usuario y para descifrar los mensajes que le lleguen al usuario, los cuales deben haber sido cifrados con su clave pública por el remitente del mensaje. Tanto la firma digital como el cifrado de mensajes de correo electrónico mejo- ran la seguridad y la confidencialidad, ya que permite garantizar que el mensaje procede de quien dice ser (validación de firma) y que sólo lo podrá leer el destinata- rio del mensaje (cifrado). Respecto a este último punto, cabe señalar que el mensaje se guarda cifrado en la base de datos de buzones de Exchange y que sólo el usuario que posea el certifi- cado correspondiente con la clave privada podrá acceder a dicho mensaje. El proceso de cifrado y firma digital es el siguiente: Cifrado y firma digital de un mensaje de correo. 219
  • 240. La protección de datos personales: Soluciones en entornos Microsoft El proceso de descifrado y validación de la firma digital es el siguiente: Descifrado y comprobación de la firma digital. Una de las mejoras de S/MIME versión 3 que merece la pena destacar es el “triple envoltorio”. Un mensaje S/MIME con triple envoltorio es aquel que se firma, se cifra y se firma de nuevo. Este nivel adicional de cifrado proporciona un nivel adicional de seguridad. Cuando los usuarios firman y cifran mensajes con Outlook Web Access con el control S/MIME, el mensaje tiene triple envoltorio automáticamente. Outlook y Outlook Express no aplican triple envoltorio a los mensajes, pero pueden leer este tipo de mensajes. S/MIME es una tecnología estándar implantada en numerosos productos de mensajería; sin embargo, su principal debilidad es que la configuración de la seguridad recae en el usuario final. En muchas organizaciones, los usuarios no disponen de los conocimientos necesarios para identificar mensajes firmados de aquellos no firmados, para realizar una solicitud de certificado de usuario, o sim- plemente para hacer una gestión adecuada de los certificados digitales de sus contactos. Además, una desventaja clara de los mensajes cifrados desde el cliente es Correo cifrado mediante S-MIME. 220
  • 241. La aplicación del reglamento de seguridad en los sistemas Microsoft que no se pueden escanear para detectar virus o filtrar según el contenido del mensaje, y tal y como están las cosas con el SPAM hoy en día, esto puede ser un problema para algunas organizaciones. Es por ello que Exchange Server 2007 implanta un modelo nuevo de confiden- cialidad cuya responsabilidad recae en los servidores perimetrales y no en el usua- rio final. Dicho modelo se denomina Message Layer Security (Seguridad a nivel de mensajes), donde el servidor perimetral es el que se encarga de cifrar y firmar el mensaje antes de ser enviado al destinatario. Esta tecnología se apoya en claves públicas y privadas. Las claves públicas se publican en los servidores DNS, desde donde se consultan por parte de los servidores destinatarios. El modelo es muy similar a S/MIME, con la diferencia que todo el trabajo se realiza en el perímetro. Debido a que el remitente debe autenticarse para poder enviar el mensaje hacia Internet, el servidor perimetral es capaz de garantizar la autenticidad del remitente. Cuando el destinatario abra el mensaje, desde OWA u Outlook 2007, se mostrará un mensaje indicando que se ha transmitido de forma segura entre organi- zaciones Exchange Server 2007 y que la autenticidad ha sido comprobada. Proceso de transporte con MLS. Además, aquellas organizaciones con versiones anteriores de Exchange o incluso aplicaciones de mensajería diferentes, si tienen el soporte para TLS habilita- do, ahora los servidores perimetrales de Exchange Server 2007 van a iniciar una conexión TLS predeterminada para la transmisión de los mensajes de correo. Esta mejora se denomina Oportunistic TLS (TLS Oportunista). Por tanto, se garantiza la confidencialidad del mensaje mientras viaja por Internet, incluso entre organizacio- nes que no tienen ningún tipo de relación, asegurando de esta forma que el inter- cambio externo de correo con datos de carácter personal conserve ese nivel de segu- ridad exigido por el Reglamento de Medidas de Seguridad que desarrolla la LOPD. 221
  • 242. La protección de datos personales: Soluciones en entornos Microsoft 222
  • 243. 12 La aplicación del reglamento de seguridad en SQL Server 12.1. Artículo 91. Control de acceso En el caso de SQL Server, podemos especificar la seguridad de control de acceso a nivel de cada uno de los objetos dentro de una base datos, llegando incluso a nivel de detalle de columna. El proceso de control de acceso en SQL Server se divide en dos pasos: 1. En primer lugar, el usuario inicia una sesión en la instancia de SQL Server, para lo cual debe disponer de un inicio de sesión asignado, como veremos en la sección de autenticación. Una vez conectado a la instancia, el usuario accederá a una determinada base de datos dentro de esa instancia, para lo cual, su inicio de sesión tendrá que tener asociado un usuario en esa base de datos. En el caso de que el inicio de sesión no tenga un usuario de base de datos asociado, SQL Server buscará si existe el usuario guest, que es el usuario invitado de SQL Server. SQL Server no crea el usuario guest de forma predeterminada, y no se considera buena práctica su utilización. A través de este funcionamiento, ya nos aseguramos de que los usuarios tan solo podrán acceder a aquellas bases de datos a las que específicamente les proporcionemos acceso. 2. Una vez que el usuario tiene acceso a una determinada base de datos, cada vez que ejecute una sentencia en esa base de datos se comprobarán los permisos de que dispone el usuario para asegurarse de que dispone de los permisos necesarios para su ejecución. Como se puede apreciar en la figura, podemos asignar permisos a los usuarios desde las propiedades 223
  • 244. La protección de datos personales: Soluciones en entornos Microsoft del objeto en cuestión o desde las propiedades del usuario, para cada una de las operaciones, o bien podemos denegar ese permiso. Al mismo tiempo, podemos ver no solo los permisos específicos asignados a ese usuario, sino también los permisos efectivos por pertenencia a grupos (funciones o roles en la terminología de SQL Server). Control de acceso a bases de datos. Todas estas operaciones pueden realizarse también utilizando sentencias Transact-SQL, de modo que podamos generar scripts para asignación de permisos que sean fáciles de reutilizar. Asignación de permisos a usuarios de bases de datos. 224
  • 245. La aplicación del reglamento de seguridad en SQL Server Como hemos comentado anteriormente, desde las propiedades de un objeto o usuario podemos obtener información acerca de los permisos específicos de esos usuarios sobre los objetos, y del mismo modo, desde las propiedades de un usuario podemos obtener información sobre los permisos específicos de dicho usuario sobre un determinado objeto. A través de la pertenencia a determinados roles de servidor, concretamente sysadmin y securityadmin, podemos controlar qué inicios de sesión pueden cambiar las configuraciones de seguridad y otorgar o denegar acceso a determinadas bases de datos. A nivel ya de base de datos, disponemos de las funciones db_accessadmin, db_securityadmin y db_owner, que nos permiten controlar qué usuarios tienen privilegios para cambiar los permisos de los objetos de cada base de datos. Del mismo modo, cuando se asigna un permiso a un determinado usuario, disponemos de la opción WITH GRANT, a través de la cual, no sólo otorga- mos el permiso al usuario, sino que le proporcionamos también la posibilidad de otorgar esos permisos a otros usuarios. 12.2. Artículo 93. Identificación y autenticación Para gestionar la autenticación de usuarios a las instancias de SQL Server, podemos utilizar dos mecanismos de autenticación: 1. Autenticación de Windows. En este caso, tan solo se permite acceso a la instancia de SQL Server a usuarios previamente autenticados a nivel del sistema operativo. SQL Server no se encarga de validar la contraseña del usuario, tan solo revisa en la tabla de inicios de sesión si le hemos otorga- do acceso a dicho usuario Windows a la instancia de SQL Server. Es el mecanismo recomendado, puesto que no viajan contraseñas, ni se almace- nan en SQL Server, y podemos reutilizar todos los mecanismos comenta- dos sobre la autenticación y gestión de usuarios a nivel del sistema opera- tivo Windows. 2. Autenticación mixta. En algunos escenarios, por ejemplo cuando tenga- mos clientes que no sean Windows o no formen parte de nuestro dominio, debemos emplear la autenticación mixta. En esta configuración, además de usuarios del sistema operativo, podemos crear inicios de sesión especí- ficos de SQL Server, a los que deberemos asignarles una contraseña. El mecanismo de autenticación predeterminado en la instalación, y recomen- dado, es la Autenticación Windows. De este modo, podemos reutilizar todas las funcionalidades de seguridad que el sistema operativo Windows proporciona a sus cuentas, y SQL Server no necesita almacenar dichas cuentas ni sus contraseñas. En aquellos escenarios de autenticación mixta, en los que creemos inicios de sesión de SQL Server, disponemos de mecanismos para hacer que el usuario modifique la contraseña en su primer inicio de sesión. Lo que SQL Server almacena de estas contraseñas es su Hash, no se almacenan en texto plano, de modo que disponemos de mecanismos para asegurar su confidencialidad e integridad, puesto que SQL Server cifra los inicios de sesión de estos usuarios, por lo que también viajan prote- gidos por la red. 225
  • 246. La protección de datos personales: Soluciones en entornos Microsoft Selección del mecanismo de autenticación. Tal y como acabamos de comentar en el apartado anterior, SQL Server almace- na el Hash de las contraseñas, por lo que éstas son ininteligibles. Del mismo modo, cuando creamos inicios de sesión de SQL Server, en una configuración de autentica- ción mixta, podemos configurar sobre estos inicios de sesión las siguientes opciones: 1. Forzar la política de contraseña. Seleccionando esta opción, nos asegura- mos de que SQL Server aplicará la misma configuración de política de contraseña que la configurada a nivel del sistema operativo. 2. Forzar caducidad de contraseña. Al igual que en el apartado anterior, seleccionando esta opción, SQL Server aplicará la política de caducidad de contraseña configurada a nivel del sistema operativo del servidor en el que esté instalado SQL Server. A través de estas dos opciones, disponibles desde SQL Server 2005, podemos aplicar un mayor nivel de seguridad que nos permita controlar los inicios de sesión de SQL Server. 12.3. Artículo 94. Copias de respaldo y recuperación SQL Server dispone de mecanismos de control que permiten proteger la información almacenada en sus bases de datos, además de capacidades de copia de seguridad y restauración. El primero de estos mecanismos es el denominado Mode- lo de recuperación. SQL Server mantiene un registro de transacciones por cada una de las bases de datos, en el que se registran las operaciones realizadas con los datos de esa base de datos. EL Modelo de recuperación especifica las operaciones que se registran en dicho log de transacciones y cómo se registran. Disponemos de tres opciones de configuración: 226
  • 247. La aplicación del reglamento de seguridad en SQL Server Configuración de las opciones de política de cuenta y contraseña. 1. Simple. En el modo de recuperación simple, SQL Server registra mínimamente determinadas operaciones, y trunca el registro de transac- ciones después de cada Checkpoint. Esta configuración está recomendada, en principio, sólo para escenarios de pruebas o desarrollo, puesto que en esta configuración no podremos realizar copias de seguridad del registro de transacciones. 2. Carga masiva. Es un modelo de recuperación que se considera temporal, y está pensado para aquellos escenarios en los que, teniendo configurado un modelo de recuperación completo, queremos optimizar un proceso de carga masiva de registros, registrando mínimamente esa operación. 3. Completo. Es el modelo predeterminado y el recomendado para las bases de datos en producción. En este modelo de recuperación, todas las tran- sacciones se registran completamente en el log de transacciones, y el log no se trunca en ningún momento. Este modelo nos añade una tarea adicional de mantenimiento para el registro de transacciones, puesto que debemos asegurarnos de que se trunca en algún momento, idealmente, cuando realicemos copia de seguridad del mismo, tal y como comentare- mos a continuación. Los cambios de un modelo de recuperación a otro, pueden realizarse en caliente en cualquier momento, desde las propiedades de la base de datos o me- diante el comando ALTER DATABASE. Sin embargo, se aconseja realizar una copia de seguridad, antes y después de realizado el cambio, para asegurarnos de no romper la secuencia de copias de seguridad. Por lo que respecta a los tipos de copias de seguridad, SQL Server proporciona los siguientes tipos: 227
  • 248. La protección de datos personales: Soluciones en entornos Microsoft Modelo de recuperación de base de datos. 1. Completa. En una copia de seguridad completa, SQL Server realiza copia de seguridad de todo el contenido de la base de datos, incluido el registro de transacciones. Además, como la copia de seguridad es una operación que puede realizarse en línea, mientras otros usuarios están trabajando con los datos, SQL Server realiza copia de la parte activa del registro de transacciones, por lo que la copia de seguridad contendrá las operaciones realizadas durante la copia de seguridad. 2. Diferencial. Tomando como base una copia completa, SQL Server recorre las cabeceras de los ficheros en busca del mapa de páginas que marca las extensiones que se han modificado desde la copia completa. Asimismo, como ocurría con la copia completa, se copia la parte activa del registro de transacciones, que contendrá las operaciones realizadas durante el proce- so de copia de seguridad diferencial. 3. Registro de transacciones. Realiza copia de seguridad del registro de transacciones, desde una copia completa o desde la anterior copia del registro de transacciones. 4. Copia de seguridad de ficheros o grupos de ficheros. Nos proporciona la posibilidad de realizar copias de seguridad sólo de determinados ficheros o grupos de ficheros de la base de datos. Estos diferentes tipos de copias de seguridad nos proporcionan la flexibilidad suficiente como para crear un plan de copias de seguridad que cumpla con los requisitos tanto funcionales como legales, por muy complicado que sea el entorno de trabajo. 228
  • 249. La aplicación del reglamento de seguridad en SQL Server A la hora de realizar la restauración de estas copias de seguridad, debemos tener en cuenta que: 1. Las copias de seguridad completas, diferenciales y del registro de transac- ciones nos permiten realizar una restauración a un punto determinado del tiempo. Esta característica es útil en aquellos escenarios en los que se ha detectado una operación no deseada que no queremos que se restaure. En estos casos, podemos incluso realizar la copia de seguridad después de realizada la operación y detener la restauración en el momento anterior a dicha operación. 2. En la versión empresarial de SQL Server, también las restauraciones pueden ser parciales. Para que una base de datos SQL Server pueda ser abierta, la instancia de SQL Server debe tener acceso al fichero .mdf y al registro de transacciones. En aquellos escenarios en los que disponemos de varios grupos de ficheros para organizar los archivos de datos, pode- mos ir restaurando parcialmente dichos grupos de ficheros, de modo que vayamos poniendo a disposición de las aplicaciones y usuarios aquellas partes más críticas. Esta característica permite reducir el tiempo de parada en escenarios de bases de datos de gran tamaño. Restauración de la base de datos. 12.4. Artículo 98. Identificación y autenticación Tal y como hemos mencionado, disponemos de la opción, a nivel de inicio de sesión, de hacer que SQL Server aplique las políticas de cuentas de Windows a los inicios de sesión de SQL Server. 229
  • 250. La protección de datos personales: Soluciones en entornos Microsoft 12.5. Artículo 101. Gestión y distribución de soportes Existen diferentes mecanismos que nos permiten distribuir la información de bases de datos, tales como copia de seguridad y restauración, o la des-asociación y asociación de bases de datos entre instancias. En SQL Server 2008 disponemos de una nueva funcionalidad, denominada Cifrado Transparente de Datos (TDE según sus iniciales en inglés), que nos permite cifrar todos los ficheros de una base de datos. Cuando tenemos habilitada esta opción, SQL Server no sólo cifra los ficheros de base de datos, sino que si realizamos una copia de seguridad, esta última tam- bién se cifra, quedando protegida. Del mismo modo, al realizarse el cifrado a nivel de entrada/salida a disco, si desasociamos la base de datos, esos ficheros permane- cerán cifrados, por lo que si distribuimos esa base de datos en algún soporte, esos datos irán cifrados. Activación del cifrado a nivel de base de datos. A la hora de configurar este cifrado transparente deberemos especificar lo siguiente: 1. El algoritmo de cifrado que deseamos utilizar. Disponemos de las siguien- tes opciones:  AES 128.  AES 192.  AES 256.  TRIPLE DES. 2. Mecanismo que deseamos utilizar para dicho cifrado. Podemos utilizar bien un certificado de servidor o bien una clave asimétrica. En ambos 230
  • 251. La aplicación del reglamento de seguridad en SQL Server casos, debemos crear esos objetos en nuestra instancia SQL Server antes de configurar el cifrado. A partir del momento en el que configuremos el cifrado, SQL cifrará y desci- frará el contenido de los ficheros de base de datos (tanto de datos, como de registro de transacciones) en cada operación de lectura y escritura. 12.6. Artículo 103. Registro de accesos A la hora de disponer de un registro de los accesos a una base de datos de SQL Server 2008, disponemos de diferentes mecanismos para obtener dicha información: 1. Utilizando trazas de SQL Server Profiler. Es la más antigua de las opcio- nes, puesto que existe desde las primeras versiones de SQL Server, y nos proporciona la posibilidad de capturar cualquier sentencia que se envíe a una instancia de SQL Server. 2. Captura de datos modificados. La Captura de datos modificados (Change Data Capture) es una de las novedades introducidas por SQL Server 2008, y nos permite llevar un control de todos los cambios realizados en aque- llas tablas que configuremos. La principal restricción de esta opción es que sólo podemos controlar las transacciones ejecutadas, no las consultas a los datos. 3. Auditoría. Probablemente es una de las características más demandadas por los profesionales de bases de datos y que aparece en SQL Server 2008 para permitirnos la auditoría en instancias de SQL Server 2008 y que analizaremos a continuación. 12.6.1. Auditoría en SQL Server 2008 Para configurar la auditoría, en primer lugar debemos crear un objeto Auditoría, tal y como muestra la Figura 8. Básicamente definiremos el destino de la auditoría (Fichero, Registro de seguridad o Registro de aplicación) y cómo SQL Server gestionará los tamaños de la auditoría. Deberemos de asegurarnos de habili- tar el objeto Auditoría, antes de poder utilizarlo, puesto que por defecto, estos objetos se crean deshabilitados. Una vez definida la auditoría, deberemos crear la Especificación de la auditoría, en la que básicamente configuraremos cuáles son los eventos que desea- mos auditar. Llegados a este punto, podemos crear especificaciones a nivel de instancia de SQL Server, para aquellos eventos que se generen a ese nivel, tales como inicios de sesión, por ejemplo; o a nivel de base de datos, para los eventos que ocurren dentro de cada base de datos, tales como los accesos a los datos. Estas especificaciones, a nivel de base de datos, son las que nos interesan en este caso. Para crear dicha especificación, deberemos acceder a la carpeta Especificaciones de auditoría de base de datos, dentro de la carpeta Seguridad de la base de datos, tal y 231
  • 252. La protección de datos personales: Soluciones en entornos Microsoft Creación de un objeto Auditoría. como podemos apreciar en la primera figura de la siguiente página. En esta especi- ficación debemos configurar lo siguiente: 1. La auditoría en la que almacenaremos el resultado de la especificación. 2. El tipo de acción a auditar, tal como SELECT, UPDATE o DELETE. 3. El objeto, esquema o base de datos, sobre el que queremos aplicar la especificación. 4. La entidad (usuario o rol) que deseamos auditar. Al igual que ocurría con las auditorías, debemos habilitar la especificación para que entre en funcionamiento. A partir de ese momento, se irán registrando las acciones auditadas en el destino seleccionado en la auditoría. Si hemos configurado que la auditoría almacene los datos en fichero, podremos acceder al contenido del mismo a través de la función sys.fn_get_audit_file(), por ejemplo: SELECT * FROM sys.fn_get_audit_file (‘C:TempAudit_Test_E5CF6565-8052-46C3-A8D4- 51D26698F5B5_0_128640862326190000.sqlaudit’,DEFAULT,DEFAULT) 12.7. Artículo 104. Telecomunicaciones En el caso de que realicemos el acceso a datos de carácter personal de nivel alto y almacenados en SQL Server a través de una red pública, deberemos configu- rar el cifrado de dichas comunicaciones, puesto que de forma predeterminada SQL Server tan sólo cifra los inicios de sesión de los usuarios, pero no las comunicacio- 232
  • 253. La aplicación del reglamento de seguridad en SQL Se