Prego de prescripcións técnicas

(1)

Prego de prescripcións técnicas

Implantación dunha plataforma avanzada de sinatura

electrónica

(2)

Índice

1. Introdución ...

1.1. Contexto...

1.2. Obxecto do contrato...

2. Especificacións Técnicas ...

2.1. Introdución... . 2.2 Administración...

2.2.1. Xestión de usuarios e permisos. ...

2.2.2 Xestión da auditoría...

2.2.3. Xestión da transformación de documentos XML a PDF... . 2.2.4. Agregación de novas CA á plataforma...

2.3. Aplicacións ...

2.3.1. Requisitos xerais...

2.3.2 Aplicación de sinatura de documentos custodiados polo usuario ...

2.3.3. Aplicación de validación de documentos ...

2.3.4 Aplicación de portasinaturas corporativo...

2.3.5. Aplicación de comprobación de códigos seguros de verificación...

2.3.6. Aplicación de administración do repositorio de documentos...

2.3.7. Aplicación de auditoría...

2.4. Servizos...

2.4.1. Condicións comúns ...

2.4.2. Planificación ...

2.4.3. Servizo de validación de certificados ...

2.4.4. Servizo de sinatura de documentos mediante selo electrónico ...

2.4.5. Servizo de repositorio de documentos...

2.4.6. Servizo de portasinaturas corporativo ...

2.4.7. Servizo de validación de documentos asinados...

2.4.8. Servizo de comprobación de códigos seguros de verificación ...

(3)

3. Condicións xerais dos traballos...

3.1. Propiedade intelectual...

3.2. Confidencialidade ...

3.3. Transferencia tecnolóxica ...

3.4. Formación ...

3.5. Planificación ...

3.6. Seguimento ...

3.7. Implantación ...

3.8. Garantía ...

3.9. Soporte ...

4. Produtos a entregar e servizos asociados ...

4.1. Software ...

4.2. Documentación ...

4.3. Servizos asociados ...

5. Estrutura e contidos das ofertas...

5.1. Contidos ...

5.2. Estrutura...

6. ANEXO: Infraestrutura dispoñible ...

6.1. Servidores ...

6.1.1. Bases de datos...

6.1.2. Servidores de aplicacións ...

6.1.3. Almacenamento...

6.1.4. Software...

6.1.5. Entorno tecnolóxico...

7. ANEXO: Hospedaxe da plataforma...

7.1. Alcance ...

7.2. Nivel do servizo ...

7.3. Seguridade ...

7.4. Acceso á plataforma pola USC...

8. ANEXO: Plataformas cliente de referencia ...

8.1. Windows ...

8.1.1. Sistemas operativos: ...

8.1.2. Navegadores ...

(4)

8.1.3. Java Runtime ...

8.2. Linux...

8.2.1. Sistemas operativos ...

8.3. Mac OS X ...

8.3.1. Sistemas operativos ...

(5)

1. INTRODUCIÓN

1.1. Contexto

As administracións públicas están suxeitas á lexislación e a normativa que se veu desenvolvendo en materia de administración electrónica, en particular:

1. LEI 11/2007, de 22 de xuño, de acceso electrónico dos cidadáns aos Servizos Públicos e REAL DECRETO 1671/2009, de 6 de novembro, polo que se desenvolve parcialmente dita lei.

2. LEI 59/2003, de 19 de decembro, de sinatura electrónica.

3. LEI 51/2003, de 2 de decembro, de igualdade de oportunidades, non discriminación e accesibilidade universal das persoas con discapacidade e o REAL DECRETO 1494/2007, de 12 de novembro, polo que se aproba o Regulamento sobre as condicións básicas para o acceso das persoas con discapacidade ás tecnoloxías, produtos e servizos relacionados coa sociedade da información e medios de comunicación social.

4. LEI ORGÁNICA 15/1999, de 13 de decembro, de Protección de Datos de Carácter Persoal e REAL DECRETO 1720/2007, de 21 de decembro, polo que se aproba o Regulamento de desenvolvemento da Lei Orgánica 15/1999.

A Lei 11/2007 establece unha serie de principios que deben inspirar a administración electrónica ou os procedementos dixitais:

1. Principio de identidade entre procesos en papel e dixitais.

2. Principio de accesibilidade.

3. Principio de neutralidade tecnolóxica.

4. Principio de simplificación administrativa.

5. Principio de transparencia e publicidade.

6. Principio de proporcionalidade.

7. Principio de calidade das informacións.

8. Cumprimento da normativa de protección de datos.

A propia Lei 11/2007 establece no seu art. 3 os obxectivos do seu articulado e establece como fins os seguintes:

1. Facilitar o exercicio de dereitos e o cumprimento de deberes por medios electrónicos.

(6)

2. Facilitar o acceso por medios electrónicos dos cidadáns á información e ao procedemento administrativo, con especial atención á eliminación das barreiras que limiten o dito acceso.

3. Crear as condicións de confianza no uso dos medios electrónicos, establecendo as medidas necesarias para a preservación da integridade dos dereitos fundamentais e, en especial, os relacionados coa intimidade e a protección de datos de carácter persoal, por medio da garantía da seguridade dos sistemas, os datos, as comunicacións e os servizos electrónicos.

4. Promover a proximidade co cidadán e a transparencia administrativa, así como a mellora continuada na consecución do interese xeral.

5. Contribuír á mellora do funcionamento interno das Administracións Públicas, incrementando a eficacia e a eficiencia das mesmas mediante o uso das tecnoloxías da información, coas debidas garantías legais na realización das súas funcións.

6. Simplificar os procedementos administrativos e proporcionar oportunidades de participación e maior transparencia, coas debidas garantías legais.

7. Contribuír ao desenvolvemento da sociedade da información no ámbito das Administracións Públicas e na sociedade en xeral.

Ademais dunha norma legal de obrigado cumprimento, este marco ofrece á USC unha oportunidade para aumentar a eficiencia, automatización e calidade dos servizos proporcionados, e así mellor desenvolver a función da USC de cara á sociedade.

Con estes fins, a USC desenvolveu un plan de implantación da administración electrónica en tres fases:

1. Fase I: implantación da plataforma avanzada de sinatura.

É o obxecto do presente prego.

2. Fase II: introdución de servizos específicos de administración electrónica.

Esta fase incluirá a posta en marcha da sede, o rexistro, as notificacións, a compulsa e a pasarela de pagamento electrónicos, así como integración da xestión de expedientes e a creación do taboleiro de editos.

3. Fase III: integración dos trámites de administración electrónica nas aplicacións corporativas.

Adaptaranse as aplicacións corporativas da USC para a súa integración na plataforma de administración electrónica.

(7)

1.2. Obxecto do contrato

O presente concurso ten como obxecto a contratación da fase I de implantación da administración electrónica, isto é, a implantación da plataforma avanzada de sinatura.

A plataforma implantada como resultado deste concurso servirá de base para o posterior desenvolvemento das fases II e III.

(8)

2. ESPECIFICACIÓNS TÉCNICAS

2.1. Introdución

A plataforma de sinatura electrónica avanzada consistirá nun conxunto de aplicacións, servizos, ferramentas e procesos de administración.

As aplicacións son programas deseñados para seren utilizados por persoas, as cales accederán a estes programas desde o seu ordenador a través da rede.

Estes programas utilizaranse mediante un navegador web, podendo, se fose necesario, conter compoñentes ricos (como applets java ou compoñentes flash). En calquera caso, a compatibilidade co maior número de clientes será un criterio de valoración fundamental.

Os servizos son programas deseñados para seren utilizados por outros sistemas informáticos, accedendo a estes mediante a rede TCP/IP. De cara a posibilitar a compatibilidade con calquera plataforma cliente, requírense protocolos o máis amplamente soportados, como HTTP mediante interfaces REST.

A descrición que segue sobre aplicacións e servizos é lóxica, non presupoñendo unha división paralela en compoñentes físicos (como aplicacións web). Un compoñente físico poderá implantar funcionalidade combinada de dúas ou máis aplicacións ou servizos. En calquera caso, a documentación entregada especificará a relación entre as aplicacións e servizos definidos neste prego e os compoñentes físicos da plataforma. As especificacións, en particular os requisitos de seguridade (incluíndo as posibles restricións para o seu acceso) e de rendemento, deberán ser soportados polos compoñentes para todas as aplicacións ou servizos que soporten segundo as especificacións deste prego.

Sen prexuízo do anterior, cada aplicación definida neste prego, independentemente do seu posible despregamento físico como parte doutra aplicación, deberá ter unha URL de entrada única que poderá ser utilizada desde aplicacións non pertencentes á plataforma para dirixir ao usuario á funcionalidade requirida.

As aplicacións e servizos requiren un nivel de rendemento especificado individualmente. A sección especifica a plataforma dispoñible na USC para alcanzar ese nivel de rendemento. Como se indica na sección , as ofertas deberán especificar calquera ampliación da infraestrutura dispoñible necesaria para o correcto funcionamento da plataforma, contemplando, en particular, os requisitos de rendemento. Opcionalmente, as ofertas poderán incluír a oferta de hospedaxe das aplicacións da plataforma, segundo se especifica na sección

A plataforma incluirá un mecanismo de auditoría que rexistrará as operacións relevantes. En particular, todas as operacións con implicacións para a seguridade serán adecuadamente rexistradas, con información de que usuario realiza a acción.

(9)

As aplicacións terán o suficiente rendemento e a escalabilidade necesaria para a normal operación da plataforma de sinatura avanzada. En todo caso, deberán cumprir os requisitos de rendemento indicados para cada caso particular. No cómputo dos tempos de resposta non se inclúen chamadas a servizos externos á plataforma, senón só tempos internos de procesamento, sempre e cando sexa posible medir obxectivamente o tempo de acceso a ditos servizos externos. En particular, non se inclúen chamadas a servidores remotos (como servidores TSA ou OCSP) e a dispositivos externos (como as tarxetas intelixentes en poder dos usuarios).

A plataforma soportará as autoridades de certificación necesarias para o cumprimento da lexislación vixente, en particular a necesidade de soportar o DNI electrónico. As seguintes autoridades de certificación estarán soportadas, sen prexuízo da posterior incorporación de novas autoridades da forma descrita na sección : Dirección Xeral da Policía e FNMT Clase 2.

A plataforma permitirá a utilización de diferentes políticas de sinatura. En particular, soportará as políticas do Ministerio de Administracións Públicas, a de Factura-e e a que a USC definirá como propia. Valorarase o soporte dun mecanismo xenérico de definición e utilización de políticas de sinatura.

A plataforma deberá contar cos mecanismos de redundancia necesarios para posibilitar unha dispoñibilidade 24x7.

2.2. Administración

A plataforma ofrecerá mecanismos de administración que permitan a súa xestión. Estes mecanismos poderán implantarse por distintos medios (aplicacións de usuario, programas no servidor, procedementos almacenados na base de datos, etc.). En calquera caso, estes mecanismos estarán catalogados e documentados en detalle no manual de operacións. En particular, deberanse implementar os seguintes mecanismos:

2.2.1. Xestión de usuarios e permisos.

As distintas aplicacións e servizos utilizarán un mecanismo unificado de xestión de usuarios. A autenticación destes estará integrada co sistema de Single Sign On da USC. A xestión da autorización de operacións particulares da plataforma realizarase mediante ferramentas ou procedementos específicos á plataforma.

A xestión de usuarios e permisos contará cunha interface electrónica que faga posible a carga, modificación e eliminación de datos relativa a usuarios e permisos por parte doutras aplicacións de xeito autónomo sen intervención dun operador.

(10)

2.2.2. Xestión da auditoría

Posibilitarase o cambio dos niveis de log e activar ou desactivar a auditoría de subsistemas concretos. Tamén se posibilitará a exportación da información de auditoría, a cal estará limitada a usuarios determinados.

2.2.3. Xestión da transformación de documentos XML a PDF

Para posibilitar a visualización de documentos electrónicos por parte dos usuarios e para posibilitar a xeración de copias do documento con códigos seguros de verificación, existirá un mecanismo polo que documentos XML de tipos recoñecidos podan ser transformados en documentos PDF. Para este fin, a plataforma permitirá a definición de transformacións mediante follas de estilo XSLT e a súa asociación a tipos concretos de documentos XML.

Unha vez feita esta asociación, a plataforma poderá xerar versións en PDF dos documentos XML do tipo dado, tanto novos como existentes.

Os administradores do sistema poderán definir novas transformacións de documentos e modificar as existentes. Tamén será posible xestionar a seguridade das copias con código seguro de verificación, segundo o especificado na sección

2.2.4. Agregación de novas CA á plataforma

Deberá existir un procedemento para engadir novas autoridades de certificación á plataforma, facendo que estas sexan recoñecidas, así como de subministrar á plataforma a información necesaria para que o mecanismo de recuperación dos datos dos certificados nun formato estándar funcione coas novas CA.

2.3. Aplicacións

2.3.1. Requisitos xerais

Todas as aplicacións deben ser multilingües, soportando, como mínimo, o galego e o castelán. O idioma por defecto da interface será o galego, de acordo co Regulamento de uso do galego na USC.

As aplicacións deberanse integrar coa aparencia visual da web corporativa da USC, seguindo a guía de estilo do sitio web da USC.

As aplicacións estarán integradas co sistema de autenticación único (Jasig CAS) da USC e incorporarán un mecanismo de seguridade para restrinxir o acceso a determinados usuarios ou grupos de usuarios. Este mecanismo debe ser configurable externamente. Todas as aplicacións requirirán autenticación, agás a parte pública da aplicación de comprobación de códigos seguros de verificación (sección ).

As aplicacións deben soportar o seu acceso desde os navegadores e plataformas máis estendidos e, en todo caso, desde as plataformas de referencia indicadas na sección deste prego.

(11)

As aplicacións deben respectar o establecido na lexislación vixente sobre accesibilidade web, en particular o Real Decreto 1494/2007, de 12 de novembro.

2.3.2. Aplicación de sinatura de documentos custodiados polo usuario 2.3.2.1. Requisitos funcionais

Esta aplicación permitiralle ao usuario aplicar a súa sinatura a documentos almacenados no seu ordenador. Debido á necesidade de aplicar a sinatura no ordenador do usuario, esta aplicación poderá utilizar applets no navegador cliente.

A aplicación deberá soportar diferentes plataformas clientes, segundo se especifica na sección Ademais, deberase soportar en tódalas plataformas clientes a utilización de tarxetas criptográficas por parte do usuario, en particular o DNI electrónico e a tarxeta de empregado público da FNMT.

Tamén deberá soportar os formatos máis estendidos de sinatura, en particular deberá permitirlle ao usuario asinar nos formatos:

1. PKCS#1

2. CMS/PKCS#7

3. PDF con sinaturas recoñecidas por lectores de ampla difusión.

4. XAdES (perfís XAdES básico, XAdES-T, XAdES- C, XAdES-X e XadES-X-L, En particular, soportaranse documentos no formato Facturae).

O resto das aplicacións e servizos da plataforma deberán soportar estes formatos de sinatura. En calquera caso, a plataforma soportará os formatos necesarios para asegurar a interoperabilidade coa Administración Xeral do Estado.

A aplicación deberá incorporar os sistemas de seguridade necesarios para a comunicación entre a parte cliente e a parte servidor da plataforma (comunicacións entre a applet e o servidor, de ser o caso). Tamén incorporará sistemas de prevención de ataques de denegación de servizo sobre os servizos invocados no servidor pola parte cliente. A documentación incluirá seccións específicas describindo con precisión ambos sistemas.

Requírese que as aplicacións externas podan facer uso da funcionalidade da aplicación de sinatura de documentos custodiados polo usuario mediante a integración con esta, que poderá ser a nivel de aplicación completa (mediante un mecanismo de URL de chamada e contrachamada) ou a nivel de applet de sinatura (mediante a incrustación do applet na aplicación cliente). A solución adoptada deberá ser aprobada pola USC.

(12)

2.3.2.2. Requisitos de rendemento

A aplicación deberá ser capaz de xestionar 500.000 sinaturas electrónicas por ano, con máximos de 50 sinaturas por minuto. O tempo medio dunha sinatura non debe exceder os 5 segundos, con máximos inferiores aos 10 segundos. Estes tempos refírense ao procesamento en servidor, sen contar o procesamento en cliente.

A aplicación deberá soportar 1000 usuarios concorrentes.

2.3.3. Aplicación de validación de documentos 2.3.3.1. Requisitos funcionais

Esta aplicación permitiralle ao usuario validar documentos asinados dixitalmente. Os documentos non deberán necesariamente proceder da plataforma, podendo ser documentos xerados e asinados externamente.

A aplicación deberá soportar a validación de sinaturas de usuarios con certificados nos formatos soportados pola aplicación de sinatura de documentos custodiados polo usuario (sección ) A aplicación extraerá os datos dos asinantes e mostrarallos ao usuario nun formato estandarizado, independente da autoridade de certificación que emitira o certificado e usuario. Este formato deberá ser validado pola USC.

A aplicación deberá ser capaz de xestionar 200.000 validacións ao ano, con máximos de 10 validacións por minuto. O tempo máximo de validación non deberá exceder os 10 segundos, para un documento de 5 MB que resida no servidor.

2.3.4. Aplicación de portasinaturas corporativo 2.3.4.1. Requisitos funcionais

A aplicación de portasinaturas permitiralle aos usuarios asinar documentos que estean asignados a estes, así como definir fluxos de traballo requirindo sinaturas de documentos por parte doutros usuarios do sistema. A definición de fluxos de sinatura deberá soportar sinaturas simples, múltiples con ou sen orde asignado e tamén a sinatura de documentos en bloque de forma eficiente.

A USC poñerá a disposición da aplicación un servizo que devolverá, dado un identificador de usuario, os roles que este usuario pode desempeñar. Á hora de definir un fluxo, un usuario normal da aplicación poderalle asignar a

(13)

cada asinante un rol entre aqueles devoltos polo servizo. Os usuarios que conten co permiso adecuado poderán elixir os roles libremente.

Aos documentos, unha vez asinados, seralles asignado un código seguro de verificación, que permitirá recuperalos mediante a aplicación de comprobación de códigos seguros de verificación (sección ).

A aplicación lanzará eventos cada vez que teñan lugar determinados sucesos, como a definición dun fluxo, a sinatura dun documento, o esgotamento dun prazo de sinatura, etc. En particular, cando un documento é incorporado á aplicación xerarase un evento no que figurará un identificador único de documento, o identificador do usuario que realizou a operación e os metadatos asociados. O identificador do documento permitirá identificar e recuperar ese documento posteriormente. Cando o fluxo de sinatura sexa completado exitosamente para un documento, xerarase un evento que conterá o identificador do documento, os metadatos do documento (como se definen na sección ) e o código seguro de verificación para ese documento, que servirá para recuperar o documento coa aplicación de comprobación de códigos seguros de verificación.

Á hora de definir un fluxo, deberá ser posible atribuír políticas de eventos por fluxo ou asinante que definan que sucesos desencadearán o lanzamento de eventos por parte do portasinaturas. Por exemplo, poderase indicar, para un asinante dado, que o portasinaturas lance un evento cando o documento estea dispoñible para ser firmado por este; poderase indicar tamén que se lance un evento cando estea cerca de esgotarse o tempo límite para a sinatura dun documento, etc.

O conxunto de sucesos para os que a aplicación lanzará eventos, a información contida nestes e o mecanismo de especificación de políticas de eventos, deberá ser definido en conxunción coa USC e ser aprobado por esta.

Os eventos serán enviados pola aplicación mediante a utilización da API JMS. Poderase utilizar outro mecanismo sempre que este sexa previamente autorizado pola USC. Garantirase o carácter atómico da operación e a propagación do evento ou, en caso contrario, debe explicarse o mecanismo de recuperación para eventos correspondentes a operacións confirmadas pero que non se conseguiron transmitir con éxito.

O portasinaturas utilizará o servizo de portasinaturas (sección ) para realizar as súas operacións, polo que os requisitos funcionais das operacións serán comúns. En particular, a xeración de eventos e a xeración de copias con códigos seguros de verificación realizaranse polo mesmo motor independentemente de se as operacións se realizan invocando esta aplicación ou directamente o servizo.

Se é posible xerar unha versión en PDF dun documento (ben porque o documento xa estea nese formato, ou ben porque exista unha transformación do formato orixinal a PDF, tal e como se describe na sección ), a aplicación ofreceralle ao usuario a posibilidade de obter as dúas versións no ciclo de sinatura, aínda que só se poda asinar a versión orixinal.

(14)

A aplicación deberá ser capaz de soportar a definición e procesamento de 200.000 fluxos anuais cunha media de 3 sinaturas por fluxo, cun máximo de 100 operacións por minuto. O tempo medio dunha operación, excluíndo o rexistro de ficheiros, será inferior a 2 segundos. O tempo máximo será inferior a 15 segundos.

2.3.5. Aplicación de comprobación de códigos seguros de verificación 2.3.5.1. Requisitos funcionais

Esta aplicación permitiralle aos usuarios recuperar un documento a partir do seu código seguro de verificación. Cada vez que un documento finaliza o seu ciclo de sinaturas e se converte nun documento oficial, xerarase un código seguro de verificación que permitirá a recuperación dunha copia do documento en formato imprimible (PDF). Hai dous procesos involucrados.

O primeiro proceso é a transformación dun documento XML nun documento PDF, descrito na sección O segundo proceso é a xeración dun código de verificación único, a súa inclusión nun documento PDF e a posta a disposición deste a través dunha URL pública.

Desta forma posibilitase que o usuario poda imprimir o documento PDF que contén o código seguro de verificación e calquera receptor deste poda comprobar a autenticidade do mesmo sen máis que utilizar a aplicación de comprobación de códigos seguros de verificación co código dado.

A aplicación restrinxirá a dispoñibilidade dos documentos en tres niveis 1. Dispoñibilidade pública

O documento estará dispoñible a través da aplicación para calquera usuario, sen requirir que este estea autenticado.

2. Dispoñibilidade mediante certificado

O documento estará dispoñible para os usuarios autenticados na aplicación mediante certificado dixital.

3. Non dispoñibilidade

O documento só estará dispoñible a través da aplicación de comprobación de códigos seguros de verificación para administradores da plataforma ou usuarios da aplicación da USC que dispoñan dun permiso específico para a visualización de copias con códigos seguros de verificación con nivel de dispoñibilidade “non dispoñible”.

(15)

Deberá ser posible o cambio de nivel de visibilidade dun documento.

A aplicación deberá soportar un total de 100.000 comprobacións por ano, con máximos de 20 comprobacións por minuto. O tempo medio para atopar un documento e iniciar a descarga será menor de 2 segundos. O tempo máximo será inferior a 10 segundos.

A aplicación deberá ser capaz de soportar 1000 usuarios concorrentes. A aplicación debería, na medida do posible, evitar a creación de sesións de usuario para acceso a documentos con dispoñibilidade pública.

2.3.6. Aplicación de administración do repositorio de documentos 2.3.6.1. Requisitos funcionais

A plataforma incluirá unha interface de administración do repositorio de documentos que permita a busca de documentos por varios parámetros e a recuperación destes. A aplicación deberá incorporar os mecanismos de seguridade necesarios para poder restrinxir o seu uso a un conxunto definido de usuarios da USC, así como posibilitar a restrición do acceso por rede á aplicación a determinados equipos ou redes cliente.

A aplicación deberá ser capaz de soportar 10 usuarios concorrentes.

2.3.7. Aplicación de auditoría

Esta aplicación permitirá consultar os rexistros de auditora, podendo aplicar filtros por aplicación ou servizo, usuario, datas, etc. Tamén posibilitará a extracción de información estatística de acceso ás aplicacións e aos servizos.

2.4. Servizos

2.4.1. Condicións comúns

Tódolos servizos deben ser accesibles, dentro da intranet da USC, polas aplicacións xa existentes, sendo preciso garantir a compatibilidade das tecnoloxías cliente coa interface exposta polos servizos. Con este fin, requírese expoñer unha interface REST, debido á facilidade de soporte desde calquera plataforma. En particular os servizos deben ser accesibles dende as aplicacións desenvolvidas nas plataformas JEE, ASP e PHP. A solución tecnolóxica proposta polo adxudicatario para expoñer as interfaces dos servizos deberá ser expresamente aprobada pola USC.

Os servizos, ao igual que as aplicacións, deberán ser capaces de soportar múltiples linguas. En particular, calquera mensaxe devolta por un servizo

(16)

que estea destinado a ser mostrada ao usuario deberá ser devolta en todas as linguas que soporte a plataforma.

Cando unha invocación dunha operación non se execute con éxito, devolverase unha resposta de erro estandarizada cuns campos fixos, independentes da operación, que incluirán: un código do tipo do erro, un código único de erro, que aparecerá na auditoría, e unha mensaxe de erro susceptible de ser mostrada ao usuario final da aplicación cliente. Como consecuencia do parágrafo anterior, esta mensaxe deberá ser devolta en todas as linguas soportadas pola plataforma.

Os servizos terán o suficente rendemento e escalabilidade para posibilitar a normal operación da plataforma de sinatura electrónica avanzada e o desenvolvemento sobre estes das fases II e III. En todo caso, cada servizo deberá satisfacer os requisitos de rendemento indicados para cada caso individual.

Os servizos contarán cos mecanismos de seguridade adecuados para restrinxir a súa utilización por aplicacións e/ou usuarios autorizados. O deseño xeral e particular para cada servizo do mecanismo de seguridade deberá ser especificado a priori e aprobado pola USC.

2.4.2. Planificación

De cara a realizar adaptacións urxentes de aplicacións non pertencentes á plataforma, requírese que, nunha primeira fase, o adxudicatario implemente stubs de tódolos servizos aquí descritos e que estes sexan entregados nunha das primeiras iteracións do proxecto, en calquera caso antes do remate dos dous primeiros meses do período de execución do contrato.

Os stubs deberán implementar a interface completa dos servizos e, dependendo de valores de entrada particulares, fixados e debidamente documentados, devolverán distintas respostas, cubrindo toda a tipoloxía posible. En particular, para cada operación dun servizo, definirase un conxunto de valores de entrada que darán lugar a unha resposta de erro.

Non se require que os stubs interaccionen coas bases de datos, compoñenetes de terceiros ou que as invocacións das operacións produzan ningún efecto permanente. En particular, non se require que invocacións sucesivas de servizos manteñan a secuencia lóxica de valores que terían coa implementación real, aínda que é desexable, na medida do posible, que os valores arbitrarios de entrada e saída elixidos posibiliten a implementación polas aplicacións cliente, de forma natural, de casos de uso que impliquen a realización de varias operacións consecutivas, utilizando os valores devoltos por unha operación para alimentar á seguinte.

Por exemplo, se a operación de gardado dun documento para un conxunto de parámetros dado, devolve un identificador de documento (que non terá ningún sentido físico, dado que o stub en realidade non garda o documento), é desexable que calquera outra operación acepte ese identificador como válido e non devolva un erro que corresponda a un “documento non existente”. Isto require elixir coherentemente os conxuntos arbitrarios de entradas e saídas das operacións dos servizos.

(17)

Os stubs deberán ser completamente deterministas, devolvendo as mesmas respostas para as mesmas entradas en cada invocación.

Os stubs subministraranse nun único compoñente autónomo (un módulo war ou similar) que sexa posible distribuír a terceiras partes para que podan, desta forma, desenvolver clientes da plataforma sen ter acceso a esta.

2.4.3. Servizo de validación de certificados 2.4.3.1. Requisitos funcionais

O servizo de validación de certificados permitirá aos clientes (en particular, á aplicación de autenticación de usuarios) a validación de certificados soportados pola plataforma. O servizo soportará, como mínimo, a seguinte operación:

1. Validación de certificados

Dado un certificado enviado polo cliente, o servizo extraerá os datos nun formato estándar independente do certificado e devolveranse na resposta.

Ademais da carga soportada para dar servizo ás aplicacións e outros servizos da plataforma, o servizo de validación de certificados soportará 350.000 peticións ao ano, con máximos de 50 peticións por minuto. O tempo medio de resposta será inferior a 1 segundo, cun tempo máximo de 5 segundos.

2.4.4. Servizo de sinatura de documentos mediante selo electrónico 2.4.4.1. Requisitos funcionais

Este servizo permitiralle ás aplicacións cliente realizar sinaturas de documentos cun ou varios certificados de selo electrónico custodiados polo servidor. A plataforma soportará a utilización de dispositivos HSM (Hardware Security Modules) para a custodia destes certificados. O servizo soportará, como mínimo, a seguinte operación:

1. Sinatura dun documento

O cliente enviará un documento, un identificador do certificado a utilizar, a política de sinatura a realizar e os parámetros requiridos pola política dada. O servizo realizará a sinatura deste co certificado almacenado no servidor correspondente ao identificador solicitado, se a aplicación cliente ten autorización para a utilización dese certificado e devolverá o identificador do documento selado. Esta operación debe estar debidamente protexida, tendo en conta a súa natureza altamente sensible. En particular, só determinadas aplicacións, executándose en

(18)

servidores coñecidos, poderán invocar o servizo e só poderán solicitar a utilización dos certificados explicitamente autorizados para esa aplicación. A forma de autenticación das aplicacións cliente debe ser fiable e para cada invocación do servizo xerarase unha entrada completa e detallada de auditoría.

Ademais da carga soportada para dar servizo ás aplicacións e outros servizos da plataforma, o servizo deberá soportar 300.000 sinaturas por ano, con máximos de 30 por minuto. O tempo medio dunha sinatura será inferior a 1 segundo, con máximos inferiores a 5 segundos.

2.4.5. Servizo de repositorio de documentos 2.4.5.1. Requisitos funcionais

A plataforma contará cun repositorio de documentos que será utilizado polo portasinaturas, pero tamén poderá ser utilizado por outras aplicacións a través deste servizo, o cal posibilitará o acceso a dito repositorio para recuperar e agregar novos documentos.

Cada documento do repositorio terá un identificador único, persistente, que actuará de nexo entre o portasinaturas e este servizo. Unha vez gardado un documento, a chamada á operación devolverá o seu identificador, e este poderá ser utilizado nas chamadas ao servizo de portasinaturas corporativo.

Do mesmo xeito, un identificador devolto polo portasinaturas poderá ser utilizado para referenciar ao documento ao invocar o servizo de repositorio de documentos.

Cada documento gardado polo repositorio terá asignado un conxunto de metadatos, que consistirá en parellas de cadeas (nome_atributo, valor).

Existirá un conxunto reservado de nomes para atributos estándar. Algúns destes atributos estándar serán asignados e xestionados pola plataforma automaticamente (como a data de creación, o tamaño e o identificador de aplicación cliente que a creou), outros serán forzosamente subministrados por calquera cliente para poder gardar un documento (como o nome do arquivo e o tipo ou extensión normalizada) e o resto serán libremente definidos polos clientes. A non subministración dun atributo requirido ou a especificación dun atributo cun nome reservado para a plataforma supoñerá un erro.

O servizo soportará, como mínimo, as seguintes operacións:

1. Gardado dun documento

O cliente enviará un documento e un conxunto de metadatos nunha única invocación (por exemplo, unha petición HTTP POST),

(19)

devolvéndose, en caso de éxito, unha resposta que conteña o identificador asignado ao documento.

2. Recuperación dun documento

O cliente enviará o identificador do documento. O servizo devolverá o documento xunto cos seus metadatos, incluíndo os xestionados pola plataforma.

3. Busca dun documento a partir dos seus metadatos O cliente especificará unha serie de condicións sobre os metadatos

(como mínimo existencia dun atributo ou o valor dun atributo).

Tamén poderá especificar unha lista de atributos sobre os que ordenar os resultados, cada un en orden ascendente ou descendente.

O servizo devolverá unha serie de identificadores de documentos cumprindo as condicións dadas, xunto cos metadatos de cada un.

O número de resultados devoltos estará limitado. Tamén se soportará a paxinación nas aplicacións cliente mediante a especificación como parámetros opcionais a páxina de inicio e o tamaño de páxina.

Ademais da carga soportada para dar servizo ás aplicacións e outros servizos da plataforma, o servizo deberá soportar o gardado de 100.000 documentos e a recuperación de 300.000 documentos por ano, con máximos de 10 e 30 invocacións por minuto, respectivamente.

O tempo medio de recuperación dun documento de 1 MB será inferior a 3 segundos, cun máximo de 15 segundos. O tempo medio de gardado dun documento de 1 MB será de 5 segundos, cun máximo de 20 segundos.

2.4.6. Servizo de portasinaturas corporativo 2.4.6.1. Requisitos funcionais

O servizo de portasinaturas corporativo daralle acceso á funcionalidade do portasinaturas ás aplicacións cliente. En particular, permitirá a creación e modificación de fluxos de sinaturas e a consulta de fluxos.

1. Creación dun novo fluxo de sinatura

O cliente especificará os documentos a incluír no fluxo e os signatarios, especificando as relacións sobre eles para poder soportar sinaturas simples, secuenciais, etc. Os documentos

(20)

poderán especificarse mediante a inclusión de identificadores de documentos previamente gardados mediante o servizo de repositorio de documentos.

2. Cancelación dun fluxo de sinatura

Esta operación permitirá cancelar un fluxo. Se a operación ten éxito xerarase un evento.

3. Obtención de información dun fluxo

Dado un identificador de fluxo, o servizo devolverá a información do estado do fluxo, incluíndo asinantes, metadatos dos documentos e o estado da sinatura de cada un.

Ademais da carga soportada para dar servizo ás aplicacións e outros servizos da plataforma, o servizo de portasinaturas deberá soportar 100.000 peticións por ano, con máximos de 20 invocacións por minuto.

2.4.7. Servizo de validación de documentos asinados 2.4.7.1. Requisitos funcionais

O servizo soportará, como mínimo, a seguinte operación:

1. Validación dun documento

O cliente enviará o documento a validar e a política de sinatura a aplicar. O servizo devolverá o status de validación do documento.

En caso de validación correcta, os datos do signatario ou signatarios serán devoltos no mesmo formato estandarizado que a aplicación de validación de documentos (sección )

Ademais da carga soportada para dar servizo ás aplicacións e outros servizos da plataforma, o servizo deberá soportar a validación de 300.000 documentos por ano, con máximos de 20 validacións por minuto. O tempo medio de validación, para un documento de 1 MB, non será superior a 3 segundos na rede local da USC. O tempo máximo non será superior a 10 segundos.

(21)

2.4.8. Servizo de comprobación de códigos seguros de verificación 2.4.8.1. Requisitos funcionais

O servizo ofrecerá a mesma funcionalidade que a aplicación de comprobación de códigos seguros de verificación e deberá asegurar o mesmo nivel de seguridade, en particular no que se refire aos niveis de acceso.

1. Recuperación dun documento a partir do seu código seguro de verificación

O cliente subministrará o código e o servidor devolverá o documento correspondente a ese código, ou un erro apropiado en caso de non existir, ter un nivel de dispoñibilidade restrinxido, etc. Esta operación respectará o nivel de seguridade dun documento, requirindo que a aplicación cliente estea autorizada para poder obter un documento restrinxido. Neste caso o cliente enviará a información necesaria para a identificación do usuario final que está accedendo o documento.

2. Consulta do nivel de dispoñibilidade dun documento O cliente enviará o código seguro de verificación dun documento e

obterá o seu nivel de dispoñibilidade.

3. Cambio de nivel de dispoñibilidade dun documento O cliente enviará o código seguro de verificación dun documento e o

novo nivel de dispoñibilidade. Esta operación estará restrinxida ás aplicacións cliente expresamente autorizadas para invocar esta operación.

Ademais da carga soportada para dar servizo ás aplicacións e outros servizos da plataforma, o servizo deberá soportar un total de 50.000 comprobacións por ano, con máximos de 10 comprobacións por minuto. O tempo medio para atopar un documento será menor de 2 segundos. O tempo máximo será inferior a 10 segundos.

(22)

3. CONDICIÓNS XERAIS DOS TRABALLOS

3.1. Propiedade intelectual

Sen prexuízo do disposto pola lexislación vixente, en materia de propiedade intelectual e de protección xurídica dos programas de ordenador, o contratista acepta expresamente que a propiedade e os dereitos de explotación e distribución das aplicacións informáticas desenvolvidas ao amparo do presente prego corresponden unicamente á Universidade de Santiago de Compostela, con exclusividade e a tódolos efectos, así como a propiedade de toda a documentación xerada.

3.2. Confidencialidade

O adxudicatario queda expresamente obrigado a manter absoluta confidencialidade e reserva sobre calquera dato que puidera coñecer con ocasión do cumprimento do contrato, especialmente nos de carácter persoal, que non poderá copiar ou empregar con fin distinto ao que figura neste prego, nin ceder a outros nin sequera para efectos de conservación.

Os licitadores achegarán unha memoria descritiva das medidas que adoptarán para asegurar a dispoñibilidade, confidencialidade e integridade dos datos manexados e da documentación facilitada.

Asemade, deberán incluír na súa oferta a designación da persoa ou persoas que, sen prexuízo da responsabilidade propia da empresa, estarán autorizadas para as relación coa USC para efectos do emprego correcto do material e da información que se vai manexar.

O adxudicatario queda obrigado ao cumprimento do disposto pola Lei orgánica 15/1999, do 13 de decembro, sobre protección de datos de carácter persoal.

3.3. Transferencia tecnolóxica

Durante a execución dos traballos obxecto do contrato, o adxudicatario comprométese a facilitar en todo momento ás persoas designadas pola USC para tales efectos a información e documentación que estas soliciten para dispoñer de pleno coñecemento das circunstancias nas que se desenvolvan os traballos, así como dos problemas que se poidan presentar e das tecnoloxías, métodos e ferramentas utilizados para resolvelos.

(23)

3.4. Formación

O adxudicatario deberá desenvolver as seguintes tarefas de formación:

(1) Elaboración e entrega do manual de usuario para cada unha das aplicacións.

(2) Un mínimo de dez horas de sesións formativas dirixidas ao persoal da Área das Tecnoloxías da Información e a Comunicación da Universidade de Santiago de Compostela, que incluirán, como mínimo, os seguintes puntos:

(a) Instalación e implantación da plataforma.

(b) Aspectos de seguridade da plataforma a ter en conta para os administradores do sistema.

(c) Solución de problemas de explotación típicos.

(d) Xestión de problemas co soporte ofertado polo adxudicatario.

(3) Un mínimo de dez horas de sesións formativas dirixidas ao persoal da Área das Tecnoloxías da Información e a Comunicación da Universidade de Santiago de Compostela, que incluirán, como mínimo, os seguintes puntos:

(a) Desenvolvemento de aplicacións cliente para os servizos.

(b) Aspectos de seguridade a ter en conta durante o desenvolvemento das aplicacións cliente.

(c) Estrutura e deseño dos programas informáticos elaborados polo adxudicatario, modificación destes e xeración dos artefactos binarios listos para o uso por parte da USC.

(4) Un mínimo de dez horas de sesións formativas dirixidas ao persoal do Centro de Atención ao Usuario, que incluirán, como mínimo, os seguintes puntos:

(a) Resolución de problemas de compatibilidade das plataformas cliente (sistema operativo, navegador, runtime de Java, …) nos equipos do cliente.

(b) Resolución de dúbidas dos usuarios sobre a utilización das aplicacións da plataforma.

(24)

3.5. Planificación

As ofertas presentadas incluirán unha planificación coa descrición de cada unha das actividades que se levarán a cabo no proxecto, incluíndo o desenvolvemento, implantación e formación dos usuarios. As distintas tarefas agruparanse en iteracións e especificaranse os prazos de execución de cada unha das iteracións.

3.6. Seguimento

A USC designará unha persoa como Director Técnico, que actuará como interlocutor principal por parte da universidade co adxudicatario e realizará o seguimento do proxecto.

O adxudicatario designará unha persoa como Xefe de Proxecto, que actuará como interlocutor principal por parte do adxudicatario e estará a disposición da USC para aclarar calquera dúbida sobre a marcha do proxecto.

O Director Técnico fará un seguimento continuo da evolución do proxecto e planificará un calendario de reunións de seguimento e de revisións técnicas co Xefe de Proxecto, co fin de revisar o grado de cumprimento dos obxectivos e a validación das programacións das actividades realizadas.

Tras as revisións técnicas, o Director Técnico poderá rexeitar en todo ou en parte os traballos realizados na medida que non correspondan ao acordado e que non superen os controles de calidade.

3.7. Implantación

O software da plataforma será instalado polo adxudicatario nos servidores do departamento de Sistemas da Área das Tecnoloxías da Información e Comunicación da USC, baixo a supervisión do persoal da área. A instalación farase para os contornos de produción, pre-produción e probas.

A tal fin, a USC poñerá a disposición do adxudicatario unha conexión VPN que poderá ser utilizada por este para todas as accións de implantación e soporte que sexan susceptibles de ser realizadas utilizando este medio. As actuacións que requiran presencia de persoal da empresa adxudicataria serán planificadas en conxunción co Director Técnico, correndo por parte do adxudicatario os gastos de desprazamento. O uso da VPN implicará a aceptación dos termos de uso e o cumprimento de todas as normas de seguridade e de confidencialidade da información asociadas.

No caso de optar a USC pola opción de hospedaxe, a instalación será realizada no entorno hospedado.

En calquera caso, o adxudicatario elaborará un Manual de Instalación que permita a instalación de tódolos compoñentes da plataforma por parte do persoal da USC de forma autónoma.

(25)

3.8. Garantía

O adxudicatario deberá garantir por un ano os produtos derivados da presente contratación, contando dende a data de recepción destes, obrigándose a realizar durante o período os cambios necesarios para solucionar as deficiencias detectadas imputadas ao adxudicatario se a USC así o solicita.

A garantía tamén incluirá de xeito gratuíto o soporte, nas condicións especificadas na sección

3.9. Soporte

As ofertas presentadas deberán incluír o prezo anual para soporte, pasado o período de garantía, e as condicións do soporte ofrecido, incluíndo o alcance previsto para o mantemento, as operacións incluídas e o nivel de servizo ofertado.

Unha vez pasado o período de garantía, a USC terá o dereito a contratar soporte da plataforma co adxudicatario nas condicións definidas por este na oferta, polo período de tempo que a USC elixa. En todo caso, o adxudicatario debe garantir, como mínimo, a posibilidade de contratar o servizo por un período de ata dous anos nas condicións especificadas na oferta.

O soporte incluirá a solución de erros ocultos que se poñan de manifesto no funcionamento das aplicacións ou que se atopen mediante probas ou calquera outro medio, así como a conclusión da documentación incompleta e reparación da que conteña deficiencias. En particular, o soporte incluirá a incorporación da solución dos erros detectados na plataforma base e corrixidos nas actualizacións desta. Os produtos orixinados como consecuencia da reparación de erros deberán entregarse de conformidade co esixido neste prego.

O tempo de resposta ante unha solicitude de asistencia por erro nos produtos obtidos durante a execución do presente prego será de como máximo 24 horas. As ofertas presentadas deberán incluír as condicións de soporte, cos tempos de resposta garantidos para solicitudes de soporte en función do seu nivel de criticalidade.

(26)

4. PRODUTOS A ENTREGAR E SERVIZOS ASOCIADOS

A plataforma de sinatura electrónica considerarase composta de tres elementos principais:

1. Infraestrutura

A infraestrutura inclúe todos os elementos de terceiros necesarios para o funcionamento da plataforma, incluíndo a rede, o hardware e o software de infraestrutura (sistemas operativos, bases de datos, …).

2. Plataforma base

A plataforma base inclúe os elementos específicos de plataforma electrónica que constitúen o núcleo da oferta do adxudicatario. Estes elementos incluirán software, documentación e servizos.

3. Elementos específicos

Ao amparo do presente prego elaboraranse unha serie de elementos de software e documentación.

A USC terá o dereito de utilizar a plataforma base a perpetuidade sen requirir ningún pagamento posterior. Valorarase a dispoñibilidade do código fonte da plataforma, na súa totalidade ou en parte, e a súa distribución mediante unha licenza que permita a súa redistribución. En calquera caso, a plataforma base deberá ser un produto de mercado adquirible por terceiras partes.

Os elementos específicos serán propiedade exclusiva da USC, como se detalla na sección Nótese que calquera modificación da plataforma base considerarase propiedade da USC e o presente prego require que sexa posible técnica e legalmente a aplicación das modificacións á plataforma base para producir o produto final sen intervención do adxudicatario nin a adquisición de ningunha licenza específica para tal fin.

En calquera caso, se a USC así o desexa, e previo acordo con esta, calquera terceira parte poderá utilizar a plataforma de sinatura electrónica da USC sen máis que configurar a infraestrutura adecuadamente, obter do adxudicatario, ou calquera outra entidade apropiada, a licenza de uso da plataforma base e obter da USC os elementos específicos desenvolvidos ao amparo do presente prego e o dereito do seu uso.

4.1. Software

Deberanse entregar, como mínimo, os seguintes elementos de software:

1. Software da plataforma base.

2. Código fonte de todas as aplicacións e servizos que aparecen recollidos na sección

(27)

3. Código fonte das modificacións á plataforma base.

4. Código fonte da plataforma base, na súa totalidade ou dos elementos para os que o código fonte se faga dispoñible.

4.2. Documentación

Deberanse entregar, como mínimo, os seguintes elementos de documentación:

1. Documentación completa da plataforma base.

2. Documentación das modificacións da plataforma base.

3. Manuais de usuario de todas as aplicacións e servizos.

No caso das aplicacións o destinatario é o usuario final destas. No caso dos servizos o usuario é o programador de sistemas cliente.

4. Manual de instalación

Este manual incluirá as instrucións precisas para a instalación da plataforma base e dos elementos específicos. Describiranse tamén os requisitos de infraestrutura necesarios para a instalación da plataforma, así como calquera configuración non estándar destes.

Incluirase neste manual a instalación dos contornos de probas, pre- produción e produción.

5. Documentación de deseño.

Describirase a arquitectura xeral da solución, tanto lóxica como física.

Tamén se describirán as consideracións de seguridade e rendemento á hora de deseñar a solución.

6. Manual de operación e mantemento

Describirá as accións necesarias para a operación da plataforma e para o mantemento, incluíndo unha relación das operacións periódicas que se deben realizar para asegurar o correcto funcionamento da plataforma.

Tamén describirá o proceso de proba de novas versións da plataforma subministradas polo adxudicatario no contorno de pre-produción e paso a produción unha vez validadas.

Describiranse os procedementos necesarios para soportar a operación ininterrumpida da plataforma.

7. Manual de programación

(28)

Describirá o proceso de creación dunha aplicación cliente dos servizos da plataforma, mediante a utilización dos stubs, a realización de probas de integración contra o contorno de probas, a súa validación no contorno de pre-produción e o seu paso a produción.

En particular, conterá guías de como realizar a programación, mecanismo de configuración e empaquetado para posibilitar un procedemento de desenvolvemento, probas e paso a produción simple e sistemático.

8. Memoria descritiva das medidas que o adxudicatario adoptará para asegurar a dispoñibilidade, confidencialidade e integridade dos datos manexados e da documentación facilitada, de acordo co especificado na sección

4.3. Servizos asociados

O adxudicatario deberá ofertar unha serie de servizos asociados como parte da solución, segundo aparece recollido no presente prego. En particular, proverá os seguintes servizos:

1. Instalación.

O adxudicatario realizará a instalación da plataforma na infraestrutura da USC, segundo as condicións fixadas na sección

2. Formación

O adxudicatario realizará as accións de formación, segundo as condicións fixadas na súa oferta que, en todo caso, incluirán as condicións fixadas na sección

3. Garantía

O adxudicatario proverá a garantía da plataforma, segundo as condicións establecidas por este na súa oferta que, en todo caso, incluirán as condicións fixadas na sección

4. Hospedaxe.

No caso de incluír a oferta a opción de hospedaxe da plataforma, o adxudicatario ofreceralle á USC a opción de contratar, de xeito separado, ese servizo nas condicións fixadas na oferta que, en todo caso, incluirán as condicións fixadas na sección

(29)

5. ESTRUTURA E CONTIDOS DAS OFERTAS

5.1. Contidos

As ofertas presentadas para o presente concurso deberán necesariamente incluír os seguintes elementos:

1. Formulario de valoración cumprimentado. En caso de incompatibilidade co resto da oferta, os valores cumprimentados no formulario prevalecerán.

2. Aceptación explícita de todas as condicións fixadas no presente prego.

3.

4. Plataforma base ofertada, indicando a

dispoñibilidade de código fonte, a licenza baixo a que o código fonte está dispoñible e as condicións de uso da plataforma.

5. Alcance e prezo do soporte ofertado, incluíndo o período máximo que o adxudicatario se compromete a ofertarlle á USC a posibilidade de contratalo. Indicaranse de xeito explícito as condicións ofertadas por riba dos mínimos fixados no presente prego.

6. Soporte de solucións HSM (Hardware Security Modules), especificando a compatibilidade con produtos comerciais concretos.

7. Alcance da garantía, en contidos e extensión temporal. Indicaranse de xeito explícito as condicións ofertadas por riba dos mínimos fixados no presente prego.

8. Proxectos adxudicados ao oferente do mesmo tipo que o prescrito no presente prego (administración electrónica en administracións públicas e/ou universidades) cun importe igual ou superior ao ofertado. É indispensable achegar a documentación necesaria para discernir sen lugar a dúbida a exactitude da información relativa aos proxectos.

9. Alcance da formación, en contidos e extensión temporal. Indicaranse de xeito explícito as condicións ofertadas por riba dos mínimos fixados no presente prego.

10. Informe de adecuación da plataforma aos requirimentos técnicos da oferta, punto a punto.

11. Funcionalidades extra ofertadas pola plataforma (tanto en aplicacións como servizos) por riba dos mínimos fixados no presente prego.

(30)

12. Planificación detallada dos traballos, incluíndo cada unha das iteracións e os produtos e servizos que se entregarán ao remate de cada unha. En particular, recollerase a planificación da entrega dos stubs dos servizos, de acordo ao especificado na sección ()

13. Plan de execución das fases II e III baseándose na plataforma de sinatura electrónica implantada como resultado deste concurso. Incluirase unha valoración económica do custo da fase II.

14. Requisitos de infraestrutura (hardware e software) para a plataforma adicionais á infraestrutura dispoñible especificada na sección Incluirase o prezo individualizado de cada compoñente adicional que o adxudicatario requirise. Estes prezos estarán incluídos no importe total da oferta.

O adxudicatario terá a obriga de ofertar a subministración dos compoñentes adicionais requiridos por este na súa oferta, aos prezos alí indicados. A USC poderá exercitar o seu dereito á adquisición da totalidade ou parte dos compoñentes adicionais ao adxudicatario, podendo optar por elixir outros subministradores para a totalidade ou parte dos compoñentes.

15. Memoria descritiva das medidas que adoptarán para asegurar a dispoñibilidade, confidencialidade e integridade dos datos manexados e da documentación facilitada (sección )

16. Memoria descritiva da solución técnica ao soporte de operación ininterrumpida (24x7).

17. Opcionalmente, incluirase na oferta as condicións e prezos do hospedaxe da plataforma de acordo cos requisitos da sección

5.2. Estrutura

As ofertas presentadas deberán axustarse ao seguinte esquema:

1. Índice.

2. Formulario de valoración cumprimentado.

3. Características xerais.

3.1. Identificación da oferta.

3.2. Aceptación expresa das condicións do presente prego.

(31)

3.3. Importe total e prazo de execución.

3.4. Acreditación da experiencia da empresa en desenvolvementos similares.

4. Descrición da oferta.

4.1. Plataforma base.

4.2. Descrición técnica da solución proposta para o desenvolvemento específico.

4.3. Soporte de solucións HSM.

4.4. Soporte, garantía e formación.

4.5. Planificación.

4.6. Descrición do soporte á operación ininterrumpida.

5. Memoria descritiva das medidas que adoptarán para asegurar a dispoñibilidade, confidencialidade e integridade dos datos manexados e da documentación facilitada.

6. Melloras da oferta.

6.1. Prestacións superiores, melloras suxeridas ao proceso de desenvolvemento, documentación ou produtos e servizos entregados. Identificarase explicitamente o punto ou puntos mellorados do presente prego.

7. Planificación do desenvolvemento e das entregas de documentación, produtos e servizos.

Incluirase neste apartado a descrición das medidas dispostas polo oferente para asegurar a calidade dos traballos, metodoloxías, medios materiais, aseguramento de calidade, seguridade e confidencialidade, así como aqueloutras que se prevén aplicar para vixiar e garantir o adecuado cumprimento do contrato.

8. Plan de execución das fases II e III 9. Requisitos extra da infraestrutura.

10. Condicións do hospedaxe, se a oferta inclúe esta opción. No caso de non ofertala, indicarase explicitamente.

11. Documentación complementaria.

Achegarase a documentación relativa a:

(32)

11.1. Garantía dos traballos, indicando nominalmente os seus responsables.

11.2. Certificados de calidade da empresa aplicables á equipa de desenvolvemento do proxecto.

11.3. Identificación do responsable dos datos e políticas de seguridade aplicadas aos datos protexidos proporcionados pola universidade para a realización dos traballos.

Santiago de Compostela, 16 de decembro de 2009 O vicerrector de Economía, Financiamento e Infraestructuras

Por delegación (Resolución reitoral do 31 de xullo de 2007, DOG de 19 de seiembro, modificada por resolución reitoral do 12 de maio de 2009, DOG do 26 de maio de 2009)

Miguel A. Vázquez Taín

(33)

6. ANEXO:INFRAESTRUTURA DISPOÑIBLE

A USC porá a disposición do proxecto de administración electrónica a seguinte infraestrutura:

6.1. Servidores

6.1.1. Bases de datos

Dous servidores adicados coas seguintes características cada un:

- 2 procesadores de cuádruple núcleo Xeon E7330

- 8 GB de RAM

- Conexión de rede SAN: link fibrechannel a 4 Gbps Sobre estes servidores estará dispoñible Oracle 10g coa posibilidade da configuración dun clúster Oracle/RAC

6.1.2. Servidores de aplicacións

Catro servidores virtualizados adicados sobre unha plataforma física análoga á do punto anterior. Cada servidor terá asignados dous cores e 4 GB de RAM.

6.1.3. Almacenamento

Disporase de almacenamento en cabina de discos, cun espazo total dispoñible para o proxecto de administración electrónica de 1 TB por ano. A cabina terá funcionalidades de SAN e NAS, cunha mestura de discos FC/SAS e SATA.

6.1.4. Software

A USC disporá das licenzas dos sistemas operativos Linux, e a base de datos Oracle. Calquera outro software necesario para a plataforma que non sexa gratuíto deberá ser imputado ao proxecto como gasto adicional e computado no importe total da oferta.

6.1.5. Entorno tecnolóxico

A plataforma tecnolóxica estándar para unha aplicación de xestión da USC é a seguinte:

− Base de datos Oracle ou SQL Server

− Servidor de aplicación Tomcat ou WebLogic sobre sistema operativo Linux

Valorarase que a solución se adapte a este esquema e requira da menor cantidade de elementos adicionais sobre estes.

(34)

7. ANEXO:HOSPEDAXE DA PLATAFORMA

As ofertas poderán incluír unha oferta de hospedaxe da plataforma. No caso de facelo, o adxudicatario comprométese a manter a oferta do servizo, nos termos exactos expresados na oferta, incluído o importe, por un período de, polo menos, dous anos contados a partir da sinatura do contrato. A USC poderá optar, durante ese período de tempo, a exercer o dereito a contratar o servizo de hospedaxe nas condicións ofertadas.

O importe do servizo de hospedaxe non será computado como parte do importe da oferta. No caso de optar a USC pola utilización deste servizo, realizarase un contrato diferente do principal.

7.1. Alcance

O servizo de hospedaxe incluirá a posta a disposición de todos os elementos de hardware e software (incluíndo calquera custo pola licenza do seu uso) necesarios para o funcionamento da plataforma.

7.2. Nivel do servizo

A plataforma estará continuamente operativa, conforme ao establecido ao respecto na LEI 11/2007, de 22 de xuño, de acceso electrónico dos cidadáns aos Servizos Públicos e o REAL DECRETO Real Decreto 1671/2009, de 6 de novembro, polo que se desenvolve parcialmente dita lei. As ofertas incluirán unha memoria descritiva dos mecanismos técnicos e nivel de dispoñibilidade ofertados, a súa adecuación á regulamentación anteriormente citada, e os requirimentos da plataforma.

Incluirá soporte dispoñible as 24 horas do día para reportar calquera interrupción ou erro do servizo. As ofertas incluirán a descrición dos niveis de soporte do servizo de hospedaxe, independentemente do soporte xeral da plataforma.

7.3. Seguridade

O servizo de hospedaxe deberá cumprir con todos os requirimentos de seguridade implicados pola lexislación aplicable e polas condicións expresadas na oferta.

A USC designará un responsable de seguridade que será a persoa responsable da xeración e xestión dos certificados utilizados polos servidores.

O servizo de hospedaxe dispoñerá de dispositivos HSM que permitan a custodia segura dos certificados e ofrezan redundancia e alta dispoñibilidade.

O responsable de seguridade será a persoa que xestionará a xeración de certificados nos dispositivos HSM.

(35)

7.4. Acceso á plataforma pola USC

A USC designará as persoas encargadas da monitorización e o acceso á plataforma hospedada. O acceso permitirá a utilización das facilidades de administración da plataforma, incluíndo a obtención da información de auditoría, a configuración de todas as aplicacións e servizos e, en xeral, o acceso en modo só lectura aos servidores que alberguen as aplicacións e servizos.

(36)

8. ANEXO:PLATAFORMAS CLIENTE DE REFERENCIA

As seguintes configuracións deberán estar soportadas polas aplicacións da plataforma. No caso concreto da aplicación de sinatura de documentos custodiados polo usuario, as configuracións subliñadas deberán ser completamente soportadas, sendo desexable que se soporten o resto das combinacións.

8.1. Windows

En contornos windows, as seguintes opcións estarán soportadas. As combinacións de sistema operativo e navegador deberán soportarse cando o navegador estea soportado por Microsoft na versión do sistema operativo considerada.

8.1.1. Sistemas operativos:

• Windows 2000

• Windows XP

• Windows Vista

• Windows 7

8.1.2. Navegadores

• Internet Explorer 6

• Firefox 2

• Firefox 3

8.1.3. Java Runtime

• JRE 1.6

8.2. Linux

8.2.1. Sistemas operativos

• Ubuntu 8.0.4 LTS, Debian 5.0

8.2.2. Navegadores

• Firefox 2

• Firefox 3

8.2.3. Java Runtime

• JRE 1.6

(37)

8.3. Mac OS X

8.3.1. Sistemas operativos

• Mac OS X 10.5 ou superior

8.3.2. Navegadores

• Safari 3

• Safari 4

8.3.3. Java Runtime

• JRE 1.6