Procedimientos y Políticas

Uso Interno

Instituto Interamericano de Cooperación para la Agricultura

Unidad de Tecnologías de Información y Comunicación

Procedimientos y Políticas

2010

Actualizado enero 2018

Uso Interno

Introducción

Atendiendo el compromiso de mejorar y modernizar los procesos administrativos y tecnológicos

para hacer un uso más racional, equitativo y transparente de los recursos, se integra las presentes

políticas y procedimientos, elaborados por la Unidad de Tecnología de Información y

Comunicación contando con la participación de diferentes unidades. El propósito de este

documento es mejorar la eficiencia, eficacia y gestión de los servicios tecnológicos del Instituto,

garantizando una gestión oportuna, pertinente y respetuosa de las normas y estándares

internacionales de las tecnologías de información y comunicación.

Para facilitar la aplicación de las políticas y los procedimientos, han sido agrupados en tres

categorías: Seguridad, Usuarios y Gestión de TI.

Seguridad

Se enfoca a la protección de la infraestructura tecnológica y la información del Instituto. Para ello

existen una serie de estándares, políticas y procedimientos que ayudan a minimizar o evitar los

riesgos a la infraestructura o a la información.

Usuarios

Los usuarios son todos aquellos funcionarios que tienen relación y utilizan los recursos

tecnológicos como una importante herramienta de trabajo para poder cumplir con los objetivos

del Instituto.

Gestión de TI

La gestión de los Recursos Informáticos consiste en una adecuada administración de la plataforma

tecnológica para asegurar, a través de normas, políticas y procedimientos internacionales un buen

servicio al usuario y garantizar la seguridad de los recursos informáticos y la información del

Institucional.

Uso Interno

Índice

Seguridad............................................................................................................................................. 1

Política de conexión de acceso remoto .......................................................................................... 2

Procedimiento conexión de acceso remoto ................................................................................... 4

Política de respaldo de datos .......................................................................................................... 7

Procedimiento generación de respaldos de datos.......................................................................... 9

Política de prevención, detección y corrección de virus ............................................................... 14

Procedimiento prevención, detección y corrección de virus ........................................................ 16

Política de administración de claves de usuarios .......................................................................... 18

Procedimiento administración de claves ...................................................................................... 21

Política de control de acceso físico al Datacenter ......................................................................... 25

Procedimiento acceso físico al datacenter ................................................................................... 28

Procedimiento monitoreo de la humedad en el centro de datos................................................. 30

Procedimiento general en caso de incendio ................................................................................. 32

Procedimiento revisión de Bitácoras sistema SAP ........................................................................ 35

Procedimiento revisión de Bitácoras de Active Directory ............................................................ 38

Usuarios ............................................................................................................................................. 40

Política para el uso de dispositivos móviles .................................................................................. 41

Política de correo electrónico ....................................................................................................... 44

Política creación de cuentas de usuarios de servicios informáticos ............................................. 47

Procedimiento creación nuevas cuentas servicios informáticos. ................................................. 54

Procedimiento eliminación de cuentas servicios informáticos. .................................................... 57

Procedimiento creación cuenta de usuario de red ....................................................................... 60

Procedimiento creación cuenta de correo electrónico ................................................................. 63

Procedimiento creación cuenta de intranet ................................................................................. 65

Procedimiento eliminación de cuenta de usuario del correo electrónico .................................... 66

Procedimiento creación cuenta de usuario de sistema de información ...................................... 68

Procedimiento solicitud de mantenimiento de un sistema de información. ............................... 70

Procedimiento cambio de funciones de usuarios de servicios informáticos. ............................... 72

Procedimiento atención de solicitudes de soporte técnico .......................................................... 75

Procedimiento de administración de extensiones telefónicas ..................................................... 77

Uso Interno

Gestión TIC ........................................................................................................................................ 81

Política de clasificación de información ........................................................................................ 82

Política de cambios de emergencia ............................................................................................... 87

Procedimiento de cambios de emergencia ................................................................................... 88

Política para la gestión de activos de tecnología de información ................................................. 91

Procedimiento gestión de activos de tecnología de información ................................................. 93

Política de adquisición de equipos TI ............................................................................................ 97

Procedimiento adquisición de equipos TI ..................................................................................... 99

Procedimiento aplicación de actualizaciones de software ......................................................... 103

Procedimiento solicitud de sistemas nuevos o cambios en sistemas de información ............... 111

Anexos ............................................................................................................................................. 114

Formulario para creación de nuevas cuentas de usuarios informáticos ......... ¡Error! Marcador no

definido.

Formulario Eliminación de Servicios Informáticos ........................... ¡Error! Marcador no definido.

Glosario ........................................................................................................................................... 118

Uso Interno Página 1

Seguridad

Instituto Interamericano de Cooperación para la Agricultura Unidad de Tecnología de Información y Comunicación

Acceso remoto VPN IICA_UTIC_MPR_POL_AcsRem Versión 1 Última modificación: Noviembre 2010

Elaborado por: UTIC Aprobado por: Emmanuel Picado


Política de conexión de acceso remoto

Objetivo.

Definir normas para la conectividad desde equipos y/o redes del exterior hacia la red del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance.

Esta política aplica a todo usuario autorizado a utilizar el acceso por la Red Virtual Privada a la plataforma institucional.

Documentos relacionados.

Procedimiento acceso remoto por VPN. Política creación de cuentas de usuarios de los servicios informáticos.

Política de conexión de acceso remoto.

Las solicitudes para conexiones remotas deben ser extendidas al área de Soporte Redes, por la jefatura de la unidad correspondiente por OTRS. En el caso de las oficinas, el administrador de la oficina envía la solicitud por correo electrónico con copia al representante.

El área de soporte redes es el único autorizado en proveer los mecanismos para establecer las conexiones remotas.

El único servicio de acceso remoto permitido hacia la red institucional es a través de la red privada virtual (VPN).

Las conexiones de VPN hacia la red Institucional, deben controlarse a través de un nombre de usuario y clave, extendidas por la Unidad de Tecnología de información y Comunicación del IICA.

Toda estación conectada a la red del IICA, deberá estar claramente identificada con una dirección IP, y se deberá especificar un responsable de la conexión.

Cada usuario podrá tener una única conexión activa por VPN.

Los funcionarios que dentro del contexto de sus legítimas responsabilidades laborales, requieran el uso de otro servicio de conexión, pueden ser exceptuados de estas políticas, previa autorización de sus jefaturas directas y de la jefatura de la Unidad de Tecnología de información y Comunicación del IICA.

Es responsabilidad de los usuarios autorizados que utilicen el acceso remoto a las redes de la Institución, asegurarse de tener las mismas consideraciones como si estuvieran directamente conectados a la red de la Institución.


Acceso remoto VPN IICA_UTIC_MPR_POL_AcsRem Versión 1 Última modificación: Noviembre 2010



Todos los equipos que se conecten a las redes internas del IICA a través de conexión remota, deben tener su antivirus al día.

El usuario autorizado no deberá proporcionar información de acceso remoto a ninguna otra persona.

En caso de que se trate de conexiones temporales, se deberá indicar en la solicitud la fecha en que debe finalizar el permiso de acceso a la VPN institucional.


Acceso remoto VPN IICA_UTIC_MPR_PRD_AcsRem Versión 1 Última modificación: Noviembre 2010



Nombre Procedimiento conexión de acceso remoto

Objetivo Describir el procedimiento de acceso a través de la red privada virtual (VPN) para los usuarios del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a todos los usuarios que tengan cuenta de acceso a través de red privada virtual (VPN).

Actores UVPN: Usuario que requiere o posee VPN.

AFS: Administrador funcional del sistema.

EST: Encargado de soporte técnico.

ERT: Especialistas en redes y telecomunicaciones

ESTO: Encargado de soporte técnico en oficinas

Consideraciones Importantes

1. Si un usuario requiere conexión VPN, su jefatura debe autorizar y solicitar el acceso. La solicitud se realiza por medio del “help desk (OTRS)” en la cola denominada Soporte Redes ó correo electrónico (en el caso de las oficinas).

2. La instalación del VPN está a cargo del ERT ó del EST. 3. La conexión con el VPN se logra a través del aplicativo Cisco VPN.

Referencia documental

Política acceso remoto VPN

Política creación de cuentas de usuarios de los servicios informáticos

Glosario UTIC: Unidad de Tecnología de Información y Comunicación.

Sistema de información: aplicación o herramienta informática que le permite al usuario ingresar, almacenar, procesar y obtener información, de manera automatizada.

Herramienta automatizada de “Help Desk OTRS”: Sistema informático que se accede vía web donde se deben registrar todas las solitudes de trabajo de la Sede Central dirigidas a la UTIC.





N° Paso

Descripción Responsable

Instalación de VPN

10 Recibe la solicitud por medio del OTRS e instala el cliente VPN de Cisco al equipo del usuario solicitante.

ERT/EST

20 Configura los archivos que apliquen según se requiera (puede ser sólo conexión IICA, o ambas conexiones VPN IICA y VPN SAP).

ERT/EST

30 Se debe configurar el usuario de VPN de acuerdo a la aplicación ACS (Authentication Cisco Server) que está integrada con Active Directory (AD).

Se aplican los permisos al usuario de AD en caso de ser usuario de la Sede Central u Oficina Costa Rica.

En caso que se trate de un usuario externo autorizado, se crea un usuario en el ACS, debido a que no poseen usuario de AD.

ERT

40 Cierra solicitud en el OTRS. ERT

Instalación de VPN en Oficinas

50 Recibe solicitud por medio de correo electrónico del administrador de la oficina.

ERT

60 Se debe configurar el usuario de VPN de acuerdo a la aplicación ACS (Authentication Cisco Server), donde se crea el nuevo usuario.

ERT

70 Se instala y configura el archivo proporcionado por el ERT en el equipo del nuevo usuario, indicando además los datos creados para el ingreso del nuevo usuario.

ESTO

Utilización de acceso remoto

80 Para realizar la conexión al VPN por medio del aplicativo “Cisco VPN Client” debe seleccionar en el desktop y ejecutar el programa para su ingreso.

UVPN

90 Ejecuta el aplicativo “Cisco VPN Client” en su computadora, UVPN





N° Paso


selecciona la conexión deseada y luego ingresa la clave indicada.

Fin del procedimiento.

Controles

Conexión a VPN requiere clave, que es la misma clave de usuario de red (en el caso de las conexiones en la Sede Central y Oficina Costa Rica).

Conexión al VPN requiere solicitud.

Registros

Logs de acceso de los usuarios.


Respaldo de datos IICA_UTIC_MPR_POL_ResDat Versión 2 Última modificación: Agosto 2016



Política de respaldo de datos

Objetivo.

Establecer los puntos a considerar para aplicar el respaldo, salvaguardar y proteger el capital intelectual del IICA con el propósito de asegurar la continuidad operativa del Instituto, con el menor impacto posible.

Alcance.

La política considera el respaldo de los siguientes datos:

Sistemas de información y sus bases de datos que estén en uso y sean administrados por la sede central

Web (legacy)

Intranet

Servidor de archivos

Y cualquier otro que sea relevante para la institución.


Procedimiento generación respaldo de datos

Correo de Wilber Cocozza de fecha 17-mar-2011

Política de respaldo de datos.

Los respaldos realizados en el IICA son sistemáticos y permanentes. Estos respaldos, se efectúan tres veces a la semana (martes, jueves y viernes).

El área responsable de los respaldos corresponde a Redes y Telecomunicaciones, perteneciente a la Unidad de Tecnología de Información y Comunicación del IICA.

Los funcionarios del área de sistemas que tengan a su cargo algún servicio informático (intranet, internet, aplicaciones web) o un sistema de información deberán explicitar al encargado de generar los respaldos, cuáles son los archivos que deben ser respaldados, así como cualquier cambio que amerite ser considerado en el respaldo. Adicionalmente, cada tres meses el responsable de realizar el respaldo deberá corroborar la lista de archivos respaldados en conjunto con cada funcionario del área de sistemas. Dicho proceso se hará mediante correos electrónicos que el funcionario responsable de los respaldos deberá guardar como apoyo documental del proceso.

Los respaldos deben quedar debidamente rotulados. Las cintas de respaldos que se envían a la empresa de custodia deben estar rotuladas con el mes y año que corresponde. Los respaldos regulares, se les rotula con la fecha y se enumeran consecutivamente dependiendo de la cantidad de cintas.


Respaldo de datos IICA_UTIC_MPR_POL_ResDat Versión 2 Última modificación: Agosto 2016



Se deberán realizar pruebas de legibilidad una vez que finalice el proceso de respaldo, con el fin de verificar que las cintas se encuentran en buen estado, estas pruebas deberán registrarse en una bitácora creada para tales efectos.

Para cada respaldo periódico se debe establecer:

Información a respaldar. Periodicidad de las copias. Medio por el cual respaldar. Tipo de respaldo.

El almacenamiento de las copias de seguridad debe realizarse en una ubicación diferente de donde reside la información primaria. Al menos una vez al mes, se deben enviar las cintas a la empresa de custodia.

La ubicación de los respaldos, será en un lugar con acceso restringido y preferiblemente, con dispositivos de seguridad y de prevención de incendios. (Bóvedas, bancos, datacenter externos).

Los respaldos estarán en custodia por parte de la empresa contratada para este fin por un periodo máximo de tres años. Una vez cumplido ese plazo los respaldos serán devueltos por la empresa de custodia al funcionario encargado de la UTIC, quien los resguardará en una bóveda por un periodo no menor a un año hasta máximo 2 años.

Cuando se programen tareas extraordinarias donde se produzcan modificaciones o cambios de software y/o hardware, debe asegurarse que se hagan los respaldos correspondientes previos a ese trabajo.

Se deben realizar copias de seguridad de la información segura y completa. La periodicidad de estos respaldos es de tres veces por semana (martes, jueves y viernes).

La información y las cintas de respaldo deben tener un nivel apropiado de protección ambiental y físico. Cada cinta debe tener como máximos 20 sobreescrituras.

Se debe mantener un registro y la fecha de envío de la cinta a la empresa de custodia.

En caso de una recuperación de respaldos, se deberá registrar en la Bitácora de recuperación de respaldos, la siguiente información: Fecha, Solicitante, #Solicitud, Archivo(s) recuperado(s), Cinta utilizada.

Una vez que las cintas de respaldo alcancen las 20 sobreescrituras ó los cinco años de almacenamiento desde su primer uso, son candidatas a ser destruidas, para esto deben quedar debidamente registradas en el libro de Actas de Destrucción de Respaldo de Datos. Sin embargo por instrucciones superiores ninguna cinta será destruida, sino que serán almacenadas en la UTIC.


Respaldo de datos IICA_UTIC_MPR_PRD_ResDat Versión 2 Última modificación: Noviembre 2016



Nombre Procedimiento generación de respaldos de datos

Objetivo Describir el procedimiento de generación de respaldos de información del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a todos los sistemas y servicios que están bajo la responsabilidad de la Unidad de Tecnología de Información y Comunicación.

Actores AFS: Administrador funcional del sistema.

AR: Administrador de respaldos.

AUTIC: Asistente Unidad de Tecnología de Información y Comunicación.

JUTIC: Jefe Unidad de Tecnología de Información y Comunicación.

RAI: Representante Auditoría Interna.

Consideraciones importantes

1. Razón de respaldos. Se realizan los respaldos con el fin de restablecer los sistemas en caso de que haya algún inconveniente en el sistema o un error de usuario. Los respaldos que se realizan son completos, y no se realiza ninguno de modo incremental, esto en búsqueda de un mayor control sobre la información.

2. Capacidad máxima de almacenamiento. La máquina de respaldos está conectada al servidor de archivos. En esta misma máquina se respaldan el resto de servidores, correo, bases de datos de usuario, sistemas, Web e Internet.

3. Periodicidad de respaldos. Se realizan 3 respaldos a la semana (lunes, miércoles y viernes).

4. Toda solicitud de entrega de respaldos urgente (mismo día) a la empresa de custodia, tendrá un costo relacionado según el contrato establecido que deberá ser cubierto por la unidad solicitante.

5. Los dueños de la información son los que indican que debe ser respaldado (AFS y usuarios).

6. Cada servidor debe tener instalado un cliente con las características particulares que el agente debe interpretar a la hora del respaldo.

7. Cada 3 meses se le envía a los dueños de los datos un correo con la lista de la información que se respalda para que ésta sea corroborada por ellos.

8. Durante el proceso de recuperación de información no se pueden ejecutar respaldos.


Política de respaldo de datos


Sistema de información: aplicación o herramienta informática que le





permite al usuario ingresar, almacenar, procesar y obtener información, de manera automatizada.


N° Paso


Generación de respaldos de datos

10 Realiza el respaldo de la información definida previamente en las fechas establecidas (tres veces por semana lunes, miércoles y viernes).

AR

20

Rotula los respaldos, indicando la fecha y número y los resguarda en una bóveda que requiere clave para su ingreso, ésta información siempre estará visible de manera que se pueda controlar la cantidad de sobreescrituras.

En el caso del respaldo del último viernes de cada mes, se rotula con el año y mes correspondiente y adicionalmente se coloca un sticker con el código de barras que provee la empresa de custodia de cintas.

AR

30

Se debe enviar un correo a la empresa de custodia, con el formulario electrónico considerando los siguientes datos: nombre del responsable, nombre de la institución (IICA), fecha, código de barras y descripción. Adicionalmente, debe indicar (para uso interno) la cantidad de sobreescrituras que tiene cada cinta.

Este formulario lo provee la empresa de custodia de cintas.

AR

40 Se guarda una copia del archivo enviado como registro de la entrega. AR

50 Entrega el respaldo a los funcionarios de la compañía de custodia, previa validación de la identificación de los funcionarios y solicita la firma de recibido conforme del respaldo.

AR

Recuperación de respaldos de datos

60 Prepara la solicitud de respaldo a través del OTRS. Usuario/AFS

70 Recibe solicitud a través del OTRS. AR





N° Paso


Valida que se tenga el respaldo en las instalaciones, si el mismo se encuentra disponible, recupera la información indicada en la solicitud OTRS y la extrae a una ubicación en la que el usuario lo pueda utilizar. Se registra la recuperación en la bitácora llamada Bitácora de recuperación de respaldos, que se ubica en \\avalon\TIC\Sistemas\respaldos.

80

Si el respaldo se encuentra en la empresa de custodia, se coordina con el usuario la prioridad de la solicitud. Si es urgente se solicita el respaldo para el mismo día con la empresa de custodia, enviándoles el requerimiento de respaldo por medio de correo electrónico.

AR

90 En caso de que sea una solicitud urgente se debe coordinar con la unidad solicitante el pago de la tarifa a la empresa de custodia.

AUTIC

100 Si el archivo no es urgente, se coordina la entrega del respaldo con la empresa de custodia para el día que retiren del IICA el respaldo del mes en curso.

AR

110

Una vez entregado el respaldo por la empresa de custodia, carga el respaldo y lo extrae a una ubicación en la que el usuario lo pueda utilizar. Se registra la recuperación en la bitácora llamada Bitácora de recuperación de respaldos, que se ubica en \\avalon\TIC\Sistemas\respaldos.

AR

120 Se cierra la solicitud en el sistema OTRS.

Resguardo de respaldos de datos

130 Una vez superado el tiempo pautado de resguardo de las cintas y/o se cumpla el límite de almacenamiento en la empresa de custodio, las cintas son entregadas por la empresa de custodia al AR.

Empresa custodio

140

En caso de que la cinta no deba ser destruida, se almacena en bóveda. Estas cintas nunca vuelven a ser utilizadas para realizar respaldo. Se almacenan en bóveda hasta que superen el tiempo pautado de almacenamiento y se destruyen.

AR

Destrucción de respaldos de datos

150 Verifica la fecha del respaldo y la cantidad de sobreescrituras. En

AR





N° Paso


caso de que el respaldo deba ser destruido, se realiza convocatoria para el acto de destrucción de respaldos mediante correo electrónico, con al menos tres días de anticipación. En dicha convocatoria se invita a la jefatura de la UTIC y a la auditoría interna para que participen como fiscalizadores del acto.

160

El día y la hora establecidos en el paso anterior se realiza el acto de destrucción de respaldos, para el cual previamente se ha registrado el acta correspondiente con la siguiente información: fecha, cantidad de cintas a destruir, códigos (identificador) de cintas a destruir, motivo de la destrucción y cualquier comentario adicional que sea requerido.

AR

170 Los fiscales del acto revisan y comprueban la información contenida en el acta.

JUTIC, RAI

180 Se destruye cada una de las cintas registradas en el acta de manera que queden inutilizables.

AR

190

Los presentes firman el acta de destrucción, dando fe del cumplimiento del acto. En caso de que alguno de los funcionarios convocados no se presente, debe indicarse en el apartado denominado Comentarios Adicionales incluyendo además la fecha de la convocatoria. En el espacio para la firma se debe escribir NSP (No Se Presentó).

AR, JUTIC, RAI

Fin del procedimiento

Controles

Rotulación de respaldos de datos

Formulario de entrega a empresa de custodia

Registro de fechas en las cintas

Registros

El software deja un log de los respaldos que queda almacenado en el mismo (por fecha).





Este log indica:

- Fecha del respaldo de datos. - Detalle por cada servidor del resultado del respaldo de datos. - Si algún respaldo falla, queda registrada alguna observación.

Registro de cintas destruidas

Formulario de entrega a custodia


Prevención, detección y corrección de virus

IICA_UTIC_MPR_POL_PdCVir Versión 1 Última modificación: Noviembre 2010



Política de prevención, detección y corrección de virus Objetivo.

Implementar los procedimientos para prevenir, detectar y corregir los virus informáticos en la plataforma tecnológica del Instituto.

Alcance. Esta política aplica a todas las estaciones de trabajo (computadores y portátiles) conectadas o que deseen conectarse a la red del IICA.

Documento relacionado.

Políticas para el uso de recursos informáticos. Plan de continuidad de servicios informáticos. Procedimiento prevención, detección y corrección de virus.

Política de prevención, detección y corrección de virus. Toda computadora y portátil perteneciente al dominio de red del IICA, debe tener instalado el antivirus corporativo.

No se permitirá la instalación de antivirus que no sea el corporativo.

El área de Soporte Redes es el responsable de la administración del software antivirus corporativo y velará porque el proceso de actualización de versiones se lleve a cabo sin inconvenientes.

El área de Soporte TIC es el responsable de configurar correctamente el antivirus en las estaciones de trabajo.

El manejo del antivirus corporativo se debe realizar a través de consolas centralizadas para la administración, monitoreo y detección de cualquier amenaza de virus.

Se deben realizar las actualizaciones de software para la detección o reparación de virus. Las actualizaciones deben realizarse de lunes a viernes.

Se debe ejecutar la revisión de los computadores del dominio de red del IICA como medio de control preventivo, a lo menos, dos veces a la semana (días lunes y jueves).

Se debe dejar un registro de las actividades que se realizan en las visitas de mantenimiento.

Las máquinas que no tienen instalado sistemas operativos basados en tecnología Microsoft, están exentas de cumplir con la política prevención, detección y corrección de virus.

La tercera semana de cada mes se deberá generar un reporte de verificación de revisión de virus, que será la base para coordinar revisiones en las computadoras que presenten problemas asociados a virus. Estas revisiones se realizan a través de visitas, al menos, una vez al mes.



IICA_UTIC_MPR_POL_PdCVir Versión 1 Última modificación: Noviembre 2010



Deben existir planes de continuidad del negocio apropiados para la recuperación ante los ataques de código malicioso, incluyendo todos los datos y software necesarios de respaldo y las disposiciones para la recuperación de los servidores.

Se debe implementar un procedimientos para recolectar de forma regular información, tal como suscripción a las listas de correo y/o comprobación de los sitios web que brindan la información sobre nuevo código malicioso.

Se deben implementar procedimientos para verificar toda la información relativa al software malicioso y asegurarse que los boletines de alerta son precisos e informativos. Los responsables deberán asegurar que se diferencian los códigos maliciosos reales de los falsos avisos, usando fuentes calificadas, por ejemplo, revistas expertas, sitios de Internet fiables o proveedores de software contra código malicioso. Se deberá advertir a los usuarios sobre el problema de los falsos avisos de código malicioso y qué hacer en caso de recibirlos.



IICA_UTIC_MPR_PRD_PdCVir Versión 1 Última modificación: Noviembre 2010



Nombre Procedimiento prevención, detección y corrección de virus

Objetivo Describir el procedimiento de prevención, detección y corrección de virus para los usuarios del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a todos los usuarios que tengan acceso a los archivos del IICA.

Actores Usuario: Usuario.

EST: Encargado de soporte técnico.

EGAv: Encargado de gestión de antivirus.


1. Se trabaja con el antivirus corporativo de McAfee. La instalación del antivirus se maneja por medio de una consola centralizada que genera un agente para el dominio.

2. Las actualizaciones se realizan por medio de la consola centralizada, la cual es alimentada por el EGAv.

3. Se maneja un contrato de mantenimiento con el proveedor del antivirus corporativo (McAfee). Este contrato comprende licencias y mantenimiento correctivo.

4. El AV de McAfee tiene un componente de monitoreo en vivo que procura detectar a tiempo y detener la incidencia de virus en las computadoras de los usuarios.

5. Las actualizaciones se deben ejecutar de lunes a viernes. La consola descarga las actualizaciones a las 9:00 am y se empiezan a distribuir a los equipos a las 10:00 am. La descarga de las actualizaciones del AV se da de forma automática.

6. En caso de presentarse algún archivo de actualizaciones extra, el proveedor enviará un aviso por correo electrónico para informar sobre la existencia de la nueva actualización.


Política prevención, detección y corrección de virus.

Plan de continuidad de los servicios informáticos.



AV: Antivirus

McAfee: Proveedor del antivirus corporativo.



IICA_UTIC_MPR_PRD_PdCVir Versión 1 Última modificación: Noviembre 2010



N° Paso


Instalación de AV en equipos del dominio

10 Realizar la instalación de antivirus a través del agente, el cual tiene las actualizaciones, parches, antispyware y políticas configuradas. Esto se debe efectuar una vez que se configura un nuevo equipo o cuando un funcionario realiza cambio de equipo.

EST

20 Llevar a cabo revisión de la versión del archivo DAT que contiene la base de datos de virus. Con esto se valida que las actualizaciones estén al día.

EGAv

Corrección de virus.

30 El usuario genera una solicitud a través del OTRS en caso de que sospeche la presencia de virus en su equipo de trabajo.

Usuario

40 Recibe solicitud por medio del OTRS. EST

50 Procede con la revisión y eliminación del virus en el equipo. EST

60 En caso de que no pueda eliminar el virus, escala solicitud al EGAv para que solucione el problema.

EST

70 Una vez solucionado el incidente, se cierra la solicitud en OTRS. EST/ EGAv


Controles

Contrato de mantenimiento mensual con McAfee.

La consola es fácil de recuperar si el servidor tiene problema.

La descarga de las actualizaciones del antivirus es automático

Registros

Registros varios generados por la consola: actualización de agentes, versiones del software del AV, computadoras más infectadas, infecciones más comunes, gráficos por día de problemas detectados o removidos.

Prueba de mantenimiento de la consola - hoja de servicio de la empresa (a través de visitas del soporte de McAfee).

Registros de virus detectados con otros aplicativos.


Administración de claves IICA_UTIC_MPR_POL_AdmCla Versión 1.1 Última modificación: Noviembre 2016



Política de administración de claves de usuarios Objetivo. Especificar mecanismos de seguridad para la creación, protección y frecuencia de cambio de las claves de usuario y garantizar una administración apropiada de la plataforma tecnológica del Instituto.

Alcance. Incluye a todo el personal que tiene bajo su responsabilidad alguna clave de: usuario de dominio (incluye clave de administración de servidores), administración de equipos de comunicaciones, correo electrónico y aplicativos adquiridos por el instituto.


Políticas para el uso de recursos informáticos Políticas para la creación de cuentas de usuarios de servicios informáticos Procedimiento para administración de claves

Política de administración de claves. Se debe realizar cambio de clave por parte de los usuarios posterior al primer ingreso en el computador y/o sistema que corresponda, a excepción de las aplicaciones que no dispongan de esa funcionalidad.

El usuario debe cambiar las claves cada tres meses o cuando se sospeche que alguien conoce la contraseña. Esta política aplica para la clave de dominio de red, y SAP.

Se permite una excepción a esta norma, para aquellos casos gerenciales que brinden una solicitud expresa a la jefatura de la Unidad. Se registrará el usuario, cargo responsable de aplicar el cambio y una observación.

En la medida de lo posible, se recomienda que el usuario no utilice la misma clave para las cuentas de la institución y para otras cuentas que no tengan relación con la misma. Se recomienda no utilizar la misma clave para acceder a diferentes cuentas.

El usuario será responsable por el mal uso que se haga de su clave cuando de forma voluntaria o involuntaria comparta sus claves con terceros.

Se deben habilitar accesos temporales en el caso de usuarios que realicen suplencias en forma temporal.

Se recomienda no activar las características de recordatorio de claves que traen las aplicaciones y/o navegadores web, para evitar una eventual suplantación de identidad. Por ejemplo, si un usuario tiene acceso al computador de su superior, quien a su vez utiliza el recordatorio de claves, podría acceder a la intranet (usurpando la identidad de su superior) y llenar el formulario de websense para auto-asignarse permisos para visitar sitios web restringidos. En este caso se verá perjudicado tanto el usuario que usurpa el computador así como el usuario (superior) que utiliza el recordatorio de claves del navegador que utilice.





El usuario no debe revelar datos sobre la forma o estructura de sus claves.

El usuario no debe escribir sus claves en papel.

El usuario no debe usar claves antiguas o ejemplos dados como claves. Cuando el usuario define una nueva clave o contraseña, la misma no podrá ser igual a las últimas cinco claves anteriormente utilizadas (histórico de claves).

La clave debe estar configurada para aceptar un mínimo de 8 caracteres. 1

Siempre que los niveles de seguridad de los sistemas lo permitan, la clave debe contener caracteres alfabéticos y numéricos.

Se hará distinción entre mayúsculas y minúsculas.

El acceso a los sistemas será bloqueado después del tercer intento de acceso denegado.2

Los bloqueos por intento fallido de conexión serán levantados solo por los administradores de sistemas.

En caso que el usuario solicite un cambio de clave, éste no podrá modificarla en los siguientes 4 días, posteriores al ingreso de la nueva clave.

El usuario deberá bloquear (Ctrl+Alt+Supr) la sesión de trabajo cada vez que deba ausentarse del escritorio para evitar el mal uso de sus privilegios.

Las claves de administradores de la plataforma tecnológica deben estar resguardadas en un sobre sellado almacenado en la caja fuerte.

Las claves de administradores de servidores deben ser cambiadas cada 90 días o cuando sea abierto el sobre sellado almacenado en la caja fuerte por una situación de emergencia.

Las claves del administrador de dominio y de equipos de comunicación deberán ser modificadas una vez al año.

Las claves de administradores de los sistemas deber ser cambiadas al menos una vez al año o según las necesidades de cada sistema.

Estándar para desarrollo de aplicaciones

Los especialistas en tecnología de información y comunicación encargados del desarrollo de aplicaciones deben asegurar que sus programas contengan las siguientes precauciones:

Los accesos a los sistemas deben controlarse a través de un nombre de usuario.

1 A excepción de las claves para intranet cuando no se pueda utilizar la clave de red para el ingreso. 2 En el caso de SAP, al tercer intento fallido cancela la sesión y al quinto intento fallido bloquea el usuario.





El almacenamiento de las claves se debe realizar utilizando mecanismos de encriptación resguardando la confidencialidad e integridad de las mismas.

La asignación de identificaciones de usuario (IDs) y contraseñas se debe realizar de forma individual con el fin de establecer responsabilidades.

Los usuarios podrán seleccionar y cambiar sus propias contraseñas e incluir un procedimiento de confirmación para evitar errores al introducirlas.

Los usuarios deberán utilizar contraseñas válidas.

Los usuarios deberán modificar sus contraseñas periódicamente de acuerdo a lo que indique esta política.

Los usuarios deberán modificar su contraseña temporal en su primera conexión.

Los sistemas deberán mantener un registro de las anteriores contraseñas utilizadas, e impedir su reutilización.

Los sistemas no mostrarán en pantalla la contraseña cuando ésta se introduce en el proceso de autenticación.

Los sistemas deberán almacenar los archivos de contraseñas en lugares diferentes de los datos del sistema de aplicaciones.

Los sistemas deberán almacenar y transmitir las contraseñas en formatos protegidos (por ejemplo, cifradas).

Acceso remoto

El acceso a las redes del Instituto en forma remota, debe ser controlado usando autenticación por clave (a través de la red privada virtual, VPN). La autenticación de usuarios IICA es en el “active directory” y el personal externo se autentica mediante “authentication cisco server (ACS)”.


Administración de claves IICA_UTIC_MPR_PRD_AdmCla Versión 2 Última modificación: Noviembre 2016



Nombre Procedimiento administración de claves

Objetivo Definir los pasos para la administración de claves de las cuentas de acceso, servicios y recursos de información de manera segura.

Alcance Todos los usuarios que son responsables sobre una cuenta de acceso, servicios y recursos de información del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Actores ARH: Administrador de SIRH

AS: Administrador de SAP.

ACR: Administrador de cuentas de red.

Usuario: Usuario de sistema.

ABI: Administrador base de datos Intranet.

ECI: Encargado de cuentas de Intranet.

ADS: Administrador de servidores, sistemas y bases de datos.

JUTIC: Jefe de la Unidad de Tecnología de Información y Comunicación.


Política de administración de claves

Políticas creación de cuentas de usuarios de servicios informáticos

Políticas para el uso de recursos informáticos

Glosario UTIC: Unidad de Tecnologías de Información y Comunicación.


Herramienta automatizada de Help Desk OTRS: Sistema informático que se accede vía web donde se deben registrar todas las solitudes de trabajo de la Sede Central dirigidas a la UTIC.

N° Paso


Solicitud cambio de clave de usuario de dominio (clave de Windows)

10 El usuario tiene las siguientes opciones para cambio de clave de Usuario





N° Paso


usuario de dominio:

Caso 1: Envia un correo electrónico al área de soporte correo para solicitud de cambio de clave.

Caso 3: Modifica su clave directamente en el sistema Windows.

20 Caso 1:

Se registra la solicitud en la bitácora llamada bitácora cambio de contraseña de dominio (\\gaia\DTIC\Bitacoras)., especificando el propietario de la solicitud.

ACR

30 Se realiza el cambio en active directory asignando una clave inicial. Una vez modificada la información, se entrega la nueva clave por correo electrónico.

ACR

40 Al primer registro del usuario en sistema se solicita el cambio de clave.

La nueva clave ingresada por el usuario debe cumplir con las directrices de la política de administración de claves.

ACR

50 Caso 3:

El usuario presiona las teclas ctrl+alt+delete, selecciona la opción cambio de clave, posteriormente aparece una pantalla que solicita la antigua clave, la nueva clave y la confirmación de la misma.

El usuario debe asegurarse que se encuentra conectado en el dominio IICA-SC y presiona aceptar.

Usuario

Solicitud clave de usuario de dominio sin expiración (clave de Windows)

60 El usuario gestiona una solicitud a través de la herramienta help desk (OTRS)

70 Se responde el ticket OTRS indicando que se aplicará el cambio.

80 Se realiza el cambio en active directory

90 Se registra el cambio en la hoja de registro correspondiente.

100 Se cierra el caso en la herramienta de help desk (OTRS).

Solicitud de cambio de clave de correo electrónico





N° Paso


110 Los usuarios pueden solicitar el cambio de clave de correo por medio de una llamada telefónica al área de soporte.

Usuario

130 Se realiza el cambio asignando una clave inicial. Una vez modificada la información, se entrega la nueva clave por teléfono.

ACR

140 Al primer registro del usuario en sistema se solicita el cambio de clave.

La nueva clave ingresada por el usuario debe cumplir con las directrices de la política de administración de claves.

ACR

Solicitud de cambio de clave en SAP

150 El usuario tiene las siguientes opciones para cambio de clave en el sistema SAP:

Caso 1: Solicitud a través de la herramienta help desk (OTRS).

Caso 2: Solicitud a través de correo electrónico para usuarios que no están en Costa Rica.

Caso 3: Modifica su clave directamente en el sistema SAP.

Usuario

160 Caso 1 y 2:

Modifica la clave del usuario, entregando una clave inicial. Proporciona la información de la nueva clave directamente al usuario por correo electrónico, en el caso de oficinas, o por medio del OTRS.

AS

170 Caso 3:

El usuario debe ingresar al aplicativo SAP, seguidamente, debe ingresar el nombre de usuario y clave de acceso en la pantalla de acceso del sistema. Posterior, debe hacer clic en la opción “clave acceso nueva”. Al hacer clic, se activa una nueva pantalla donde debe colocar la nueva clave de acceso y la confirmación de la misma, esta clave la debe colocar en letras mayúsculas.

Usuario

180

Caso 1 y 2:

Al primer registro del usuario en el sistema se solicita el cambio de clave, el sistema no admite clave nula.

Usuario

190 Caso 1, 2 y 3:

La nueva clave ingresada por el usuario debe cumplir con las directrices indicadas en el documento Políticas para la creación de

Usuario





N° Paso


cuentas de usuarios de servicios informáticos.

200 Si aplica, se cierra el caso en la herramienta help desk (OTRS). AS

Gestión de claves de administrador de servidores, sistemas y bases de datos.

210 Acorde a la periodicidad correspondiente modificar las claves de acceso.

ADS

220 La clave de administración de servidores, sistemas y bases de datos se debe guardar en un sobre cerrado, rotulado y almacenado en la caja fuerte (de forma individual).

ADS

230 En el caso de que los ADS y/o su respaldo funcional no estén disponibles, el encargado de manipular las claves que se encuentran en los sobres sellados en la caja fuerte es el Jefe de la Unidad de Tecnologías de Información y Comunicación o en su defecto a quien este designe.

JUTIC


Controles Active directory

Correo electrónico SAP

Controles propios del sistema x x x

Registro Active directory

Correo electrónico SAP

Solicitud correo electrónico x x

Cambio de clave (log) x

Hoja de registro de usuarios sin expiración contraseña X


Acceso físico al datacenter IICA_UTIC_MPR_POL_AcFiDc Versión 2 Última modificación: Noviembre 2016



Política de control de acceso físico al Datacenter Objetivo.

Establecer los aspectos básicos que deben ser considerados para el control de acceso al Datacenter del Instituto y garantizar el resguardo de la información y la continuidad de los servicios de red bajo estrictas medidas de seguridad.

Alcance

Esta política aplica a todos quienes trabajen en el IICA, personal externo y visitas autorizadas, a la hora de ingreso al datacenter

Documentos relacionados

Procedimiento del acceso físico al datacenter.

Procedimiento Monitoreo de la humedad en el centro de datos

Procedimiento general en caso de incendio

Memorandum de ingreso de visitantes y otros SC/DAF-171.

Manual de Seguridad Interna de la Sede Central

Políticas generales de acceso físico al datacenter.

El perímetro de seguridad del área del datacenter deberá estar claramente definido, la ubicación y la resistencia de cada uno de los perímetros dependerán de los requisitos de seguridad de los activos dentro del perímetro y de los resultados de una evaluación de riesgos.

El perímetro del datacenter deberá tener solidez física (por ejemplo no debe tener zonas que puedan derribarse fácilmente); los muros externos del lugar deben ser sólidos y todas las puertas exteriores deberán estar convenientemente protegidas contra accesos no autorizados, mediante mecanismos de control, por ejemplo, barreras, alarmas, cerraduras, etc., puertas y ventanas deberán estar bloqueadas cuando se encuentren descuidadas.

Cualquier visitante incluyendo funcionarios, personal de contrato y empleados de terceros deberán utilizar algún tipo de identificación visible.

Los derechos de acceso a las áreas seguras deben ser regularmente revisados y actualizados, y revocados cuando sea necesario.

Se deben tomar en cuenta las regulaciones y normativas pertinentes en materia de salud y seguridad vigentes.

Se debería tomar en consideración cualquier amenaza de seguridad presentada por las instalaciones vecinas, por ejemplo, incendios, inundaciones o explosiones.

Solo personal autorizado puede ingresar al datacenter, el acceso de personal externo al datacenter debe quedar registrado, detallando motivo, nombre y apellido, identificación de la empresa, fecha, hora de entrada/ salida y quien autoriza el ingreso.

El ingreso al datacenter debe tener acceso restringido, mediante autenticación por clave y tarjeta de acceso.





La clave de ingreso al datacenter será definida por el usuario junto con encargado de seguridad perimetral directamente en el sistema de acceso al datacenter. Esta clave puede tener hasta un máximo de 6 dígitos.

Las tarjetas de control de acceso son intransferibles, por lo que queda estrictamente prohibido el préstamo o intercambio de las mismas entre personal de la Unidad de Tecnología de Información y Comunicación del IICA.

En caso de pérdida de la tarjeta de control de acceso, el funcionario de la UTIC deberá enviar una solicitud por “help desk” a Soporte Redes, con el fin de informar y otorgar una nueva tarjeta de acceso.

Las tarjetas de visita, entregadas por el oficial de seguridad, deben estar visibles durante la permanencia del personal externo en la institución.

El datacenter debe estar protegido por puertas de seguridad que resistan fuego, intentos de ingreso a la fuerza, etc.

La puerta del datacenter debe estar equipada con dispositivos que la cierren automáticamente.

Cuando un empleado de la Unidad de Tecnología de Información y Comunicación del IICA deja de prestar funciones debe devolver la tarjeta de control asignada y se debe eliminar la clave de acceso al datacenter.

Los materiales peligrosos o combustibles deberán ser almacenados a una distancia prudente de al menos 25 mts de un área segura. Los suministros a granel tales como los materiales de oficina no deben almacenarse dentro de un área segura.

El equipo de reserva y los medios de respaldo deberán estar ubicados a una distancia prudente para evitar daños producto de un desastre que afecten al emplazamiento principal.

No es permitido el ingreso de comidas o líquidos al datacenter ya que puedan dañar la integridad de los equipos.

No se permite fumar dentro del datacenter.

El datacenter debe tener detectores de humo y equipo para mitigar incendios.

No se permiten las conexiones en cadena de varios PDU (regletas). Esto aumenta el riesgo de ocasionar un incendio y una potencial sobrecarga de los circuitos eléctricos, resultando en la pérdida de energía del PDU o del circuito completo.

Todos los elementos de soporte, tales como electricidad, abastecimiento de agua, aguas residuales, calefacción/ventilación, y aire acondicionado deberán ser adecuados para los sistemas que están apoyando. Los elementos de soporte deberán ser examinados regularmente y probados adecuadamente de manera de asegurar su funcionamiento apropiado y reducir cualquier riesgo de mal funcionamiento o falla.

Deberá existir un suministro eléctrico apropiado conforme con las especificaciones del fabricante del equipo.





Se deberá contar con una fuente de energía ininterrumpida (UPS) para asegurar el correcto apagado o el funcionamiento continuo del equipo que soporta las operaciones críticas del negocio.

Los equipos de UPS y los generadores se deberían inspeccionar regularmente para asegurar que tienen la capacidad requerida y probarlos de acuerdo con las directrices del fabricante.

El equipo de telecomunicaciones deberá estar conectado con el proveedor al menos a través de dos rutas distintas para prevenir fallas en el servicio de una de las rutas de conexión imposibilitando los servicios de voz. Los servicios de voz se deberían adecuar para alcanzar los requisitos legales locales para comunicaciones de emergencia.

Se deberán adoptar controles para reducir al mínimo el riesgo de amenazas físicas potenciales, por ejemplo hurto, fuego, explosivos, humo, inundaciones (o falta de suministro de agua), polvo, vibraciones, efectos químicos, interferencias en el suministro eléctrico, interferencia de las comunicaciones, radiación electromagnética y vandalismo.

Las condiciones ambientales, tales como temperatura y humedad, deberán ser supervisadas para verificar que las mismas no afectan negativamente el funcionamiento de las instalaciones de procesamiento de la información. Esta supervisión se realizará de forma diaria al inicio y al final de la jornada laborar y se registrará la temperatura y la humedad relativa reportada por el equipo de monitoreo.

Se deberán colocar pararrayos sobre todos los edificios y se deberán aplicar filtros de protección contra rayos a todas las líneas entrantes de energía y de comunicaciones.

Se deberán utilizar marcas claramente identificables en cables y equipo para reducir al mínimo los errores de manejo, tales como conexiones accidentales erróneas de los cables de red.

Se deberá utilizar una lista documentada de las conexiones para reducir la posibilidad de errores.

El equipo que se encuentra dentro del datacenter deberá recibir el mantenimiento necesario de acuerdo a los niveles de servicio establecidos en el contrato de mantenimiento.

Sólo el personal de mantenimiento debidamente autorizado podrá realizar reparaciones y mantenimiento a los equipos.

Se deberán mantener registros de todos los fallos, reales o sospechas, así como de todo el mantenimiento preventivo y correctivo;

Se deberán implementar los controles adecuados en los casos en que sea necesario dar mantenimiento a equipos que contengan información confidencial, de manera que la información se mantenga convenientemente resguardada.

Se deberá cumplir con todos los requisitos impuestos por pólizas de seguros.


Acceso físico al datacenter IICA_UTIC_MPR_PRD_AcFiDc Versión 1 Última modificación: Noviembre 2010



Nombre Procedimiento acceso físico al datacenter

Objetivo Definir las reglas de acceso al datacenter del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Personal interno que no tenga permiso de acceso al datacenter y personal externo que requiera acceso al datacenter.

Actores SR: Soporte Redes.

Usuario: Personal que requiera acceso al datacenter.

JUTIC: Jefe de unidad de Tecnología de Información y Comunicación.

AUTIC: Asistente de unidad de Tecnología de Información y Comunicación.

EO: Empresa de outsourcing.


1. El acceso a la sala del datacenter está restringido solo al personal responsable de los sistemas, cuyo acceso está controlado por clave y tarjeta de acceso

2. El personal de redes deberá acompañar a personal o visitantes externos mientras se mantengan en el área del datacenter

3. Cuando un funcionario de la UTIC deja de prestar funciones en la institución la tarjeta de acceso la debe devolver a la asistente de la Unidad de Tecnología de Información y Comunicación o al encargado de la seguridad perimetral del datacenter.

4. Referencia al memorándum de acceso de visitas a las instalaciones del IICA SC/DAF-171.


Política de Acceso físico al Data Center.

Memorándum de ingreso de visitantes y otros. SC/DAF-171.


N° Paso


Acceso al área del datacenter.

10 El personal del IICA que no pertenece a la unidad de informática, visitantes, empresas de outsourcing, deberán solicitar acceso a los funcionarios del área de TI para el ingreso al área previa al datacenter.

Usuario

20 Esta solicitud se realiza a través de la asistente de la Unidad de Tecnología de Información y Comunicación hacia el personal de

AUTIC


Acceso físico al datacenter IICA_UTIC_MPR_PRD_AcFiDc Versión 1 Última modificación: Noviembre 2010



N° Paso


soporte redes.

30 Soporte redes debe validar el acceso del funcionario y/o empresa de outsourcing.

SR

40 En caso de aprobar el acceso, personal de soporte redes, le solicita a la persona por ingresar al datacenter, que se registre en el control de acceso (especificando nombre completo, fecha, hora, identificación de la empresa y motivo de visita).

SR

50 Se permite el ingreso del externo, quien durante su permanencia en el datacenter estará acompañado por personal de soporte de redes.

SR

60 Una vez finalizada la visita, personal de soporte de redes debe registrar la salida del visitante en la hoja de registro correspondiente.

EO

70 El encargado de revisar los registros de la hoja de visita es el jefe de la unidad de informática y sistemas de información.

JUTIC


Controles

Tarjeta de control de acceso (área de informática)

Tarjeta de control de acceso + clave (datacenter)

Registro del software de las puertas

Registros

Hoja de registro del visitante.

Logs de acceso (registro software de las puertas).


Monitoreo de la humedad en el centro de datos

IICA_UTIC_MPR_PRD_AcFiDc Versión 1 Última modificación: Enero 2018



Nombre Procedimiento monitoreo de la humedad en el centro de datosObjetivo Describir el procedimiento de monitoreo de humedad del datacenter del

Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica al datacenter del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Actores SR: Soporte redes.

JUTIC: Jefe de unidad de Tecnología de Información y Comunicación.


1. El acceso a la sala del datacenter está restringido solo al personal responsable de los sistemas, cuyo acceso está controlado por clave y tarjeta de acceso.

2. El rango más adecuado de humedad es entre el 20% y el 80% (rango recomendado por ICREA-STD-131-2015).

3. Si la humedad está fuera de los rangos permitidos deberá notificarse de inmediato al personal de mantenimiento para su revisión.


Política de Acceso físico al Data Center. ICREA-STD-131-2015: http://www.icrea-international.org


N° Paso


Registro humedad centro de datos

10 Diariamente se verifican los datos de humedad en la consola del aire acondicionada del centro de datos .

SR

20 Se registran los datos de humedad en la bitácora llamada bitácora humedad centro datos (\\gaia2\DTIC\Bitacoras). Fecha, hora, porcentaje de humedad.

SR

30 El encargado de revisar los registros es el jefe de la unidad de informática y sistemas de información.

JUTIC


Controles

Tarjeta de control de acceso (área de informática)

Registro del software de las puertas


Monitoreo de la humedad en el centro de datos

IICA_UTIC_MPR_PRD_AcFiDc Versión 1 Última modificación: Enero 2018



Registros

Hoja de registro del visitante.

Logs de acceso (registro software de las puertas).



IICA_UTIC_PGCI Versión 1 Última modificación: Agosto 2016



Nombre Procedimiento general en caso de incendio Objetivo Definir las acciones a realizar de forma coordinada evitando

improvisaciones en caso de un eventual incendio.

Alcance Sistema de alarma contra incendios de la UTIC

Actores JUTIC: Jefe de unidad de Tecnología de Información y Comunicación.

OFSEG: Oficiales de Seguridad del Instituto.

PETIC: Personal de la Unidad


1. Se velará por la seguridad personal y, a continuación, por minimizar los efectos materiales en caso de un incendio

2. El mantenimiento de los extintores es responsabilidad de la División de Servicios del Instituto.

3. El IICA cuenta con un procedimiento general en caso de incendio. Referencia documental


N° Paso


Pasos a seguir en caso de fuego en horas laborables

10 En el caso de que se detecte fuego y el sistema de alarma de incendio no haya puesto en marcha las sirenas de alarma, se deben activar los pulsadores manuales de alarma de incendio que el sistema dispone en todas las salidas de las áreas.

PETIC

20 Cuando se escuchen las sirenas de alarma, el personal deberá abandonar el área de trabajo inmediatamente, utilizando la salida de emergencia. Una vez en el exterior se comprobará que todos los miembros están localizados.

PETIC

30 El Jefe de la Unidad o la persona encargada en ese momento, procederá a coordinar la extinción del fuego, para lo cual se utilizarán los extintores portátiles que se encuentran en cada uno de los módulos de la Unidad.

JUTIC

PETIC

40 El Jefe de la Unidad o la persona encargada en ese momento, notificará a las autoridades del Instituto.

JUTIC

Pasos a seguir en caso de fuego en horas no laborables

60 Cuando se escuchen las sirenas de alarma, se notificará al Jefe de UTIC y a las autoridades del Instituto sobre el incidente.

OFSEG






N° Paso


70 Utilizando el código de acceso brindado por el Jefe de la Unidad, en caso de ser posible, se ingresará para tratar de extinguir el fuego utilizando los extintores portátiles.

OFSEG

80 El Jefe de la Unidad o la persona encargada en ese momento, coordinará las acciones a seguir.

JUTIC

Pasos para utilizar un extintor portátil

90 Hale el pasador que se encuentra en la manija PETIC

OFSEG 100 Tome la manguera y diríjala a la base del fuego, sin asumir riesgo alguno

110 Apriete la manija para que comience a salir el elemento extintor

120 Si el fuego persiste, deberá trasladarse a un lugar seguro e informar la situación.

Pasos a seguir una vez extinto el fuego o falsa alarma

130 Para silenciar las sirenas del sistema contra incendio en caso de emergencia o falsa alarma presione dos veces la tecla F1 o F5 en el panel de alarma de incendios.

PETIC

OFSEG

140 El Jefe de la Unidad coordinará una revisión de los equipos y área física afectada e indicara los pasos a seguir para normalizar labores

JUTIC

150 Se realizará un informe de lo sucedido.


Planos de los recursos contra incendios

Centro de datos

Área de

Desarrollo

Sala de

reuniones

Cocina y bodega

Recepción

y oficinas






Leyenda

Extintor portátil

Detector de humo

Pulsadores manuales de alarma de incendio

Panel de alarma de incendios

Salida de emergencia


Revisión de bitácoras sistema SAP IICA_UTIC_REV_BIT_SAP Versión 1 Última modificación: Mayo 2016



Nombre Procedimiento revisión de Bitácoras sistema SAP Objetivo Describir el procedimiento de revisión de las bitácoras de eventos y Jobs en

el sistema SAP.

Alcance Este procedimiento aplica para el sistema de aplicación SAP.

Actores ASI: Administrador de Sistema de Información


Se revisarán las bitácoras de:

1. Eventos de seguridad (transacción SM20) 2. Eventos en línea (transacción SM21). 3. Vaciados de memoria (transacción ST22) 4. Ejecución de Jobs (transacción SM37)



N° Paso


Revisión de eventos de seguridad

10 Quincenalmente (16 y primer día del mes o día hábil posterior más cercano) se revisa la bitácora de seguridad del sistema en la transacción SM20, indicando el período de evaluación (quincena), desde las 00:00 horas hasta las 24:00 horas. Se seleccionan los eventos: Entr.sist.interact., Entrada sist.RFC/CPIC, Llamada función RFC y Modif.maestro usuario, para el mandante 500 y todos los usuarios (*). En la pestaña de Edición debe cambiarse el número de páginas a 5000 ya que las entradas son bastantes

ASI

20 Se debe exportar el reporte de eventos a una hoja electrónica para revisión detallada.

ASI

30 Se revisa el reporte para identificar incidencias de seguridad que se pudieron haber presentado y que ameriten investigación.

40 Se registra el resultado de la revisión en la bitácora llamada bitácora de logs IEP (\\gaia\DTIC\Bitacoras\Bitacoras SAP\Bitacora logs IEP ). Se debe registrar la fecha a la que corresponde el análisis, el tipo de bitácora, los mensajes relevantes y acciones tomadas en caso de ser necesario.

ASI





Revisión de eventos en línea

50 Los primeros días de cada semana se revisa la bitácora de eventos en la transacción SM21, indicando el período de evaluación (lunes a domingo de semana anterior), desde las 00:00 horas hasta las 24:00 horas. Se dejan seleccionados los parámetros estándar (Formas de mensajes (todas)).

ASI

60 Se debe exportar el reporte de eventos a una hoja electrónica para revisión detallada.

ASI

70 Se revisa el reporte para analizar los eventos que se presentaron e identificar aquellos que ameriten investigación.

ASI

80 Se registra el resultado de la revisión en la bitácora llamada bitácora de logs IEP (\\gaia\DTIC\Bitacoras\Bitacoras SAP\Bitacora logs IEP ). Se debe registrar la fecha a la que corresponde el análisis, el tipo de bitácora, los mensajes relevantes y acciones tomadas en caso de ser necesario.

ASI

Revisión de vaciados de memoria

90 El último día hábil de cada semana se revisa la bitácora de vaciados de memoria en la transacción ST22, indicando el período de evaluación (sábado a viernes de semana actual), desde las 00:00 horas hasta las 24:00 horas. Se seleccionan todos los usuarios, quitando el que se está usando y que aparece en el campo Usuario

ASI

100 Se revisa el reporte para analizar los vaciados que se presentaron e identificar aquellos que ameriten investigación. Estos vaciados también se pueden identificar en las bitácoras de eventos y en los informes mensuales generados por los responsables del hospedaje del sistema.

ASI

Se registra el resultado de la revisión en la bitácora llamada bitácora de logs IEP (\\gaia\DTIC\Bitacoras\Bitacoras SAP\Bitacora logs IEP ). Se debe registrar la fecha a la que corresponde el análisis, el tipo de bitácora, los mensajes relevantes y acciones tomadas en caso de ser necesario.

ASI

Revisión de ejecución de Jobs propios

110 Los días martes y jueves de cada semana se revisa la bitácora de Jobs propios en la transacción SM37. Se indican todos los Jobs (*) para el usuario ADMSC, para el período de evaluación: jueves a lunes o martes a miércoles de cada semana. Los parámetros para Status de Jobs, se dejan con el estándar.

ASI

120 Se revisa el reporte para verificar que los Jobs programados terminaron satisfactoriamente. En caso que alguno no haya concluido satisfactoriamente se hará la investigación necesaria.

ASI





130 Se registra el resultado de la revisión en la bitácora llamada bitácora de logs IEP (\\gaia\DTIC\Bitacoras\Bitacoras SAP\Bitacora logs IEP ). Se debe registrar la fecha a la que corresponde el análisis, el tipo de bitácora, y las acciones tomadas en caso de que un Job no haya terminado satisfactoriamente.

ASI


Controles

Bitácora de eventos de seguridad

Bitácora de eventos del sistema

Bitácora de vaciados de memoria

Bitácora de ejecución de jobs

Registros

Bitácora de revisión de logs


Revisión de bitácoras de Active Directory

IICA_UTIC_REV_BIT_ACTDIR Versión 1 Última modificación: Enero 2016



Nombre Procedimiento revisión de Bitácoras de ActiveDirectory

Objetivo Describir el procedimiento de revisión de las bitácoras de eventos para servicios de Active Directory.

Alcance Este procedimiento aplica para Windows Server.

Actores ASI: Administrador de Sistema de Información


Se revisarán las bitácoras de:

4. Security

5. Directory Service 6. DFS Replication



N° Paso


Revisión de eventos de seguridad

10 Quincenalmente (16 y primer día del mes o día hábil posterior más cercano) se revisa la bitácora de seguridad del sistema Windows en el Event Viewer.

ASI

20 Se filtra la bitácora de Security por eventos “Audit Failure” y se examinan las dos últimas semanas.

ASI

30 Se filtra la bitácora de Directory Service por eventos “Error” y “Critical” y se examinan las dos últimas semanas.

ASI

40 Se filtra la bitácora de DFS Replication por eventos “Error” y “Critical” y se examinan las dos últimas semanas.

ASI

50 Se registra el resultado de la revisión en la bitácora llamada Bitacora de logs Active Directory (\\gaia\DTIC\Bitacoras\Bitacoras AD\Bitacora logs Active Directory.xls ). Se debe registrar la fecha a la que corresponde el análisis, el tipo de bitácora, los mensajes relevantes y acciones tomadas en caso de ser necesario.

ASI



Revisión de bitácoras de Active Directory

IICA_UTIC_REV_BIT_ACTDIR Versión 1 Última modificación: Enero 2016



Controles

Bitácora de eventos de seguridad

Bitácora de eventos de replicación

Bitácora de eventos del servicio de directorio

Registros

Bitácora de revisión de logs


Usuarios


Política para el uso de dispositivos móviles

IICA_UTIC_MPR_POL_DispMov Versión 2 Última modificación: Noviembre 2016




Objetivo.

Establecer y asegurar la aplicación de los criterios esenciales sobre el uso de los dispositivos móviles provistos a los funcionarios del Instituto Interamericano de Cooperación para la Agricultura (IICA), de manera que se haga un uso conveniente de este tipo de recursos institucionales.

Alcance.

Estas políticas aplican a todo funcionario que haga uso de dispositivos móviles (computadores portátiles, smartphones y PDA’s) institucionales. Entiéndase por dispositivo móvil, cualquier dispositivo electrónico portable, con algunas capacidades de procesamiento, con conexión permanente o intermitente a una red, con memoria limitada, diseñados específicamente para una función, pero que pueden llevar a cabo otras funciones más generales.


Orden Ejecutiva No. 19rev. ”Control de activos movibles electrónicos”. Manual de Seguridad Interna de la Sede Central


El uso de los dispositivos móviles mencionados en esta política estará regulado por la orden ejecutiva No. 19rev, por tanto se deben completar los formularios “Inventario personal de activos movibles electrónicos” y “Solicitud de uso de activo movible electrónico” que se indican en esa orden ejecutiva.

Cada dispositivo móvil institucional es asignado mediante un documento formal a una persona responsable quien será garante de su custodia y buen uso. El uso del dispositivo es exclusivo de la persona responsable, excepto en los casos en que se designe el dispositivo como de uso común para una respectiva dependencia, esto con el fin de evitar usurpación de identidad, mal uso o fuga de información institucional.

Los dispositivos móviles cuyo valor sea mayor a $100, deberán ser registrados en el inventario institucional siguiendo los procedimientos oficiales vigentes.

Los dispositivos móviles institucionales independientemente de su ubicación física deben estar bien resguardados, por parte de la persona responsable, de manera que se minimice al máximo la exposición a daños, pérdida o robo del dispositivo móvil.

Cuando los dispositivos móviles se encuentren dentro de las instalaciones del Instituto, deben ser resguardados en condiciones ambientales y de seguridad apropiadas, evitando la exposición innecesaria del aparato.

Cuando los dispositivos móviles se encuentren fuera de las instalaciones del Instituto, éstos deben permanecer en lugares seguros y siempre bajo la supervisión del responsable.

En caso de viaje deben tomarse las precauciones necesarias para evitar que el equipo pueda verse afectado de alguna manera. En los viajes por avión, autobús, tren o algún otro medio público, los






dispositivos móviles deben viajar como equipaje de mano junto al pasajero, y no documentarse como carga o equipaje. No se recomienda dejar a la vista ninguna etiqueta que identifique al equipo como propiedad del instituto.

Ningún dispositivo móvil debe ser dejado desatendido dentro de los vehículos. Se recomienda no dejar los dispositivos móviles en los automóviles o en la cajuela de estos, ya que se exponen a robos o daños por severas temperaturas.

Si es necesario dejar una computadora portátil desatendida en alguna oficina, cuarto de reuniones o cuarto de hotel, debe utilizar el cable (candado) de seguridad, para sujetar el dispositivo al escritorio. En caso de no contar con el cable de seguridad, el responsable deberá tenerla consigo siempre. Cuando se trate de cualquier otro dispositivo móvil más pequeño, deberá estar custodiado todo el tiempo por la persona responsable, esto con el fin de evitar la pérdida o robo de información, así como del aparato.

Los Oficiales de Seguridad tendrán la obligación de asegurar que en periodos vacacionales, fines de semana, o nocturnos no haya acceso sin excepción de personal a las oficinas.

Para tener acceso en estos periodos deberá contar con un permiso expreso del responsable de la Unidad. Los Oficiales deberán llevar un registro del personal que ingresa, anotando el motivo del acceso de las oficinas fuera de horario regular, hora de ingreso/salida, verificar a la entrada y salida por parte del Oficial de Seguridad los equipos y activos de la Oficina.

Los funcionarios deberán asegurarse de que los equipos portátiles o móviles deberán ser guardados en lugares que ofrezcan la mayor seguridad, es responsabilidad de los funcionarios responder sobre el activo.

En caso para las oficinas que no tienen un esquema de seguridad para salvaguardar los equipos móviles en periodos de ausencia, pueden buscar asesoría a la UTIC para salvaguardar el equipo con las medidas necesarias para evitar robos o mal uso de los equipos.

Se debe evitar el almacenamiento de información sensible en los dispositivos móviles, a menos que cuenten con mecanismos seguros de encriptación. Se recomienda no guardar contraseñas o información clasificada como confidencial para el Instituto. Esto para evitar la pérdida o robo de información sensible del Instituto.

Cualquier daño que pueda presentar un dispositivo móvil propiedad del Instituto, ya sea por accidentes u otra causa, debe ser reportado lo más pronto posible a la UTIC por medio de solicitud, de tal manera que se pueda realizar la reparación correspondiente. La Unidad de Tecnologías de Información y Comunicación se hace responsable por reparos únicamente en dispositivos móviles que sean propiedad del Instituto.

En caso de pérdida, robo o hurto del dispositivo móvil, el responsable del activo deberá informar de lo sucedido a las instancias institucionales correspondientes en cumplimiento con la normativa institucional vigente (Orden Ejecutiva No. 19rev. ”Control de activos movibles electrónicos”).

Cualquier software adicional, cambio de configuración o de seguridad requerido deberá ser instalado únicamente por personal autorizado de la Unidad de Tecnologías de Información y Comunicación.






Se requiere que las computadoras portátiles tengan un nivel aceptable de funcionalidad, es por esto que en caso de cualquier instalación de software detectada y que pueda poner en riesgo la seguridad de la información institucional, la Unidad de Tecnologías de Información y Comunicación se reserva el derecho realizar la desinstalación correspondiente.

Es responsabilidad del usuario que está conectado a la red institucional mediante su dispositivo móvil asegurarse que todos los requisitos de su conexión se mantengan tan seguros como si se estuviese en su computadora de oficina, deberá asegurarse que no contiene virus, software malicioso, o algún otro software que pueda poner en peligro la plataforma tecnológica, en caso de dudas se deberá contactar a la UTIC para la asesoría correspondiente.

La UTIC se reserva el derecho de eliminar el acceso de un dispositivo móvil a cualquier punto de red que ponga en riesgo los sistemas, información, usuarios o red institucional.

Cualquier dispositivo móvil configurado para acceder los recursos del instituto mediante redes inalámbricas debe realizar sus conexiones con la apropiada autenticación provista por la Unidad de Tecnologías de Información y Comunicación.

En caso que exista sospecha de incidentes de accesos no autorizados a los recursos del Instituto (correo, intranet, etc.), se debe indicar inmediatamente a la Unidad de Tecnologías de Información y Comunicación mediante el “help desk” institucional

En caso de renuncia, todos los dispositivos móviles y sus respectivos accesorios deben ser devueltos a las unidades respectivas el último día de trabajo.


Correo electrónico IICA_UTIC_MPR_POL_UsCoEl Versión 2 Última modificación: Noviembre 2016



Política de correo electrónico

Objetivo.

Establecer y aplicar los criterios idóneos para la gestión eficaz del correo electrónico Institucional, que permitan un adecuado funcionamiento del servicio y protección de la información, los servicios de red y la imagen institucional.

Alcance.

Esta política aplica a todos quienes tengan asignada una cuenta de correo institucional.


Políticas para el uso de recursos informáticos. Política para la creación de cuentas de usuarios de servicios informáticos. Procedimiento para crear cuentas de usuario de correo electrónico. Procedimiento para eliminar cuentas de usuario de correo electrónico. Orden Ejecutiva 30/2008 – Correo Electrónico Institucional.

Política de servicio

El área de soporte correo del IICA tiene la facultad para la creación de cuentas de correo electrónico y la administración del servicio.

Sólo podrán hacer uso del servicio de correo electrónico los usuarios que cuenten con una clave de acceso autorizada por soporte correo.

La cuenta de correo electrónico se debe crear con base en los datos suministrados en la herramienta de “help desk OTRS” por la unidad solicitante. Es responsabilidad de la unidad solicitante gestionar ante la Unidad de Tecnología de Información y Comunicación tanto la creación como la eliminación de las cuentas de correo.

Las cuentas de correo de los miembros del personal IICA, tendrán vigencia únicamente durante el tiempo que comprenda su periodo laboral en la Institución.

Si se trata de personas que no sean miembros del personal del Instituto, únicamente se asignará cuenta de correo institucional, de forma temporal, cuando el caso sea debidamente justificado por parte de la jefatura de la Unidad Solicitante. La vigencia de la cuenta será controlada mediante la cuenta de red que tiene asociada.

El usuario podrá tener acceso al correo electrónico vía Internet mediante el usuario y contraseña asignados.

El área de soporte correo del IICA debe agregar el nuevo usuario a los grupos de correo básicos y a cualquier otro grupo que haya sido requerido por la Unidad Solicitante, lo cual se debe registrar en la bitácora de usuario y en una nota interna de la solicitud. Cualquier nuevo grupo en el que sea necesario agregar al usuario deberá ser solicitado por el responsable (administrativo) del grupo de correo a la UTIC a través del OTRS.





El tamaño máximo de un mensaje de correo electrónico y sus adjuntos que el sistema permite es de 25 MB. Si el archivo tiene un mayor tamaño deberá utilizar otros medios para su envío

El buzón de correo de cada usuario tendrá un tamaño de 30 GB, solamente en casos de excepción, se ampliará el tamaño del buzón, siempre que esté debidamente justificado.

El sistema de correo electrónico institucional aplicará filtros para evitar, en la medida de lo posible, la entrada de mensajes, archivos o enlaces que puedan afectar la integridad y seguridad de la plataforma institucional.

Cada vez que se ingrese o elimine un usuario de correo, la acción debe ser registrada en la bitácora de usuarios correspondiente (Bitácora_Usuarios).

Toda solicitud de eliminación de cuentas de correo debe ser enviada al área de soporte correo del IICA a través del sistema “help desk OTRS”. En caso de que se haya solicitado inhabilitar temporalmente la cuenta, el buzón de correo será eliminado automáticamente después de 30 días naturales, excepto que expresamente se indique lo contrario.

Cuando una cuenta se encuentra inhabilitada, podrá recibir correos pero no se permitirá su envío, de manera que otro usuario pueda darle seguimiento al buzón de correo y de esta manera se puedan finiquitar situaciones de interés institucional que se encuentren inconclusas.

En ninguno de los casos (eliminar o inhabilitar) se permite al usuario acceder al buzón de correo, pues ya no tiene relación con la Institución.

Políticas de uso

El servicio de correo institucional debe ser utilizado estrictamente para la comunicación y el trámite de asuntos institucionales. Los asuntos de carácter personal deberán ser tratados mediante correos personales como por ejemplo hotmail, yahoo o gmail.

El servicio de correo electrónico no puede ser empleado con los siguientes fines:

Enviar información confidencial o de propiedad exclusiva del Instituto a terceras personas no relacionadas con la Institución.

Transmitir correos que promuevan actos ilícitos, deshonestos, contrarios a la moral y a las buenas costumbres, que difamen o perjudiquen la reputación de otras personas, que contengas asuntos de carácter obsceno o pornográfico o que promueva la discriminación en cualquier sentido (por razones de raza, credo, nacionalidad o género). Tampoco se podrá utilizar el correo electrónico institucional para asuntos de política partidaria o para hacer campañas electorales de cualquier índole.

Hacerse pasar por alguna otra persona, hacer declaraciones falsas y cualquier otra forma de falsificación de la identidad de alguna persona.





Enviar mensajes no solicitados por los destinatarios, promociones, cadenas, archivos que contengan virus, programas o códigos con la capacidad de dañar equipos.

Hacer uso de la cuenta para fines comerciales ni publicitarios.

Enviar correos a los grupos de correo institucionales (por ejemplo gmundo_iica) sobre asuntos que no son institucionales.

La información transmitida mediante el servicio de correo, es responsabilidad única y exclusiva de cada usuario, no del IICA; por ello, la institución no garantiza la veracidad, integridad o calidad del contenido de los mensajes enviados mediante este servicio.

El usuario es responsable de realizar la administración de la cuenta de correo electrónico, esto incluye la capacidad del buzón de correo electrónico y respaldo de la información.

Políticas de seguridad

Las cuentas de correo electrónico son intransferibles y no pueden ser heredadas.

El usuario tiene la responsabilidad de reportar cualquier anomalía o mal uso de su cuenta. En caso de detección de anomalías, reportar de manera inmediata a soporte correo.

El identificador del usuario o el correo electrónico debe estar compuesto por nombre.apellido, en caso de que ya exista se utiliza nombre.nombre2.apellido ó nombre.apellido.apellido2.

El usuario es responsable de respaldar sus archivos de correo.

No se permite la descarga de archivos ejecutables.


Política creación de cuentas de usuarios de servicios informáticos

IICA_UTIC_MPR_POL_CrCuUs Versión 2 Última modificación: Diciembre 2016




Objetivo

Establecer un conjunto de estándares para la creación de cuentas de usuarios de los diferentes servicios informáticos que provee la Unidad de Tecnología de Información y Comunicación (UTIC) con el fin de garantizar el funcionamiento adecuado de la plataforma tecnológica del Instituto.

Alcance

Esta política aplica a todos los usuarios autorizados para utilizar los servicios informáticos administrados por la Unidad de Tecnología de Información y Comunicación del IICA.

Documentos relacionados

Reglamento de personal

Manual de Personal

Orden Ejecutiva N° 17/2005

Orden Ejecutiva N° 28/2007

Orden Ejecutiva N° 30

Políticas generales para la creación de cuentas de usuarios de servicios informáticos

Una plataforma tecnológica es un conjunto de normas, herramientas de hardware y software que deben permitir:

Garantizar la conectividad e interoperabilidad entre las instituciones.

Permitir el funcionamiento y desarrollo de sistemas institucionales.

Capacidad de trabajo interactivo entre usuarios mediante la implementación de sistemas colaborativos por medios electrónicos.

La plataforma tecnológica propiedad del Instituto Interamericano de Cooperación para la Agricultura (IICA), será administrada por la Unidad de Tecnología de Información y Comunicación. Dicha plataforma estará a disposición de los diferentes tipos de usuarios del Instituto y solo deberá ser utilizada para propósitos específicos del Instituto.

La plataforma tecnológica está compuesta por una infraestructura tanto de software como de hardware que provee diversos servicios a sus usuarios entre los cuales están: red institucional, correo electrónico, intranet, internet, sistemas de información, VPN y telefonía IP, entre otros.

Por ser la Unidad de Tecnología de Información y Comunicación la encargada de administrar la infraestructura tecnológica del Instituto, las solicitudes de acceso a los servicios informáticos serán canalizadas directamente a través de ésta.

La cantidad de recursos informáticos es limitada, por lo que se deberá considerar al resto de los usuarios con los que se comparten estos recursos.






Corresponde a todos los usuarios mantener la confidencialidad de sus claves de acceso (passwords) a los diferentes servicios tecnológicos: red, correo electrónico, intranet y sistemas de información, entre otros.

Cuando se suministra equipo informático al usuario (computador de escritorio o portátil), éste equipo cuenta con todo el software necesario para realizar sus labores, el usuario no deberá instalar ningún software o herramienta sin autorización de la UTIC.

No se deberá almacenar en los servidores institucionales archivos o información no institucional, como por ejemplo (fotografías personales, música, videos) En caso de que la UTIC encontrase este tipo de contenidos, los archivos serán eliminados de forma inmediata.

Tipos de usuarios

En seguimiento al reglamento de personal, manual de personal, orden ejecutiva N° 17 y N° 28, el IICA establece diferentes criterios de clasificación del personal, estas clasificaciones poseen diferentes roles y responsabilidades, así como derechos y deberes dentro del Instituto. Para cada una de estas clasificaciones se han definido una serie de normas en cuanto al uso de la plataforma tecnológica del Instituto, mismas que a continuación se detallan.

Consultor

De acuerdo con la Orden Ejecutiva N° 17, artículo D inciso 3 párrafo tercero expresamente se indica:

“Cualquier persona física que preste servicios bajo un contrato por servicios profesionales de consultoría no es considerado miembro del personal del Instituto, y no tendrá derecho a pretensión alguna en cuanto a las condiciones que ostenta un miembro del personal del IICA.”

Aspectos específicos

Los consultores del IICA no deberán tener cuentas de correo electrónico Institucionales, ni participar en los diferentes grupos de correo, acceso a internet o red local del IICA.

Los consultores no deberán tener acceso a la Intranet Institucional, sistemas de información institucional, computadoras del IICA, impresoras o activos tecnológicos del Instituto.

Los consultores no deberán tener acceso a la VPN del Instituto

Personal Emérito

De acuerdo con el Manual de Personal en el artículo 1.8.2.1 establece que el Personal Emérito “… se consideran Consultores Permanentes del IICA”. Basado en esta aseveración, el Personal Emérito se rige bajo las mismas disposiciones que las establecidas para los Consultores y consecuentemente según lo establecido en la Orden Ejecutiva N° 17.


El Personal emérito del IICA no deberá tener cuentas de correo electrónico Institucionales, ni participar en los diferentes grupos de correo.






El Personal emérito no deberá tener acceso a la Intranet Institucional, sistemas de información institucional.

El Personal Emérito no deberá tener acceso a la VPN del Instituto.

Personal contratado en el marco de instrumentos jurídicos

De acuerdo con la Orden Ejecutiva N°28, para el personal local contratado bajo las normas del Instituto (Artículo IV, Segunda Modalidad) se aplican las condiciones y beneficios mandatorios (inciso 7) y opcionales (incisos 8 y 9). Estos beneficios y condiciones no incluyen la disponibilidad de recursos tecnológicos para el desempeño de su trabajo. En este contexto, será el Representante en la Oficina (o en su defecto el Administrador de la Oficina, si así lo delega el Representante), quien solicitará por escrito cada uno de los recursos tecnológicos a los cuales tendrá derecho el personal contratado en el marco de instrumentos jurídicos, incluyendo el acceso a un computador, a los servicios de red provistos por la Oficina, a la conexión a Internet y en último término, a la cuenta de correo electrónico. Dicha concesión tendría un plazo máximo equivalente a la finalización del instrumento jurídico o a la finalización de la contratación, lo que ocurra primero. Es por ello fundamental, que así como le fueron entregadas las facilidades al contratado, se solicite su retiro en los mismos términos.


Previo al acceso a la plataforma institucional por parte del personal contratado en el marco de instrumentos jurídicos, el Representante o a quien este delegue, deberá enviar una comunicación oficial, en la cual indique los servicios a los cuales el funcionario deberá tener acceso.

Una vez terminado el contrato, los servicios de la plataforma tecnológica se suspenderán inmediatamente. La administración o la unidad de Recursos Humanos de cada oficina o Sede Central deberá informar con al menos 24 horas de anticipación la terminación de los contratos respectivos. Adicionalmente, la Unidad de Tecnología de Información y Comunicación cada 3 meses consultará a las autoridades respectivas sobre el listado de usuarios activos en la plataforma institucional.

El uso del correo electrónico se regulará de acuerdo a la Orden Ejecutiva No. 30.

Pasante o practicante

Un practicante o un pasante no pueden ser nunca considerados funcionarios del IICA, debido a que no existe relación laboral establecida (nota aclaratoria de la Unidad de Recursos Humanos). Habría que evaluarse cuidadosamente si al efectuar su trabajo el pasante o practicante requiere de elementos propios de la tecnología de información (acceso a la red institucional, a Internet y a cuenta de correo electrónico), para lo cual el Jefe de Unidad o el Representante debería elaborar una solicitud donde expresamente indique los elementos a los cuales se les debe dar acceso y el plazo máximo de dicho otorgamiento, basado en el período de la pasantía o práctica acordado.







Previo al acceso a la plataforma institucional por parte del pasante o practicante, el Representante/Director o Jefe o a quien este delegue, deberá enviar una comunicación oficial a la Unidad de Tecnología de Información y Comunicación departamento de Informática, en la cual se indique los servicios y el tiempo a los cuales el funcionario deberá tener acceso.

Por ser practicantes o pasantes, no deberán participar de los diferentes grupos de correo institucionales.

Una vez terminado el contrato, los servicios de la plataforma tecnológica se suspenderán inmediatamente. La administración o la unidad de Recursos Humanos de cada oficina o Sede Central deberá informar con al menos 24 horas de anticipación la terminación de los contratos respectivos. Adicionalmente, la Unidad de Tecnología de Información y Comunicación cada 3 meses consultará a las autoridades respectivas sobre el listado de usuarios activos en la plataforma institucional.

El uso del correo electrónico tendrá que ser basado de acuerdo a la Orden Ejecutiva No. 30.

Personal Temporal (con contrato temporal)

En el caso de personal local contratado con fondos institucionales, el contrato temporal se refiere a contrataciones por plazo fijo y para una labor específica y transitoria (Manual de Personal, artículos 1.7.2.2 y 1.7.3.1). Bajo este criterio, el otorgamiento de facilidades tecnológicas se sustentaría en el plazo estipulado. El hecho que pueda utilizar un computador (notebook o desktop) no necesariamente justifica su acceso a la cuenta de correo, ni a Internet. De hecho, las condiciones de trabajo se establecen taxativamente en el contrato y según la legislación y prácticas laborales de su país (Manual de Personal, artículos 1.7.2.2 y 1.7.3.1). En términos generales, salvo contratos superiores a 1 año, ningún contratado temporal requiere acceso a cuenta de correo o a Internet, a menos que exista justificación expresa del Representante o Jefe de Unidad respectivo y que se debe crear un proceso automático que suspenda ambos servicios y el acceso a los servicios de red con base en la fecha de finalización del contrato establecido, dando un plazo de gracia no mayor a 15 días.


El Personal temporal tendrá acceso a toda la plataforma tecnológica institucional de acuerdo al rol y responsabilidades propias de su trabajo.

Una vez terminado el contrato, los servicios de la plataforma tecnológica se suspenderán inmediatamente. La administración o la unidad de Recursos Humanos de cada oficina o Sede Central deberá informar con al menos 24 horas de anticipación la terminación de los contratos respectivos. Adicionalmente, la Unidad de Tecnología de Información y Comunicación cada 3 meses consultará a las






autoridades respectivas sobre el listado de usuarios activos en la plataforma institucional.

Si hace uso del correo electrónico, tendrá que ser basado de acuerdo a la Orden Ejecutiva No. 30.

Por ser personal temporal, no deberá formar parte de los grupos de correo electrónico institucional.

Personal Regular

“Según lo establecido en el Reglamento de Personal en su artículo 1.4”

“1.4.1 El Director General, conforme a las normas aprobadas por la Junta o el Comité Ejecutivo, dictará las disposiciones administrativas para la clasificación del personal que ingresa y que está siendo promovido en las categorías Profesional y de Servicios Generales, de acuerdo a criterios basados en el curriculum vitae de la persona, sus calificaciones, clase y calidad de servicios que brinda al Instituto.

Dichas normas servirán para determinar la clasificación personal y el nivel o clase de cada funcionario, que deberán ser compatibles con el nivel de clasificación del cargo que ocupa. (Artículo 34)”

“1.4.2 Ningún funcionario al servicio del IICA podrá ser degradado en su nivel de clasificación personal, durante su período de nombramiento.”

En el Manual de Personal se aclara:

“1.6.4 El personal de las categorías Profesional Local y Servicios Generales se nombra de acuerdo con la legislación y las prácticas laborales de cada país, en cargos clasificados y presupuestados en el Programa Operativo de cada unidad, con fondos regulares u otros recursos que administre el IICA. Estos nombramientos están sujetos a revisiones”


El Personal regular tendrá acceso a toda la plataforma tecnológica institucional de acuerdo al rol y responsabilidades propias de su trabajo.

Una vez terminado el contrato, los servicios de la plataforma tecnológica se suspenderán inmediatamente, respecto a la casilla del correo electrónico se mantendrá activa 30 días hábiles una vez terminada la relación laboral.

Si hace uso del correo electrónico, tendrá que ser basado de acuerdo a la Orden Ejecutiva No. 30.

Acceso al correo electrónico

La cuenta de correo electrónico de los usuarios serán definidos como [email protected]. El identificador (ID) del usuario estará compuesto por nombre.apellido, en caso de que ya exista se utiliza nombre.nombre2.apellido ó en su defecto nombre.apellido.apellido2.






El buzón de correo de cada usuario tendrá un tamaño máximo de 30 GB, solamente en casos de excepción, se ampliará el tamaño del buzón, siempre que esté debidamente justificado.

Cada vez que se ingrese o elimine un usuario de correo, la acción será registrada el sistema automatizado de registro de solicitudes.

Acceso a la red

A la red institucional podrán ingresar únicamente los usuarios autorizados, quienes deberán superar el proceso de autenticación de Windows para acceder a la red institucional.

El identificador de usuario de red estará compuesto por la primera letra del nombre junto con el primer apellido completo, en caso de que ya exista se utilizará adicionalmente la primera letra del segundo nombre con el primer apellido completo ó la segunda letra del primer nombre junto con el primer apellido completo.

Al usuario se le indicará la clave de acceso para que pueda ingresar a la red, misma que deberá modificar la primera vez que logre ingresar a la red, esto por solicitud expresa y de forma automática del sistema operativo.

La clave definida por el usuario deberá ser mayor o igual a 8 caracteres y estará compuesta únicamente por letras y/o números.

El cambio de clave será automático, con una periodicidad de 90 días.

La clave que defina el usuario no podrá ser igual a las últimas 5 claves anteriormente utilizadas.

Cada vez que se ingrese o elimine un usuario de red, la acción será registrada en el sistema automatizado de registro de solicitudes.

Acceso a intranet

Cada usuario institucional podrá ingresar a la intranet utilizando el usuario de correo electrónico.

Para acceder a la intranet institucional el usuario podrá utilizar cualquier navegador, sin embargo se recomienda utilizar internet explorer para que tenga acceso a todas las funcionalidades del sitio.

La dirección (URL) será facilitado por la UTIC a los usuarios, misma que deberá ser ingresada en el navegador para que puedan ingresar a la intranet institucional.

Cada vez que se ingrese o elimine un usuario de intranet, la acción será registrada en la bitácora de usuarios de intranet, así como en el sistema automatizado de registro de solicitudes.

Acceso a los sistemas de información

Para que un funcionario pueda acceder a uno o varios sistemas de información, éste deberá solicitar el acceso directamente al administrador funcional del sistema, el cual será la única persona autorizada a solicitar la cuenta sus respectivos roles a la Unidad de Tecnología de Información y Comunicación.

En el caso de los sistemas de información, el objetivo principal es que el usuario no deba aprenderse múltiples claves para ingresar a ellos, especialmente en los sistemas o aplicaciones de escritorio, sino que pueda utilizar el mismo ID de usuario y contraseña de la intranet. Por supuesto






que en el caso de los sistemas de mayor complejidad (sistemas integrados, modulares, etc.) se contará para cada uno, con políticas específicas para este tema.

Las aplicaciones que se utilizan mediante la intranet, validarán la cuenta y contraseña del usuario de intranet, es decir, para que el usuario acceda al sistema debe ingresar a la intranet con su ID y clave y desde ahí podrá acceder a los sistemas para los que posea las autorizaciones correspondientes.

Las aplicaciones de escritorio (que no están en intranet), validarán su ingreso de acuerdo al ID y clave de red, esto significa que el usuario desde el escritorio de su PC, podrá ingresar a los diferentes sistemas indicando para cada uno, el mismo ID y clave que utiliza en la red. Si la clave de red es modificada, para acceder a los sistemas el usuario deberá utilizar la nueva clave, sin ejecutar ningún paso adicional.

En el caso de los sistemas integrados, cada uno tendrá sus políticas de administración de usuarios, como se presenta a continuación,

Sistema ID usuario Clave inicial

Tamaño mínimo de la clave

Vigencia de la clave

Distinción mayúsculas y minúsculas

Histórico claves

SAP Primera letra del nombre y primer apellido

12345678 8 (con al menos 3 dígitos

numéricos)

90 días NO 14

En el caso de que se requiera crear cuentas genéricas de dominio o cuentas genéricas en sistemas,

deberán registrarse con una justificación y el responsable que lo solicita.


Procedimiento creación nuevas cuentas servicios informáticos

IICA_UTIC_MPR_PRD_CrCuIn Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento creación nuevas cuentas servicios informáticos.

Introducción Este procedimiento fue creado para documentar el proceso de creación de cuentas de usuarios de servicios informáticos del Instituto.

Cabe mencionar que en el caso de la unidad de Informática, será una única persona la responsable de darle seguimiento a la solicitud del usuario, independientemente de cuántas personas participen en el proceso de creación de las diferentes cuentas.

Objetivo Definir de manera detallada los pasos a seguir cuando se solicita la creación de nuevas cuentas para los servicios informáticos que ofrece el IICA.

Actores AUS: Administrador usuarios de red

ACE: Administrador correo electrónico

AIN: Administrador intranet

ASI: Administrador sistema de información

AET: Administrador Extensiones Telefónicas

USO: Unidad solicitante

SPU: Soporte a usuarios


Políticas creación de cuentas de usuarios de servicios informáticos

Política administración de claves

Política correo electrónico

Formulario creación de servicios informáticos

Procedimiento creación cuenta de usuario de red

Procedimiento creación cuenta de correo

Procedimiento creación cuenta intranet

Procedimiento creación cuenta de usuario de sistema de información

Procedimiento de administración de extensiones telefónicas


Con el afán de ofrecer un servicio de calidad, la Unidad de Tecnología de Información y Comunicación requiere que las solicitudes le sean enviadas con al menos una semana de anticipación.

La instalación del sistema de “Boletas” tiene como requerimiento previo la






creación y configuración del usuario de red en la computadora del usuario, junto con el aplicativo “Microsoft Office Access”.

Cada uno de los funcionarios de UTIC que participen en la atención de una solicitud deberá agregar una nota interna detallando lo que hizo, en función de facilitar el trabajo y mejorar la comunicación a lo interno de la Unidad.

En todos los casos, soporte técnico a usuarios será el responsable de darle seguimiento a las solicitudes hasta su finalización.

Glosario UTIC: Unidad de Tecnología de Información y Comunicación

Herramienta automatizada de Helpdesk OTRS: Sistema informático que se accede vía web donde se deben registrar todas las solitudes de trabajo de la Sede Central dirigidas a la UTIC.

VPN: Virtual Private Network, tecnología de red que permite la extensión de la red local sobre una red pública como intranet.

N° Paso


10 La unidad solicitante registra su solicitud en la herramienta automatizada de Helpdesk denominada OTRS, para lo cual debe adjuntar debidamente lleno el Formulario creación de servicios informáticos. La solicitud deberá ser incluida en la cola de trabajo llamada Soporte TIC.

USO

20 En un máximo de 60 minutos la solicitud será atendida por un funcionario de soporte técnico quién revisará el formulario y pasará la solicitud a la cola de trabajo correspondiente según se indique. Adicionalmente, le dará seguimiento a la solitud durante todo el proceso, para lo cual debe auto-asignarse como Responsable de ésta.

SPU

30 Si es indicado en el formulario, se crea la cuenta del usuario de red. Así como los permisos necesarios acceder a las carpetas de trabajo. Ver Procedimiento creación cuenta usuario de red.

AUS

40 Si es indicado en el formulario, se crea la cuenta de correo para el nuevo usuario. Ver Procedimiento creación cuenta de correo.

ACE

50 Si es indicado en el formulario, se crea la cuenta para el uso de Intranet del nuevo usuario. Ver Procedimiento creación cuenta de intranet.

AIN

60 Si es indicado en el formulario, se crea la cuenta del nuevo usuario en los sistemas de información que fueron solicitados. Ver Procedimiento

ASI






creación cuenta de usuario de sistema de información.

70 Si es indicado en el formulario, se configura una extensión telefónica para el nuevo usuario. Ver Procedimiento de administración extensiones telefónicas.

AET

80 Si es indicado en el formulario, se configura el equipo (PC) que el usuario utilizará, para lo cual se instalarán los programas y se realizarán los mapeos a carpetas e impresoras, de acuerdo a las funciones y ubicación física del nuevo usuario.

SPU

90 Si no queda nada pendiente de realizar, se finaliza con la atención de la solicitud para lo cual en la herramienta OTRS se debe modificar su estatus a “Pendiente Auto-close (1día)” que enviará de manera automática un correo electrónico a la persona que creó la solicitud.

SPU



Eliminación de cuentas servicios informáticos

IICA_UTIC_MPR_PRD_ElCuIn Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento eliminación de cuentas servicios informáticos.

Introducción Los servicios informáticos están disponibles para los usuarios del Instituto, una vez que la relación laboral finaliza, por aspectos de seguridad se deben eliminar los accesos del usuario a la plataforma tecnológica del Instituto. Para que la Unidad de Tecnología de Información y Comunicación proceda formalmente con la eliminación de cuentas de red, de correo, de intranet y/o de sistemas de información, la unidad a la cual pertenece el usuario deberá solicitar la cancelación de las cuentas activas del usuario.

Objetivo Definir de manera detallada los pasos a seguir para eliminar cuentas de usuario de los diferentes servicios informáticos.

Actores AUS: Administrador usuarios de red


AGC: Administrador de grupos de correo (UTIC)



AET: Administrador extensiones telefónicas

USO: Unidad solicitante

SPU: Funcionario de soporte a usuarios


Políticas creación de cuentas de usuarios de servicios informáticos.

Política de administración de claves.

Formulario eliminación de servicios informáticos.

Glosario Responsable del grupo de correo: es la persona que dentro de una unidad de trabajo solicita inclusiones o exclusiones de usuarios en los grupos de correo que utiliza esa unidad.

Administrador de grupos de correo: es la persona en la Unidad de Tecnología de Información y Comunicación que se encarga de darle mantenimiento a los grupos de usuarios existentes en el IICA, de acuerdo a las solicitudes que realicen los responsables de los grupos de correo.


Herramienta automatizada de Helpdesk OTRS: Sistema informático que se accede vía web donde se deben registrar todas las solitudes de trabajo de la






Sede Central dirigidas a la UTIC.

N° Paso


10 Con al menos 24 horas de anticipación, se genera una solicitud de servicio (ticket) mediante la herramienta automatizada de help desk denominada OTRS, se explica el tipo de servicios que se necesita y se adjunta debidamente lleno el Formulario Eliminación de Servicios Informáticos, donde se deben indicar los servicios que deben ser eliminados y a partir de qué fecha se debe realizar o en su defecto una nota que justifique la no eliminación de uno o varios servicios activos para el ex usuario. La solicitud deberá ser incluida en la cola de trabajo llamada Soporte TIC.

USO

20 En un máximo de 60 minutos la solicitud será atendida por un funcionario de soporte técnico quién revisará el formulario y pasará la solicitud a la cola de trabajo correspondiente según se indique. Adicionalmente, le dará seguimiento a la solitud durante todo el proceso, para lo cual debe auto-asignarse como Responsable de ésta.

SPU

30 Si es indicado en el formulario se elimina la cuenta de red. Se debe tomar en cuenta que al eliminar la cuenta de red del ActiveDirectory, serán eliminados los accesos por VPN, cisco IP y aplicaciones de escritorio. Se debe agregar una nota interna a la solicitud indicando la acción realizada.

AUS

40 Si es indicado se elimina la carpeta personal. En caso contrario, se elimina al cumplir los 30 días naturales.

AUS

50 Si es indicado en el formulario se elimina la cuenta de correo electrónico. Ver Procedimiento: Eliminación cuenta de correo electrónico.

ACE

60 Si es indicado en el formulario se elimina la cuenta de intranet. Los cambios se registran en la bitácora llamada Bitácora usuarios intranet, que se ubica en \\gaia\DTIC\Bitacoras. Cabe mencionar que al eliminar la cuenta de intranet se elimina automáticamente el acceso a los sistemas web en los que el usuario haya sido incluido con anterioridad. No así el registro del usuario dentro de cada sistema, por eso se recomienda además eliminar el usuario definido dentro de cada sistema (web o escritorio). Se agrega una nota interna a la solicitud indicando la acción realizada y se envía un correo electrónico al administrador del directorio institucional para que se realicen las gestiones pertinentes.

AIN

70 Si es indicado en el formulario se elimina la cuenta de usuario en las aplicaciones indicadas en el formulario. Actualizando las bitácoras de cada aplicación según sea el caso. Cabe mencionar que solamente se

ASI






hará en las aplicaciones cuya administración de usuarios sea responsabilidad de la Unidad de Tecnología de Información y Comunicación. Toda acción realizada debe quedar registrada en OTRS mediante una nota interna asociada a la solicitud.

80 Si es indicado en el formulario, se elimina la extensión telefónica asignada al usuario. Se envía un correo electrónico al encargado del mantenimiento del directorio telefónico institucional avisando del cambio. Se debe agregar una nota interna a la solicitud indicando la acción realizada.

AET

90 Se finaliza con la atención de la solicitud para lo cual en la herramienta OTRS se debe modificar su estatus a “Pendiente Auto-close (1día)” que enviará de manera automática un correo electrónico a la persona que creó la solicitud.

SPU



Creación cuenta de usuario de red IICA_UTIC_MPR_PRD_CrCuRd Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento creación cuenta de usuario de red

Introducción La red institucional es la infraestructura tecnológica que el IICA, a través de la Unidad de Tecnología de Información y Comunicación (UTIC), pone a disposición de sus usuarios para la utilización de diversas herramientas tecnológicas con las que cuenta el Instituto.

Objetivo Definir de manera detallada los pasos a seguir para crear una cuenta de usuario de red para funcionarios del Instituto.

Actores AUR: Administrador de usuarios de red









N° Paso


10 Llega una nueva solicitud en OTRS a la cola Soporte Redes, la cual es bloqueada para empezar a ser atendida. La solicitud es utilizada como mecanismo formal de altas y bajas de cuentas.

AUR

20 Con base en los datos suministrados por la unidad solicitante (en la herramienta de help desk OTRS), la cuenta de red es creada, dando el acceso a las diferentes carpetas compartidas de la unidad, siguiendo los estándares y políticas utilizadas en la UTIC que se encuentran definidas en el documento Política creación usuarios de servicios informáticos.

AUR

30 Se le habilitan los permisos necesarios para que el nuevo usuario tenga acceso a las impresoras, carpetas y archivos compartidos de la unidad donde iniciará labores, según sea indicado en el formulario de solicitud.

AUR





40 Se le crea una carpeta al usuario para que éste realice sus respaldos en la red. Esta carpeta se crea en el servidor de archivos institucional (que se respalda diariamente). El espacio asignado a cada usuario es de 2.5 GB.

AUR

50 Se registra en el tiquete de OTRS el nuevo usuario de red, así como una contraseña temporal que el usuario utilizará la primera vez y deberá cambiar.

AUR

60 El funcionario de soporte a usuarios se presenta a la unidad solicitante para verificar que la PC del nuevo usuario posea la configuración básica institucional y cualquier otro servicio solicitado. En caso de que no lo posea se debe hacer la instalación y configuración necesaria.

SPU

70 Se le entrega al usuario el ID y la clave, indicándole que el controlador de dominio le solicitará cambiar la clave la primera vez que lo acceda. Además se le brindarán al usuario las recomendaciones para el cambio de la clave de acuerdo a la política institucional, como por ejemplo cantidad de caracteres y cuáles pueden utilizar.

SPU

80 Se mapeará en la máquina del usuario la carpeta para realizar sus respaldos en el servidor, indicándole la forma de utilizar esta facilidad y el tipo de información que se podría respaldar.

SPU

90 Se añade una nota interna indicando las acciones realizadas. En caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar al estado Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

AUR

Crear cuentas genéricas de dominio

100 Con base en los datos suministrados al administrador de dominio y previamente aprobado por la Jefatura de la Unidad, la cuenta de red es creada, siguiendo los estándares y políticas utilizadas en la UTIC que se encuentran definidas en el documento Política creación usuarios servicios informáticos.

AUR

110 Se registran los datos del nuevo usuario en la bitácora llamada bitácora cuentas genéricas de dominio (\\gaia\DTIC\Bitacoras).

AUR

120 Se entrega, por mecanismo seguro, tanto el ID de usuario como su respectiva clave.

AUR






Registros

Bitácora cuentas genéricas de dominio


Creación cuenta de correo electrónico

IICA_UTIC_MPR_PRD_CrCuCo Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento creación cuenta de correo electrónico

Introducción El correo electrónico es una herramienta que el IICA a través la Unidad de Tecnología de Información y Comunicación pone a disposición de sus usuarios para facilitar la transferencia de información y conocimiento institucional.

Objetivo Definir de manera detallada los pasos a seguir para crear una cuenta de usuario de correo electrónico para funcionarios del Instituto.

Actores ACE: Administrador correo electrónico




Políticas para creación de cuentas de usuarios de servicios informáticos


Política de correo electrónico


Formulario para creación de servicios informáticos



N° Paso


10 Llega una nueva solicitud en OTRS a la cola Soporte Correo, la cual es bloqueada para empezar a ser atendida.

ACE

20 Con base en los datos suministrados por la unidad solicitante (en la herramienta de help desk OTRS), la cuenta de correo electrónico es creada, siguiendo los estándares y políticas utilizadas en la UTIC que se encuentran definidas en el documento Políticas para creación de cuentas de usuarios de servicios informáticos.

ACE

40 Se agrega el nuevo usuario a los grupos de correo básicos y a cualquier otro grupo que haya sido requerido por la Unidad Solicitante, lo cual se debe registrar en una nota interna de la solicitud. En adelante, cualquier nuevo grupo en el que sea necesario agregar al usuario deberá ser solicitado por el responsable

AGC


Creación cuenta de correo electrónico

IICA_UTIC_MPR_PRD_CrCuCo Versión 2 Última modificación: Agosto 2016



(administrativo) del grupo de correo a la UTIC a través del OTRS.

60 El funcionario de soporte a usuarios se presenta a la unidad solicitante para configurar el acceso a la cuenta de correo electrónico.

SPU

70 Se añade una nota interna indicando las acciones realizadas, en caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar al estado Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

ACE



Creación cuenta de intranet IICA_UTIC_MPR_PRD_CrCuIn Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento creación cuenta de intranet

Introducción La intranet institucional es una herramienta que el IICA, a través la Unidad de Tecnología de Información y Comunicación, pone a disposición de sus usuarios para facilitar la transferencia de información. Este procedimiento fue creado para documentar el proceso de creación de una nueva cuenta de usuario para el uso de la intranet institucional.

Objetivo Definir de manera detallada los pasos a seguir para crear una cuenta de usuario de intranet para usuarios del Instituto.

Actores AIN: Administrador intranet


Políticas creación de cuentas de usuarios de servicios informáticos Política administración de claves Procedimiento creación nuevas cuentas servicios informáticos Formulario creación de servicios informáticos



N° Paso


10 Llega una nueva solicitud en OTRS a la cola Soporte Sistemas, la cual es bloqueada para empezar a ser atendida.

AIN

20 De acuerdo a los datos suministrados en la solicitud (en la herramienta de help desk OTRS), la cuenta de intranet es creada en el Sistema de administración de usuarios de intranet, acatando los estándares y políticas utilizadas en la UTIC que se encuentran definidas en l Política creación de cuentas de servicios informáticos.

AIN

30 Se envía un correo al administrador del directorio institucional para que se incluyan los datos del nuevo usuario en los archivos correspondientes.

AIN

40 Se añade una nota interna a la solicitud indicando las acciones realizadas, en caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar su estado a Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

AIN



Eliminación de cuenta de correo electrónico

IICA_UTIC_MPR_PRD_ElCuCo Versión 2 Última modificación: Noviembre 2010



Nombre Procedimiento eliminación de cuenta de usuario del correo electrónico

Introducción El correo electrónico es una herramienta de carácter institucional disponible para usuarios del Instituto.

Objetivo Definir de manera detallada los pasos a seguir para eliminar una cuenta de usuario de correo electrónico institucional.

Actores ACE: Administrador correo electrónico



Políticas para la creación de cuentas de usuarios de servicios informáticos

Políticas administración de claves

Formulario eliminación de servicios informáticos



N° Paso


10 Llega una nueva solicitud en OTRS a la cola Soporte Correo, la cual es bloqueada para empezar a ser atendida.

ACE

20 Con base en los datos suministrados por la unidad solicitante (en la herramienta de help desk OTRS), se inhabilita la cuenta para envío de correo a partir de la fecha indicada en el formulario. El buzón de correo no será eliminado en ese momento, se dará un plazo de 30 días naturales, excepto que explícitamente se indique otro plazo en la solicitud o que se indique que el buzón de correo se debe eliminar de forma inmediata.

ACE

30 Se registran los datos de la modificación del estatus del usuario de correo en la bitácora llamada Bitacora Usuarios Correo.

ACE

40 El ACE transfiere la información para que el usuario sea eliminado de los grupos de correo a los que pertenece el usuario.

AGC

50 30 días naturales después el buzón de correo se eliminará en forma permanente. Excepto que expresamente se indique lo contrario.

ACE


Eliminación de cuenta de correo electrónico

IICA_UTIC_MPR_PRD_ElCuCo Versión 2 Última modificación: Noviembre 2010



N° Paso


60 Se registran los datos de la eliminación permanente del buzón de correo en la bitácora llamada Bitacora Usuarios Correo.

ACE

70 Se añade una nota interna indicando las acciones realizadas, luego se pasa el ticket a la cola de trabajo correspondiente según se indica en la solicitud.

ACE



Creación cuenta de usuario de sistema de información

IICA_UTIC_MPR_PRD_UrSiIn Versión 2 Última modificación: Noviembre 2011



Nombre Procedimiento creación cuenta de usuario de sistema de información

Introducción Los sistemas de información son aplicaciones que facilitan el trabajo diario de los usuarios del IICA. Este procedimiento fue creado para documentar el proceso de creación de una nueva cuenta de usuario de un sistema de información cuya administración de usuarios se encuentre bajo la responsabilidad de la Unidad de Tecnología de Información y Comunicación. Cabe destacar que existen diversos tipos de aplicaciones y no en todas es necesario crear un usuario y clave particular para acceder a ellas, en algunos casos se puede ingresar indicando como ID de usuario la cuenta de correo electrónico y la clave de red (aplicativos de intranet), en otros casos se podrá acceder a los sistemas únicamente con un ID de usuario y una clave particular para ese sistema.

Objetivo Definir de manera detallada los pasos a seguir para crear una cuenta de usuario para acceder a un sistema de información.


ESI: Especialista en sistemas de información encargado de la aplicación.









N° Paso


10 Llega una nueva solicitud en OTRS a la cola Soporte Sistemas, la cual es bloqueada para empezar a ser atendida.

ESI

20 Con base en los datos suministrados, se crea el identificador de usuario y la clave, siguiendo los estándares y políticas utilizadas en TIC que se encuentran definidas en el documento Políticas y estándares para la creación de cuentas de usuario para los servicios informáticos.

ESI

30 Se registran los datos del nuevo usuario en la bitácora correspondiente ubicada en \\gaia2\DTIC\Bitacoras, esto de

ESI


Creación cuenta de usuario de sistema de información

IICA_UTIC_MPR_PRD_UrSiIn Versión 2 Última modificación: Noviembre 2011



N° Paso


acuerdo al sistema o aplicación que corresponda.

40 Se le asigna al usuario el rol solicitado y se actualiza la matriz de roles correspondiente.

ESI

50 En caso de ser necesario se coordina la instalación de la aplicación en la PC del usuario para que éste pueda acceder a la aplicación.

ESI

60 Se añade una nota interna indicando las acciones realizadas, en caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar de estado a Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

ESI



Solicitud de mantenimiento de un sistema de información

IICA_UTIC_MPR_PRD_SolMan Versión 2 Última modificación: Noviembre 2010

Elaborado por: Fabiola Badilla Aprobado por: Emmanuel Picado


Nombre Procedimiento solicitud de mantenimiento de un sistema de información.

Introducción Los sistemas de información son aplicaciones que facilitan el trabajo diario de los funcionarios del IICA. Este procedimiento fue creado para documentar el proceso de solicitud de mantenimiento de un sistema de información, esto incluye agregar, eliminar o modificar funcionalidades en los sistemas de información que se tienen en ambientes de producción. Aplica para cualquier sistema ya sea aplicación web o de escritorio. Los cambios podrán ser solicitados únicamente por los usuarios clave del área funcional, es decir, los dueños o administradores funcionales del sistema.

Objetivo Definir de manera detallada los pasos a seguir para solicitar trabajos de mantenimiento en los sistemas de información administrados por la UTIC.

Actores AFS: Administrador funcional del sistema

ESI: Especialista en sistemas de información encargado de la aplicación en la Unidad de Tecnología de Información y Comunicación.


Guía de usuario para formulario solicitud de cambios (en proceso de creación)

Formulario solicitud de cambios

Guía de usuario para formulario especificación de pruebas (en proceso de creación)

Formulario especificación de pruebas



Mantenimiento de un sistema de información: cualquier cambio (adicionar, eliminar o modificar) que se realice a un sistema de información que se encuentre activo (ambiente productivo).


N° Paso


10 Se ingresa en la aplicación de help desk denominada OTRS para generar una solicitud (ticket), donde se debe explicar claramente en qué consiste la modificación, adjuntando el formulario Registro de solicitud de cambio, debidamente lleno. (Ver Guía de usuario formulario solicitud de cambio). La solicitud debe colocarse en la cola denominada Soporte Sistemas o en su defecto a Soporte SAP si se trata de un cambio

AFS


Solicitud de mantenimiento de un sistema de información

IICA_UTIC_MPR_PRD_SolMan Versión 2 Última modificación: Noviembre 2010



N° Paso


específico en SAP (en este caso particular se debe llenar el Formulario único de consultas e incidencias).

20 En un plazo no mayor a 30 minutos la solicitud deberá ser tomada y bloqueada por el ESI responsable del mantenimiento de la aplicación.

ESI

30 Con base en los datos suministrados por el AFS, se analiza la solicitud y en caso de ser aceptada, se continúa con el paso N° 40, en cualquier otro caso, se devuelve la solicitud al AFS indicando las razones del rechazo y finaliza el procedimiento.

ESI

40 Se realizan las reuniones que sean necesarias con el AFS, para aclarar dudas con respecto a los requerimientos indicados en el formulario.

ESI

50 Se realizan los cambios solicitados al sistema de información. ESI

60 Se realizan pruebas preliminares para validar la solicitud de cambio. ESI

70 Se registran los cambios realizados en la bitácora de cambios del sistema de información correspondiente.

ESI

80 Los cambios se trasladan al ambiente de pruebas y se le indica al AFS, mediante un mensaje de correo electrónico a través del OTRS, que a partir de ese momento deberá proceder a realizar las pruebas correspondientes, cambiando el estado de la solicitud a Customer Action.

ESI

90 Se procede a ejecutar los casos de prueba y documentarlos de acuerdo a la solicitud de cambio inicial. Ver Guía de usuario formulario especificación de pruebas.

AFS

100 En caso de que se presenten errores en las pruebas, deben ser documentados. Ver Guía de usuario formulario especificación de pruebas.

AFS

110 Indicar al ESI el resultado de las pruebas realizadas. Si las pruebas fueron satisfactorias se autoriza el traslado del cambio al ambiente de producción y se cambia el estado de la solicitud a Pendiente Auto-close (1 día). Si por el contrario, el resultado de las pruebas fueron fallidas, entonces se repite el ciclo a partir del paso N° 40.

AFS



Cambio de funciones de usuarios de servicios informáticos

IICA_UTIC_MPR_PRD_CaFuUs Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento cambio de funciones de usuarios de servicios informáticos.

Introducción Es posible que un usuario del IICA cambie sus funciones por diversas razones, cuando esto sucede la Unidad de Tecnología de Información y Comunicación (UTIC) debe ser notificada formalmente del cambio, a partir de qué fecha se hace efectivo y si este cambio es temporal o permanente. De manera que se cuente con la información necesaria para realizar los cambios requeridos, en cuanto a grupos de correo, archivos compartidos, aplicaciones web, aplicaciones de escritorio o cualquier otra donde la administración de los usuarios se encuentre bajo la responsabilidad de la UTIC. Para esto es necesario que cada unidad de trabajo involucrada le indique a la UTIC los permisos y accesos que deben ser creados, modificados o eliminados.

Objetivo Definir de manera detallada los pasos a seguir para cambiar las funciones en servicios informáticos de los usuarios de estos servicios.

Actores UNR: Unidad responsable que solicita activación/desactivación del servicio (jefe o secretaria)

SPU: Soporte a usuarios

AUS: Administrador usuarios de red


AGC: Administrador de grupos de correo



AET: Administrador Extensiones Telefónicas

Glosario Responsable del grupo de correo: es la persona que dentro de una unidad de trabajo tiene la potestad de solicitar inclusiones o exclusiones de usuarios en los grupos de correo que esa unidad utiliza.

Administrador de grupos de correo: es la persona en la Unidad de Tecnología de Información y Comunicación que se encarga de darle mantenimiento a los grupos de usuarios existentes en el IICA, de acuerdo a las solicitudes que realicen los responsables de los grupos de correo.








N° Paso


10 Cada una de las dos unidades involucradas (la que finaliza relaciones laborales con el usuario y la que inicia relaciones laborales con el usuario) debe crear una solicitud (ticket) en la aplicación de help desk denominada OTRS, generando de esta manera la solicitud para crear, eliminar o modificar los servicios informáticos de un usuario. Esto se debe realizar al menos 3 días hábiles antes de que se haga efectivo el cambio. El objetivo es que cuando se haga efectivo el traslado, el tema de creación de nuevos accesos y la eliminación de accesos anteriores ya se encuentre resuelto.

UNR

20 La aplicación de help desk OTRS, notificará a los funcionarios de Soporte a usuarios la creación de la solicitud. En ese caso uno de ellos tomará el ticket para su atención. Si transcurrida una hora el ticket no ha sido seleccionado, el coordinador de soporte lo asignará a algún funcionario.

SPU

30 El funcionario TIC que atiende la solicitud coordinará internamente con cada uno de los encargados de los servicios informáticos, según fuese indicado en la solicitud (ticket) generada.

SPU

40 Si se realizan cambios a nivel de cuenta de red, Se debe tener en consideración que si se elimina la cuenta de red del ActiveDirectory, serán eliminados los accesos por VPN y a las aplicaciones de escritorio.

AUS

50 Si se realizan cambios en cuentas de correo electrónico ACE

60 Si se realizan cambios con respecto a los grupos de usuarios, éstos deben quedar debidamente documentados en la herramienta de administración de grupos de usuarios.

AGC

70 Si se realizan cambios con respecto a la cuenta de intranet, éstos se registran en la bitácora llamada Bitácora usuarios intranet, que se ubica en \\gaia\DTIC\Bitacoras. Cabe mencionar que al eliminar la cuenta de intranet se elimina automáticamente el acceso a los sistemas web en los que el usuario haya sido incluido con anterioridad. No así el registro del usuario dentro de cada sistema, por eso se recomienda además eliminar la cuenta de usuario definida en cada sistema (web o escritorio).

AIN

80 Si se realizan modificaciones relacionadas con accesos a diversas aplicaciones, se deben actualizar las bitácoras de cada aplicación según sea el caso. Cabe mencionar que solamente se hará en las aplicaciones cuya administración de usuarios sea responsabilidad de la Unidad de Tecnología de Información y Comunicación.

ASI






90 De ser necesario se deshabilita o elimina la extensión telefónica y se reactiva o crea una nueva extensión telefónica según sea especificado en cada una de las dos solicitudes.

AET

100 Una vez que se finaliza con la atención de cada solicitud, se actualiza el estado de ambos tickets en la aplicación de help desk indicando que su estado es pendiente auto-close, de manera que cada una de las solicitudes se cierre en forma automática al día siguiente.

SPU



Atención de Solicitudes de Soporte Técnico

IICA_UTIC_MPR_PRD_SoSoTe Versión 1 Última modificación: Diciembre 2011



Nombre Procedimiento atención de solicitudes de soporte técnico

Introducción La Unidad de Tecnología de Información y Comunicación (UTIC), es la responsable de atender las labores de mantenimiento tanto del hardware como del software que se utilizan en la Sede Central y en la Oficina Costa Rica. Las labores de mantenimiento y atención de solicitudes se limitarán única y exclusivamente al equipo oficial del Instituto y en ningún caso se utilizarán recursos del Instituto para atender problemas de software ilegal o hardware de uso personal de los usuarios del Instituto.

Objetivo Definir de manera detallada los pasos a seguir para atender una solicitud de soporte.

Actores USR: Usuario de plataforma tecnológica del Instituto

SPU: Funcionario de TIC que atiende una solicitud realizada por un usuario del Instituto.


Plataforma tecnológica: infraestructura (hardware y software) tecnológica.

Hardware: cualquier componente físico de un computador (monitores, teclados, CPU’s e impresoras, entre otros).

Software: cualquier programa que se encuentre instalado en el computador (procesador de texto, hoja electrónica, correo electrónico y sistema operativo, entre otros).

Software legal: es el grupo de programas de los cuales se cuenta con una licencia en el IICA que lo respalde.

Herramienta automatizada de help desk OTRS: Sistema informático que se accede vía web donde se deben registrar todas las solitudes de trabajo de la Sede Central dirigidas a la UTIC.

N° Paso


10 El usuario directamente ingresará a la herramienta automatizada de help desk para registrar su solicitud de servicio de soporte (crear un ticket) que debe agregar a la cola llamada Soporte TIC, para lo cual debe ingresar a la aplicación denominada OTRS, una vez que se registre en la aplicación, deberá especificar detalladamente y en forma clara su solicitud.

USR


Atención de Solicitudes de Soporte Técnico

IICA_UTIC_MPR_PRD_SoSoTe Versión 1 Última modificación: Diciembre 2011



N° Paso


20 El usuario crea la solicitud (ticket) en la cola Soporte TIC. SPU

30 La solicitud es seleccionada por un funcionario de soporte a usuarios. Si al cabo de una hora la solicitud no ha sido seleccionada, el coordinador de soporte designará directamente al funcionario de soporte a usuarios que atenderá la solicitud.

SPU

40 La solicitud es atendida por el funcionario de soporte a usuarios, en los casos donde se requiera trasladar el caso a un tercero, el funcionario de soporte a usuarios contactará al proveedor del servicio para explicar el problema y propiciar una atención oportuna del caso.

SPU

50 Una vez atendida la solicitud, el funcionario de soporte deberá agregar una nota en el mismo ticket explicando las acciones realizadas. Y le asignará el estado pendiente auto-close con lapso de 1 día (24 horas).

SPU

60 El usuario recibirá por correo una notificación indicando el cambio de estado (pendiente auto-close) y al día siguiente recibirá una nueva notificación indicando que el nuevo estado es cerrado exitosamente. En caso de que al usuario no le sea solucionado su problema, éste podrá reabrir la solicitud.

USR


Instituto Interamericano de Cooperación para la Agricultura Unidad de Tecnologías de Información y Comunicación

Manejo de extensiones telefónicas IICA_UTIC_MPR_PRD_ExtTel Versión 2 Última modificación: Agosto 2016



Nombre Procedimiento de administración de extensiones telefónicas

Objetivo Definir los procedimientos necesarios para la creación, modificación y eliminación de extensiones telefónicas para funcionarios de la Sede Central.

Alcance Personal interno de la Sede Central que requiera, o tenga asignada, una extensión telefónica.

Roles ASR: Administrador soporte redes.

Funcionario: Personal que haga solicitud de extensión telefónica.

ST: Soporte Telefónico


1. En el momento de la creación de extensiones se debe tener el número de cuenta a la que se cargaran las llamadas generadas por esa extensión, de otra manera no se crea la extensión, (con sus debidas excepciones).

2. Las modificaciones posibles para una extensión son: a. Nombre de la persona asignada a la extensión b. Cambio de modelo de teléfono. c. Cambio de características (desvíos, grupo de captura de llamadas, entre otros).

3. Si al final del día hubo creaciones, modificaciones o eliminaciones de extensiones, el ST envía un correo al encargado de las listas de extensiones institucionales. Además, se debe detallar un resumen de los cambios realizados (nuevas extensiones, personas asignadas, cuentas asignadas a extensiones).

Glosario UTIC: Unidad de Tecnologías de Información y Comunicación.

Herramienta automatizada de Help Desk OTRS: Sistema informático que se accede vía web donde se deben registrar todas las incidencias y solitudes de la Sede Central dirigidas a la UTIC.

N° Paso


Creación de extensiones telefónicas.

10 Crea una nueva solicitud en OTRS a la cola Soporte Telefónico, la cual contiene la solicitud de creación de la extensión telefónica.

Usuario

20 En caso que no se indique, solicita la cuenta a la que se va a cargar la extensión telefónica requerida.

ASR





N° Paso


30 Asigna la solicitud a ST ASR

40 Crea la extensión en la central telefónica. ST

50 Mediante una nota en la solicitud, detalla la extensión, persona asignada, modelo de teléfono.

ST

70 Crea buzón de voz (mensajería de voz) según los siguientes pasos:

1. Ingresa al sitio http://10.0.10.17/cgi_bin/webassistant/start 2. Ingresa en Configuración del Servidor/Crear un nuevo usuario. 3. Da clic en botón Ejecutar, llena formulario. 4. Da clic en Crear. 5. Completar todos los campos y finaliza dando clic en el botón Guardar, para salvar los cambios.

ST

80 Envía correo a persona asignada a extensión, indicando su nueva extensión y los pasos para acceder el buzón de voz.

ST

90 En caso que la solicitud forme parte del proceso de “Creación de usuarios servicios informáticos”, se añade una nota interna indicando las acciones realizadas, en caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar al estado Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

En caso que la solicitud no forme parte del proceso de “Creación de usuarios servicios informáticos”, se envía respuesta al usuario indicando que se creó la extensión y se cambia el estado de la solicitud a Pendiente Auto-close (1 día) en el OTRS.

ST

100 Actualiza la “Bitácora de extensiones telefónicas”, indicando las acciones realizadas.

ST

110 Notificación por correo al encargado de las listas de extensiones institucionales (0223 Operadora) informándole de la extensión creada y a qué departamento corresponde.

ST

Modificación de extensiones telefónicas

120 Crea una nueva solicitud en OTRS a la cola Soporte Telefónico, la cual contiene los nuevos requerimientos.

Usuario


140 Realiza modificación indicada en la solicitud del Usuario. ST





N° Paso


150 Mediante una nota en la solicitud, detalla la modificación realizada (las modificaciones posibles se detallan en la sección de Consideraciones Importantes)

ST


ST

170 Cuando aplique, envía correo a persona asignada a extensión, indicando su nueva extensión y los pasos para acceder el buzón de voz

ST

180 Notificación por correo al encargado de las listas de extensiones institucionales (0223 Operadora) informándole de la extensión modificada y a qué departamento corresponde.

ST

190 En caso que la solicitud forme parte del proceso de “Creación de usuarios servicios informáticos”, se añade una nota interna indicando las acciones realizadas, en caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar al estado Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

En caso que la solicitud no forme parte del proceso de “Creación de usuarios servicios informáticos”, se envía respuesta al usuario indicando que se modificó la extensión y se cambia el estado de la solicitud a Pendiente Auto-close (1 día) en el OTRS.

ST

Eliminación de extensiones telefónicas

200 Crea una nueva solicitud en OTRS a la cola Soporte Telefónico, la cual contiene los nuevos requerimientos.

Usuario


220 Elimina la extensión de la central telefónica ST

230 Mediante una nota en la solicitud, detalla la eliminación realizada ST


ST

250 Elimina buzón de voz (mensajería de voz) según los siguientes pasos:

1. Ingresa al sitio https://10.0.10.17/cgi_bin/webassistant/start 2. Ingresa en Configuración del Servidor 3. En la lista de usuarios busca el usuario que desea eliminar. 4. Selecciona de la lista el buzón de voz que desea eliminar

ST





N° Paso


Da clic en “Borrar Usuario”, y finalmente da clic en “Aceptar” para confirmar el procedimiento..

260 En caso que la solicitud forme parte del proceso de “Eliminación de usuarios informáticos”, se añade una nota interna indicando las acciones realizadas, en caso de que no quede nada pendiente para la atención de la solicitud se debe cambiar al estado Pendiente Auto-close (1 día) en el OTRS. Caso contrario, se deberá desbloquear la solicitud y pasarla a la cola correspondiente.

En caso que la solicitud no forme parte del proceso de “Eliminación de

usuarios informáticos”, se envía respuesta al usuario indicando que se eliminó la extensión y se cambia el estado de la solicitud a Pendiente Auto-close (1 día) en el OTRS.

ST

270 Notificación por correo al encargado de las listas de extensiones institucionales (0223 Operadora) informándole de la extensión eliminada.

ST


Controles

Control de “timestamp” en los documentos de Listas de extensiones

Registros

Bitácora de extensiones telefónicas

Lista de extensiones


Gestión TIC


Clasificación de información IICA_UTIC_MPR_POL_ClsInf Versión 1 Última modificación: Noviembre 2010



Política de clasificación de información Objetivo.

Establecer, aplicar y clasificar las categorías de la información, tanto la impresa como la electrónica de los sistemas informáticos que son administrados por Unidad de Tecnología de Información y Comunicación.

Alcance.

Esta política aplica a la información impresa y electrónica de la Unidad de Tecnología de Información y Comunicación del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Se excluye de esta política la información que se genera en los sistemas a los cuales se les da mantenimiento en la UTIC, la responsabilidad de clasificación de esta información es de la administración funcional de cada sistema. No obstante, a pesar de que el personal de la UTIC tenga acceso a la información almacenada en los diferentes sistemas, queda totalmente prohibido utilizar dicha información para fines personales.

Política general de clasificación de información.

Toda la información manejada por la Unidad de Tecnología de Información y Comunicación del IICA se clasifica en tres grupos, con base en su contenido. Estos grupos corresponden a:

Información confidencial.

Información para uso interno.

Información para uso público.

A continuación se detalla la normativa para clasificar la información en cada uno de estos grupos:


Este grupo de información posee un alto nivel de restricción para su acceso.

Esta información es de uso restringido para un grupo específico de personas, definido en forma explícita por la jefatura del área.

Esta información no puede ser divulgada a personas que no sean las autorizadas, por tener como consecuencia graves daños para la empresa, o para las instituciones relacionadas con el IICA. Estos daños pueden significar el comprometer la imagen institucional, el relacionamiento con otras instituciones y oportunidades de negocios entre otros aspectos.

Los tipos de información considerados en este grupo, corresponden a:

Información de auditoría.

Información de la Dirección General.

Informes gerenciales.





Información estratégica para el negocio.

Información de plan de mejoramiento de oficinas.

Informes de evaluación técnica.

Información relacionada con salarios del personal.

Información de detalle relacionada con los servicios tecnológicos de IICA, que pueda dañar la imagen institucional.

Información relacionada para el control de acceso a la plataforma computacional de IICA y a los servicios que ofrece, como por ejemplo perfiles de usuarios y listas de acceso de tráfico.

Información relativa a contratos con proveedores y empleados.


Este grupo de información posee un nivel medio de restricción para su acceso.

Esta información es de uso de la Unidad de Tecnología de Información y Comunicación del IICA y para las personas externas autorizadas por esta.

Esta información no puede ser divulgada por tener como consecuencia daños menores para el IICA, o para las instituciones relacionadas.


Memorandos.

Informes.

Correos.

Publicaciones.

Información relacionada al modelo operacional del negocio en detalle, como por ejemplo políticas, normas y procedimientos administrativos asociados a los procesos, y que sean de uso interno.

Información relacionada con la configuración de la plataforma computacional del IICA.

Información relativa a políticas, procedimientos y medidas de seguridad existentes en la unidad, que sean de uso interno.

Información de pagos a terceros.


Esta información puede ser usada por cualquier usuario dentro de la Institución.

La divulgación de esta información no provoca daños para la empresa, o para las instituciones relacionadas, no compromete la imagen corporativa de la empresa, la relación con otras instituciones, ni las oportunidades de negocios.






Normas.

Reglamentos.

Informes (Si se especifica que es para uso general).

Información en el web y la Intranet.

Otro tipo de información.

Generación y clasificación de la información.

Responsable de la información impresa: Funcionario que genera el documento.

Funcionario de la UTIC clasifica la información según su contenido, en una de las tres categorías existentes:




Para el caso de la información impresa clasificada como confidencial, uso interno y de uso público, el funcionario de la UTIC debe indicar en el documento su clasificación. Sin perjuicio de lo anterior, la información impresa de la UTIC generada por un tercero (informes de auditoría externa, ofertas de servicios, etc.) mantiene la clasificación que le otorgue el mismo, en caso de no tener clasificación la jefatura de la UTIC es responsable de clasificar el documento del externo acorde a lo estipulado en esta política.

El funcionario de la UTIC debe nombrar el documento interno de acuerdo a la estructura de codificación y disciplina.

Almacenamiento de la información.

Responsable: Funcionario de la UTIC.

Funcionario almacena la información de acuerdo a su clasificación:


Los documentos en formato electrónico deben ser almacenados en la carpeta personal o dentro del directorio correspondiente de la unidad en el File Server.

Los documentos impresos de la Unidad de Tecnología de Información y Comunicación del IICA, debe ser almacenada en caja fuerte, en un mueble de seguridad, o en un mueble metálico bajo llave.


Los documentos en formato electrónico, pueden ser almacenados en el File Server o en la Intranet.





Los documentos impresos de la Unidad de Tecnología de Información y Comunicación del IICA, deben ser almacenados en un lugar con acceso restringido, o bajo llave en caso necesario.


Los documentos en formato electrónico o impreso clasificada como uso público, pueden ser almacenados sin restricciones y se puede publicar en el Web.

Tránsito o distribución de la información.


La distribución de los documentos internos y/o públicos de la Unidad de Tecnología de Información y Comunicación del IICA, debe estar controlada a través de un acuerdo de confidencialidad u otro mecanismo que asegure la protección de la información entregada. No se restringe la entrega de ningún tipo documento, pero si es aplicado el criterio del responsable del mismo en la decisión final de entrega a terceros.

La información se distribuye sólo a las personas autorizadas por la Jefatura de la UTIC, considerando los siguientes aspectos según su clasificación:


Los documentos electrónicos se deben distribuir con una clave de seguridad la cual será provista por la herramienta de Microsoft Oficce (Word, Excel, PowerPoint) que se utilice. Esta clave de seguridad estará compuesta por letras y números, estará conformada por al menos 8 caracteres y en un archivo aparte debe ir la clave, el archivo será de tipo texto y será enviado por correo electrónico al destinario.

Los documentos impresos de la Unidad de Tecnologías de Información y Comunicación del IICA, transita y se distribuyen en sobre sellado y con constancia escrita de su recepción por parte del destinatario.


Los documentos electrónicos transitan y se distribuyen sin restricción.

Los documentos impresos transitan y se distribuyen con constancia escrita de su recepción por parte del destinatario.


Los documentos electrónicos y/o impresos transitan y se distribuyen sin restricciones.

Destrucción de la información.


Funcionario de la UTIC destruye la información de acuerdo a su clasificación:






Los documentos electrónicos, deben ser destruidos borrando la información de cualquier lugar donde se encuentre almacenado, incluyendo la papelera de reciclaje o inutilizando el medio que lo contiene.

Los documentos impresos, deben ser destruidos en forma manual, en al menos ocho partes, o en una máquina picapapeles.

Información para uso interno:

Los documentos electrónicos, deben ser destruidos borrando la información de cualquier lugar donde se encuentre almacenado, incluyendo la papelera de reciclaje o inutilizando el medio que la contiene.

Los documentos impresos, deben ser destruidos en forma manual, en al menos ocho partes, o en una máquina picapapeles.

Información para uso público:

Los documentos electrónicos, pueden ser destruidos sin restricciones, incluso puede ser reciclada.


Cambios de Emergencia IICA_UTIC_MPR_POL_CamEmr Versión 1 Última modificación: Noviembre 2010



Política de cambios de emergencia Objetivo. Asegurar ante una emergencia la continuidad de los servicios informáticos que se brindan en la Unidad de Tecnologías de Información y Comunicación.

Alcance. Esta política aplica a todo el personal que tenga a su cargo servidores, aplicaciones o servicios y sistemas de la Unidad de Tecnología de Información y Comunicación del IICA.


Procedimiento de cambios de emergencia Plan de continuidad de servicios informáticos

Políticas de cambios de emergencia

Se debe asegurar que exista un proceso para analizar y trabajar los cambios de emergencia, incluyendo la causa y la resolución de los mismos.

Se debe mantener un registro de los cambios de emergencia abiertos y resueltos.

Se debe revisar el estatus de los cambios de emergencia para confirmar que los procesos se lleven a cabo de una manera efectiva.

Se deben revisar las soluciones por cada cambio de emergencia, las cuales, en determinado momento, pueden originar una solicitud que deba ser rastreada y asociada con un incidente.

Se deben documentar los hallazgos y recomendaciones. Presentarlos a la Jefatura de la Unidad de Tecnología de Información y Comunicación del IICA para revisión y aprobación.

Se deben realizar revisiones del proceso de cambios de emergencia al menos una vez al año.

Se deben registrar los incidentes en el OTRS, en la sección de FAQ’s, indicando al menos fecha del incidente, cuál fue el incidente, cómo se originó, cómo se solucionó y el tiempo de resolución, entre otros.


Cambios de emergencia IICA_UTIC_MPR_PRD_CamEmr Versión 1 Última modificación: Noviembre 2010



Nombre Procedimiento de cambios de emergencia

Objetivo Describir el procedimiento de cambios de emergencia para servidores, aplicaciones o servicios y sistemas en el Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a todo el personal que tenga a su cargo servidores, aplicaciones y/o servicios de la Unidad de Tecnología de Información y Comunicación del IICA.


AS: Administrador de servidores.

AR: Administrador de respaldos.


A continuación se detallan los planes de recuperación existentes en la actualidad para la Unidad de Tecnología de Información y Comunicación del IICA:

Planes de recuperación de TI para servidores. Planes de recuperación de TI para aplicaciones o servicios. Planes de recuperación de TI para sistemas.


Política de cambios de emergencia

Plan de continuidad de servicios informáticos



N° Paso


10 Al presentarse una contingencia de tipo tecnológica, realiza el requerimiento al AS de manera directa.

AFS

20 Entrega al AS información detallada del incidente y el daño producido, lo que permitirá recuperar en el menor tiempo posible el proceso interrumpido.

AFS

30 Ingresa al servidor y verifica que los servicios se estén ejecutando. De igual manera, consulta el visor de eventos (Event Viewer de Windows Server 2003) y la bitácora de aplicaciones

AS





N° Paso


40 En el caso de que el servidor no tenga disponible algún servicio, se reinstala o repara el servicio que no está disponible. (Referencia documento: Planes de Recuperación de TI para Aplicaciones y Servicios).

AS

50 Si se tiene contacto con el proveedor se envía una consulta por la falla o error.

AS

60 En el caso que sea un error por pérdida de datos, se solicita el respaldo del día anterior al administrador de respaldo a través de una solicitud en la herramienta help desk (OTRS).

AS

70 Consulta la información solicitada en el registro de respaldos., recupera el archivo y lo extrae a una ubicación en la que el usuario lo pueda utilizar.

AR

80 Recupera el archivo y lo extrae a una ubicación en la que el usuario lo pueda utilizar (Procedimiento de respaldos, recuperación de respaldos). Se cierra el caso en la herramienta help desk (OTRS).

AR

90 En el caso que el servidor donde reside la aplicación o servicio no se restablezca por los respaldos, se debe disponer de un servidor con menos carga que pueda funcionar como servidor de contingencia.

AS

100 Se solicita el respaldo al AR para realizar copia de emergencia y duplicar el servidor que inicialmente tenía errores.

AS

110 Consulta la información solicitada en el registro de respaldos. AR

120 Envía la información solicitada al AFS. AR

130 Documentar el incidente en el OTRS en la sección de FAQ donde se deben indicar, los síntomas, el problema, la solución y cualquier comentario adicional (por ejemplo tiempo de resolución, fecha del incidente).

AS/AR/AFS


Nota: Las actividades a realizar en el caso de recuperación de servidores, aplicaciones o servicios y sistemas están detalladas en el apartado de consideraciones importantes.

Controles

Visor de eventos (Event Viewer de Windows Server 2003).





Bitácora de aplicaciones.

Respaldos.

Registros

Documentación del incidente en FAQ’s de OTRS


Gestión de activos de tecnología de información

IICA_UTIC_MPR_POL_GstAct Versión 1 Última modificación: Noviembre 2010



Política para la gestión de activos de tecnología de información

Objetivo.

Mantener un nivel apropiado de protección de los activos de tecnologías de información de la institución, de acuerdo a su criticidad.

Alcance.

Esta política aplica a todos los activos de tecnologías de información de la sede central oficina de Costa Rica y sitio alterno que maneja el Instituto Interamericano de Cooperación para la Agricultura (IICA), considerando como activo de tecnología de información cualquier elemento que tenga valor para la Institución desde el punto de vista tecnológico.


Política de adquisición de equipos de TI Procedimiento adquisición de equipos de TI Procedimiento gestión de activos de tecnologías de información

Política de gestión de activos de tecnología de información.

Anualmente se debe realizar una revisión al inventario de activos de tecnologías de información por proceso. Este inventario debe contemplar al menos:

Nombre del activo.

Responsable.

Custodio técnico.

Tipo de activo (información, software, hardware, servicios). A continuación se citan algunos ejemplos por tipo de activo:

Información: manuales técnicos, políticas y procedimientos de la Unidad de Tecnologías de Información y Comunicación del IICA.

Software: licencias de ofimática, licencias de SAP, aplicativos propios.

Hardware: servidores, notebooks, desktops.

Servicios: Internet, Intranet, comunicaciones, websense, active directory, e-courier y cualquier otro servicio que se incluya en el catálogo de servicios de la UTIC.

Impacto (en función de la confidencialidad, integridad y disponibilidad), este impacto puede ser: alto, medio y bajo.

Los activos de tecnologías de información incluidos en el inventario deben tener un funcionario responsable del mismo.



IICA_UTIC_MPR_POL_GstAct Versión 1 Última modificación: Noviembre 2010



Se deben definir reglas para el uso aceptable de los activos de tecnologías de información, las que deben estar identificadas, documentadas e implantadas, como por ejemplo reglas para el uso de Internet, correo electrónico, acceso físico al datacenter, respaldos, acceso remoto por VPN y adquisición de equipos TI.

Los criterios bajo los cuales se clasificarán los activos de tecnologías de información deben estar establecidos.

El tratamiento de la información dependerá de la clasificación asignada, considerando su administración, su transmisión y el medio en que reside.

La actualización del inventario de activos de tecnología de información y la clasificación de los activos de tecnologías de información se revisará de forma anual, en el mes de junio por parte de la Unidad de Tecnología de Información y Comunicación del IICA.

La salida o baja de los activos de tecnología de información se realizará bajo los siguientes criterios:

Los servidores se dan de baja cuando pasado el tiempo de garantía, presentan fallas críticas3 en el hardware o cuando cumplen un período mayor a 5 años (caso de servidores críticos) y son sustituidos de acuerdo al plan de reposición de equipos.

Las impresoras que no se encuentren bajo el sistema de leasing se dan de baja una vez que fallan y el arreglo tenga un costo mayor que el valor de la impresora.

Las desktop y laptop se dan de baja cuando pasado el tiempo de garantía, presentan fallas críticas o irreparables en el hardware o en su defecto son sustituidas de acuerdo al plan de reposición de equipos.

Los equipos de red se dan de baja cuando pasado el tiempo de garantía, presentan fallas críticas o irreparables o en su defecto son sustituidos de acuerdo al plan de reposición de equipos.

3 Fallas críticas: son fallas en el hardware cuyo costo de reparación es mayor o igual al valor del equipo.



IICA_UTIC_MPR_PRD_GstAct Versión 1.1 Última modificación: Noviembre 2010



Nombre Procedimiento gestión de activos de tecnología de información

Objetivo Describir el procedimiento de la correcta gestión de activos de tecnología de información de la sede central de Costa Rica y sitio alterno del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a todos los usuarios que tengan acceso a los activos de tecnología de información de la sede central de Costa Rica y sitio alterno del IICA.

Actores EGA: Encargado de gestión de activos de tecnología de información.

AUTIC: Asistente de la Unidad de Tecnología de Información y Comunicación.


1. Los activos fijos se encuentran debidamente plaqueados y este número de placa es el que se agrega al control de activos junto a su ubicación y responsable. Los encargados de plaquear los activos fijos son los funcionarios la División de Servicios y Apoyo Administrativo.

2. Los cambios en los equipos que se re utilizan se efectúan en el apartado de modificaciones del inventario de activos de tecnología de información.

3. El impacto del activo de tecnología de información se valoriza de acuerdo a la siguiente información:

Impacto alto: Se refiere a servidores en producción, router, switch de servidores, switch de DMZ, switch de usuarios de áreas críticas, ups, servidor de correo, central telefónica, SAN/DAS (arreglos de discos).

Impacto medio: Se refiere a equipos de ambiente de prueba, desktop y laptop de las unidades, licencias de software, teléfono ip y convencionales, impresoras multifuncionales.

Impacto bajo: switch de usuarios de áreas no críticas, impresoras, escáner, aparato de respaldos y el IPS.

Sin perjuicio del detalle anterior, los activos de tecnología de información que no están considerados en la clasificación de impacto se valorizan como impacto bajo.



Política de adquisición de equipos TI.

Procedimiento de adquisición de equipos TI


Control de activos en el help desk






OTRS: Módulo de gestión de configuración donde se tienen registrados todas las computadoras que hay en la sede central, así como impresoras, sistemas operativos, equipos de comunicaciones y redes.

N° Paso


Ingreso de activos de tecnología de información en el inventario.

10 Personal de la División de Servicios y Apoyo Administrativo lleva los activos de tecnología de información adquiridos para su configuración e ingreso en el sistema help desk.

En este paso se exceptúan los activos de tecnología de información de tipo Servicio.

EGA

20 Los activos de tecnología de información se ingresan en el sistema help desk en el módulo de elemento de configuración.

EGA

30 Se cataloga el activo de tecnología de información de acuerdo a los elementos existentes. A continuación se detalla los tipos de activos de tecnología de información en la dirección de informática y sistemas: computer, hardware, location, network, software, services.

EGA

40 Se ingresan los datos y especificaciones del activo de tecnología de información, dependiendo del elemento escogido.

En esta etapa debe ser ingresado el responsable del activo de tecnología de información y el impacto (acorde a la tabla de valores detallada en consideraciones importantes).

EGA

Modificación de inventario de activos de tecnología de información

50 En esta fase, se realizan modificaciones de las características de los activos de tecnología de información, de acuerdo a cambios internos en el IICA. Estas modificaciones se realizan directamente en el help desk.

EGA

60 Ingresar al help desk, al módulo de elementos de configuración. EGA

70 Realizar modificaciones, de acuerdo a los cambios de estado del activo de tecnología de información. Estas modificaciones pueden ser de especificaciones del activo de tecnología de información, cambio de responsable y el estado de implementación.

EGA






N° Paso


Validación de inventario de activos de tecnología de información. EGA

80 Anualmente, se debe realizar una validación del inventario de activos de tecnología de información existente en la Unidad de Tecnología de Información y Comunicación del IICA.

El resultado de esta revisión se debe reflejar en el inventario de activos de tecnología de información en el sistema help desk y en caso de que existan diferencias se debe indicar en las observaciones de la bitácora de revisiones.

EGA

90 Guardar registro de las actividades realizadas en la bitácora de revisión de activos del sistema help desk.

EGA

Salida de inventario de activos de tecnología de información (Baja). EGA

100 Una vez que un equipo se da de baja, se llena la boleta traslado de equipo y se entrega al asistente.


EGA

110 El asistente archiva la boleta de traslado de equipo.


AUTIC

120 Ingresar al help desk, al módulo de elementos de configuración. EGA

130 Realizar cambio en el Estado de Implementación a retirado y una justificación del retiro del activo de tecnología de información en el área de descripción.

EGA

Salida de computadoras en Unidades y Oficina de Costa Rica

140 Envía solicitud para eliminación de software instalado en equipo por OTRS y envía CPU a la UTIC

DA

150 Recibe equipo y realiza una revisión del equipo contra el inventario actual.

EGA

160 De encontrarse diferencias en la revisión, se deben anotar como observaciones en el área de descripción del activo.

EGA

170 Posterior a la revisión, debe hacer un formateo de bajo nivel EGA






N° Paso


180 Realiza cambio en el Estado de Implementación a retirado y una justificación del retiro del activo de tecnología de información en el área de descripción.

EGA

190 Responde al usuario, a través de la solicitud, indicando que el activo está listo para ser retirado. Dicha respuesta debe llevar copia obligatoria a los funcionarios de la División de Servicios y Apoyo Administrativo.

EGA


Controles

Validación del inventario de activos de tecnología de información.

Control de versiones.

Registros

Versiones en el help desk.

Archivo de boleta de traslado de equipo.


Adquisición de equipos TI IICA_UTIC_MPR_POL_AdqEqp Versión 1 Última modificación: Noviembre 2010



Política de adquisición de equipos TI

Objetivo.

Aplicar el mecanismo y los procedimientos adecuados para agilizar y maximizar los recursos institucionales asignados a la adquisición de equipo tecnológico, como software, hardware u otras herramientas que contribuyan con el desarrollo tecnológico del Instituto.

Alcance.

Esta política aplica a los funcionarios que entre sus funciones se encuentre la gestión de compras de los equipos tecnológicos en las diferentes unidades del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Documentos Relacionados.

Política de gestión de activos de tecnología de información. Procedimiento de gestión de activos. Procedimiento adquisición de equipos TI Manual de Adquisición de Bienes y Contratación de Servicios.

Políticas generales de UTIC.

La Unidad de Tecnología de Información y Comunicación del IICA, deberá planificar la actualización oportuna y la reposición del equipo tecnológico propios de la unidad y del datacenter para evitar la obsolescencia, mediante la revisión periódica de dichos activos.

La Unidad de Tecnología de Información y Comunicación del IICA, debe preparar anualmente un plan de reposición de los equipos a su cargo, el cual asegure la debida disponibilidad de los equipos y prestación del servicio. Este plan debe estar listo en el mes de octubre de cada año.

El plan de reposición de la UTIC debe establecer los objetivos, planes y tareas específicas, entendidas y aceptadas por la Unidad de Tecnología de Información y Comunicación y alineada con la planificación estratégica de la institución.

Para desarrollar el plan de reposición se deben determinar las necesidades y objetivos específicos que se requieren alcanzar, igualmente, se debe determinar si la necesidad que se pretende satisfacer está contemplada en el presupuesto aprobado.

Tomar en cuenta los siguientes criterios para el desarrollo del plan de reposición: responsable, producto o entregable, requerimientos de acuerdo al producto o entregable y justificación.

Toda reposición de equipo debe estar aprobada por la Jefatura de la Unidad de Tecnología de Información y Comunicación del IICA.


Adquisición de equipos TI IICA_UTIC_MPR_POL_AdqEqp Versión 1 Última modificación: Noviembre 2010



Cada vez que se compren equipos nuevos de red, se deben incluir dentro del plan de mantenimiento preventivo.

Los cambios de equipos deben responder al plan de reposición de equipos o cuando los mismos ya no cumplan con la prestación del servicio para el cual brindan apoyo.

De acuerdo con el Manual de Adquisición de Bienes y Contratación de Servicios es necesario contar con al menos 3 cotizaciones para compra de equipos TI.

Las compras de equipo que sean mayores a $30 000 dólares, deben realizarse por licitación, en este caso se debe involucrar al comité de compras y la unidad de servicios que se encarga de hacer las compras en la sede.

Los servidores más críticos de la unidad deben estar en garantía.

Políticas generales de las unidades del IICA.

Toda compra de equipo tecnológico en el Instituto deberá contar previamente con el aval técnico de la Unidad de Tecnología de Información y Comunicación.

La Unidad de Tecnología de Información y Comunicación, deberá asesorar y proveer los requerimientos técnicos, así como aprobar las compras de equipos de otras unidades de la sede central.

Las compras de equipos tecnológicos de las diferentes unidades del IICA, deberán realizarse conforme se establece en el Manual de Adquisición de Bienes y Contratación de Servicios.

La Unidad de Tecnología de Información y Comunicación, realizará una vez al año un estudio de necesidades tecnológicas, en cada una de las unidades del IICA, con el fin de determinar, orientar y maximizar el proceso de adquisición de equipos tecnológicos en el IICA.

Es recomendable que las unidades del IICA sustituyan anualmente el 25% o 30% de sus equipos (PC’s), de manera que los equipos siempre se encuentren en garantía. Este aspecto deberá ser considerado en el estudio de necesidades tecnológicas de las unidades del IICA.


Adquisición de equipos TI IICA_UTIC_MPR_PRD_AdqEqp Versión 1 Última modificación: Noviembre 2010



Nombre Procedimiento adquisición de equipos TI

Objetivo Describir el procedimiento de renovación de equipos en la dirección de informática y sistemas del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a todos quienes trabajen en la Unidad de Tecnología de Información y Comunicación y la División de Servicios y Apoyo Administrativo dentro del IICA.


EE: Encargado de equipos (equipo de redes, comunicaciones, servidores, laptops, desktops, dockings, impresoras y proyectores).

JUTIC: Jefe de la Unidad de Tecnología de Información y Comunicación.

DSAA: División de Servicios y Apoyo Administrativo

AUTIC: Asistente de Unidad de Tecnologías de Información y Comunicación


1. Los equipos antiguos (excepto servidores) se dejan para préstamo y los que tienen mayor antigüedad se envían a bodega. La División de Servicios y Apoyo Administrativo dispone del equipo de acuerdo a sus lineamientos. En caso de préstamo se debe seguir el procedimiento de gestión de activos en la sección de modificación de activos de tecnología de información. Si el activo se debe dar de baja seguir el procedimiento de gestión de activos en la sección de salida de inventario de activos (baja).

2. Generalmente, se solicitan 3 cotizaciones al adquirir equipos de TI. 3. Las compras se realizan una vez al año, a no ser que haya un proyecto específico que requiera una compra de equipo adicional.

4. Los servidores más críticos siempre deberán estar en garantía. 5. Se recomienda cambiar entre el 25% y 30% de las pc’s, procurando que los equipos estén siempre en garantía.


Política de adquisición de equipos TI.


Procedimiento de gestión de activos de tecnología de información.

Manual de Adquisición de Bienes y Contratación de Servicios.







SP: Solicitudes de pedido.

N° Paso


Solicitud de compra

10 Realizar una revisión del plan de reposición de recursos TI y un análisis de las características de los equipos que se necesitan.

EE

20 El EE presenta sugerencias al Jefe de la UTIC a partir del resultado del análisis hecho. Esto se realiza a través del correo electrónico.

EE

30 Se evalúan las sugerencias en reuniones con los responsables, acorde a lo estipulado en la política de adquisición de equipos y el plan de reposición. En caso de que exista presupuesto disponible, se aprueba la adquisición del equipo.

En caso contrario, se rechaza la solicitud de adquisición.

JUTIC

40 Una vez con la aprobación del Jefe de la UTIC, se debe comunicar a la unidad de servicios para que procedan con las cotizaciones.

EE

50

Una vez que se reciben las cotizaciones, el EE selecciona la mejor opción y recomienda al Jefe aquella que cumpla con todos los requerimientos técnicos.

EE

Creación SP.

60 Cuando se ha aprobado una compra para la Unidad de Tecnología de Información y Comunicación del IICA, debe notificar a la ADIS, para que proceda a crear la solicitud de pedido.

JUTIC

70 Si el activo tiene un costo mayor a $1000 dólares, solicita el número de empleado a quien le será asignado el activo, al Área de Operaciones de la Unidad de Finanzas.

AUTIC

80 Llena el formulario “Solicitud creación de activo fijo” y lo envía al Área de Activos de la Unidad de Finanzas, indicando entre otras cosas la cuenta presupuestaria, el número de empleado y nombre del encargado del activo. El formulario es devuelto a la UTIC con el número de activo asignado. Este paso se realiza siempre que el valor

AUTIC





N° Paso


de la compra sea mayor a $1000 dólares.

90 Crea solicitud de pedido (SP) en el sistema SAP y debe especificar claramente en la SP las observaciones que sean requeridas, tales como condiciones de pago, de envío y de compra.

AUTIC

Aprobación de SP.

100 Los aprobadores (el EE correspondiente y el JUTIC) deben validar la información de la solicitud de pedido. Una solicitud de pedido se considera aprobada cuando es autorizada por la totalidad de los aprobadores.

JUTIC/EE

110 En caso de que la solicitud de pedido haya sido rechazada, es recomendable que se contacte a los aprobadores para verificar el motivo de rechazo inicial y realizar las modificaciones necesarias para su aprobación.

AUTIC

120 En caso de aprobación de la solicitud de pedido, se debe generar un documento oficial (.pdf) de la solicitud de pedido autorizada.

Esta solicitud de pedido tendrá un número único y correlativo asignado por el sistema SAP.

AUTIC

130 Imprime la solicitud de pedido y la archiva.

Envía correo a la US con detalle del número de aprobación de la solicitud y adicionalmente adjunta las cotizaciones.

AUTIC

140 Recibe el equipo por parte del proveedor. DSAA

150 Entrega del equipo a la UTIC para su revisión, en caso de que el equipo cumpla con las características solicitadas se hace un recibido conforme y se inicia el procedimiento de gestión de activos. De lo contrario, se devuelve a la DSAA.

EE


Controles

Las compras de equipo que sean mayores a $30 000, deben realizarse por licitación, en este caso se debe involucrar al comité de compras y la unidad de servicios que se encarga de hacer las compras de la sede.





SP creada en el sistema y en línea con demás departamentos relacionados.

Aprobación del Jefe de la Unidad de Tecnología de Información y Comunicación del IICA.

Registros

SP en el sistema SAP.

Formulario de movimiento de equipo.

Formulario de “Solicitud Creación de Activo Fijo”.


Aplicación de actualizaciones de software

IICA_UTIC_MPR_PRD_ActSft Versión 1.1 Última modificación: Agosto 2016



Nombre Procedimiento aplicación de actualizaciones de software

Objetivo Describir el procedimiento de la correcta aplicación de actualizaciones de software a los funcionarios de la Unidad de Tecnología de Información y Comunicación del Instituto Interamericano de Cooperación para la Agricultura (IICA).

Alcance Este procedimiento aplica a las actualizaciones de los siguientes sistemas: Windows, SAP, SAPIENS, Ms SQL y sharepoint, administrados por la Unidad de Tecnología de Información y Comunicación del IICA.

Actores ESI: Especialista en sistemas de información.

APS: Administradores de plataforma y seguridad.

LF: Líder funcional.


Plan de continuidad de los servicios informáticos.


1. El sistema SAP está en un hosting con T-Systems México. Tienen la responsabilidad de administración de plataforma, incluyendo la aplicación de actualizaciones. Los parches del sistema SAP son Support Packages (SP), Parches individuales (notas) y Enhanced packages.

2. Aplicación de parches de los sistemas operativos se aplican para: Sharepoint y SQL Server.

3. Los parches al Sharepoint (servidor Argus) no se suelen aplicar, ya que alteran gran cantidad de la información.

4. IICA maneja la política de mantener la instalación en el nivel de parches en n-1.

5. En el caso específico de SQL Server, los parches se instalan cuando ocurren errores y/o problemas en los equipos.

6. Los service packs se instalan para mejora de rendimiento de sistemas, cubrir brechas de seguridad, aprovechamiento de recursos, entre otros. Su instalación se realiza después de 2 a 6 meses de ser liberados por Microsoft.

7. La aplicación de parches en SAPIENS deben instalarse en orden ascendente. Debe llevarse un control para evitar problemas de instalación.

Glosario Help desk T-Systems: Punto de contacto con T-Systems, que se accede vía teléfono (01 800 052 1195) o correos electrónicos [email protected] (soporte al sistema SAP) o [email protected] (mantenimiento de accesos a la VPN/SSL) donde se deben registrar todas las solitudes de trabajo de la sede central






dirigidas a T-Systems.

Notas: Correcciones puntuales a objetos de SAP.

Support Package: Conjunto de correcciones a objetos de SAP.

Enhanced Package: Mejora o nuevas funcionalidades de SAP.

AV: Antivirus.

SP: Support package.

N° Paso


Aplicación de parches al sistema operativo y AV en equipo con sistema SAP

10 T-Systems México envía la solicitud de la apertura del ticket por medio del correo electrónico para la aplicación de parches en el sistema operativo y/o AV en los equipos con sistema SAP.

T-Systems México

20 Los APS deben levantar tickets en el help desk T-Systems, gestionando “ventanas” para cambios ya sea de sistema operativo y/o AV en los equipos con sistema SAP.

APS

30 Una vez que se les ha notificado por medio de la solicitud (ticket) acerca de la apertura de la ventana de mantenimiento, procede con la aplicación de parches del primer servidor (ambiente desarrollo y ambiente calidad).

T-Systems México

40 Realizan seguimiento a la aplicación a través de la solicitud (ticket), una vez que reciben notificación de que los parches ya fueron aplicados en el primer servidor, cierran la solicitud.

APS

50 Como máximo después de tres semanas de haber sido aplicados los parches al servidor icadvw01 (Ambiente de desarrollo y calidad) deben generar otra solicitud (ticket) para abrir la ventana de mantenimiento para aplicar los parches en el servidor icadvw02 (ambiente de producción).

APS

Aprobación y solicitud de SP en equipo con sistema SAP

60 Verifica la aplicación de SP según planificación preestablecida por APS






SAP dos veces al año. SAP libera los SP acorde a la planificación.

70 Cuando se verifica que existe una nueva liberación de SP, se consulta vía correo electrónico a la gerencia del proyecto SAP en IICA, quienes deben autorizar la aplicación del SP.

APS

80 Una vez que se obtuvo el visto bueno de la gerencia del proyecto solicitan la aplicación por medio de una solicitud (ticket) en el help desk T-Systems.

Nota: Se debe hacer una solicitud (ticket) OSS por ambiente ya que los parches en el sistema se aplican por cada ambiente (desarrollo, calidad y productivo).

APS

Revisión de aplicación de SP en equipo con sistema SAP

90 Una vez que se realice la aplicación de SP, queda disponible en el primer ambiente y deben notificar por medio de una solicitud (ticket) a los APS si se presentó algún problema.

T-Systems México

100 En la aplicación de SP, los APS deben revisar los objetos del sistema que con la aplicación de los parches se puedan haber devuelto a versiones anteriores.

Deben revisar 3 transacciones principales:

SNOTE, aplicación automática de notas (parches individuales). Se valida a cuáles notas requieren volver a aplicarle una versión más nueva o cuáles ya quedaron obsoletas.

SPAU, objetos con modificaciones que se regresaron a otras versiones (tablas, todo tipo de objetos). Deben corregir lo que pueda afectar el sistema.

(A partir de la solución del SPAU, SAP genera una orden de cambio para los otros ambientes, por lo que quedarán todas las correcciones que los APS aplicaron en la aplicación del SP).

SPDD, ajuste de objetos del diccionario con modificaciones, también se revisa su totalidad.

APS

110 Una vez revisadas las transacciones de SNOTE, SPAU y SPDD, envían un correo a la gerencia de proyectos SAP indicando que ya fue aplicado el SP.

APS

120 Realizan la prueba en el ambiente de desarrollo LF






Aplicación de SP en calidad y productivo en equipo con sistema SAP.

130 Realizan pruebas a su sistema y notifican mediante correo electrónico que todo funcione.

LF

140 Posteriormente deben crear otro ticket en el help desk T-Systems para que procedan a aplicar el SP en el ambiente de calidad.

APS

150 Se procede a transportar los cambios realizados en las transacciones SNOTE, SPAU y SPDD al ambiente de calidad.

APS

160 Una vez que el SP haya sido aplicado en el ambiente de calidad, reciben notificación de T-Systems.

APS

170 Se realizan pruebas en el sistema y verifican que todo funcione. LF

180 Se debe crear solicitud (ticket) para proceder con la instalación en el ambiente productivo.

APS

190 T-Systems notifica que la instalación ya se realizó en el ambiente productivo.

T-Systems México

200 Se procede a transportar los cambios realizados en las transacciones SNOTE, SPAU y SPDD al ambiente productivo.

Informa mediante correo electrónico a los líderes funcionales que se realizaron las actualizaciones en el ambiente productivo.

APS

Aplicación de parches individuales (notas) en equipo con SAP.

210 Líder funcional indica que tiene algún problema de funcionamiento a través del OTRS.

LF

220 Se realiza análisis para verificar las notas que pueden ayudar a resolver el problema de funcionamiento.

APS

230 Si la nota requiere solamente ser descargada y aplicada, proceden a realizar la aplicación directamente en el ambiente de desarrollo.

APS

240 Si la aplicación de la nota o parche es por un problema funcional, se define el tipo de nota a aplicar, ya sea por medio de una investigación que realicen en el sitio de soporte de SAP, o por medio de una

APS






solicitud (ticket) de SAP y se aplica la nota con la SNOTE. El proceso puede ser completamente automático o parcial, según lo indicado en la descripción de la nota que está en el sitio de SAP.

250 Una vez que aplican la nota, el sistema automáticamente pide una orden de cambio, la cual proceden a completar.

APS

260 Después que la nota se aplicó, se comunica por medio de la solicitud en OTRS para que se realicen las pruebas en el ambiente de desarrollo.

APS

270 Realiza pruebas en el ambiente de desarrollo, y si todo funciona adecuadamente notifica su aprobación y paso de cambios a calidad mediante el seguimiento de la solicitud del OTRS.

En caso de que continúe el error en el funcionamiento del sistema, notifica mediante correo electrónico a los APS para su corrección (volver al paso 220).

LF

280 Se realizan pruebas en el ambiente de calidad y si se soluciona el problema se procede a comunicar a los APS para aplicar los cambios en el ambiente productivo.

En caso de que continúe el error en el funcionamiento del sistema, notifica mediante correo electrónico a los APS para su corrección (volver al paso 220).

LF

Aplicación de enhanced packages en equipo con sistema SAP.

290 Se define con SAP hosting por medio de correos electrónicos, acerca de qué se debe instalar.

Posteriormente se crea la solicitud (ticket) en el help desk T-Systems y se sigue el mismo procedimiento de aplicación de SP.

APS

Aplicación de parches de sistemas operativos para servidores

propios.

300 Los parches son aplicados luego de recibir el automatic update de Windows.

La configuración permite que se descarguen los parches pero no se aplican automáticamente. Previo a cualquier instalación de parches se revisan los boletines de seguridad de Microsoft, donde se verifica que sea seguro para el IICA aplicar los parches.

APS






310 La instalación se realiza de forma manual el segundo miércoles de cada mes en un servidor de prueba. Al transcurrir un tiempo prudencial de prueba sin generar problemas o errores, se aplica en el resto de los equipos, siendo el orden correcto: servidores de pruebas, servidores no críticos, servidores críticos. Las pruebas realizadas consisten en verificar que los servicios “levanten” bien una vez que sean actualizados los sistemas operativos.

APS

320 Las aplicaciones de parches a servidores se ejecutan durante el mes, el tiempo que transcurre entre la instalación de parches de las tres categorías de servidores mencionadas en el paso anterior es aproximadamente entre 1 y 2 semanas.

APS

Errores de aplicación de parches a sistemas operativos.

330 Si algún servicio presenta problemas, los usuarios deberían notificar para que el APS proceda a desinstalar el parche y ver si esto restablece el servicio.

Si se presenta algún error en la aplicación del parche éste se debe desinstalar.

En caso que esto no solucione el problema o más bien lo empeore, se debe investigar si existe una solución alternativa.

APS

Aplicación de actualizaciones para SQL Server.

340 Los parches y service packs para SQL Server son descargados manualmente del sitio de Microsoft, y son aplicados inicialmente en ambientes de pruebas.

Si no se presentan errores en equipo de prueba, se procede a la instalación en ambiente productivo, cuando no haya usuarios conectados.

No es frecuente que se presenten errores una vez que sean instaladas las actualizaciones, sin embargo si se presentan lo correcto es investigar el origen del error y buscar la solución adecuada.

APS

Aplicación de parches al Sharepoint.

350 En caso de que se apliquen puede darse de dos maneras:

Por actualización: Una vez que se notifica una actualización disponible, se procede con la aplicación manual, primero en un

APS






ambiente de prueba y si todo procede bien, se aplica en los ambientes correspondientes. Posteriormente realiza una revisión de las bases de datos y de la aplicación.

Por necesidad: En caso de presentarse un problema, se busca un parche que lo solucione, para esto, se visita el sitio del Sharepoint, se descarga el archivo y se aplica el ejecutable. Posteriormente se debe dar una revisión de las bases de datos y de la aplicación.

Aplicación de parches en SAPIENS.

360 Antes de la aplicación de un reléase debe verificarse si la versión que se desea instalar no fue aplicada antes y si el consecutivo está correcto.

APS

370 El archivo comprimido con extensión .jar usualmente contendrá una carpeta de fuentes, un documento extensión .doc con los cambios y documentación adicional del release, un archivo xml con la descripción de los archivos contenidos, y 2 archivos de comprobación para revisión de integridad del archivo (.sha1 y .md5).

APS

380 Utilizando FTP, se debe copiar la carpeta de archivos “fuentes” en el directorio wwwroot de coldfusion. Este proceso sustituiría solamente los archivos modificados.

APS

390 Se recomienda utilizar el mismo documento que viene en el release para llevar un control de los cambios que deben aplicarse al instalar cada release.

APS

400 El release podría traer una carpeta denominada asp_dbm que contiene los cambios en la base de datos. Esta carpeta tendrá un archivo .xml. Se debe ingresar al sistema SAPIENS, en la opción “Actualización del Modelo” y aplicar el cambio en la base de datos.

APS

410 También podría venir una carpeta SQLServer que contiene los scripts puntuales que deben hacerse para correrse en la base de datos para agregar, modificar o eliminar datos directamente en la base de datos. Estos son archivos .sql y deben ejecutarse en SQL Studio.

APS


Controles






Revisión de transacciones SNOTE, SPAU, SDDR.

Aprobación de aplicación de SP.

Todas las solicitudes y control de la aplicación que se maneja por el help desk T-Systems.

El líder funcional es el único que puede autorizar pasar las órdenes de cambio a productivo.

Registros

Orden de transporte de actualizaciones del sistema SAP.

Tickets de help desk T-Systems

Registros en Microsoft, o en las nuevas versiones de los SP instalados.

Instalación de parche al Sharepoint queda registrada en el control panel


Desarrollo y Mantenimiento de SI IICA_UTIC_MPR_PRD_ActSI Versión 1.2 Última modificación: Noviembre 2016



Nombre Procedimiento solicitud de sistemas nuevos o cambios en sistemas de información

Objetivo Brindar una guía detallada sobre los pasos que deben seguirse para solicitar un nuevo sistema o un cambio a un sistema de información.

Alcance Este procedimiento detalla los pasos a seguir para realizar una solicitud de desarrollo o mantenimiento a un sistema de información.

Actores ESI: Especialista en sistemas de información.

JUTIC: Jefe Unidad de Tecnología de Información y Comunicación

LF: Líder funcional. Usuario autorizado para solicitar sistemas de información, cambios o mejoras.


Procedimiento para solicitud de cambios en sistemas de información


1. Este procedimiento aplica para los sistemas desarrollados con recursos propios y aquellos externos cuyo mantenimiento sea responsabilidad de la UTIC.

2. Este procedimiento no aplica para la actualización de programas producto o desarrollos externos cuya responsabilidad esté a cargo de proveedores externos.

Glosario

N° Paso


Análisis de solicitudes

10 El usuario autorizado para solicitar un mantenimiento a un sistema de información debe enviar un correo electrónico a la Entidad Informática. Básicamente este documento tiene que especificar el tipo de acción (desarrollo o mantenimiento), el sistema de información que se desea modificar, una breve descripción del requerimiento, la unidad que está solicitando el cambio, el usuario clave que pide el cambio, y otra información que se considere apropiada.

El usuario que envía la solicitud debe contar con previa autorización o ser miembro del “Registro de Administradores de Sistema de Información”. Está lista indica que usuarios tiene autorización para solicitar cambios en los sistemas de información.

LF





20 En caso de desarrollo la jefatura de la UTIC procede a revisar la solicitud de desarrollo de sistemas y la asigna a un Especialista en Sistemas de Información (ESI).

En caso de mantenimiento el ESI responsable del sistema procede a priorizar la solicitud.

JUTIC

ESI

30 El ESI debe reunirse con el usuario que hizo la solicitud y realizar un análisis de los requerimientos. El ESI debe evaluar en este paso la factibilidad del completar o no la solicitud. En caso de que se decida que la solicitud no procede, se ejecuta el paso 90.

40 Basado en la reunión con el usuario clave, el ESI debe plasmar su análisis en un documento (Análisis de Solicitud) que detalle claramente cuáles son los requerimientos del usuario.

ESI

50 El ESI debe enviar el análisis de la solicitud al usuario, y concertar una nueva reunión con el usuario clave.

ESI

LF

Ejecución de solicitudes

60 Una vez que el usuario clave y el ESI están claros sobre el contenido del Análisis de la Solicitud, se procede a realizar una reunión en donde se determina quién va a realizar el mantenimiento y en que marco de tiempo.

ESI

70 El ESI a cargo debe coordinar la solicitud de mantenimiento con el usuario solicitante hasta que se concluya.

ESI

LF

80 El ESI informa al usuario que su solicitud ha sido completada y que debe ser probada. La prueba se hará en los ambientes de prueba.

LF

90 Si el usuario encuentra algún error en la solicitud o una omisión que se encuentre incluida en el Análisis de la Solicitud, debe avisar inmediatamente al ESI para realizar las correcciones del caso y devolverse al paso 80.

LF

ESI

100 Una vez que el usuario haya probado y aceptado la solución propuesta, el ETI procede a coordinar el paso de la modificación o desarrollo al ambiente productivo.

ESI

Paso de la modificación o desarrollo a productivo





110 Coordinar con los responsables para el paso a productivo. ESI


Controles

Solicitudes y control de la aplicación que se maneja por el help desk

Formulario de incidencias en SAP

El líder funcional es el único que puede autorizar pasar las órdenes de cambio a productivo.

Registros

Orden de transporte de actualizaciones del sistema SAP.


Anexos


Glosario


ACS (Access Control Server): política de control de acceso a la plataforma institucional, incluye acceso por VPN, acceso por red inalámbrica, control de acceso a la red y administración de dispositivos de red.

AD (Active Directory): es el término que utiliza Microsoft para referirse a la estructura jerárquica que permite mantener una serie de objetos relacionados con componentes de una red como usuarios, grupos de usuarios, permisos y asignación de recursos y políticas de acceso.

Ambiente de desarrollo: entorno de desarrollo (creación y modificación) de un sistema informático.

Ambiente de calidad: entorno de pruebas de un sistema informático.

Ambiente productivo: entorno de funcionamiento real de un sistema informático.

Antispyware: herramienta de software de detección de spyware (programas espías).

Antivirus: herramienta de software que permite prevenir, detectar y eliminar virus informáticos.

CISCO Systems: empresa multinacional dedicada a la fabricación, venta, mantenimiento y consultoría de equipos de telecomunicaciones.

Cliente VPN de CISCO: software que contiene una interfase de usuario que permite trabajar con conexiones seguras a redes privadas virtuales.

Conexión remota: conexión a través de Internet que permite trabajar con un computador en forma remota.

Datacenter: Centro de cómputo

Dirección IP: direcciones numéricas en los equipos de cómputo que permiten establecer la comunicación entre ellos en las redes, utilizan el protocolo de internet (IP Internet Protocol).

Help Desk OTRS (Open–source Ticket Request System): servicio de soporte automatizado, es un software de código abierto orientado a la gestión de tiquetes o requerimientos de usuarios. Esta herramienta es utilizada por la UTIC en la Sede Central para registrar todas las solicitudes de trabajo.

OSS (Online SAP Support): Servicio de soporte en línea que ofrece SAP a sus clientes, donde se pueden encontrar notas que solucionan problemas, pueden consultar errores, así como calendarios de liberación y soporte de versiones, entre otros.

PDU (Power Distribution Unit): Unidades de distribución de energía que contiene una entrada de electricidad y varias salidas como por ejemplo las regletas.


Ticket de OTRS: número de solicitud asignado automáticamente por el sistema OTRS cuando un usuario solicita un servicio o requerimiento.

UPS (Uninterrupted Power System): que por sus siglas en inglés significa Sistema de Potencia Ininterrumpida, es un dispositivo que puede proporcionar energía eléctrica a los dispositivos eléctricos que tenga conectados por un tiempo limitado en ausencia de electricidad (durante un apagón).

UTIC: Unidad de Tecnologías de Información y Comunicación

VPN (Virtual Private Network/Red Privada Virtual): es una tecnología de red que permite la extensión de la red local sobre una red pública como lo es internet. Un ejemplo puede ser la posibilidad de conectar dos o más sucursales de una empresa utilizando como vínculo internet.

VPN de acceso remoto: modelo de VPN donde los usuarios se pueden conectar a su organización o empresa desde sitios remotos utilizando internet para acceder a la red de su empresa y luego de autenticarse tendrán un nivel de acceso similar al que tienen en la red local de la empresa.

VPN IICA: nombre de la red privada virtual que permite la conexión remota con la infraestructura tecnológica del IICA.

VPN SAP: nombre de la red privada virtual que permite la conexión remota con los servidores de SAP que se encuentran en México.

Procedimientos y Políticas

Documents

Transcript of Procedimientos y Políticas