UNIVERSIDAD TECNOLÓGICA DE CHILE AREA INFORMÁTICA Y TELECOMUNICACIONES DISEÑO E IMPLEMENTACIÓN DE UNA NUEVA ESTRUCTURA DE RED EN REEMPLAZO DE DATACENTER Y CORREO CORPORATIVO ACTUAL
UNIVERSIDAD TECNOLÓGICA DE CHILE
AREA INFORMÁTICA Y TELECOMUNICACIONES
DISEÑO E IMPLEMENTACIÓN DE UNA NUEVA ESTRUCTURA DE RED EN
REEMPLAZO DE DATACENTER Y CORREO CORPORATIVO ACTUAL
Cristian Andrés Jara Espina
2014
UNIVERSIDAD TECNOLÓGICA DE CHILE
AREA INFORMÁTICA Y TELECOMUNICACIONES
DISEÑO E IMPLEMENTACIÓN DE UNA NUEVA ESTRUCTURA DE RED EN
REEMPLAZO DE DATACENTER Y CORREO CORPORATIVO ACTUAL
Trabajo de Titulación presentado en conformidad a los requisitos para obtener el
Título de Ingeniero en Telecomunicaciones, Conectividad y Redes.
Profesor guía: Sergio Cordero Leiva
Cristian Andrés Jara Espina
2014
AGRADECIMIENTOS
Desde niño tuve el sueño de progresar, ser mejor y convertirme en ingeniero. Sin
embargo, la vida se esforzó en enseñarme de que además debía aprender a
luchar por lo que quiero, no importa cuanto sea el tiempo y el esfuerzo invertido.
Fueron años de estudios, un paseo por varias instituciones y en paralelo una
carrera y crecimiento profesional importante. No obstante, los últimos 7 años de mi
vida he tenido la suerte de conocer y casarme con una compañera incondicional,
quien ha sacrificado tanto como yo para lograr este sueño y quien me ha ayudado
infinitamente a lograrlo. Ella ha sido quien me ha dado fuerzas cuando las he
necesitado, quien me ha entregado palabras veraces pese a la adversidad, quien
ha corrido a mi lado y me ha seguido y apoyado en cada una de mis locuras. Cada
vez que pensé que el sueño era inalcanzable y estuve a punto de no continuar,
ella fue quien con cálidas palabras siempre me dijo que podía seguir adelante, que
era capaz de llegar a la meta, conseguir hacer realidad mis sueños y mucho más.
Porque ha sido mi esposa quien me ha enseñado a creer en mí, a ser mejor
persona, a fijarme en los detalles, a crecer profesionalmente y amar
incondicionalmente entre tantas otras cosas.
Me gustaría no sólo dedicar esta memoria a ella, sino también todo el esfuerzo de
años que este libro representa, la materialización de una meta cumplida, un sueño
alcanzado y el cierre de un ciclo.
…A mi esposa, el gran pilar de mi vida y a Dios, quien me ha dado la oportunidad
de vivir y conocerla.
iii
ÍNDICE
RESUMEN............................................................................................................8
1. CAPíTULO I: INTRODUCCIÓN......................................................................13
2. CAPíTULO II : DESARROLLO DEL TEMA.....................................................14
2.1 Presentación Corporativa.............................................................................14
2.2 Situación Inicial.............................................................................................15
2.3 Plan de trabajo..............................................................................................15
2.4 Proveedores.................................................................................................16
2.5 Definición de tiempos y tareas del proyecto.................................................17
2.6 Solicitudes de Propuestas............................................................................17
2.7 Riesgos.........................................................................................................18
3. CAPÍTULO III : SOLUCIÓN.............................................................................19
3.1 Estructura técnica.........................................................................................19
3.2 Servicio de correo Google Apps...................................................................26
3.3 Desarrollo de la Planificación........................................................................28
4. CAPíTULO IV: FUNDAMENTOS TEÓRICOS EN REDES Y
COMUNICACIONES..............................................................................................34
4.1 Modelo OSI...................................................................................................34
4.1.1 Capa Número 1: Capa Física.................................................................35
4.1.2 Capa Número 2: Capa de enlace de datos............................................35
4.1.3 Capa Número 3: Capa de Red...............................................................36
4.1.4 Capa Número 4: Capa de Transporte....................................................36
4.1.5 Capa Número 5: Capa de Sesión..........................................................37
4.1.6 Capa Número 6: Capa de Presentación................................................37
4.1.7 Capa Número 7: Capa de Aplicación.....................................................38
4.2 ARQUITECTURA MODELO TCP/IP............................................................39
4.2.1 Capa Número 1: Capa de acceso a la red.............................................40
4.2.2 Capa Número 2: Internet........................................................................40
4.2.3 Capa Número 3: Capa de Transporte....................................................41
4.2.4 Capa Número 4: Capa de Aplicación.....................................................41
4.3 Comparativa entre Modelos OSI – TCP/IP...................................................42
4.4 Direccionamiento IP......................................................................................42
4.5 Clases de Direccionamiento IP.....................................................................43
4.5.1 Clase A...................................................................................................44
1
4.5.2 Clase B...................................................................................................44
4.5.3 Clase C..................................................................................................44
4.5.4 Clase D..................................................................................................44
4.5.5 Clase E...................................................................................................44
4.5.6 Broadcast...............................................................................................45
4.5.7 Loopback................................................................................................45
4.5.8 Máscara de Red.....................................................................................45
4.5.9 Subredes................................................................................................45
4.6 Multiplexación de datos................................................................................47
4.7 Descripción de Puertos.................................................................................48
4.7.1 FTP........................................................................................................48
4.7.2 SSH........................................................................................................48
4.7.3 Telnet.....................................................................................................49
4.7.4 SMTP.....................................................................................................49
4.7.5 DNS........................................................................................................49
4.7.6 DHCP.....................................................................................................49
4.7.7 TFTP......................................................................................................50
4.7.8 HTTP......................................................................................................50
4.7.9 POP3......................................................................................................50
4.7.10 NTP......................................................................................................50
4.7.11 IMAP....................................................................................................50
4.7.12 SNMP...................................................................................................51
4.7.13 LDAP....................................................................................................51
4.7.14 SSL/HTTPS..........................................................................................51
4.7.15 SQL......................................................................................................51
4.7.16 RDP......................................................................................................51
4.7.17 Asignación dinámica de puertos..........................................................52
4.8 Conceptos de Switching en una Red Ethernet.............................................53
4.9 VLAN............................................................................................................54
4.10 Routers.......................................................................................................54
4.10.1 Lógica para realizar el proceso de ruteo..............................................55
4.11 Tipos de redes............................................................................................55
4.11.1 LAN......................................................................................................55
4.11.2 WAN.....................................................................................................56
2
4.11.3 MAN.....................................................................................................56
4.11.4 VPN......................................................................................................56
4.12 Firewalls......................................................................................................56
4.12.1 Tecnologías Firewall............................................................................57
4.12.2 Objetivos de un Firewall.......................................................................57
4.12.3 Cinco Métodos de Tecnología Firewall................................................58
4.12.4 NAT......................................................................................................60
4.12.5 VPN......................................................................................................60
4.12.6 Tipos de Tecnología VPN....................................................................61
4.12.7 IPSec....................................................................................................61
4.12.8 SSL......................................................................................................61
4.12.9 MPLS...................................................................................................62
4.13 Tipos de VPN..............................................................................................62
4.13.1 Remote-Access....................................................................................62
4.13.2 Site-to-Site...........................................................................................62
4.13.3 Principales beneficios de las VPN........................................................62
4.14 Criptografía.................................................................................................63
4.14.1 Keys.....................................................................................................63
4.14.2 Private Keys.........................................................................................63
4.14.3 Public Keys..........................................................................................64
4.14.4 Session Keys.......................................................................................64
4.14.5 Certificados..........................................................................................64
4.14.6 Firmas digitales....................................................................................64
4.14.7 Kerberos...............................................................................................64
4.14.8 Especificaciones Adicionales al Protocolo IPSec.................................65
4.14.9 Protocolos IPSec..................................................................................66
5. CAPíTULO V: FUNDAMENTOS TEÓRICOS en sistemas OPERATIVOS.....68
5.1 Windows Server 2003...................................................................................68
5.1.1 Modo Usuario.........................................................................................69
5.1.2 Ambiente de subsistemas......................................................................69
5.1.3 Subsistema Integro................................................................................70
5.1.4 Modo Kernel...........................................................................................71
5.1.5 I/O manager...........................................................................................71
5.1.6 Referencia de Monitor de Seguridad......................................................71
3
5.1.7 Administrador de comunicación de Interprocesos.................................71
5.1.8 Administrador de Memoria o Administrador Virtual de Memoria............72
5.1.9 Administración de Procesos...................................................................72
5.1.10 Administrador de Plug and Play...........................................................72
5.1.11 Administración de Poder......................................................................72
5.1.12 Administrador de ventanas y Dispositivo de Interfaz Gráfica (GDI).....72
5.1.13 Administrador de ventana....................................................................72
5.1.14 GDI.......................................................................................................73
5.1.15 Administrador de objetos......................................................................73
5.1.16 Drivers de Dispositivo...........................................................................73
5.1.17 Microkernel...........................................................................................73
5.1.18 Capa de abstracción de hardware.......................................................73
5.1.19 Arquitectura de Procesamiento............................................................73
5.1.20 Administración de Memoria..................................................................74
5.2 Active Directory.............................................................................................74
5.2.1 Modelo de Datos....................................................................................75
5.2.2 El Modelo Organizacional......................................................................75
5.2.3 El Modelo de Seguridad.........................................................................75
5.2.4 El Modelo Topológico.............................................................................75
5.3 Arquitectura Active Directory........................................................................76
5.3.1 Bosques (Forests)..................................................................................76
5.4 Controladores de Dominio............................................................................76
5.4.1 Catalogo Global.....................................................................................77
5.4.2 Sites.......................................................................................................77
5.5 FSMO...........................................................................................................77
5.6 Maestros de Operación a Nivel de Bosque..................................................78
5.6.1 Maestro de esquema (Schema Master).................................................78
5.6.2 Maestro de nombres de Dominio (Domain Naming Master)..................78
5.7 Maestros de Operación a Nivel de Dominio.................................................78
5.7.1 Maestro RID (Relative Identifier Master)................................................78
5.7.2 Maestro de Infraestructura (Infrastructure Master).................................78
5.7.3 Maestro controlador Principal de Dominio (Primary Domain Controller Emulator).........................................................................................................79
5.8 Dominios.......................................................................................................79
5.9 DNS..............................................................................................................79
4
5.9.1 Tipos de registros...................................................................................81
5.9.2 Resolvers, Name Servers, Forward Lookup..........................................81
5.9.2 DHCP.....................................................................................................82
5.10 Radius.........................................................................................................83
6. CAPíTULO VI:FUNDAMENTOS TEóRICOS GESTIÓN DE PROYECTOS....84
6.1 Definición de Proyecto..................................................................................84
6.2 Dirección de proyectos.................................................................................84
6.3 Planificación Estratégica...............................................................................85
6.4 Ciclo de vida de un proyecto.........................................................................86
6.4.1 Interesados............................................................................................86
6.4.2 Proceso de planificación........................................................................86
6.4.3 Grupo del Proceso de Ejecución............................................................87
6.4.4 Proceso de Seguimiento y de control.....................................................87
6.4.5 Grupo proceso de cierre.........................................................................87
7. CAPíTULO VII: DESARROLLO EXPERIMENTAL..........................................88
7.1 Aplicaciones críticas.....................................................................................88
8. CAPíTULO VIII: ANÁLISIS DE RESULTADOS..............................................94
8.1 Resultados DE PRUEBAS INICIALES.........................................................94
8.2 Inconvenientes Registrados..........................................................................96
9. CAPíTULO IX: ASPECTOS ECONOMICOS Y RENTABILIDAD DEL
PROYECTO...........................................................................................................97
9.1 Carta Gantt...................................................................................................97
9.2 Diagrama de Red del Proyecto...................................................................100
9.3 Flujo Neto de Fondos y Análisis de Rentabilidad.......................................102
9.4 Análisis de Rentabilidad.............................................................................103
10. CAPíTULO X : CONCLUSIONES..............................................................104
11. CAPíTULO XI: REFERENCIAS BIBLIOGRAFICAS...................................106
12. CAPíTULO XII : ANEXOS..........................................................................107
12.1 Presupuesto Global y Local......................................................................107
12.2 Resumen de Propuestas..........................................................................108
13. CAPíTULO XIII : Acrónimos.......................................................................109
5
ÍNDICE DE FIGURAS
Figura 1.1 Diagrama de Datacenter Actual en Suecia………………………………….. 08
Figura 1.2 Diagrama resumido para el flujo de datos a Datacenter…………………… 10
Figura 1.3 Diagrama de Sites entre la versión anterior y la nueva estructura……….. 11
Figura 2.1 Cláusula de Contrato SYSTeam……………………………………………… 15
Figura 3.1 Diseño de granja de Servidores en Datacenter…………………………….. 20
Figura 3.2 Conexión VPN de Oficinas en el Mundo…………………………………….. 22
Figura 3.3 Interconexión de Firewalls de Oficinas a Núcleo WAN……………..……… 23
Figura 3.4 Interfaz web de Aplicación Corporativa………………………………………. 24
Figura 3.5 Esquema de Unidades Organizaciones de Active Directory………….…… 25
Figura 3.6 Directivas de Grupo del Dominio……………………………………………… 26
Figura 3.7 Control de Replicación en consola Active Directory Sites and Services.... 31
Figura 3.8 Registros MX en proveedor DNS SpeedNames.Net………………...……… 33
Figura 4.1 Modelo OSI……………………………………………………………………… 34
Figura 4.2 Comparación de Modelos TCP/IP………………………..…………………… 39
Figura 4.3 Comparación entre modelo OSI y ambos modelos TCP/IP……………..… 42
Figura 4.4 Estructura de cada una de las clases A, B y C…………………………….... 46
Figura 4.5 Estructura de una dirección IP con subred…………………………………... 46
Figura 5.1 Muestra la arquitectura base para Windows Server 2003……………….... 69
Figura 5.2 Árbol DNS……………………………………………………………………….. 76
Figura 5.3 Ilustración del procedimiento de resolución DNS…………………………... 82
Figura 7.1 Conexión de Túneles VPN…………………………………………………….. 89
Figura 7.2 Configuración de Túneles VPN……………………………………………….. 89
Figura 7.3 Replicación de esquema Active Directory……………………………………. 92
Figura 7.4 DNS Forwarders………………………………………………………………… 92
Figura 7.5 Maestro Esquema Definido para la Nueva Estructura de Red…………..… 93
Figura 8.1 Gráfico de los datos obtenidos………………………………………………... 95
Figura 8.2 Registro de Actividad de los usuarios………………………………………… 95
Figura 9.1 Vista Global de Carta Gantt……………………………………………………. 97
Figura 9.2 Tareas Asignadas en Carta Gantt…………………………………………….. 98
Figura 9.3 Organigrama Área Informática LCL Chile……………………………………. 99
Figura 9.4 Método de Roy aplicado a las tareas del Proyecto…………………………. 10
6
1
ÍNDICE DE TABLAS
Tabla 4.1 Ejemplos de protocolos y dispositivos por capa en modelo OSI……... 38
Tabla 4.2 Ejemplos de protocolos en Arquitectura de Modelo TCP/IP…………… 41
Tabla 4.3 Ejemplos de Números de Puertos conocidos……………………..….…. 48
Tabla 5.1 Muestra los sistemas soportados por el ambiente de subsistema…..... 70
Tabla 5.2 Subsistemas Integrales…………………………………………………….. 70
Tabla 5.3 Dominios originales de nivel superior…………………………………...... 80
Tabla 7.1 Mediciones de conexión al Datacenter……………………………………. 90
Tabla 7.2 Nuevas Mediciones a los Nuevos Núcleos WAN………………………... 91
Tabla 9.1 Detalle de tareas del proyecto…………………………………………….... 100
Tabla 9.2 Flujo Económico del Proyecto……………………………………………… 102
Tabla A.1 Resumen de Presupuesto LCL………………………………………….…. 107
Tabla A.2 Costos de cada solución por proveedor……………………………….….. 108
7
RESUMEN
El directorio de la corporación NYK Japón, toma la decisión de vender una de las
compañías de su holding llamada LCL Logística Chile Ltda. A nuevos accionistas
en nuestro país, Chile. En base a estos hechos, el nuevo directorio determina un
plan de acción para disminuir costos y así evitar pérdidas innecesarias. El área TI
fue involucrada en éste plan, cuya solución y nuevo diseño propuesto al
requerimiento de gerencia dan origen al presente proyecto.
De ésta forma, esta memoria presentará un escenario inicial con un Datacenter
ubicado en Suecia, administrado por la empresa SYSTeam. LCL cuenta con varias
filiales y cada una de ella tiene sus respectivos centros de datos conectados al
Datacenter, entre ellos Chile y Estados Unidos. En el desarrollo del documento se
apreciará un proceso de transición, junto al diseño y migración a una nueva
infraestructura de las Tecnologías de la Información y Comunicaciones (TIC’s) que
deberá mejorar el rendimiento y disminuir considerablemente los costos del área.
Así, el proyecto comienza con diferentes alternativas de solución que deben
mejorar o igualar los servicios entregados por el Datacenter actual. En la siguiente
Figura 1.1, se destacan los servidores, funciones y servicios entregados por el
proveedor del centro de datos contratado actualmente.
INTERNET
Sharepoint Base de Datos
Spamfilter Servidor de correo Primario
Servidor de correo Secundario
Servidor de DominioPrimario
Servidor de DominioSecundario
Servidor de Actualizaciones
ServidorTécnico IT
Firewall CISCO ASA
5510
- Usuarios Remotos- Correo en Smart Phones- Conexión VPN Cliente
Sitios Remotos
Figura 1.1 Diagrama de Datacenter Actual en Suecia
8
Existen varias alternativas de solución, aunque los costos asociados determinarán
la viabilidad futura del proyecto:
Contratación de nuevo Datacenter en Chile, con los mismos servicios e
igualdad de condiciones al anterior Datacenter (ver Fig. 1.1).
Las siguientes soluciones involucran una nueva re-ingeniería de los actuales
recursos:
Contratación única de servicio de correo en un Nuevo Datacenter
Buscar soluciones alternativas de correo y diseñar un nuevo centro de
datos interno.
Éste proyecto está basado en Tecnología de Software de Servidores y Equipos de
Comunicaciones en Redes LAN. Se proporcionará información adicional respecto
a elementos de Gestión de Proyectos y Análisis de Costos, pero no será un
proyecto basado en estos antecedentes. Información, tablas, gráficos,
cotizaciones a proveedores, Contrato con Datacenter anterior, Documentos de
análisis de las diferentes soluciones y el documento de solicitud a nuevos
proveedores (Request for Proposal, RFP) previo serán presentados como
evidencia de estos temas, aunque manteniendo cierto grado de reserva por la
confidencialidad de los datos corporativos.
La documentación utilizada para el desarrollo técnico de la tecnología en
servidores será basada en Microsoft, específicamente en sus cursos de
entrenamiento para Implementación y Mantención de Servidores. Para el caso de
los equipos de comunicaciones, se utilizará la documentación de los cursos de
CISCO correspondientes al grado de certificación CCNA Routing & Switching y
Security, agregando el curso de Administración de PIX y ASA. Documentación
técnica de IEEE e ITU serán agregadas para entregar referencias técnicas sólidas
y entreguen mayor objetividad y valor agregado al trabajo realizado.
9
Recepción de Informaciónpor usuario final
Flujo de Información
crítica vía VPN
Acceso a Servidores
Solicitud Servicios por Usuario y Servicios Red
Así, tendremos que el objetivo general del proyecto será diseñar e Implementar
una nueva solución que reemplace el actual Datacenter y el Correo Corporativo.
Acorde al objetivo descrito, deberemos cumplir con el flujo de información
previamente establecido por la organización, acorde a la siguiente Figura 1.2:
Figura 1.2 Diagrama resumido para el flujo de datos a Datacenter.
La nueva solución debe mantener la misma estructura de flujo de datos, o elevar
su disponibilidad. El diagrama topológico para ambas redes, tanto la del centro de
datos anterior como la del nuevo serán agregados apropiadamente.
Los objetivos específicos del proyecto serán:
Analizar las condiciones del Datacenter actual.
Disminuir Costos Fijos en departamento TI cuanto sea posible.
Buscar nuevos proveedores TI para reemplazar la solución actual de
Datacenter por los mismos servicios, o bien, buscar nuevos proveedores
que entreguen sólo la solución de correo corporativo a un menor costo.
Estudiar la información y determinar la nueva solución para la compañía.
Analizar costos y viabilidad.
Implementar nueva solución de Datacenter aceptada por gerencia, lo que
incluye una nueva topología interna para un site en Chile y otro en USA,
utilizando los mismos recursos con que la empresa cuenta en este minuto.
10
Contribución Esperada
En términos cualitativos: Mejora en la percepción del usuario tanto en la utilización
y rendimiento del correo electrónico versus el sistema de correo anterior.
En términos cuantitativos: Disminución importante de los costos asociados en la
nueva estructura. La evidencia se presentará con una tabla comparativa para
demostrar el ahorro efectuado entre el antigüo Datacenter y la nueva estructura
de red. La topología de la figura 1.3 muestra la diferencia en términos generales
de ambos esquemas.
Figura 1.3 Diagrama de Sites entre la versión anterior y la nueva estructura.
Metodología
Bajo la corporación anterior, los estándares de informática y su metodología se
rigen bajo los procedimientos internacionales J-SOX (Japan Sarbanes Oxley) que
corresponde a la versión Japonesa de SOX (Ley de USA también denominada
‘Public Company Accounting Reform and Investor Protection Act’). La migración
propone mantener estos estándares para toda la organización, sin modificaciones
en el corto plazo.
11
Para el desarrollo del proyecto, técnicamente será basado en la metodología de
trabajo y procedimientos definidos por Microsoft para la nueva estructura de
servidores. En cuanto a infraestructura de red, se diseñará una solución que
permita conectividad y crecimiento a futuro, ya sea por apertura de nuevas oficinas
o conectividad de nuevos usuarios remotos.
Tareas
Dentro de las tareas a realizar, se pretende:
Estudiar la situación actual de la red de datos e infraestructura de
equipamiento.
Investigación y análisis de nuevos proveedores y soluciones.
Entregar un reporte con las posibles soluciones a gerencia para determinar
una solución final.
Implementación de la nueva solución.
Con todos los puntos explicados hasta aquí, tendremos una vista completa del
desarrollo del proyecto, desarrollo e intenciones que persigue. La última fase del
proyecto mostrará la implementación de la nueva solución informática,
evidenciando una gestión del proyecto tanto a nivel técnico como organizacional,
demostrado a través del esfuerzo coordinado entre personal del Datacenter
anterior y el nuevo proveedor de servicios, así como el desarrollo de reingeniería
para los pequeños centros de datos corporativos que reemplazarán el Datacenter
anterior.
12
1. CAPÍTULO I: INTRODUCCIÓN
Cada empresa necesita contar con un sistema de tecnologías de información y
comunicaciones (TIC’s) adaptadas a su negocio, de tal forma que le permita
intercambiar datos con clientes y proveedores, desarrollando así correctamente el
núcleo de su propósito. Desde aquí podemos analizar un principio básico que ha
ido tomando fuerza los últimos años, principio que corresponde a la integración de
las TIC’s con el negocio de la compañía.
Cada herramienta TIC que se utiliza dentro de la empresa corresponderá a un
recurso valioso, tanto para la administración de información como para los
reportes que éstas pudiesen generar. Provocando un retorno de inversión
significativo no sólo en términos de retroalimentación positiva, sino que provee
métodos de análisis con una correcta lectura. De esta manera, la correcta
utilización y configuración de la tecnología resulta ser clave. Es vital que toda
herramienta TIC esté normalizada y en línea con el negocio, por ello el papel del
departamento de informática se aleja de ser un ente que asume ciertas tareas,
convirtiéndose en una unidad fundamental del negocio mismo.
En éste trabajo se podrá estudiar cómo se puede aplicar una reingeniería con los
recursos ya disponibles dentro de la empresa, además de proveer importante
información teórica como base sólida especificada para todo el proyecto.
El desarrollo teórico y técnico que se experimentará en el proceso de migración
del Datacenter en el extranjero hacia una nueva plataforma conjunta de Servidores
Internos en diferentes oficinas de la empresa, localizadas en diferentes partes del
mundo, sumando el servicio externalizado de correos Google Apps y su suite de
aplicaciones empresa, mostrará un proceso en el que se debe reunir información
del negocio de la compañía, aplicar re-ingeniería, recopilar nueva información
técnica, además de exponer capas de de ejecución y gestión del trabajo.
13
2. CAPÍTULO II: DESARROLLO DEL TEMA
2.1 PRESENTACIÓN CORPORATIVA
LCL Limitada es una compañía que se dedica a transportar carga entre diferentes
países, siendo su principal fortaleza el transporte de fruta fresca a través del
océano. Entre los productos típicamente exportados encontramos la palta,
arándanos, frutillas, naranjas y uva entre otros.
El negocio es una unidad compleja. Mientras que una naviera atiende únicamente
clientes grandes que ocuparán buena parte de la nave mercante, LCL se dedica a
comprar cierta cantidad de espacio a la naviera, agrupando a una gran cantidad
de pequeños productos que desean exportar su producto. Como empresa
logística, LCL puede proveer todas las unidades de negocio de exportación, tales
como la entrega de seguros asociados, transporte terrestre, servicios de frigorífico,
documentación aduanera, el proceso de exportación marítima y el contacto con
cliente final.
LCL tiene su casa matriz en Chile y sucursales en Perú, Ecuador, Costa Rica,
Estados Unidos, Holanda y Sudáfrica. El dueño de esta empresa es la gran
corporación multinacional NYK, dedicada al negocio naviero y transporte de carga
internacional, cuyos cuarteles centrales están localizados en Tokio, Japón.
El negocio de LCL es muy dinámico, por lo que la información debe viajar muy
rápido y estar siempre disponible. Un ejemplo es el envío de documentación, si no
es posible enviarla a tiempo, un buque podría no zarpar en el horario previsto lo
que provocaría retrasos importantes y por supuesto, elevados costos en multas
por parte del terminal portuario, el equipamiento para mantener la fruta, arriendo
de espacio en el puerto, etc. Por lo tanto, es de vital importancia la disponibilidad
de los servicios informáticos que procesan información tanto en la oficina de
origen como de destino, el servicio de correo electrónico y datos del usuario final.
14
2.2 SITUACIÓN INICIAL
NYK ha decidido vender LCL Limitada. Los nuevos dueños corresponden a un
grupo de inversionistas representados por el accionista mayoritario: Señor Miguel
Quezada Sciaraffia.
Durante los últimos meses del año 2010, LCL ha mantenido una tendencia a la
baja en la venta de sus productos. Por ello, tras la venta de la compañía, los
nuevos dueños dispondrán de un plan de acción a fin de evitar pérdidas
innecesarias y llegar a un “punto muerto”, término financiero que define la posición
de una empresa sin utilidades pero tampoco con pérdidas.
Así el departamento de informática realizará un ahorro importante de costos tanto
en contratos de servicio, licencias, etc. El más importante de todos los ahorros, es
una reducción en los costos de servicios de su Datacenter, proyecto que es
estudiado y definido en este trabajo.
2.3 PLAN DE TRABAJO
El desarrollo del plan de trabajo fue supeditado a las fechas estipuladas en el
contrato que se mantiene con el Datacenter SYSTeam. En él, se especifica la
fecha límite de los servicios y por lo tanto, un período de aviso en el término de
contrato con 6 meses de anticipación, la siguiente figura 2.1 muestra la cláusula
del contrato en idioma inglés:
Figura 2.1 Clausula de Contrato SYSTeam.
15
La traducción dice lo siguiente: “El contrato entrará en vigencia el día en que
firmen ambas partes contractuales, siendo válido por un período de once (11)
meses desde la fecha actual de comienzo de la operación de servicios. La fecha
de expiración de los términos del contrato es el 31 de Diciembre 2010.
El aviso de término de contrato deberá ser entregado no menos de seis (6) meses
previos a la expiración del término de contrato. Si dicha aviso no es entregado, el
contrato será extendido automáticamente por un período sucesivo de 12 meses,
manteniendo el periodo de notificación anteriormente mencionado. El aviso de
término de contrato debe ser realizado por escrito.”
La cláusula es muy clara y el plan de acción debió ser pensado rápidamente para
tomar la decisión respectiva. Entre las posibles soluciones tenemos:
Contratación de nuevo Datacenter en Chile, con los mismos servicios e
igualdad de condiciones al anterior Datacenter ubicado en Malmö, Suecia.
Las siguientes soluciones involucran una nueva reingeniería de los actuales
recursos, aprovechando sus capacidades al máximo:
Contratación única de servicio de correo en un Nuevo Datacenter
Buscar soluciones alternativas de correo y diseñar un nuevo centro de
datos interno.
2.4 PROVEEDORES
Debido a que la administración del departamento de Informática, específicamente
de Redes y Comunicaciones se encuentra en Chile, la alternativa lógica para
efectos de administración fue buscar proveedores de servicios que estuviesen en
el país. Esto se suma al hecho de que la casa matriz se encuentra en Chile, por lo
16
que la estructura de costos y administración financiera es cómoda de operar en
moneda nacional.
Entre los posibles proveedores se encuentran dos Datacenters ubicados en
Santiago, para el servicio de correos se ha considerado la opción de Microsoft 365
y la solución de correo electrónico Google Apps.
2.5 DEFINICIÓN DE TIEMPOS Y TAREAS DEL PROYECTO
La definición de planificación estratégica para el desarrollo del proyecto está ligada
estrechamente a la definición de gerencia. Si bien hay una primera parte de esta
estructura que obedece un patrón de pruebas y análisis de tecnología, el camino a
recorrer será una decisión final del grupo de directores de la compañía, siendo el
deber de informática ofrecerles todas las posibilidades e información que
concierne a cada posible solución. Las tareas a definir tienen un plazo crítico de 7
meses, tiempo de finalización del contrato con el actual Datacenter.
La Carta Gantt del proyecto, descrita con detalle en el Capítulo IX de éste
documento, muestra las fases más importantes del proyecto. Siendo de vital
importancia la definición inicial de ‘productos’ o ‘servicios’ a cotizar con los
proveedores de servicio seleccionados.
2.6 SOLICITUDES DE PROPUESTAS
También denominado como ‘Request for Proposal’ (RFP). Este es un documento
elaborado por la compañía donde se detalla con exactitud cuáles son las
necesidades y requerimientos de la empresa, haciendo mención de los aspectos
técnicos e informaciones concernientes al proveedor de servicios para que pueda
ser elaborada una propuesta valorizada exacta y acotada. Incluye además tiempos
asociados del proyecto tanto para el proceso de cotización, selección, desarrollo,
17
mantenciones, etc. Contando además el formato de presentación, recepción, entre
otras informaciones.
Nuestro RFP menciona una breve introducción de la empresa. Informaciones
posteriores fueron entregadas a cada proveedor en una entrevista en las
dependencias corporativas. Luego indicamos la cantidad de usuarios, escenario
en el que nos encontrábamos con el actual Datacenter, tipo de servicios que
esperábamos de parte del nuevo proveedor, cantidad de oficinas y su ubicación
geográfica, además de solicitar un nivel de inglés aceptable en caso de posibles
solicitudes de soporte. Además de mencionar que este documento tiene carácter
confidencial a cada proveedor de servicios que deseó ser parte de esta licitación,
le entregamos directivas claras sobre nuestra tecnología, estándares de conexión,
herramientas utilizadas y tipos de acceso remoto. Lo anterior, para definir un
marco de trabajo igual o superior a los requerimientos que solicitaríamos.
Adicionalmente, en los apéndices entregamos un inventario de los servidores
actuales en nuestro Datacenter y las oficinas conectadas alrededor del mundo.
2.7 RIESGOS
Los riesgos que tiene el proyecto son de variadas directrices. Uno de ellos está
basado en la disponibilidad del personal de informática, ya que su departamento
se compone de sólo una persona en el área de redes y comunicaciones, por lo
que su compromiso con el proyecto es un factor clave.
Los proveedores de servicio son clave. Muchos de ellos determinan a qué clientes
entregar el servicio y por supuesto, si cumplirán con la entrega de las propuestas.
Tal como ya se presentó a LCL, una compañía logística internacional con miras a
convertirse en Enterprise pero de tamaño pequeño o mediano, los servicios
requeridos corresponden a tecnología para grandes empresas, por lo que es muy
posible que para los proveedores de servicio el negocio no resulte atractivo.
18
3. CAPÍTULO III: SOLUCIÓN
Una vez que se han obtenido todas las propuestas por parte de los proveedores
de servicios, es necesario realizar un análisis y entregar a gerencia la información
resumida y procesada, lista para determinar la mejor solución.
En este caso particular y por el estilo de administración de gerencia, toda la
información relevante fue mencionada en un breve documento y se concertó una
entrevista para aclarar los puntos mencionados y tomar la decisión respectiva.
Este documento contenía el valor total del actual Datacenter y los costos
respectivos de los nuevos servicios. Las funcionalidades y especificaciones
técnicas de cada solución fue información reservada para la entrevista.
Fue así como la resolución final adoptada en ésta reunión fue en base a costos,
con el objetivo de conseguir un punto de equilibrio o punto muerto para este año
fiscal. Esta solución, la recomendada por el departamento de informática, consiste
en implementar los servicios actuales del Datacenter en nuestra propia
infraestructura, siendo externalizados solamente los servicios de correo
electrónico. Así, las oficinas de Chile y Estados Unidos se convertirán en el nuevo
núcleo organizacional y Google Apps, con su solución mundial de correo
electrónico, proveerá un flujo de información constante con todos los servicios,
soporte, conexión móvil y espacio suficiente para los usuarios finales.
3.1 ESTRUCTURA TÉCNICA
Las oficinas de Chile y Estados Unidos fueron las escogidas para reemplazar el
actual Datacenter, tal como ya se mencionó. Existen varias razones para esto
además de los costos implicados, como por ejemplo, ambas oficinas cuentan con
espacio suficiente para contar con una pequeña sala de servidores, con aire
acondicionado reglamentado a 19ºC según recomendación del fabricante, acceso
restringido en cada caso. En el caso de Chile, la persona encargada del
19
departamento de informática a nivel mundial se encuentra en esta oficina, por lo
que su administración se ve favorecida. En el caso de Estados Unidos, la oficina
de Seattle presenta una conectividad privilegiada por estar en el estado de
Washington, capital del país. Si bien el centro de las telecomunicaciones está en
Florida, los tiempos de conexión entre ambos estados presentan una mínima
latencia, casi imperceptible.
A continuación se puede observar en la figura 3.1, un diseño de red del Datacenter
actual.
Figura 3.1 Diseño de granja de Servidores en Datacenter
En ella se puede apreciar como primera línea de acceso un firewall asignado sólo
para nuestra compañía, además de una pequeña granja de servidores en su red
LAN. Los servidores presentados corresponden a dos servidores controladores del
dominio, cada uno de ellos es un servidor primario siendo uno backup del otro.
Cada uno de ellos cumplen el rol de FSMO (Flexible Single Master Operations o
20
Maestros de Operaciones), Catálogo Global y Servidor DNS Principal. El siguiente
servidor corresponde a un Servidor de Base de Datos, el cual utiliza Microsoft SQL
Server como motor y almacena la información del sistema corporativo. Este
servidor trabaja en conjunto con un Servidor Web, el cual utiliza como servicio de
publicación IIS. Dentro de este servidor se encuentra la aplicación corporativa,
aquella que almacena los datos del negocio logístico de la empresa. Se tiene
además un Servidor para Informática, el cual contiene aplicaciones de registro de
sucesos y eventos (SysLog), además de almacenar las configuraciones de los
equipos, junto a sus sistemas operativos. En este servidor además se encuentran
los sistemas de monitoreo SNMP (Simple Network Management Protocol o
Protocolo Simple de Administración de Red), estos sistemas son WhatsApp de
IPSwitch junto a PRTG, el primero con licenciado y el segundo versión open. Otro
de los servidores que se aprecian es un servidor de actualizaciones, denominado
por Microsoft como WSUS (Windows Server Update Services), este servidor se
encarga de realizar las actualizaciones únicamente de servidores y no de equipos
de usuario final.
Los usuarios también tienen acceso a la red del Datacenter, pero sólo para tráfico
de datos de los servidores que componen el sistema de correos, estos son el
sistema antispam y dos servidores Microsoft Exchange. Esto se debe a por
políticas de la empresa todo el correo debe ser gestionado por túneles VPN,
maximizando la seguridad contenida en ellos. Además, cada corta fuegos de cada
oficina es capaz de tener su propia VPN por si el usuario necesita utilizar datos
almacenados o compartidos en los servidores propios.
Hay oficinas que al presente han cerrado sus operaciones (e.g. Turquía, Costa
Rica, Los Ángeles, Egipto, etc.). Las oficinas que se encuentran alrededor del
mundo presentadas son las que se han mantenido estables en el tiempo. Sin
embargo, el objetivo se mantiene y este es demostrar la conexión al Datacenter a
través de VPN, formando una topología estrella, tal como podemos apreciar en la
figura 3.2.
21
Figura 3.2 Conexión VPN de Oficinas en el Mundo
La nueva arquitectura va a disponer de dos nuevos ‘sites’ como núcleo de esta
nueva configuración, en las ciudades de Santiago y Seattle. Así, quedará
formando una topología en estrella con cada una de las oficinas conectadas, pero
que entrelazadas, termina extendiéndose como una malla con dos nodos
centrales, aunque sin las interconexión de los nodos finales. Los dos sites
centrales si se encuentran interconectados, debido a la replicación de los
servidores y la estructura de los servicios publicados, además de que cada uno es
el respaldo del otro.
La siguiente figura 3.3 muestra la interconexión final de los firewalls en sitios u
oficinas del mundo a las dos oficinas principales: Santiago en Chile y Seattle en
USA. La conexión VPN con túneles IPSec se representa mediante las líneas de
conexión entre ellos:
22
Figura 3.3 Interconexión de Firewalls de Oficinas al Núcleo WAN
Cada una de las oficinas que se representan en la figura 3.3, disponen como
equipamiento base un firewall, switch y servidores interconectados. El enlace a
internet representa la unión crítica a la topología, además de representar la
conexión a servicios de navegación.
Esta interconexión fue pensada para que entre los dos sitios que actúen como
núcleo WAN, uno sea respaldo del otro y viceversa. Este respaldo funciona tanto
en la sincronización de registros del Dominio a través de la sincronización
realizada por la herramienta de configuración de “Active Directory Sites and
Services” (Sitios y Servicios del Directorio Activo), donde se establecen los
horarios de replicaciones y el respectivo envío de información. Configurar estos
parámetros es importante debido a que las oficinas alrededor del mundo trabajan
con horarios diferentes, dependiendo del GMT asignado (Greenwich Mean Time o
Tiempo medio de Greenwich). Así, las oficinas se mantienen interconectadas
alrededor del mundo 24 horas, 7 días a la semana.
23
El valor real de mantener el sitio on-line, es su aplicación corporativa. Esta
aplicación es un desarrollo basado en tecnología .NET y sostiene el negocio de la
empresa, siendo un referente para el análisis y reportes asociados. Esta aplicación
es utilizada principalmente por los países de Chile, Perú y Ecuador, siendo una
fuente importantísima de información estadística para los países que reciben la
carga. Es así, como no solamente la aplicación es importante sino además la
información que ésta maneja. La siguiente figura 3.4 muestra su interfaz web:
Figura 3.4 Interfaz web de Aplicación Corporativa
Esta aplicación contempla un control de acceso basado en Single Sign-on, un
método de acceso que permite la integración de la cuenta de usuario del dominio
local manejado por Active Directory, para ser utilizada también en la aplicación a
través de ciertas rutinas de programación. Active Directory será el repositorio de
todas las cuentas de usuario del dominio Microsoft. A continuación en la figura 3.5,
se muestra el esquema de “Unidades Organizacionales” dentro del Dominio en
referencia:
24
Figura 3.5 Esquema de Unidades Organizaciones de Active Directory
Además, el dominio tiene un nombre del tipo “dominio.local” y tiene configuradas
una serie de directivas de grupo (Group Policy) que determinan la seguridad de las
cuentas, tales como largo, estructura, complejidad, etc.
En este caso particular y en el de las siguientes imágenes, se ha suprimido
intencionalmente información confidencial para evitar difundir innecesariamente la
información corporativa. Sin embargo, la estructura e informaciones pertinentes al
correcto desarrollo del proyecto se mantienen.
La siguiente figura 3.6 es una impresión de pantalla de algunas de las directivas
ya mencionadas y utilizadas por la empresa multinacional LCL. Algunas de ellas
han sido aplicadas a un nivel suprior, mientras que otras han sido aplicadas a
niveles inferiores específicos por países. Los requerimientos varían acorde a la
necesidad y según la solicitud o políticas de los gerentes locales de cada oficina
particular:
25
Figura 3.6 Directivas de Grupo del Dominio
3.2 SERVICIO DE CORREO GOOGLE APPS
El servicio de correo de Google Apps es el correo electrónico ofrecido por Google,
en concreto una versión empresarial que dispone de cuentas de correo a bajo
costo con múltiples servicios. Si bien la mayoría de estos servicios no están
incluidos bajo el contrato de soporte del correo, funcionan bastante bien y sus
niveles de SLA son tan aceptables como los del correo.
Durante el año en curso de este proyecto, Microsoft Exchange 2003 era una de las
últimas tecnologías de correo electrónico. Esto hacía difícil la elección del
proveedor, debido a que no existían mayores alternativas en tecnología que
servicios de correo basados en plataforma Linux, Datacenters, un emergente
correo BPOS (más tarde Office 365) y la alternativa reciente Google Apps. Esta
última prestaba sus servicios en Chile desde hace un año.
26
La tecnología de SmartPhones o Teléfonos Inteligentes estaba recién
comenzando y no tenía el impacto que generó años posteriores. Sin embargo,
conocía esta posibilidad y tenía que considerarla a la hora de contratar un nuevo
proveedor.
Mi intención fue sugerir un nuevo proveedor que sea capaz de mejorar sus
servicios en el tiempo, entregando y actualizando su tecnología a la par de sus
competidores sin la necesidad de actualizar contratos y así minimizar el impacto
con los usuarios frente a futuras migraciones.
De cierta forma, el servicio de Google Apps entregó no sólo herramientas de
mensajería de correo electrónico, también entregó una capacidad de
almacenamiento de 25GB por cuenta de usuario que se mantiene en constante
crecimiento. Además, entregó una plataforma de Intranet con Google Sites, chat
corporativo y posibilidad de conexión remota en teléfonos inteligentes. Más tarde,
el servicio actualizaría sus servicios a Video Conferencia remota, herramientas de
soporte, almacenamiento para todo tipo de archivos en Google Drive, streaming
de video por Youtube, etc. En una evaluación posterior de estos servicios, se
identificó una decisión acertada el escoger a este proveedor.
Fue así como el proveedor seleccionado para ser intermediario entre Google y
LCL fue Soluciones Orión S.A. Una empresa emergente con un buen equipo de
soporte, ingenieros de pre y post venta muy capaces y con excelente gestión.
Soluciones Orión S.A. Ofreció la solución de migrar el correo en el servidor
Exchange a la plataforma Google Apps, valorizando cada cuenta por un costo de
USD 50.- Este valor aún se mantiene, siendo la estrategia de venta agregar los
servicios de soporte exclusivo como vendedor y entidad certificada Google. Así,
LCL obtiene 100% de confianza al contratar sus servicios y un equipo de personas
que gestionarán el servicio ante posibles caídas.
27
3.3 DESARROLLO DE LA PLANIFICACIÓN
Como todo proyecto, fue necesario realizar una planificación desde el inicio del
proyecto. Esta consistió en definir los principales hitos que marcarían no sólo la
continuidad, sino también el curso del mismo.
El primer hito fue definir el nuevo esquema de trabajo. Si bien las posibilidades
eran numerosas, se redujeron a un total de tres. Sin embargo, fue necesario
realizar un RFP en primera instancia para enviarlo a los proveedores y así ellos
puedan cotizar su solución respectiva.
En éste documento RFP se detalló en primera instancia el negocio de la empresa,
la topología WAN de las distintas oficinas interconectadas al Datacenter, los
servicios y servidores presentes en el Datacenter, los tipos de acceso remoto, las
oficinas conectadas y su localización, nuestros estándares corporativos en
referencia a hardware de servidores y equipos de comunicaciones, software de
servidores y marca utilizada de impresoras (necesaria por los drivers y su
compatibilidad). Además se detallaron las aplicaciones críticas y los tiempos
asociados para mantenerlas siempre operativas.
En segunda instancia, se realizó toda la solicitud respectiva de los requerimientos
que requeríamos para cotizar un servicio de este tipo. Además de que íbamos a
necesitar de ciertos tipos de servicios como soporte con la migración de la actual
plataforma, mantención del equipamiento, soporte a equipos y usuarios finales,
backup, SLA (Service Level Agreement), un Account Manager o contacto
comercial responsable de nuestra cuenta, Reuniones de Coordinación y Estatus
de tareas, reportes mensuales o post-incidentes. Además, se solicita
expresamente asistencia en caso de necesitar asistencia frente a futuros cambios
de tecnología.
28
Finalmente, se les entrega un inventario de cada servidor a nuestros proveedores
para que ellos puedan cotizar y entregarnos el valor solicitado por los servicios.
Como se mencionó, las ideas eran un total tres:
La primera de estas opciones era contratar un Datacenter en igualdad de
condiciones al que ya teníamos. De esta manera, el cambio sería limpio y para el
usuario final sería casi imperceptible. Sin embargo, durante el proceso de
cotizaciones y el respetivo análisis de costos no hacían viable esta opción.
Además, este tipo de contratos se rigen de forma estructurada y no es posible
modificar servicios a no ser que se pague una prima extra, lo mismo ocurre con
mejoras y upgrades de tecnología.
La segunda opción era contratar un proveedor únicamente para servicios de
correo. Los proveedores entregaron propuestas por los dos tipos principales de
tecnología de aquel tiempo: Microsoft Exchange y correo Pop en Linux. El primero
de ellos tenía un costo elevado, mientras que el segundo era un costo muy bajo.
El principal problema de ambas opciones era el espacio, ambos cotizaban por un
espacio de 2GB por cuenta de usuario, hablando de un universo de 140 usuarios.
Es así como llegamos a buscar nuevas tecnologías. Durante este período el
servicio BPOS de Microsoft estaba recién comenzando a entrar en nuestro
mercado, más tarde comenzaría a llamarse Office 365. Sin embargo, ya teníamos
presente en el país el Servicio de Google Apps. Ellos tenían un costo estándar por
cuenta de usuario a USD 50.- por cada cuenta y ofrecían además la suite
Business de Google, compuesta por Google Docs que puede editar y almacenar
documentos en línea (hoy es conocido como Google Drive), además de Google
Sites, Calendario y Chat Corporativo. Todos estos servicios por un costo total de
USD 7000.- Es importante destacar que Google ofrece nuevos servicios como
parte de su oferta, que además incluye un aumento de espacio cada cierta
cantidad de años, conectividad a través de dispositivos móviles, etc.
29
Es así como se presentó toda la información a gerencia, cuyo detalle se encuentra
adjunto en el Capítulo XI, bajo el subtitulo 11.2 Resumen de Propuestas. De esta
reunión y con la entrega de la información recopilada, como Jefe del Proyecto y el
Departamento TIC LCL, entregué la sugerencia respectiva:
La mejor opción por tecnología y costos para la nueva plataforma de
correos es Google Apps.
Los servicios del actual Datacenter serán movidos a nuestros centros de
datos propios, tanto en la oficina de Seattle (USA) como Santiago (Chile).
Ambos sitios se convertirán en el núcleo o de la organización. Así, en caso
de fallas uno podrá reemplazar al otro.
Bajo esta solución, podremos tener una importante reducción de costos a
futuro.
Gerencia estuvo de acuerdo con la solución de Google Apps y migrar los servicios
del Datacenter a nuestra infraestructura, por lo que entregó su aprobación. A partir
de ésta definición, se hizo patente comenzar un nuevo ciclo de pruebas y trabajos
que deberán ser ejecutados para analizar la viabilidad del proyecto desde el área
técnica.
A continuación se presenta la figura 3.7 con los sites configurados, los cuales
fueron pasos importantes previos dentro de la preparación de la nueva
configuración: Crear la replicación entre los diferentes Sites con el nuevo Núcleo
WAN, que tal como ya se mencionó, consta de 2 unidades ubicadas en dos países
diferentes. Esta configuración se realizó en el nuevo Controlador de Dominio
Principal, ubicado en la oficina de Santiago (Chile), bajo las herramientas
administrativas del servidor, específicamente en la consola de Administración
Active Directory Sites and Services.
30
Figura 3.7 Control de Replicación en consola Active Directory Sites and Services
Cada link especifica la interconexión entre ciudades. Una vez realizada la
replicación entre todas las oficinas y agregando los respectivos costos y tiempos
de replicación (30 minutos para el núcleo de la red y 60 minutos para otras
oficinas), se procedió a crear las VPN según el estándar corporativo. Nuevamente,
esto se analiza con mayor detalle en el Capítulo VII de esta memoria.
Con toda la conexión en marcha, se entregó la autorización al departamento de
desarrollo para instalar las Aplicaciones Corporativas: BOSS (Business Operations
Surveillance System) y CMS (Claims Management System) en los nuevos
servidores ubicados en Seattle, Estados Unidos. Como se trata de sistemas web,
31
mientras no se cambien los registros DNS que apuntan a las nuevas direcciones
IP, los usuarios no notarán que están ya instalados y listos para ser utilizados.
Una vez que todo estuvo interconectado, se realizó la coordinación respectiva con
el departamento de Ingeniería de Soluciones Orión. A través de una serie de
reuniones, se coordinó principalmente la nueva configuración de la plataforma
online, la carga de usuarios a la plataforma, el upload de la información de los
usuarios, tiempos del proyecto, cambio de los registros MX y soporte post-
migración.
La carga de los usuarios y su información a la plataforma se realizó con un archivo
.CSV. La plataforma acepta este tipo de archivo bajo una plantilla con campos
específicos. Así, la carga de descripciones, passwords y otras informaciones es
mucho más eficaz y eficiente. Cabe destacar que este trabajo fue en conjunto,
mientras el departamento TI entregó la nómina de los usuarios en el formato
requerido, fue Soluciones Orión quien realizó la carga masiva.
La configuración de la plataforma fue realizada íntegramente por Soluciones
Orión, bajo las especificaciones de LCL. Esta configuración fue realizada en la
plataforma Antispam basada en tecnología del proveedor Postini, la cual era parte
de la solución de Google. Además, se agregaron las cuentas de administración
dentro de Google Apps. Más tarde, agregué y creé todos los grupos utilizados en
la organización. Una vez que todas las configuraciones estuvieron listas, revisadas
y probadas a la última semana de Diciembre, se dio aviso al Datacenter y Google
Apps que el cambio sería realizado previo al 1 Enero. Durante este período, se
actualizaron los registros MX en el DNS y luego se esperó la replicación. No tardó
más de 8 horas en recibir los primeros mensajes en la nueva plataforma,
indicando que el cambio fue exitoso. A continuación, la figura 3.8 muestra la
interfaz web del nuestro proveedor DNS Speednames.Net:
32
Figura 3.8 Registros MX en proveedor DNS SpeedNames.Net
Una vez realizado el cambio de los registros MX, se realizó el cambio de registros
DNS (Host A) para las aplicaciones de BOSS y CMS apuntando a los servidores
de nuestra oficina en Estados Unidos, para luego dar de baja el servicio web del
Datacenter. Así, el cambio para los usuarios fue totalmente transparente e
imperceptible.
Durante la semana siguiente y posterior a la migración de la plataforma de
correos, se realizó la carga de mensajes de años anteriores a la nueva plataforma
de correo electrónico. Esto con una herramienta de Sincronización de Google y en
otros casos utilizando directamente Microsoft Outlook.
Efectuados todos los pasos anteriores, se coordinó la baja de los servicios en el
Datacenter y se pidió de inmediato las capacitaciones generales para todos los
usuarios por parte de Soluciones Orión para trabajar en el nuevo ambiente web de
correo electrónico de Google Apps.
El resultado de la migración, incluyendo tareas realizadas y efectividad del
proceso fue enviado a través de un reporte vía correo electrónico a gerencia,
dando por terminado el proyecto.
33
4. CAPÍTULO IV: FUNDAMENTOS TEÓRICOS EN REDES Y
COMUNICACIONES
4.1 MODELO OSI
El Modelo OSI (Open Systems Interconnection) es un estándar Internacional que
nació para homogeneizar las nuevas tecnologías correspondientes a las redes de
computadoras. Para ello, [1] la Organización Internacional de Estándares
(International Standards Organization, ISO) se vio en la necesidad de crear un
subcomité en el año 1977 (TC97/SC16), cuya primera tarea, fue crear un marco
de trabajo donde se especificara una definición de protocolos concreta y
estandarizada. Después de 18 meses de estudio se adoptó la arquitectura de un
modelo distribuido en 7 capas. La siguiente figura 4.1 muestra el modelo gráfico
implementado:
Figura 4.1 Modelo OSI.
En Julio de 1979 el estudio fue denominado como “Modelo de referencia OSI” y es
un acuerdo donde se definirán la operación, niveles, trabajo y especificaciones de
las funciones de cada protocolo. Este modelo representa la base de los estudios
formales en el área de redes y comunicaciones de datos, ya que provee un marco
34
de referencia importante por ser la herramienta de primer nivel para el estudio de
las tecnologías de información [3].
Las siguientes son las capas que conforman el modelo OSI: Capa física, enlace de
datos, red, transporte, sesión, presentación y aplicación. Cada una de las capas
ofrece un concepto, marco de trabajo y estandarización.
4.1.1 Capa Número 1: Capa Física
Es la capa base de modelo OSI o también denominada primera capa. Tal como su
nombre lo indica, esta capa contiene todos los elementos físicos que proporcionan
la conexión entre diferentes dispositivos tales como los conectores utilizados,
protocolos utilizados en la capa e incluso el voltaje generado para enviar y recibir
señales eléctricas que transmiten la información. Esta capa nos proveerá la
activación, mantención y será el punto de intersección entre las propiedades
mecánicas, eléctricas, características funcionales y procesos asociados como:
voltajes, tasa de transferencia, distancia máxima de transmisión, conexión al
medio físico. Así, la función principal de esta capa será completar la transmisión
de información entre dos dispositivos.
La definición y especificaciones técnicas de ésta capa incluyen estándares como
EIA/TIA RS-232, EIA/TIA RS-449, V.35, etc.
4.1.2 Capa Número 2: Capa de enlace de datos
Corresponde a la segunda capa del modelo OSI que controla la comunicación
entre la capa física y la capa de red. Se encarga de establecer y finalizar el vínculo
lógico entre los nodos y la respectiva transferencia de tramas a través del canal
físico, siendo su principal rol el establecer cuan confiable es el estado de la
transmisión de datos y la transmisión de los mismos. Confirma, detecta y provee
los mecanismos necesarios para la recuperación de errores agregando el campo
35
de CRC (Campo de redundancia cíclica, Cyclic Redundancy Check). Así es como
se puede comprobar si la información que contiene la PDU (Protocol Data Unit,
Unidad de datos de protocolo) es la trama que se busca o no.
4.1.3 Capa Número 3: Capa de Red
Es la tercera capa del modelo OSI. Esta capa controla la operación de la red, la
prioridad de la transmisión, el nivel de congestión de la red, calidad de servicio y el
costo de los enlaces para llegar desde un nodo a otro.
Las redes están basadas en diferentes interconexiones y equipos que encaminan
los datos entre las diferentes redes, en base a un direccionamiento asignado a
cada una de ellas. Así se entrega una guía estandarizada para la accesibilidad a la
información.
La principal función de esta tercera capa es completar la transmisión de paquetes
entre los hosts, aprovechando los servicios de la capa de enlace de datos.
Esta capa de red tiene protocolos del tipo IP, OSPF, RIP, etc.
4.1.4 Capa Número 4: Capa de Transporte
Es la cuarta capa del modelo OSI. Esta capa, garantiza que los mensajes se
entreguen sin errores, en secuencia, sin pérdidas, duplicaciones o cualquier tipo
de problema. Además, libera a los protocolos de capas superiores de cualquier
relación con la transferencia de datos entre ella o capas inferiores.
La función primaria de ésta capa es proveer transmisión de datos confiable entre
procesos, control de flujo, multiplexación, administración de circuitos virtuales,
detección de errores y recuperación de los mismos.
36
Esta capa puede aceptar mensajes relativamente grandes, sin embargo, existen
limitaciones de tamaño para las capas inferiores. Como consecuencia, la capa de
transporte debe dividir los mensajes en unidades más pequeñas, anteponiendo el
respectivo encabezado a cada una de ellas. Éste encabezado incluye información
de control, como aquellos marcadores que indica inicio y fin de los mensajes, así
la capa de transporte del otro extremo tendrá la información pertinente dentro los
límites exigidos.
Esta capa incluye protocolos como TCP y UDP.
4.1.5 Capa Número 5: Capa de Sesión
La quinta capa del modelo OSI es la responsable del establecimiento de sesiones
entre procesos que se ejecutan entre diferentes estaciones de trabajo. La capa de
sesión es también utilizada para insertar marcas en la información para lograr
sincronización.
Entre las funciones de ésta capa se incluyen: establecimiento en la conexión de la
comunicación y la mantención de su flujo durante la sesión. Decide cuando es
posible realizar una interrupción entre el dialogo simultáneo entre dos nodos de la
red, además de cuando puede comenzar a retransmitir nuevamente. Además
permite la transmisión de datos en full-duplex o en cualquiera de las otras
transmisiones de un solo sentido.
4.1.6 Capa Número 6: Capa de Presentación
Esta capa entrega el formato que deberá presentarse en la capa de aplicación, es
decir, es el traductor entre las diferentes capas. Como por ejemplo, entre la capa
de aplicación y la capa de red.
37
La función principal de la sexta capa del modelo OSI es manejar la encriptación y
el descifrado de los datos, como los sistemas de procesamiento de contraseñas,
conversión de código de caracteres y conversión de datos.
4.1.7 Capa Número 7: Capa de Aplicación
Esta es la última capa del modelo OSI, nominada también como la séptima capa.
Está orientada a la interacción con el usuario, será entonces ésta capa la que
actúe como una interfaz entre el usuario final y las aplicaciones, para así proveer
la interconexión hacia capas inferiores o acceder hacia alguno de sus servicios,
siendo ésta su principal misión.
Si bien ésta capa lleva por nombre “aplicación”, entre sus servicios no significa
que sobre ésta capa funcione una aplicación o software en particular, más bien,
provee servicios como la transferencia de archivos, administración de archivos y
procesamiento de información de correo.
Ésta capa de aplicación incluye la utilización de protocolos como: FTP, Telnet,
HTTP, SNMP, etc.
La siguiente tabla 4.1 muestra la utilización de protocolos por capa en el modelo
OSI:
Nombre de la Capa
N° de Capa Protocolos Dispositivos
Aplicación 7Telnet, HTTP, FTP, SMTP, POP3, SNMP
Hosts, FirewallsPresentación 6Sesión 5Transporte 4 TCP, UDP FirewallsRed 3 IP RouterEnlace de Datos 2
Ethernet (IEEE 802.3), HDLC, PPP, MPLS.
LAN Switch, Wireless Access Point
Física 1 Ethernet (802.3)Cables, conexiones físicas
Tabla 4.1 Ejemplos de protocolos y dispositivos por capa en modelo OSI
38
4.2 ARQUITECTURA MODELO TCP/IP
Fue desarrollado por una comunidad de investigadores de una agencia
gubernamental norteamericana: ARPA (Advanced Research Projects Agency) bajo
la protección del Departamento de Defensa Norteamericano (DoD), así, los
sistemas que ya tenían en su poder (creado y adquirido a partir de diferentes
fabricantes) podrían ser utilizados entre sí.
El nombre de esta capa proviene de dos importantes protocolos de la familia: TCP
(Transmission Control Protocol) e IP (Internet Protocol).
Este modelo de capas ha resultado ser la base de la arquitectura que conocemos
hoy en día en Internet y sirve como base para la interconexión de todo tipo de
redes de dispositivos que utilizan este servicio.
El modelo TCP/IP está compuesto por 4 capas o niveles, cada uno de ellos está
encargado de determinados aspectos de la comunicación y flujo de datos,
brindando el servicio respectivo a la capa subyacente. La siguiente figura 4.2
muestra la representación gráfica de este modelo:
39
Capa Enlace
Capa de Internet
Capa Enlace de Datos
Capa de Red
Capa de Transporte
Capa de Transporte
Capa Física
Capa de Aplicación
Capa de Aplicación
Modelo TCP/IP de 4 Capas
Modelo TCP/IP de 5 Capas
Figura 4.2 Comparación de Modelos TCP/IP
En el lado izquierdo de la figura anterior, se visualiza gráficamente el modelo de
abstracción de las cuatro capas según se define en el RFC 1122. La figura 4.2 del
lado derecho es el modelo actualizado de TCP/IP, modelo que agrega una capa
en el nivel inferior que se encargará de transmitir la información por el medio
físico. Vale decir que el modelo del lado derecho, es el que se utiliza mayormente
en las redes de datos de nuestros días.
Si bien los modelos son similares, es necesario informar sobre cada una de las
capas y sus respectivas funciones. Por ello, serán nominadas y explicadas a
continuación:
4.2.1 Capa Número 1: Capa de acceso a la red
Se encuentra en el nivel inferior, pero no por ello es menos importante. Su función
es encapsular un datagrama IP en una trama que pueda ser transmitida por un
medio físico, siendo ésta en la mayoría de los casos una trama Ethernet. Además,
se encarga de realizar la correspondencia entre las direcciones lógicas IP a las
direcciones físicas de los dispositivos adaptadores a la red (NIC). Para éstos
casos, el RFC 894 el estándar que regulará este tipo de transmisión y
encapsulamiento de datos.
4.2.2 Capa Número 2: Internet
Es la capa siguiente a la anterior: “Acceso a la red”. La labor de esta capa es
inyectar paquetes en la red y lograr que viajen de manera independiente hasta la
red de destino. Esta capa define el protocolo IP oficialmente como formato, incluso
cuando es un protocolo que no está orientado a la conexión. Lo anterior indica que
si dos equipos desean conectarse entre sí, no intercambiarán información para
establecer la sesión. El protocolo IP tampoco se preocupa de comprobar si se han
producido errores de transmisión, sino que confiará esta función a las capas
40
superiores. Es decir, los paquetes de datos tendrán la información suficiente como
para propagarse a través de la red sin que sea necesario establecer conexiones
permanentes.
4.2.3 Capa Número 3: Capa de Transporte
Es la tercera capa a contar del nivel inferior. Permite administrar las sesiones de
comunicación entre hosts, además de definir el nivel de servicio y el estado de la
conexión para transportar datos.
En la capa de transporte se encuentran definidos el protocolo TCP y el protocolo
UDP (User Datagram Protocol). TCP permite enviar los datos desde un extremo a
otro de la conexión con confiabilidad y es orientado a la conexión. Por otro lado,
UDP reduce la cantidad de información enviada en la cabecera de cada
datagrama enviando los paquetes basado en un "mejor esfuerzo", obteniendo
mayor rapidez en base a menor confiabilidad en la entrega de los datos.
4.2.4 Capa Número 4: Capa de Aplicación
Es la capa superior dentro de la estructura jerárquica del modelo TCP/IP. En ella
se incluyen las aplicaciones y procesos con que intercambiará datos la capa de
transporte. En esta capa trabajan los protocolos que soportarán los servicios de
conexión remota, correo electrónico, transferencia de archivos, etc.
La siguiente tabla 4.2 muestra los protocolos presentes en cada capa TCP/IP:
Arquitectura de Modelo TCP/IP
N° de Capa
Ejemplo de Protocolos
Aplicación 4HTTP, POP3,
SMTPTransporte 3 TCP/UDPInternet 2 IPEnlace 1 Ethernet, T1, PPP
41
Tabla 4.2 Ejemplos de protocolos en Arquitectura de Modelo TCP/IP
4.3 COMPARATIVA ENTRE MODELOS OSI – TCP/IP
Para el estudio de ambos modelos, tanto el modelo OSI como el modelo TCP/IP,
proporcionan un modelo abstracto que permite el estudio y agrupación de las
diferentes funciones relacionadas [2].
La siguiente figura 4.3 muestra la estructura gráfica de ambos modelos, su
distribución y concordancia entre capas:
Figura 4.3 Comparación entre modelo OSI y ambos modelos TCP/IP.
4.4 DIRECCIONAMIENTO IP
Para entender que es el direccionamiento, debemos comenzar por definir
dirección IP. Esta es una dirección lógica con una longitud de 32 bits para IPv4,
correspondiente a una dirección única para un dispositivo conectado a una red
que funcione bajo la estructura TCP/IP. Su nomenclatura se define en base a
cuatro bloques, separados entre sí por puntos para facilitar su utilización.
42
Cada uno de estos bloques será un byte, denominado comúnmente como
‘octetos’. Cada uno de ellos estará conformado por 8 bits en formato binario. Para
un mejor manejo, se trabaja con ellos en su equivalente a formato decimal
comprendido entre 0 a 255.
Las direcciones IP nos proveen información fundamental. Entre ellas, la dirección
de host y direcciones de red para realizar la entrega de información, además de
informar al resto de los sistemas sus propios datos de conexión.
La entrega de información se puede realizar de los siguientes tipos de conexión:
Unicast: Los paquetes de datos tienen como destino la dirección de un
único host.
Musticast: Los datos se pueden enviar de manera simultánea a un conjunto
determinado de hosts.
Broadcast: Corresponde a la dirección de red que permite realizar la
difusión de los datos a todos los hosts que estén conectados a un mismo
segmento de red.
En el caso del número de bits empleados para definir la porción de red y la porción
que identificará a los hosts, podrían llegar a variar entre diferentes casos. Para
cada caso, cada dirección contará con un prefijo, cuya longitud se revelará a
través de una operación matemática. La longitud de éste prefijo la establecen los
bits de dirección de la máscara de red. Es decir, si en la máscara de subred la
porción de números ‘1’ revelará la subred, mientras que la porción en ‘0’ revelará
la porción de hosts.
4.5 CLASES DE DIRECCIONAMIENTO IP
Para diferenciar el tipo de direccionamiento entre redes de diversos tamaños o
prestaciones, se ha establecido como un estándar internacional el asignar clases a
cada una de ellas designadas por una letra: A, B, C, D, E. A continuación se
43
presentan cada una de las clases y detalles adicionales de su funcionamiento y
aplicaciones:
4.5.1 Clase A
Por definición es una clase para grandes corporaciones. Se utiliza el primer octeto,
del 1 hasta el 126 para definir las redes a utilizar, los otros tres octetos son para
definir la porción de hosts. Es decir, existirán 126 redes en esta clase.
En IPv4, la dirección IP 127.0.0.1 ha sido reservada para el propio equipo o su
interfaz loopback.
4.5.2 Clase B
Esta clase se utiliza para redes de tamaño mediano. Serán parte de esta clase las
direcciones del primer octeto desde el 128 al 191, aunque también se utiliza al
segundo octeto como identificador de la red.
4.5.3 Clase C
Corresponden a las direcciones que en su primer octeto están numeradas a partir
del 192 al 223. En esta clase se utiliza al segundo y tercer octeto como elemento
para definir la red.
4.5.4 Clase D
Es una clase reservada para Multicast (permite el envío de información a muchos
puntos). Esta red está definida desde el decimal 224 al 239.
4.5.5 Clase E
44
Es una red reservada para uso experimental y estará definida para los rangos
decimales que van desde el 240 al 254.
4.5.6 Broadcast
Se trata de los mensajes que se enviarán a todos los host que estén conectados a
la red, esta red es siempre la misma y está definida como 255.255.255.255.
4.5.7 Loopback
Corresponde a la dirección reservada 127.0.0.1. A través de esta dirección el host
puede enviar un mensaje a sí mismo.
4.5.8 Máscara de Red
Al igual que la dirección IP, es una combinación de bits que la acompaña y permite
delimitar la estructura de una red. Es decir, con la ayuda de una operación lógica
AND binaria entre la dirección IP y la máscara, permitirá conocer red, subred y
cantidad asignada de hosts como ya se mencionaba anteriormente. Con la
operación OR binaria y la máscara de subred negada se obtendrá la dirección de
broadcasting.
4.5.9 Subredes
Según lo que ya se mencionó en párrafos anteriores, la especificación original del
RFC 790 define 3 grandes clases. Este documento además provee información
sobre como una dirección IP se divide en una parte identificada como parte de la
red y otra parte identificada como porción de hosts. El formato de cada clase
determinará el número de redes disponibles y la cantidad de hosts que pueden ser
utilizados. En el RFC 988 se define adicionalmente la clase D, utilizado para
multicast.
45
Identificador de Host
Identificador de Subred
Identificador de Red
La siguiente figura 4.4 muestra una representación gráfica de los bits utilizados por
cada clase, la cantidad de hosts y redes disponibles. Además, la tabla muestra el
cálculo matemático quitando las redes y hosts no utilizables por ser direcciones
reservadas:
Figura 4.4 Estructura de cada una de las clases A, B y C.
La estructura de una dirección IP no es rígida, de hecho, puede ser modificada.
Esto es posible destinando parte de la dirección de hosts para bits de red
adicionales o de subred. La creación de ellas reducirá la cantidad de direcciones
destinadas para hosts, así los bits de subred definirán un nuevo bloque de
direcciones dentro del bloque de red al que actualmente pertenece.
El subnetting o subdireccionamiento IP, está descrito en los RFC: 950, 1878,
1519. Es una técnica para dividir cada una de las clases (A, B, C) en pequeños
grupos de direcciones IP que se adecuen de mejor manera a nuestras
necesidades.
En una red con subdireccionamiento, la parte que está a la derecha de la
numeración que indica la clase se dividirá en una parte de subred y una porción de
hosts. La siguiente figura 4.5 muestra gráficamente esta representación:
Figura 4.5 Estructura de una dirección IP con subred
46
Cada IP debe tener asociada una máscara de subred, que identifique que bits
están asociados a la subred y cuales a la porción de hosts.
4.6 MULTIPLEXACIÓN DE DATOS
Cuando tenemos un traspaso desde la capa de transporte a la capa de aplicación,
es muy importante identificar claramente a que servicio de red están destinados y
como pueden ser identificados.
La autoridad IANA (Internet Assigned Numbers Authority) es responsable de
coordinar elementos como el registro de Nombres (DNS), el pool global de
direcciones IP y las asignaciones de protocolo para mantener el orden,
regulaciones y la estandarización en Internet. Por lo tanto, esta entidad mantiene
un registro actualizado con los números de puerto asignados a cada servicio de
red, descrito en el RFC 1700.
Los números de puertos mencionados mantienen un tamaño de 16 bits, el primero
es el número de puerto de origen, que identifica el proceso que envía los datos y
el segundo es el número de puerto destino que identifica al puerto que los recibe.
Ambos números están localizados en la cabecera de los datagramas enviados por
TCP o UDP.
Existen puertos más utilizados que otros debido al tipo de servicio que prestan,
convirtiéndolos en “puertos conocidos”.
La Tabla 4.3 muestra la información sobre los puertos más conocidos,
presentando su número, protocolo sobre el que opera y acrónimo (representado
en la fila “Servicio”). A continuación de ésta, podremos encontrar un resumen de
cada servicio y sus respectivas labores, entregando información importante sobre
su funcionamiento, con el objetivo de comprender eficazmente la importancia de la
47
estandarización del número que le fue asignado. Adicionalmente, se explica su
acrónimo (más traducción) y forma de operación.
Número de
Puerto Protocolo Servicio20 TCP FTP (data port)21 TCP FTP (control port)22 TCP SSH23 TCP Telnet25 TCP SMTP53 TCP/UDP DNS67 UDP DHCP69 UDP TFTP80 TCP HTTP
110 TCP POP3123 UDP NTP 143 TCP IMAP161 UDP SNMP389 TCP/UDP LDAP443 TCP SSL/HTTPS
1433 TCP SQL3389 TCP RDP
Tabla 4.3 Ejemplos de Números de puerto conocidos
4.7 DESCRIPCIÓN DE PUERTOS
4.7.1 FTP
File Transfer Protocol o Protocolo de Transferencia de Archivos. Permite la
transferencia de archivos a través de la arquitectura cliente-servidor. Siempre con
interconexión entre redes TCP, independiente del sistema operativo o si es para
subida o bajada de archivos.
48
4.7.2 SSH
Secure Shell o Intérprete de Ordenes Seguro. Facilita las comunicaciones seguras
entre dos sistemas usando una arquitectura cliente/servidor y que permite a los
usuarios conectarse a un host remotamente. A diferencia de otros protocolos de
comunicación remota tales como FTP o Telnet, SSH cifra la sesión de conexión,
haciendo imposible que alguien pueda obtener contraseñas no cifradas.
4.7.3 Telnet
Teletype Network. Permite la conexión remota a otro equipo con un usuario y
contraseña, para así ejecutar comandos disponibles y permitidos. No es muy
seguro debido a que la información de texto viaja en texto plano.
4.7.4 SMTP
Simple Mail Transfer Protocol o Protocolo de Transferencia Simple de Correo
Electrónico. Es un estándar oficinal en Internet definido en el RFC 2821, permite la
transferencia de mensajes entre diversos dispositivos.
4.7.5 DNS
Domain Name System o Sistema de Nombres de Dominio. Permite la traducción
de nombres de dominio a direcciones IP y viceversa. Este sistema en Internet es
distribuido, jerárquico, replicado y tolerante a fallas.
4.7.6 DHCP
Es el Protocolo de configuración dinámica de hosts, viene del inglés Dynamic Host
Configuration Protocol. Es un protocolo que automáticamente asigna
direccionamiento IP a los host que podrían estar conectados en una red TCP/IP.
49
Mayor información de este protocolo se analizará en detalle en secciones
posteriores.
4.7.7 TFTP
Trivial File Transfer Protocol o Protocolo de Transferencia de Archivos Trivial. Es
una versión muy básica utilizada para la transferencia de archivos entre
dispositivos. El hecho que sea del tipo básica no significa que sea menos utilizada
o que no deba ser utilizada, más bien se traduce en la forma de operar,
configuración y composición.
4.7.8 HTTP
Hypertext Transfer Protocol o Protocolo de Transferencia de Hipertexto. Es un
protocolo utilizado para la transferencia de Información vía Internet, responsable
de las transacciones y con arquitectura cliente servidor.
4.7.9 POP3
Post Office Protocol o Protocolo de Oficina de Correo. Es utilizado para obtener
los mensajes de correo almacenados en un servidor remoto.
4.7.10 NTP
Network Time Protocol o Protocolo de Tiempo de Red. Es utilizado para
sincronizar relojes entre diversos dispositivos a través de Internet.
4.7.11 IMAP
50
Internet Message Access Protocol o Protocolo de Acceso de Mensajes de Internet.
Es un protocolo que permite la recuperación de mensajes, más complejo que Pop
y que permite trabajar sobre demanda sin necesidad de descargar los mensajes
ya almacenados.
4.7.12 SNMP
Simple Network Management Protocol o Protocolo Simple de Administración de
red. Facilita el intercambio de información entre diversos dispositivos de red y
permite a sus administradores supervisar, controlar, etc.
4.7.13 LDAP
Lightweight Directory Access Protocol o Protocolo Ligero de Acceso a Directorios.
Permite el acceso a un servicio de directorio distribuido.
4.7.14 SSL/HTTPS
Secure Socket Layer o Capa de Conexión Segura. Permite las conexiones
seguras, proporcionando autenticación y privacidad de la información entre
extremos de Internet mediante criptografía.
4.7.15 SQL
Structured Query Language o Lenguaje de Consulta Estructurado. Es un lenguaje
que permite el acceso y operación a bases de datos relacionales.
4.7.16 RDP
51
Remote Desktop Protocol o Protocolo de Escritorio Remoto. Protocolo propietario
desarrollado por Microsoft, el cual permite la conexión remota a otro equipo. Es un
protocolo que trabaja bajo modalidad cliente-servidor.
No significa que aquellos puertos que no están nominados en la tabla sean menos
importantes, más bien, se trata de ejemplificar el número de puerto al servicio
asociado y de utilización común.
Según la numeración de los puertos, se hace la siguiente clasificación
estandarizada:
Todos los puertos por debajo de 1024 están debidamente definidos y
normados. Es decir, son números de puerto estandarizados y no pueden
ser modificados ni asignados a otros servicios.
Los puertos numerados entre 1024 y 49151 son puertos registrados. Esto
significa que la IANA tiene una organización para este rango, pero no con
las restricciones impuestas para este rango de numeración.
Aquellos puertos numerados entre 49152 y 65535, son puertos privados y
destinados para cualquier uso.
4.7.17 Asignación dinámica de puertos
El rango de puertos bien conocidos simplifican las conexiones, ya que debido a su
estandarización, los equipos interconectados saben exactamente a qué aplicación
van destinados los datos.
Además de los puertos mencionados anteriormente, cada conexión necesita
asignar aleatoriamente un segundo número de puerto. Su elección es aleatoria,
aunque deberá ser superior al decimal 1024.
52
La ventaja de utilizar puertos dinámicamente, es que permite que un servicio
soporte múltiples usuarios, como por ejemplo, el servicio http asignará números de
puertos para interconectar dos nodos remotamente.
La combinación de una dirección IP y el número de puerto es denominado socket.
Un socket identifica un proceso de red de forma única en internet.
4.8 CONCEPTOS DE SWITCHING EN UNA RED ETHERNET
Un Switch es un dispositivo que interconectará múltiples hosts de la red. Este tipo
de equipo recibe las tramas por cada uno de sus puertos, información que será
reenviada directamente al host destino, realizando de ésta manera una decisión
sobre el envío de los datos asociado a uno de sus puertos.
El predecesor del switch (HUB), si bien también tenía la función de interconectar
hosts, funcionaba de una manera totalmente diferente.
Cuando el hub recibe una señal eléctrica en uno de sus puertos, replica
exactamente la misma señal a todo el resto de los puertos.
Si dos equipos envían datos al mismo tiempo, ocurrirá una colisión
eléctrica, por lo tanto va a corromper la información que transportan.
De esta manera, cada broadcasts y unicast será escuchado y procesado
por todos los equipos de la red LAN.
Los equipos Hub, si bien lograban el objetivo de interconectar nodos, provocaban
una degradación importante de la red. Es por esto que hoy en día la utilización de
equipos switches ha sido ampliamente aceptada.
53
La lógica de los Switches se basa en las direcciones únicas de identificación MAC
(Media Access Control Address) de las NIC de origen y destino en cada cabecera
de las tramas Ethernet.
En base a todas las direcciones MAC que el switch ha aprendido, construirá una
tabla con todas las direcciones y las interfaces asociadas. Así, cuando el switch
reciba una trama, revisará cual es la dirección de destino y la comparará son su
tabla de direcciones.
Cuando un switch recibe tramas Ethernet realizará una toma de decisiones, como
por ejemplo reenviar la trama por algún otro puerto, o bien, ignorar la trama.
También, aprenderá todas las direcciones MAC de todos los equipos que tenga
directamente conectados, examinando cada la dirección de envío de cada trama.
Además, creará una arquitectura libre de loops basado en el protocolo Spanning-
Tree.
El protocolo Spanning-Tree (STP) previene la inundación de tramas en la red,
provocados por conexiones redundantes. De esta forma, STP bloqueará algunos
puertos cuando el reenvío no proceda, así se evita una degradación de la red y
permite una mejor utilización de los recursos.
4.9 VLAN
Su acrónimo significa Virtual Local Area Network o Red de Área Local Virtual. Esta
red virtual corresponde a una configuración lógica que será realizada en el switch
y que segmentará la utilización de éste acorde a los requerimientos de la red.
Si bien las VLANs son redes lógicas, tienen los mismos atributos de una LAN
física. De esta forma, cualquier puerto que esté conectado a la misma VLAN podrá
recibir paquetes unicast, multicast y broadcast. Si existiera una VLAN diferente
dentro del mismo switch, no podrán tener comunicación entre ellas a menos que
54
exista un router que provea el ruteo de paquetes. Según esta definición, se puede
inferir que cada VLAN deberá tener una dirección de red diferente, o bien, una
subred diferente para lograr la conexión.
4.10 ROUTERS
Este tipo de dispositivo hace posible la interconexión de las diferentes redes
existentes, por lo tanto, su servicio provee una de las características más
importantes dentro de la capa de red, es decir, la capacidad de dirigir el tráfico de
paquetes desde un origen hasta un destino.
4.10.1 Lógica para realizar el proceso de ruteo
En IPv4, el proceso de ruteo comienza desde que un host crea el paquete IPv4
destinado a otra red, de otro modo, si el paquete estuviese dirigido dentro de la
misma red el host lo enviaría directamente utilizando su tabla de direcciones (ARP,
Address Resolution Protocol). Para el caso anterior, como el paquete no está
dentro de la misma red, lo enviará hasta su puerta de enlace (Default Gateway).
Aquí es donde el router recibirá la trama, la examinará y buscará el paquete,
revisará si la dirección destino coincide con alguna de las entradas que posee en
su tabla de enrutamiento, luego tomará el paquete y nuevamente lo encapsulará
en una trama para ser enviado por la interfaz que corresponda.
Los routers funcionan en base a protocolos, los cuales harán posible encaminar
los paquetes desde un lugar a otro. Ejemplos de este tipo de protocolo son EIGRP
y OSPF, los cuales dependiendo del caso, dirigirán el tráfico en base la cantidad
de saltos, mejor ruta, costos, etc.
4.11 TIPOS DE REDES
55
En la actualidad existen numerosos tipos de redes, las cuales se clasifican por su
tamaño y distribución lógica. En esta oportunidad nos vamos a centrar en el
estudio de las que conciernen al proyecto en curso. Por lo tanto, entre los tipos
principales de redes podemos encontrar:
4.11.1 LAN
Local Area Network o Red de Área Local. Este tipo de red conecta dispositivos en
una distancia relativamente pequeña, las cuales pueden estar dentro de una
oficina o edificio. Generalmente están constituidas dentro de una misma subred,
por lo que su administración es relativamente simple.
4.11.2 WAN
Wide Area Network o Red de Área Extensa. Esta red abarca grandes
dimensiones, como un país, continente o el mundo.
4.11.3 MAN
Metropolitan Area Network o Red de Área Metropolitana. Es más grande que una
LAN pero más pequeña que una WAN, por ejemplo, sus dimensiones podrían ser
las de una ciudad.
4.11.4 VPN
Virtual Private Network o Red Privada Virtual. Es un tipo de red que se configura
lógicamente, entre dos equipos remotos.
4.12 FIREWALLS
56
Como ya se ha estudiado, existe equipamiento que se ha especializado en ciertas
áreas. Algunos de ellos en el usuario final, otros como funciones especificas
dentro del área de servidores, otros proporcionan direccionamiento de tráfico
como los routers.
Considerando todos los factores ya estudiados, incluyendo las direcciones de
origen y de destino, números de puerto, protocolos asociados, números de
secuencia, tamaño de paquetes y los datos enviados en ellos, podremos analizar
correctamente que es un firewall o corta fuegos y determinar cuáles son sus
principales funciones.
Un firewall, al igual que otros dispositivos, se trata de un computador
especializado en mantener la seguridad de las redes a las cuales está conectado.
Así, el firewall será el dispositivo que podrá actuar como una medida de protección
ante posibles ataques, bloqueando cierto tráfico que no esté permitido o que no
sea requerido por alguno de los hosts que está protegiendo. Este tipo de
protección es realizada en base a parámetros, los cuales pueden ser muy simples
y basados en los puntos anteriormente mencionados, hasta otro tipo de
equipamiento que emplea técnicas más avanzadas y depuradas para filtrar e
inspeccionar el tráfico entrante.
4.12.1 Tecnologías Firewall
Un firewall puede ser un dispositivo de hardware dedicado con cierto software pre-
instalado (appliance), o bien un software que puede establecer ciertos límites. Por
ejemplo, un router o un dispositivo de capa 3 que posea listas de acceso u otro
método de filtrado de paquetes entre dos o más interfaces diferentes, podría
actuar como firewall.
En adición, podemos encontrar firewalls bajo licenciamiento Open/GNU que son
de sencilla instalación para el caso de empresas pequeñas denominadas en
57
territorio nacional como PYMES (Pequeña y Mediana Empresa). También existen
opciones dedicadas para empresas medianas y grandes empresas, que utilizan
técnicas y configuraciones avanzadas requieren de mayor conocimiento para una
correcta implementación y desarrollo.
Existen hosts que poseen software dedicado que impide el tráfico saliente o
entrante en cada socket de conexión, esto constituye un ejemplo de software
firewall.
4.12.2 Objetivos de un Firewall
Debe ser resistente a los ataques. Si el firewall puede ser desconectado
remotamente (o sus servicios de bloqueo), compromete su integridad al punto de
que permita tráfico no deseado, incluso si el firewall permite ataques del tipo de
denegación de servicio (Denial of Service, DoS) y no permite el acceso a los
usuarios, o si existe alguna falla de seguridad que pueda ser activada con un
exploit, todas son razones válidas para que un firewall se mantenga siempre
suficientemente estable y resista posibles ataques.
El tráfico entre diferentes redes debe ser forzado a través de un firewall. Si existe
una conexión alternativa, el tráfico malicioso podría aprovecharse de éste punto y
cruzar desde una red a otra sin ningún tipo de filtro.
Debe forzar la aplicación de la política corporativa. Una buena política empresarial,
sin importar el tamaño de la empresa, debe estar escrita y documentada
apropiadamente. Luego, a partir de ella, debe ser aplicada en el firewall, en este
orden.
Para algunas compañías, muchas veces el poseer un firewall o un dispositivo de
seguridad debe ser apropiadamente justificado debido a que la inversión para
adquirir uno es importante. Sin embargo, considerando los beneficios, la inversión
58
retorna rápidamente. Un firewall va a proteger la exposición de los datos frente a
individuos no confiables, usuarios no autorizados, agregar seguridad adicional a
otras zonas de la red, virus, etc. Por supuesto, el instalar un firewall no va a liberar
la empresa de todos los ataques del mundo, pero si liberará un gran porcentaje de
ellos.
4.12.3 Cinco Métodos de Tecnología Firewall
Filtros de paquetes estáticos. Está basado en la capa 3 y capa 4 del modelo OSI.
Por ejemplo, un router con una lista de acceso entre dos o más interfaces podría
pertenecer a este segmento y permitir o denegar trafico especifico. Uno de los
problemas de este tipo de filtros, es que el administrador debe conocer
exactamente que desea filtrar, lo que puede ser confuso cuando se tienen muchos
usuarios con diferentes servidores de acceso. Como ventaja, provoca muy poca
latencia en la red y es de fácil configuración.
Cada vez que el tráfico es recibido o enviado, es comparado a un set de reglas
aplicado. Si el tráfico concuerda con alguna de ellas, será descartado o permitido y
dejará de buscar dentro del resto de las reglas.
La primera mención de tecnología será referida al Proxy. Denominados también
como Application Layer Gateway o Proxy Firewalls, pueden operar desde la capa
3 del modelo OSI hacia arriba. El proxy actúa como un intermediario entre el
cliente y el servidor, debido a que no existirá comunicación directa entre ellos.
Además, como este dispositivo puede operar hasta en la capa 7 del OSI, los filtros
pueden llegar a ser muy granulares y analíticos para cada uno de los paquetes
que intercambien ambos nodos y así forzar la aplicación de las reglas respectivas.
Como desventaja, este tipo de equipamiento produce cierto grado de latencia
debido a la alta utilización de memoria y procesamiento en el servidor proxy.
59
La segunda mención de tecnología será referida al Stateful Packet Filtering. Es
una de las tecnologías más importantes hoy en día. No tiene una traducción
definida aunque es llamado filtrado dinámico para la inspección de paquetes, por
que recuerda el estado de las sesiones que vas a través del firewall. Así, el firewall
revisará las direcciones IP de origen y destino, números de puerto asociados y
otra información de las cabeceras respectivas, siendo comparadas en su reingreso
a la tabla respectiva. Si un atacante desea ingresar, no podrá debido a que este
tráfico esta denegado por defecto.
La tercera mención de tecnología será referida al Application Inspection. O bien
Inspección de Aplicación, puede inspeccionar toda clase de protocolos incluyendo
aquellos de la capa 7 del modelo OSI, pero no actuará como proxy entre el cliente
y el servidor que el está tratando de acceder.
Y por último, La cuarta mención de tecnología será referida al Trasparent
Firewalls. O Firewalls transparentes, poseen una gran diferencia con los tipos de
firewalls ya nombrados anteriormente y es debido a que ellos se implementan a
nivel de capa 2 del modelo OSI. La mayoría de los firewalls tradicionales se
configuran a nivel e capa 3, es decir entre dos diferentes subredes. En un
Transparent Firewall todavía tendremos dos interfaces de red, pero no tendremos
configuradas direcciones IP para cada una de ellas, actuando como un switch con
dos puertos en la misma VLAN.
4.12.4 NAT
Su acrónimo significa Network Address Translation o en español Traducción de
Direcciones de Red. Corresponde a una de las características más importantes de
los equipos firewall y es ampliamente implementada. Su funcionamiento se basa
en asignar una dirección IP válida sobre la internet, a una dirección IP privada.
Esta característica no sólo puede proveer una traducción 1 a 1, es decir, una
dirección IP pública a una dirección IP privada, sino también se puede asignar una
dirección IP pública a varias direcciones IP internas utilizando la característica
60
PAT (Port Address Translation) que significa Traducción de Direcciones de Puerto,
ampliamente utilizado para la navegación en internet por múltiples usuarios.
Gracias a esta funcionalidad, se ha logrado explotar de mejor manera el
direccionamiento IPv4.
4.12.5 VPN
Su acrónimo viene del inglés: Virtual Private Network. En español se traduce
como: Red Privada Virtual. Esta conexión se realizará a través de dos dispositivos
que se encuentren a grandes distancias entre si, cuya interconexión será a través
de Internet. Una VPN agregará integridad y confidencialidad a la información que
será enviada, para lograr que los datos lleguen a destino sin ningún tipo de
alteración o manipulación.
Si bien es posible contratar un enlace WAN con un proveedor de servicios de
Internet (ISP), los costos de estos son altísimos. VPN surge como una excelente
alternativa para enviar tráfico encriptado a través de la Internet a un mínimo costo.
Además, hablamos de una tecnología que es escalable. Se puede utilizar desde
unos cuantos usuarios conectados a través de una conexión DSL utilizando un
software cliente VPN, hasta dos firewalls conectados entre sí como sitios remotos
(Site-to-Site VPN).
4.12.6 Tipos de Tecnología VPN
Basados en la definición de VPN, se pueden considerar como tal las siguientes
tecnologías:
4.12.7 IPSec
Es el acrónimo de Internet Protocol Security. Es un conjunto de protocolos que
tiene como trabajo asegurar las comunicaciones sobre el protocolo Internet (IP),
autenticando, validando o cifrando cada paquete IP en un flujo de datos. Este
61
protocolo incluye el establecimiento de claves de cifrado. Implementa seguridad de
paquetes IP en la capa 3 del modelo OSI y puede ser utilizado para Site-to-Site
VPN’s o VPN de Acceso Remoto.
4.12.8 SSL
Es el acrónimo de Secure Socket Layer. Es un estándar de seguridad que permite
implementar seguridad entre un servidor web y un browser cliente. Esta conexión
se asegura de que toda la comunicación se produzca dentro de túnel,
manteniendo la información integra y confidencial. Implementa seguridad a las
sesiones de TCP en la capa 4 del modelo OSI y puede ser utilizado como VPN de
acceso-remoto.
4.12.9 MPLS
Es el acrónimo de Multiprotocol Label Switching. Este protocolo permite la entrega
de la información a través de la segunda capa en lugar de pasarlo a la tercera, la
capa de red. Por lo tanto, es un servicio que provisto por un ISP para interconectar
2 o más sucursales de una compañía. Si bien es un tipo de VPN (MPLS L3VPN)
no existe encriptación por defecto.
4.13 TIPOS DE VPN
4.13.1 Remote-Access
Conexión remota desde el equipo de un usuario hasta las oficinas centrales de la
compañía, donde se encuentra el firewall con la tecnología VPN.
4.13.2 Site-to-Site
62
Una de las implementaciones más importantes para las empresas, debido a que
provee conexión y acceso seguro a las empresas que poseen dos o más oficinas y
necesiten interconectar sus redes. Este tipo de tecnología, al igual que Remote-
Access, trabaja sobre Internet.
4.13.3 Principales beneficios de las VPN
El primero de los beneficios es la Confidencialidad. Los datos son encriptados a
través de algoritmos matemáticos previamente configurados, que tan solo emisor y
receptor tienen la capacidad para descifrar la información.
El segundo de los beneficios es la Integridad de los datos. Existen algoritmos que
permiten identificar si los datos llegan a destino íntegros, o bien, es posible
retransmitir la información.
El tercero de los beneficios es la Autenticación. Existen múltiples métodos para
lograr éste punto, entre ellos la “pre-shared key”. Esta es una llave previamente
compartida, su traducción muy bien lo especifica, que permitirá verificar los puntos
remotos a autenticar. Es decir, ambos sitios tendrán esta llave y realizarán la fase
de autenticación preguntándose el uno al otro por este parámetro.
El cuarto de los beneficios es la Anti-respuesta. Los firewalls incorporan tecnología
que permite evitar respuestas de posibles atacantes, esto se logra determinando
los paquetes enviados en un preciso instante de tiempo. Es decir, en cualquier
otro instante de tiempo que el firewall no haya calculado su posible regreso, no
será válido como respuesta en ningún otro momento dentro de la sesión VPN. Por
lo tanto, la respuesta del posible atacante será bloqueada o descartada.
4.14 CRIPTOGRAFÍA
63
Es una ciencia que construye, estudia y analiza las múltiples técnicas de mantener
la seguridad de la información, además de la confidencialidad, integridad,
autenticación sobre una base de no repudio.
4.14.1 Keys
Llaves, son los métodos de autenticación frente a la criptografía.
4.14.2 Private Keys
O llaves privadas, es también conocida como Encriptación de llaves simétricas
(Symmetric Key Encription) o llamada también Criptografía convencional
(ConventionalCryptography).
Este tipo de encriptación utiliza la misma llave para cifrar o descifrar. Por
supuesto, este tipo de encriptación no es la más segura en un dominio público.
4.14.3 Public Keys
O llaves Públicas. Este tipo de encriptación utiliza dos llaves, una de ellas es
pública y la otra es privada. Ambas llaves pueden cifrar información, pero sólo la
llave privada puede descifrar. El problema con este tipo de criptografía es la
lentitud.
4.14.4 Session Keys
Para evitar la lentitud del proceso anterior, se crea una llave por sesión.
4.14.5 Certificados
Estos son contenedores de llaves públicas. Este tipo de archivos pueden contener
otro tipo de información como la fecha de creación, dominio creador o firmas
64
digitales. Es recomendable que los certificados digitales sean gestionados a través
de un proveedor de este servicio, pagando la prima que corresponda.
4.14.6 Firmas digitales
Este tipo de criptografía le permite al receptor del mensaje verificar la validez de la
entidad que creó el mensaje y que no ha sufrido ningún tipo de modificación o
alteración en la entrega desde que fue firmado en el origen.
4.14.7 Kerberos
Es un protocolo de autenticación que permite a dos hosts demostrar su identidad
entre ellos de forma segura en una red insegura. Está basado en una tecnología
de encriptación por llaves privadas. Trabaja en conjunto con tecnologías como
Single-Sign-On, que corresponde a una medida de seguridad que entrega al
usuario la capacidad de tener una única contraseña para sus aplicaciones.
4.14.8 Especificaciones Adicionales al Protocolo IPSec
Este protocolo puede ser utilizado para proteger datagramas TCP/UDP, de ahí su
flexibilidad de trabajo en la capa 3 del modelo OSI. Así, su conjunto de protocolos
aseguran la confidencialidad, la integridad de los datos y la autenticación. Algunas
de las características que provee es la autenticación mediante firmas digitales
para verificar la identidad del remitente. Para cumplir este objetivo, puede utilizar
certificados digitales, Kerberos o una clave compartida previamente.
Otra característica es proveer Integridad de los datos a través del Hashed
Message Authentication Code (HMAC), con esto se asegura de que los datos no
han sido manipulados en la red. IPSec mantendrá la Confidencialidad de la
información a través de la encriptación, cambiando el texto plano por texto cifrado.
Así aunque sea interceptada, no podrá ser descifrada.
65
IPSec provee Soporte anti-respuestas (Anti-reply Support). Esto es cuando las
VPN’s son establecidas, cada nodo numera sus paquetes en forma secuencial,
entonces si un paquete es reenviado o respondido por un posible atacante, el
paquete no será aceptado por que la VPN pensará que el paquete ya ha sido
procesado.
Otra característica es que ofrece soporte de no repudio. Esto se logra utilizando
firmas digitales, de tal forma que el remitente no pueda negar el envío.
IPSec trabaja con claves dinámicas, es decir, creará claves durante la sesión
protegiendo segmentos de la información con diferentes claves. La regeneración e
claves en IPSec se realiza mediante el algoritmo de intercambio de claves
denominado Diffie-Hellman (DH), el cual se utiliza para que dos equipos puedan
realizar el intercambio de llaves de manera exitosa y segura, creando una clave
privada compartida para autenticar la información y cifrar los datagramas IP. Los
distintos grupos D-H son el Grupo 1, Grupo 2, Grupo 3, Grupo 4 y Grupo 5.
Es importante mencionar que este protocolo tiene dos modos de funcionamiento:
El primer Modo será el modo de Transporte. En este modo son cifrados sólo los
datos que se transfieren en el paquete IP, manteniendo el enrutamiento intacto ya
que no se modifica la cabecera IP. Se utiliza para conexiones entre hosts.
Mientras que el segundo será el Modo Túnel. Aquí es cifrado todo el paquete IP,
por lo que debe ser encapsulado en un nuevo paquete IP para que pueda ser
enrutado. Se utiliza para una conexión entre dos redes remotas sobre un canal
inseguro.
4.14.9 Protocolos IPSec
Básicamente son dos, el primero Cabecera de autenticación o Authentication
Header (AH), el cual provee autenticación e Integridad a los datagramas que se
intercambian entre dos sistemas.
66
El segundo es Seguridad de encapsulamiento de carga útil o Encapsulating
Security Payload (ESP). Usado para entregar confidencialidad (encriptación),
autenticación de los datos de origen, integridad, servicio opcional anti-respuesta.
IPSec tiene un stack completo de protocolos que proveen diferentes
funcionalidades. Entre ellas encontraremos también Advanced Encryption
Standard (AES). Éste es un esquema de cifrado por bloques adoptado como un
estándar de cifrado por el gobierno de los Estados Unidos. Ha sido ampliamente
utilizado en el mundo entero y analizado exhaustivamente.
El predecesor de AES es el Data Encryption Standard (DES). Este es el algoritmo
de cifrado es utilizado en forma nativa por Windows Server 2003, el cual utiliza un
cifrado de 56-bit. No se recomienda debido a que se considera poco robusto. Ante
las vulnerabilidades presentes en DES, se le aplicó re-ingeniería y se reutilizó este
algoritmo. La opción fue utilizar tres rondas de DES sobre cada bloque de texto
plano (plain text), dando origen a Triple DES (3DES). 3DES tiene 3 modos de
operación, los cuales son conocidos también como “keying”. El primero o Keying
1, se utiliza con 3 claves distintas. El segundo o Keying 2, se utiliza con 2 claves
distintas (K1 = K3). Mientras que el tercero o Keying 3, utiliza tres claves que son
idénticas.
Respecto de AES, DES y 3DES son considerados como cifrados de bloques. Esto
significa que trabajan en bloques de un largo fijo, es decir, un bloque de texto
plano (plain text), sin cifrar, de un determinado tamaño que origina un bloque de
texto cifrado del mismo tamaño. Los equipos intercambian información que al ser
procesada por el algoritmo de intercambio, genera una clave compartida que luego
puede utilizarse como clave de sesión, o para generar una clave de sesión que
luego se utilizará para cifrar la información.
Analizando un poco más el método de autenticación utilizado por IPSec,
entenderemos que la por autenticación realizará la verificación de la identidad del
67
equipo que envía la información (remitente), o la identidad del equipo que la recibe
(destinatario). Luego tenemos NTLM, un mecanismo de autenticación de tipo
“challenge/response” propietario de Microsoft e interoperable con Active Directory.
Si consideramos un poco más en detalle el algoritmo de integridad, entenderemos
que su funcionamiento es su propia aplicación a la información que se transmitirá,
de tal forma que el remitente generará un hash del mismo, el cual se adjunta al
paquete. Cuando el destinatario recibe el paquete, procede a separar el hash
calculado por el remitente y a calcular el propio, a partir de la información del
paquete recibido. Luego compara su hash con el del remitente y si son iguales,
entonces se comprueba que el paquete no fue alterado en tránsito. Como
ejemplos tenemos MD5, SHA y sus variantes SHA-256, etc.
Cuanto mayor el largo de clave, se considera más robusto, debido complejidad de
los cálculos criptográficos. Sin embargo eso también significa un mayor consumo
de recursos por parte de los equipos, principalmente ciclos de CPU.
5. CAPÍTULO V: FUNDAMENTOS TEÓRICOS EN SISTEMAS
OPERATIVOS
Este es una herramienta lógica que permite administrar y coordinar todos los
componentes complejos de hardware y sus respectivas funciones. Los
computadores modernos constan de procesadores, múltiples memorias, interfaces
de red y un sin número de otros periféricos. Lo anterior, en base a una asignación
ordenada y controlada de todos aquellos programas que compiten por los
recursos.
Los sistemas operativos de hoy en día permiten la ejecución de múltiples
aplicaciones, administración de recursos, multiplexación de datos y ejecución de
aplicaciones multiusuarios.
68
Existen sistemas operativos para múltiples dispositivos, tanto equipos de usuario
final, como dispositivos especializados de comunicaciones. En particular, los
sistemas operativos también son aplicables a aquellos que proveen servicios a
otros y son llamados servidores. En particular, Microsoft ha desarrollado sistemas
operativos a partir del año 1993, fecha que marcó un hito en la compañía debido a
la primera división entre sistemas operativos para usuarios finales y servidores.
5.1 WINDOWS SERVER 2003
Este sistema operativo es modular. Todos sus objetos propios exponen interfaces
que aprovechan otros objetos y procesos que interactúan entre ellos para obtener
funcionalidades y servicios. Este sistema operativo, posee dos grandes capas:
Modo Usuario y Modo Kernel [5].
La siguiente figura 5.1 representará los modos y sus sistemas del Sistema
Operativo, mostrando su operación en bloques para una mejor apreciación. Luego
se explicará en detalle cada una de sus partes, operación, etc. [6]
69
Figura 5.1 Muestra la arquitectura base para todas las versiones de Windows
Server 2003: Standard, Enterprise, Datacenter y Web Server.
5.1.1 Modo Usuario
Corresponde al soporte de la capa de aplicación para el ambiente de software
Microsoft y aplicaciones de terceros. Esta es la parte del sistema operativo donde
ambas aplicaciones partes pueden hacer llamadas al sistemas operativo en base
a las API’s publicadas o la estructura de Orientación a Objetos. Todas las
aplicaciones y servicios están instaladas en la capa Modo Usuario.
5.1.2 Ambiente de subsistemas
Provee la capacidad de correr aplicaciones que podrían haber sido escritas para
diferentes sistemas operativos. Diseñada para interceptar las llamadas que se
realizan a una API en particular y convertirlas en un lenguaje que entienda el
70
Aplicaciones Win32
Subsistema
Integral
Aplicaciones POSIX
Aplicaciones OS/2
Subsistema
WIN32
Subsistema
POSIX
Subsistema OS/2
MODO USUARIO
SERVICIOS EJECUTIVOS MODO KERNEL
Servicios Ejecutivos
Hardware
Capa de Abstracción de Hardware
Administrador de Objetos
Dispositivo Drivers Micro Kernel
Sistema de Archiv
os
Administrador de I/O
Administrador Referencia o Seguri
dad
Administrador
PC
Administrador
de Memo
ria
Administrador
de Procesos
Administrador PNP
Administrador
de Poder
Administrador
de Venta
naServicios
Ejecutivos
sistema operativo base. Es entonces, cuando se le debe dar respuestas a las
llamadas aprobadas. La siguiente tabla 5.1, explica la función de cada uno de los
componentes de la arquitectura.
Ambiente de Sub-Sistema
Propósito
W. Server 2003
Soporta aplicaciones basadas en W32/64 Bits.Responsable por las aplicaciones DOS basadas en 16 bits.Aquí todas las aplicaciones I/O y funcionalidades GUI son manejadas.Desde este sistema operativo en adelante fue diseñado para mejorar la experiencia de Terminal Services
OS/2 Soporta aplicaciones de 16 bits, principalmente Microsoft OS/2.POSIX Sólo aplicaciones POSIX, usualmente UNIX
Tabla 5.1 Muestra los sistemas soportados por el ambiente de subsistema
5.1.3 Subsistema Integro
Es utilizado para realizar funciones críticas propias del sistema operativo. La
siguiente tabla 5.2, muestra estas funciones:
Sub-Sistema Integral Propósito
Sub-Sistema de Seguridad
Servicios relacionados a los permisos para cuentas de usuario, control de acceso a toda la red, Objetos de Sistema Operativo definidos, Solicitudes y procesos de autenticación en inicio de Sesión.
Servicio de ServidorEste subsistema convierte a W2003 Server en un sistema operativo de red. Todos los servicios de red tienen a este subsistema como raíz.
Servicio WorkStationEstá orientado al acceso del usuario a la red. Sin embargo, es posible trabajar en una estación de trabajo si este sub-sistema/Servicio está deshabilitado.
Tabla 5.2 Subsistemas Integrales
71
5.1.4 Modo Kernel
Esta es la capa que tiene acceso a los datos del sistema y el hardware, listados en
la tabla 5.1. Los respectivos componentes de su arquitectura se definen de la
siguiente manera:
5.1.5 I/O manager
Maneja la entrada de los todos los dispositivos a la maquina.
En particular, este incluye los siguientes servicios:
o Sistema de Archivos. Traduce requerimientos del sistema de
archivos a llamadas específicas a dispositivos.
o Drivers. Maneja los controladores que acceden directamente el
hardware.
o Administrador de Cache. Maneja el rendimiento del administrador I/O
a través de la cache interna en la lectura del disco.
5.1.6 Referencia de Monitor de Seguridad
Este componente fuerza las políticas de seguridad en el equipo.
5.1.7 Administrador de comunicación de Interprocesos
Es el responsable por la comunicación entre el cliente y los procesos del servidor.
Este compromete las llamadas de procedimientos locales (LPC) y las llamadas de
procedimientos remotos (RPC).
72
5.1.8 Administrador de Memoria o Administrador Virtual de Memoria
Este componente administra la memoria virtual. Provee una dirección de espacio
virtual para cada proceso, a su vez que mantienen la integridad de del sistema.
Además controla la demanda del disco físico a la para la Memoria RAM Virtual,
conocida como paginación.
5.1.9 Administración de Procesos
Crea y termina procesos de hilos, creados por servicios o aplicaciones.
5.1.10 Administrador de Plug and Play
Provee la capacidad de entregar el servicio de “conectar y utilizar” o Plug-and-
Play, conecta directamente con los dispositivos o drivers relacionados.
5.1.11 Administración de Poder
Este componente controla la capacidad de administrar la energía del sistema.
Trabaja con varias APIs y administradores de poder del sistema.
5.1.12 Administrador de ventanas y Dispositivo de Interfaz Gráfica
(GDI)
El driver asociado combina el servicio de control para ambos componentes y
administra la pantalla de sistema como sigue:
5.1.13 Administrador de ventana
Administra la pantalla de salida y el entorno de ventanas. También maneja los
datos de I/O desde el ratón y teclado.
73
5.1.14 GDI
Este componente maneja el código, el dibujo y manipulación de gráficos en
pantalla y otros objetos que ocupan estos servicios.
5.1.15 Administrador de objetos
Este motor administra el sistema de objetos (crea, administra y elimina). En
adición a los servicios indicados en la figura 1.4, existen otros 3 núcleos del
sistema que completan la capa del modo kernel:
5.1.16 Drivers de Dispositivo
Este componente simplemente traduce las llamadas a los drivers en rutinas que
puedan manipular el hardware.
5.1.17 Microkernel
Este es el núcleo del sistema operativo. Administra los hilos de cada proceso que
ha sido creado en el microprocesador, agenda, interrumpe, etc.
5.1.18 Capa de abstracción de hardware
Esencialmente esta capa esconde los detalles del hardware, es decir, es una capa
de abstracción para otros servicios y componentes.
5.1.19 Arquitectura de Procesamiento
Está construida sobre una arquitectura de Multiprocesamiento Simétrico
(Symmetric Multiprocessing). Esto quiere decir, que está construido para poder
trabajar con múltiples CPU (Unidad Central de Procesamiento) y como segundo
74
punto, que puede crear todos los hilos y procesos que necesite, incluyendo sumar
la cantidad total de CPU o distribuir la carga.
5.1.20 Administración de Memoria
Consiste en un modelo de memoria que ha sido desarrollada desde la tecnología
NT, la cual consiste en una memoria plana, lineal, con direccionamiento de
espacio e implementada para 32 y 64 bits.
Existen 2 tipos de memoria utilizados en este sistema operativo servidor. La
primera es la memoria física, la que incluye los circuitos de memoria instalados en
la placa base, típicamente en forma de SDRam (Synchronous Dynamic Random-
Access Memory), DDRam o RamBus. La segunda es la memoria virtual, es
utilizada para administrarla memoria de sistema. Administra y combina toda la
memoria física en un sistema tal, que proporciona mayor cantidad de memoria
disponible que la disponible en los circuitos de memoria utilizando espacio físico.
5.2 ACTIVE DIRECTORY
Es un almacén de información universal distribuido a través del cual todos los
objetos de red, configuraciones de aplicaciones, servicios, usuarios, computadores
y procesos pueden acceder de manera consistente sobre toda la extensión de la
red. Esto es posible por la estructura lógica del directorio.
Si bien Active Directory tiene una historia relativamente reciente, sus orígenes se
basan en la tecnología X.500 bajo un protocolo conocido como Directory Access
Protocol (Protocolo de Acceso Directorio) o mejor conocido por su acrónimo DAP.
Este consistía en u conjunto de funciones que proveían capacidades a los clientes
de crear, modificar o eliminar información del directorio X.500. Luego, se construyó
una versión mucho más liviana denominada Lightweight Directory Access Protocol
(LDAP), la que fue sostenida por la IETF (Internet Engineering Task Force) [5].
75
De esta forma, LDAP consistirá en los siguientes componentes que constituyen la
base de la mayoría de los directorios, incluyendo Active Directory de Microsoft:
5.2.1 Modelo de Datos
Representa como se accede a los datos del directorio. El modelo de datos es
heredado, por lo que cada objeto tendrá asignado atributos, a su vez, cada
atributo contiene diferentes valores.
Los objetos serán clasificados en grupos o clases, como unidades organizaciones
(OU). El mismo modelo se aplica a otras herramientas de ésta línea de Servidores
y sus respectivos modelos de desarrollo e Ingeniería de software.
5.2.2 El Modelo Organizacional
El Servicio de Nombres de Directorio (Domain Name System, DNS) está
modelado tal como un árbol invertido. Contiene una raíz y millones de hojas o
nodos.
5.2.3 El Modelo de Seguridad
Especifica cómo se accede a la información de forma segura y privada.
LDAP adoptó la contraseña de autenticación Kerberos y ha adicionado capas
adicionales de autenticación a través de la capa de autenticación de Seguridad
Simple (Simply Authentication Security Layer, SASL). La versión 3.0 de LDAP
también soporta SSL (Secure Socket Layer).
5.2.4 El Modelo Topológico
Especifica cómo se integra o relaciona con otros servicios de directorio.
76
5.3 ARQUITECTURA ACTIVE DIRECTORY
5.3.1 Bosques (Forests)
Estos consisten en uno o más controladores de dominio que comparten el
esquema de un catalogo global.
Si existen varios dominios dentro de un bosque y todos ellos comparten el mismo
esquema de nombres DNS, entonces hablaremos de un árbol de dominios. Este
ejemplo se grafica en la siguiente figura 5.2:
Figura 5.2 Árbol DNS
Un bosque puede estar compuesto por uno o más arboles de dominio, siendo el
dominio del bosque raíz el primer dominio en el directorio.
5.4 CONTROLADORES DE DOMINIO
Un controlador de dominio tiene como principal característica la administración de
Active Directory. Este, como cerebro y sistema nervioso central del dominio,
entrega autenticación a los usuarios, administra la seguridad y entrega control de
acceso a las comunicaciones, impresiones, acceso a la información, etc. También
almacena la información corporativa, la estructura de la red, entre otros.
77
5.4.1 Catalogo Global
Este es un controlador de dominio, que ha sido designado y habilitado
manualmente para ser contenedor del catalogo global. Entre sus principales
funciones:
La primera de sus funciones tratará sobre ser un servidor donde los usuarios
pueden autenticarse y validar sus cuentas de dominio. Esto significa que tiene una
réplica completa de los usuarios del dominio.
La segunda es que provee búsquedas rápidas entre el dominio sin tener que iterar
entre arboles de dominio.
5.4.2 Sites
Un site (sitio) es una representación de una LAN, con la abstracción de tener un
Active Directory bajo una arquitectura TCP/IP, denominado como unidad lógica.
Bajo este esquema de sitios, los servidores Microsoft realizan una replicación
entre ellos acorde a lo modelado por el administrador. Para que esto ocurra de
manera confiable y rápida, debe estar definido un modelo de sub-direccionamiento
bajo la red TCP/IP, para así mapear todo lógicamente bajo la misma estructura
física.
5.5 FSMO
Es el acrónimo para ésta denominación es Flexible Single Master Operations. En
cada dominio existe cinco únicos maestros esquema para determinada
funcionalidad, siendo este responsable de los cambios efectuados en el
controlador de dominio respectivo: El maestro esquema. Existen 5 tipos de
maestros esquema: 2 roles a nivel de bosque y 3 roles que son a nivel de dominio.
78
5.6 MAESTROS DE OPERACIÓN A NIVEL DE BOSQUE
5.6.1 Maestro de esquema (Schema Master)
Este es el único servidor que puede realizar modificaciones al esquema. Cada una
de las modificaciones será entonces replicada a todos los demás controladores del
dominio.
5.6.2 Maestro de nombres de Dominio (Domain Naming Master)
Garantiza la unidad de los nombres de dominio que se agreguen al bosque del
directorio. Este controlador de dominio es el único que puede agregar o quitar un
dominio del directorio.
5.7 MAESTROS DE OPERACIÓN A NIVEL DE DOMINIO
5.7.1 Maestro RID (Relative Identifier Master)
Cada vez que creamos un objeto en el dominio se le es asignado un SID (Security
ID). Este es una identificación única y nunca es reutilizada, aunque la cuenta
original sea eliminada. De esta manera, este maestro asigna una cantidad
determinada de identificadores RID a cada servidor controlador de dominio, así
todos ellos disponen de una cantidad determinada de RID's para creación de
nuevos objetos.
5.7.2 Maestro de Infraestructura (Infrastructure Master)
Es el responsable de mantener la información actualizada de cada objeto del
dominio. De esta forma, si el objeto es transferido a otro dominio, será este
maestro quien entregue y actualice toda la información del objeto correspondiente
para la siguiente ubicación.
79
5.7.3 Maestro controlador Principal de Dominio (Primary Domain
Controller Emulator)
Es un maestro controlador de dominio que mantendrá la compatibilidad entre
tecnologías anteriores. Además, es el servidor que recibe de manera preferencial
la replicación de los cambios de contraseña para cuentas de usuario, es el
responsable del servicio de horario como "Time Server" del dominio, cumple como
principal controlador de servidor de directivas de grupo (Group Policy Objects,
GPO).
5.8 DOMINIOS
Un dominio es un contenedor lógico de la red, el cual controla el acceso a los
recursos. De cierta forma, el dominio no existe en un sentido físico pero siempre
se puede acceder a él utilizando un acceso remoto, conexión directa a su LAN,
etc. Es decir, representa el conjunto de recursos y dispositivos de los cuales
dispone una red, pero con los límites de seguridad que éste impone.
Un dominio es protegido y mantenido por los controladores de dominio (Domain
Controllers). Estos mantienen las bases de datos para autenticar usuarios
confirmando sus credenciales de seguridad. Estas bases de datos son conocidas
como SAM (Security Accounts Manager).
5.9 DNS
[4] El Servicio de Nombres de Dominio (Domain Name System), es un sistema
jerárquico que provee un servicio de traducción o mapeo de nombres a
direcciones IP, pudiendo ser esta ser una red privada o Internet, pero siempre
identificando nodos.
80
Los nombres de dominio no están ubicados a un mismo nivel. Estos a su vez
pueden incorporar dominios adicionales, es decir, el DNS distribuye la
responsabilidad de asignar nombres de dominio y su mapeo respectivo a
direcciones IP, mediante la designación de Authoritative Name Servers
(Servidores de Nombre Autoritativos) para cada dominio y ellos a su vez podrían
delegar responsabilidades sobre su dominio asignado a otros servidores.
Un ejemplo de dominios de nivel superior y su respectiva denominación y
utilización, lo registra la tabla 5.3 lista los dominios originales de nivel superior,
indicando como ejemplo los tipos de dominios disponibles a nivel de internet.
Sufijo Propósito EjemploCom Organizaciones Comerciales microsoft.comEdu Organizaciones Educacionales mit.eduGov Organizaciones Gubernamentales nasa.govInt Organizaciones Internacionales nato.intMil organizaciones Militares army.milNet Organizaciones de Networking mci.netOrg Organizaciones sin fines de lucro ieee.org
Tabla 5.3 Dominios originales de nivel superior
El DNS tiene una profundidad variable, donde cada nodo es un árbol que tiene
una etiqueta asociada.
El nombre de dominio de un nodo es una concatenación de todas las etiquetas de
la ruta desde el nodo a las raíces del árbol. Por lo tanto y con lo que ya
consideramos anteriormente, cada subdominio estará separado por puntos y
podría tener sub-servidores que controlen cada resolución de nombres respectiva.
Por lo tanto, el FQDN (Fully Qualify Domain Name) de un host será su localización
absoluta en un espacio de dominio DNS. Esto es para un servidor DNS LAN o de
Internet, en ambos casos aplica de igual forma.
81
5.9.1 Tipos de registros
El primer registro es el SOA (Start of Authority). El registro SOA indica que el
servidor es autoritativo sobre el dominio.
El segundo tipo de registro es el Host A. Registra el nombre para la dirección IP de
un servidor.
El tercer tipo de registro es CNAME (Canonical Name o Alias Records). El cual
registra un alias para un FQDN.
El cuarto tipo de registro es Mail Exchanger (MX). Estos registros habilitan a los
servidores para dirigir el tráfico de correo electrónico. Este registro incluye el
FQDN del servidor de correo y un número de preferencia numerado entre 0 y
65535.
La funcionalidad de los registros MX es determinar la entrega de correo e indicar
la preferencia en la entrega de correo electrónico, dependiendo de la cantidad de
servidores configurados.
El quinto tipo de registro son los Pointers (PTR), los cuales mapean direcciones IP
a nombres.
5.9.2 Resolvers, Name Servers, Forward Lookup
Los servidores DNS cliente son llamados Resolvers, estos envían consultas a los
servidores DNS para resolver nombres en direcciones IP. Por ejemplo, el host
cliente realizará la consulta al DNS configurado en su conexión TCP/IP, por lo que
en primera instancia se asume que será el servidor DNS propio de nuestra LAN.
Este servidor revisará su caché local (la cual almacena consultas anteriores) y su
base de datos interna. Si no tiene registros asociados, realizará una búsqueda
82
acorde a la dirección de sus DNS Forwarders configurados (o servidor DNS
externo configurado para realizar consultas de nombres) hasta llegar a los ROOT
Servers (o servidores raíz). Finalmente, estos servidores responderán el mensaje
con la dirección IP correspondiente.
La siguiente figura 5.3 muestra el proceso de consulta de nombres a un DNS de
Dominio y a un Root Server, ejemplificando lo expuesto anteriormente.
Figura 5.3 Ilustración del procedimiento de resolución DNS
5.9.2 DHCP
Es el Protocolo de configuración dinámica de hosts, viene del inglés Dynamic Host
Configuration Protocol. Es un protocolo que automáticamente asigna
direccionamiento IP a los host que podrían estar conectados en una red TCP/IP.
Éste protocolo utiliza UDP como protocolo base para la entrega de sus mensajes.
83
La asignación de direccionamiento dinámico es la función más importante del
DHCP. Este servicio proporciona una administración automática de cada dirección
IP entregada, previniendo que dos equipos tengan la misma dirección. Dentro de
la información entregada adicional al direccionamiento IP podemos encontrar:
Máscara de red, puerta de enlace (Default Gateway), Servidores DNS primario y
secundario, etc. Existe además el término "lease" o arriendo, que proporciona la
reutilización del direccionamiento IP valiéndose de la entrega de direcciones sólo
por un tiempo determinado. Cuando ésta expira, el servicio la recupera y puede
reutilizarla con un cliente diferente [7].
5.10 RADIUS
Los diversos sistemas operativos, incluyendo sistemas operativos Microsoft,
incluyen un servicio llamado Servicio de Autenticación de Internet (Internet
Authentication Service, IAS), el cual trabaja con un protocolo de autenticación y
verificación de servicios de acceso llamado RADIUS (Remote Authentication Dial-
In User Server).
En adición a las características de este protocolo, también realiza “accounting”
realizando registros del control de usuarios, duración de la sesión, etc. Sus
características lo hacen particularmente interesante para servicios de Inicio de
sesión único (Single-Sign-On), es decir, utilizar una única cuenta de Active
Directory para todos los servicios de red. Esto se debe a que su operación puede
proveer una fuerte autenticación, además de que puede trabajar con múltiples
dispositivos como equipos wireless con autenticación de Active Directory, o bien,
servicios remotos de VPN bajo el mismo tipo de validación.
Existen aplicaciones libres que permiten utilizar este protocolo sin la necesidad de
contar con un servidor de línea Microsoft. En este proyecto en particular, se tienen
las licencias del sistema operativo por lo que se utiliza la aplicación ya integrada.
84
6. CAPÍTULO VI: FUNDAMENTOS TEÓRICOS GESTIÓN DE
PROYECTOS
6.1 DEFINICIÓN DE PROYECTO
Se identifica como proyecto a un esfuerzo temporal que se lleva a cabo para
terminar un producto, servicio o resultado único. Po ser temporales, tienen una
condición predefinida de límites tanto de inicio como para el final del proyecto. El
final de un proyecto será cuando sean alcanzados los objetivos propuestos al
inicio o cuando se da un corte al proyecto porque se ha identificado con claridad
que no será posible alcanzar los resultados esperados o cuando ya no existe la
necesidad de continuar con el proyecto. Cuando hablamos de una duración de
tiempo determinada, no hacemos mención directa a un tiempo acotado o de corta
duración [8].
Un esfuerzo de trabajo permanente suele ser un tanto repetitivo, ya que seguirá
procesos, estándares y procedimientos impuestos por un consultor, experto o
propios de la empresa.
6.2 DIRECCIÓN DE PROYECTOS
Es la aplicación de conocimientos, estándares, habilidades, herramientas y
técnicas a las actividades propias del proyecto. Según menciona el estándar
internacional PMBOK (Project Management Body of Knowledge), cumplir con una
dirección de proyectos se basa en un proceso modelado en 42 fases, los que
agrupados lógicamente, se conforman en 5 grupos de procesos los cuales son:
Iniciación.
Planificación.
Ejecución.
Seguimiento y control.
Cierre.
85
Dirigir un proyecto Implica:
Identificar requisitos.
Abordar las diversas necesidades, inquietudes y expectativas de los
interesados según se planifica y efectúa el proyecto.
Equilibrar las restricciones contrapuestas del proyecto que se relacionan
con:
o El alcance.
o La calidad.
o El cronograma.
o El presupuesto.
o Los recursos.
o El riesgo.
6.3 PLANIFICACIÓN ESTRATÉGICA
Toda empresa genera una proyección y define su estrategia. Generalmente, todo
proyecto nace en base a este plan y son autorizados como resultado de alguna de
las siguientes consideraciones:
Demanda del mercado.
Oportunidad estratégica/Necesidad comercial.
Solicitud de un cliente.
Adelantos tecnológicos.
Requisitos legales.
Así, los proyectos están destinados a alcanzar objetivos y metas propios de la
organización.
86
6.4 CICLO DE VIDA DE UN PROYECTO
Se trata de un conjunto de fases, generalmente secuenciales y en ocasiones
superpuestas, cuyo nombre y número se determinan por las necesidades de
control y gestión de las organizaciones involucradas en el proyecto. Este ciclo es
posible documentarlo en base a una metodología, debido a que por su magnitud,
varían en tamaño y complejidad.
6.4.1 Interesados
Los interesados son personas u organizaciones cuyos intereses se pueden ver
afectados por el desarrollo de las actividades propias o bien, por el resultado del
producto final del proyecto, ya sea de manera positiva o negativa. Estos grupos de
interés pueden influir en el proyecto, los entregables y otros miembros del equipo.
6.4.2 Proceso de planificación
Este está compuesto por las actividades que nos harán saber el alcance total del
esfuerzo, así como la definición de objetivos y la línea de acción.
Desarrollar el plan para la dirección del proyecto.
Recopilar requisitos / Definir el alcance.
Recopilar una estructura que divida los entregables del trabajo.
Definir las actividades.
Secuenciar las actividades.
Estimar los recursos de las actividades.
Estimar la duración de las actividades / Desarrollar el cronograma.
Estimar costos.
Determinar presupuestos.
Planificar la calidad.
Desarrollar plan de recursos humanos.
Planificar la gestión de riesgos e identificarlos.
87
Realizar análisis cualitativo y cuantitativo de riesgos.
Planificar la respuesta de los riesgos.
Planificar las adquisiciones.
6.4.3 Grupo del Proceso de Ejecución
Está compuesto por los procesos realizados para alcanzar las metas propuestas.
Dirigir y gestionar la ejecución del proyecto.
Realizar aseguramiento de calidad.
Adquirir, desarrollar, dirigir al equipo del proyecto, distribuir la información.
Gestionar las expectativas de los interesados en el proyecto.
Efectuar adquisiciones.
6.4.4 Proceso de Seguimiento y de control
En este grupo están inmersas todas aquellas actividades que permitan supervisar,
analizar, regular el progreso y desempeño del proyecto. Así, si un cambio se
efectúa, se pueden tomar las acciones correspondientes. Ejemplos de estas
acciones son los siguientes puntos:
Seguimiento a las actividades del proyecto.
Realizar control integrado de cambios /Verificar/Controlar alcance.
Controlar costos.
Controlar cronograma.
Control de calidad / Informar el desempeño.
Seguir y controlar riesgos / Administrar las adquisiciones.
6.4.5 Grupo proceso de cierre
Está compuesto por aquellos procesos realizados para finalizar las actividades de
todos los grupos anteriores de la dirección de proyectos, a fin de terminar todas
las fases contractuales.
88
7. CAPÍTULO VII: DESARROLLO EXPERIMENTAL
7.1 APLICACIONES CRÍTICAS
Dentro de nuestra compañía existen 2 aplicaciones que son críticas y que
mantienen el negocio operativo. Una de ellas es el correo y la otra es la aplicación
Logística/Operacional Boss.
El desarrollo experimental consta de 3 pruebas principales. La primera de ellas es
la habilitación de túneles VPN entre todos los sitios a los nuevos núcleos de la red.
Como todo el resto de las oficinas ya tiene VPN's funcionando, la efectividad
operacional ya está probada y sólo es necesario configurar los nuevos túneles a
las nuevas locaciones.
Cada uno de los túneles fue configurado de acuerdo al estándar corporativo:
IKE Policy : ESP-AES-256 / SHA / DH5
IPSec Transform Set : ESP-AES-256 / SHA
La tarea de configuración de todos estos túneles fue realizada según Gantt a partir
del 30 de Agosto, por un plazo máximo de 43 días. Sin embargo, la configuración
tardó poco menos de una semana incluyendo la publicación a Internet de las
aplicaciones BOSS y CMS.
La siguiente figura 7.1 muestra como evidencia de la configuración los túneles
operativos de acuerdo a las especificaciones entregadas anteriormente, junto con
los datos transmitidos y recibidos. y bajo la aplicación de cisco ASDM (CISCO
Adaptive Security Device Manager). Una nota importante es que se ha eliminado
intencionalmente el primer y segundo octeto por confidencialidad de la información
corporativa.
89
Figura 7.1 Conexión de Túneles VPN
La siguiente figura 7.2 refuerza la anterior, demostrando la configuración y
creación de túneles VPN con los puntos remotos. Nuevamente, intencionalmente
se ha eliminado el primer y segundo octeto por confidencialidad de la información.
Figura 7.2 Configuración Túneles VPN
Respecto del proyecto, lo realmente crítico era saber cuáles serían los tiempos de
respuesta del nuevo correo. Mientras que el servidor Ms Exchange enviaba todo el
90
tráfico vía VPN sobre UDP, la conexión era muy sensible a cortes e intermitencias,
provocando continuos errores de conexión. La siguiente tabla 7.1 evidencia esta
aseveración, entregando datos importantes de la velocidad del tráfico y su latencia
promedio de unos 450ms desde Sudamérica, 150ms desde Estados Unidos y
menor a 80ms desde Europa.
Mediciones Anteriores
Tipo de Prueba OrigenDestino Medición [ms]
PingValparaíso Malmö 467
Ping Lima Malmö 450
Ping Seattle Malmö 342
Ping Rotterdam Malmö 75
Ping Sudáfrica Malmö 432
Ping Santiago Malmö 448
Tabla 7.1 Mediciones de conexión al Datacenter
Por otro lado y referente a la pruebas de correo electrónico, Google tiene
diferentes Datacenters en todo el mundo, facilitando el acceso de los usuarios
independiente de donde estos se encuentren. Sin embargo, no existía forma de
probar la conexión a este correo más que confiando en el proveedor, sus niveles
de SLA por contrato y su experiencia, sin contar el servicio gratuito que ofrece y la
utilización de este servicio por la mayoría de los usuarios. Es importante
mencionar que el proveedor no podía entregar el servicio como “demostración” o
“piloto”. Por ello, análisis de pruebas con este servicio no existen.
Respecto de las mediciones de interconexión de las nuevas oficinas, las pruebas y
mediciones finales concretas que se realizaron fueron en base a medición de
latencia en los nuevos centros de datos para saber si las replicaciones de
información del esquema del dominio y conexiones remotas funcionarían mejor
con menores niveles de retardo. La tabla 7.2 evidencia esta situación, dadas las
mismas pruebas anteriores se registraron niveles de velocidad superiores y con
menor escala de latencia en comparación a las pruebas realizadas anteriormente.
91
Nuevas Mediciones
Tipo de Prueba Origen Destino Medición [ms]
Ping Valparaíso Santiago 7
Ping Lima Santiago 244
Ping Seattle Santiago 188
Ping Rotterdam Santiago 191
Ping Sudáfrica Santiago 243
Ping Valparaíso Seattle 176
Ping Lima Seattle 171
Ping Santiago Seattle 188
Ping Rotterdam Seattle 182
Ping Sudáfrica Seattle 210
Tabla 7.2 Nuevas Mediciones a los Nuevos Núcleos WAN
Como se puede observar, todos los tiempos eran por mucho mejores que los
450ms medidos desde Chile a Suecia. Considerando que no existirá más tráfico
de correo electrónico por la red interna y que no es posible realizar una prueba en
un ambiente separado, se asume obtiene como resultado del análisis preliminar
que la nueva infraestructura trabajará correctamente, de manera más eficiente
basados en los resultados de los nuevos tiempos, los cuales permitirán disponer
de un mayor ancho de banda y así mejorarán el tráfico de esquema del dominio.
Otro factor importante que ya se mencionó de forma implícita, es que el correo
viajaba por tráfico VPN sobre el protocolo UDP. Como UDP es sensible a caídas y
no retransmite información, provocaba continuas caídas. A partir del nuevo
escenario, toda la comunicación será por tráfico TCP y por lo tanto este tipo de
problemas se ve solucionado.
Respecto de la configuración de los núcleos de la red WAN en Santiago y Seattle,
se muestra a continuación la evidencia de la replicación del esquema de Active
Directory en la figura 7.3. Cuya replicación entre ambos sitios está configurada
92
cada 30 minutos y su visualización es a través de la consola de Active Directory
Sites and Services:
Figura 7.3 Replicación de esquema Active Directory
La evidencia de la configuración DNS es una de las más importantes a nivel de
dominio. Por ello, la figura 7.4 muestra los DNS (Forwarders) que resuelven las
peticiones de registros que no pertenecen a la red, además de que registra una
primera búsqueda al servidor del otro núcleo:
93
Figura 7.4 DNS Forwarders
Para finalizar, la evidencia concluyente de que todo el proyecto ha sido ejecutado
con éxito y la correcta normalidad de este, es la muestra de los FSMO (Flexible
Single Master Operations) del dominio.
En la figura 7.5 se aprecia cómo se muestra correctamente cada uno de los roles
al aplicar el comando: “netdom query fsmo” en un intérprete de comandos del
servidor principal del dominio corporativo. Cada uno de los Roles Maestros indica
seguidamente el servidor que corresponde, en este caso se refleja la salida del
dato como “servidor.dominio.local”.
94
Figura 7.5 Maestro Esquema Definido para la Nueva Estructura de Red
Nuevamente, el nombre del servidor principal y el dominio han sido borrados
intencionalmente para no comprometer información sensible de la compañía.
Mayor información sobre los roles FSMO y como se desarrolló dentro de este
proyecto, se analizarán en el Capítulo VIII, bajo el subtitulo 8.2 Inconvenientes
Registrados.
8. CAPÍTULO VIII: ANÁLISIS DE RESULTADOS
8.1 RESULTADOS DE PRUEBAS INICIALES
Como este proyecto trata de aplicación de ingeniería y como se pueden mejorar
procesos ya establecidos, las pruebas realizadas están directamente ligadas al
mismo ambiente de producción, lo que limita la cantidad de pruebas, posibilidades
y configuraciones posibles.
95
Referentes a las pruebas realizadas y configuraciones anteriores a la migración
listadas en el Capítulo VII, todas resultaron ser un buen referente y con índices
satisfactorios. Si bien no fue posible tener un ciclo de pruebas específicas previas
al desarrollo del proyecto, todas las labores necesarias y sus mediciones fueron
realizadas con antelación a la migración, de tal forma de buscar nuevas
alternativas en caso de que estas no hubiesen tenido éxito. Sin embargo, el caso
anterior fue exitoso en cuanto en su predicción.
Si bien no era necesario implementar nada nuevo en términos de equipamiento de
redes, si era importante realizar esta reingeniería y mejorar la infraestructura con
el mismo equipamiento presente en la compañía, según lo indicado en el
requerimiento inicial descrito por gerencia.
Para el análisis de los datos anteriormente señalados en las tablas 7.1 y 7.2
respectivamente, se presenta la figura 8.1 con la gráfica de los resultados. En ella
se aprecia que en Seattle y Santiago se obtienen resultados promedio en 200[ms]
de latencia en color azul y celeste respectivamente, mientras que un índice de
comparación muy superior con los resultados de las pruebas obtenidas
anteriormente con el datacenter, representado en color naranjo. El análisis de
tiempos y velocidades indica que el promedio de las pruebas al datacenter eran de
369[ms], mientras que para la nueva estructura es de un promedio de 180[ms]. Es
decir, hablamos de una reducción de tiempo aproximado de 51%.
96
Figura 8.1 Gráfico de los datos obtenidos
En cuanto al proceso migratorio de plataforma de correo electrónico, resultó
exitoso, tal como lo informó el proveedor de servicios previo al acuerdo
contractual. Esto se evidencia en la figura 8.2, con el registro de la actividad de los
usuarios en la nueva plataforma. Los registros MX actualizaron en un plazo de 8
horas en total, la evidencia de este proceso se muestra en el Capítulo III, figura
3.8. En las primeras 4 horas tuvimos un error de digitación, por lo que tuvimos que
actualizar y volver a generar los registros.
Figura 8.2 Registro de Actividad de los usuarios
97
8.2 INCONVENIENTES REGISTRADOS
No se esperaba tener que promover uno de los servidores como servidor principal
del dominio.
Lo anterior es debido a que Microsoft cambió la estructura desde la anterior
plataforma NT con sus PDC y BDC (Primary and Backup Domain Controller)
cuando insertó en el mercado la línea de servidores 2003, no se menciona en la
documentación oficial [9] los FSMO (Flexible Single Master Operations).
En un proceso posterior a la migración fue necesario realizar el upgrade de uno de
los servidores del dominio, dando así la categoría de primer servidor de la red a
esta máquina. Con este paso realizado, es posible seguir agregando
funcionalidades la red actual, entre ellas el agregar nuevos servidores de dominio.
Es importante mencionar en esta memoria de este proyecto, proyecto sólo por
desconocimiento no fue posible planificar este ítem con anterioridad, sufriendo
pérdidas de tiempo importantes en futuras implementaciones.
La evidencia del traspaso de los Roles al Nuevo Servidor Primario localizado en
Santiago se entrega en el Capítulo VII, Figura 7.6.
Los Roles mencionados son:
Maestro Esquema.
Maestro Dominio.
PDC.
Administrador de Grupos RID.
Maestro infraestructura.
98
9. CAPÍTULO IX: ASPECTOS ECONOMICOS Y RENTABILIDAD DEL
PROYECTO
9.1 CARTA GANTT
Este documento de análisis de tiempos y tareas fue elaborado en base a la
reunión con el nuevo directorio, quienes conversaron directamente con el área TI
para definir la problemática y solicitar así una solución concreta en un plazo
determinado. Esta reunión no sólo trató de soluciones, plazos y acuerdos, sino
además se designó cual sería la estructura del departamento a futuro y su
respectivo líder.
La siguiente figura 9.1, muestra una vista completa de la proyección de las tareas
propuestas en la Carta Gantt, además de los respectivos links entre diferentes
asignaciones consecutivas:
Figura 9.1 Vista Global de Carta Gantt
99
Si bien se entregará y detallará apropiadamente las tareas y sus respectivas
notas, el diagrama de la figura 9.1 muestra en su lado derecho todas las
actividades de forma gráfica, entregando una percepción más tangible del
proyecto. Se puede apreciar además una línea de color negro en cada una de las
barras, la que representa el porcentaje de finalización de las tareas relacionadas,
mientras que la línea roja al final del proyecto, representa la fecha límite máxima
sin posibilidad de cambio, lo anterior debido a la existencia de una relación
contractual.
A continuación y para una mejor visualización, se presentan sólo las tareas del
proyecto en la figura 9.2, junto al tiempo de duración, fecha de inicio y fecha de
término respectivamente:
Figura 9.2 Tareas Asignadas en Carta Gantt
100
El inicio del proyecto se registra como fecha 5 de Abril de 2010, en una reunión
confidencial. Esta fecha coincide con las primeras negociaciones por parte del
nuevo directorio, siendo la principal preocupación de ellos el separar
completamente las empresas vinculadas no sólo financieramente, sino que
también a nivel de Tecnologías de Información y Telecomunicaciones.
Un detalle no menor es la existencia de otras empresas que son parte del Grupo
LCL. Sin embargo, la construcción de esta memoria ha sido en base al desarrollo
tecnológico de la principal de estas compañías.
Es importante destacar que el área informática está compuesta por un equipo de
dos personas para desarrollo de aplicaciones corporativas y una persona dedicada
al área de Redes y Comunicaciones. Así, el organigrama del área TIC se compone
acorde a la representación gráfica de la siguiente figura 9.3:
Figura 9.3 Organigrama Área Informática LCL Chile
Las tareas representadas en la figura 9.2, están agrupadas bajo diferentes ítems.
A continuación se mencionarán en la tabla 9.1, el detalle de cada tarea, notas e
información adicional no presentada anteriormente.
101
Departamento de Desarrollo
Patricio FernándezDeveloper
Eduardo AcuñaSenior
Developer & Architect
Cristian JaraIT Manager
Departamento de Redes y Telecomunicaciones
ID Nombre de Tarea Especificación1 Inicio del Proyecto Primer Hito, Gerencia plantea problema y precisa solución
2Investigación de Proveedores de Datacenter En mercado Nacional e Internacional
3 Definir Nuevo Esquema de Trabajo Búsqueda de nuevas soluciones, luego reportar a gerencia4 Crear RFP Documento de requerimientos específicos a proveedores5 Analizar Nuevo Nucleo - CL, BR o US Análisis de nueva reestructuración de la red (topología)6 Enviar C. Gantt a Posibles Proveedores Confirmación formal de fechas límites a proveedores7 Definición de Fechas Finales Confirmación de gerencia a tarea 6.8 Enviar RFP - Solicitar propuestas Documento revisado y aprobado para su envio9 Pruebas de la nueva tecnología Pruebas de plataforma en servidores de prueba
10 Exchange IMAP, POP3 Linux, Google Apps Tecnologías a Investigar11 Recepción de propuestas Paso posterior a tarea 8.12 Definición Nuevo Proveedor Revisar propuesta y definir nuevo proveedor con gerencia13 Enviar información al Depto. Desarrollo Basado en definición anterior, informar para ciclo de test14 Términos de Contrato
Negociación de costos con el proveedor15 Definición de Términos16 Negociación de Costos
17 Periodo de PruebasRealizar pruebas en la nueva plataforma y preparación previa
18 Administración de la Red Incluye Soporte a usuarios sin personal 7x24 del Datacenter.19 Aplicaciones Corporativas (BOSS + CMS)
20 Infraestructura Nuevo Datacenter LCL Establecer Nueva Topología
21Proceso Migración Esquema Active Directory Traspasar roles de Servidores
22 Finalizar Proceso Técnico/Administrativo Coordinación de actividades finales en Datacenter
23Cambio DNS MX. Direccionar a Google Apps Coordinar con Datacenter y Google Apps Nuevos Registros
24 Comienzo con el Nuevo Proveedor Hito Final del Proyecto
Tabla 9.1 Detalle de tareas del proyecto
9.2 DIAGRAMA DE RED DEL PROYECTO
El método de Roy en muestra una visión diferente y lógica para visualizar el
correcto desarrollo del proyecto, permitiendo evaluar gráficamente cada uno de las
tareas y sus respectivas conexiones. Además, evidencia las tareas que no
requieren predecesoras, por lo que puede ayudar a mejorar los tiempos de
ejecución con un respectivo análisis de costos asociados. Este proyecto en
particular es bastante crítico, por lo que es muy difícil de adelantar tareas. La
siguiente figura 9.4 muestra el método aplicado:
102
Figura 9.4 Método de Roy aplicado a las tareas del Proyecto
El análisis muestra que la tarea 10 puede ser adelantada sin contratiempos debido
a que no posee tareas predecesoras. Si bien se trata de una investigación de
mercado, es vital para conocer las tecnologías presentes al momento de recibir
propuestas por parte de los posibles nuevos proveedores de servicio.
De esta manera tenemos 2 documentos asociados a este proyecto que permiten
ver y analizar cómo será desarrollado el proyecto en base a sus tareas. Si bien la
Carta Gantt muestra el desarrollo de las tareas y como estas se relacionan en
base a una línea de tiempo, el Diagrama de Roy nos permite analizar gráficamente
las tareas que son posibles adelantar y cuáles serían los costos asociados.
Además, tiene una representación gráfica muy clara del mapa de la ruta crítica.
En este caso, todas las tareas del proyecto son por completo es críticas.
103
4
3030
20
03
2020
7
3630
5
7330
8
4141
10
11
4242
12
5757
13
6868
15
7373
16
8383
166
166
21
136136
24
165165
23
164164
22
159159
18
7373
19
8383
20
9393
176
9.3 FLUJO NETO DE FONDOS Y ANÁLISIS DE RENTABILIDAD
Para tener una expectativa del desarrollo económico del proyecto, es necesario
revisar sus Flujos Netos de Fondo. Así, podremos tener un análisis acabado de
cómo se invertirán los dineros en un transcurso de tiempo aplicado a 4 años.
Como en este caso en particular se debe pagar todo en dólares americanos
debido a que nuestros proveedores son extranjeros, la construcción de la tabla
que se mostrará a continuación estará avaluada en ésta moneda extranjera.
El proyecto comenzó a finales de 2010, siendo el primer día de funcionamiento el
1 de enero del año 2011. Por lo tanto, el análisis del flujo mostrará como todos
estos valores han cambiado hasta este año en particular.
La siguiente tabla 9.2 corresponderá al análisis del flujo neto de fondos, además
de VAN (Valor Actual Neto) y TIR (Tasa Interna de Retorno) asociados.
Flujo Económico LCL [USD]
Items / Periodo en Años 2010 2011 2012 2013 2014
Ingresos
Ahorros 77.000 77.000 77.000 77.000
Total Ingresos 77.000 77.000 77.000 77.000
Egresos
Costo mantención o soporte 1.000 1.000 1.000 1.000
Costo de operación 30.000 30.000 30.000 30.000
Total Egresos 31.000 31.000 31.000 31.000
Resultado antes de impuesto 46.000 46.000 46.000 46.000
Impuesto a la renta 1ra Cat. (20%) 9.200 9.200 9.200 9.200
Resultado después de impuesto 36.800 36.800 36.800 36.800
Inversión inicial -26.000
Flujo neto de fondos -26.000 36.800 36.800 36.800 36.800
VAN 90.651
TIR 137%Tabla 9.2 Flujo Económico del Proyecto
Los puntos a considerar en este análisis financiero son el gasto que se realizaba
en el Datacenter anterior, alrededor de USD 84.000.- Por lo tanto, pagando USD
104
7.000.- al nuevo proveedor de correo electrónico Google Apps, se aprecia un
ahorro considerable.
El costo de “Mantención y Soporte” es un pago anual al proveedor para análisis de
tickets complejos para soporte del sistema de correos. Mientras que los costos de
operación corresponde a una aproximación estándar de sueldos de mercado para
sustentar la operación desde la compañía.
El impuesto a la renta es el correspondiente a las empresas de primera categoría,
20% según la ley Chilena.
La inversión inicial corresponde al pago anticipado del nuevo proveedor, USD
7.000.- por el sistema de correos, USD 1.000.- por concepto de soporte y un valor
promedio aproximado de las remuneraciones de una persona que trabaja en este
proyecto por un periodo de 6 meses (USD 15.000.-). Además, se considera un
viaje a Estados Unidos por USD 3.000.-
9.4 ANÁLISIS DE RENTABILIDAD
Según el análisis visto en la tabla 9.2, tenemos un Valor Actualizado Neto Mayor y
muy superior a 0, indicado en dólares americanos que ronda los USD 100.000.-
Con esta información, sabemos de inmediato que el proyecto será viable
económicamente, superior a la ganancia ya exigida del 10%.
Si bien no existe una exigencia sobre la Tasa Interna de Retorno, su valor de
137% es superior a la tasa de interés del 10% exigida. Por lo tanto y en
conclusión, el proyecto es totalmente viable y atractivo en términos financieros.
105
10.CAPÍTULO X: CONCLUSIONES
El desarrollo de un proyecto es una estructura compleja que debe ser estudiada y
analizada en profundidad, independiente del tamaño de éste. Cada una de las
tareas asignadas a su realización, compone hitos que crearán reacciones en
cadena independiente si su ejecución es efectiva o no, afectando incluso la
valorización de éste.
En el ámbito técnico es imprescindible trabajar en base a las mejores prácticas.
Una estandarización adecuada permite eliminar contratiempos no deseados y
maximizar la efectividad de una buena planeación. En este caso, el trabajar bajo la
arquitectura de J-SOX estableció parámetros generales aplicables a otros
ambientes, pudiendo ser replicados normas y estándares mundiales de calidad
comprobada.
La seguridad de los datos en cualquier sistema compromete recursos de sistema y
efectividad en la entrega de los datos al usuario final. En el caso particular de las
VPN’s utilizadas, estas utilizan un algoritmo de criptográfico fuerte que utiliza
bastantes recursos del equipo. Quizás bajo otro escenario, la modificación de éste
hubiese sido inminente.
Es posible realizar ingeniería sobre los recursos ya existentes en una organización
y aplicar mejoras. Incluso bajo el nuevo escenario, es posible realizar mejoras de
rendimiento sobre los equipos de comunicaciones y utilización de recursos en
servidores.
Fuera del plano técnico, es muy necesario contar con habilidades blandas para el
correcto manejo de proveedores. Adicionalmente, el ejercer comunicación eficaz
permite una fluidez de información con los superiores. Y por último el dominar otro
106
lenguaje facilita el trabajo con Ingenieros de otros lugares del mundo, abriendo
posibilidades a nuevas tecnologías y servicios.
107
Cada empresa es diferente y por lo tanto la aplicación de las TIC debe ser
diferente. En este caso, se ha escogido avanzar a una estandarización
descentralizada manteniendo los principales sistemas en ambientes totalmente
diferentes. Una compañía como unidad de negocio siempre será compleja, por lo
tanto, es imperativo que las TIC sean parte de la operación cuando no se trata de
una empresa informática. El ser transversal en TI es lo que está diferenciando a
las empresas de hoy.
Si bien se ha optado por una estrategia de descentralización, la seguridad de los
datos se sigue manteniendo mediante medidas de concientización,
configuraciones de seguridad directamente aplicadas al usuario final y cuando es
posible, aplicando la seguridad directamente desde el servidor.
La solidez de aplicar re-ingeniería a un producto o servicio, radica en la
concepción de mejorar los procesos previamente establecidos. La concepción
fundamental de y la visión integral de la globalidad del negocio, entendiéndolo
como un todo, hará que sea posible este tipo cambios adaptadas a las nuevas
realidades.
Una administración ordenada permite control específico sobre materias de gestión.
Esto no sólo aplicas a labores técnicas de ingeniería, también compete a labores
de administración como contratos TI, renovaciones de licencias, compra de
insumos, etc.
Si bien el estudio de las TIC aparece como una tecnología reciente en
comparación a otras carreras, es de vital importancia entender que su estudio no
sólo se limita a los contenidos contemplados por la universidad, también es
necesario consultar otro tipo de contenidos como estandarizaciones
internacionales, certificaciones especializadas, mejores prácticas sobre las
tecnologías utilizadas en nuestra compañía, etc.
108
11.CAPÍTULO XI: REFERENCIAS BIBLIOGRAFICAS
[1] Hubbert Zimmermann, “OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection”, IEEE Transactions on Communications, Volumen Com-28, Número 4, Abril 1980, pp. 425-432
[2] Yadong Li, Wenqiang Cui, Danlan Li, Rui Zhang, “Research based on OSI Model”, IEEE, Publicación 978-1-61284-486-2, 2011, pp. 554-557
[3] Douglas Meyer, George Zobrist, “TCP/IP Versus OSI, The Battle of the Network Standards”, IEEE Potentials, 0278-6648/90/0002-0016, Febrero 1990, pp. 16-19
[4] Paul V. Mockapetris, Kevin J. Dunlap, “Development of the Domain Name System”, Investigación por Defense Advanced Research Projects Agency bajo contrato MDA903-87-C-0719, pp. 123-133
[5] Andrew S. Tanenbaum, “Sistemas Operativos Modernos”, Tercera Edición, México 2009, Pearson Educación. ISBN: 978-607-442-046-3
[6] Jeffrey R. Shapiro, JimBoyce, “Windows Server 2003 Bible R2 and SP1 Edition”, 2006, Wiley Publishing Inc. ISBN-13: 978-0-471-75480-0
[7] Ralph Droms, Ph.D. Ted Lemon, “The DHCP Handbook”, Segunda Edición, USA 2003, Sams Publishing, ISBN: 0-672-32327-3
[8] Project Management Institute, Guía de los fundamentos para la dirección de Proyectos (Guía del PMBOK), 4ta Edición, 1 Dic. 2009, PMI.
[9] Craig Zacker, “Managing and Maintaining a Microsoft Windows Server 2003 Environment”. Enero 2004, Microsoft Official Certification, ISBN-13:9780072944877
109
12.CAPÍTULO XII: ANEXOS
12.1 PRESUPUESTO GLOBAL Y LOCAL
El siguiente documento muestra información oficinal financiera de LCL, para
explicar de mejor manera el análisis del tema en curso. Los presupuestos
mostrados a continuación reflejan la estructura de costos previo a la migración del
Datacenter y al periodo post migración.
LCL – Oficina Global
2011 2010
ItemTotal Año
[USD]Total Año
[USD]
Costo Datacenter 84.000 83.311 Contrato Cisco Smartnet 12.320 12.320 Software Corporativo 4.900 6.400 Contrato Mantención Impresoras 4.800 4.800 DNS (lclog.com) 100 100 Total 106.120 106.931
LCL Oficina Chile
2011 2010
ItemTotal Año
[USD]Total Año
[USD]Contrato Mantención Impresoras 4.800 4.800 ISP SCL 24.000 30.000 DRP/BCP 2.400 2.650 Licencias 10.000 - Mantención Equipos 1.200 1.000 Total 42.400 38.450
Tabla A.1 Resumen de Presupuesto LCL
110
Ambas tablas reflejan costos en formato anual, sin detalle mensual. El primer
presupuesto corresponde a la oficina base, aquella que controla a todas las demás
en términos financieros y operacionales. El segundo corresponde solo la oficina de
Chile, al área que vende que vende servicios y genera gestión logística.
12.2 RESUMEN DE PROPUESTAS
Las siguientes tablas muestran el resumen de costos de cada proyecto por
proveedor.
NetGlobalis
Propt. 1
Opción 24 MesesTotal
Configuración Inicial
Cuota Mensual
Valor Anual 2011
Valor Anual 2011 + Cuota
Inicial
Valor Anual 2012
USD 4.566 USD 5.944 USD 71.322 USD 75.888 USD 71.322Opción 36 Meses
Total Configuración
Inicial
Cuota Mensual
Valor Anual 2011
Valor Anual 2011 + Cuota
Inicial
Valor Anual 2012
USD 4.566 USD 5.518 USD 66.217 USD 70.783 USD 66.217
BPOS
Propt. 1
Única OpciónTotal
Configuracion Inicial
Cuota Mensual
Valor Anual 2011
Valor Anual 2011 + Cuota
Inicial
Valor Anual 2012
USD 6.801 USD 2.000 USD 24.000 USD 30.801 USD 24.000
Google Mail
Propt. 1
Única OpciónTotal
Configuracion Inicial
Cuota Mensual
Valor Anual 2011Valor Anual
2011 + Cuota Inicial
Valor Anual 2012
USD 8.018 - USD 9.505 USD 17.523 USD 9.505
111
Tabla A.2 Costos de cada solución por proveedor.
112
13.CAPÍTULO XIII: ACRÓNIMOS
A
ASDM : CISCO Adaptive Security Device Manager
_____________________________________________________________
B
Break Even : Punto Muerto o umbral de equilibrio, es un término
financiero que hace referencia al mínimo de unidades de productos o servicios que
la empresa necesita vender para no generar utilidades y no tener pérdidas.
BDC : Backup Domain Controller
F
FSMO : Flexible Single Master Operations o Maestro de
Operaciones
I
IKE : Internet Key Exchange o Intercambio de Llaves
J
J-SOX : Japan Sarbanes-Oxley, versión Japonesa de la ley
financiera en USA
P
113
PDC : Primary Domain Controller
R
RFP : Request for Proposal o Solicitud de Propuestas a
proveedores.
S
Single Sign-on : Servicio de Inicio de Sesión Único
SLA : Service Level Agreement
T
TIC : Tecnologías de la Información y Comunicaciones
U
USD : United States Dollar
114