Suministros y Especificaciones técnicas

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.

Detalles de los productos y/ servicios con las respectivas especificaciones técnicas - CPS

Los productos y/o servicios a ser requeridos cuentan con las siguientes especificaciones técnicas:

SUMINISTROS REQUERIDOS - ESPECIFICACIONES TÉCNICAS

 

GENERALIDADES:

  • MÓDULO DE OFERTAS ELECTRÓNICAS:

De acuerdo a lo establecido en la Res. DNCP N° 1930/20 Por la cual se dispone la utilización del Sistema de Información de Contrataciones Públicas para la presentación y apertura de ofertas electrónicas en los procedimientos de contratación:

  • El oferente que participe en el presente procedimiento de contratación deberá contar, como condición previa, con un usuario activo en el Sistema de Información de Proveedores del Estado (SIPE) para acceder al módulo de oferta electrónica a efectos de la presentación y apertura de ofertas.
  • Presentación de ofertas electrónicas: la oferta deberá ser presentada a través del módulo de ofertas electrónicas del SICP a más tardar en el día y hora señalados al efecto en el SICP. Asimismo, podrá ser modificada y retirada hasta antes del día y hora previstos para la presentación de ofertas y realización del acto de apertura, según corresponda en cada caso de acuerdo a las disposiciones legales.
  • Carga de Ofertas electrónicas: ingresando al módulo habilitado en el SICP, a través de su usuario y contraseña, el oferente generará su oferta. En ella cargará todos los documentos requeridos en el presente pliego de bases y condiciones, los cuales deberán ser incorporados electrónicamente y estar debidamente firmados, según corresponda.
  • Remisión de documentos en formato físico: A los efectos de la verificación y validación de la documentación que integra las ofertas electrónicas recibidas, se establecerá en el SICP lugar, fecha y hora límites para que el oferente remita en sobre cerrado: el Formulario de Oferta, la Lista de Precios y la Garantía de Mantenimiento de oferta originales en formato físico. El plazo establecido por la Convocante en el SICP no podrá ser superior a dos días hábiles posteriores a la fecha prevista para el acto de apertura. La falta de presentación de la documentación física en el lapso señalado será motivo de rechazo de la oferta electrónica y la conducta del oferente será analizada conforme a lo establecido en el título séptimo De las Infracciones y Sanciones de la Ley 2051/2003. La presentación física del Formulario de Oferta, de la Lista de Precios y de la Garantía de Mantenimiento de Oferta no será requerida cuando los documentos hayan sido suscritos digitalmente en las condiciones y términos previstos por la Ley Nº 4017/2010 "De validez jurídica de la firma electrónica, la firma digital, los mensajes de datos y el expediente electrónico". En los casos en que la Garantía de Mantenimiento de Oferta fuera instrumentada mediante una póliza de seguros digital, la presentación física no será requerida si el documento cumple con los requerimientos y condiciones exigidas por la Superintendencia de Seguros del Banco Central del Paraguay.
  • PORCENTAJE DE LA GARANTÍA DE MANTENIMIENTO DE OFERTA

El porcentaje indicado en el SICP para la Garantía de Mantenimiento de Oferta es del 5% cinco por ciento.

  • ADENDAS AL PBC:

La adenda es el documento emitido por la convocante, mediante la cual se modifican aspectos establecidos en la convocatoria y/o en las bases de la licitación. La adenda será considerada parte integrante del documento cuyo contenido modifique.

La convocante podrá introducir modificaciones o enmiendas a los pliegos de bases y condiciones, siempre y cuando se ajuste a los parámetros establecidos en la Ley.

La convocante podrá prorrogar el plazo de presentación de ofertas a fin de dar a los posibles oferentes, un plazo razonable para que puedan tomar en cuenta la enmienda en la preparación de sus ofertas. Esta prórroga deberá quedar asentada en la adenda citada.

  • RESPONSABILIDADES GENERALES DEL PROVEEDOR:

1. El Proveedor deberá suministrar todos los bienes o servicios de acuerdo con las condiciones establecidas en el pliego de bases y condiciones y sus adendas, así como en el Contrato y sus adendas.

2. El Proveedor será responsable de cualquier indemnización por daños causados en el marco de la ejecución del contrato por él o su personal a los funcionarios y/o a terceros, y/o a los bienes de éstos, y/o a los bienes o instalaciones o imagen reputacional de la Contratante; por causas imputables al mismo.

3. Responder por todo incumplimiento o consecuencia imputable al mismo, derivados de la incorrecta o incompleta ejecución de lo contratado.

4. Contratar y mantener el personal calificado necesario para la realización de los servicios requeridos. Cumplir con todas las leyes laborales y de Seguridad Social vigentes. Asumir todos los riesgos en los términos del Código del Trabajo vigente, liberando al BCP de cualquier responsabilidad al respecto.

5. Cumplir con todas las medidas de seguridad que se requieran respecto a su personal, a fin de evitar accidentes de trabajo durante la ejecución contractual.

6. El Proveedor deberá indemnizar y eximir de cualquier responsabilidad a la contratante y a sus empleados y funcionarios, por cualquier litigio, acción legal o procedimiento administrativo, reclamación, demanda, pérdida, daño, costo y gasto cualquiera sea su naturaleza, incluidos los honorarios y gastos de representación legal, en los cuales pueda incurrir la contratante como resultado de riesgos profesionales o muerte de los empleados del Proveedor, sea reclamado por el trabajador o sus causahabientes durante la vigencia del contrato. Como riesgos profesionales se entenderán los accidentes de trabajo y enfermedades profesionales. Se considerarán igualmente accidentes del trabajo los hechos constituidos por caso fortuito o fuerza mayor inherentes al trabajo que produzcan las mismas lesiones.

  • CONFIDENCIALIDAD DE LA INFORMACIÓN

De acuerdo a lo indicado en la Sección Especificaciones técnicas y Suministros Requeridos, el personal del Proveedor deberá firmar un Compromiso de Confidencialidad de la Información en los términos del Formulario de la Sección Formularios Adicionales.

MODALIDAD DE CONTRATACIÓN

Contrato Cerrado.

ESPECIFICACIONES TÉCNICAS

La solución debe cumplir con las siguientes características:

ESPECIFICACIONES TÉCNICAS

Requisito

Detalle y definiciones

REQUERIDO

OFRECIDO

ITEM N° 1: ADQUISICIÓN DE SOLUCIÓN DE GESTIÓN DE IDENTIDADES Y PRIVILEGIOS

1.1 Generalidades del Servicio

1.1.1

Se solicita la provisión de una herramienta que permita el Gobierno y Administración de Identidades (IGA) para la automatización del proceso de requerir, aprobar, certificar y auditar el acceso a las aplicaciones, datos y otros servicios de TI y la automatización del proceso de entregar información de gobierno y seguridad sobre cómo las identidades son creadas, administradas y utilizadas para acceder a las aplicaciones para por lo menos 900 cuentas de usuarios, con proyecciones de crecimiento, en las distintas plataformas utilizadas por el Banco Central del Paraguay, con soporte y mantenimiento del fabricante por 24 meses desde la fecha de entrega de la solución/licencia, en modalidad de licenciamiento perpetuo. 

EXIGIDO

 

1.1.2

Debe cumplir con las siguientes categorías de funcionalidades de IGA: * Evaluación del Estado Actual en cuanto a usuarios, perfiles y recursos.

EXIGIDO

 

1.1.2.1

* Control de Calidad y Limpieza de Privilegios  

EXIGIDO

 

1.1.2.2

* Administración de Perfiles

EXIGIDO

 

1.1.2.3

* Administración y Aprovisionamiento de Usuarios   

EXIGIDO

 

1.1.2.4

* Administración de Requerimientos de Servicios de Accesos

EXIGIDO

 

1.1.3

Debe contemplar la implementación de la solución ofertada para la administración centralizada de privilegios.

EXIGIDO

 

1.1.4

Debe contemplar la implementación de la solución en un servidor que sirva de administrador central de las cuentas de usuarios.

EXIGIDO

 

1.1.5

Debe ser posible realizar un ‘GAP Analysis’ que permita identificar las aplicaciones y sistemas que serán más beneficiados por una sistematización de los procesos de Gestión de Identidades y que contribuyan a una disminución de los riesgos para la Institución.

EXIGIDO

 

1.2 Evaluación del Estado Actual de Gestión de Identidades

1.2.1

Importar datos desde como mínimo tres de los sistemas más significativos de la Institución y poder establecer una comprensión del estado actual de las identidades, perfiles y estado de privilegios dentro de los primeros 10 días de inicio de la implementación. Posteriormente, se integrarán las tecnologías que sean definidas como resultado del GAP Analysis.

EXIGIDO

 

1.2.2

Debe ser posible importar datos desde una fuente o sistema gestionado o administrado por Recursos Humanos, que contengan información de la estructura jerárquica de la Institución y alimenten la evaluación del estado actual en cuanto a perfiles y usuarios.

EXIGIDO

 

1.2.3

Con los datos obtenidos de las importaciones, debe cuantificar el número de usuarios, grupos, perfiles y privilegios de los sistemas significativos de la Institución.

EXIGIDO

 

1.2.4

Con los datos obtenidos de las importaciones, debe evaluar los privilegios y perfiles definidos.

EXIGIDO

 

1.2.5

Con los datos obtenidos, la solución debe identificar y cuantificar:

* Privilegios excepcionales  

EXIGIDO

 

1.2.5.1

* Asignación inconsistente de permisos  

EXIGIDO

 

1.2.5.2

* Usuarios con permisos de accesos excesivos

EXIGIDO

 

1.2.6

Debe tener la capacidad de evaluar reglas de segregación de funciones que puedan ser utilizadas para evaluar el riesgo para cada perfil asignado.

EXIGIDO

 

1.2.7

Debe ser posible identificar riesgos y necesidades de cumplimiento de regulaciones, así como restricciones en una implementación de procesos de Gestión de Identidades.   

EXIGIDO

 

1.3 Integraciones, Control de Calidad y Limpieza de Privilegios

1.3.1

Debe ser posible determinar cuál es el estado actual de los usuarios y permisos asignados para tener una evaluación base de la situación actual y poder determinar la estrategia de implementación que sea más conveniente para la Institución.  

EXIGIDO

 

1.3.2

Debe ser posible crear un repositorio de identidades basado en los datos de las aplicaciones, correlacionando el acceso y luego identificando permisos fuera de patrón, cuentas huérfanas y usuarios colectores de permisos.  

EXIGIDO

 

1.3.3

Debe soportar que este sea un proceso iterativo, que permita un refinamiento de los accesos de los usuarios mejorando las políticas y procesos. 

EXIGIDO

 

1.3.4

Debe ser posible proveer una visión consolidada de los usuarios, perfiles y privilegios asociados junto con las uniones entre cada uno de ellos   

EXIGIDO

 

1.3.5

Debe ser posible analizar los sistemas existentes (incluidos aquellos que no tienen perfiles definidos) con un nivel de granularidad y análisis que permita identificar temas de seguridad y cumplimiento de regulaciones / auditoría. 

EXIGIDO

 

1.3.6

Debe soportar mínimamente la integración nativa con los siguientes componentes de la suite de Microsoft: * Microsoft Active Directory

EXIGIDO

 

1.3.6.1

* Microsoft Skype for Business Server

EXIGIDO

 

1.3.6.2

* Microsoft Exchange

EXIGIDO

 

1.3.6.3

* Microsoft SQL Server

EXIGIDO

 

1.3.6.4

* Microsoft 365

EXIGIDO

 

1.3.6.5

* Microsoft Windows

EXIGIDO

 

1.3.6.6

* Microsoft Windows Server

EXIGIDO

 

1.3.7

Debe soportar mínimamente la integración nativa con Oracle Server.

EXIGIDO

 

1.3.8

Debe soportar mínimamente la integración vía JDBC/JNDI con los siguientes componentes: * Microsoft SQL Server

EXIGIDO

 

1.3.8.1

* MySQL Enterprise Server

EXIGIDO

 

1.3.8.2

* Open LDAP

EXIGIDO

 

1.3.8.3

* Oracle Server

EXIGIDO

 

1.3.8.4

* Postgres

EXIGIDO

 

1.3.8.5

* Red Hat Directory Server

EXIGIDO

 

1.3.9

Debe soportar mínimamente la integración con los siguientes componentes: * Amazon Web Services

EXIGIDO

 

1.3.9.1

* Azure

EXIGIDO

 

1.3.9.2

* Flat file (CSV)

EXIGIDO

 

1.3.9.3

* G Suite

EXIGIDO

 

1.3.9.4

* IBM DB2 UDB

EXIGIDO

 

1.3.9.5

* Kerberos

EXIGIDO

 

1.3.9.6

* Red Hat Enterprise Linux (AS, ES)

EXIGIDO

 

1.3.9.7

* RSA SecurID

EXIGIDO

 

1.3.9.8

* Salesforce

EXIGIDO

 

1.3.9.9

* ServiceNow

EXIGIDO

 

1.3.10

Debe soportar la integración nativa con sistemas de Recursos Humanos para las operaciones de Alta, Baja y Retiro o cambio de personal.

EXIGIDO

 

1.3.11

Debe ser posible la importación y administración de datos que sea ejecutada en forma inmediata o planificada a intervalos regulares (por lotes).

EXIGIDO

 

1.3.12

Debe ser posible la importación/exportación de datos vía archivos CSV y LDIF.

EXIGIDO

 

1.3.13

Debe ser posible identificar automáticamente y remediar las siguientes excepciones a privilegios, tales como: * Cuentas

EXIGIDO

 

1.3.13.1

* Perfiles

EXIGIDO

 

1.3.13.2

* Recursos huérfanos 

EXIGIDO

 

1.3.13.3

* Colectores de privilegios excesivos 

EXIGIDO

 

1.3.13.4

* Aquellos que estén fuera de patrón

EXIGIDO

 

1.3.14

Debe ser posible automatizar los procesos de consulta a los propietarios de perfiles/recursos que validen las excepciones necesarias 

EXIGIDO

 

1.3.15

Debe ser posible la generación de reportes en forma simplificada para identificar las excepciones de privilegios

EXIGIDO

 

1.4 Gobierno de Identidades

1.4.1

Debe ser posible definir reglas de negocio/compliance mediante una interfaz simplificada en la que no se requiera el desarrollo de programas, utilización APIs o scripts.

EXIGIDO

 

1.4.2

Las reglas de negocio deben especificar controles de: * Segregación de Funciones  

EXIGIDO

 

1.4.2.1

* Restricciones de negocio tales como ubicación física o área a la que se encuentra asignado el personal, función de trabajo, propiedad de datos y otros criterios

EXIGIDO

 

1.4.2.3

* Políticas entre sistemas  

EXIGIDO

 

1.4.2.4

* Ejecución de transacciones de acuerdo con los perfiles y privilegios asignados.

EXIGIDO

 

1.4.3

Debe ser posible establecer el nivel de riesgo y el monitoreo de este, de cualquier combinación de perfiles y privilegios asignados a determinados usuarios

EXIGIDO

 

1.4.4

Debe ser posible la asignación de una calificación de riesgo basada en una combinación de condiciones de negocio (ubicación, función, etc.).

EXIGIDO

 

1.4.5

Debe ser posible mostrar e identificar el nivel de riesgo en el panel principal de cada usuario

EXIGIDO

 

1.4.6

Debe ser posible la certificación automática para: * Usuarios

EXIGIDO

 

1.4.6.1

* Perfiles

EXIGIDO

 

1.4.6.2

* Recursos

EXIGIDO

 

1.4.7

Debe ser posible identificar las cuentas relevantes y ejecutar certificaciones de solo un subconjunto de datos de esas cuentas de aquellos: * Que violan una política de segregación de funciones  

EXIGIDO

 

1.4.7.1

* Combinaciones de permisos de accesos 

EXIGIDO

 

1.4.7.2

* Potencialmente riesgosos (basados en análisis de patrones)

EXIGIDO

 

1.4.7.3

* Recursos con ‘links’ directos a los usuarios (opuesto al modelo de perfiles) 

EXIGIDO

 

1.4.7.4

* Cuentas Huérfanas  

EXIGIDO

 

1.4.7.5

* Permisos que cambian entre fechas 

EXIGIDO

 

1.4.8

Debe ser posible alertar a los usuarios de violaciones a las políticas durante el desarrollo de una campaña de certificación 

EXIGIDO

 

1.4.9

Debe ser posible integrarse con los sistemas de aprovisionamiento para una remediación automática

EXIGIDO

 

1.4.10

Debe ser posible mostrar, mediante reportes y tableros de control, el estado de cumplimiento de la Institución sobre las políticas de Gestión de Identidades definidas.

EXIGIDO

 

1.4.11

Debe ser posible evaluar, mediante las políticas de cumplimiento, los privilegios de acceso entre múltiples sistemas

EXIGIDO

 

1.4.12

Debe ser posible proveer un mecanismo que permita a los administradores especificar, de forma automatizada, el lanzamiento de correos recordatorios y alertas.

EXIGIDO

 

1.4.13

Debe ser posible proveer un mecanismo que permita a los administradores requerir una justificación, mediante un comentario, de la certificación de acceso de un usuario que está violando una política de cumplimiento.

EXIGIDO

 

1.4.14

Debe ser posible proveer un mecanismo intuitivo para que los dueños de los sistemas puedan certificar el acceso de los usuarios.

EXIGIDO

 

1.4.15

Debe ser posible personalizar los procesos de campaña de certificación de privilegios y accesos.

EXIGIDO

 

1.4.16

Debe ser posible proveer un mecanismo que permita que el motor de cumplimiento de políticas pueda ser integrado a otros sistemas mediante ‘web services’.

EXIGIDO

 

1.5 Administración de Perfiles

1.5.1

Debe ser posible el descubrimiento de perfiles usando técnicas como el análisis basado en patrones.

EXIGIDO

 

1.5.2

Debe ser posible utilizar técnicas combinadas para la sugerencia de perfiles según un enfoque ‘top-down’, ‘bottom-up’ e híbrido.

EXIGIDO

 

1.5.3

Debe ser posible proveer metodologías de descubrimiento de perfiles ‘out-of-the-box’ (listo para ser usado) y personalizables mediante parámetros.

EXIGIDO

 

1.5.4

El descubrimiento de los perfiles se puede basar en: * Atributos de RRHH (departamento, locación, etc.).

EXIGIDO

 

1.5.4.1

* Combinación de atributos de RRHH.

EXIGIDO

 

1.5.4.2

* Patrones existentes entre los usuarios y privilegios actualmente definidos  

EXIGIDO

 

1.5.5

Debe ser posible visualizar los diferentes tipos de asociaciones existentes entre usuarios, perfiles y recursos.

EXIGIDO

 

1.5.6

Debe ser posible asociar los resultados de las diferentes metodologías de descubrimiento de perfiles utilizadas.

EXIGIDO

 

1.5.7

Debe ser posible proveer reportes que muestren el grado de cobertura de privilegios de usuarios.

EXIGIDO

 

1.5.8

Debe ser posible soportar simulaciones para los cambios de perfiles propuestos posterior al descubrimiento.

EXIGIDO

 

1.5.9

Debe ser posible proveer una administración basada en web.

EXIGIDO

 

1.5.10

Debe ser posible detectar cambios de permisos de acceso a nivel negocio que sugieran cambios en el modelo de perfiles.

EXIGIDO

 

1.5.11

Debe ser posible automatizar los procesos de negocio para aprobación, autoservicio y modificación de perfiles.

EXIGIDO

 

1.5.12

Debe ser posible proveer consultas y reportes sobre los permisos de acceso y/o perfiles que hayan sido asignados a un usuario.

EXIGIDO

 

1.5.13

Debe ser posible proveer consultas y reportes sobre los usuarios/perfiles que tengan asignado un recurso específico o un permiso de acceso.

EXIGIDO

 

1.5.14

Debe ser posible proveer reportes de privilegios/perfiles y certificaciones, tales como: * Certificación de Privilegios de Usuarios   

EXIGIDO

 

1.5.14.1

* Campaña de Certificación de Usuarios   

EXIGIDO

 

1.5.14.2

* Campaña de Certificación de Perfiles

EXIGIDO

 

1.5.14.3

* Campaña de Certificación de Recursos  

EXIGIDO

 

1.5.14.4

* Estado de Avance de Certificaciones   

EXIGIDO

 

1.5.14.5

* Requerimientos de Cambios de Privilegios de Usuarios  

EXIGIDO

 

1.5.14.6

* Recertificaciones de Privilegios de Usuarios  

EXIGIDO

 

1.5.15

Debe ser posible mostrar, en un tablero de control, el estado en que se encuentran las certificaciones.

EXIGIDO

 

1.5.16

Debe ser posible mostrar el estado en que se encuentran los riesgos de la institución con respecto a la asignación de perfiles y privilegios.

EXIGIDO

 

1.5.17

Debe ser posible proveer reportes de segregación de funciones que permitan: * Restricciones entre Grupos 

EXIGIDO

 

1.5.17.1

* Restricciones entre Recursos 

EXIGIDO

 

1.5.17.2

* Restricciones entre Perfiles

EXIGIDO

 

1.5.17.3

* Restricciones entre datos de recursos humanos y grupos  

EXIGIDO

 

1.5.17.4

* Restricciones entre grupos y recursos

EXIGIDO

 

1.6 Administración de Usuarios

1.6.1

Debe ser posible minimizar la complejidad de la Gestión de Identidades automatizando los procesos de creación, modificación, remoción, o borrado de cuentas de forma eficiente y confiable.

EXIGIDO

 

1.6.2

Debe ser posible crear, actualizar y eliminar cuentas de usuario en cualquier entorno tecnológico del BCP, incluidos sistemas y aplicaciones.

EXIGIDO

 

1.6.3

Debe ser posible almacenar las cuentas administradas por la solución en un directorio.

EXIGIDO

 

1.6.4

Debe ser posible la definición de una identificación de usuario global (UID global) que permita la asociación y mapeo de identidades de usuarios a través de los distintos sistemas integrados en base a reglas prestablecidas (funcionalidad de Autodescubrimiento y correlación de cuentas de usuario).

EXIGIDO

 

1.6.5

Debe ser posible soportar la Gestión de Identidades para los siguientes tipos de grupos de usuarios: * Empleados  

EXIGIDO

 

1.6.5.1

* Contratados  

EXIGIDO

 

1.6.5.2

* Socios de negocio  

EXIGIDO

 

1.6.5.3

* Usuarios externos

EXIGIDO

 

1.6.6

Debe poseer la capacidad de modificar los perfiles y privilegios según el tipo de grupo de usuarios, tanto internos como externos.

EXIGIDO

 

1.6.7

Debe ser posible la asignación granular de permisos, en forma temporal con: * Fecha de comienzo de la asignación  

EXIGIDO

 

1.6.7.1

* Fecha de finalización de la asignación  

EXIGIDO

 

1.6.8

Debe ser posible la delegación dinámica de una tarea de aprobación de manera tal a reasignar la tarea a otro usuario según reglas preestablecidas. 

EXIGIDO

 

1.6.9

Debe ser posible cargar en forma masiva la información de usuarios desde más de una fuente autoritativa (sistemas integrados desde donde se obtienen los datos de cargos, perfiles y otros datos de los usuarios) al mismo tiempo. 

EXIGIDO

 

1.6.10

Debe ser posible la carga masiva de usuarios aplicando reglas y realizando transformaciones de datos para normalizar el modelo de datos de usuarios de los sistemas integrados.

EXIGIDO

 

1.6.11

Debe ser posible el aprovisionamiento de Usuarios basado en roles (RBAC), de la solución a los sistemas integrados.

EXIGIDO

 

1.6.12

Debe ser posible soportar la capacidad de manejar perfiles anidados basado en RBAC.

EXIGIDO

 

1.6.13

Debe ser posible el aprovisionamiento basado en reglas dinámicas (ABAC: Attribute Based Access Control) de manera de poder realizar la asignación de permisos basado en atributos del usuario.

EXIGIDO

 

1.6.14

Debe ser posible proveer flexibilidad de aprovisionar usuarios de fuentes de identidades donde no tenga un conector y donde se requiera un aprovisionamiento manual.

EXIGIDO

 

1.6.15

Debe ser posible la construcción de conectores a aplicaciones internas o comerciales no soportadas por un conector ‘out-of-the-box’ (listo para ser usado), tales como: * Aplicaciones basadas en base de datos  

EXIGIDO

 

1.6.15.1

* Aplicaciones basadas en directorios LDAP  

EXIGIDO

 

1.6.15.2

* Aplicaciones accesibles via ‘web services’ 

EXIGIDO

 

1.6.15.3

* Aplicaciones basadas en la Nube    

EXIGIDO

 

1.6.15.4

* Aplicaciones basadas en CSV

EXIGIDO

 

1.6.16

Debe ser posible el desarrollo de conectores mediante herramientas tipo ‘wizard’, sin la necesidad del desarrollo de programas o scripts.

EXIGIDO

 

1.6.17

Debe ser posible soportar una integración a los diferentes sistemas en forma ‘agentless', es decir, sin necesidad de instalar agentes. 

EXIGIDO

 

1.6.18

Debe ser posible soportar interfaces a sistemas abiertos como: * SPML

EXIGIDO

 

1.6.18.1

* Web Services

EXIGIDO

 

1.6.18.2

* APIs Java

EXIGIDO

 

1.6.19

Debe ser posible el diseño y especificación de los workflows en forma gráfica, sin necesidad del desarrollo de scripts.

EXIGIDO

 

1.6.20

Debe ser posible tener la capacidad de cambiar el camino de aprobación del workflow, teniendo en cuenta el resultado de los pasos intermedios, basado en reglas.

EXIGIDO

 

1.6.21

Debe ser posible soportar las normas estándares de la industria para especificación de Workflow (Standard WfMC).

EXIGIDO

 

1.6.22

Debe ser posible proveer modelos de ejemplo de workflows de aprobación preconfigurados que aceleren la implementación de la solución.

EXIGIDO

 

1.6.23

Debe ser posible proveer Workflows de aprobación: * En serie 

EXIGIDO

 

1.6.23.1

* En Paralelo  

EXIGIDO

 

1.6.23.2

* Teniendo X de Y cantidad de aprobaciones

EXIGIDO

 

1.6.24

Debe ser posible la integración con sistemas o aplicación de terceros vía Web Services (WDSL y SOAP), publicando las tareas de Gestión de Identidades.

EXIGIDO

 

1.6.25

Debe ser posible formular Políticas de Identidades basadas en lógica de negocio, que permitan la ejecución de cambios cuando se cumple una condición o se evalúa una regla determinada.   Los cambios de negocios pueden ser:  * Asignar o revocar perfiles

EXIGIDO

 

1.6.25.1

* Asignar o revocar membresías de grupos

EXIGIDO

 

1.6.25.2

* Actualizar atributos de un perfil de usuario  

EXIGIDO

 

1.6.26

Debe ser posible sugerir plantillas preconfiguradas basadas en posibles procesos de negocio: * Proceso de incorporación de funcionario

EXIGIDO

 

1.6.26.1

* Proceso de cambio de cargo de funcionario

EXIGIDO

 

1.6.26.2

* Proceso de desvinculación de funcionario

EXIGIDO

 

1.6.27

Debe ser posible soportar la aplicación de políticas de identidades en forma selectiva a un grupo de usuarios determinados.

EXIGIDO

 

1.6.28

Debe ser posible formular Políticas de Identidades Preventivas que eviten que un usuario reciba privilegios que no estén acorde a las buenas prácticas de Gestión de Identidades.

EXIGIDO

 

1.6.29

Debe ser posible la construcción de Políticas de Identidades complejas mediante una herramienta tipo ‘wizard’, sin la necesidad del desarrollo de programas o scripts.  

EXIGIDO

 

1.6.30

Debe ser posible tener la capacidad de sincronizar cuentas: * Hacia Afuera: desde la definición central en el IGA hacia los sistemas integrados, a través de políticas de identidades y perfiles. 

EXIGIDO

 

1.6.30.1

* Hacia Adentro: desde los sistemas integrados hacia el IGA, a través de un proceso de sincronización reversa.   

EXIGIDO

 

1.6.31

Debe ser posible ejecutar acciones cuando se detecten cambios que no fueron realizados a través de la herramienta IGA, tales como:  * Enviar flujos de aprobación

EXIGIDO

 

1.6.31.1

* Aceptar 

EXIGIDO

 

1.6.31.2

* Borrar 

EXIGIDO

 

1.6.31.3

* Suspender  

EXIGIDO

 

1.6.32

Debe ser posible la sincronización de usuarios del Active Directory Server (ADS), con información de usuarios de aplicaciones en la nube. Por ejemplo: se puede configurar para que el ADS sincronice adiciones o cambios del grupo local y lo propague al entorno de nube.

EXIGIDO

 

1.6.33

Debe ser posible proveer un mecanismo para gestionar las altas y bajas de cuentas de usuarios mediante la lectura de archivos CSV y XLSX.

EXIGIDO

 

1.6.34

Debe ser posible la carga masiva de usuarios, que ejecute un workflow que permita realizar las siguientes acciones, a nivel de ABM de usuario: • Aprobar

EXIGIDO

 

1.6.34.1

• Rechazar

EXIGIDO

 

1.6.34.2

• Reservar

EXIGIDO

 

1.6.34.3

• Liberar

EXIGIDO

 

1.6.35

Debe ser posible modificar en forma masiva los atributos de un usuario mediante filtros, tales como departamento, ciudad, fecha de ingreso, fecha de egreso etc.     

EXIGIDO

 

1.6.36

Debe ser posible proveer un mecanismo de notificación de correos electrónicos basado en políticas (Ej.: basado en la información del evento y/o de la fecha, se podrá configurar dinámicamente el cuerpo del mensaje y el receptor).

EXIGIDO

 

1.6.37

Debe mostrar en tiempo real las modificaciones realizadas directamente desde la consola de los sistemas integrados, por los administradores, es decir, aquellas que no se hayan realizado desde el IGA, tales como creación de cuentas nuevas, atributos modificados, etc.

EXIGIDO

 

1.6.38

Debe ser posible tener la capacidad para calendarizar o programar las altas y bajas de cuentas, con una fecha efectiva de inicio y fecha efectiva de terminación.

EXIGIDO

 

1.6.39

Debe ser posible buscar usuarios basado en diferentes atributos tales como ID de usuario, apellido, nombre, etc.

EXIGIDO

 

1.6.40

Debe ser posible proveer un mecanismo que permita a los usuarios ver su información de acuerdo con su perfil, con filtros como su nombre, apellido, oficina, teléfono, dirección, roles y privilegios.

EXIGIDO

 

1.6.41

Debe ser posible definir un ID de usuario único durante la creación de la cuenta en el sistema integrado, basado en una lógica predefinida que debe considerar las siguientes situaciones de conflicto: * Que el usuario esté previamente definido (en cuyo caso deberá generar una ID de usuario único).

EXIGIDO

 

1.6.42.1

* Que el usuario haya sido retirado o deshabilitado (en cuyo caso se deberá prevenir la reutilización del mismo usuario).

EXIGIDO

 

1.6.43

Debe ser posible proveer un mecanismo de administración web que permita: * Administrar múltiples sistemas desde un único lugar.

EXIGIDO

 

1.6.43.1

* Administrar múltiples cuentas, grupos y atributos de conectores personalizados definidos por el administrador (conectores ‘adhoc’).

EXIGIDO

 

1.6.43.2

* Tener un control granular de relaciones entre cuentas y grupos.

EXIGIDO

 

1.6.43.3

* Explorar los contenidos de un sistema integrado correlacionando las cuentas.

EXIGIDO

 

1.6.43.4

* Clasificar los sistemas de acuerdo con diferentes criterios (tecnología, área, negocio, etc.).  

EXIGIDO

 

1.6.44

Debe ser posible proveer flexibilidad en la administración de perfil, permitiendo un control granular de cambios a nivel de: * Perfiles de negocio o funcionales

EXIGIDO

 

1.6.44.1

* Las cuentas  

EXIGIDO

 

1.6.44.2

* Los atributos de las cuentas  

EXIGIDO

 

1.6.44.3

* Los valores de los atributos de las cuentas    

EXIGIDO

 

1.6.45

Debe ser posible mostrar en forma gráfica el estado de la ejecución de los workflows permitiendo observar el flujo de ejecución a nivel de: * Tareas aprobadas  

EXIGIDO

 

1.6.45.1

* Tareas enviadas

EXIGIDO

 

1.6.45.2

* Aprobadores en cada instancia del proceso

EXIGIDO

 

1.6.46

La interfaz del usuario de la solución se debe poder configurar en español e inglés.

EXIGIDO

 

1.6.47

Debe ser posible personalizar la interfaz del usuario final, permitiendo:

* Modificar la estructura de las páginas.

EXIGIDO

 

1.6.47.1

* Modificar las pantallas de ayuda en contexto, etc.

EXIGIDO

 

1.6.47.2

* Permitir diferentes 'skins' de acuerdo con el tipo de usuarios que este ingresando a la interfaz.

EXIGIDO

 

1.6.48

Debe ser posible permitir la aprobación de tareas de flujos de trabajo desde un dispositivo móvil.

EXIGIDO

 

1.7 Administración de Requerimientos de Servicios de Accesos

1.7.1

Debe ser posible simplificar la operativa de Administración de Identidades, permitiendo que los usuarios finales sin necesidad de un conocimiento técnico avanzado puedan resolver los temas relacionados con el manejo de sus Identidades y permisos asociados tales como: * Autoservicio de Registro y Administración de Usuarios

EXIGIDO

 

1.7.1.1

* Autoservicio de ‘Reseteo’ de Contraseñas

EXIGIDO

 

1.7.1.2

* Administración de Requerimientos de Servicios de Acceso

EXIGIDO

 

1.8 Autoservicio de Registro y Administración de Usuarios

1.8.1

Debe ser posible tener la capacidad de permitir el autoservicio de registro y administración de usuarios finales. 

EXIGIDO

 

1.8.2

Debe ser posible proveer una interfaz web que permita a los usuarios de negocio: * Actualizar elementos de su Perfil de Usuario.

EXIGIDO

 

1.8.2.1

* Administrar sus contraseñas y configurar las preguntas y respuestas de verificación de identidad.

EXIGIDO

 

1.8.2.2

* Acceso a través de un catálogo a solicitar un nuevo: - Perfil

EXIGIDO

 

1.8.2.2.1

    -Permiso

EXIGIDO

 

1.8.2.2.2

    -Servicio de negocio

EXIGIDO

 

1.8.2.2.3

   - Aplicación

EXIGIDO

 

1.8.3

Debe ser posible que un usuario final realice el seguimiento del estado de las solicitudes que posee.

EXIGIDO

 

1.8.4

Debe ser posible que un usuario final pueda ver los perfiles asignados a sí mismo.

EXIGIDO

 

1.8.5

Debe ser posible, para un usuario final, delegar perfiles y privilegios dependiendo de cómo este configurado.

EXIGIDO

 

1.8.6

Debe ser posible que el proceso de registro obligue al usuario final a dar como leída y aceptada las condiciones de acceso a la Institución, a través de un formulario de aceptación o una política de seguridad aprobada. 

EXIGIDO

 

1.8.7

Debe ser posible que el proceso de registro permita establecer diferentes métodos de verificación de identidad: * Validación de los atributos ingresados en la pantalla de registro, que son comparados contra sistemas internos/externos de verificación de estos atributos.

EXIGIDO

 

1.8.7.1

* Validación del usuario en forma posterior por parte de un administrador.

EXIGIDO

 

1.8.8

La interfaz web debe proveer formularios para el registro de usuarios.

EXIGIDO

 

1.9 Autoservicio de Reseteo de Contraseñas

1.9.1

Debe ser posible que los usuarios autogestionen sus contraseñas a través de la interfaz web. 

EXIGIDO

 

1.9.2

Debe ser posible poseer un sistema de administración de contraseñas flexible que permite establecer políticas robustas de: * Composición  

EXIGIDO

 

1.9.2.1

* Reutilización  

EXIGIDO

 

1.9.2.2

* Expiración 

EXIGIDO

 

1.9.2.3

* Reseteo  

EXIGIDO

 

1.9.2.4

* Autoservicio  

EXIGIDO

 

1.9.2.5

* Propagación 

EXIGIDO

 

1.9.2.6

* Sincronización  

EXIGIDO

 

1.9.2.7

* Integración 

EXIGIDO

 

1.9.3

Debe ser posible asignar la contraseña a un usuario la primera vez y luego obligar su cambio con el primer inicio de sesión.

EXIGIDO

 

1.9.4

Debe ser posible soportar políticas de contraseña, que permita establecer los siguientes parámetros, de forma flexible: * Composición de contraseña basado en un diccionario de palabras no permitidas.

EXIGIDO

 

1.9.4.1

* Extensión o Longitud mínima

EXIGIDO

 

1.9.4.2

* Historial mínimo

EXIGIDO

 

1.9.4.3

* Duración mínima

EXIGIDO

 

1.9.4.4

* Datos de los atributos del perfil de usuario

EXIGIDO

 

1.9.4.5

* Porcentaje de diferencia con respecto a la contraseña anterior

EXIGIDO

 

1.9.5

Debe ser posible establecer diferentes políticas de contraseñas para diferentes grupos de usuarios.

EXIGIDO

 

1.9.6

Debe ser posible proveer un mecanismo de autoservicio de preguntas/respuestas de seguridad al usuario para: * Olvido de ID de usuario

EXIGIDO

 

1.9.6.1

* Olvido de Contraseña de usuario

EXIGIDO

 

1.9.7

Debe ser posible proveer una interfaz que permita el proceso de recuperación de datos de cuenta (ID de usuario, contraseña, etc.) antes de la pantalla de inicio de sesión de usuario del sistema operativo (Ej.: Windows).

EXIGIDO

 

1.9.8

Debe ser posible soportar políticas de expiración de contraseñas flexibles para satisfacer las necesidades de la Institución, basadas en: * Inactividad de un usuario (seguimiento de inicio de sesión exitosos)

EXIGIDO

 

1.9.8.1

* Cantidad de contraseñas incorrectas (seguimiento de inicio de sesión fallidos)

EXIGIDO

 

1.9.9

Debe ser posible proveer un mecanismo de propagación de cambio de contraseñas a todas las plataformas soportadas.

EXIGIDO

 

1.9.10

Debe ser posible proveer un mecanismo para capturar cambios de contraseñas cuando se realizan en Active Directory (Windows), y sincronizar en forma bidireccional estos cambios con la solución IGA.

EXIGIDO

 

1.9.11

Debe ser posible presentar una interfaz compatible con dispositivos móviles (Smartphone) y realizar: * Reseteo de Contraseñas 

EXIGIDO

 

1.9.11.1

* Cambio de Contraseñas 

EXIGIDO

 

1.9.11.2

* Responder a solicitudes de aprobación 

EXIGIDO

 

1.9.11.3

* Debe proveer soporte para las plataformas móviles IOS y Android

EXIGIDO

 

1.10 Administración de Requerimientos de Servicios de Acceso

1.10.1

Debe ser posible la personalización de la interfaz de usuarios finales como: * Agregar el logo de la institución al portal

EXIGIDO

 

1.10.1.1

* Modificación del background del portal

EXIGIDO

 

1.10.1.2

* Modificación de tipografía del portal

EXIGIDO

 

1.10.2

Debe ser posible presentar una interfaz intuitiva a nivel usuario final que simplifique el proceso de requerimiento de acceso, a través de un tipo de ‘carrito de compras’, donde los usuarios puedan seleccionar los perfiles y permisos que sean necesarios para cumplir sus funciones.

EXIGIDO

 

1.10.3

Debe ser posible que el usuario final pueda visualizar: * Detalles de su Perfil de usuario 

EXIGIDO

 

1.10.3.1

*  Acceso Actual 

EXIGIDO

 

1.10.3.2

* Cuentas asignadas en los distintos sistemas integrados 

EXIGIDO

 

1.10.3.3

* Estado de sus Requerimientos de Acceso, y Certificaciones de Acceso 

EXIGIDO

 

1.10.4

Debe ser posible que el usuario final pueda visualizar y hacer seguimiento activo del proceso de solicitud de acceso (tiempo de la solicitud, cuándo fue pedido, cuándo fue aprobado, qué queda pendiente).

EXIGIDO

 

1.10.5

Debe ser posible el manejo de un Catálogo de permisos granulares de manera tal que permita solicitar: * Perfiles

EXIGIDO

 

1.10.5.1

* Membresía de grupos 

EXIGIDO

 

1.10.5.2

* Atributos de usuario

EXIGIDO

 

1.10.6

Debe ser posible soportar un Modelo de Permisos que permita presentar y agrupar estos en forma lógica, de manera que el usuario final pueda solicitar los permisos que necesita. Las agrupaciones lógicas deberían ser al menos las siguientes: * Aplicaciones

EXIGIDO

 

1.10.6.1

* Grupo de Aplicaciones 

EXIGIDO

 

1.10.6.2

* Perfiles

EXIGIDO

 

1.10.6.3

* Grupo de Perfiles

EXIGIDO

 

1.10.6.4

* Permisos de Negocio 

EXIGIDO

 

1.11 Hardware y Software

1.11.1

EL BCP dispondrá para la implementación de: hasta 2 instancias virtuales, cada una con como máximo 10 vCPUs, 128 GB de RAM, y 400 GB HD, con su respectivo software de base (ESXi y SO).

EXIGIDO

 

1.11.2

En caso de que la solución requiera conectarse a un motor de base de datos, el BCP podrá disponer una instancia de SQL Server. Si la solución no es compatible con esta base de datos, el proveedor deberá incluir la licencia de la base de datos, en su propuesta, con la que su solución es compatible.

EXIGIDO

 

1.11.3

Cualquier licencia de software adicional no contemplado en este documento, el proveedor deberá incluir en su propuesta para asegurar el correcto y completo funcionamiento de la solución.

EXIGIDO

 

1.12 Servicio de relevamiento previo a la implementación

1.12.1

Se debe contemplar el servicio de relevamiento antes de la implementación de la herramienta. 

EXIGIDO

 

1.12.1.1

Etapa de Relevamiento: *Que permita conocer toda la variedad de los ámbitos funcionales y organizacionales, determinando los niveles de usuarios existentes y proyectados.

EXIGIDO

 

1.12.1.1.1

* Se debe identificar los sistemas de información que deben ser integrados a una solución IGA.

EXIGIDO

 

1.12.1.1.2

* Definición de Esquema de Políticas de Acceso: Se debe definir el esquema de políticas de acceso conforme a la estructura organizacional existente. Esta definición debe estar diseñada de forma tal que permita la flexibilidad ante cambios de estructuras organizacionales que pudiera presentarse, con el fin de que estos puedan aplicarse de manera simple y sencilla, minimizando el impacto que pueda producir.

EXIGIDO

 

1.12.1.1.3

* Definición de Perfiles: Se deben definir los Perfiles y sus privilegios con base al esquema de políticas de acceso existente, manteniendo la flexibilidad de cambios que puedan producirse y apuntando al nivel mínimo de granularidad.

EXIGIDO

 

1.12.1.1.4

* Definición de usuario "especiales": Se deben definir los perfiles y los privilegios de los usuarios que requieren accesos especiales a ciertos recursos tecnológicos, debido a sus funciones como especialistas.

EXIGIDO

 

1.12.1.2

Etapa de Propuesta: * Se debe proponer un listado de sistema a integrar a la solución, basado en el relevamiento previo

EXIGIDO

 

1.12.1.2.1

* Se debe proponer un documento que defina el plan estratégico de integración con la solución IGA.

EXIGIDO

 

1.12.1.2.2

Propuesta de Estrategia de Implementación: * Se debe proponer un documento que especifique, a partir de la Definición de Esquema de Políticas de Acceso, los perfiles de Sistemas y Perfiles globales.

EXIGIDO

 

1.12.1.2.3

* Se debe, conforme al diagnóstico obtenido, elaborar un Plan de Acción que deberá incluir niveles de prioridad para la implementación, recursos necesarios y plazos esperados.

EXIGIDO

 

1.13 Servicio de implementación

1.13.1

El oferente deberá incluir: la instalación, configuración y puesta en producción del producto, posterior al relevamiento previo realizado.

EXIGIDO

 

ITEM N° 2: SERVICIOS DE ACOMPAÑAMIENTO Y SOPORTE LOCAL (MENSUAL)

2.1 Servicio de acompañamiento y soporte local

2.1.1

Se requiere acompañamiento y soporte local del Proveedor por 20 meses contados a partir de la fecha de entrega de la solución y de la entrega del informe de plan de implementación (ítem N° 1)

EXIGIDO

 

 

DEL PERSONAL INTERVINIENTE

El Oferente deberá presentar una declaración jurada que garantice que el personal técnico asignado a este servicio está técnicamente calificado para realizar los trabajos descriptos en las especificaciones técnicas, asumiendo la responsabilidad por los trabajos del personal técnico asignado, los equipos y las tareas realizadas comprendidas en las presentes especificaciones técnicas.

El plantel técnico debe estar conformado al menos por 6 (seis) profesionales.  El oferente deberá presentar el Curriculum vitae de los mismos, conforme al Formato obrante más abajo, así como los documentos exigidos más abajo.

A continuación, el detalle de los perfiles requeridos para cada miembro del plantel técnico:

    1. Arquitecto de Soluciones IAM/IGA: al menos 1 (uno). Debe ser Licenciado en Análisis de Sistemas, Licenciado en Ciencias Informáticas, Ingeniero de Sistemas Informáticos o afines, que será responsable de establecer los requisitos técnicos (infraestructura y ciberseguridad) del proyecto de gestión de identidades. Debe contar con experiencia demostrable igual o mayor a 10 años en asesoramiento, consultoría y/o implementación de proyectos de Gestiones de Identidades. Asimismo, se deberá presentar fotocopia simple del documento que acredite que dicho personal cuenta con un programa de certificación del fabricante de la solución.
    1. Arquitecto de Infraestructura: al menos 1 (uno). Debe ser Licenciado en Análisis de Sistemas, Licenciado en Ciencias Informáticas, Ingeniero de Sistemas Informáticos o afines, que será responsable del diseño e implementación del software de base a modo de respaldar la infraestructura previa necesaria para el funcionamiento óptimo de la solución ofertada, en el cual se acredite como mínimo 3 (tres) experiencias en procesos de diseño e implementación de la solución ofertada.
    1. Integrador de Soluciones: al menos 1 (uno). Debe ser Licenciado en Análisis de Sistemas, Licenciado en Ciencias Informáticas, Ingeniero de Sistemas Informáticos o afines, que será responsable de los procesos relacionados con la creación de conectores a medida para nuevos sistemas, desde la planificación inicial hasta el establecimiento, diseño, codificación y pruebas, en el cual se acredite como mínimo 2 (dos) experiencias en el desarrollo de conectores en la herramienta ofertada contra endpoints no homologados.
    1. Gerente de Proyecto: al menos 1 (uno), quien deberá asegurarse de que el proyecto se cumpla dentro de los objetivos marcados, entre ellos los requisitos de alcance y tiempo. Debe contar con experiencia demostrable igual o mayor a 10 años en liderar proyectos y al menos 3 (tres) referencias de haber liderado proyectos de Gestión de Identidades en instituciones públicas y/o privadas. Asimismo, se deberá presentar fotocopia simple del documento que acredite que dicho personal cuenta con certificación de al menos 1 (una) metodología en administración de proyecto.
    1. Consultor Senior (IAM/IGA): al menos 1 (uno), quien será responsable principal del logro de los objetivos establecidos en el punto 1.12 de las especificaciones técnicas. Debe contar con experiencia demostrable igual o mayor a 10 años en la implementación/configuración de la disciplina de Identity Governance and Administration y de haber participado en diferentes proyectos de asesoramiento, consultoría y/o implementación de soluciones de Gestión de Identidades. Asimismo, se deberá presentar fotocopia simple del documento que acredite que dicho personal cuenta con certificación del fabricante de la solución ofertada.
    1. Consultor implementador (IAM/IGA): al menos 1 (uno), quien realizará la instalación y puesta en marcha de la solución ofertada, en el cual se acredite como mínimo 3 (tres) experiencias en la implementación en instituciones públicas y/o privadas en el periodo comprendido entre los años 2015 al 2022. Asimismo, se deberá presentar fotocopia simple del documento que acredite que dicho personal cuenta con certificación del fabricante de la solución ofertada.

El BCP se reserva el derecho a verificar la información y para el efecto se deberá incluir una lista de los clientes (Empresa, contacto, teléfono, correo corporativo) en los cuales todos los perfiles solicitados hayan participado en proyectos de la solución ofertada.

Formato del Currículum Vitae de cada personal interviniente que el Oferente deberá presentar con su oferta:

Datos Personales

Requerimientos

Documentación de respaldo

Nombre(s)

Especificar

 

Apellido(s)

Especificar

 

Fecha de Nacimiento

Especificar

 

N° de documento de identidad

Especificar

Adjuntar fotocopia simple de C.I.

Formación Académica

Nivel Terciario

Exigido

Adjuntar la fotocopia simple del título o certificado de estudios en caso de que haya finalizado la carrera universitaria en las carreras de Informática o afines.

Carrera

Especificar

 

Culminación

Especificar

 

Certificaciones

Exigido

Adjuntar la fotocopia simple de los documentos que acrediten las certificaciones.

Programa de Certificación del Fabricante

Especificar (exigido Arquitecto de Soluciones IAM/IGA)

 

Certificación del Fabricante

Especificar (exigido para Consultor Senior (IAM/IGA) e Implementador (IGA/IAM))

 

Certificación de Gestión de Proyecto

Especificar (exigido para el Gerente de Proyecto)

 

 

Profesional

Experiencia (años/implementaciones)

Adjuntar fotocopia simple de las referencias documentadas de la experiencia requerida.

Arquitecto de Soluciones IAM

Especificar

 

Arquitecto de Infraestructura

Especificar

 

Integrador de Soluciones

Especificar

 

Gerente de Proyecto

Especificar

 

Consultor Senior (IAM/IGA)

Especificar

 

Consultor implementador (IAM/IGA)

Especificar

 

CONDICIONES GENERALES

  1. Compromiso de Confidencialidad: el personal contratado interviniente del proveedor deberá firmar un Compromiso de Confidencialidad de la Información, dado que podría acceder a información confidencial de la Contratante, de acuerdo al Formulario incluido en la Sección "Formularios" del PBC.
  2. Área Técnica Administradora del Contrato: la administración del contrato estará a cargo del Departamento de Ciberseguridad.
  3. Acuerdo de Nivel de Servicio:

El Proveedor deberá suscribir un Acuerdo de Nivel de Servicio, bajo los siguientes términos:

Tiempo de respuesta a incidentes que afectan la disponibilidad del servicio:

  • Crítico: 2 (dos) horas desde la comunicación del incidente.
    En caso de no cumplir con el plazo establecido, el Proveedor deberá comunicarlo por escrito mediante nota dirigida al DCS, indicando los motivos técnicos de su atraso. En estos casos, el Proveedor está obligado a proporcionar y mantener funcionando el servicio de respaldo/contingencia mientras dure la reparación y puesta a punto del servicio.
  • No crítico: 4 (cuatro) horas desde la comunicación del incidente.
    El Proveedor facilitará el nombre, número telefónico y correo electrónico del contacto para gestionar los incidentes críticos y no críticos.
  1. Lugar y Horario de Trabajo: la prestación del servicio se realizará de manera presencial en las oficinas del Banco Central, sito en Av. Federación Rusa y Augusto Roa Bastos, en el horario de 8:00 a 16:00, pudiendo eventualmente el Dpto. de Ciberseguridad establecer otros horarios. Para casos excepcionales y previo acuerdo con la contraparte técnica administradora del contrato (Departamento de Ciberseguridad del BCP), se podrá realizar de manera remota, a través de herramientas tecnológicas tales como Microsoft Teams, acceso VPN a través de herramientas SDP o similares.
  2. Forma de pago: La Contratante abonará al Proveedor en Guaraníes, en un plazo máximo de 30 (treinta) días contados a partir de la presentación de la factura correspondiente y del otorgamiento de la conformidad por parte del área técnica encargada del control y fiscalización, conforme se establece: 
    Item N° 1
         		 A la entrega del Informe de Relevamiento 20% del monto contratado del ítem n°1. 
    Entrega e instalación de la solución y entrega del Informe del Plan de Implementación 80% del monto contratado del ítem n°1. 
    Item N° 2 En forma mensual. El plazo de inicio será a partir de la fecha de entrega de la solución y de la entrega del informe de plan de implementación (Item N° 1) El precio unitario mensual

Identificación de la unidad solicitante y justificaciones

•El presente llamado a ser publicado ha sido solicitado por: el Departamento de Ciberseguridad del Banco Central del Paraguay.

•La necesidad que se pretende satisfacer mediante la contratación realizada radica en: como uno de los componentes principales del Plan Director de Ciberseguridad, que forma parte del PEI vigente, se estableció el proyecto N° 3 Protección Integral de Cuentas de Acceso y Gestión de Privilegios. Este proyecto tiene como objetivo fortalecer los procesos internos operativos de gestión de cuentas, perfiles y privilegios de la organización, en el entendido que una gestión y gobierno adecuados de los privilegios de acceso es un componente esencial de la ciberseguridad de toda organización. El presente proyecto tiene como objetivo la adquisición de la herramienta principal para la gestión de identidades del Banco (Solución IAM/IGA).

•Con relación a la planificación, se indica que: se trata de un llamado que responde a una necesidad temporal.

•Las especificaciones técnicas establecidas se justifican en: las necesidades actuales de la Institución, conocimiento del área técnica, entre otros.

Plan de entrega de los bienes

La entrega de los bienes se realizará de acuerdo al plan de entrega y cronograma de cumplimiento, indicado en el presente apartado. Así mismo, de los documentos de embarque y otros que deberá suministrar el proveedor indicado a continuación: 

No aplica.

Plan de entrega de los servicios

Ítems

Descripción del servicio

Cantidad

Unidad de medida

Lugar donde los servicios serán prestados

 Plazo de ejecución de los servicios

Plazo de prestación de los servicios

Plazo de vigencia del Contrato

De acuerdo a la Lista de Precios publicada en el SICP

De acuerdo a la Lista de Precios publicada en el SICP

De acuerdo a la Lista de Precios publicada en el SICP

De acuerdo a la Lista de Precios publicada en el SICP

Los servicios se prestarán en los lugares establecidos en la Sección Especificaciones Técnicas y Suministros Requeridos

Item N° 1:

Informe de relevamiento: en el plazo máximo de 20 (veinte) días calendario contados a partir de la fecha a ser establecida en la Orden de Inicio. Entrega e instalación de la solución y Entrega del Informe de Plan de Implementación: en el plazo máximo de 45 (cuarenta y cinco) días calendario contados a partir de la fecha a ser establecida al efecto en la  Orden de Inicio.

El soporte y mantenimiento del fabricante: será prestado por el plazo de 24 (veinticuatro) meses contados a partir de la fecha de entrega de la solución. 

Item N° 2: por el plazo de 20 (veinte) meses contados a partir de la fecha de entrega de la solución y de la entrega del informe de plan de implementación.

El plazo de prestación del servicio será de 26 (veintiseis) meses, contados a partir de la fecha a ser establecida al efecto en la Orden de Inicio, que será emitida por el Departamento de Ciberseguridad dentro de los 10 (diez) días hábiles siguientes a la suscripción del Contrato.

El plazo de vigencia del Contrato será a partir de la fecha a ser establecida al efecto en la Orden de Inicio, que será emitida por el Departamento de Ciberseguridad dentro de los 10 (diez) días hábiles siguientes a la suscripción del Contrato, hasta el cumplimiento total de las obligaciones contractuales.

Planos y diseños

Para la presente contratación se pone a disposición los siguientes planos o diseños:

No aplica

Embalajes y documentos

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

Inspecciones y pruebas

Las inspecciones y pruebas serán como se indica a continuación:

La Contratante fiscalizará la ejecución del Contrato a través del área administradora del Contrato. Se verificará que lo ejecutado cumpla a cabalidad con lo establecido en la Sección Suministros Requeridos Especificaciones técnicas y en la Lista de Precios; y se adecuen al Plan de Entrega de los Bienes o Servicios del presente PBC.

1. El proveedor realizará todas las pruebas y/o inspecciones de los Bienes, por su cuenta y sin costo alguno para la contratante.

2. Las inspecciones y pruebas podrán realizarse en las instalaciones del Proveedor o de sus subcontratistas, en el lugar de entrega y/o en el lugar de destino final de entrega de los bienes, o en otro lugar en este apartado.

Cuando dichas inspecciones o pruebas sean realizadas en recintos del Proveedor o de sus subcontratistas se le proporcionarán a los inspectores todas las facilidades y asistencia razonables, incluso el acceso a los planos y datos sobre producción, sin cargo alguno para la Contratante.

3. La Contratante o su representante designado tendrá derecho a presenciar las pruebas y/o inspecciones mencionadas en la cláusula anterior, siempre y cuando éste asuma todos los costos y gastos que ocasione su participación, incluyendo gastos de viaje, alojamiento y alimentación.

4. Cuando el proveedor esté listo para realizar dichas pruebas e inspecciones, notificará oportunamente a la contratante indicándole el lugar y la hora. El proveedor obtendrá de una tercera parte, si corresponde, o del fabricante cualquier permiso o consentimiento necesario para permitir a la contratante o a su representante designado presenciar las pruebas o inspecciones.

5. La Contratante podrá requerirle al proveedor que realice algunas pruebas y/o inspecciones que no están requeridas en el contrato, pero que considere necesarias para verificar que las características y funcionamiento de los bienes cumplan con los códigos de las especificaciones técnicas y normas establecidas en el contrato. Los costos adicionales razonables que incurra el Proveedor por dichas pruebas e inspecciones serán sumados al precio del contrato, en cuyo caso la contratante deberá justificar a través de un dictamen fundado en el interés público comprometido. Asimismo, si dichas pruebas y/o inspecciones impidieran el avance de la fabricación y/o el desempeño de otras obligaciones del proveedor bajo el Contrato, deberán realizarse los ajustes correspondientes a las Fechas de Entrega y de Cumplimiento y de las otras obligaciones afectadas.

6. El proveedor presentará a la contratante un informe de los resultados de dichas pruebas y/o inspecciones.

7. La contratante podrá rechazar algunos de los bienes o componentes de ellos que no pasen las pruebas o inspecciones o que no se ajusten a las especificaciones. El proveedor tendrá que rectificar o reemplazar dichos bienes o componentes rechazados o hacer las modificaciones necesarias para cumplir con las especificaciones sin ningún costo para la contratante. Asimismo, tendrá que repetir las pruebas o inspecciones, sin ningún costo para la contratante, una vez que notifique a la contratante.

8. El proveedor acepta que ni la realización de pruebas o inspecciones de los bienes o de parte de ellos, ni la presencia de la contratante o de su representante, ni la emisión de informes, lo eximirán de las garantías u otras obligaciones en virtud del contrato.

Indicadores de Cumplimiento

El documento requerido para acreditar el cumplimiento contractual, será:

El documento requerido para acreditar el cumplimiento contractual, será:

  • Documentos de solicitud de los bienes/servicios al Proveedor emitidos por el área administradora del contrato, si correspondiere.
  • Nota/Formulario/Providencia/Memorando de conformidad del área técnica.

Planificación de indicadores de cumplimiento:

INDICADORES

TIPO

FECHA DE PRESENTACIÓN PREVISTA

Documentos de solicitud de los bienes/ servicios al Proveedor, si correspondiere, y  Conformidad del área técnica administradora del contrato.
  • Documentos de solicitud de los bienes/servicios al Proveedor emitidos por el área administradora del contrato, si correspondiere.
  • Nota/Formulario/Providencia/Memorando de conformidad del área técnica administradora del contrato.

En el marco de la ejecución contractual, de acuerdo al plazo establecido en el Plan de Entrega de los  bienes o servicios del presente PBC, el área administradora del contrato emitirá los documentos de solicitud al Proveedor, si correspondiere, y posteriormente, el/la Nota/Formulario/Providencia/Memorando de conformidad, exigida/o para el/los pago/s correspondiente/s.

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.

Criterios de Adjudicación

La convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.

1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante de la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.

2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.

3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad de Bienes requeridos, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.

En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la Convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.

Notificaciones

La comunicación de la adjudicación a los oferentes será como sigue:

1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.

2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.

3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.

4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.

5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.

 

Audiencia Informativa

Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.

La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.

La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.

La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.

Documentación requerida para la firma del contrato

Luego de la notificación de adjudicación, el proveedor deberá presentar en el plazo establecido en las reglamentaciones vigentes, los documentos indicados en el presente apartado.

 

  1. Personas Físicas / Jurídicas
  • Certificado de no encontrarse en quiebra o en convocatoria de acreedores expedido por la Dirección General de Registros Públicos;
  • Certificado de no hallarse en interdicción judicial expedido por la Dirección General de Registros Públicos;
  • Constancia de no adeudar aporte obrero patronal expedida por el Instituto de Previsión Social.
  • Certificado laboral vigente expedido por la Dirección de Obrero Patronal dependiente del Viceministerio de Trabajo, siempre que el sujeto esté obligado a contar con el mismo, de conformidad a la reglamentación pertinente - CPS
  • En el caso que suscriba el contrato otra persona en su representación, acompañar poder suficiente del apoderado para asumir todas las obligaciones emergentes del contrato hasta su terminación.
  • Certificado de cumplimiento tributario vigente a la firma del contrato.

       2. Documentos. Consorcios
  • Cada integrante del Consorcio que sea una persona física o jurídica deberá presentar los documentos requeridos para oferentes individuales especificados en los apartados precedentes.
  • Original o fotocopia del Consorcio constituido
  • Documentos que acrediten las facultades del firmante del contrato para comprometer solidariamente al consorcio.
  • En el caso que suscriba el contrato otra persona en su representación, acompañar poder suficiente del apoderado para asumir todas las obligaciones emergentes del contrato hasta su terminación.