Esta sección constituye el detalle de los bienes y/o servicios con sus respectivas especificaciones técnicas - EETT, de manera clara y precisa para que el oferente elabore su oferta. Salvo aquellas EETT de productos ya determinados por plantillas aprobadas por la DNCP.
El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes y servicios serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.
Los bienes y servicios suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.
El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.
En este apartado la convocante deberá indicar los siguientes datos:
Identificar el nombre, cargo y la dependencia de la Institución de quien solicita el llamado a ser publicado.
Lic. Gustavo López, director, Dirección de Sistema Informático.
Justificar la necesidad que se pretende satisfacer mediante la contratación a ser realizada.
A fin garantizar un óptimo rendimiento de la red durante picos de demanda, así como, minimizar los tiempos de respuesta y mejora la experiencia del usuario al dirigir las solicitudes al servidor más adecuado en función de factores como la carga actual, la ubicación del usuario y el tipo de solicitud, convirtiéndose en una herramienta muy valiosa para asegurar el buen funcionamiento del Sistema Ambiental (SIAM) del MADES
Justificar la planificación (si se trata de un llamado periódico o sucesivo, o si el mismo responde a una necesidad temporal)
Dado que la adquisición de los balanceadores de carga representa una solución definitiva para la problemática actual, la planificación de esta contratación se ha diseñado como un proceso único y puntual.
Justificar las especificaciones técnicas establecidas.
Se establecieron especificaciones técnicas que, sin restringir la competencia, garantizan la obtención de una solución óptima que cumpla con los requisitos del proyecto.
Los productos y/o servicios a ser requeridos cuentan con las siguientes especificaciones técnicas:
ESPECIFICACIONES TÉCNICAS
Los servicios críticos Ministerio del Ambiente y Desarrollo Sostenible (MADES) funcionan sobre infraestructura de red y seguridad de nivel enterprise el cual abarca varias capas de la infraestructura TI de la entidad. Con el objetivo de continuar el fortalecimiento de la arquitectura de seguridad, la entidad requiere la implementación de una solución que brinde protección a las aplicaciones y además proporcione balanceo inteligente y optimización de tráfico.
En este marco, el MADES busca la implementación de equipos que sean de línea Enterprise con funcionalidades que puedan cubrir las necesidades actuales y futuras de la entidad.
| Solución de Balanceo de Carga y Protección de aplicaciones | |||
| Marca | Especificar | ||
| Modelo | Especificar | ||
| Nro. de parte del fabricante del equipo | Especificar | ||
| Procedencia | Especificar | ||
| Cantidad | 2 (DOS) | Especificar | |
| Requisitos | CARACTERISTICAS | Mínimo exigido | Cumple / NO Cumple |
|
CARACTERÍSTICAS DEL EQUIPO |
Factor forma virtual o appliance. En caso de ser virtual, el oferente deberá incluir los recursos de hardware y software necesarios para el correcto funcionamiento y puesta en marcha de la solución ofertada. | Exigido | |
| Ancho de banda licenciado: | 200 Mbps | ||
| Todos los componentes de la solución (software, hardware y licencias) deberán contar con una garantía y vigencia de 24 meses. | Exigido | ||
| Los equipos deben tener la característica de soportar alta disponibilidad, Modo Activo/Activo y/o Activo/Pasivo, es decir, tener la capacidad de conectarse a una unidad similar y operar en modo activo y la otra unidad en modo pasivo (fail-over) y deberá contar con la capacidad de direccionamiento virtual. La Solución debe tener la capacidad de recuperar las sesiones del sistema en forma inmediata y automática, en caso de fallo de un adaptador, cable de red, canal de controladora o alimentación de fluido eléctrico. | Exigido | ||
| Debe soportar cluster Activo/Activo entre dos o más plataformas, soportando diferentes modelos de hardware (no solamente del mismo modelo). | Exigido | ||
| Debe contar con plantillas estándares de implementación rápida para aplicaciones | Exigido | ||
| CARACTERÍSTICAS DEL HARDWARE | La solución deberá ser rackeable en racks estándar de 19'', se deberán incluir todos los accesorios para la correcta instalación del equipo. | ||
| Memoria RAM | ≥ 32 GB | ||
| CPU | ≥ 4 Cores | ||
| Capacidad de Disco de estado sólido | ≥ 600 GB | ||
| Arreglo de Disco | Raid 1 | ||
| Al menos 4 puertos SFP+/SFP28, con opción de conectividad de 10 Gbps | Exigido | ||
| Al menos 2 módulos SFP+ 10GE multimodo | Exigido | ||
| Fuente redundante | Exigido | ||
| Deberá contar con todos los accesorios para el montaje en Rack, como así también todos los cables para conexiones eléctricas y de datos. | Exigido | ||
| THROUGHPUT MÍNIMO |
Cada equipo debe cumplir con las siguientes características:
|
Exigido | |
| GENERALES | La solución debe permitir configurar cluster entre más de dos equipos y permitir que sean plataformas no necesariamente idénticas (como equipos appliance físico, chasis o virtuales) con el fin de contar con un sistema a futuro altamente escalable y en demanda | Exigido | |
| Para mejorar el rendimiento de la sincronización de configuración deberá poder sincronizar la configuración de manera incremental. | Exigido | ||
| Ante la necesidad de conmutar el tráfico a otros dispositivos del grupo, el sistema deberá poder realizar cálculos para determinar el mejor dispositivo basado en: recursos, capacidad, carga de tráfico en cada dispositivo. Identificando la mejor opción cuando el ambiente sea heterogéneo en cuanto se refiere a plataformas. | Exigido | ||
| La configuración será sincronizada entre todos los dispositivos del grupo pudiendo escoger si la sincronización se realiza de manera automática o manual. | Exigido | ||
| Los equipos deben tener hardware acelerador FPGA personalizables y programables para varias funciones como protección DDoS, protocolos SDN y manejo de tráfico UDP | Exigido | ||
| FUNCIONES DE ADMINISTRACIÓN DE TRÁFICO | La solución debe realizar funciones de balanceo de tráfico a aplicaciones basadas en TCP/UDP, incluidos servicios web. | Exigido | |
| La solución debe permitir la definición de dirección IP y puerto virtual para la prestación de un servicio, que permita atenderlo mediante una granja de servidores identificados mediante una dirección IP y un puerto del servicio igual o diferente del presentado al público | Exigido | ||
| La solución debe tener arquitectura Full-Proxy, control de entrada y salida de conexiones distinguiendo conexiones del lado del cliente y del lado del servidor o los recursos | Exigido | ||
| La solución ofertada debe ser capaz de soportar balanceo amortiguado de los servidores que se agreguen nuevos, para prevenir la saturación de conexiones. De manera que servidores que se agregan al grupo de balanceo, reciban al inicio menos cantidad de peticiones por un tiempo determinado, hasta ser capaz de recibir la misma cantidad de peticiones que los que ya estaban en el grupo. | Exigido | ||
| Deberá permitir hacer persistencia de conexiones hacia la aplicación con base en cualquier información contenida en cualquier parte del paquete completo, esto para poder adaptar la solución a las necesidades de las diferentes aplicaciones | Exigido | ||
|
La solución debe permitir hacer control de balanceo de tráfico según se defina entre uno o varios tipos de algoritmos especializados de balanceo. Estos métodos deben realizarse de manera nativa y no por medio de configuración por scripting:
|
Exigido | ||
| Debe permitir balancear a una granja de servidores y seleccionar el destino basado en la carga de estos, como memoria/RAM | Exigido | ||
| El equipo debe no tener restricciones en el número de servicios virtuales que se pueden configurar (Virtual Servers, Virtual IP, granjas) | Exigido | ||
| El sistema debe ser capaz de identificar fallos en servicios para redundancia de las aplicaciones. | Exigido | ||
| La solución debe tener reglas que permitan el control de ancho de banda de manera dinámica | Exigido | ||
|
La solución debe realizar monitoreo de la salud de los Servidores que gestione el equipo de Balanceo de tráfico, por medio de:
|
Exigido | ||
|
Debe poder realizar todos estos métodos de persistencia de las conexiones:
|
Exigido | ||
| Debe Permitir crear persistencia por cualquier valor del paquete por medio de reglas. | Exigido | ||
| Debe garantizar afinidad del servidor, de tal forma que una solicitud de un cliente y cada solicitud posterior se dirijan al mismo servidor de la granja. | Exigido | ||
| El sistema debe ser capar de realizar un método secundario de persistencia, en caso de que el primer método no pueda ejecutarse por factores externos a la plataforma. | Exigido | ||
|
Soporte de API para construir aplicaciones de administración o monitoreo personalizadas:
|
Exigido | ||
| Soporte de REST API | Exigido | ||
| Deberá ser posible modificar el contenido HTML utilizando objetos de configuración y sin necesidad de generar scripts. | Exigido | ||
| Debe soportar el protocolo TDS para balanceo de MSSQL | Exigido | ||
| Debe soportar el protocolo MQTT para administración de tráfico desde dispositivos IoT. Debe permitir identificar mensajes dentro del protocolo MQTT, proveer estadísticas y exponer API para acceder a la información de los mensajes MQTT | Exigido | ||
| Debe soportar el protocolo NetFlow (v5) | Exigido | ||
| El sistema deberá soportar scripts de programación basados en un lenguaje estructurado (TCL) que permita crear funcionalidades que por defecto no se encuentren en el menú de configuración u opciones y debe soportar la creación de Procedimientos o funciones que pueden ser utilizadas desde cualquier otro script. | Exigido | ||
| La solución debe permitir configuración de scripts basados en Node.js con el fin de brindar además del TCL, el acceso a paquetes de npm para facilitar la escritura y el mantenimiento del código | Exigido | ||
| El equipo debe ser compatible con tráfico IPSEC y ser certificado por ICSA Labs como dispositivo IPSEC 1.3 | Exigido | ||
| Debe soportar e incluir Geolocalización, de manera que pueda tomar decisiones basado en una base de datos de continentes, países y de direcciones IP. | Exigido | ||
| La Base de datos de geolocalización debe incluir los países de América Latina y estar disponible en el mismo equipo sin necesidad de acceso a Internet (offline). | Exigido | ||
| FUNCIONES DE SEGURIDAD |
Cada equipo debe soportar seguridad SSL con las siguientes características:
|
Exigido | |
| La solución debe soportar mirroring de sesiones SSL. Sin el equipo primario falla el equipo secundario debe mantener la sesión SSL | Exigido | ||
|
El Stack TLS del equipo debe soportar las siguientes funcionalidades/características:
|
Exigido | ||
| La solución debe manejar AES, AES-GCM, SHA1/MD5 y soporte a algoritmos de llave pública: RSA, Diffie-Hellman, Digital Signature Algorithm (DSA) y Elliptic Curve Cryptography (ECC) | Exigido | ||
| Debe soportar algoritmos de cifrado Camellia | Exigido | ||
| El equipo o sistema operativo debe estar certificado por ICSA Labs como Firewall de Red (Corporate Firewall) | Exigido | ||
| El equipo o sistema operativo debe estar certificado por ICSA Labs como Web Application Firewall | Exigido | ||
| Cada equipo debe contar con Protección SYN Cookies contra ataques de SYN flood. Esta funcionalidad deberá ser realizada por Hardware específico para la función y soportar 80.000.000 de SYN cookies por segundo | Exigido | ||
| Firmado criptográfico de cookies para verificar su integridad. | Exigido | ||
| Capacidad de integración con dispositivos HSM externos. Deberá soportar al menos Thales nShield Y Safenet (Gemalto) Luna. | Exigido | ||
| La solución debe permitir la funcionalidad Proxy SSL, esta funcionalidad permite que sesión SSL se establezca directamente entre el usuario y el servidor final, sin embargo, el equipo balanceador debe ser capaz de desencriptar, optimizar y reencriptar el tráfico SSL sin que el balanceador termine la sesión SSL. | Exigido | ||
| Se requiere que soporte la extensión STARTTLS para el protocolo SMTP de manera de poder cambiar una conexión en texto plano a una conexión encriptada sin necesidad de cambiar el puerto. | Exigido | ||
| Debe soportar HSTS (HTTP Strict Transport Security) | Exigido | ||
|
Debe soportar por medio de agregación de subscripción a futuro, un sistema de reputación IP para prevenir conexiones bidireccionales (entrantes y salientes) a direcciones IP no confiables y agrupadas en categorías:
|
Exigido | ||
| FUNCIONES DE ACELERACIÓN DE TRÁFICO |
La implementación de la solución debe incluir la capacidad de hacer aceleración de aplicación a nivel de:
|
Exigido | |
| El sistema deberá permitir comprimir tráfico http a través del estándar GZIP y compatible con browsers como MS Internet Explorer, Google Chrome, Mozilla Firefox, Safari, etc. | Exigido | ||
| Cada equipo debe contar con una capacidad de compresión de tráfico a una tasa de 40 Gbps o superior. Pudiendo crecer via licenciamiento. | Exigido | ||
| Debe soportar el protocolo HTTP2 y funcionar como Gateway para este protocolo. | Exigido | ||
| Permitir la modificación de los tags de cache para cada objeto del sitio web de manera independiente, pudiendo respetar los tags generados por el Web server o modificarlos | Exigido | ||
| Debe soportar Adaptive Forward Error Correction a nivel TCP y UDP | Exigido | ||
| BALANCEO A NIVEL GLOBAL | La solución debe soportar el permitir alta disponibilidad de aplicaciones distribuidas en 2 o más datacenters, sin importar la ubicación geográfica. | Exigido | |
| Debe funcionar como un servidor DNS autoritativo de alto desempeño, permitiendo manejar un dominio completo o delegación de parte de un dominio. Debe ser autónomo sin necesidad de balancear requerimientos DNS a una granja de servidores DNS. | Exigido | ||
| Debe funcionar como un servidor DNS cache autónomo, sin necesidad de balancear requerimientos DNS a una granja de servidores. | Exigido | ||
|
Para el balanceo global (DNS), debe permitir los siguientes métodos de balanceo estático y dinámico, de manera nativa y no a través de configuración por scripting:
|
Exigido | ||
| Debe manejar persistencia a nivel global, manteniendo a los usuarios en un mismo datacenter por el transcurso de su sesión. | Exigido | ||
| Permitir Balanceo de cargas ente datacenters de acuerdo a la ubicación geográfica | Exigido | ||
| Debe permitir la creación de topologías personalizadas con el fin de permitir distribución de tráfico basado en requerimientos particulares de la infraestructura | Exigido | ||
| Debe permitir monitoreo de la infraestructura y las aplicaciones a balancear, integrándose con otros equipos del mismo fabricante o de terceros. | Exigido | ||
| Las zonas del DNS Autoritativo deben cargarse en RAM, para evitar latencias y tener tiempos de respuesta rápidos. | Exigido | ||
| Debe permitir realizar balanceo de servidores DNS. | Exigido | ||
| Debe soportar el protocolo DNSSEC | Exigido | ||
| Debe incluir herramienta de administración grafica para el manejo de zonas DNS | Exigido | ||
| Debe soportar registros AAAA para IPv6 | Exigido | ||
| Debe soportar traducción entre DNS IPv4 y DNS IPv6 | Exigido | ||
| FUNCIONES DE FIREWALL Y PROTECCION DDOS | Debe incluir protección contra ataques de DDoS en capas 2-4 utilizando vectores de ataque personalizables | Exigido | |
| La solución de DDoS debe contar con un sistema de protección basado en comportamiento (Behavioral) que permita la creación de firmas o vectores de ataque de manera dinámica. | Exigido | ||
| La solución debe proteger contra ataques de denegación de servicio tanto en una topología en línea (inline deployment) como en una topología fuera de línea (TAP mode) | Exigido | ||
| Debe bloquear ataques a nivel de red como flood, sweep, teardrop, smurf attacks | Exigido | ||
| Debe mitigar ataques basados en protocolos, incluyendo SYN, ICMP, ACK, UDP, TCP, IP, DNS, ICMP, ARP | Exigido | ||
| Debe permitir la creación de reglas basadas en aplicación, independientes para cada una de ellas. | Exigido | ||
| Debe permitir la creación de reglas globales | Exigido | ||
| Debe tener la opción de funcionar como un firewall statefull full-proxy y ser certificado por ICSA Labs como Network Firewall | Exigido | ||
|
Debe permitir la definición de horarios (schedules) que apliquen a las reglas configuradas, permitiendo activar regla:
|
Exigido | ||
| Debe permitir la creación de listas blancas (White lists) de direcciones IP | Exigido | ||
| Debe permitir la configuración de túnel IPSEC Site-to-Site | Exigido | ||
| Debe incluir funcionalidad de application delivery controller o integrarse con dispositivos de Application Delivery | Exigido | ||
| Debe brindar protección contra Ataques de Denegación de Servicio para el protocolo DNS, poder controlar el tráfico DNS de acuerdo al tipo de Registro solicitado y detectar anomalías a nivel del protocolo | Exigido | ||
| Debe brindar protección contra Ataques de Denegación de Servicio para el protocolo SIP y poder controlar el tráfico SIP de acuerdo al Método SIP recibido y detectar anomalías a nivel del protocolo | Exigido | ||
| Debe permitir personalizar los Logs, y ser exportados a un repositorio Syslog externo que conste de uno o varios servidores. | Exigido | ||
| Debe funcionar como un Proxy SSH para control de conexiones entre diferentes redes con el fin de dar visibilidad a las sesiones SSH y controlar las mismas | Exigido | ||
| Debe soportar Port Misuse, evitando que servicios pasando a través de puertos conocidos que buscan saltar protecciones de Firewall (por ejemplo, un servicio SSH escuchando en el puerto 80 y busque abusar de reglas orientadas a HTTP). | Exigido | ||
| Debe soportar RTBH (Remotely Triggered Black-hole Route Injection) para protección en caso de implementaciones fuera de línea. | Exigido | ||
| FIREWALL DE APLICACIONES WEB (WAF) | La solución debe incluir funcionalidad de Firewall de Aplicaciones (WAF) en la misma caja, no debe ser un appliance independiente (para optimización de latencias, administración, espacio en rack, energía eléctrica, soportes de fabricante). | Exigido | |
| La funcionalidad de WAF debe permitir la personalización de la política, de manera que se pueda ajustar finamente de acuerdo al servicio específico que estará protegiendo, sus URLs, parámetros, métodos, de manera específica. | Exigido | ||
| Debe trabajar en un esquema proxy TCP reverso y/o transparente | Exigido | ||
| El WAF debe poder construir automáticamente políticas basadas en el tráfico detectado | Exigido | ||
| Debe trabajar con políticas de seguridad por capas, donde se configura una política de seguridad base y las políticas de seguridad hijas heredan sus configuraciones y permita que solo cambios específicos se apliquen a las políticas hijas. | Exigido | ||
| La creación automática de políticas deberá unificar múltiples URLs explicitas utilizando wildcards de manera de reducir la cantidad de objetos en la configuración. | Exigido | ||
| Debe trabajar en modo de bloqueo o en modo informativo | Exigido | ||
| Debe permitir diferentes políticas de seguridad para diferentes aplicaciones | Exigido | ||
| WAF debe tener la capacidad de importar archivos de diccionario OpenAPI 3.0 (Swagger) para crear una política de protección de API automáticamente ajustada a su contenido. (Métodos, URL, Variables, etc) | Exigido | ||
| El WAF debe tener la capacidad de realizar la firma antes de la implementación final. Durante el período de estadificación, los eventos falsos positivos se pueden administrar y ajustar para que coincidan con los datos de la aplicación del mundo real | Exigido | ||
| El WAF debe tener la capacidad de retroceder a otro host en caso de que la aplicación protegida no esté disponible o devuelva códigos de error HTTP | Exigido | ||
| El WAF debe tener la capacidad de multiplexación de nivel TCP para reducir la cantidad de conexiones L4 a servidores backend | Exigido | ||
| WAF debería filtrar los DDoS de nivel de aplicación antes de procesar sus políticas HTTP. La protección DDoS debe medir el estrés de la aplicación para una detección precisa | Exigido | ||
| WAF debe tener la capacidad de crear scripts de plano de datos (evento de tráfico) y plano de control (evento de gestión) para manejar eventos únicos que suceden en el entorno. | Exigido | ||
| El WAF debe tener la capacidad de detectar automáticamente el software utilizado en el backend para definir los conjuntos de firmas necesarios para la política WAF definida | Exigido | ||
| Cada tipo de violación de WAF debe tener una configuración para activar la acción de Registro, Alarma o Bloquear o cualquier combinación de ellos. | Exigido | ||
| Para el modo de aprendizaje automático, las sugerencias deben aceptarse automáticamente en función de la probabilidad | Exigido | ||
| El WAF debería tener soporte para el descifrado TLS 1.3. | Exigido | ||
| El WAF debe tener la capacidad de agregar cookies para la persistencia del equilibrio de carga. | Exigido | ||
| El WAF debe tener la capacidad de devolver el tráfico en modo proxy inverso a su puerto de origen y dirección MAC incluso si no se especifica una entrada de enrutamiento. | Exigido | ||
| WAF debe tener contextos administrativos con su propia configuración y diferentes usuarios permitidos para administrar estos contextos. De modo que varios grupos de administradores pueden trabajar con un sistema sin influencia en la configuración de los demás. | Exigido | ||
| Debe permitir la creación de firmas personalizadas | Exigido | ||
| Debe trabajar con modelos de seguridad positiva y negativa | Exigido | ||
| La solución debe tener la posibilidad de automatizar la creación de políticas de WAF desde los pipelines de desarrollo, a través de esquemas basados en modelos declarativos (archivos con sintaxis json). Esto podría hacerse desde herramientas como Jenkins, GitLab, postman, curl, ansible, terraform, cuya política de seguridad, se encuentre bajo dicho formato se mantenga en un repositorio u origen confiable privado, o público (GitHub, por ejemplo) | Exigido | ||
| El WAF debe entregar una puntuación de riesgo de la violación recibida | Exigido | ||
| Debe tener la capacidad de crear, modificar y eliminar políticas de WAF mediante API Rest. | Exigido | ||
| Debe poder aprender el comportamiento de la aplicación automáticamente sin intervención humana | Exigido | ||
| El WAF debe poder admitir la aplicación de políticas de seguridad para aplicaciones escritas en Google Web Toolkit (GWT) | Exigido | ||
| El WAF debe permitir personalizar las páginas de bloqueo incluyendo la capacidad de responder a webservices mediante un código HTTP 500 o responder con payloads JSON | Exigido | ||
| El WAF debe permitir personalizar las páginas de bloqueo | Exigido | ||
|
El WAF debe admitir las siguientes técnicas de detección evasiva:
|
Exigido | ||
| El WAF debe proporcionar seguimiento de sesión con capacidades mejoradas de generación de informes y cumplimiento que toman en cuenta las sesiones de usuario HTTP y los nombres de usuario dentro de la aplicación. Esto le brinda al administrador más información sobre actividades sospechosas de la aplicación (por ejemplo, quién fue el usuario detrás de un ataque) y más flexibilidad para aplicar la política de seguridad (como impedir que un determinado usuario use la aplicación). Se puede configurar si el sistema realiza un seguimiento de las sesiones según el nombre de usuario, la dirección IP o el número de identificación de la sesión. | Exigido | ||
| Debe prevenir exponer el OS fingerprinting | Exigido | ||
| Debe permitir la integración con Herramientas de verificación de vulnerabilidades, en particular WhiteHat, Cenzic, Qualys, IBM AppScan, HP WebInspect. | Exigido | ||
|
El WAF Debe soportar:
|
Exigido | ||
| El WAF Debe incluir protección a Web Services XML y restringir el acceso a métodos definidos vía Web Services Description Language (WSDL) | Exigido | ||
| El WAF debe incluir protección contra el Top 10 de ataques definidos en OWASP, y presentar un dashboard de cumplimiento para cada una de las políticas creadas en la solución. | Exigido | ||
| El WAF debe incluir protección contra Web Scraping | Exigido | ||
| Debe ser Session-aware es decir identificar y forzar que el usuario tenga una sesión e identificar los ataques por usuario | Exigido | ||
| Permitir la definición y detección de las condiciones a cumplir para que una aplicación externa que vía Java realiza un requerimiento cross-domain, permitiendo evitar un CORS (Cross-Origin Resource Sharing). | Exigido | ||
| Debe permitir verificar las firmas de ataque en las respuestas del servidor al usuario | Exigido | ||
| Debe permitir el enmascaramiento de información sensible filtrada por el servidor | Exigido | ||
| Debe poder bloquear basado en la ubicación geográfica e incluir la base de datos de geolocalización. | Exigido | ||
| Debe permitir la integración con servidores Antivirus por medio del protocolo ICAP | Exigido | ||
| Debe brindar reportes respecto a la normativa PCI DSS 2.0 | Exigido | ||
|
Debe integrarse con Firewall de Base de Datos:
|
Exigido | ||
| Debe proteger contra ataque DoS /DDoS de Capa 7 | Exigido | ||
| Una vez detectado un ataque deberá ser posible descartar todos los paquetes que provengan de una dirección IP sospechosa | Exigido | ||
| En caso de detectarse un ataque se requiere tener la posibilidad de iniciar una captura de tráfico (tipo tcpdump) para poseer información forense. | Exigido | ||
| Debe soportar tecnologías AJAX y JSON | Exigido | ||
|
Debe proteger como mínimo:
|
Exigido | ||
| Debe poder identificar y configurar URLs que generen un gran consumo de recursos en los servidores como método de protección de ataques de denegación de servicios. | Exigido | ||
| Debe permitir verificaciones de seguridad y validación a protocolos FTP y SMTP | Exigido | ||
| Debe permitir comparar dos políticas de seguridad y mostrar las diferencias entre ambas | Exigido | ||
| Debe incluir firmas de BOTS para detectar y bloquear tráfico originado por estos. | Exigido | ||
| Debe soportar CAPTCHA como método de prevención para mitigar ataques de denegación hacia las aplicaciones protegidas. | Exigido | ||
| Debe ofrecer protección sobre tráfico basado en WebSockets | Exigido | ||
| El WAF debe identificar de manera única a los usuarios por medio de Fingerprint del navegador (Browser Fingerprint) y haciendo tracking del dispositivo. | Exigido | ||
| Debe proteger las aplicaciones contra ataques de denegación de servicio a nivel L7 | Exigido | ||
| El WAF debe poder perfilar dinámicamente el tráfico y crear firmas de patrones de tráfico anómalos, deteniendo los ataques DoS de la capa 7 antes de que afecten a su aplicación, incluidos los ataques "Día Cero". | Exigido | ||
| EL WAF debe permitir utilizar protección avanzada de credenciales en formularios de la aplicación web, haciendo cifrado de la data entrada en formularios. Este cifrado se debe realizar usando un esquema de llave publica/privada. Este cifrado debe ser en tiempo real y no requerir modificaciones en la aplicación del lado del servidor o de la instalación de agentes en el servidor. | Exigido | ||
| Deberá de contar con una protección automática contra ataques DDoS, que analice el comportamiento de tráfico, usando técnicas como "Machine learning" y el análisis de datos | Exigido | ||
| EL WAF debe realizar ofuscación de contenido HTTP, en particular de los nombres de cualquier parámetro dentro de la aplicación. Esta ofuscación de parámetros debe realizarse constantemente y los parámetros deben cambiar de nombre varias veces por minuto para evitar que estos parámetros sean objeto de ataques dirigidos. | Exigido | ||
| Deberá de monitorear constantemente la salud del servicio y su carga de trabajo, con el objetivo de validar las condiciones del servidor protegido, ataques y mitigaciones. | Exigido | ||
| El WAF debe prevenir contra keyloggers sobre el browser, evitando revelar los datos escritos sobre parámetros de la aplicación Web, bien sea cifrándolos o inyectando contenido basura en estos parámetros. | Exigido | ||
|
La protección con base a comportamiento de tráfico deberá de trabajar de la siguiente manera:
|
Exigido | ||
|
El WAF ebe soportar por medio de agregación de subscripción a futuro, un sistema de reputación IP para prevenir conexiones bidireccionales (entrantes y salientes) a direcciones IP no confiables y agrupadas en categorías:
|
Exigido | ||
|
Deberá de contar con los siguientes métodos de mitigación:
|
Exigido | ||
| El WAF debe soportar WebHook notifications, notificando a servicios de Continuous Integrations / Continuous Delivery (CI/CD) cuando hay cambios en la política o Eventos de Seguridad | Exigido | ||
|
Soporte y Protección ante ataques a GraphQL:
|
Exigido | ||
| El WAF deberá contar con la posibilidad de mitigar ataques generados por BOTNETS o por Bots los cuales intentan suplantar el comportamiento de los usuarios, así mismo este deberá proveer la detección y el bloqueo de amenazas automatizadas a nivel de sesión. | Exigido | ||
| Soporte de API´s declarativa con capacidad de: Autenticación Básica de referencias externas Utilizar referencias externas para plantillas base, Exportar políticas en formato declarativo JSON | Exigido | ||
| El WAF debe tener un mecanismo de reversión de políticas | Exigido | ||
| El WAF debe ser extensible con una licencia complementaria para proporcionar la autenticación de API y admitir oAuth 2.0, permitiendo la importación de archivos swagger para la construcción de la política de protección (ya sea para las funcionalidades de autenticación, autorización de acceso, como también para la construcción de la política de WAF) | Exigido | ||
| Debe tener la capacidad de exportar e importar las políticas de WAF en formato XML y JSON. | Exigido | ||
| El WAF debe poder proporcionar listas blancas de direcciones IP unificadas para las direcciones IP de confianza de Policy Builder y listas blancas de anomalías (Prevención de ataques DoS, Prevención de ataques de fuerza bruta y Detección de web scraping) en una sola lista. | Exigido | ||
| La funcionalidad de protección contra ataques DDoS para aplicaciones debe incluir protección basada en comportamientos (Behavioral) | Exigido | ||
| FUNCIONES DE SEGURIDAD DE ACCESO | El equipo debe soportar la implementación de VPN SSL | Exigido | |
| Entre los métodos soportados deben incluir un modo "Portal" donde la máquina se comporte como un proxy reverso, buscando los contenidos de portales web internos y presentarlos como vínculos seguros en el portal del usuario | Exigido | ||
| Entre los métodos soportados deben incluir un modo de "Network", donde un usuario se conecta a la red interna obteniendo una dirección IP enrutable dentro de la red interna | Exigido | ||
| Proporcionar un acceso remoto seguro a toda la red para cualquier aplicación basada en IP (TCP o UDP) | Exigido | ||
| Soporte de Split Tunnel, solo el tráfico especificado debe ir por VPN | Exigido | ||
| Soportar túneles de aplicación, donde únicamente una aplicación en particular tenga acceso a los recursos de red | Exigido | ||
| Soporte de compresión HTTP. | Exigido | ||
| Permitir establecimiento de una conexión segura para el acceso remoto sin la necesidad de instalar software de cliente en la máquina del usuario | Exigido | ||
| Permitir un transporte seguro utilizando encapsulamiento DTLS (Datagramas TLS) | Exigido | ||
| Posibilidad de personalizar la página de acceso de usuario, portal, y mensajes de pre-inicio de sesión presentados al usuario | Exigido | ||
| Incluir licencias para mínimo 500 usuarios simultáneos VPN SSL | Exigido | ||
| El equipo suministrado debe soportar un crecimiento de al menos 20000 usuarios concurrentes VPN SSL, que se pueden habilitan por medio de licencias adquiridas a futuro | Exigido | ||
| El equipo debe tener soporte para Single-Sign-On (SSO) | Exigido | ||
| El equipo deberá ser capaz de solicitar las credenciales de usuario sólo una vez, y autenticar al usuario en todos los portales que requieran autenticación por medio de las mismas credenciales. | Exigido | ||
| El equipo debe ser capaz de almacenar en caché todas las credenciales del usuario y utilizar las credenciales adecuadas en cada portal (por ejemplo, algunos portales requieren correo electrónico como nombre de usuario, otros requieren el usuario de Dominio/ AD). | Exigido | ||
|
La solución es incluir soporte para la validación de la estación del usuario. Debe validar por lo menos:
|
Exigido | ||
| Para cada elemento de la validación de la estación del usuario, debe ser posible configurar una acción a tomar si la prueba es satisfactoria o no. | Exigido | ||
| La configuración de estas acciones debe ser a través de una interfaz gráfica y fácil de gestionar. | Exigido | ||
| El sistema debe ser capaz de verificar la ubicación geográfica de las direcciones IP, lo que permite la creación de reglas de acceso en función del país o del estado | Exigido | ||
| La solución debe ser capaz de autenticar a los usuarios contra sistemas LDAP, LDAPS, RADIUS, TACACS+, Directorio Activo, HTTP, RSA, OCSP, CRLDP | Exigido | ||
| La solución debe soportar limpieza de cache del lado del cliente final | Exigido | ||
| La solución debe permitir la creación de un Entorno Protegido para los usuarios donde no se permita la creación de archivos fuera del entorno. | Exigido | ||
| La solución debe ser compatible con múltiples factores de autenticación que utiliza tokens de hardware | Exigido | ||
| La solución debe soportar el uso de un cliente stand-alone incluido con la solución | Exigido | ||
| El cliente stand-alone debe ser capaz de hacer Roaming inteligente, donde el cambio de dirección IP no implica re-autenticación manual del usuario sin importar el tipo de enlace utilizado. (Punto de Acceso WiFi, 3G, etc.) | Exigido | ||
| El cliente stand-alone debe soportar Windows, Linux, MAC OS, iOS, Android | Exigido | ||
| Debe soportar Single-Sign-On utilizando Security Assertion Markup Language (SAML) 2.0 funcionando como identity provider (IdP) y/o service provider (SP). | Exigido | ||
| La solución debe integrarse con Oracle Access Manager | Exigido | ||
| La solución debe integrarse con VMware Horizon y funcionar como proxy PCOIP | Exigido | ||
| La solución debe integrarse con sistemas MDM para control de acceso a servicios internos | Exigido | ||
| La solución debe integrarse con Citrix XenApp y Citrix XenDesktop y funcionar como proxy ICA | Exigido | ||
| La solución debe soportar Smartcard Single Sign-On (SSO) para entornos VDI con VMware Horizon | Exigido | ||
| Debe soportar integración con escritorios virtuales Windows y Linux usando el protocol VMware Blast Extreme | Exigido | ||
| La solución debe autorizar el acceso a aplicaciones integrando el protocolo OAuth v2.0 | Exigido | ||
| La solución debe soportar Step-up Authentication para validar a los usuarios con un segundo factor de autenticación solamente al acceder recursos sensibles que necesitan mayores privilegios. | Exigido | ||
|
Mediante una suscripción adicional, la solución deberá ser capaz a futuro de agregar sobre la misma solución (sin necesidad de agregar software/hardware adicional) funcionalidades de Filtrado de Contenido Web con al menos las siguientes características:
|
Exigido | ||
| ESTÁNDARES DE RED | Soporte VLAN 802.1q, Vlan tagging | Exigido | |
| Soporte de 802.3ad para definición de múltiples troncales | Exigido | ||
| Soporte de NAT, SNAT | Exigido | ||
| Soporte de IPv6: El equipo debe funcionar como Gateway entre redes IPv6 e IPv4 permitiendo tener ambos tipos de redes simultáneamente. | Exigido | ||
| Soporte de Rate Shapping | Exigido | ||
| Soporte de dominios de Enrutamiento, donde cada uno pueda tener su propio Default Gateway y estar conectados a redes IP con el mismo direccionamiento. | Exigido | ||
| Debe soportar VXLAN, VXLAN Gateway, NVGRE y Transparent Ethernet Bridging para entornos de redes virtualizadas. | Exigido | ||
| Debe soportar el protocol de OVSDB (Open vSwitch Database) para crear tuneles VXLAN usando un controlador SDN | Exigido | ||
| Debe soportar protocolos de enrutamiento BGP, RIP, OSPF, IS-IS | Exigido | ||
| ADMINISTRACIÓN DEL SISTEMA | La solución debe permitir el acceso para la administración del equipo appliance vía CLI (Interfaz de línea de comandos) por SSH, interfaz de administración gráfica basada en Web seguro (HTTPS) | Exigido | |
| La solución debe integrarse con Directorio Activo Windows 2003 o superior, para la autenticación de usuarios para gestión de la herramienta. | Exigido | ||
| La solución debe integrarse con LDAP, para la autenticación de usuarios para gestión de la herramienta. | Exigido | ||
| La solución debe integrarse con RADIUS y TACACS+ para la autenticación de usuarios para gestión de la herramienta. | Exigido | ||
| La solución debe incluir comunicación cifrada y permitir la autenticación del equipo y de los usuarios administradores/supervisores con Certificados Digitales | Exigido | ||
|
La solución debe soportar el envío de alertas y eventos a un Sistema Centralizado mediante:
|
Exigido | ||
| El sistema de administración debe ser totalmente independiente del sistema de procesamiento de tráfico. | Exigido | ||
| El equipo debe contar con un módulo de administración tipo lights out que permita encender/apagar el sistema de manera remota y visualizar el proceso de arranque. | Exigido | ||
| La interfaz gráfica debe contar con un Dashboard personalizable que permita monitorear el estado del equipo en tiempo real | Exigido | ||
| Debe contar con un módulo de reportes que permita visualizar gráficamente el comportamiento de las aplicaciones HTTP como latencias hacia los servidores, latencias en los URL, Direcciones IPs que acceden las aplicaciones, URLs más visitados en las aplicaciones, Throughput hacia los servidores y estadísticas acerca de los servicios creados y los servidores físicos. | Exigido | ||
| Debe Contar con plantillas para la implementación rápida de aplicaciones de mercado conocidas (ej., Oracle, Microsoft, SAP, IBM) y permitir crear plantillas personalizadas que puedan ser actualizadas/exportadas entre equipos. | Exigido | ||
| AUTORIZACIÓN DEL FABRICANTE | El oferente deberá presentar una carta del fabricante del equipo, debidamente firmado por una autoridad del mismo con potestades sobre nuestra región, y que se encuentra en condiciones para proveer, instalar, configurar y soportar posteriormente y directamente con la ayuda del fabricante cualquiera de los equipos propuestos en caso de ser adjudicatarios de esta Licitación. La carta deberá hacer referencia al presente llamado, no se aceptarán cartas de autorización del tipo genéricas. | Exigido | |
| GARANTÍA | Se deberá incluir 24 meses de soporte del fabricante para reemplazo avanzado de hardware en la modalidad de Next Business Day, para asistencia técnica el oferente deberá contar con un portal de soporte en línea (WEB) operativo (no se aceptarán versiones beta) y una línea telefónica para la apertura y seguimiento de casos en la modalidad 24x7. | Exigido | |
| Eventos reportados en cualquiera de las plataformas serán atendidos en la modalidad 8 horas del día hábil, 5 días de la semana (no incluye feriados, sábados y domingos), según el tipo de incidente. Si el caso es abierto luego de las 5pm, el caso es atendido el siguiente día hábil (NBD) | |||
| SOPORTE | El Oferente deberá incluir un soporte local 8x5 que cubra consultas, reclamos ante posibles eventos que requieran asistencia técnica inmediata vía remota o presencial. El oferente adjudicado deberá proveer de forma escrita, a la entrega de los equipos, el listado del personal técnico asignado para el soporte de la solución ofertada indicando el nombre completo, cargo, especialidad, correo, teléfono de línea baja y celular. El tiempo de respuesta de soporte presencial deberá ser de 4 horas máximo. | Exigido | |
| PERSONAL TÉCNICO | El oferente debe contemplar el personal técnico necesario para realizar el trabajo de soporte, así como el gerenciamiento de las solicitudes de servicio de soporte a los efectos de la correcta resolución de los problemas o fallas del sistema. Para ello el oferente deberá contar por lo menos 2(dos) personales técnicos para soporte de primer nivel los cuales deberán estar debidamente capacitados. El oferente deberá presentar los certificados de entrenamiento de sus técnicos. No serán aceptados certificados de nivel comercial o preventa. | Exigido | |
| EXPERIENCIA | La empresa oferente deberá presentar documentos que acrediten la experiencia propia de la marca ofertada dentro del territorio nacional en al menos 2 implementaciones de soluciones de WAF y balanceo de carga. Los documentos deberán contener como mínimo el nombre del cliente donde se ha implementado la solución, el número telefónico de contacto y se deberá contar con la posibilidad de poder realizar una visita técnica a dicho cliente. | Exigido | |
| CAPACITACIÓN | Se deberá proveer un curso de capacitación de al menos 40 horas para 3 funcionarios del MADES, el contenido del curso deberá contemplar desde la instalación, configuración y puesta a punto de los componentes de la solución. | Exigido | |
El propósito de la Especificaciones Técnicas (EETT), es el de definir las carácteristicas técnicas de los bienes que la convocante requiere. La convocante preparará las EETT detalladas teniendo en cuenta que:
- Las EETT constituyen los puntos de referencia contra los cuales la convocante podrá verificar el cumplimiento técnico de las ofertas y posteriormente evaluarlas. Por lo tanto, unas EETT bien definidas facilitarán a los oferentes la preparación de ofertas que se ajusten a los documentos de licitación, y a la convocante el examen, evaluación y comparación de las ofertas.
- En las EETT se deberá estipular que todos los bienes o materiales que se incorporen en los bienes deberán ser nuevos, sin uso y del modelo más reciente o actual, y que contendrán todos los perfeccionamientos recientes en materia de diseño y materiales, a menos que en el contrato se disponga otra cosa.
- En las EETT se utilizarán las mejores prácticas. Ejemplos de especificaciones de adquisiciones similares satisfactorias en el mismo sector podrán proporcionar bases concretas para redactar las EETT.
- Las EETT deberán ser lo suficientemente amplias para evitar restricciones relativas a manufactura, materiales, y equipo generalmente utilizados en la fabricación de bienes similares.
- Las normas de calidad del equipo, materiales y manufactura especificadas en los Documentos de Licitación no deberán ser restrictivas. Siempre que sea posible deberán especificarse normas de calidad internacionales . Se deberán evitar referencias a marcas, números de catálogos u otros detalles que limiten los materiales o artículos a un fabricante en particular. Cuando sean inevitables dichas descripciones, siempre deberá estar seguida de expresiones tales como “o sustancialmente equivalente” u “o por lo menos equivalente”. Cuando en las ET se haga referencia a otras normas o códigos de práctica particulares, éstos solo serán aceptables si a continuación de los mismos se agrega un enunciado indicando otras normas emitidas por autoridades reconocidas que aseguren que la calidad sea por lo menos sustancialmente igual.
- Asimismo, respecto de los tipos conocidos de materiales, artefactos o equipos, cuando únicamente puedan ser caracterizados total o parcialmente mediante nomenclatura, simbología, signos distintivos no universales o marcas, únicamente se hará a manera de referencia, procurando que la alusión se adecue a estándares internacionales comúnmente aceptados.
- Las EETT deberán describir detalladamente los siguientes requisitos con respecto a por lo menos lo siguiente:
(a) Normas de calidad de los materiales y manufactura para la producción y fabricación de los bienes.
(b) Lista detallada de las pruebas requeridas (tipo y número).
(c) Otro trabajo adicional y/o servicios requeridos para lograr la entrega o el cumplimiento total.
(d) Actividades detalladas que deberá cumplir el proveedor, y consiguiente participación de la convocante.
(e) Lista detallada de avales de funcionamiento cubiertas por la garantía, y las especificaciones de las multas aplicables en caso de que dichos avales no se cumplan.
- Las EETT deberán especificar todas las características y requisitos técnicos esenciales y de funcionamiento, incluyendo los valores máximos o mínimos aceptables o garantizados, según corresponda. Cuando sea necesario, la convocante deberá incluir un formulario específico adicional de oferta (como un Anexo al Formulario de Presentación de la Oferta), donde el oferente proporcionará la información detallada de dichas características técnicas o de funcionamiento con relación a los valores aceptables o garantizados.
Cuando la convocante requiera que el oferente proporcione en su oferta una parte de o todas las Especificaciones Técnicas, cronogramas técnicos, u otra información técnica, la convocante deberá especificar detalladamente la naturaleza y alcance de la información requerida y la forma en que deberá ser presentada por el oferente en su oferta.
Si se debe proporcionar un resumen de las EETT, la convocante deberá insertar la información en la tabla siguiente. El oferente preparará un cuadro similar para documentar el cumplimiento con los requerimientos.
Los bienes y/o servicios deberán cumplir con las siguientes especificaciones técnicas y normas:
|
ITEM |
DESCRIPCION |
UNIDAD DE MEDIDA |
PRESENTACIÓN |
CANTIDAD |
|
1 |
Balanceador de carga / Terminador SSL |
Unidad |
Unidad |
2 |
Para los procedimientos de Menor Cuantía, este tipo de procedimiento de contratación estará preferentemente reservado a las MIPYMES, de conformidad al artículo 34 inc b) de la Ley N° 7021/22 ‘’De Suministro y Contrataciones Públicas". Son consideradas Mipymes las unidades económicas que, según la dimensión en que organicen el trabajo y el capital, se encuentren dentro de las categorías establecidas en el Artículo 5° de la Ley N° 4457/2012 ‘’PARA LAS MICRO, PEQUEÑAS Y MEDIANAS EMPRESAS’’, y se ocupen del trabajo artesanal, industrial, agroindustrial, agropecuario, forestal, comercial o de servicio
La entrega de los bienes se realizará de acuerdo al plan de entrega, indicado en el presente apartado. Así mismo, de los documentos de embarque y otros que deberá suministrar el proveedor indicado a continuación:
|
ITEM |
DESCRIPCION |
CANTIDAD |
UNIDAD DE MEDIDA |
LUGAR DE ENTREGA DE LOS BIENES |
PLAZO |
|
1 |
Balanceador de carga / Terminador SSL |
2 |
Unidad |
MADES Sede Central: Madame Lynch N° 3500 Asunción |
Dentro de los 60 (SESENTA) días calendarios contados desde la recepción efectiva de la orden de Compra por parte del proveedor adjudicado |
Para la presente contratación se pone a disposición los siguientes planos o diseños:
No aplica
El embalaje, la identificación y la documentación dentro y fuera de los paquetes serán como se indican a continuación:
No aplica
Las inspecciones y pruebas serán como se indica a continuación:
No aplica
El documento requerido para acreditar el cumplimiento contractual, será:
Frecuencia: Dentro del plazo de vigencia establecido
Planificación de indicadores de cumplimiento:
|
INDICADOR |
TIPO |
FECHA DE PRESENTACIÓN PREVISTA |
|
Nota de Remisión |
Nota de Remisión |
Entrega de los bienes e implementación y puesta a punto/ funcionamiento deberá ser dentro de los 60 días calendarios posteriores a la recepción efectiva de la orden de compra por parte del proveedor adjudicado |
|
Acta de Recepción y Conformidad |
Acta de Recepción y Conformidad |
Entrega de los bienes e implementación y puesta a punto/ funcionamiento deberá ser dentro de los 60 días calendarios posteriores a la recepción efectiva de la orden de compra por parte del proveedor adjudicado |
De manera a establecer indicadores de cumplimiento, a través del sistema de seguimiento de contratos, la convocante deberá determinar el tipo de documento que acredite el efectivo cumplimiento de la ejecución del contrato, así como planificar la cantidad de indicadores que deberán ser presentados durante la ejecución. Por lo tanto, la convocante en este apartado y de acuerdo al tipo de contratación de que se trate, deberá indicar el documento a ser comunicado a través del módulo de Seguimiento de Contratos y la cantidad de los mismos.