5.1. Gestió de riscos de les infraestructures tècniques¶

Pàgina web amb informació important sobre seguretat i gestió de riscos: https://www.incibe.es/ciberseguridad/empresas/

Aquest document respon a les preguntes del TDR Checklist for Repository,

5.1.1. El dipòsit ha d'identificar i gestionar els riscos¶

El DDD està format per:

• Dos servidors HP Proliant, un de producció i un de pràcticament idèntic per proves, descrits a HardwareDDD. Es van renovant seguint quan diferents indicadors de preu de manteniment, obsolescència tecnològica o rendiment, aconsellen. La darrera actualització és del 2016.

Hi ha contracte de manteniment per a les dues màquines, amb una prestació de 24x7, amb número de peticions de servei il·limitat i un temps de resposta per l'assistència de 4 hores, inclou peces i materials. Per al programari hi ha un contracte de manteniment amb cobertura 24x7 i temps de resposta telefònica de 2 hores, el número de peticions de servei és il·limitat.

• Una porció del servidor de disc corporatiu (SAN/NAS, també conegut com a Clariion), on s'allotgen els documents (PDFs o JPEGs), i que al 2016 és de 650 GB. S'estableix un contracte de manteniment per als anys 2015-2018.
• Dos armaris de disc, VNX 5300, pels originals de les digitalitzacions retrospectives, detallats a HardwareDDD. La capacitat útil actual és de 23 TB.
• Dos armaris de disc com a còpia de seguretat dels originals de les digitalitzacions retrospectives, detallats a SataBeast. No hi ha contractat manteniment dels Satabeasts. La compra inicial va ser el gener del 2008 i s'han fet successives ampliacions fins el març del 2010. La capacitat útil actual és de 22,4 TB.

La decisió de renovar es fa en base a diferents indicadors, com ara l’obsolescència tecnològica, l’increment del cost de manteniment, la baixada dels indicadors de rendiment, etc

EL 31 d’octubre de 2014 s’ha ampliat la connexió que la Universitat Autònoma de Barcelona (UAB) té a l’Anella Científica, passant d’1 a 2 Gbps. Dades de l'Anella Científica http://www.catnix.net/ca/estadistiques/. Al novembre del 2016 es va ampliar a 5 GB (https://blog.csuc.cat/?p=8809).

Estat del tràfec de la xarxa ('weathermap')
http://monitor.uab.es/monitor/xarxa/weathermap/

Monitorització del Trafec de Sortida
http://monitor.uab.es/monitor/xarxa/hsrp.html

El programari més rellevant utilitzat per al DDD és:

• Aplicació de repositoris, Invenio, versió 1.1.6 (http://invenio-software.org/).
• Servidor de web Apache, actualment versió 2.4 (http://www.apache.org/).
• Servidor de bases de dades MariaDB (https://mariadb.org/).
• Llenguatge de programació Python.
• Utilitats vàries de conversió i manipulació dels documents: xpdf i mupdf per als documents PDF, LibreOffice per als documents ofimàtics, ImageMagick per a les imatge, JHove per a l'extracció de metadades tècniques dels documents.

Pel que fa a l'aplicació específica, Invenio, hi ha varis canals de suport:

• Un contracte signat amb el CERN per a suport a la UAB amb un cost fix anual. El document està adjunt a aquesta pàgina amb el nom invenio-cern-uab_a2011m3d22.pdf
• Llistes de correu públiques (https://www.mail-archive.com/project-invenio-general@cern.ch/ i http://www.mail-archive.com/project-invenio-devel@cern.ch/).
• Gestor de tasques a Github (https://github.com/inveniosoftware/invenio/issues)

5.1.1.1. S'ha d'utilitzar tecnologia de monitorització¶

A través del Centreon (https://centreon.uab.es) es monitoritza el servidor del DDD i el servidor de consulta.

La monitorització de l'obsolescència de programari i maquinari es basa en l'indicador de rendiment i el cost del servei de manteniment; pel que fa al programari es segueixen les indicacions del Cern en quan a noves versions.

Les alertes es registren a Remedy (https://sdesk.uab.es:8443/arsys/shared/login.jsp?/arsys/forms/sdesk/SRS:ServiceRequestConsole/), l’equip d’Altran revisa les incidències generades des de monitorització i resolen segons prioritat dins del SLA (nivell de servei) pactat.

Les noves versions del d'Invenio s'anuncien a través de llistes de correu. Les funcionalitats de les noves versions es publiquen a Github (https://github.com/inveniosoftware/invenio/milestones), tot i que encara hi ha informació a l'antiga web (http://invenio-software.org/)

5.1.1.2. El dipòsit ha de tenir maquinari i programari adequat per a les còpies de seguretat i pel seguiment de les activitats¶

Per al DDD, com a dipòsit institucional de consulta, es fan diferents tipus de còpies de seguretat:

1. Les genèriques que es fan a tots els servidors de la UAB. Aquests backups permeterien recuperar els servidors i deixar-los tal qual estaven abans de l'hipotètic desastre: l'estat complet de tot el programari (des del sistema operatiu fins a totes les utilitats i aplicacions, i les modificiacions específiques de la UAB, i els scripts particulars de DDD), les seves configuracions (incloses les contrasenyes), bases de dades (metadades, usuaris, estadístiques, permisos, rols, alertes creades, definicions de col·leccions), fitxers de log, i documents del DDD (fitxers, miniaturies, metadades tècniques, etc.). A la seva vegada, cal diferenciar els dos tipus de còpies, la dels documents (el disc compartit Clariion) i els discs locals del servidor.

L'horari i calendaris del disc compartit Clariion, on es desen els documents del DDD és:

a. Total el dissabte.
b. Incremental diari, de nit.
c. Retenció de 2 mesos en local, que vol dir que durant dos mesos es pot recuperar fitxers de qualsevol de les còpies de seguretat dels darrers dos mesos.

Pel que fa als discs locals del servidor, la política és la mateixa, llevat que la còpia total es fa el divendres.

El procediment de backup general per a tots els serveis de la UAB consisteix en fer la primera còpia a disc, que és més ràpida i permet un accés immediat en cas de recuperació de fitxers esborrats el dia anterior. El dispositiu és un EMC Datadomain 2500, ubicat a la Sala CPD, Edifici D (Sala de màquines del Servei d'Informàtica).

Un cop al mes, de la darrera còpia local a disc se'n fan còpies a cintes LTO-6 i es desa fora de la UAB per part de l'empresa EID Seguridad de Contenidos. No hi ha una cinta pròpia pel DDD. Tota la documentació sobre el backup està al servei Nebula (site de Producció):

2. A més a més, per al DDD es fa una còpia de seguretat que consisteix en desar-ne totes les versions històriques, el que es coneix com a control de versions. A la seva vegada, són de dos tipus: un, dels registres Marc21, amb tots els seus canvis, i l'altre dels documents (fitxers), amb tots els seus canvis. El programari que fem servir per a gestionar el control és git (http://git-scm.com/), segurament el més conegut i potent, creat per a gestionar el codi font del sistema operatiu Linux. Els fitxers resultants d'aquest emmagatzemament del control de versions es guarden diàriament, al Volum 2, després es fa una còpia conjunta setmanal (els divendres al vespre) i finalment durant tot el dia de dissabte es comprimeix aquesta còpia. Amb aquest control de versions podem saber com estava o retornar a qualsevol versió del fitxer o de les dades dels darrers 5 anys. De tots dos tipus se'n fa còpia amb el procés de backup habitual, genèric de la UAB perquè s'ha demanat específicament a explotació recollir el disc del Volum 2 anomenat 'historic' (/mnt/VOLUM-2/historic/ddd/ddd-docs.git).

3. Finalment, per al dipòsit dels originals en alta resolució de les digitalitzacions, i altres originals que no són d'accés públic, pel seu volum (uns 22 TB l'any 2016), i pel seu contingut majoritàriament estàtic i amb un creixement esporàdic (no continu) no es poden seguir les mateixes polítiques de backup que la resta del sistema, sinó que apliquem aquestes:

• Hi ha dos armaris de discs redundants, VNX i SataBeast, i una fa de còpia de seguretat de l'altra. Els discs estan en RAID6, és a dir, hi ha dos discs de paritat dels principals, és a dir, que se'n poden fer malbé fins a un màxim de dos simultàniament i el sistema funciona amb normalitat.
• Igual que en el Clariion, els fitxers d'aquests discs estan protegits contra l'escriptura. Però a més a més, els propis discs d'aquesta segona còpia estan permanentment modus només de lectura, és a dir, protegits contra l'escriptura i l'esborrat, accidental o voluntari.
• Tampoc no hi ha control de versions. El motiu és que qualsevol control de versions implica, com a mínim, una còpia (segurament comprimida i en un format específic) dels fitxers versionats. Pel propi tamany del dipòsit de digitalització no és possible fer-ho, si més no amb la mateixa eina (git) que per al dipòsit institucional (Clariion). De fet, és en un disc del VNX i un altre del Satabeast on s'allotgen còpies del control de versions del Clariion.
• El que sí que hi ha, en la majoria dels casos, és un fitxer de paritat par2 (vegeu https://en.wikipedia.org/wiki/Parchive) que permet recuperar fins a un 10% d'errors, en cas que el fitxer s'hagi corromput. La creació de fitxers de paritat el fem directori a directori, a mesura que el contingut queda endreçat. Aquests fitxers de paritat funcionen com una tercera còpia en cas que de la segona no se'n pugui recuperar un fitxer fet malbé. Hem provat que funciona, i ho fa correctament, tot i que no ens ha calgut posar-ho en pràctica mai.

Des de finals del 2018 (#4843) ja s'estan enviant còpies fora de la UAB de la versió jpeg dels documents que hem digitalitzat en tiff.

5.1.1.3. S'ha de comptar amb mecanismes eficaços per detectar la corrupció o la pèrdua de bits¶

Un primer sistema bàsic de protecció consisteix en canviar els permisos de tots els fitxers a només lectura, de manera que no es poden esborrar o sobreescriure accidentalment.

A través del control de versions al Dipòsit Institucional (Clariion) sí que hi ha un control rígid del checksum i dóna una alarma en cas que hi hagi una variació. El control es fa setmanalment, quan es compacten els canvis, i un cop al mes quan es comproven sistemàticament els checksums de tots els fitxers, utilitzant l'algoritme sha1. Els errors arriben a l'administrador de l'aplicació (Ferran). Fa alguns anys n'havien saltat alguns, però era per manca d'experiència en el programari, i quan aquest era menys madur.

Pel que fa als Dipòsits de digitalització (Volums 2 i 3) el control no es fa de manera sistemàtica però sí esporàdicament quan s'han de moure grans quantitats de fitxers.

De tota manera, en cap dels dos casos, i ni tan sols dels documents migrats de sistemes anteriors (Decomate o l'antiga Web de biblioteques), mai no ens hem trobat ni un sol cas d'error de checksum, en els 1,2 milions de fitxers monitoritzats.

5.1.1.4. S'han de registrar actuacions de millora en quant a seguretat¶

En el cas del programari Invenio es fa un seguiment de les noves versions i s'instal·la la penúltima. L'actualització es programa amb el Servei de Biblioteques i es pacten els calendaris.

El programari de Debian s'actualitza automàticament sempre que hi ha alguna nova versió disponible i amb ell tots els programes que queden per les capes inferiors.

5.1.1.5. Identificar i documentar els processos d'emmagatzematge i canvis de maquinari o programari en un entorn de proves¶

L'entorn de proves del Dipòsit institucional és el ddd-test, https://ddd-test.uab.cat/

5.1.1.6. Identificar i documentar els processos crítics¶

Els processos crítics pel Servei de Biblioteques serien:
1. La consulta per usuaris externs
2. L'alimentació per usuaris interns des de formularis o des d'Ein@
3. L'elaboració de les còpies de seguretat

La consulta es garanteix, entre altres, comprovant que el servidor Apache respongui bé a les peticions. Quan hi ha sobrecàrregues, accidentals o provocades, el servidor pot deixar de respondre, o enlentir-se d'una manera que el fa inaccessible. Són els casos coneguts com atac de denegació de servei, o variants com Slow Loris. Per solucionar-ho, cada 10 minuts es comprova que el número de peticions simultànies no sobrepassi d'un límit configurable (per exemple, 300), i si el sobrepassa, reinicia el servei.

Monitorització / comprovació de les còpies de seguretat

a. Registre a Remedy d’incidències derivades dels Backup, amb revisió diària. El registre és automàtic i es genera a partir dels logs del servidor de Backup i del propi software de Backup (legato).
b. Log/resum diari dels Backup al portal “uabentory”. Tant el Centreon (Nagios) com l’uabentory té una part pública, el responsable del servei pot sol·licitar accés als indicadors que necessiti per el seguiment del seu servei.

L'empresa Altran, que monitoritza els servidors de la UAB, també, si es dóna el cas, avisa personalment o per correu a l'administrador de l'aplicació (Ferran).

El temps de restauració en cas de desastre (RTO) i el període màxim en que es perdrien dades en cas de desastre (RPO) no estan definits. Es fan recuperacions sota demanda.

5.1.2. Gestionar el nombre i la ubicació de les còpies dels objectes digitals¶

En quant al backup a disc, el dispositiu es EMC DATADOMAIN 2500. El Datadomain està ubicat a la Sala CPD, Edifici D (Sala de màquines del Servei d'Informàtica).

Al dipòsit de digitalització tindríem els fitxers als Volums 2 i 3, i les còpies al Volum-I i Volum-Ib respectivament, situades al mateix lloc físicament. El Dipòsit de digitalització (Volums 2 i 3) no fa una sincronització automàtica de la còpia amb el SataBeast sinó que es realitza de manera manual quan hi ha canvis o introducció de nous documents o col·leccions. Generalment activa aquesta còpia el Ferran de manera manual, i decideix com i quan és millor per a la seguretat o integritat dels documents; si les còpies fossin automàtiques els discos dels volums 2 i 3 estarien en 'modus captura' (sense protecció) massa sovint.

5.2. Gestió dels riscos de seguretat¶

5.2.1. El dipòsit mantindrà un anàlisi sistemàtic dels factors de risc de seguretat associats a dades, sistemes i personal¶

L'ENS donarà al Servei d'Informàtica un anàlisi dels riscos genèrics a nivell de tota la universitat. S’ha fet el pla d’adequació a nivell de tota la UAB, però està pendent d’execució. El DDD va fer un anàlisi amb l'ENS al 2014.

5.2.2. Implementar controls per tractar adequadament cada risc de seguretat definit¶

Les mesures de seguretat correctores o preventives són:

• Protecció d'instal·lacions i infraestructures. Identificació del personal que accedeix a l'edifici del Servei d'Informàtica o a la sala de màquines. Identificació dels administradors o gestió dels rols o privilegis de cada usuari al DDD.
• La gestió del personal obliga a realitzar accions de formació continuada.
• Establir una política de gestió de les contrasenyes i adoptar un sistema d'identificació segur. L'anàlisi de riscos fet amb l'ENS va detectar que en el cas del DDD hi havia un punt feble relacionat amb el canvi de contrasenyes i autorització d'usuaris i es va solucionar afegint una nota en el registre al dipòsit (https://ddd.uab.cat/youraccount/register); amb la identificació per LDAP els usuaris utilitzen les contrasenyes i identificadors propis del campus i la seva normativa ( http://www.uab.cat/doc/TR_normativa_TIC ; Capítol III. Responsabilitats de les persones usuàries).
• La protecció de les dades inclou la política de les còpies de seguretat.
• La protecció dels equips tindria una part relacionada amb la protecció de les instal·lacions, però també ho està amb la disponibilitat de les màquines. Les actualitzacions de programari cal que es facin sempre en un entorn de proves.
• El maquinari també ha de estar protegit d'atacs externs, amb tallafocs i sistemes antivirus.

5.2.3. El personal té rols definits, responsabilitats i autoritzacions relacionades amb l'aplicació de canvis al sistema¶

Tot el personal del Servei de Biblioteques és responsable de crear i mantenir registres bibliogràfics, així com de conservar la documentació relativa al DDD que sigui necessària, autoritzacions, convenis, documentació de treball...

És responsabilitat de la Cap de la Unitat Tècnica i de Projectes coordinar-se amb els serveis informàtics de la UAB i del Consorci de Serveis Universitaris de Catalunya (CSUC) per assegurar el correcte funcionament dels recursos d’informació.

És responsabilitat de la Gestora de Serveis d’Informació assegurar la difusió de la normativa de dipòsits digitals aplicable entre tot el personal implicat, així com assignar i fer el manteniment dels rols d’entrada als formularis i edició de metadades.

La Gestora de Serveis d’Informació i el tècnic de projectes del Servei d'Informàtica actuant com a administradors de la interfície web de consulta, amb la possibilitat de generar noves col·leccions, aplicar CSS, fer tasques de recol·lecció, crear o modificar formularis d'entrada de dades...

El personal del Servei de Biblioteques és responsable de fer un us adequat del seu usuari i la seva contrasenya d'entrada. Una persona assignada per cada biblioteca tindrà els permisos per modificar, renombrar o moure fitxers directament.

El personal docent i investigador (PDI) és responsable de fer un us adequat dels seus permisos d'introducció de documents al DDD, i en garanteix la seva autenticitat.

5.2.4. Preparació en cas de desastres i pla de recuperació¶

Les amenaces identificades i les mesures preses són:

• Fallada del suport. Còpies de seguretat especificades en aquesta mateixa pàgina.
• Fallada del maquinari. Contracte de manteniment 24x7
• Fallada del programari. Contracte amb el CERN.
• Errors en les comunicacions. Prestació de servei del Servei d'Informàtica. Hi ha dos ports aturats per si algun dels que està actiu s'espatlla.
• Fallada dels serveis de xarxa. Prestació de servei del Servei d'Informàtica.
• Degradació bit rot. Comprovació regular de la integritat i substitució pel fitxer de la còpia en cas de dany.
• Obsolescència dels suports i del maquinari, existeix un pla de millora de maquinari periòdicament.
• Obsolescència del programari; Invenio, el programari utilitzat per a la gestió del repositori està suportat pel CERN, i la UAB realitza tots els canvis de versions necessaris per a mantenir-lo al dia.
• Obsolescència dels formats: vigilància tecnològica per decidir si cal realitzar una migració.
• Error de l’operador / errors humans. S'ha implementat un sistema robust de control de versions (git) que permet recuperar versions anteriors dels fitxers i de les metadades corresponents.
• Desastre natural, existeixen vàries còpies de seguretat en diferents localitzacions separades geogràficament.
• Atac extern. Cada 10 minuts es comprova el número de peticions simultànies, i si el sobrepassa, es reinicia el servei. Mapa de ciberamenaces: https://cybermap.kaspersky.com/es
• Atac intern, només usuaris privilegiats poden accedir a determinades parts dels discos o fitxers.
• Fallada econòmica. Es mantindria el Servei sense actualitzacions.
• Fallada organitzativa. Si la Universitat deixa de complir amb les seves funcions organitzatives, com a membres de l'administració pública, el legat passa a l'òrgan superior, la Generalitat de Catalunya.