memoria seminario

165
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

Upload: andreas-deris

Post on 05-Dec-2015

220 views

Category:

Documents


1 download

DESCRIPTION

.

TRANSCRIPT

Page 1: Memoria Seminario

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

Page 2: Memoria Seminario

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

Page 3: Memoria Seminario

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

Page 4: Memoria Seminario

Í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

Page 5: Memoria Seminario

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

Page 6: Memoria Seminario

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

Page 7: Memoria Seminario

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

Page 8: Memoria Seminario

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

Page 9: Memoria Seminario

Í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

Page 10: Memoria Seminario

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

Page 11: Memoria Seminario

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

Page 12: Memoria Seminario

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

Page 13: Memoria Seminario

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

Page 14: Memoria Seminario

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

Page 15: Memoria Seminario

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

Page 16: Memoria Seminario

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

Page 17: Memoria Seminario

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

Page 18: Memoria Seminario

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

Page 19: Memoria Seminario

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

Page 20: Memoria Seminario

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

Page 21: Memoria Seminario

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

Page 22: Memoria Seminario

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

Page 23: Memoria Seminario

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

Page 24: Memoria Seminario

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

Page 25: Memoria Seminario

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

Page 26: Memoria Seminario

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

Page 27: Memoria Seminario

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

Page 28: Memoria Seminario

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

Page 29: Memoria Seminario

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

Page 30: Memoria Seminario

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

Page 31: Memoria Seminario

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

Page 32: Memoria Seminario

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

Page 33: Memoria Seminario

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

Page 34: Memoria Seminario

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

Page 35: Memoria Seminario

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

Page 36: Memoria Seminario

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

Page 37: Memoria Seminario

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

Page 38: Memoria Seminario

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

Page 39: Memoria Seminario

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

Page 40: Memoria Seminario

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

Page 41: Memoria Seminario

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

Page 42: Memoria Seminario

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

Page 43: Memoria Seminario

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

Page 44: Memoria Seminario

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

Page 45: Memoria Seminario

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

Page 46: Memoria Seminario

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

Page 47: Memoria Seminario

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

Page 48: Memoria Seminario

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

Page 49: Memoria Seminario

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

Page 50: Memoria Seminario

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

Page 51: Memoria Seminario

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

Page 52: Memoria Seminario

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

Page 53: Memoria Seminario

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

Page 54: Memoria Seminario

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

Page 55: Memoria Seminario

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

Page 56: Memoria Seminario

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

Page 57: Memoria Seminario

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

Page 58: Memoria Seminario

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

Page 59: Memoria Seminario

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

Page 60: Memoria Seminario

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

Page 61: Memoria Seminario

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

Page 62: Memoria Seminario

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

Page 63: Memoria Seminario

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

Page 64: Memoria Seminario

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

Page 65: Memoria Seminario

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

Page 66: Memoria Seminario

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

Page 67: Memoria Seminario

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

Page 68: Memoria Seminario

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

Page 69: Memoria Seminario

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

Page 70: Memoria Seminario

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

Page 71: Memoria Seminario

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

Page 72: Memoria Seminario

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

Page 73: Memoria Seminario

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

Page 74: Memoria Seminario

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

Page 75: Memoria Seminario

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

Page 76: Memoria Seminario

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

Page 77: Memoria Seminario

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

Page 78: Memoria Seminario

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

Page 79: Memoria Seminario

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

Page 80: Memoria Seminario

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

Page 81: Memoria Seminario

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

Page 82: Memoria Seminario

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

Page 83: Memoria Seminario

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

Page 84: Memoria Seminario

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

Page 85: Memoria Seminario

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

Page 86: Memoria Seminario

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

Page 87: Memoria Seminario

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

Page 88: Memoria Seminario

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

Page 89: Memoria Seminario

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

Page 90: Memoria Seminario

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

Page 91: Memoria Seminario

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

Page 92: Memoria Seminario

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

Page 93: Memoria Seminario

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

Page 94: Memoria Seminario

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

Page 95: Memoria Seminario

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

Page 96: Memoria Seminario

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

Page 97: Memoria Seminario

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

Page 98: Memoria Seminario

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

Page 99: Memoria Seminario

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

Page 100: Memoria Seminario

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

Page 101: Memoria Seminario

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

Page 102: Memoria Seminario

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

Page 103: Memoria Seminario

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

Page 104: Memoria Seminario

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

Page 105: Memoria Seminario

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

Page 106: Memoria Seminario

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

Page 107: Memoria Seminario

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

Page 108: Memoria Seminario

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

Page 109: Memoria Seminario

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

Page 110: Memoria Seminario

lenguaje facilita el trabajo con Ingenieros de otros lugares del mundo, abriendo

posibilidades a nuevas tecnologías y servicios.

107

Page 111: Memoria Seminario

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

Page 112: Memoria Seminario

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

Page 113: Memoria Seminario

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

Page 114: Memoria Seminario

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

Page 115: Memoria Seminario

Tabla A.2 Costos de cada solución por proveedor.

112

Page 116: Memoria Seminario

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

Page 117: Memoria Seminario

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