MINISTERIO DE JUSTICIA

“Programa de Fortalecimiento de las Acciones de Protección contra las Violencias por Motivos de Género” (BCIE N.º 2280) “Modernización de la Infraestructura de Cómputo, Procesamiento, Resguardo y Recuperación del Data Center del Ministerio de Justicia” ENMIENDA N° 01/2026 En virtud de la solicitud formulada por la Dirección General de Tecnologías de la Información y las Telecomunicaciones, SE REEMPLAZA toda la Sección V. “Lista de Requisitos de Bienes y Servicios Conexos”, la cual quedará redactada de la siguiente manera (las demás condiciones, términos y disposiciones del Pliego de Condiciones no modificadas por la presente Enmienda mantienen su plena vigencia y aplicabilidad): Sección V. Lista de Requisitos de bienes y Servicios Conexos El objetivo central del proyecto es modernizar la infraestructura tecnológica y asegurar la continuidad operativa, el resguardo de los sistemas y de los datos del organismo. Los servicios conexos a ser prestados por el adjudicatario comprenderán la instalación, configuración y puesta en marcha de los productos objeto del presente requerimiento. La correcta ejecución y finalización de dichas tareas deberá contar con la aprobación de un representante técnico designado por el organismo contratante.

Recepción provisoria y definitiva de los bienes Una vez realizada la entrega de los bienes en el lugar y plazo estipulados, se procederá a la recepción provisoria, la cual consistirá en la verificación física, documental y funcional de los equipos entregados y se formalizará mediante el correspondiente Acta de Recepción Provisoria. Durante esta etapa, se comprobará que los bienes se correspondan con las cantidades, modelos y especificaciones técnicas detalladas en el contrato. Cumplida esta verificación preliminar, el adjudicatario deberá realizar la instalación, configuración e implementación, y comprobar el correcto funcionamiento de los bienes, la integración con la infraestructura existente y el cumplimiento de las especificaciones técnicas establecidas en el pliego. Este servicio conexo es condición esencial para la aceptación definitiva de los bienes. Concluida satisfactoriamente la instalación, configuración e implementación, y comprobado el funcionamiento integral de los bienes, se procederá a la recepción definitiva, que se formalizará mediante el correspondiente Acta de Recepción Definitiva, documento que acreditará la aceptación total de los bienes y habilitará el inicio del plazo de garantía. La garantía comenzará a regir a partir de la fecha de firma del Acta de Recepción Definitiva, conforme las condiciones establecidas en el contrato y en el Pliego de Especificaciones Técnicas. En esta sección se incluye: 1. Lista de bienes y plan de entrega 2. Lista de servicios conexos y cronograma de cumplimiento 3. Especificaciones técnicas requeridas 4. Planos o diseños 5. Inspecciones y pruebas 1.Lista de Bienes y Plan de Entregas 2.Lista de Servicios Conexos y Cronograma de Cumplimiento 1.Si corresponde: Oferente: (indicar nombre completo del oferente) Nombre: (indicar nombre completo de la persona que firma la propuesta) Cargo: (del firmante) Firma: firma de la persona cuyo nombre y cargo aparecen arriba indicados) Fecha: (día, mes y año en que se firma la propuesta) 3. ESPECIFICACIONES TÉCNICAS OBJETO Los bienes y servicios conexos deberán cumplir con las siguientes especificaciones técnicas y normas. El objetivo central del proyecto es modernizar la infraestructura tecnológica y asegurar la continuidad operativa, el resguardo de los sistemas y de los datos del organismo, y de esta forma garantizar la continuidad operativa mediante una arquitectura escalable, segura y resiliente capaz de satisfacer las necesidades operativas actuales y futuras mediante la incorporación de nuevas tecnologías de vanguardia y equipamiento de marcas de primer nivel reconocidas mundialmente. Garantía Los elementos de hardware ofrecidos deberán ser nuevos sin uso y contar con una garantía de TREINTA Y SEIS (36) meses. La garantía deberá incluir el soporte oficial del fabricante, cubriendo desperfectos, fallas o roturas, así como las actualizaciones, parches y demás servicios de mantenimiento provistos directamente por el fabricante durante el período de vigencia. No se aceptarán ofertas variantes ni propuestas que contemplen la ejecución parcial de los renglones detallados en el pliego. Por un lado la solución de Hiperconvergencia debe basarse en nodos independientes, permitiendo chasis que alojen más de un nodo a la vez compartiendo la misma alimentación eléctrica, siempre que cada nodo tenga sus propias conexiones de red Ethernet y tenga conectividad a sus propios discos internos. Los puertos de red de datos deberán ser de mínimo 25Gbps del tipo SFP28, los cuales se conectarán a dos (2) switches Ethernet Top-of-the-Rack (TOR) dedicados para el tráfico del clúster. El Hardware ofertado deberá estar homologado para funcionar con la solución de Software hiper convergente ofertada. La capacidad total de cada nodo deberá cumplir como mínimo los siguientes requerimientos: El Total de recursos solicitados para los 5 servidores: 240 Cores, 2,560.00 GB de RAM. La capacidad total de almacenamiento bruto (Raw) del clúster deberá ser de 921.6 TB en discos SSD/NVMe PCIe Gen5 (U.2). El oferente deberá garantizar que, tras aplicar la arquitectura de protección distribuida y tolerancia a fallos tipo $ N+1$ requerida en este pliego, la capacidad neta utilizable real disponible para las Máquinas Virtuales no sea inferior a 460 TB, sin considerar técnicas de deduplicación o compresión. Y en lo que respecta al resguardo de los sistemas y de los datos del organismo, se comprende la adquisición de una solución integral de respaldo y recuperación de datos, compuesta por licencias de backup para 250 máquinas virtuales, hardware de almacenamiento con de duplicación optimizada, destinado a garantizar la continuidad operativa. Especificaciones Técnicas Detalladas Renglón 1 - Nodos para Infraestructura Hiper Convergente La solución por proveer deberá incluir los elementos de hardware y las licencias de software para proveer una arquitectura escalable y distribuida, la cual pueda crecer de manera horizontal en recursos de procesamiento, memoria RAM y almacenamiento que forman parte de la solución. Deberá estar compuesta solamente por servidores (o nodos, en adelante se hablará de servidor o nodo en forma indistinta, pero son lo mismo) basados en procesadores de propósito general x86 (sin la utilización de otro tipo de procesadores de propósito específicos tales como ASIC o similares). Cada nodo deberá tener almacenamiento local basado exclusivamente en discos de estado sólido de tecnología ultra rápida All-Flash NVMe PCIe Gen5, contribuyendo a la arquitectura de almacenamiento distribuido sin excepción. En caso que se oferten discos combinados (ejemplo NVMe con SSD), el sistema debe utilizar primero los discos más rápidos, para luego hacer tiering en forma automática y todos los discos deben utilizarse para datos. Los procesadores deberán estar basados en Arquitectura actual: procesadores de servidor de arquitectura moderna (Intel Ice Lake o equivalentes técnicos de AMD EPYC con especificaciones comparables en términos de núcleos, frecuencia y TDP). La solución deberá permitir integrar nodos/servidores con diferentes características que le permitan adaptarse a los requerimientos de cada una de las aplicaciones y formando un clúster heterogéneo. Los tipos de nodos esperados pueden incluir: •Intensivos en CPU/Memoria •Intensivos en Almacenamiento •Nodos solamente con discos SSD •Nodos solamente con discos NVMe •Nodos con discos NVMe y SSD Todo equipamiento de Hardware deberá contar con fuentes de alimentación y ventiladores redundantes. Cada nodo/servidor deberá contar con conectividad de datos independiente del Tipo Ethernet de 25 Gbps (al menos 2 puertos nativos con soporte de conectores SFP28) y puertos dedicados de 10 Gbps para la red de administración. Asimismo, cada nodo deberá contar con un puerto que permita la administración remota a nivel Hardware por medio de puertos ILO, iDRAC, IPMI o equivalente. Proveer la factibilidad de crecimientos modulares evitando así el sobredimensionamiento del proyecto. Los crecimientos tienen que incrementar tanto procesamiento, memoria, y almacenamiento en forma simultánea y en diferentes proporciones, para poder acomodarse a los diferentes requerimientos. Compatibilidad y Respaldo de la Solución: Se requiere que la solución de software hiperconvergente y el hardware de los nodos servidores cuenten con una integración nativa, estando la combinación de componentes de hardware propuestos homologada, certificada y soportada de fábrica de manera oficial por el fabricante del software HCI. La oferta debe incluir las garantías y contratos de soporte técnico cruzado que aseguren un único punto de contacto o un esquema de resolución conjunta de incidentes (Back-to-Back) entre los fabricantes implicados, sin perder el carácter agnóstico multihípervisor solicitado en este pliego. La solución de Hiperconvergencia debe soportar múltiples hipervisores, como Broadcom (VMWare ESXi), Microsoft Hyper-V, KVM o similares. Así como también deberá ser compatible con soluciones de Escritorios Virtuales (VDI), tales como Omnissa (VMWare Horizon Enterprise) y Citrix Virtual Desktop and Application Solution u otros. La solución hiperconvergente deberá tener implementada las “Security Technical Implementation Guidelines” (STIG) propuestas por la industria y ajustadas al fabricante de la solución hiperconvergente, pues se espera aumentar la seguridad de la infraestructura. Estas STIG deben revisarse automáticamente todos los días, si se detecta alguna desviación, estas deben repararse automáticamente. Todas las características y funcionalidades deben poder administrarse desde una sola consola de administración. Características del sistema hiperconvergente que compondrá la solución La infraestructura deberá ser distribuida y completamente definida por software, armando un clúster que posea las siguientes características: Storage Definido por Software Solución de Almacenamiento (storage) definida por software, con capacidad de recuperación ante la falla de un disco o de un servidor completo que forma parte de la solución. Capacidad de generar almacenamiento distribuido entre todos los nodos, usando los discos DAS de cada uno de los servidores generando un almacenamiento virtual, el cual pueda ser presentado a la capa de Hipervisor, que se decida utilizar, para que los diferentes Hosts puedan hacer uso del almacenamiento de manera transparente y homogénea. La solución de almacenamiento no debe usar switches Fibre Channel ni FCoE para su funcionamiento. Solamente se utilizará IP sobre Ethernet estándar. El Almacenamiento generado debe ser presentado a todos los Hipervisores que corren en los nodos del cluster, permitiendo que todos ellos puedan ver y compartir el mismo almacenamiento definido por software. El almacenamiento definido por Software (Software Defined Storage) de la solución hiperconvergente deberá proveer las siguientes funcionalidades y características: 1. Tiering automático de storage: Esquema de optimización de capas de almacenamiento de datos para Lectura y Escritura en tiempo real, ejecutado de manera automática y distribuida entre los niveles de rendimiento internos del clúster (Memoria RAM y la arquitectura de estado sólido NVMe). 2. Deduplicación: Operativa en los discos de estado sólido NVMe. Deberá tener la capacidad de decidir qué ‘datastores’ se deduplicarán y cuáles no. 3. compresión: Tanto en línea como en reposo (post-process), funcionando sobre la totalidad de los datos alojados en los discos NVMe. 4. La solución debe soportar “Erasure Coding”, para mejor aprovechamiento del almacenamiento. 5. Snapshots: basados en punteros y del tipo “Redirect-on-Write”, con posibilidad de integrar la solución con el servicio VSS (Volume Shadow Copy Service) de Microsoft para asegurar la integridad de aplicaciones como SQL Server. Los Snapshots podrán tomarse tanto manualmente como también en forma automatizada, para agendar la toma de Snapshots y el tiempo de retención de los mismos. Deberá ser posible poder enviar estos snapshots a un cluster secundario, permitiendo un tiempo de retención diferente al snapshot de origen. 6. Desde un snapshot, se permitirá la recuperación granular de archivos, sin necesidad de recuperar la máquina virtual completa. Esta operación se podrá realizar desde la VM, sin necesidad de acceder al interfaz de gestión del cluster hiperconvergente. 7. Clones de VMs: sin consumo de espacio adicional (thin provisioning y deduplicado). Deberá contar con integración para acelerar el clonado de máquinas virtuales tales como: vSphere API for Array Integration (VAAI) y similares. 8. Debe existir un sistema que permita que a lo largo del tiempo los datos más accedidos por una VM corriendo en cualquiera de los nodos, tengan siempre una copia en los discos locales del nodo, de manera que la lectura pueda realizarse localmente, en la mayoría de las veces, sin que deba utilizar la red ethernet. Este mecanismo debe converger y actualizarse de manera automática si la VM se mueve/traslada a otro nodo. 9. Para escenarios donde un disco virtual (vDisk) se lea desde múltiples hosts (por ejemplo, una imagen “gold” en entornos VDI), se deberá proporcionar un sistema automático de cache (caching) que permita que la lectura pueda realizarse desde el almacenamiento local en cada nodo. Esta funcionalidad debe actuar automáticamente en caso de accesos al mismo vDisk desde múltiples nodos, estando integrado a la solución de Storage distribuido y sin requerir una configuración específica. 10. Thin provisioning: para todos los discos virtuales de cada máquina virtual. 11. Capacidad de aplicar Storage QoS, de modo que se puedan limitar la cantidad de IOPS a los discos virtuales, con granularidad de Máquina Virtual. Storage Basado en Bloques (iSCSI) La solución hiperconvergente ofertada deberá permitir generar volúmenes virtuales de almacenamiento por bloques (Block Storage) que puedan presentarse a VMs internas o incluso a servidores externos (ya sean bare metal, como por ejemplo servidores con AIX o Solaris, o virtuales fuera del cluster a proponer) mediante el protocolo iSCSI. Los volúmenes presentados por iSCSI deben hacer uso de todas las características del almacenamiento definido por software, es decir protección de datos con snapshots, replicación remota de estos, clones, tiering, deduplicación, compresión y erasure-coding, que son utilizados en el almacenamiento dentro del cluster. Se deberá entregar redundancia nativa del Target iSCSI y permitir aumentar el tamaño de las LUN que se están presentando en caliente (sin detener de servicio). El acceso iSCSI deberá soportar seguridad CHAP (Challenge-Handshake Authentication Protocol), de manera que la password no viaje por la red en texto plano. Storage Basado en Archivos (NFS/SMB) Capacidad de ofrecer nativamente, y de manera distribuida, storage NAS (Network Attached Storage) para File Sharing corporativo, soportando los protocolos SMB y NFS, que se pueda integrar con Active-Directory (incluyendo permisos, cuotas) y LDAP. Este storage NAS deberá distribuir y proteger los datos en el Cluster Hiperconvergente, garantizando escalabilidad en cantidad de usuarios e integración con Snapshots del Sistema. La gestión de esta solución de File Sharing deberá estar integrada en la misma consola de Gestión del Cluster Hiperconvergente. Este tipo de storage deberá poder replicar hacia otro cluster secundario para disponer de tolerancia contra desastres en caso que el data center genere indisponibilidad. El storage NAS deberá contar, y estar incluida en la oferta, con una herramienta de análisis que permita mostrar información estadística acerca del uso de las carpetas compartidas, mostrando la distribución por tipos de archivos (capacidad usada en ofimática, en pdf, en archivos comprimidos, multimedia, etc.) para saber en qué se usan los file sharings, así como también distribución por tamaños de archivos. Adicionalmente que muestre la distribución por accesos, para conocer la cantidad de información que NO se ha accedido en el tiempo (por ejemplo, capacidad que no se ha leído en 12 meses o más). También deberá ser capaz de reconocer comportamiento anómalo y reportarlo, como por ejemplo modificaciones masivas de información, típico de un ataque ransomware. Se debe incluir en la oferta la licencia nativa para la funcionalidad de File Sharing corporativo con una capacidad de uso habilitada de un mínimo de 10 TB útiles (o, en su defecto, que cubra la totalidad de la capacidad útil del clúster) , permitiendo al Organismo explotar de manera real las herramientas analíticas de uso, estadísticas de acceso y detección de comportamiento anómalo por Ransomware detalladas en este apartado. Storage Basado en Objetos (S3) Capacidad de ofrecer nativamente, y de manera distribuida, almacenamiento basado en objetos (Object Storage). El acceso al almacenamiento por objetos deberá ser compatible con el API S3 mediante HTTPS, y permitir políticas de tipo Write Once Read Many (WORM). La capacidad de ofrecer Storage por objetos debe poder escalar en capacidad agregando nodos de la misma forma que el Cluster Hiperconvergente. La gestión de esta solución de Object Storage deberá estar integrada en la misma consola de Gestión del Cluster Hiperconvergente. Este tipo de storage deberá poder replicar hacia otro cluster secundario para disponer de tolerancia contra desastres en caso que el data center genere indisponibilidad. Protección de Datos y VMs Los datos se protegerán a través de múltiples copias de los bloques distribuidos entre todos los nodos del cluster, de manera de garantizar que los datos sigan disponibles aún en caso de falla de algún disco o incluso por la falla de un nodo completo. El cluster deberá tener los recursos necesarios para tener el 100% de las VMs encendidas y el 100% de los datos protegidos aún si falla un nodo completo (configuración tipo N+1). En este caso, si falla un nodo, los recursos de storage deben ser suficientes para reconstruir la información perdida y que siga protegida para poder asegurar su disponibilidad en caso de fallos. La cantidad de copias de cada bloque podrá ser configurado en modo 2 ó 3, dependiendo de la cantidad de nodos instalados, incluso definiendo estas réplicas a nivel de datastore o container. En los casos de configuraciones departamentales, tipo “edge” u “oficinas remotas” de un solo nodo, la protección se hará a través de la copia de los datos entre diferentes discos del mismo nodo, soportando 2 copias de cada bloque. •Esta protección de datos deberá realizarse entre los múltiples Servidores/Nodos que componen el Clúster, de manera distribuida (permitiendo usar todos los nodos del cluster para esta protección distribuida, no estando limitado a un esquema 1+1 ni a sub-grupos específicos de discos o nodos) •En caso de una falla, la solución basada en Software debe actuar de manera automática e inmediata, creando nuevas copias de los datos, de manera de mantener el nivel de protección hasta que se reemplace el componente que haya fallado. •Capacidad de incorporar una licencia que permita encriptar los datos almacenados en los discos (Data-at-Rest Encryption (DaRE) ), sin necesidad de Hardware específico (encriptación por software). El algoritmo de encriptación deberá ser como mínimo AES-256 y la solución debe cumplir FIPS 140-2, y deberá incluir el sistema de gestión de llaves (keys) centralizado. Replicación Remota para Disaster Recovery El cluster ofertado debe poder replicar contra otro cluster de similares características (no necesariamente iguales, pues es posible que no se repliquen todas las VMs) que se encuentre en otro sitio. Adicionalmente la solución de replicación remota debe de permitir replicar máquinas virtuales entre hipervisores diferentes para poder facilitar la migración de un hipervisor a otro. Se deberá soportar la réplica entre clusters hiperconvergentes en diferentes sitios (para un esquema de alta disponibilidad geográfica). La réplica deberá ser nativa y configurable desde la misma consola de administración de la plataforma hiperconvergente. Se deberán soportar las siguientes alternativas de replicación remota entre Clusters con una granularidad a nivel de VM: •Réplica Asincrónica (RPO = 1 hora o más) entre múltiples Clusters/Sites sin estar limitado a una réplica entre solo dos Clusters. Esta opción debe venir incluida en la oferta. •Réplica Near-Sync (RPO = 1 minuto o más) entre múltiples Clusters/Sites sin estar limitado a una réplica entre solo dos Clusters. •Réplica Sincrónica (RPO=0). •La solución deberá de tener la capacidad de realizar respaldos a AWS (Amazon Web Services). Adicionalmente, se debe soportar un orquestador de DR de manera que sea posible configurar el orden en que se deben encender las VMs en caso de un failover. Esto es opcional. Crecimiento La solución debe contar con la capacidad de expandir la capacidad de la infraestructura en formato “scale-out”, esto es, agregar servidores al cluster, de modo que se cuente con más recursos de CPU, memoria RAM y Storage. El crecimiento deberá ser en caliente, es decir, sin que se deba bajar el servicio, sin bajar VMs ni los nodos actualmente existentes del cluster. Además, esta tarea debe estar automatizada, es decir, que el administrador deba realizar la menor cantidad de tareas posible, evitando errores humanos. El sistema deberá soportar diferentes configuraciones de servidores en un mismo Cluster (aportando capacidad al mismo cluster hiperconvergente), de modo que se pueda escalar aumentando la capacidad del recurso que se requiere, por ejemplo, es posible que se necesite más capacidad de almacenamiento, pero poca CPU y poca RAM, o se requieran servidores con alta capacidad de cómputo, pero poco storage. Deberá ser posible mezclar nodos All-Flash (SSD) junto con nodos puramente NVMe de diferentes capacidades o cómputo, contribuyendo todos al storage total distribuido. No se admitirá la incorporación de tecnologías de almacenamiento mecánico (HDD) que degraden la latencia o la resiliencia del clúster. Adicionalmente, deberá ser posible agregar servidores de generaciones superiores, de modo que el crecimiento pueda realizarse con tecnologías nuevas que vayan apareciendo durante la vida del cluster. También se debe soportar la posibilidad de remover nodos del cluster, sin detener el servicio del cluster ni bajar VMs (“en caliente”). Este proceso debe estar automatizado. Actualizaciones de Software y Firmwares La solución deberá permitir actualizaciones de software, ya sea el software de hiperconvergencia, el hipervisor o el software de administración, sin detener las cargas de trabajo (VMs) que están corriendo en la solución ofertada. El upgrade debe funcionar de forma desatendida (automatizada) para todos los nodos que forman parte del cluster. La solución ofertada deberá permitir los updates/upgrades de los firmware del hardware ofertado (actualizaciones de BIOS, firmware, etc.) desde la misma consola de administración y, también, sin detener el servicio del cluster ni bajar las VMs y en forma automatizada (desatendida) para todos los nodos que conforman el cluster. Virtualización de Servidores (Hipervisor) La solución ofrecida deberá incluir el hipervisor de base (integrado), cuya licencia esté integrada e incluida en la solución ofertada y que cuente con soporte del fabricante de la solución hiperconvergente. Dicho hipervisor deberá soportar al menos: Movimiento de VMs entre los nodos físicos en caliente (Live Migration), High-Availability de VMs (reiniciar la VM en otro nodo automáticamente en caso de falla), “Resource Scheduler” de VMs entre los nodos por consumo de recursos, Import/Export de VMs en formatos Standard OVA/OVF, Hot-Add de recursos a VMs (CPU, RAM, vDisk), compatibilidad de CPU, consola de la VM vía Web. Los switches virtuales deben ser distribuidos, con soporte para VLANs, y las puertas físicas ethernet que use deben soportar un esquema de uso del tipo activo/pasivo y activo/activo (LACP) para los casos que los switches Top-of-the-Rack (TOR) soporten LACP. Todo el monitoreo, telemetría y administración, tanto del hipervisor, como de las VMs y los nodos físicos, debe realizarse desde la misma consola gráfica de administración. Adicionalmente al hipervisor de base incluido en la solución, la plataforma hiperconvergente ofrecida deberá ser agnóstica al hipervisor, permitiendo al usuario cambiar el hipervisor de base. Como mínimo deberá soportar VMware ESXi, Microsoft Hyper-V y KVM (o basados en KVM). La solución hiperconvergente deberá soportar a: •Mover VMs entre hosts físicos en caliente (vMotion) •Levantar VMs en otro host automáticamente en el caso que el host donde corre la VM falle (High Availability) •Resource Scheduler automático y en funcionamiento (Dynamic Resource Scheduler) Microsegmentación de Redes El hipervisor integrado deberá soportar la configuración de microsegmentación de redes virtuales, permitiendo configurar, aplicar y monitorear políticas de seguridad de tráfico con granularidad de Direcciones IP, Subnets y puertos, aún para VMs que se encuentren dentro de las mismas VLANs. La administración y configuración de políticas de seguridad deben realizarse dentro de la misma consola de administración de la plataforma hiperconvergente. Esta funcionalidad es opcional, pero deberá poder activarse en el futuro (agregando las licencias que sean necesarias) sin la necesidad de tener que instalar software para este propósito, debe venir ya instalado y solo activarse. Virtual Private Cloud (VPC) y Network Overlay La solución debe incluir la capacidad para la construcción de Tenants o VPCs, para la creación de ambientes de operación independientes, de modo que se puedan configurar redes virtuales dentro de cada VPC. Las redes de cada VPC deben ser independientes de otras VPCs, de modo que se puedan tener “Overlay” de rede, es decir, que dos (o más) redes tengan el mismo direccionamiento IP, sin que se vean entre ellas. Las redes dentro de las VPCs deben tener forma de conectarse con las redes externas, como hacer “stretch Layer 2” entre VPCs y redes físicas, además de soportar VPN y Floating IPs. La solución debe ofrecer mecanismos para que orquestadores/controladores de segundo nivel puedan interactuar a través de mecanismos tipo Rest API/Script/Shell/Integraciones nativas. La administración de VPCs y subnets virtuales debe realizarse desde la misma consola de administración de la solución hiperconvergente. Esta funcionalidad es opcional, pero deberá poder activarse en el futuro (agregando las licencias que sean necesarias) sin la necesidad de tener que instalar software para este propósito, debe venir ya instalado y solo activarse. Portal de Autoservicio IaaS – (portal web de autoservicio para aprovisionamiento de recursos) La solución deberá incluir un portal de autoservicio, con acceso basado en roles (personalizables) y con la posibilidad de limitar la utilización máxima de recursos (asignar cuotas de recursos de hardware). Este portal deberá ofrecer la capacidad de aprovisionar y administrar máquinas virtuales en modo autoservicio, con la posibilidad de definir múltiples proyectos en donde los usuarios asignados a estos proyectos disponen de acceso al catálogo de plantillas de imagen de VM e imágenes de disco acorde a los permisos definidos. Mediante este sistema, se deberá proporcionar un Portal para usuarios internos tipo IaaS (Infrastructure as a Service), de manera de poder asignar una cuota de uso máximo y que el usuario pueda crear y administrar sus propias VMs dentro de esa cuota de recursos (CPU, RAM, Storage) que el administrador le ha asignado. Se debe poder asignar roles a los usuarios para que solamente puedan ver/administrar las VMs permitidas y dentro de la cuota que ha sido asignada. Esta funcionalidad debe estar integrada con Active Directory, para asignar los diferentes roles a usuarios y/o grupos de Active Directory. Las licencias necesarias para este servicio deberán estar incluidas en la propuesta. Visibilidad de Costo La solución debe proporcionar la capacidad para el análisis de costos, permitiendo visibilizar y crear reportes de que modelen y reflejen los valores de la operación que incluyan tanto hardware, software, instalaciones, administración entre otros parámetros. Esta capacidad de incluir en su análisis las siguientes características: •Costo real de la infraestructura •Métricas y Visibilidad de costos de la infraestructura, además de recursos, con granularidad diaria y mensual •Las métricas de costos deben tener granularidad a nivel de VMs •Debe ser posible configurar “Centros de Costos” para organización de reportes y presupuestos departamentales. Kubernetes La solución deberá incluir una funcionalidad que permita administrar el ciclo de vida de clusters Kubernetes, esto es: •Debe permitir el despliegue automatizado de clusters Kubernetes. •Debe permitir el crecimiento tipo “Scale-Out” de nodos/workers a los clusters Kubernetes. •Debe permitir las actualizaciones de versiones de Kubernetes. •Debe desplegar el driver CSI para la configuración de Storage Persistente (del mismo cluster hiperconvergente). Esta funcionalidad deberá estar incluida y licenciada para todos los nodos de los clusters hiperconvergentes ofertados. Administración La consola de administración deberá: •Accederse mediante un browser y estar basada en HTML5. No se acepta instalar ningún software cliente en las estaciones de trabajo del administrador. •Proveer una consola centralizada para todo el entorno. •La consola de Administración deberá permitir administrar y monitorear a todos los servidores/nodos que forman parte del Clúster. •La consola de Administración deberá permitir administrar y monitorear centralizadamente todos los clusters en caso de disponer de diferentes clusters en varios sitios o ubicaciones. •La consola de Administración deberá ejecutarse sobre los mismos nodos del Clúster que administra, aprovechando la tolerancia a fallos del mismo (Ej. La consola debe permanecer disponible ante la falla de cualquiera de los nodos). •Proveer accesos por línea de comandos basados en “SSH”. •Contener autenticación LDAP Active Directory, CAC Prompt y certificados firmados por SSL. •Se deberá guardar LOG de las acciones generadas por un usuario, conteniendo al menos: usuario que estaba autenticado, horario y acción ejecutada. •La consola deberá enviar alertas por email vía SMTP y tener la funcionalidad “Call Home” de modo que reporte automáticamente al soporte del fabricante en caso de la falla de componentes. •Soportar la gestión de la infraestructura de forma completa mediante APIs REST para permitir así la integración con sistemas de gestión y orquestación de terceros, integración con “pipelines CI/CD”, integración con “Infraestructura as Code”, automatización, entre otros. •Tener la capacidad de facilitar una consola gráfica, que permita visualizar los recursos utilizados por las VMs independientemente del tipo de hipervisor. •Permitir crear alertas y tareas personalizadas de acuerdo al consumo de recursos. Telemetría La solución de administración deberá permitir: •La solución deberá incluir herramienta de monitoreo y todas las métricas necesarias para controlar el estado de salud del entorno de virtualización y hardware de forma unificada: •Gráficos de consumo CPU, RAM, IOPS, Ancho de Banda, Latencia de acceso a datos del entorno completo •Gráficos de consumo CPU, RAM, IOPS, Ancho de Banda, Latencia de acceso a datos de los servidores físicos •Gráficos de consumo CPU, RAM, IOPS, Ancho de Banda, Latencia de acceso a datos de cada máquina virtual del entorno •Todos los gráficos deberán ser personalizables por el usuario de tal forma que se pueda elegir en cada momento qué métricas desea analizar y sobre qué entidades (VMs, servidores, etc.) •La solución deberá incluir mecanismos de detección automática y alerta de comportamiento anormal de todo el entorno incluyendo Hardware (CPU, RAM, Discos) y VMs. •Entregar estadísticas completas sobre las máquinas virtuales y nodos físicos, como consumos de vCPU, RAM y discos, y de IOPS de lectura, IOPS de escritura y latencias. Capacity Planning Utilizando la información de la telemetría, también debe proveer mecanismos de capacity planning, la misma consola de administración deberá permitir: •Mostrar gráficamente el consumo de recursos en el tiempo y extrapolar hacia el futuro, de modo de predecir cuándo faltará algún o algunos recursos, ya sea CPU, RAM o almacenamiento en discos, para planificar en forma proactiva y con tiempo de antelación, desocupar recursos o agregar nuevos nodos. •Simular cargas nuevas, mostrando el impacto en el uso de los recursos actuales y proponiendo la cantidad de recursos nuevos en caso que se requieran al agregar estas cargas nuevas. •Analizar el consumo de recursos de las VMs actuales de modo que avise de VMs que estén sobre-aprovisionadas, es decir, que se hayan asignado muchos recursos que no esté utilizando. Por ejemplo, se hayan asignado 16GB de RAM a una VM, pero que históricamente no haya usado más de 4GB de RAM, de este modo se pueda quitarle recursos de memoria que podrían asignarse a otras VMs. •Analizar el consumo de recursos de las VMs actuales de modo que avise de VMs que estén con problemas de bajos recursos provisionados. Por ejemplo, VMs en que el consumo de CPU sea superior al 98% en forma constante o recurrente, esto es un signo de que le falta CPU. El software de administración debe permitir mostrar y alertar este análisis, de modo que se puedan realizar las acciones necesarias para arreglar este problema. •Analizar el consumo de recursos de las VMs actuales de modo que avise de VMs que estén sobre-exigiendo los recursos provisionados. Lo que normalmente se les puede llamar “VMs Bully”, pues podrían estar afectando el rendimiento de otras VMs. •Analizar el comportamiento de VMs que podrían estar haciendo “nada”, es decir, VMs que están encendidas, pero por el consumo de recursos podrían estar solamente encendidas sin estar realizando ninguna acción o procesos (ninguna tarea útil) y que podrían apagarse e incluso eliminarse. Automatización de Operaciones El software de administración debe permitir automatizar operaciones que normalmente se hacen en forma manual, debe permitir: •Crear políticas para agregar recursos automáticamente, por si a una o más VMs les falta recursos. Si el sistema operativo “guest” (dentro de la VM) lo soporta, agregar estos recursos en caliente. •Apagar VMs que se encuentren inactivas, es decir, que no tengan movimientos ni consumos de recursos. •Crear políticas para quitar recursos automáticamente, si hay VMs que le sobren recursos, que los quite en forma programada y automáticamente. Debe ser programada pues los sistemas operativos “guest” (Linux y Windows) no soportan eliminar recursos en caliente, así que el software de administración debe ser capaz de seleccionar una fecha y hora para bajar la VM, quitar los recursos y encenderla, todo en forma automática. •Crear alguna otra acción de acuerdo a alertas, eventos o gatilladores externos vía REST API o WebHooks. Renglón 2 - Switch Ethernet para cluster de Hiperconvergencia Las características requeridas para cada switch son: •48 puertos que soporten como mínimo velocidades de 10/25 Gbps basados en interfaces SFP28 •Puertos Uplink de 40 Gbps o superior (al menos 2 puertos Uplink). •Completamente Wire-Speed (backplane no bloqueante, Line-Speed – Sin Oversubscription) •Baja Latencia: Minimizar la latencia entre puertos al orden de microsegundos o nanosegundos; categoría TOR Enterprise. •Capacidad de buffer por puerto de al menos 400 KB como mínimo. •12 Cables del tipo Direct Attach Copper (DAC) / Twinax nativos de 25 Gbps, de 3 metros de longitud como mínimo, compatibles con las interfaces SFP28/SFP+ de los switches y los nodos propuestos, garantizando conectividad a velocidad de línea sin sobre-suscripción ni estrangulamiento de ancho de banda para el tráfico del clúster hiperconvergente. Renglón 3 – Almacenamiento para copias de seguridad Se requiere una solución de hardware de almacenamiento de copias de seguridad por niveles, orientada a garantizar la rapidez en respaldos y restauraciones, retención eficiente a largo plazo y protección frente a ataques. Es igualmente, requisito indispensable, que sea una solución abierta, con capacidad de crecimiento, flexible según se vaya requiriendo, sin disminuir la velocidad y rendimiento aún y cuando crezca la ingesta y el volumen de los datos. Es requisito indispensable que los equipos propuestos no se encuentren en el final de su ciclo de vida comercial (End of Life) ni de soporte oficial (End of Support) al momento de la apertura de la oferta. El fabricante deberá garantizar la disponibilidad de repuestos, parches de seguridad y actualizaciones de firmware por un período mínimo de cinco (5) años contados a partir de la adjudicación. Detalle Técnico / Funcional Deberá integrarse con la infraestructura existente y ofrecer escalabilidad para acompañar el crecimiento de datos, evitando la obsolescencia tecnológica y la necesidad de reemplazos disruptivos. El equipo de Almacenamiento para Copias de Seguridad deberá contar con las siguientes características: Arquitectura: Sistema de almacenamiento de copias de seguridad por niveles, compuesto como mínimo por: •Zona de Aterrizaje (Landing Zone): Basada en caché de disco, para respaldos y restauraciones de alta velocidad, incluyendo recuperaciones instantáneas de máquinas virtuales. •Repositorio de Retención (Repository Tier): almacenamiento optimizado para deduplicación, orientado a la conservación a largo plazo, con mecanismo de aislamiento lógico (air gap) para mitigación de riesgos de ciberseguridad. •Arquitectura escalable en modo Scale-Out (crecimiento horizontal), esto es la capacidad de incorporar con cada módulo: CPU, Memoria, Conectividad y Almacenamiento. Este crecimiento debe realizarse de forma transparente y sin generar silos de información dentro de la infraestructura. •No se aceptarán soluciones definidas por software. •Debe poseer activadas todas las licencias de funcionalidad disponibles para el sistema o equipo, sin limitación y de forma perpetua. Capacidad: •Factor de forma: El clúster de almacenamiento en su totalidad, incluyendo la suma de todos los nodos físicos que componen la solución, deberá ocupar un espacio máximo consolidado de 4 unidades de rack. •Capacidad Utilizable: Raw: 216 TB, Useable: 162 TB. 81 TB Full Backup. •Tolerancia a Fallos: La configuración interna del almacenamiento deberá implementarse bajo un esquema de protección tolerante a fallas físicas de hardware equivalente a paridad distribuida doble (RAID 6 e incluir componentes de repuesto en línea activos (Hot Spare) instalados de fábrica. La capacidad RAW total cotizada por el oferente deberá calcularse para garantizar el espacio neto utilizable solicitado bajo este esquema de protección •Capacidad Lógica: Hasta 2 PB como mínimo. •Discos Duros: Compuesto por discos SAS. •Memoria RAM: El sistema de almacenamiento deberá contar con una capacidad mínima global de 512 GiB de memoria RAM de grado empresarial con tecnología de corrección de errores (ECC), distribuida de manera homogénea mediante módulos nativos de 128 GiB instalados de fábrica en cada uno de los dos nodos físicos que integran el clúster •Puertos de Red: El equipamiento deberá incluir al menos 2 (dos) puertos de 1 GbE y un mínimo de 4 puertos de 25 GbE nativos (SFP28) dedicados. El oferente deberá suministrar la totalidad de los transceivers ópticos de 25G SR y cables de conexión (Patchcords) de fibra óptica multimodo OM4 de una longitud mínima de 5 metros para la totalidad de las interfaces de alta velocidad solicitadas. •Fuentes de alimentación: Redundantes y HotPlug. Incluir cables de energía C13/C14 para la conexión a PDU. •Configuración RAID: RAID 6 con Hot Spare. •Integración de nivel de repositorio sin conexión directa a red para protección frente a ataques de Ransomware. •Funcionalidades de seguridad avanzadas: autenticación robusta, cifrado en tránsito y en reposo, y aislamiento de datos críticos. •Opciones de recuperación ante desastres (DR) soportadas de forma nativa. •Restauraciones rápidas sin necesidad de procesos de rehidratación de datos. •Mecanismos de concurrencia de trabajos de respaldo múltiples en paralelo. •Debe tener capacidades de tolerancia a fallas de discos, fuentes de alimentación y ventiladores. •Debe permitir la implementación de topologías de replicación, como 1 a 1, 1 para N, N a 1 y equipos en cascada. La solución debe permitir la replicación de los datos retenidos en la nube pública. Eficiencia y Optimización: •La solución de almacenamiento deberá garantizar una tasa de transferencia e ingesta de datos agregada de al menos 4.8 TB/hora sostenidos durante las operaciones concurrentes de copia de seguridad y restauración •Deduplicación avanzada para optimizar el espacio de almacenamiento requerido en retención de largo plazo. •Bajo consumo de espacio en rack, energía y refrigeración. •Escalabilidad modular. •Deberá integrarse de manera nativa con el software de backup ofrecido, lo que permite reducir la infraestructura de CPU y memoria requerida. Renglón 4 – Licencias para backup con monitoreo y analítica avanzada. Se requiere la adquisición de licencias de software bajo modalidad de suscripción por un periodo de treinta y seis (36) meses, para una plataforma de protección de datos de clase empresarial que incluya, como mínimo, las siguientes capacidades: Respaldo •La solución debe proporcionar una copia de seguridad eficiente ‘incremental para siempre’ e incluir opciones de copias de seguridad completas y ad-hoc. •La solución debe admitir la copia de seguridad de VM directamente desde SAN. •La solución debería detectar automáticamente las máquinas virtuales con el uso compartido de bus SCSI y excluirlas de la copia de seguridad. •La solución debería detectar automáticamente el espacio libre del datastore productivo y evitar el snapshot de copia de seguridad si el espacio está por debajo del umbral definido. •La solución debería monitorear automáticamente la latencia del datastore productivo durante la copia de seguridad y reducir la velocidad de la copia de seguridad si la latencia del datastore supera un umbral definido. •La solución debería detectar automáticamente los snapshots de VMware huérfanas y eliminarlas. •La solución debería permitir la exclusión de discos de máquinas virtuales y archivos de intercambio (swap) en copias de seguridad basadas en snapshots. •La solución debería permitir la exclusión de archivos y carpetas de la copia de seguridad basada en snapshots. •La solución deberá permitir la exclusión de los bloques marcados como eliminados para reducir el tamaño de la copia de seguridad y aumentar el rendimiento del respaldo. •La solución no deberá requerir agentes implementados en máquinas virtuales para facilitar el respaldo de aplicaciones y la recuperación granular. •La solución no debe necesitar realizar copias de seguridad de sistema operativo separadas de las copias de seguridad de datos de la aplicación en máquinas virtuales para facilitar la recuperación granular de elementos de la aplicación. •Protección Universal de Cargas de Trabajo: Respaldo y recuperación a nivel de imagen para entornos virtuales, físicos y aplicaciones. •Gestión de Entornos de Colaboración: Protección nativa para los servicios de mensajería y almacenamiento en la nube, incluyendo capacidades de auditoría, búsqueda y restauración granular. Respaldo con integraciones de snapshot de almacenamiento •La solución debe integrarse con los sistemas de almacenamiento y utilizar snapshots de almacenamiento para las operaciones de respaldo. •La solución debería poder leer los datos de la máquina virtual directamente desde un snapshot de almacenamiento a través de una conexión SAN. •La solución deberá proporcionar la capacidad de explorar máquinas virtuales en snapshots de almacenamiento y recuperar instantáneamente la máquina virtual, el archivo del sistema operativo o la carpeta o los elementos de la aplicación directamente desde el snapshot de almacenamiento. Esta capacidad también debería aplicarse a los snapshots de almacenamiento creados independientemente de la aplicación de respaldo. •La solución deberá proporcionar la capacidad publicar instantáneamente los discos de la máquina virtual Windows o Linux en otra máquina virtual para recuperaciones masivas, para que aplicaciones de 3ros escaneen el disco, o para minado de datos sin necesidad de restaurar la maquina original. •La solución deberá poder utilizar snapshots de almacenamiento para crear una copia de la máquina virtual en un entorno de red aislado para fines de prueba. Protección de datos continua •La solución deberá ser capaz de replicar máquinas virtuales sin snapshots del ambiente virtual y debe capturar todas las E/S de escritura directamente del disco de la VM. •La solución deberá ser una replicación asíncrona que se pueda utilizar sin limitación de distancia. •La funcionalidad deberá estar incluida en el mismo licenciamiento de respaldo, es decir que no debe requerir alguna otra licencia adicional. •La funcionalidad debe permitir File-level Recovery desde una réplica •La funcionalidad debe permitir Application item-level Recovery desde una réplica •La funcionalidad debe ofrecer un visualizador de anomalías de I/O para permitir la recuperación justo en el momento antes del ataque de malware •La funcionalidad debe ofrecer Planned Failover •La funcionalidad debe ofrecer Failback to Cluster Respaldo de hipervisor compatible con arquitectura de código abierto •Crear copias de seguridad de las máquinas virtuales (VMs) de hipervisor compatible con arquitectura de código abierto y almacenarlas en repositorios de respaldo. •Se debe soportar repositorios S3 y SOSAPI •Crear instantáneas (snapshots) de las VMs de hipervisor compatible con arquitectura de código abierto y de los dominios de protección. •Crear copias de seguridad funcionalidad de exportación y compresión de máquinas virtuales de las VMs de hipervisor compatible con arquitectura de código abierto. •Crear varias instancias (copias) de los mismos datos respaldados en diferentes ubicaciones. •Restaurar VMs desde copias de seguridad e instantáneas de hipervisor compatible con arquitectura de código abierto al entorno original de hipervisor compatible con arquitectura de código abierto. •Restaurar VMs desde VMware ESXi y Microsoft Hyper-V al entorno hipervisor compatible con arquitectura de código abierto. •Restaurar VMs desde copias de seguridad de oVirt KVM y Proxmox VE al entorno hipervisor compatible con arquitectura de código abierto. •Restaurar VMs desde copias de seguridad de Microsoft Azure, Amazon Web Services (AWS) y Google Cloud al entorno hipervisor compatible con arquitectura de código abierto. •Restaurar máquinas físicas desde copias de seguridad creadas por agentes de respaldo para máquinas físicas al entorno hipervisor compatible con arquitectura de código abierto. •Restaurar VMs desde copias de seguridad de hipervisor compatible con arquitectura de código abierto a entornos de Microsoft Azure, Amazon Web Services (AWS) y Google Cloud. •Restaurar VMs desde copias de seguridad de hipervisor compatible con arquitectura de código abierto a entornos VMware vSphere y Microsoft Hyper-V. •Realizar recuperación instantánea de VMs y máquinas físicas en entornos hipervisor compatible con arquitectura de código abierto, VMware vSphere y Microsoft Hyper-V. •Restaurar archivos y carpetas de los sistemas operativos invitados de las VMs de hipervisor compatible con arquitectura de código abierto. •Restaurar elementos de aplicaciones (como Microsoft Active Directory, Microsoft Exchange, Microsoft SharePoint, Oracle Database y Microsoft SQL Server). •Restaurar discos de VMs de hipervisor compatible con arquitectura de código abierto y adjuntarlos a VMs que se ejecutan en clústeres hipervisor compatible con arquitectura de código abierto. •Exportar discos de VMs de hipervisor compatible con arquitectura de código abierto respaldadas a formatos VMDK, VHD y VHDX. •Montar discos de VMs de hipervisor compatible con arquitectura de código abierto respaldadas en cualquier servidor y acceder a los datos en modo de solo lectura. •La solución debe integrarse con plataforma centralizada de administración de infraestructura •La solución debe integrarse con Microsoft VSS en las máquinas virtuales para respaldo consistente de aplicaciones con transaction log shipping para permitir recuperaciones point-in-time. •La solución debe proporcionar exploradores para recuperación de ítems de aplicación MS Active Directory, MS SQL Server, Oracle y PostgreSQL. •La solución debe ofrecer detección in-line de entropía en los File Systems mediante Machine Learning entrenada en la detección de indicadores de compromiso. •La solución debe permitir indexar los File Systems de las máquinas virtuales para habilitar la detección de extensiones de malware, notas de ransomware y otros indicadores de compromiso. •La solución debe soportar herramientas de optimización para máquinas virtuales •La solución debe soportar Virtual Trusted Platform Modules vTPM. •La solución debe soportar mecanismo de aislamiento lógico de recursos y control de acceso Respaldo de Proxmox •Crear copias de seguridad de las máquinas virtuales (VMs) de Proxmox VE hasta v9.0 y almacenarlas en repositorios de respaldo. •La solución debe integrarse con Microsoft VSS en las máquinas virtuales para respaldo consistente de aplicaciones con transaction log shipping para permitir recuperaciones point-in-time. •La solución debe proporcionar exploradores para recuperación de ítems de aplicación MS Active Directory, MS SQL Server, Oracle y PostgreSQL. •Se debe soportar HPE StoreOnce Catalyst Copy •Crear copias de seguridad funcionalidad de exportación y compresión de máquinas virtuales de las VMs de Proxmox VE. •Crear varias instancias (copias) de los mismos datos de respaldo en diferentes ubicaciones. •Restaurar VMs desde copias de seguridad de Proxmox VE al entorno Proxmox VE. •Restaurar VMs desde VMware ESXi y Microsoft Hyper-V al entorno Proxmox VE. •Restaurar VMs desde copias de seguridad de hipervisor compatible con arquitectura de código abierto y oVirt KVM al entorno Proxmox VE. •Restaurar VMs desde copias de seguridad de Microsoft Azure, Amazon Web Services (AWS) y Google Cloud al entorno Proxmox VE. •Restaurar máquinas físicas desde copias de seguridad creadas por agentes de respaldo para máquinas físicas al entorno Proxmox VE. •Restaurar VMs desde copias de seguridad de Proxmox VE a entornos de Microsoft Azure, Amazon Web Services (AWS) y Google Cloud. •Realizar recuperación instantánea de VMs de Proxmox VE en entornos VMware vSphere y Microsoft Hyper-V. •Restaurar elementos de aplicaciones (como Microsoft Active Directory, Microsoft Exchange, Microsoft SharePoint, Oracle Database y Microsoft SQL Server). •Restaurar archivos y carpetas de los sistemas operativos invitados de las VMs de Proxmox VE. •Exportar discos de VMs de Proxmox VE respaldadas a formatos VMDK, VHD y VHDX. •Montar discos de VMs de Proxmox VE respaldadas en cualquier servidor y acceder a los datos en modo de solo lectura. •La solución debe ofrecer capacidades de detección de malware en los respaldos de Proxmox VMs incluyendo detección inline de malware y detección de actividad de archivos sospechosa durante el respaldo. •La solución debe poder escanear los respaldos utilizando un Antivirus (externo o provisto por la solución) y reglas YARA. Operaciones de respaldo, entornos físicos Ofrecerá un respaldo basado en agente de entornos físicos •La solución debe admitir copias de seguridad físicas de sistemas operativos Windows, Linux (x86 y Power), AIX, Solaris con soporte a ZFS encryption y MAC. •La solución debería facilitar la copia de seguridad a nivel de imagen y de archivo de entornos físicos o basados en la nube. •La solución debe utilizar la tecnología Changed Block Tracking para copias de seguridad incrementales de cargas de trabajo físicas o basadas en la nube. •La solución debe admitir la copia de seguridad de los servidores de Windows configurados como clúster. •La solución debe proporcionar complementos de respaldo (plugin) para las aplicaciones MS SQL, Oracle RMAN, SAP HANA, SAP MaxDB, DB2 (x86) y DB2 (Power) permitiendo la centralización de repositorio. •Todos los plugins de aplicaciones soportaran la copia de seguridad directa a Object Storage. •Todos los plugins de aplicaciones soportarán encriptación at source. •La solución debe proporcionar conocimiento de la aplicación al realizar copias de seguridad de MySQL y PostgreSQL hasta la v17 que se ejecutan en Linux. •La solución debe proporcionar conocimiento de la aplicación al realizar copias de seguridad de MongoDB hasta la v8 per-replica set que se ejecutan en Linux. •La solución debe ofrecer protección de MongoDB per-replica set oplog (transaction log) permitiendo recuperaciones point-in-time de réplica sets, databases y collections. •La solución debe permitir mover los archivos de respaldo entre cualquier tipo de repositorio de respaldo (aun cuando el repositorio destino sea de un tipo distinto al del origen) sin necesidad de usar la gestión regular de archivos (copiar/pegar) •La solución debe permitir mover los respaldos entre las tareas y copiar los respaldos entre repositorios. Operaciones de recuperación Recuperación de VMs y servidores físicos •La solución debe proporcionar una portabilidad completa en cualquier archivo de respaldo propietario y no debe depender de ninguna infraestructura de respaldo como, por ejemplo, el catálogo central, para la recuperación. •La solución debe proporcionar tecnología de recuperación Instantánea de respaldos de la máquina virtual o de la máquina física hacia Vmware vSphere, Microsoft Hyper-V y Microsoft Azure. •La solución debe proporcionar tecnología de recuperación de la máquina virtual snapshot, correr múltiples Virtual Machine directamente desde el servidor de copia de seguridad del repositorio. •La solución debe proporcionar la tecnología de recuperación Changed Block Tracking para máquinas virtuales VMware. •La solución debe permitir que las copias de seguridad de máquinas virtuales en la nube puedan ser restauradas en cualquier nube pública o volver a una máquina virtual en un hipervisor local en las instalaciones. •La solución debería permitir la recuperación de VMware Virtual Machine a través del canal de fibra SAN. •La solución debe escanear los datos de la máquina virtual con un software antivirus antes de restaurar la máquina al entorno de producción. La solución debería abortar la operación de recuperación si se detecta malware. •La solución debería proporcionar la capacidad de iniciar la máquina virtual en un entorno de red aislado durante el proceso de recuperación e inyectar un script en el sistema operativo invitado que permita que el servidor se modifique para fines de cumplimiento antes de la recuperación. Dicha funcionalidad debe soportar NSX-T. •La solución debería proporcionar la capacidad de verificar la consistencia de los backups y escanear el contenido de estos con un antivirus y/o con reglas YARA sin requerir un entorno de red aislado. •La solución debería proporcionar una recuperación completa de la copia de seguridad basada en el Agente con la capacidad de crear un medio de arranque para el servidor específico, del tipo bare metal. •La solución debe permitir la recuperación instantánea de copias de seguridad basadas en agentes para VMware o máquinas virtuales Hyper-V. •La solución debe permitir la recuperación instantánea de copias de seguridad de sistemas de archivos tipo NAS (FileShares). •La solución debería facilitar la recuperación de VMware o una copia de seguridad basada en agentes directamente en Google Platform, Amazon AWS o Microsoft Azure y Microsoft Azure Stack. •La solución debería convertir automáticamente UEFI a BIOS durante la operación de recuperación de Amazon AWS. Recuperación a nivel de archivo •La solución debería facilitar las operaciones de recuperación a nivel de archivo sin la necesidad de implementar un agente o plugin de recuperación en un servidor virtual o físico. •La solución debería poder recuperar archivos en un sistema operativo invitado de máquina virtual incluso cuando no haya conexión de red entre el servidor de respaldo y la máquina virtual. •La solución debe permitir delegar operaciones de restauración y proporcionar una interfaz de usuario de autoservicio basada en la web y la capacidad de buscar máquinas, recursos compartidos de archivos y archivos específicos en todas las copias de seguridad. •La solución debe admitir todos los sistemas de archivos dentro del alcance en el Ministerio de Justicia. •La solución debe permitir restaurar las listas de control de acceso (ACL) de archivos y carpetas sin la necesidad de sobre escribir los archivos. Recuperación de elementos de aplicación •La solución deberá disponer de un Explorador para permitir el restore de ítems de las aplicaciones de Microsoft Active Directory, Exchange, SQL, SharePoint, Oracle, SAP HANA, PostgreSQL y MongoDB. •La solución debería admitir la recuperación granular de bases de datos Oracle a partir de copias de seguridad basadas en imágenes u Oracle RMAN. •La solución no debe usar un producto de terceros para la recuperación granular de elementos de la aplicación. •La solución debe proporcionar una interfaz de usuario de autoservicio basada en la web y la capacidad de examinar y recuperar elementos de Microsoft Exchange y bases de datos SQL u Oracle. •La solución debe permitir la recuperación instantánea o la publicación de base de datos SQL, Oracle, MongoDB y PostgreSQL desde la copia de seguridad al último estado o a un punto anterior en el tiempo a cualquier servidor de base de datos de producción o clúster (físico o virtual) en minutos, independientemente de su tamaño. Detección e identificación de Cyber Amenazas •Todas las capacidades de detección de malware estarán disponibles para respaldos de máquinas Linux y Windows basados en host y basados en agente. Esto incluye el análisis de actividad sospechosa del sistema de archivos durante y después de los respaldos. Escaneo in-line durante el backup •La solución debe permitir el escaneo in-line de los backups con bajo impacto utilizando análisis de entropía con Machine Learning para detectar datos encriptados por un malware, incluido en la licencia de respaldo y misma consola. •El escaneo in-line también debe detectar onion links, cambios en el file system, comparar metadatos como grado de compresión de los archivos y cambios masivos en la extensión de estos, incluido en la licencia de respaldo y misma consola. Escaneo de imágenes de backup off-line •La solución debe permitir escanear los backups en los repositorios bajo demanda o de manera agendada para detectar los backups limpios y sospechosos. •La solución debe permitir aplicar búsquedas con regla YARA para detectar malware o cumplir con compliance. Escaneo proactivo de backups •La solución iniciará automáticamente un análisis basado en firmas de los respaldos cada vez que se detecte actividad sospechosa durante el respaldo. •La solución permitirá resolver automáticamente los eventos de malware en función de los resultados del análisis, reduciendo significativamente los falsos positivos. Requisitos de la solución de respaldo Copia de seguridad en disco •La solución debe estar definida por software y ser capaz de ejecutarse localmente o en cualquier plataforma en la nube. Se refiere únicamente a la flexibilidad lógica del software de gestión de backup, el cual debe poseer una arquitectura agnóstica respecto a la plataforma de cómputo subyacente para su consola de administración •La solución debe ser independiente del almacenamiento y debe contar con tecnología integrada de deduplicación y compresión. •La solución debe implementar mecanismos de autorización doble (four-eyes authorization) para prevenir el borrado accidental o intencional de imágenes de backups o repositorios de backup, cambios en los usuarios, roles y accesos. •La solución deberá asegurar las copias de seguridad en repositorios reforzados a prueba de malware y hackers con copias de seguridad inmutables, para prevenir el cifrado o eliminación por ransomware y debe admitir credenciales que se usan una sola vez y no ser almacenadas en la infraestructura de respaldo, así si el servidor de respaldo se ve comprometido, un atacante no puede obtener las credenciales y conectarse al repositorio reforzado. •La solución debe poder escalar tanto horizontal como verticalmente. •La solución debe proporcionar un mecanismo fácil para expandir o contratar el almacenamiento de respaldo de destino. •La solución debería ofrecer la flexibilidad para ajustar el tamaño del bloque de deduplicación de datos y el nivel de compresión de datos. •La solución debe ser compatible con la inmutabilidad ofrecida por appliances de backup. Seguridad de datos de respaldo •La solución debería encriptar los archivos de respaldo usando el encriptado AES de 256 bits. El cifrado no debe depender de la plataforma de almacenamiento de respaldo. •La solución debe integrarse a servicios KMS (Key Management Server) tales como Fortanix DSM, IBM Security Guardium Key Lifecycle Manager, Thales CipherTrust Manager y otros. •La solución debe proporcionar un cifrado AES de 256 bits con tecnología de protección de pérdida de contraseña, por lo que los datos se pueden descifrar si se pierde la contraseña operativa. •Todos los componentes de la solución de respaldo deben admitir autenticación Kerberos. •La solución debe permitir autenticación multifactor (MFA) para una verificación adicional de usuario en la consola de administración de la solución. •La solución debe incorporar autenticación federada que permita aprovechar proveedores de identidad externos que soporten Security Assertion Markup Language (SAML) 2.0, junto con un servicio compartido de autorización OAuth para acceder tanto a la nueva interfaz web como a la consola de respaldo basada en Windows. •La solución debe ofrecer Role Based Access Control RBAC para un control de acceso detallado para las operaciones de respaldo y restauración en todo el entorno incluyendo respaldos basados en host para VMware vSphere y Microsoft Hyper-V, respaldos basados en agentes, respaldos a nivel de aplicación y respaldos de datos no estructurados (comparticiones de archivos y almacenamiento de objetos). •La solución debe ofrecer un asistente de Roles Personalizados para definir roles y sus permisos asociados. •Los roles recién creados pueden asignarse a usuarios individuales o grupos, garantizando que su nivel de acceso se alinee con las políticas organizacionales y las necesidades operativas. Verificación de datos de respaldo •La solución debería leer y verificar automáticamente la consistencia de los datos de producción en el archivo de copia de seguridad una vez completada la copia de seguridad. En caso de que se detecte corrupción de datos, la solución debería reconstruir automáticamente el bloque dañado con datos de producción. •La solución deberá iniciar automáticamente las máquinas virtuales de VMware y Hyper-V Windows y Linux así como de agentes de nube y físicas a partir de copias de seguridad y verificar el sistema operativo y la disponibilidad de la aplicación. Esta prueba no debe tener impacto en la red de producción. La solución debe proporcionar un informe de verificación de recuperación. •La solución debería escanear automáticamente los datos de producción en busca de virus durante la verificación de respaldo. Copia de seguridad en cinta •La solución debería admitir de forma nativa la copia del respaldo a cinta y no debería requerir software adicional para su administración. •La solución debe admitir copias de seguridad deduplicadas y comprimidas en medios de cinta. •La solución debe admitir medios de cinta WORM, soportar LTO hasta LTO10 e IBM 3592 (Jaguar) •La solución no debe requerir licenciamiento adicional para el uso de librerías sin importar la cantidad de drives que tengan. •La solución debe permitir la visualización del contenido de una cinta. •La solución debe permitir el backup de Distributed File System (DFS) recorriendo toda su estructura. •La solución debe permitir copiar respaldos de object storage en cintas. Copia de seguridad NAS •La solución debe proporcionar una copia de seguridad eficiente basada en archivos incrementales. •La solución debe admitir recursos compartidos de archivos basados en NFS, SMB, Windows y Linux. •La solución debe aprovechar los snapshots basadas en matrices para copias de seguridad basadas en archivos siempre que sea posible •La solución debe aprovechar los snapshots de VSS cuando sea posible •La solución debe proporcionar una recuperación incremental a cualquier plataforma objetivo-heterogénea •La solución debe proporcionar un mecanismo de reversión incremental para cualquier recurso compartido NAS •La solución debe proporcionar la capacidad de archivo granular de archivos, archivando tipos de archivos específicos. •La solución debe proporcionar un mecanismo de comparación con producción para restaurar rápidamente sólo los archivos cambiados por un ataque de ransomware. Copia de seguridad de Object Storage •La solución debe proporcionar point-in-time rollback del estado de un bucket después de un ataque de ransomware o sabotaje. •La solución debe proporcionar recuperación a nivel objetos. •La solución debe permitir el backup de Object Storage a otro Object Storage que estén en Public Cloud o que estén on-premises. •La solución debe permitir el backup de Object Storage a unidades locales dentro de un Scale Out Backup Repository •La solución debe permitir el backup de Object Storage directamente a cinta •La solución debe proporcionar el encriptado de los backups de Object Storage y el backup copy. Operaciones de respaldo en entorno nube •La solución debe estar desarrollada para tareas de protección y recuperación ante desastres para entornos Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS) incluyendo RDS for MS-SQL y RDS for PostgreSQL 17, Amazon DynamoDB y Amazon Elastic File System (EFS), Redshift Cluster y Amazon FSX. También debe permitir respaldar y restaurar las configuraciones de Amazon Virtual Private Cloud (VPC). •La solución debe poder realizar las siguientes operaciones de protección de datos: crear instantáneas nativas de la nube de instancias EC2, crear instantáneas nativas de la nube de los recursos de RDS, crear copias de seguridad a nivel de imagen de instancias EC2 y crear copias de seguridad de los sistemas de archivos EFS. •La solución debe poder realizar las siguientes operaciones de recuperación de datos respaldados: restaurar instancias EC2 completas, restaurar volúmenes de instancias EC2, restaurar archivos y carpetas de instancia EC2, restaurar instancias de base de datos de RDS, restaurar sistemas de archivos EFS completos, así como archivos y directorios EFS, configuraciones completas y elementos específicos de configuraciones de VPC. •La solución de poder realizar las siguientes operaciones: crear copias de seguridad a nivel de imagen e instantáneas nativas de la nube de máquinas virtuales de Azure, crear copias de seguridad a nivel de imagen de las bases de datos de Azure SQL, crear instantáneas nativas en la nube de recursos compartidos de archivos de Azure, restaurar archivos individuales de recursos compartidos de archivos de Azure, bases de datos específicas de Azure SQL, máquinas virtuales de Azure completas, discos virtuales individuales y archivos y carpetas del sistema operativo invitado. •La solución debe estar desarrollada para tareas de protección y recuperación ante desastres para entornos de Google Cloud protegiendo GCP VMs (incluyendo Hyperdisk), GCP Cloud SQL Enterprise edition, GCP Cloud SQL on PostgreSQL y GCP Cloud Spanner. •La solución de poder realizar las siguientes operaciones: crear copias de seguridad a nivel de imagen e instantáneas nativas de la nube de instancias de máquinas virtuales de Google, crear copias de seguridad a nivel de imagen e instantáneas nativas de la nube de las instancias de Google Cloud SQL, restaurar instancias de Google Cloud SQL completas, bases de datos de Google Cloud SQL específicas, instancias de máquinas virtuales de Google completas, discos persistentes individuales y archivos y carpetas del sistema operativo invitado. •La solución debe crear copias de seguridad del tenant de Microsoft Entra ID y almacenarlas en bases de datos PostgreSQL. •Crear copias de seguridad de los registros de auditoría y de inicio de sesión de Microsoft Entra ID y almacenarlas en repositorios de respaldo. •Crear copias de seguridad de políticas Microsoft Intune. •Crear copias de seguridad granulares del tenant de Entra ID permitiendo seleccionar tipos específicos de recursos a respaldar. •Crear copias secundarias de seguridad en unidades inmutables. •Restaurar usuarios, grupos, unidades administrativas, roles, aplicaciones y principales de servicio desde copias de seguridad del tenant de Microsoft Entra ID al entorno de Microsoft Entra ID. •Restaurar propiedades de usuarios, grupos, unidades administrativas, roles, aplicaciones y principales de servicio desde copias de seguridad del tenant de Microsoft Entra ID al entorno de Microsoft Entra ID. •Restaurar registros de auditoría e inicio de sesión desde copias de seguridad de registros de Microsoft Entra ID al entorno de Microsoft Entra ID. Monitoreo y Reporting de Respaldo Se requiere informes y monitoreo precisos de la infraestructura de respaldo y el estado del trabajo para garantizar que se puedan cumplir los objetivos de recuperación. •La solución debe proporcionar información del estado de protección de cargas de trabajo virtuales, físicas o basadas en nube. •La solución debe alertar sobre trabajos de respaldo fallidos y trabajos que exceden la ventana de respaldo incluyendo los Enterprise Plugins. •La solución debe alertar por adelantado si el objetivo de la copia de seguridad se acerca a la capacidad. •La solución debe ofrecer un dashboard que ofrezca una calificación del estado de seguridad de la instalación del software de backup analizando si se siguieron las mejores prácticas, si se utiliza inmutabilidad, si se cumplen con los RPO y si se han probado los backups y réplicas. •La solución debe proporcionar alertas proactivas para eliminar problemas. Estos problemas deben detectarse automáticamente, abarcar la configuración y el rendimiento, y el proveedor debe actualizar dinámicamente la detección. •La solución debe proporcionar un informe de evaluación de Infraestructura VMware para asegurar que el entorno esté preparado para las operaciones de respaldo basadas en snapshots y detectar máquinas virtuales que requieren implementación de respaldo basada en agente. •La solución debe proporcionar un informe de autoevaluación. El informe debe detectar si la solución se implementa de acuerdo con las mejores prácticas. •La solución debe proporcionar un informe sobre máquinas virtuales que no están protegidas por copia de seguridad y un informe de cumplimiento de RPO (Objetivo del punto de recuperación) para las máquinas virtuales protegidas. •La solución debe proporcionar planificación de capacidad y pronosticar la utilización del espacio de almacenamiento de respaldo. •La solución debe proporcionar un informe automatizado sobre todas las operaciones de recuperación para fines de auditoría. •La solución debe proporcionar una infraestructura de respaldo y un informe de cambios de política para fines de auditoría. •La solución debe permitir definir dashboards de monitoreo personalizados e integraciones con sistemas ITSM con la ayuda de REST APIs. •La solución debe permitir programar la entrega automática de dashboards, informes y carpetas de informes. Se debe poder optar por recibir dashboards e informes por correo electrónico, guardar dashboards e informes en una carpeta local o recurso compartido de red. •La solución debe notificar a los usuarios sobre eventos importantes, cambios y posibles problemas en el entorno virtual y de copia de respaldo. •La solución debe ser capaz de tomar acciones de remediación como por ejemplo ejecutar un script que encienda una VM, o ejecutar un script que agregue una VM a un trabajo de respaldo existente o ejecutar un script que elimine el último snapshot en VMware o que elimine el último checkpoint en Hyper-V. •La solución debe generar sus eventos en formato SYSLOG y ser capaz de enviar dichos eventos a herramientas SNMP y SIEM como SPLUNK, Crowdstrike, Palo Alto, Microsoft Sentinel, Fortinet, IBM Qradar y otros. •La solución debe proporcionar monitoreo de infraestructura de Vmware y Hyper-V incluyendo alarmas, reportes, dashboards y vistas. •La solución debe proveer asistencia basada en AI para optimizar la performance de los respaldos, atacar potenciales riesgos y tomar rápidas decisiones basadas en datos mejorando la eficiencia y reduciendo la carga de trabajo en los equipos de TI. •La interacción con la AI debe poder realizarse mediante lenguaje natural. •La AI debe proveer al menos dos modos de operación, básico mejorado y avanzado. •La AI en modo Avanzado proporcionará acceso a los detalles de la infraestructura de respaldo y a datos de monitoreo en tiempo real. •La AI en modo Avanzado, enviará un reporte diario con una vista consolidada de las actividades de respaldo, reduciendo la fatiga por alertas y optimizando las operaciones. Este informe agrega los estados de los trabajos en todo el entorno, agrupa errores idénticos para una clasificación rápida y proporciona recomendaciones de resolución basadas en contexto con enlaces directos a recursos de soporte relevantes. •La solución contará con un Agente de AI para detectar y responder a las amenazas proporcionando información en tiempo real, detalles de anomalías, alcance del impacto y las siguientes mejores acciones para los pasos de recuperación, incluyendo la activación de análisis de malware basados en firmas. •La solución contará con Agente de Análisis Profundo de Datos para crear informes personalizados de la infraestructura de respaldo. •Los reportes generados deben estar basados en HTML-5 •La solución debe proveer un constructor de reportes personalizables. •La solución debe poder integrarse a la consola del servidor de respaldos evitando que el operador deba cambiar de consolas. •La solución debe monitorear los mecanismos de cluster HA del servidor de respaldos. Se requiere que el oferente cuente con al menos dos (2) ingenieros con certificación vigente en dicha tecnología Renglón 5 – Servicios Conexos El adjudicatario deberá llevar a cabo tanto la instalación, configuración y puesta en marcha de los productos que componen este requerimiento, así como las tareas mínimas que se describen a continuación, las cuales deberán ser aprobadas por un representante técnico designado por el organismo: Tareas específicas para Renglon 1 - Nodos para Infraestructura Hiperconvergente. •Inicialización del chasis multinodo en rack, energización redundante y actualización de firmwares a la versión homologada. •Configuración de la controladora de gestión por nodo y aprovisionamiento de los arreglos locales SSD/NVMe PCIe Gen5 (U.2). •Configuración y balanceo de los 240 Cores y 2,560GB de RAM asignados globalmente a través del hipervisor. •Configuración del software de Almacenamiento Definido por Software (SDS) agrupando los discos DAS de todos los nodos. •Configuración del almacenamiento virtual distribuido con capacidad de tolerancia ante fallas de un disco o de un servidor completo. •Configuración del factor de réplica (RF2 o RF3) a nivel de datastore/container para la protección por bloques distribuidos. •Configuración de la protección distribuida del clúster con reserva de recursos para tolerancia a fallos tipo N+1. •Aplicación y endurecimiento del sistema base mediante las plantillas de seguridad STIG específicas del fabricante hiperconvergente. •Configuración del motor de cumplimiento para el escaneo diario automatizado de desviaciones de la línea base STIG. •Configuración de las tareas de remediación automática (auto-healing) para corregir configuraciones inseguras detectadas. •Puesta en marcha, simulación de falla de un nodo completo para validar la reconstrucción automática de bloques y el failover del 100% de las VMs activas. Tareas específicas para Renglon 2 - Switch Ethernet para clúster de Hiperconvergencia •Inicialización de los dos switches TOR dedicados, interconexión de fuentes y actualización de firmware de misión crítica. •Configuración del enlace cruzado de alta disponibilidad (MLAG/vPC) entre ambos switches TOR y activación de Jumbo Frames. •Configuración de los puertos SFP28 a 25Gbps para recibir los enlaces de datos y almacenamiento de cada nodo independiente. •Puesta en marcha, validación del aislamiento de tráfico del clúster y monitoreo de rendimiento de ultra baja latencia. Tareas específicas para Renglon 3 - Almacenamiento para Copias de Seguridad •Inicialización y montaje del hardware de almacenamiento dedicado para resguardo con conexión redundante a la red. •Configuración del pool de almacenamiento primario basado en los requerimientos de retención y activación de la deduplicación optimizada. •Configuración del cifrado en reposo, endurecimiento de seguridad (repositorio inmutable) y creación de los volúmenes de destino. •Puesta en marcha, pruebas de estrés de escritura concurrente y validación de tasas de reducción de datos por deduplicación. Tareas específicas para Renglon 4 - Licencias para backup con monitoreo y analítica avanzada •Inicialización del servidor de respaldo, activación y asignación de las licencias corporativas para las 250 máquinas virtuales. •Configuración de las políticas de respaldo automatizadas, ventanas de ejecución y asignación del almacenamiento optimizado como destino. •Configuración de la analítica avanzada, tableros de control predictivos y alertas automatizadas para detección de anomalías o ransomware. •Puesta en marcha, ejecución del primer respaldo completo del clúster hiperconvergente y validación de los reportes de cumplimiento El adjudicatario será responsable de la implementación de todos los bienes adquiridos. Deberá realizar el reemplazo del equipamiento actualmente en funcionamiento, realizando la instalación, configuración y puesta en marcha, la que comprende la infraestructura de red completa, junto con la solución de seguridad interna, la administración centralizada y de análisis, aplicación de licencias, entre otros, garantizando el pleno funcionamiento de toda la solución en las sedes del Organismo. El oferente deberá contar con certificación vigente en la Norma ISO/IEC 20000-1:2018 en Gestión de Servicios de TI. El oferente deberá presentar certificado ISO/IEC 27001:2022 vigente. PLAZOS DE ENTREGA DE LOS BIENES Plazo de entrega Los bienes objeto de la presente contratación deberán ser entregados dentro de los 90 (NOVENTA) días hábiles contados a partir del primer día hábil siguiente a la fecha de firma del Contrato. Todos los gastos correspondientes a flete, traslados del personal técnico, seguro, carga y descarga de herramientas y/o elementos necesarios para la entrega serán por cuenta y cargo del adjudicatario. Plazo de recepción provisoria La recepción provisoria se llevará a cabo dentro de los 90 (NOVENTA) días hábiles posteriores a la entrega de los bienes en el lugar indicado por el Ministerio de Justicia, previa verificación de cantidades y estado general de los equipos. Plazo de recepción definitiva: La recepción definitiva se efectuará dentro de los 120 (CIENTO VEINTE) días hábiles contados desde la recepción provisoria, una vez realizada la configuración e implementación y comprobado el correcto funcionamiento de los bienes, la integración con la infraestructura existente y el cumplimiento de las especificaciones técnicas establecidas en el pliego. Responsable de recepción de los bienes: Gabriel Villalba (gvillalba@jus.gob.ar) Responsable de confirmación de funcionalidad de los bienes o validación de la prestación del servicio: Gabriel Villalba (gvillalba@jus.gob.ar). 1. Planos o diseños. Este documento de licitación “no incluye” planos y diseños 4.Inspecciones y Pruebas No se prevén inspecciones ni pruebas adicionales a las verificaciones físicas y funcionales previstas en la recepción provisoria y definitiva de los bienes y servicios relacionados.

e. 07/09/2026 N° 63960/26 v. 07/09/2026