ADQUISICIÓN DE SOLUCIÓN DE ALMACENAMIENTO NAS EMPRESARIAL.

2         REQUISITOS DE ADMISIBILIDAD

2.1        La participación en el presente procedimiento de contratación pública implica la aceptación plena e incondicional de todas las disposiciones contenidas en el pliego de condiciones y sus anexos. La oferta presentada deberá cumplir íntegramente con los requisitos legales, técnicos, administrativos y formales establecidos en el presente pliego, así como con la normativa vigente en materia de contratación pública.

2.2        El oferente deberá presentar una carta vigente emitida por el fabricante de la solución NAS ofertada, dirigida al Banco Central de Costa Rica, en la que conste expresamente su respaldo. La carta deberá haber sido emitida dentro de los tres (3) meses anteriores a la fecha de presentación de la oferta, identificar claramente la marca y la plataforma ofertada, e indicar expresamente los siguientes puntos:

1. El oferente se encuentra autorizado para comercializar, implementar y brindar soporte sobre la solución propuesta en Costa Rica.

2. El fabricante respalda la participación del oferente en el presente procedimiento de contratación.

3. La solución ofertada cuenta con soporte oficial del fabricante.

4. La solución dispone de acceso a actualizaciones de software y firmware durante la vigencia del soporte ofrecido.

5. Se garantiza la disponibilidad de repuestos y mecanismos de escalamiento técnico con el fabricante durante todo el período contractual ofertado.

2.3        El oferente deberá acreditar, mediante una carta, constancia, certificación u otro documento idóneo emitido por el cliente o destinatario de los bienes o servicios, que cuenta con experiencia positiva en la implementación de soluciones empresariales de almacenamiento.

2.3.1      Asimismo, deberá demostrar que durante los últimos cuatro (4) años ha ejecutado al menos dos (2) proyectos en Costa Rica, Centroamérica o el Caribe relacionados con la implementación, migración o puesta en operación de soluciones empresariales de almacenamiento con características, capacidades o nivel de complejidad similares o superiores a la solución ofertada.

2.3.2      La documentación aportada deberá evidenciar que los bienes o servicios fueron recibidos a satisfacción, para lo cual deberá completar y aportar en la oferta, el anexo 3 de este documento.

2.4        Certificaciones del fabricante

2.4.1       El fabricante de la solución ofertada deberá demostrar un compromiso formal y verificable con la seguridad de su cadena de suministro, procesos de manufactura y gestión de la seguridad de la información. Para ello deberá contar con al menos una de las siguientes certificaciones internacionales vigentes, emitidas por un organismo de certificación acreditado:

• ISO/IEC 20243 (Open Trusted Technology Provider Standard – O‑TTPS).

• ISO/IEC 27001.

• Evidencia verificable de cumplimiento de NIST SP 800‑53 en nivel Moderado o Alto.

2.4.2       La certificación o evidencia aportada deberá:

1. Encontrarse vigente a la fecha de presentación de la oferta.

2. Haber sido emitida por una entidad de certificación o evaluación reconocida internacionalmente.

3. Corresponder directamente al fabricante de la plataforma ofertada.

2.4.3       El oferente deberá aportar la documentación correspondiente o indicar el enlace público verificable que permita comprobar el cumplimiento de este requisito.

1         ESPECIFICACIONES TÉCNICAS

1.1        ARQUITECTURA GENERAL REQUERIDA

1.1.1      La solución ofertada deberá corresponder a una plataforma NAS empresarial diseñada para la prestación de servicios corporativos de almacenamiento de archivos en entornos de misión crítica.

1.1.2      Las funcionalidades de almacenamiento de archivos deberán ser proporcionadas de forma nativa por la plataforma ofertada y encontrarse soportadas directamente por el fabricante de la solución. No se aceptarán propuestas que requieran componentes externos adicionales para proveer las funcionalidades principales de servicios de archivos solicitadas en el presente cartel.

1.1.3      La arquitectura propuesta deberá permitir la sustitución de la plataforma institucional actualmente utilizada para la prestación de servicios de almacenamiento de archivos, garantizando niveles adecuados de disponibilidad, escalabilidad, rendimiento, protección de datos y continuidad operativa.

1.1.4      La solución deberá suministrarse como una plataforma integrada de almacenamiento de archivos, incluyendo todos los componentes de hardware, software, licenciamiento y servicios necesarios para su correcta implementación y operación.

1.1.5      DISTRIBUCIÓN GEOGRÁFICA DE LA SOLUCIÓN

1.1.5.1     La solución deberá implementarse en los dos centros de datos del Banco Central de Costa Rica.

1.1.5.2     La arquitectura propuesta deberá contemplar componentes instalados en ambos centros de datos y permitir la continuidad de los servicios de almacenamiento de archivos conforme a los mecanismos de disponibilidad y protección de datos definidos en el presente cartel.

1.1.5.3     El oferente deberá describir detalladamente la distribución de los componentes de la solución entre los sitios propuestos.

1.1.6      ALTA DISPONIBILIDAD

1.1.6.1     La arquitectura propuesta deberá diseñarse bajo principios de alta disponibilidad, eliminando puntos únicos de falla (SPOF) en los componentes críticos locales de cada sitio. La plataforma de almacenamiento deberá contar con al menos dos entidades de procesamiento por sitio (tales como controladoras o nodos) operando bajo mecanismos automáticos de redundancia. La falla local de una controladora, nodo, interfaz, fuente de poder o ventilador en el sitio donde se encuentre prestando el servicio no deberá provocar la pérdida de acceso a la información ni la interrupción de los servicios.

1.1.6.2     Para el mantenimiento planificado, actualizaciones de software/firmware y sustitución de partes, la solución deberá permitir esquemas de actualización no disruptiva (NDU), garantizando la continuidad del servicio.

1.1.6.3     Al contemplar una arquitectura de recuperación entre sitios del tipo Activo-Pasivo, el oferente deberá especificar detalladamente los tiempos objetivos de recuperación (RTO) y de punto de recuperación (RPO) ofrecidos. Asimismo, deberá describir los procedimientos de failover, failback y restablecimiento de servicios, detallando cuáles actividades se ejecutan de forma automática y cuáles requieren intervención administrativa.

1.1.7      ESCALABILIDAD DE LA ARQUITECTURA

1.1.7.1     La arquitectura propuesta deberá permitir la ampliación futura de la solución mediante mecanismos oficialmente soportados por el fabricante, sin requerir la sustitución completa de la plataforma inicialmente instalada.

1.1.7.2     La solución deberá permitir la incorporación de recursos adicionales de procesamiento, almacenamiento, conectividad u otros componentes soportados por la arquitectura propuesta, de acuerdo con los mecanismos de crecimiento definidos por el fabricante.

1.1.7.3     El oferente deberá describir las alternativas disponibles para la expansión de la arquitectura ofertada y las consideraciones aplicables para su implementación.

1.1.8      REPLICACIÓN, CONSISTENCIA Y RECUPERACIÓN DE SERVICIOS

1.1.8.1     La solución deberá disponer de mecanismos para permitir la replicación del entorno del servicio hacia el sitio alterno, garantizando la disponibilidad de:

• Los protocolos NAS habilitados para la prestación del servicio (CIFS/SMB, NFS u otros protocolos soportados por la solución ofertada).

• Las políticas de seguridad, permisos (ACLs) y mecanismos de control de acceso asociados al servicio.

• La estructura completa de volúmenes o recursos de almacenamiento asociados al servicio.

 

1.1.8.2     Ante un evento de conmutación (failover), la solución, ya sea mediante capacidades nativas o herramientas de orquestación incluidas en la oferta, deberá permitir que el sitio alterno asuma el servicio y la integración con el Active Directory del Banco, garantizando que el acceso de los usuarios finales y aplicaciones se restablezca sin necesidad de reconfigurar manualmente los recursos de almacenamiento, los protocolos de acceso o los permisos de seguridad.

1.1.8.3     Asimismo, la solución deberá garantizar la consistencia multi-volumen mediante puntos de recuperación coordinados y simultáneos para aquellos volúmenes que conforman una misma unidad de servicio, evitando estados parciales o inconsistentes en el sitio destino.

1.1.8.4     El proceso de conmutación (failover) y reversión (failback) entre sitios será iniciado bajo demanda por el administrador mediante un mecanismo de orquestación centralizado.

1.1.8.5     Una vez iniciado el proceso, la solución deberá ejecutar de forma automática y secuencial todas las tareas necesarias para la activación de volúmenes, habilitación de protocolos de acceso y validación de los mecanismos de acceso y seguridad asociados al servicio, restableciendo la totalidad del servicio de forma conjunta sin requerir tareas de reconfiguración manual elemento por elemento por parte del personal técnico.

1.1.9      CONTINUIDAD OPERATIVA

1.1.9.1     La arquitectura propuesta deberá estar diseñada para soportar las labores normales de mantenimiento preventivo, actualización de software, actualización de firmware y sustitución de componentes defectuosos con la menor afectación posible para los servicios institucionales.

1.1.9.2     El oferente deberá indicar las actividades que pueden ejecutarse de manera no disruptiva y los mecanismos disponibles para minimizar interrupciones durante la operación y mantenimiento de la plataforma.

1.1.10   DIAGRAMA DE ARQUITECTURA

1.1.10.1  Como parte de la oferta técnica, el oferente deberá presentar un diagrama de arquitectura de alto nivel que permita identificar claramente la conformación de la solución propuesta.

1.1.10.2  El diagrama deberá mostrar, como mínimo:

• La distribución de los componentes principales en cada centro de datos.

• Las entidades de procesamiento que forman parte de la solución.

• Los componentes de almacenamiento.

• Los mecanismos de alta disponibilidad implementados.

• Los mecanismos de replicación entre sitios.

• La arquitectura general de conectividad de la plataforma.

1.1.10.3  La información aportada será utilizada por el Banco para validar el cumplimiento de los requisitos arquitectónicos establecidos en el presente cartel.

1.2        ALMACENAMIENTO

1.2.1      PLATAFORMA DE ALMACENAMIENTO

1.2.1.1     La solución deberá proporcionar capacidades empresariales de almacenamiento de archivos diseñadas para soportar cargas de trabajo institucionales, garantizando niveles adecuados de disponibilidad, escalabilidad, rendimiento, confiabilidad y protección de datos.

1.2.1.2     La totalidad de la capacidad ofertada deberá encontrarse integrada dentro de una arquitectura oficialmente soportada por el fabricante de la solución propuesta.

1.2.1.3     El oferente podrá proponer arquitecturas basadas en tecnologías 100% de Estado Sólido (All-Flash) o arquitecturas híbridas (SSD y HDD). Independientemente de la arquitectura física interna propuesta, el oferente deberá describir las características de desempeño de la plataforma ofertada y los mecanismos soportados por el fabricante para optimizar las operaciones de lectura y escritura sobre la información almacenada.

1.2.1.4     La solución deberá permitir la implementación de mecanismos soportados por el fabricante para optimizar la utilización de los recursos de almacenamiento, considerando criterios de capacidad, desempeño y eficiencia operativa.

1.2.1.5     Cuando la solución disponga de funcionalidades de jerarquización (tiering), clasificación, reubicación automática de datos o mecanismos equivalentes, el oferente deberá describir su funcionamiento, beneficios operativos y forma de administración.

1.2.2      Capacidad inicial

1.2.2.1     La solución propuesta deberá suministrar una capacidad útil mínima inicial de 100 TiB en el sitio principal, destinada a la prestación de servicios de almacenamiento de archivos, y una capacidad útil mínima inicial de 100 TiB en el sitio alterno, destinada a la replicación, protección de datos y continuidad operativa de los servicios.

1.2.2.2     Se entenderá por capacidad útil mínima inicial la capacidad física disponible para el almacenamiento de información institucional desde el inicio de la operación de la plataforma, una vez descontada la capacidad requerida por los mecanismos de protección de medios, RAID, Erasure Coding o mecanismos equivalentes; metadatos; sistemas de archivos; espacios de reserva obligatorios; discos de repuesto o capacidad reservada equivalente; sobrecargas del sistema; y cualquier otra capacidad requerida para la operación normal de la solución.

1.2.2.3     La capacidad útil mínima inicial no deberá calcularse aplicando factores o beneficios derivados de deduplicación, compresión, aprovisionamiento delgado u otros mecanismos de reducción o eficiencia de datos.

1.2.3      Crecimiento de capacidad útil

1.2.3.1     La solución deberá permitir el crecimiento futuro de la capacidad útil inicial de almacenamiento al menos a 500 TiB en cada sitio, sin requerir la sustitución completa de la plataforma inicialmente instalada y deberá realizarse mediante mecanismos soportados oficialmente por el fabricante y podrá contemplar la incorporación de medios de almacenamiento, bandejas, nodos, controladoras u otros componentes compatibles con la arquitectura ofertada.

1.2.3.2     El oferente deberá indicar:

• Capacidad útil máxima soportada por la plataforma ofertada por sitio.

• Los incrementos mínimos de capacidad requeridos para cada expansión.

• Los componentes adicionales que serían necesarios para alcanzar la capacidad indicada.

• Limitaciones técnicas asociadas al crecimiento de la plataforma.

• Impacto operativo requerido para realizar ampliaciones futuras.

1.2.4      Protección, Redundancia y Tolerancia a Fallos

1.2.4.1     Protección de Medios (Discos)

1. La solución deberá implementar mecanismos de protección lógica en sus arreglos de almacenamiento (tales como RAID o esquemas equivalentes de dispersión de datos / Erasure Coding) que garanticen la tolerancia a la falla simultánea de al menos dos (2) medios de almacenamiento dentro del mismo grupo de protección, sin pérdida de información, ni indisponibilidad total de los servicios de almacenamiento. El oferente deberá declarar cualquier impacto esperado en capacidad, rendimiento, nivel de protección o tiempo de reconstrucción mientras la plataforma opere en condición degradada.

2. El oferente deberá incluir en su propuesta los discos de repuesto (hot-spare) necesarios, ya sean físicos dedicados o capacidad reservada equivalente dentro del arreglo, según la arquitectura del fabricante.

 

1.2.4.2     Redundancia de Componentes

a) Cada plataforma de almacenamiento instalada en los sitios de la institución deberá contar con una arquitectura de alta disponibilidad de hardware, incluyendo:

• Al menos dos (2) controladoras o nodos de procesamiento operando bajo mecanismos de tolerancia a fallos.

• Fuentes de poder redundantes que permitan la continuidad de operación ante la falla de una unidad individual.

• Módulos de ventilación redundantes.

 

b) Todos los componentes de hardware críticos mencionados (Los medios de almacenamiento, fuentes de poder y módulos de ventilación) deberán ser intercambiables en caliente. Las controladoras, nodos o entidades de procesamiento deberán poder ser retirados, sustituidos o sometidos a mantenimiento sin provocar la interrupción total del servicio ni la pérdida de acceso a la información, conforme a los procedimientos soportados por el fabricante.

 

1.2.5      Reemplazo y mantenimiento de componentes

1.2.5.1     La arquitectura propuesta deberá permitir la sustitución de componentes defectuosos asociados al almacenamiento de conformidad con las mejores prácticas definidas por el fabricante.

1.2.5.2     El oferente deberá indicar cuáles componentes podrán ser reemplazados sin afectar la operación normal de los servicios.

 

1.2.6      Supervisión del almacenamiento

1.2.6.1     La solución deberá proporcionar mecanismos que permitan monitorear, como mínimo:

• Capacidad utilizada.

• Capacidad disponible.

• Estado de los medios de almacenamiento.

• Estado de los componentes críticos asociados al almacenamiento.

• Eventos relacionados con fallos o degradación de componentes.

1.2.6.2     La información deberá encontrarse disponible mediante las herramientas de administración nativas de la solución.

1.2.7      Información técnica requerida en la oferta

1.2.7.1     Como parte de la propuesta técnica, el oferente deberá indicar:

• Capacidad útil inicial ofertada.

• Capacidad máxima soportada por la plataforma.

• Tipo de medios de almacenamiento utilizados.

• Mecanismos de protección implementados.

• Esquema general de crecimiento soportado por la solución.

• Consideraciones utilizadas para el cálculo de la capacidad ofertada.

1.2.7.2     El oferente deberá aportar una Memoria de Cálculo de capacidad para cada sitio que permita verificar la capacidad útil ofertada. Como mínimo deberá indicar la cantidad y capacidad nominal de los medios de almacenamiento, capacidad bruta resultante, capacidad destinada a mecanismos de protección, capacidad de repuesto o reserva equivalente, reservas obligatorias, sobrecargas del sistema y capacidad útil final disponible. Esta Memoria de Cálculo deberá permitir comprobar que la capacidad útil final es igual o superior a 100 TiB por sitio sin aplicar factores de duplicación, compresión u otras eficiencias de datos.

1.2.7.3     Los valores, porcentajes de reserva, sobrecargas y criterios de protección utilizados en la Memoria de Cálculo deberán estar respaldados por documentación oficial del fabricante o por herramientas oficiales de dimensionamiento de la solución ofertada.

1.3        SERVICIOS NAS

1.3.1      Servicios de almacenamiento de archivos

1.3.1.1     La solución deberá proporcionar servicios empresariales de almacenamiento de archivos diseñados para soportar cargas de trabajo corporativas de alta criticidad.

1.3.1.2     La plataforma deberá permitir la creación y administración de recursos compartidos de archivos para usuarios, grupos, aplicaciones y servicios institucionales.

1.3.2      Protocolos de acceso

1.3.2.1     La solución deberá soportar como mínimo los siguientes protocolos de acceso a archivos:

• SMB (Server Message Block).

• NFS (Network File System).

1.3.2.2     El oferente deberá indicar las versiones soportadas por la plataforma ofertada. Como mínimo deberá soportar SMB 2.x, SMB 3.x y SMB 3.1.1 o superiores, así como NFS v3, NFS v4.0, NFS v4.1 o superiores.

1.3.3      Integración con Active Directory

1.3.3.1     La solución deberá integrarse de forma nativa con Microsoft Active Directory.

1.3.3.2     La integración con Active Directory deberá permitir la preservación de usuarios, grupos y permisos existentes durante los procesos de migración definidos para el proyecto.

1.3.3.3     La integración deberá permitir como mínimo:

• Autenticación de usuarios y grupos.

• Resolución de identidades.

• Aplicación de permisos basados en usuarios y grupos de Active Directory.

• Administración de recursos compartidos utilizando identidades del dominio institucional.

1.3.3.4     El oferente deberá describir los mecanismos de integración soportados por la plataforma propuesta.

1.3.4      Administración de recursos compartidos

1.3.4.1     La solución deberá permitir la creación, modificación y eliminación de recursos compartidos de archivos mediante interfaces gráficas de administración.

1.3.4.2     Asimismo, deberá permitir la configuración independiente de permisos y políticas de acceso para cada recurso compartido.

1.3.5      Control de acceso y permisos

1.3.5.1     La solución deberá soportar mecanismos de control de acceso que permitan asignar permisos sobre archivos y directorios de manera granular.

1.3.5.2     La plataforma deberá permitir la administración de permisos compatibles con entornos Microsoft Windows y Active Directory.

1.3.6      Cuotas de almacenamiento

1.3.6.1     La solución deberá permitir la definición y administración de cuotas de almacenamiento para recursos compartidos, usuarios, grupos o mecanismos equivalentes soportados por el fabricante.

1.3.6.2     El oferente deberá indicar las capacidades disponibles para la administración y monitoreo de dichas cuotas.

1.3.7      Administración de auditoría y trazabilidad

1.3.7.1     La solución deberá proporcionar mecanismos que permitan registrar eventos relacionados con el acceso y administración de la información almacenada.

1.3.7.2     Como mínimo, deberá ser posible registrar eventos asociados a:

• Acceso a recursos compartidos.

• Modificación de configuraciones.

• Administración de usuarios y permisos.

• Eventos de seguridad.

1.3.7.3     El oferente deberá describir las capacidades de auditoría incorporadas en la solución propuesta.

1.3.8      Administración centralizada

1.3.8.1     La solución deberá proporcionar herramientas de administración que permitan gestionar la totalidad de los componentes de la plataforma desde una interfaz unificada.

1.3.8.2     La consola de administración deberá permitir como mínimo:

• Supervisión del estado general de la plataforma.

• Administración de recursos compartidos.

• Administración de usuarios y permisos.

• Administración de capacidad.

• Administración de alertas y eventos.

1.3.9      Disponibilidad de los servicios NAS

1.3.9.1     La prestación de los servicios NAS deberá mantenerse operativa ante la falla de componentes redundantes de la solución, de conformidad con los mecanismos de alta disponibilidad definidos por el fabricante.

1.3.9.2     La pérdida de una controladora, nodo, interfaz de red, medio de almacenamiento o cualquier otro componente protegido por los mecanismos de redundancia implementados no deberá provocar la indisponibilidad total de los recursos compartidos de archivos.

1.3.9.3     El oferente deberá describir los mecanismos de continuidad operativa, redundancia y recuperación soportados por la solución propuesta.

1.3.10   Continuidad de acceso a recursos compartidos

1.3.10.1  La solución deberá proporcionar mecanismos que permitan mantener la disponibilidad lógica de los recursos compartidos de archivos ante eventos de falla de componentes, indisponibilidad de un sitio, activación de mecanismos de recuperación, conmutación por falla (failover) o cualquier otro mecanismo de continuidad operativa soportado por la plataforma.

1.3.10.2  La arquitectura propuesta deberá permitir que los usuarios continúen accediendo a los recursos compartidos mediante las mismas rutas lógicas de acceso definidas por la Administración, sin requerir modificaciones manuales en estaciones de trabajo, servidores, aplicaciones, scripts, unidades de red mapeadas o configuraciones de acceso como consecuencia de eventos de continuidad operativa o cambio de sitio.

1.3.10.3  El oferente deberá describir los mecanismos incorporados en la solución propuesta para garantizar la continuidad de acceso a los recursos compartidos y la preservación de las rutas lógicas utilizadas por los usuarios y sistemas institucionales.

1.4        PROTECCIÓN DE DATOS

1.4.1      Consideraciones generales

1.4.1.1     La solución deberá incorporar mecanismos empresariales de protección de datos orientados a garantizar la integridad, disponibilidad y recuperación de la información almacenada.

1.4.1.2     Las funcionalidades de protección de datos deberán encontrarse integradas nativamente en la plataforma ofertada o formar parte de componentes oficialmente soportados por el fabricante.

1.4.2      Seguridad de la cadena de suministro y gestión de seguridad

1.4.2.1     El fabricante de la solución ofertada deberá demostrar un compromiso formal y verificable con la seguridad de su cadena de suministro, procesos de manufactura y gestión de la seguridad de la información.

1.4.2.2     Para ello, deberá contar con al menos uno de los siguientes mecanismos de certificación o cumplimiento:

• ISO/IEC 20243 (Open Trusted Technology Provider Standard - OTTPS).

• ISO/IEC 27001.

• Evidencia verificable de cumplimiento de NIST SP 800-53 en nivel Moderado o Alto.

1.4.2.3     La certificación o evidencia aportada deberá encontrarse vigente a la fecha de presentación de la oferta, haber sido emitida por una entidad reconocida internacionalmente y corresponder directamente al fabricante de la plataforma ofertada. El oferente deberá aportar la documentación correspondiente o indicar el enlace público verificable que permita comprobar su cumplimiento.

1.4.3      Snapshots

1.4.3.1     La solución deberá permitir la creación y administración de copias instantáneas (snapshots) de manera nativa mediante herramientas soportadas por el fabricante, sin afectar significativamente el rendimiento normal de la plataforma.

1.4.3.2     Como mínimo, deberá permitir:

• Creación manual y automática de snapshots mediante mecanismos soportados por el fabricante.

• Definición de políticas programadas para la generación de snapshots (horarias, diarias, semanales o equivalentes).

• Administración de períodos de retención y capacidades de protección contra modificación o eliminación cuando dichas funcionalidades sean soportadas por la solución.

• Recuperación ágil de información a partir de snapshots, permitiendo la restauración de archivos, carpetas o volúmenes completos.

1.4.3.3     El oferente deberá describir las capacidades de programación, retención, escalabilidad y recuperación soportadas por la solución propuesta, indicando además si dichas funcionalidades se encuentran incluidas y licenciadas para ambos sitios desde el inicio de la operación.

1.4.4      Recuperación de información

1.4.4.1     La solución deberá permitir la recuperación de información almacenada sin requerir necesariamente la restauración completa de volúmenes o sistemas de archivos.

1.4.4.2     Como mínimo, deberá permitir la recuperación de:

• Archivos individuales.

• Directorios

• Recursos compartidos.

• Volúmenes o equivalentes definidos por el fabricante.

1.4.4.3     El oferente deberá describir los mecanismos disponibles para realizar dichas recuperaciones.

1.4.5      Replicación

1.4.5.1     La solución deberá disponer de mecanismos de replicación nativos que permitan mantener copias de protección de la información entre los sitios definidos por el Banco Central de Costa Rica conservando la consistencia de la información protegida.

1.4.5.2     El oferente deberá indicar:

• Modalidades de replicación soportadas.

• Mecanismos de sincronización disponibles.

• Capacidades de recuperación asociadas.

• Mecanismos utilizados para garantizar la integridad de la información replicada.

1.4.6      Protección mediante almacenamiento inmutable (WORM)

1.4.6.1     La solución deberá soportar mecanismos de almacenamiento inmutable tipo WORM (Write Once Read Many) para la protección de información crítica. Estos mecanismos deberán encontrarse soportados nativamente por la solución o por componentes oficialmente soportados por el fabricante.

1.4.6.2     Dichos mecanismos deberán impedir la modificación o eliminación de la información protegida durante los períodos de retención definidos.

1.4.6.3     El oferente deberá indicar:

• Modalidades de protección soportadas.

• Mecanismos de retención disponibles.

• Capacidades de administración asociadas.

1.4.7      Protección ante ransomware

1.4.7.1     La solución deberá incorporar capacidades orientadas a fortalecer la protección de la información ante eventos de corrupción, alteración o eliminación maliciosa de datos.

1.4.7.2     El oferente deberá describir las funcionalidades disponibles en la plataforma para contribuir a la recuperación y protección de la información frente a este tipo de incidentes.

1.4.7.3     El oferente deberá indicar si la solución incorpora capacidades nativas relacionadas con:

• Protección mediante snapshots inmutables.

• Detección de comportamientos anómalos.

• Alertamiento de eventos sospechosos.

• Capacidades de recuperación y restauración eficiente de información ante eventos de corrupción, alteración o eliminación de datos

1.4.8      Auditoría y trazabilidad

1.4.8.1     La solución deberá proporcionar mecanismos que permitan consultar, conservar y administrar la información de auditoría generada por la plataforma.

1.4.8.2     La información de auditoría deberá incluir eventos relacionados con la administración, seguridad y utilización de los servicios prestados por la solución.

1.4.8.3     El oferente deberá describir las capacidades disponibles para la consulta, conservación, búsqueda y exportación de la información de auditoría, así como cualquier limitación o consideración aplicable a dichas funcionalidades.

1.4.9      Integridad de la información

1.4.9.1     La solución deberá incorporar mecanismos nativos soportados por el fabricante que permitan preservar la integridad y consistencia de la información almacenada, mitigar el impacto de fallas y garantizar la recuperación consistente de la plataforma.

1.4.9.2     Como mínimo, la solución deberá:

• Incorporar mecanismos de protección que permitan preservar de forma segura las operaciones de escritura pendientes ante eventos de pérdida de energía o fallas inesperadas, evitando la pérdida o corrupción de información.

• Implementar mecanismos de validación de integridad que permitan detectar condiciones de corrupción de datos, inconsistencias de almacenamiento o eventos de corrupción silenciosa de la información.

• Incorporar procesos de verificación periódica de integridad y mecanismos de corrección o recuperación soportados por el fabricante cuando dichas capacidades formen parte de la solución propuesta.

• Garantizar la consistencia lógica del sistema de archivos y la recuperación automática de los servicios después de interrupciones inesperadas, sin requerir procedimientos manuales extensivos de reparación o reconstrucción.

1.4.9.3     El oferente deberá describir los mecanismos de hardware y software implementados por la solución para cumplir con los requisitos de integridad, consistencia y recuperación indicados en este apartado.

1.4.10   Información técnica requerida en la oferta

1.4.10.1  Como parte de la propuesta técnica, el oferente deberá describir las capacidades, funcionalidades, alcances, limitaciones y consideraciones de implementación asociadas a los mecanismos de protección de datos, continuidad operativa, recuperación, auditoría, seguridad e integridad soportados por la solución ofertada.

1.4.10.2  La documentación aportada deberá incluir las referencias técnicas, manuales, hojas de datos o documentación oficial del fabricante que permitan verificar dichas capacidades cuando corresponda.

1.5        CONECTIVIDAD E INTEGRACIÓN CON LA INFRAESTRUCTURA INSTITUCIONAL

1.5.1      Consideraciones generales

1.5.1.1     La solución ofertada deberá contar con una arquitectura de comunicaciones que garantice la separación entre el tráfico de prestación de servicios (Front-End), el tráfico de administración (Out-of-Band) y las comunicaciones internas requeridas para la operación de la plataforma (Back-End), ya sea mediante redes físicas independientes o mecanismos equivalentes soportados por el fabricante.

1.5.1.2     La solución deberá soportar conectividad IPv4 e IPv6.

1.5.1.3     El oferente deberá suministrar todos los módulos ópticos, transceptores, cables de fibra óptica, cables UTP, patch cords, adaptadores, conectores y cualquier otro componente requerido para la correcta instalación y operación de la solución ofertada.

1.5.1.4     No se aceptarán requerimientos adicionales de hardware, software o licenciamiento no incluidos en la oferta para habilitar la operación normal de la plataforma, sus mecanismos de alta disponibilidad, balanceo de carga, replicación o cualquier otra funcionalidad ofertada.

1.5.2      Conectividad Front-End

1.5.2.1     La solución deberá contar con interfaces redundantes para la prestación de servicios NAS.

1.5.2.2     Cada interfaz de servicio deberá soportar una velocidad mínima de 25 GbE.

1.5.2.3     La pérdida de un enlace, interfaz o componente de conectividad no deberá provocar la interrupción del acceso a la información almacenada.

1.5.2.4     El Banco Central de Costa Rica proporcionará la infraestructura institucional de switching requerida para la conectividad Front-End.

1.5.2.5     El oferente deberá indicar expresamente la cantidad de interfaces de servicio requeridas para la implementación de la solución ofertada, especificando como mínimo:

• Cantidad de interfaces por controladora, nodo o entidad de procesamiento.

• Velocidad nominal de cada interfaz.

• Tipo de interfaz física.

• Función dentro de la arquitectura propuesta.

• Mecanismos de redundancia implementados.

• Mecanismos de balanceo o distribución de carga implementados.

1.5.2.6     La cantidad de interfaces declaradas deberá corresponder a la configuración mínima requerida para garantizar los niveles de disponibilidad, resiliencia y desempeño ofertados.

1.5.3      Conectividad Back-End

1.5.3.1     La solución deberá contar con una arquitectura interna de comunicaciones que permita las funciones de clustering, sincronización, redistribución de datos, reconstrucción ante fallos, balanceo de carga, gestión de metadatos y demás funciones requeridas para la operación normal de la plataforma.

1.5.3.2     La arquitectura propuesta deberá garantizar que el tráfico interno del sistema no genere contención ni degradación significativa sobre el tráfico de servicio.

1.5.3.3     El oferente deberá describir detalladamente la arquitectura de conectividad interna de la solución, incluyendo las tecnologías utilizadas, capacidades de ancho de banda y mecanismos implementados para asegurar la continuidad operativa y el desempeño de la plataforma.

1.5.3.4     La solución deberá incluir todos los componentes requeridos para dichas comunicaciones internas.

1.5.3.5     En caso de que la arquitectura ofertada requiera dispositivos o componentes externos para soportar las comunicaciones Back-End, éstos deberán ser suministrados, instalados, configurados y soportados por el contratista como parte integral de la solución.

1.5.3.6     Para las comunicaciones entre sitios o para funcionalidades que requieran interconexión mediante redes externas a la plataforma, el oferente podrá utilizar la infraestructura de red institucional suministrada por el Banco. En tal caso, deberá indicar los requisitos de conectividad, ancho de banda, protocolos, puertos de comunicación y demás dependencias técnicas necesarias para la correcta operación de la solución propuesta.

1.5.4      Red de administración (Out-of-Band)

1.5.4.1     La solución deberá disponer de al menos una interfaz física dedicada de administración por cada controladora, nodo o entidad de procesamiento que forme parte de la solución.

1.5.4.2     Las interfaces de administración deberán ser independientes de las interfaces utilizadas para la prestación de los servicios NAS.

1.5.4.3     Dichas interfaces deberán permitir la administración, monitoreo, diagnóstico y mantenimiento de la plataforma.

1.5.4.4     La solución deberá soportar mecanismos de administración segura mediante protocolos estándar, incluyendo como mínimo HTTPS y SSH.

1.5.4.5     La pérdida o indisponibilidad de las interfaces Front-End no deberá impedir el acceso administrativo a la plataforma mediante las interfaces de administración dedicadas.

1.5.4.6     El Banco Central de Costa Rica proporcionará la conectividad requerida para las interfaces de administración mediante la infraestructura institucional de gestión.

1.5.4.7     Las interfaces de administración deberán soportar conectividad Ethernet 10/100/1000 Mbps.

1.5.5      Diagrama de conectividad

1.5.5.1     Como parte de la oferta técnica, el oferente deberá presentar un diagrama de conectividad de alto nivel de la solución propuesta.

1.5.5.2     El diagrama deberá identificar como mínimo:

• Controladoras, nodos o entidades de procesamiento que conforman la solución.

• Interfaces Front-End utilizadas para la prestación de servicios.

• Interfaces de administración (Out-of-Band).

• Componentes de conectividad interna (Back-End).

• Dispositivos de interconexión requeridos para la operación de la solución, cuando corresponda.

• Velocidades de los enlaces utilizados.

• Esquemas de redundancia implementados.

• Cantidad total de puertos requeridos por sitio para las redes Front-End y de administración.

1.5.5.3     La información aportada será utilizada por el Banco para validar la arquitectura ofertada y planificar la integración de la solución con la infraestructura institucional de comunicaciones.

1.6        ADMINISTRACIÓN Y MONITOREO

1.6.1      Administración centralizada

1.6.1.1     La solución deberá proporcionar una plataforma de administración centralizada que permita gestionar la totalidad de los componentes que conforman la solución ofertada desde una interfaz unificada.

1.6.1.2     La consola de administración deberá permitir, como mínimo:

• Administración de la capacidad de almacenamiento.

• Creación y gestión de recursos compartidos.

• Administración de usuarios, grupos y permisos.

• Configuración de políticas de protección de datos.

• Administración de mecanismos de replicación.

• Administración de snapshots y funcionalidades de recuperación.

• Gestión de alertas y eventos.

• Supervisión de la salud general de la plataforma.

1.6.1.3     El oferente deberá indicar las capacidades de administración disponibles y los componentes que pueden administrarse desde la interfaz propuesta.

1.6.1.4     Cuando la plataforma de administración requiera componentes independientes de la solución principal para su funcionamiento, éstos deberán ser suministrados para su instalación dentro de la infraestructura institucional del Banco y ser compatibles con el entorno de virtualización VMware vSphere utilizado por la Institución.

1.6.2      Interfaz de administración

1.6.2.1     La solución deberá disponer de una interfaz gráfica de administración basada en tecnologías web que permita realizar las labores habituales de operación, supervisión y configuración de la plataforma.

1.6.2.2     La interfaz deberá soportar acceso seguro mediante HTTPS.

1.6.2.3     La administración de la solución no deberá depender exclusivamente de herramientas instaladas localmente en estaciones de trabajo específicas.

1.6.3      Administración basada en roles

1.6.3.1     La solución deberá permitir la definición y administración de diferentes perfiles de usuarios administrativos mediante mecanismos de control de acceso basados en roles (RBAC) o funcionalidades equivalentes soportadas por el fabricante.

1.6.3.2     Deberá ser posible asignar permisos diferenciados de administración según las funciones y responsabilidades definidas por el Banco.

1.6.4      Monitoreo de la infraestructura

1.6.4.1     La solución deberá proporcionar capacidades de monitoreo que permitan supervisar como mínimo:

• Estado de controladoras, nodos o componentes de procesamiento.

• Estado del almacenamiento.

• Utilización de capacidad.

• Estado de interfaces de red.

• Estado de componentes redundantes.

• Replicación de datos.

• Estado de snapshots.

• Eventos de error o degradación.

• Utilización de recursos de la plataforma.

1.6.4.2     La información deberá estar disponible mediante las herramientas nativas de administración suministradas por el fabricante.

1.6.5      Alertamiento y notificaciones

1.6.5.1     La solución deberá contar con mecanismos de generación de alertas para eventos operativos, administrativos y de infraestructura.

1.6.5.2     Como mínimo deberá poder generar alertas asociadas con:

• Fallos de hardware.

• Fallos de discos o medios de almacenamiento.

• Pérdida de redundancia.

• Problemas de conectividad.

• Fallos en procesos de replicación.

• Problemas asociados a snapshots o mecanismos de protección.

• Alcance de umbrales de capacidad configurables.

1.6.5.3     El oferente deberá indicar los mecanismos de notificación soportados por la solución.

1.6.6      Registros y trazabilidad

1.6.6.1     La solución deberá mantener registros de eventos operativos y administrativos que faciliten las labores de auditoría, diagnóstico y análisis de incidentes.

1.6.6.2     Como mínimo deberán registrarse eventos relacionados con:

• Inicio y cierre de sesión administrativos.

• Cambios de configuración.

• Administración de recursos compartidos.

• Administración de permisos.

• Eventos de seguridad.

• Fallos de componentes.

• Eventos asociados a la protección de datos.

1.6.6.3     Los registros deberán disponer de marcas de tiempo y mecanismos que permitan su consulta mediante las herramientas de administración de la solución.

1.6.7      Integración con plataformas de monitoreo

1.6.7.1     La solución deberá soportar mecanismos estándar de integración con plataformas de monitoreo y gestión existentes en el Banco.

1.6.7.2     El oferente deberá indicar los protocolos, servicios o mecanismos de integración soportados por la solución propuesta.

1.6.8      Información histórica y análisis de capacidad

1.6.8.1     La solución deberá proporcionar información histórica que permita realizar análisis de utilización y crecimiento de la plataforma.

1.6.8.2     Como mínimo deberá ser posible consultar información relacionada con:

• Crecimiento de capacidad.

• Utilización de almacenamiento.

• Tendencias de consumo.

• Eventos relevantes de operación.

1.6.8.3     El oferente deberá describir las capacidades disponibles para análisis histórico y planificación de capacidad.

1.6.9      Monitoreo Proactivo, Telemetría y Analítica

1.6.9.1     La solución deberá disponer de mecanismos soportados por el fabricante para la recopilación de telemetría, monitoreo proactivo y análisis operativo de la plataforma durante todo el período de soporte contratado.

1.6.9.2     La solución deberá proporcionar información relacionada con:

• Estado de salud general de la plataforma.

• Utilización de capacidad y tendencias de crecimiento.

• Utilización de recursos de procesamiento y almacenamiento.

• Efectividad de las funcionalidades de eficiencia de datos soportadas por la solución.

• Estado de componentes críticos y eventos relevantes para la operación.

1.6.9.3     Asimismo, deberá permitir la identificación de condiciones que puedan afectar la operación de la plataforma, incluyendo:

• Vulnerabilidades conocidas asociadas al software de la solución.

• Eventos de capacidad.

• Degradación de desempeño.

• Riesgos operativos identificados por el fabricante cuando dichas capacidades sean soportadas por la solución propuesta.

1.6.9.4     Cuando la solución disponga de capacidades de soporte proactivo, diagnóstico remoto, generación automática de casos de soporte o mecanismos equivalentes, el oferente deberá describir su funcionamiento, alcance y los requisitos de conectividad necesarios para su operación, indicando si dichas capacidades operan mediante componentes locales (On-Premises), servicios basados en la nube (Cloud) o esquemas híbridos.

1.6.9.5     Asimismo, deberá indicarse la información o telemetría transmitida, los mecanismos de protección utilizados durante la transmisión y cualquier dependencia de conectividad requerida para el adecuado funcionamiento de estas capacidades.

1.6.9.6     Las capacidades de monitoreo, analítica y soporte proactivo ofrecidas deberán permanecer disponibles durante todo el período de soporte contratado.

1.6.10   Información técnica requerida en la oferta

1.6.10.1  Como parte de la propuesta técnica, el oferente deberá indicar:

• Herramientas de administración incluidas.

• Capacidades de administración centralizada disponibles.

• Funcionalidades de monitoreo incorporadas.

• Capacidades de generación de alertas.

• Capacidades de auditoría y trazabilidad.

• Mecanismos de integración con plataformas externas de monitoreo.

• Capacidades disponibles para análisis de capacidad y generación de reportes.

• Capacidades de telemetría, monitoreo proactivo, soporte predictivo, diagnóstico remoto y analítica operacional soportadas por la solución, cuando dichas funcionalidades se encuentren disponibles.

• Requisitos de conectividad asociados a estas funcionalidades, incluyendo la utilización de componentes On-Premises, servicios en la nube o esquemas híbridos, cuando corresponda.

1.7        IMPLEMENTACIÓN Y MIGRACIÓN

1.7.1      Consideraciones generales

1.7.1.1     El contratista será responsable de realizar la totalidad de las actividades necesarias para la instalación, configuración, integración, puesta en operación y migración de la solución ofertada.

1.7.1.2     Todos los trabajos deberán ejecutarse en coordinación con el Administrador del Contrato y siguiendo los procedimientos institucionales aplicables al ingreso, instalación y puesta en producción de infraestructura tecnológica.

1.7.1.3     La solución deberá quedar completamente instalada, configurada, integrada y operativa a satisfacción del Banco Central de Costa Rica.

1.7.2      Plan de implementación

1.7.2.1     Como parte de la ejecución contractual, el contratista deberá elaborar y presentar un plan de implementación para aprobación del Banco.

1.7.2.2     Como mínimo, dicho plan deberá contemplar:

• Actividades de instalación física.

• Configuración inicial de la solución.

• Integración con la infraestructura institucional.

• Configuración de servicios NAS.

• Configuración de mecanismos de alta disponibilidad.

• Configuración de replicación.

• Configuración de protección de datos.

• Actividades de validación y pruebas.

• Cronograma general de ejecución.

1.7.2.3     El inicio de las labores de implementación estará sujeto a la aprobación del plan correspondiente por parte del Banco.

1.7.3      Instalación y configuración

1.7.3.1     Previo al inicio de las actividades de instalación, configuración, integración o migración, el contratista deberá presentar al Administrador del Contrato la identificación del personal técnico designado para la ejecución del proyecto, incluyendo las certificaciones vigentes correspondientes y la descripción de su participación en las actividades del proyecto.

1.7.4      El contratista deberá disponer de la capacidad técnica necesaria para realizar las actividades de instalación, configuración, integración, migración, pruebas y puesta en operación de la solución ofertada.

1.7.4.1     Para la ejecución del proyecto deberá contar, como mínimo, con dos (2) recursos técnicos certificados por el fabricante de la solución ofertada.

1.7.4.2     Como parte de la oferta técnica, el oferente deberá identificar los recursos propuestos para la ejecución del proyecto e indicar:

• Perfil técnico.

• Certificaciones vigentes relacionadas con la solución ofertada.

• Participación prevista dentro del proyecto.

• Experiencia relevante asociada a labores de implementación, migración o soporte de la plataforma ofertada.

1.7.4.3     Estos recursos deberán participar en las etapas de implementación, migración, validación, pruebas y puesta en producción de la solución.

1.7.5      El contratista deberá realizar la instalación física y lógica de la totalidad de los componentes que conforman la solución ofertada. Como mínimo deberá ejecutar:

• Instalación física de la solución.

• Configuración de almacenamiento.

• Configuración de servicios NAS.

• Integración con Active Directory.

• Configuración de mecanismos de protección de datos.

• Configuración de monitoreo y administración.

• Integración con las redes institucionales definidas por el Banco.

La totalidad de los componentes deberá quedar configurada conforme a las mejores prácticas recomendadas por el fabricante.

1.7.6      Pruebas de funcionamiento

1.7.6.1     Previo a la puesta en operación de la solución, el contratista deberá ejecutar las pruebas necesarias para verificar el correcto funcionamiento de la plataforma.

1.7.6.2     Como mínimo deberán realizarse pruebas relacionadas con:

• Acceso a servicios NAS.

• Alta disponibilidad.

• Failover

• Replicación.

• Acceso administrativo.

• Protección de datos.

• Integración con Active Directory.

• Operación general de la plataforma.

1.7.6.3     El contratista deberá documentar los resultados obtenidos y presentarlos al Banco para su revisión.

1.7.7      Puesta en operación

1.7.7.1     Se considerará que la solución ha sido puesta en operación cuando:

• La totalidad de los componentes se encuentre instalada.

• La configuración haya sido completada.

• Las integraciones requeridas hayan sido realizadas.

• Las pruebas de funcionamiento hayan concluido satisfactoriamente.

• El Banco haya otorgado el visto bueno correspondiente.

1.7.7.2     A partir de este momento podrá iniciarse formalmente el proceso de migración de información.

1.7.8      Migración de información

1.7.8.1     Como parte de la contratación, el contratista deberá realizar la migración de la información que el Banco determine desde la plataforma actual hacia la nueva solución NAS.

1.7.8.2     La migración deberá ejecutarse mediante procedimientos controlados que minimicen los riesgos para la disponibilidad e integridad de la información institucional.

1.7.8.3     El contratista deberá presentar para aprobación un plan de migración que contemple como mínimo:

• Metodología de migración.

• Cronograma

• Dependencias técnicas.

• Estrategia de validación.

• Procedimientos de reversión.

• Gestión de riesgos.

1.7.8.4     La migración deberá realizarse en coordinación con el Banco y conforme a los lineamientos establecidos en el Plan Operativo de Migración definido para el proyecto.

1.7.9      Plan Operativo de Migración

1.7.9.1     Previo al inicio de cualquier actividad de migración productiva, deberá existir un Plan Operativo de Migración validado por los responsables institucionales del servicio de almacenamiento de archivos.

1.7.9.2     El Plan Operativo de Migración utilizará como insumo el plan general presentado por el contratista y tendrá como objetivo definir la ejecución detallada de las actividades de migración dentro del entorno institucional.

1.7.9.3     Como mínimo deberá contemplar:

• Identificación de los recursos compartidos incluidos en cada fase u oleada de migración.

• Orden de ejecución de las actividades de migración.

• Ventanas de mantenimiento autorizadas.

• Responsables de cada actividad.

• Procedimientos de validación funcional.

• Puntos de control antes, durante y después de cada migración.

• Plan de comunicación con las áreas usuarias.

• Procedimientos de escalamiento.

• Estrategia de reversión (rollback) ante contingencias

1.7.9.4     La migración productiva no podrá iniciarse hasta que el Plan Operativo de Migración haya sido revisado y validado por los responsables institucionales correspondientes

1.7.10   Validación de la migración

1.7.10.1  Finalizada cada fase de migración, el contratista deberá colaborar con el Banco en la ejecución de las validaciones requeridas.

1.7.10.2  Como mínimo deberán validarse:

• Integridad de la información migrada.

• Disponibilidad de los recursos compartidos.

• Conservación de permisos y controles de acceso.

• Acceso de usuarios autorizados.

• Integración con Active Directory.

• Operación de los mecanismos de respaldo.

• Operación de snapshots o mecanismos equivalentes.

• Integración con los mecanismos institucionales de monitoreo y alertas.

1.7.10.3  Las inconsistencias atribuibles al proceso de migración deberán ser corregidas por el contratista sin costo adicional para la Administración.

1.7.11   Documentación de implementación y migración

1.7.11.1  Al finalizar los trabajos, el contratista deberá entregar la documentación técnica correspondiente.

1.7.11.2  Como mínimo deberá incluir:

• Arquitectura implementada.

• Diagramas actualizados.

• Configuración realizada.

• Procedimientos de operación.

• Procedimientos de recuperación.

• Informe de pruebas.

• Informe de migración.

• Recomendaciones operativas del fabricante.

1.7.12   Responsabilidad de la migración

1.7.12.1  La responsabilidad sobre la ejecución técnica de la migración corresponderá al contratista.

1.7.12.2  El Banco proporcionará el acceso, acompañamiento técnico e información necesaria para la ejecución de las actividades definidas dentro del alcance del proyecto.

1.7.12.3  El contratista deberá garantizar la participación de los recursos técnicos certificados definidos en el apartado de admisibilidad durante las actividades de implementación, pruebas y migración.

1.8        SOPORTE Y GARANTÍA

1.8.1      Garantía de la solución

1.8.1.1     La totalidad de los componentes de hardware, software, licenciamiento y demás elementos que conforman la solución ofertada deberán contar con garantía y soporte integral por un período mínimo de treinta y seis (36) meses, contado a partir de la recepción definitiva de la solución.

1.8.1.2     La garantía deberá comprender, como mínimo:

• La reparación o sustitución de componentes defectuosos.

• El soporte técnico especializado requerido para el diagnóstico, restauración y resolución de incidentes.

• El acceso a actualizaciones, correcciones, parches de seguridad y versiones de software y firmware liberadas por el fabricante para la solución ofertada.

• El acceso a los mecanismos oficiales de escalamiento técnico definidos por el fabricante.

• La disponibilidad de repuestos y componentes requeridos para mantener la solución en correcto funcionamiento.

• La mano de obra, desplazamientos, instalación, configuración, pruebas y demás actividades requeridas para la atención de los incidentes cubiertos por la garantía.

• La totalidad de los costos asociados con la atención de incidentes cubiertos por la garantía deberá encontrarse incluida en la oferta, sin costo adicional para el Banco.

1.8.2      Alcance del soporte

1.8.2.1     El servicio de soporte deberá cubrir la totalidad de los componentes que conforman la solución implementada en ambos centros de datos, incluyendo hardware, software, firmware, licenciamiento, herramientas de administración y componentes complementarios suministrados como parte de la solución.

1.8.2.2     Como mínimo, el soporte deberá incluir:

• Recepción y atención de incidentes.

• Diagnóstico de fallas.

• Restauración de los servicios afectados.

• Reparación o sustitución de componentes defectuosos.

• Asistencia técnica especializada.

• Escalamiento al fabricante cuando corresponda.

• Soporte para los mecanismos de alta disponibilidad.

• Soporte para las funcionalidades de replicación, snapshots, protección de datos, administración y monitoreo.

• Recolección y análisis de registros, diagnósticos y demás información técnica requerida para la resolución de incidentes.

• Acompañamiento técnico para la instalación de actualizaciones, correcciones y firmware cuando resulte necesario.

1.8.3      Horario y modalidad de atención

1.8.3.1     El soporte deberá encontrarse disponible bajo las siguientes modalidades:

1.8.3.1.1    Incidentes de severidad 1, crítica, y severidad 2, alta: cobertura durante las veinticuatro (24) horas del día, los siete (7) días de la semana, incluyendo fines de semana y días feriados.

1.8.3.1.2     Incidentes de severidad 3, media, y severidad 4, baja: cobertura de lunes a viernes, de las 8:00 a las 17:00 horas de Costa Rica, excepto días feriados.

1.8.3.2      El contratista deberá disponer, como mínimo, de los siguientes canales oficiales para la apertura y seguimiento de incidentes:

• Portal de soporte o sistema de gestión de casos.

• Atención telefónica.

• Correo electrónico.

 

1.8.3.3     El contratista deberá proporcionar al Banco los datos, credenciales, procedimientos y contactos requeridos para la apertura, consulta, actualización y escalamiento de los casos.

1.8.3.4     Los tiempos correspondientes a los niveles de servicio se contabilizarán a partir de la fecha y hora en que el incidente sea registrado mediante cualquiera de los canales oficiales habilitados.

1.8.4      Clasificación de incidentes

Los incidentes serán clasificados según su impacto sobre la disponibilidad, integridad, redundancia y operación de la solución:

1.8.4.1     Severidad 1, crítica

Se clasificará como severidad 1 cualquier incidente que presente una o más de las siguientes condiciones:

 

• Indisponibilidad total de los servicios NAS.

• Pérdida generalizada de acceso a la información.

• Pérdida o corrupción de información institucional.

• Imposibilidad de recuperar información requerida para la continuidad de los servicios.

• Falla simultánea de componentes que comprometa la operación de la plataforma.

• Condición que comprometa de manera inmediata la integridad de la información o la continuidad de los servicios institucionales.

1.8.4.2     Severidad 2, alta

Se clasificará como severidad 2 cualquier incidente que presente una o más de las siguientes condiciones:

 

• Degradación significativa de los servicios NAS.

• Pérdida de redundancia que deje la solución expuesta ante una falla adicional.

• Falla de replicación entre los centros de datos.

• Indisponibilidad de un componente principal sin interrupción total del servicio.

• Afectación importante sobre el rendimiento, protección o disponibilidad de la plataforma.

• Falla que afecte un grupo relevante de usuarios, aplicaciones o recursos compartidos sin causar indisponibilidad total.

1.8.4.3     Severidad 3, media

Se clasificará como severidad 3 cualquier incidente que produzca una afectación parcial sin impedir la operación general de la plataforma, incluyendo:

 

• Falla de una funcionalidad secundaria.

• Alertas persistentes que requieran diagnóstico.

• Problemas operativos que dispongan de una alternativa temporal razonable.

• Degradaciones menores que no comprometan la continuidad del servicio.

1.8.4.4     Severidad 4, baja

Se clasificará como severidad 4 cualquier situación sin afectación inmediata sobre la operación, incluyendo:

 

• Consultas técnicas.

• Solicitudes de información.

• Recomendaciones de configuración.

• Revisión de documentación.

• Solicitudes de análisis preventivo.

• Otras gestiones de carácter administrativo o técnico que no correspondan a una falla activa.

 

1.8.5      Niveles de servicio

1.8.5.1     El contratista deberá cumplir, como mínimo, los siguientes niveles de servicio:

Severidad	Cobertura	Tiempo máximo para iniciar la atención	Frecuencia mínima de actualización	Tiempo objetivo de restauración
1, crítica	24 horas, 7 días	1 hora natural	Cada 2 horas naturales	8 horas naturales
2, alta	24 horas, 7 días	2 horas naturales	Cada 4 horas naturales	12 horas naturales
3, media	Horario hábil	4 horas hábiles	Una vez por día hábil	2 días hábiles
4, baja	Horario hábil	1 día hábil	Según el plan de atención acordado	5 días hábiles

 

1.8.5.2     Para la aplicación de la tabla anterior se utilizarán las siguientes definiciones:

• Tiempo para iniciar la atención: período comprendido entre el registro del incidente y el momento en que personal técnico calificado inicia el diagnóstico y establece comunicación con el Banco.

• Actualización del caso: comunicación documentada que deberá incluir el estado del incidente, diagnóstico disponible, acciones realizadas, actividades pendientes y plazo estimado para la siguiente actualización.

• Tiempo objetivo de restauración: período máximo para restablecer la operación afectada mediante una solución definitiva, procedimiento de recuperación, mecanismo de redundancia, medida temporal o alternativa de contingencia oficialmente soportada por el fabricante.

1.8.5.3     El tiempo objetivo de restauración no deberá interpretarse necesariamente como el tiempo de resolución definitiva cuando esta dependa de una corrección adicional del fabricante, una actualización de software, una sustitución compleja o un análisis especializado.

1.8.5.4     Cuando se implemente una medida temporal, el contratista deberá mantener el incidente abierto, sujeto a seguimiento y escalamiento, hasta alcanzar su resolución definitiva.

1.8.5.5     Los tiempos correspondientes a incidentes de severidad 1 y severidad 2 se contabilizarán en horas naturales. Los tiempos de severidad 3 y severidad 4 se contabilizarán en horas o días hábiles, según corresponda.

1.8.5.6      La clasificación inicial será asignada por el Banco con base en el impacto operativo observado. La severidad podrá ajustarse posteriormente, de común acuerdo, cuando el diagnóstico técnico demuestre que corresponde una clasificación diferente. El ajuste y su justificación deberán quedar documentados dentro del caso de soporte.

1.8.6       Escalamiento de incidentes

1.8.6.1     El contratista deberá disponer de procedimientos formales para el escalamiento técnico y administrativo de los incidentes.

1.8.6.2     Los incidentes de severidad 1 deberán ser escalados al fabricante desde el inicio de su atención, salvo que sean resueltos inmediatamente mediante un procedimiento documentado y oficialmente soportado.

1.8.6.3     Los incidentes de severidad 2 deberán ser escalados al fabricante cuando:

• no exista un diagnóstico concluyente dentro de las primeras cuatro (4) horas naturales;

• se determine la necesidad de una corrección, actualización o intervención del fabricante;

• se requiera sustituir un componente principal; o

• exista riesgo de que el incidente evolucione a una severidad crítica.

 

1.8.6.4     El contratista mantendrá la responsabilidad integral sobre el seguimiento del incidente, aunque este haya sido escalado al fabricante.

1.8.6.5     El Banco deberá poder consultar el número de caso, estado, severidad, fecha y hora de apertura, actividades realizadas y estado del escalamiento.

1.8.7      Sustitución de componentes defectuosos

1.8.7.1     Durante el período de garantía, el contratista deberá reparar o sustituir cualquier componente defectuoso cubierto por la garantía, sin costo adicional para el Banco.

1.8.7.2     Los componentes utilizados para la sustitución deberán ser nuevos, originales o equivalentes oficialmente autorizados por el fabricante y compatibles con la configuración implementada.

1.8.7.3     Cuando un incidente de severidad 1 o severidad 2 requiera la sustitución de un componente de hardware crítico, el repuesto deberá quedar instalado, configurado y operativo dentro de un plazo máximo de ocho (8) horas naturales, contado a partir del momento en que el diagnóstico técnico determine y documente la necesidad de sustitución.

1.8.7.4     Se considerarán componentes críticos, entre otros:

• Controladoras o nodos de procesamiento.

• Medios de almacenamiento.

• Fuentes de poder.

• Módulos de ventilación.

• Interfaces, adaptadores o componentes de conectividad necesarios para la operación o redundancia.

• Componentes internos requeridos para la replicación, alta disponibilidad o funcionamiento de la plataforma.

1.8.7.5      Cuando, por razones técnicas debidamente documentadas, no sea posible completar la sustitución dentro del plazo establecido, el contratista deberá:

• implementar una medida temporal o procedimiento de contingencia oficialmente soportado por el fabricante;

• restablecer la operación o la redundancia en el menor tiempo posible;

• escalar inmediatamente el incidente al fabricante;

• comunicar al Banco el diagnóstico, riesgo, acciones realizadas y plazo previsto para la sustitución definitiva; y

• mantener las actualizaciones periódicas correspondientes a la severidad del incidente.

 

1.8.7.6      La sustitución se considerará concluida únicamente cuando el componente haya sido instalado, configurado y validado, y la solución se encuentre operando en condiciones iguales o superiores a las existentes antes de la falla.

1.8.7.7      El esquema propuesto complementa la arquitectura redundante, la sustitución de componentes conforme a las prácticas del fabricante y la continuidad ante fallas previstas actualmente en el pliego.

1.8.8      Personal técnico de soporte

1.8.8.1     Las intervenciones sobre la solución deberán ser realizadas por personal certificado en la plataforma ofertada o por personal técnico oficialmente autorizado por el fabricante.

1.8.8.2     El contratista deberá mantener disponibles, durante toda la vigencia de la garantía, recursos técnicos con las certificaciones y experiencia requeridas para:

• diagnóstico de incidentes;

• sustitución de componentes;

• instalación de software y firmware;

• validación de mecanismos de alta disponibilidad y replicación;

• recuperación de servicios; y

• escalamiento técnico al fabricante.

1.8.8.3      La sustitución de los recursos técnicos asignados deberá efectuarse únicamente mediante personal con certificaciones y experiencia equivalentes o superiores.

1.8.8.4     Las actividades deberán realizarse conforme a los procedimientos, recomendaciones y mejores prácticas oficiales del fabricante.

1.8.9      Atención en las instalaciones del Banco

1.8.9.1     Cuando la atención de un incidente requiera la presencia de personal del contratista o del fabricante en alguno de los centros de datos del Banco, dicho personal deberá cumplir las políticas, procedimientos y controles institucionales para el ingreso, permanencia y ejecución de actividades dentro de las instalaciones.

1.8.9.2     El contratista deberá coordinar el ingreso con el Administrador del Contrato o con la persona designada por este.

1.8.9.3     El cumplimiento de los procedimientos de acceso deberá considerarse dentro del esquema de atención ofrecido y no eximirá al contratista del cumplimiento de los niveles de servicio establecidos.

1.8.10   Respaldo del fabricante

1.8.10.1  La solución deberá contar con soporte oficial del fabricante durante la totalidad del período de garantía.

1.8.10.2  El Banco deberá disponer de acceso a los mecanismos oficiales de escalamiento definidos por el fabricante para la solución ofertada.

1.8.10.3  El soporte podrá ser gestionado por el contratista en su condición de socio autorizado, siempre que:

• la solución cuente con una cobertura oficial vigente del fabricante;

• el contratista tenga acceso a los mecanismos oficiales de diagnóstico y escalamiento;

• se encuentren disponibles las actualizaciones, correcciones, software y firmware correspondientes; y

• el contratista asuma frente al Banco la responsabilidad integral por el cumplimiento de los niveles de servicio.

1.8.11   Actualizaciones de software y firmware

1.8.11.1  Durante el período de soporte, el Banco tendrá derecho a acceder a las actualizaciones, correcciones, parches de seguridad y versiones de software y firmware liberadas por el fabricante para la plataforma ofertada.

1.8.11.2  Las actualizaciones deberán ser oficiales y encontrarse soportadas por el fabricante.

1.8.11.3  Cuando una actualización requiera actividades de implementación, configuración, pruebas o validación técnica, el contratista deberá proporcionar el acompañamiento técnico correspondiente, sin costo adicional para el Banco.

1.8.12   Disponibilidad de repuestos

1.8.12.1   El contratista deberá garantizar la disponibilidad de repuestos y componentes oficialmente soportados durante la totalidad del período de garantía.

1.8.12.2   El contratista será responsable de mantener los acuerdos, existencias, contratos de soporte o mecanismos logísticos necesarios para cumplir los tiempos de sustitución establecidos en este capítulo.

1.8.12.3   La falta de disponibilidad local de un repuesto no eximirá al contratista del cumplimiento de las obligaciones de restauración, contingencia, escalamiento y comunicación.

1.8.13    Acreditación del servicio ofertado

1.8.13.1   Como parte de la oferta, el oferente deberá aportar documentación oficial del fabricante, certificación emitida por este o referencia pública verificable que permita acreditar:

• la vigencia del soporte oficial durante al menos treinta y seis (36) meses;

• la modalidad y cobertura horaria del soporte contratado;

• los mecanismos disponibles para la apertura y escalamiento de incidentes;

• el derecho de acceso a actualizaciones, correcciones, software y firmware;

• la disponibilidad de repuestos;

• la modalidad mediante la cual se brindará el soporte en Costa Rica; y

• la correspondencia entre el soporte contratado con el fabricante y los niveles de servicio ofrecidos al Banco.

1.8.13.2   Cuando alguno de los niveles de servicio exigidos sea asumido directamente por el contratista y no forme parte del soporte estándar del fabricante, el oferente deberá declararlo expresamente y describir los recursos, procedimientos, contratos, inventarios y mecanismos de respaldo mediante los cuales garantizará su cumplimiento.

1.8.14   Registro e informe de incidentes

1.8.14.1  El contratista deberá mantener un registro actualizado de los incidentes atendidos durante la vigencia contractual. El registro deberá incluir, como mínimo:

• número de caso;

• fecha y hora de apertura;

• severidad asignada;

• descripción del incidente;

• componentes o servicios afectados;

• diagnóstico;

• actividades realizadas;

• escalamiento efectuado;

• repuestos utilizados;

• fecha y hora de restauración;

• fecha y hora de resolución definitiva; y

• causa raíz, cuando corresponda.

 

1.8.14.2  Para los incidentes de severidad 1 y severidad 2, el contratista deberá entregar un informe de cierre que documente la causa del incidente, las acciones correctivas ejecutadas y las recomendaciones necesarias para evitar su recurrencia.

1.8.15   Mantenimiento preventivo y vigencia tecnológica

1.8.15.1  Durante el período contractual, el contratista deberá poner a disposición del Banco las recomendaciones, boletines técnicos, alertas de seguridad y mejores prácticas publicadas por el fabricante que resulten aplicables a la solución ofertada.

1.8.15.2  Asimismo, deberá informar oportunamente sobre vulnerabilidades, riesgos, defectos conocidos o condiciones que puedan afectar la seguridad, disponibilidad o estabilidad de la plataforma.

1.8.15.3  La solución deberá mantenerse en condición de soporte oficial durante todo el período de garantía. No se aceptarán componentes que entren en condición de fin de soporte sin que exista una alternativa oficialmente soportada que permita mantener las capacidades, el rendimiento, la disponibilidad y la protección de datos requeridos.

1.9        TRANSFERENCIA DE CONOCIMIENTO

1.9.1      El contratista deberá realizar actividades formales de transferencia de conocimiento dirigidas al personal técnico designado por el Banco Central de Costa Rica.

1.9.2      La transferencia de conocimiento deberá orientarse a que el personal técnico adquiera las capacidades necesarias para operar, administrar, monitorear, respaldar y atender incidentes de primer nivel sobre la solución implementada.

1.9.3      Las actividades deberán realizarse utilizando la solución efectivamente instalada como parte del presente proyecto.

1.9.4      La transferencia de conocimiento deberá contemplar, como mínimo, los siguientes temas:

1.9.4.1     Arquitectura de la solución

• Arquitectura general implementada.

• Componentes principales de la plataforma.

• Distribución entre sitios.

• Mecanismos de alta disponibilidad.

• Mecanismos de replicación.

1.9.4.2     Administración del almacenamiento

• Administración de capacidad.

• Administración de recursos compartidos.

• Administración de cuotas.

• Crecimiento de la plataforma.

1.9.4.3     Servicios NAS

• Administración de recursos compartidos.

• Gestión de permisos.

• Integración con Active Directory.

• Gestión de usuarios y grupos.

1.9.4.4     Protección de datos

• Administración de snapshots.

• Recuperación de archivos y carpetas.

• Replicación de datos.

• Funcionalidades WORM o equivalentes.

• Buenas prácticas de protección de la información.

1.9.4.5     Monitoreo y operación

• Administración de alertas.

• Interpretación de eventos.

• Monitoreo de capacidad.

• Uso de la consola de administración.

1.9.4.6     Soporte operativo

• Diagnóstico básico de incidentes.

• Procedimientos de revisión inicial.

• Recolección de información para escalamiento.

• Buenas prácticas recomendadas por el fabricante.

1.9.5      Modalidad

1.9.5.1     La transferencia de conocimiento podrá realizarse de forma presencial, remota o mediante una combinación de ambas modalidades.

1.9.5.2     Deberá incluir actividades prácticas sobre la plataforma implementada, utilizando configuraciones y escenarios representativos del ambiente institucional.

1.9.6      Participantes

1.9.6.1     El Banco definirá las personas que participarán en las actividades de transferencia de conocimiento.

1.9.6.2     El contratista deberá garantizar la participación de personal con experiencia comprobable en la solución ofertada.

1.9.7      Material de apoyo

1.9.7.1     El contratista deberá suministrar la documentación utilizada durante las sesiones de transferencia de conocimiento.

1.9.7.2     Como mínimo deberá entregar:

• Presentaciones 

• Procedimientos de administración.

• Procedimientos de respaldo y recuperación.

• Documentación técnica relevante del fabricante.

• Recomendaciones operativas para la plataforma implementada.

1.9.8      Constancia de ejecución

1.9.8.1     Finalizadas las actividades de transferencia de conocimiento, el contratista deberá entregar un informe que incluya:

• Temas cubiertos.

• Fechas de las sesiones.

• Material entregado.

• Participantes

• Evidencia de realización.

1.9.9      Certificaciones

1.9.9.1     No se requerirá que las actividades de transferencia de conocimiento correspondan a cursos oficiales del fabricante ni a programas conducentes a certificaciones técnicas.

1.9.9.2     El objetivo de esta actividad será garantizar la adecuada operación y administración de la solución implementada por parte del personal técnico del Banco.

1.10    ENTREGABLES

1.10.1   Consideraciones generales

1.10.1.1  El contratista deberá entregar la totalidad de la documentación, informes y demás productos derivados de la implementación de la solución.

1.10.1.2  Todos los entregables deberán presentarse en idioma español o inglés y en formato electrónico editable o de uso común para la Institución.

1.10.1.3  La documentación entregada deberá corresponder a la configuración efectivamente implementada en el Banco Central de Costa Rica.

1.10.2    Documentación de arquitectura

1.10.2.1  El contratista deberá entregar documentación que describa la arquitectura final implementada.

1.10.2.2  Como mínimo deberá incluir:

• Descripción general de la solución.

• Componentes instalados.

• Distribución de componentes por sitio.

• Arquitectura de alta disponibilidad.

• Arquitectura de replicación.

• Relaciones entre componentes principales.

1.10.3   Diagramas técnicos

1.10.3.1  El contratista deberá entregar diagramas actualizados de la solución implementada.

1.10.3.2  Como mínimo deberá proporcionar:

1.10.3.2.1Diagrama de arquitectura mostrando:

• Controladoras, nodos o entidades de procesamiento.

• Componentes de almacenamiento.

• Componentes de replicación.

• Componentes de protección de datos.

1.10.3.2.2Diagrama de conectividad mostrando:

• Interfaces Front-End.

• Interfaces de administración (Out-of-Band).

• Conectividad Back-End.

• Componentes de interconexión.

• Velocidades de enlaces.

• Distribución de puertos requeridos por sitio.

1.10.4   Documentación de configuración

1.10.4.1  El contratista deberá documentar la configuración implementada sobre la plataforma.

1.10.4.2  Como mínimo deberá incluir:

• Configuración general de la solución.

• Configuración de almacenamiento.

• Configuración de servicios NAS.

• Configuración de alta disponibilidad.

• Configuración de replicación.

• Configuración de snapshots.

• Configuración de mecanismos de protección de datos.

• Configuración de monitoreo y alertamiento.

1.10.5   Procedimientos operativos

1.10.5.1  El contratista deberá entregar procedimientos operativos orientados a la administración de la plataforma.

1.10.5.2  Como mínimo deberá incluir:

• Procedimiento de creación de recursos compartidos.

• Procedimiento de administración de permisos.

• Procedimiento de creación y administración de snapshots.

• Procedimiento de recuperación de información.

• Procedimiento de failover entre sitios.

• Procedimiento de failback entre sitios.

• Procedimiento de validación posterior a la recuperación de servicios entre sitios.

• Procedimiento de verificación de estado de la plataforma.

• Procedimiento de revisión de alertas.

• Procedimiento de escalamiento al soporte.

1.10.6   Informe de pruebas

1.10.6.1  El contratista deberá entregar un informe que documente las pruebas realizadas sobre la solución.

1.10.6.2  Como mínimo deberá incluir:

• Pruebas de funcionamiento.

• Pruebas de acceso a servicios NAS.

• Pruebas de alta disponibilidad.

• Pruebas de failover.

• Pruebas de replicación.

• Pruebas de recuperación.

• Resultados obtenidos.

• Evidencias asociadas.

1.10.7   Planes de implementación y migración

1.10.7.1  El contratista deberá entregar:

• Plan general de implementación.

• Plan general de migración.

1.10.7.2  Asimismo, deberá incorporar las observaciones y ajustes derivados de la coordinación con el Banco para la elaboración del Plan Operativo de Migración definido en la sección Implementación y Migración.

1.10.8   Informe de migración

1.10.8.1  Finalizado el proceso de migración deberá entregarse un informe que documente:

• Recursos compartidos migrados.

• Resultados de validación.

• Verificación de integridad de la información.

• Validación de permisos.

• Incidencias identificadas.

• Acciones correctivas ejecutadas.

• Resultado final del proceso.

1.10.8.2  Este informe deberá servir como insumo para la recepción definitiva de la migración.

1.10.9   Documentación de transferencia de conocimiento

1.10.9.1  Como resultado de las actividades definidas en la sección Transferencia de Conocimiento, el contratista deberá entregar:

• Material utilizado durante las sesiones.

• Procedimientos de administración.

• Procedimientos de recuperación.

• Informe de ejecución de la transferencia de conocimiento.

1.10.10                   Inventario de la solución

1.10.10.1             El contratista deberá entregar un inventario de los componentes suministrados.

1.10.10.2             Como mínimo deberá incluir:

• Marca
• Modelo

• Número de serie.

• Licencias asociadas.

• Versiones de software y firmware instaladas.

• Ubicación física de los componentes cuando corresponda.

1.10.11                   Entrega final de documentación

1.10.11.1             La totalidad de los entregables definidos en este apartado deberá encontrarse actualizada y entregada antes de la recepción definitiva del proyecto.

1.10.11.2             La documentación deberá reflejar la configuración final efectivamente implementada en el ambiente de producción del Banco Central de Costa Rica.

1.11    Capacidad técnica y recursos certificados:

1.11.1   El oferente deberá acreditar que dispone de la capacidad técnica necesaria para implementar, configurar, migrar y poner en operación la solución ofertada.

1.11.2   Asimismo, deberá acreditar que cuenta con acceso a un mínimo de dos (2) recursos técnicos certificados por el fabricante de la solución ofertada para la ejecución del proyecto.

1.11.3   El oferente deberá indicar la estructura técnica disponible para la ejecución del proyecto y describir los perfiles profesionales que participarán en las actividades de implementación, migración, pruebas, transferencia de conocimiento y soporte especializado.

1.11.4   La Administración podrá solicitar información adicional cuando lo considere necesario para verificar el cumplimiento de este requisito.

1.12    Vigencia comercial y soporte de la plataforma

1.12.1   La solución ofertada deberá corresponder a una plataforma comercialmente disponible y soportada por el fabricante.

1.12.2   No serán admisibles soluciones que, a la fecha de presentación de las ofertas, hayan sido declaradas por el fabricante en condición de:

• Fin de venta (End of Sale).

• Fin de soporte (End of Support).

• Fin de vida útil (End of Life).

1.12.3   El oferente deberá aportar documentación oficial emitida por el fabricante o referencia pública verificable que permita comprobar esta condición.

1.12.4   Asimismo, la plataforma ofertada no deberá encontrarse publicada por el fabricante con una fecha oficial de finalización de soporte que ocurra dentro del período mínimo de garantía solicitado por la Administración.

1.13    Disponibilidad de soporte y repuestos

1.13.1   El oferente deberá declarar que durante todo el período contractual ofertado garantizará la disponibilidad de soporte técnico, acceso a actualizaciones oficiales del fabricante y disponibilidad de repuestos para la solución propuesta.

4        CONDICIONES GENERALES

4.1        LUGAR Y PLAZO DE ENTREGA: La solución deberá entregarse e instalarse en los dos centros de datos definidos por el Banco Central de Costa Rica:

a) Instalaciones del Banco Central de Costa Rica, ubicadas en calle 4 y avenida central, San José; y
b) Oficentro Tecnológico CODISA, ubicado en Llorente de Tibás, un kilómetro al este del periódico La Nación, contiguo a la Escuela Anselmo Llorente.

4.2        El plazo máximo para la entrega será de sesenta (60) días hábiles, contado a partir de la comunicación de la orden de inicio. La recepción será coordinada por el Administrador del Contrato.

4.3        GARANTÍA SOBRE EL OBJETO CONTRACTUAL: La totalidad de los componentes de hardware, software, licenciamiento y demás elementos que conforman la solución NAS ofertada deberán contar con garantía y soporte integral por un período mínimo de treinta y seis (36) meses, contados a partir de la recepción definitiva de la solución.

4.4        SUBCONTRATACIÓN:

4.4.1      Cuando resulte necesario, el oferente podrá subcontratar hasta un 50% del monto ofertado, únicamente para la ejecución de actividades especializadas. Esta subcontratación no exime al contratista de su responsabilidad frente a la Administración.

4.4.2      Para tal efecto, el oferente deberá adjuntar el detalle de las actividades que pretende subcontratar, indicando el monto, el porcentaje de participación dentro del costo total de la oferta y el nombre del subcontratista correspondiente. Asimismo, deberá aportar certificación de los titulares del capital social y de los representantes legales de la empresa o empresas subcontratistas, a fin de verificar el cumplimiento del régimen de prohibiciones.

4.4.3      Cada subcontratista solo podrá participar en una oferta dentro de este concurso. Si varios oferentes requieren subcontratar a una misma persona física o jurídica, deberá acreditarse que existe un número limitado de subcontratistas en el mercado para el objeto contractual correspondiente.

4.5        OFERTAS EN CONSORCIO:

4.5.1      Cuando se presenten ofertas en consorcio, las empresas integrantes deberán cumplir las condiciones de admisibilidad y los requisitos establecidos en el pliego de condiciones, como si actuaran como un solo oferente, y responderán solidariamente por la totalidad de la oferta.

4.5.2      Dado que el BCCR utiliza SICOP para sus procedimientos de contratación, las personas físicas o jurídicas que oferten en consorcio deberán constituirlo en dicha plataforma y obtener el número de consorcio correspondiente. De no hacerlo, la oferta no podrá considerarse consorcial, aunque se aporte como anexo un acuerdo consorcial.

4.5.3      La oferta deberá responder todos los requerimientos del pliego de condiciones e indicar con claridad la experiencia y demás requisitos aplicables, así como cuál integrante del consorcio acredita cada uno.

4.5.4      En todos los casos, deberá presentarse el acuerdo consorcial debidamente firmado por las partes, en el cual se identifiquen sus integrantes y las obligaciones que asumirá cada uno.

4.5.5      Todos los miembros del consorcio serán solidariamente responsables.

4.5.6      Para efectos de esta licitación, cuando no exista una figura jurídica que formalice el consorcio, quien presente la oferta en el Sistema Integrado de Compras Públicas (SICOP) actuará como enlace ante el BCCR para todo lo relacionado con esta contratación.