INSTITUTO POLITÉCNICO NACIONAL

CDMX, 2017.

DIRECTOR DE TESIS:

M. C. RAFAEL SALVADOR IBÁÑEZ CASTAÑEDA

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y

CIENCIAS SOCIALES Y ADMINISTRATIVAS

SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

PROPUESTA DE UNA ARQUITECTURA DE SEGURIDAD

BASADA EN OPENSTACK COMO PLATAFORMA DE

INFRAESTRUCTURA

TESIS

QUE PARA OBTENER EL GRADO DE

MAESTRO EN CIENCIAS DE LA INFORMÁTICA

PRESENTA:

LIC. ALEJANDRO ÁVILA ALCÁNTARA

2

3

4

Gracias……

A mi director de tesis M. C. Rafael Salvador Ibáñez Castañeda, por ser la guía

para terminar este trabajo.

A Omar Ceja por acompañarme en todo este camino.

A mis familiares y amigos que me han motivado todo este tiempo.

A UPIICSA y al Instituto Politécnico Nacional.

5

ÍNDICE

RESUMEN 11

ABSTRACT 14

MARCO METODOLÓGICO 16

PROBLEMÁTICA 16

JUSTIFICACIÓN 16

OBJETIVO GENERAL 16

OBJETIVOS ESPECÍFICOS 17

ALCANCE 17

CAPÍTULO 1 LA ARQUITECTURA GENERAL DE UN SISTEMA DISTRIBUIDO 18

1.1 QUE SON LOS SISTEMAS DISTRIBUIDOS 18

1.2 DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS 20

1.3 ¿QUÉ ES UN SERVICIO? 23

1.4 ¿QUÉ ES UNA OPERACIÓN? 23

1.5 ¿QUÉ ES SOA? 23

1.6 GOBIERNO DE SERVICIOS 25

1.7 ¿QUÉ ES UN ARQUITECTO? 26

CIERRE CAPÍTULO 1 26

CAPÍTULO 2 DEL PARADIGMA TRADICIONAL AL CLOUD COMPUTING 27

2.1 INTRODUCCIÓN AL CLOUD COMPUTING 27

2.2 DEFINICIÓN DE CLOUD COMPUTING 27

2.3 ¿CÓMO FUNCIONA EL CLOUD COMPUTING? 28

2.4 ARQUITECTURA GENERAL DEL CLOUD COMPUTING 29

2.5 CARACTERÍSTICAS CENTRALES DEL CLOUD COMPUTING 30

2.6 MULTITENANT (MULTITENENCIA) 30

2.7 TIPOS DE CLOUD 31

2.7.1 CLOUD PÚBLICA 31

2.7.2 CLOUD PRIVADA 32

6

2.7.3 CLOUDS HÍBRIDAS 33

2.8 MODELOS DE SERVICIO CLOUD (SAAS, PAAS E IAAS) 34

2.8.1 SAAS (SOFTWARE AS A SERVICE) 34

2.8.1.1 VENTAJAS Y DESVENTAJAS 35

2.8.2 PAAS (PLATFORM AS A SERVICE) 36

2.8.2.1 VENTAJAS Y DESVENTAJAS 37

2.8.3 IAAS (INFRAESTRUCTURE AS A SERVICE) 38

2.8.3.1 VENTAJAS Y DESVENTAJAS 39

2.9 SEGURIDAD EN LA NUBE 40

2.10 SECAAS 42

2.11 INTRODUCCIÓN A OPENSTACK 46

2.11.1 ¿QUÉ ES OPENSTACK? 46

2.11.2 DISEÑO DE OPENSTACK 47

2.11.3 COMPONENTES DE OPENSTACK 47

2.11.3.1 COMPUTE (NOVA) 47

2.11.3.2 OBJECT STORE (SWIFT) 47

2.11.3.3 BLOCK STORAGE (CINDER) 48

2.11.3.4 NETWORKING (NEUTRON) 48

2.11.3.5 DASHBOARD (HORIZON) 48

2.11.3.6 IDENTITY (KEYSTONE) 49

2.11.3.7 IMAGE SERVICE (GLANCE) 49

2.11.4 ARQUITECTURA CONCEPTUAL DE OPENSTACK 50

CIERRE CAPÍTULO 2 51

CAPÍTULO 3 ANÁLISIS DE CUMPLIMIENTO SECAAS 52

3.1 SERVICIOS DE CUMPLIMIENTO DE SECAAS 52

3.2 SERVIDOR PROXY INVERSO (REVERSE PROXY) 52

3.2.1 EJEMPLOS DE PROXY INVERSO MÁS USADOS 54

3.3 LDAP 54

3.3.1 ESTRUCTURA DE ÁRBOL DE LA INFORMACIÓN (DIT) 56

3.3.2 ENTRY (ENTRADA) 57

3.3.3 EJEMPLOS DE LDAP MÁS USADOS 57

7

3.4 FIREWALL 58

3.4.1 TIPOS DE FIREWALL 58

3.4.1.1 FIREWALL PROXY 58

3.4.1.2 FIREWALL DE INSPECCIÓN ACTIVA 58

3.4.1.3 FIREWALL DE ADMINISTRACIÓN UNIFICADA DE AMENAZAS (UTM) 59

3.4.1.4 FIREWALL DE SIGUIENTE GENERACIÓN (NGFW) 59

3.4.1.5 FIREWALL DE SIGUIENTE GENERACIÓN (NGFW) CENTRADO EN AMENAZAS 59

3.4.2 EJEMPLOS DE FIREWALLS MÁS USADOS 61

3.5 IPS 61

3.5.1 CLASIFICACIONES 61

3.5.2 MÉTODOS DE DETECCIÓN 62

3.5.2.1 DETECCIÓN BASADA EN FIRMAS 62

3.5.2.2 DETECCIÓN BASADA EN POLÍTICAS 62

3.5.2.3 DETECCIÓN BASADA EN ANOMALÍAS 62

3.5.3 EJEMPLOS DE IPS MAS USADOS 63

3.6.1 EJEMPLOS DE IDS MAS USADOS 65

3.7 ESCANEO DE VULNERABILIDADES 65

3.7.1 VULNERABILIDAD 65

3.7.2 TIPOS DE ESCÁNERS 65

3.7.3 TIPOS DE ESCANEOS 66

3.7.4 EJEMPLOS DE SISTEMAS DE ESCANEO DE VULNERABILIDADES MAS USADOS 67

3.8 ELECCIÓN DE SOLUCIONES DE SEGURIDAD PARA LA PROPUESTA DE SOLUCIÓN 67

3.8.1 NGINX 67

3.8.2 OPENLDAP 68

3.8.3 SURICATA 69

3.8.4 OPNSENSE 70

3.8.5 OPENVAS 72

3.9 ARQUITECTURA DE SEGURIDAD 73

3.9.1 LA IMPORTANCIA DE CONTAR CON UNA ARQUITECTURA DE SEGURIDAD 74

CIERRE CAPÍTULO 3 77

8

CAPÍTULO 4 PROPUESTA DE ARQUITECTURA DE SEGURIDAD PARA UNA

ORGANIZACIÓN 78

4.1 ARQUITECTURA DE LAS APLICACIONES 78

4.2 MODELO DE SEGURIDAD EN CAPAS 79

4.3 CICLO DE VIDA DE UN SERVICIO 82

4.4 DISEÑO DE SERVICIOS 84

4.5 CONSTRUCCIÓN DE SERVICIOS 85

4.6 CONSUMO DE SERVICIOS 86

4.7 EVOLUCIÓN DE UN SERVICIO 86

4.8 ROBUSTECIENDO EL MODELO DE ARQUITECTURA DE SERVICIOS 87

4.9 OPENSTACK COMO CAPA BASE DE INFRAESTRUCTURA 88

4.10 DESCRIPCIÓN DE LA PROPUESTA DE ARQUITECTURA DE SEGURIDAD DE LA

INFRAESTRUCTURA 91

4.10.1 CAPA DE AUTENTICACIÓN 92

4.10.2 SEGMENTACIÓN DE RED 93

4.10.2.1 RESPONSABILIDADES GENERALES DEL ADMINISTRADOR DE SEGURIDAD 94

4.10.2.2 RESPONSABILIDADES GENERALES DEL USUARIO FINAL 95

4.10.2.3 SEGREGACIÓN DE REDES EN LA ORGANIZACIÓN 95

4.10.2.3.1 RESPONSABILIDADES DEL ADMINISTRADOR DE SEGURIDAD 96

4.10.2.4 SOLICITUD DE CONEXIONES EN INTERNET CON LA ORGANIZACIÓN 97

4.10.2.4.1 RESPONSABILIDADES DEL ADMINISTRADOR DE SEGURIDAD 97

4.10.2.4.2 RESPONSABILIDADES DEL USUARIO FINAL 98

4.10.2.4.3 RESTRICCIONES 98

4.10.3 DETECTANDO Y PREVINIENDO (IPS/IDS) 99

4.10.4 USO DE PROTOCOLOS SEGUROS Y BLOQUEO DE SERVICIOS PROHIBIDOS. 101

4.10.5 ADMINISTRACIÓN DE LOGS 102

4.10.6 ANÁLISIS PERIÓDICO DE VULNERABILIDADES 103

4.10.7 APLICACIÓN DE ACTUALIZACIONES Y REMEDIACIÓN DE VULNERABILIDADES 104

4.10.8 DEFINIR UN ÁREA DE MONITOREO 105

4.10.9 IMPLEMENTAR UN SISTEMA DE GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN

(SGSI) 105

9

CONCLUSIÓN 111

TRABAJOS FUTUROS 113

BIBLIOGRAFÍA 115

ANEXO I INSTALACIÓN BÁSICA DE OPENSTACK EN FEDORA 118

ANEXO II INSTALACIÓN DE NGINX EN UBUNTU 127

ANEXO III INSTALACIÓN DE OPENLDAP EN UBUNTU 130

10

Asesor Propuesto:

M. C. Rafael Salvador Ibáñez Castañeda

Título

Propuesta de una arquitectura de seguridad basada en Openstack como

plataforma de infraestructura

11

RESUMEN

El presente trabajo fue elaborado mediante la investigación en diferentes medios electrónicos con

el fin de recabar el material necesario para sustentar la propuesta de solución aquí planteada.

El primer enfoque de este trabajo es entender el funcionamiento de una aplicación web en un

esquema tradicional y como se pueden lograr beneficios al portar esto al esquema basado

arquitectura de servicios para de este modo hacer una reingeniería del enfoque de desarrollo de

aplicaciones de una organización.

El segundo enfoque es entender el “nuevo” paradigma del cloud computing y cuáles son las

ventajas que se obtienen al migrar a dicho esquema en un entorno de cloud privada.

EL hecho de migrar a la parte cloud no implica que estemos protegidos de amenazas razón por la

cual abordamos los distintos controles de seguridad que deben de ser implementados en este

entorno posteriormente realizar un análisis de cuales podemos cumplir y los elementos necesarios

para dar dicho cumplimiento.

Es este punto ya tenemos un entorno de infraestructura (Hardware) y un entorno de aplicación

(Software), pero falta definir una arquitectura de seguridad que involucre a ambos componentes y

que sea el modelo que sustente nuestra plataforma, dicho modelo es la propuesta de solución que

se presenta y que es la razón de ser de este documento.

Al establecer una arquitectura nos preocupamos no solo por la parte tecnológica, también incluye

los procesos que se deben de implementar dentro de la organización para que el modelo sea

soportado.

La propuesta de solución busca ser una referencia general para cualquier organización que quiera

implementarla, que sea fácilmente adaptable gracias al uso de software libre y sobre todo sencillo

de entender. No Pretende ser un documento detallado de una implementación.

Los constantes cambios tecnológicos nos llevan a evolucionar más rápido en todos los sentidos,

hoy día las empresas no van acorde a esa dinámica, ya sea porque las aplicaciones que tienen

funcionan de manera adecuada o porque no están dispuestos a gastar en renovación de

infraestructura.

Hoy día las soluciones que se brindan en cloud son una buena alternativa a un costo accesible,

pero es difícil dar el salto a dichas plataformas debido a los paradigmas actuales, a muchas

empresas les es difícil el no saberse dueños de la infraestructura donde se ejecutan sus

aplicaciones o donde reside su información.

12

Para dar solución a esto se puede usar un modelo de cloud privada en donde se pueden tener

todos los beneficios del cloud computing (Elasticidad, escalabilidad, redundancia, etc.) mediante la

implementación de Openstack como plataforma IaaS. Pero el tener el poder de cómputo no es

suficiente, es necesario generar una arquitectura que pueda explotar de manera adecuada todas

las capacidades, razón por la cual se propone para el entorno de la aplicación pasar a un modelo

basado en servicios y en la capa de infraestructura usar software libre.

De nada sirve tener infraestructura robusta si es vulnerable, en esta tesis se define un modelo de

pueden implementar controles de seguridad tanto por software como por procesos que permitan

tener el entorno de la aplicación y la infraestructura seguros.

En el capítulo 1 se aborda el cómo es el entorno tradicional de una aplicación web en la que el

cliente usa un navegador para consumir directamente de un servidor web, lo que implica que en

este resida toda la lógica de negocio, se explora el cambio de paradigma al pasar a la arquitectura

de servicios en la que la lógica de negocio ya no tiene por qué residir en cada una de las

aplicaciones y esta capa se puede extraer.

En el capítulo 2 se explicarán los conceptos base para entender el cloud computing, los tipos de

clouds que se tienen en cuanto a su implementación y el modelo de servicio que estas pueden

ofrecer, adicional a esta descripción se aborda el tema de seguridad y los puntos que se deben de

considerar para tener un entorno seguro en cualquier tipo de cloud, al final se aborda Opensatck

como plataforma para poder generar la infraestructura necesaria para que sea usada por nuestras

aplicaciones, de describe su funcionamiento y sus principales módulos.

En el capítulo 3 se realiza el análisis de qué objetivos de seguridad para el entorno cloud podemos

cubrir y se realiza la descripción de los componentes que se estarán considerando, después de

esto se realiza la elección de componentes de que se proponen para la arquitectura de seguridad

basados en sus funcionalidades y en que sean software libre.

En el capítulo 4 se describe la propuesta de solución en la que primero se define en modelo de

gobierno para el desarrollo de servicios dentro de la organización, para de este modo tener el

control de que es lo que se desarrolla y el ciclo de vida que debe de tener un servicio, la siguiente

parte se centra en implementar un modelo de seguridad en la infraestructura que va a soportar la

arquitectura de servicios, desde implementar una capa de autenticación que “elimine esta

preocupación” de los desarrolladores, realizar una adecuada segmentación de red indicando

cuales son las responsabilidades del administrador y las del usuario adicional al uso de una

herramienta de monitoreo de intrusiones para mantener la seguridad, después de estos controles

es preciso considerar procesos para el mantenimiento de la seguridad, desde definir un área de

monitoreo, realizar una revisión periódica de las vulnerabilidades de la infraestructura y considerar

13

la remediación de las mismas, estos se pueden indicar en un Sistema de Gestión de la Seguridad

de la Información del cual se hace una breve descripción.

14

ABSTRACT

The present document was elaborated after researching in different electronic means in order to

gather the necessary material to support the solution proposed here.

The first approach of this work is to understand the operation of a web application in a traditional

scheme and how benefits can be achieved by porting this to the service architecture based schema

in order to reengineer the application development approach of an organization.

The second approach is to understand the "new" paradigm of cloud computing and what are the

advantages gained by migrating to that scheme in a private cloud environment.

Migrating to the cloud does not imply that we are protected from threats, which is why we approach

the different security controls that must be implemented in this environment, carrying out an

analysis of what can we accomplish and the elements necessary to give such compliance.

It is this point already we have an infrastructure environment (Hardware) and an application

environment (Software), but it is necessary to define a security architecture that involves both

components and that is the model that supports our platform, that model is the solution proposal

presented here and raison d'être of this document.

When establishing architecture, we are concerned not only with the technological part, but also with

the processes that must be implemented within the organization in order for the model to be

supported.

The solution proposal seeks to be a general reference for any organization that wants to implement

it, that is easily adaptable thanks to the use of free software and above all simple to understand. It

is not intended to be a detailed document of an implementation.

The constant technological changes lead us to evolve faster in all senses, today companies do not

act according to that dynamics, either because the applications they have work properly or because

they are not willing to spend on infrastructure renovation.

Today the solutions offered in the cloud are a good alternative at an affordable cost, but it is difficult

to make the leap to these platforms due to the current paradigms, many companies find difficult

coming to terms with knowing they are not the owners of the infrastructure in which they run their

Applications or where their information resides.

To solve this, you can use a private cloud model where you can have all the benefits of cloud

computing (Elasticity, scalability, redundancy, etc.) by implementing Openstack as IaaS platform.

15

However, having the power of computation is not sufficient, it is necessary to generate an

architecture that can adequately exploit all the capacities, which is why it is proposed for the

application environment to move to a service-based model and the layer of Infrastructure to use

free software.

It is of no use to have robust infrastructure if it is vulnerable, in this thesis a model is defined that

can implement security controls both by software and processes that allow the application

environment and infrastructure to be secure.

Chapter 1 addresses how the traditional environment of a web application in which the client uses a

browser to consume directly from a web server, which implies that the whole business logic resides

within it, it explores the change of paradigm when moving to the services architecture in which

business logic no longer has to reside in each of the applications and this layer can be extracted.

Chapter 2 will explain the basic concepts to understand cloud computing, the types of clouds you

have in terms of its implementation and the service model that these can offer, in addition to this

description, the issue of security and points that must be considered to have a secure environment

in any type of cloud. In the end, Opensatck is addressed as a platform to be able to generate the

infrastructure necessary for it to be used by our applications, describing its operation and main

modules.

In chapter 3 we perform the analysis of which security objectives for the cloud environment we can

cover and the description of the components that are being considered is performed, after this the

components for the security architecture are chosen, based on their functionality and these being

free software.

Chapter 4 describes the solution proposal in which it is first defined the governance model for the

development of services within the organization, in order to have control of what is developed and

the life cycle that a service must have, the next part focuses on implementing a security model in

the infrastructure that will support the service architecture, including an authentication layer that

"eliminates this concern" from the developers, performing a proper network segmentation indicating

which are the responsibilities of the administrator and those of the user, in addition to the use of an

intrusion monitoring tool to maintain the security, after these controls it is necessary to consider

processes for the maintenance of the security, defining a pair such as defining a monitoring

department, performing periodic review of infrastructure vulnerabilities and considering their

remediation, these can be indicated in an Information Security Management System, of which a

brief description is made.

16

MARCO METODOLÓGICO

PROBLEMÁTICA

El paradigma cliente/Servidor clásico no es suficientemente robusto ya que cuando un servidor

está fuera de línea las peticiones de los clientes no pueden ser procesadas de este modo se

produce la indisponibilidad del servicio lo que conlleva al daño reputacional y a las sanciones por

incumplimiento de los niveles de servicio.

Adicionalmente el no contar con una arquitectura de seguridad genera que no se tengan con

modelos estandarizados que se puedan seguir en la implementación de la aplicación ya que de

este modo se deja la tarea de establecer los mecanismos de seguridad a la aplicación lo que

puede llevar a ampliar el tiempo de desarrollo de la misma.

JUSTIFICACIÓN

Para mitigar la desventaja del paradigma Cliente/Servidor es necesario realizar un fuerte gasto en

infraestructura que permita generar redundancia y de este modo reducir la indisponibilidad, dicha

infraestructura no implica solo el costo de adquisición ya que requiere un costo de mantenimiento y

se debe de considerar los tiempos de puesta en marcha de los equipos. Si se genera una

arquitectura estandarizada se puede acortar el tiempo de implementación.

OBJETIVO GENERAL

Establecer los mecanismos y lineamientos necesarios para la correcta implementación de una

arquitectura de seguridad en una aplicación WEB para garantizar que cumple con la

confidencialidad, integridad y disponibilidad, usando Openstack como plataforma de gestión de

infraestructura.

Al poder establecer una arquitectura se facilitará la implementación de la aplicación de banca en

línea ya que se plantea contar con una solución de autenticación independiente que a la larga

puede ser usada por otras aplicaciones.

17

OBJETIVOS ESPECÍFICOS

Con base en base a la propuesta que se desarrolle, se espera lo siguiente:

Garantizar la protección de las aplicaciones.

Cambiar el paradigma del desarrollo para pasar a la arquitectura basada en servicios.

Minimizar el riesgo de posibles intrusiones no autorizadas o compromiso de la información.

Incrementar la confianza de clientes.

Luchar contra la suplantación y otros fraudes que se producen en Internet.

Reducir los costos y tiempos de la implementación de infraestructura.

Diseñar una arquitectura de seguridad que sea estándar para cualquier aplicación WEB.

Reducir los tiempos de desarrollo de la aplicación al evitar “preocuparse” por el desarrollo

del módulo de autenticación de usuarios.

ALCANCE

El objetivo del presente documento es definir una arquitectura de seguridad para aplicaciones WEB

basadas en servicios usando Openstack como plataforma de infraestructura.

18

CAPÍTULO 1 LA ARQUITECTURA GENERAL DE UN SISTEMA DISTRIBUIDO

1.1 QUÉ SON LOS SISTEMAS DISTRIBUIDOS

Ian Sommerville en su libro Ingeniería del software describe los sistemas distribuidos y sus

características de la siguiente manera:

“Prácticamente todos los grandes sistemas informáticos son en la actualidad sistemas

distribuidos. Un sistema distribuido es un sistema en el que el procesamiento de

información se distribuye sobre varias computadoras en vez de estar confinado en una

única máquina. Existen cuestiones específicas que deben tenerse en cuenta cuando se

diseña este tipo de sistemas.1

Se identifican las siguientes ventajas del uso de un sistema distribuido para el desarrollo de

sistemas:

Recursos compartidos: Permite compartir recursos hardware y software (como

discos y archivos) que se asocian con computadoras en una red.

Apertura: Los sistemas distribuidos son normalmente sistemas abiertos, lo que

significa que se diseñan sobre protocolos estándar que permiten combinar

hardware y software de diferentes proveedores.

Concurrencia: En un sistema distribuido, varios procesos pueden operar al mismo

tiempo sobre diferentes computadoras de la red. Estos procesos comunicarse con

otros durante su funcionamiento normal.

Escalabilidad: Los sistemas distribuidos son escalables en tanto que la capacidad

del sistema puede incrementarse añadiendo nuevos recursos para cubrir nuevas

demandas sobre el sistema.

Tolerancia a fallos: La disponibilidad de varias computadoras y el potencial para

reproducir información significa que los sistemas distribuidos pueden ser tolerantes

a algunos fallos de funcionamiento del hardware y del software. En la mayoría de

los sistemas distribuidos, se puede proporcionar un servicio degradado cuando

ocurren fallos de funcionamiento; una completa pérdida de servicio sólo ocurre

1 Sommerville, Ian. 2005. Ingeniería del software. Ingeniería del software. Madrid : Pearson, 2005.

19

cuando existe un fallo de funcionamiento en la red o una caída total de toda la

infraestructura.”

La siguiente figura muestra el diagrama general de un sistema distribuido:

Aplicación

Repositorios de datos

Fig. 1 Sistemas distribuidos.

(Autoría propia)

20

1.2 DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS

Ian Sommerville en su libro Ingeniería del software describe las siguientes desventajas respecto a

los sistemas legacy:

“Complejidad: Los sistemas distribuidos son más complejos que los sistemas

centralizados. Esto hace más difícil comprender sus propiedades y probar estos

sistemas. Por ejemplo, en vez de que el rendimiento del sistema dependa de la

velocidad de ejecución de un procesador, depende del ancho de banda y de la

velocidad de los procesadores de la red.

Mover los recursos de una parte del sistema a otra puede afectar de forma radical al

rendimiento del sistema o inclusive su funcionamiento debido a dependencias de

Hardware o de componentes específicos.

Inseguridad: Debido a que se puede acceder desde distintos puntos en la red, el tráfico

puede estar sujeto a escuchas indeseadas. Esto hace más difícil el asegurar la

confidencialidad y la integridad de los datos en el sistema y que los servicios del

sistema no se degraden por ataques de denegación de servicio (Disponibilidad).

Dificultad en administración: La infraestructura que soporta un sistema pueden ser de

diferentes tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los

defectos en un componente pueden propagarse a otros equipos con consecuencias

inesperadas. Esto significa que se requiere más esfuerzo para gestionar y mantener el

funcionamiento del sistema.

Impredecibles: Los sistemas distribuidos tienen una respuesta impredecible ya que

depende de la carga total en el sistema, de la infraestructura, la organización y del

tráfico en la red. Como todos ellos pueden cambiar con mucha rapidez, el tiempo

requerido para responder a una petición de usuario puede variar drásticamente de una

petición a otra.

El reto para el diseño es, valga la redundancia, diseñar el software y hardware para

proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo,

minimizar los problemas inherentes a estos sistemas. Para hacer eso, se necesita comprender

las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Las dos

arquitecturas más comunes son las siguientes:

21

Arquitectura cliente-servidor. En esta arquitectura, el sistema puede ser visto como un

conjunto de servicio que se proporcionan a los clientes que hacen uso de dichos

servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.

Arquitecturas de objetos distribuidos. En esta arquitectura, no hay distinción entre

servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que

interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de

servicios y el usuario de estos servicios.

Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de

programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los

modelos de datos, la representación de la información y los protocolos de comunicación

pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda

gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e

intercambiar datos. El término middleware se usa para hacer referencia al software que se

sitúa en medio de los diferentes componentes distribuidos del sistema”2

Un componente necesario para el funcionamiento de los sistemas distribuidos es el middleware, el

cual Ian Sommerville define de la siguiente manera: de la siguiente manera:

“El middleware es un software de propósito general que normalmente se compra como un

componente comercial más que escribirse especialmente por los desarrolladores de la

aplicación. Ejemplos de middleware son software para gestionar comunicaciones con

bases de datos, administradores de transacciones, convertidores de datos y controladores

de comunicación.”3

Dicho de forma más simple el middleware es un intermediario que se ocupa para gestionar los

recursos necesarios para que la aplicación pueda funcionar.

Ian Sommerville describe el proceso de desarrollo de un sistema distribuido de la siguiente manera:

de la siguiente manera:

“Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación

orientada a objetos. Estos sistemas están formados por partes independientes pobremente

integradas, cada una de las cuales pueden interaccionar directamente con los usuarios o

con otras partes del sistema. Algunas partes del sistema pueden tener que responder a

2 Sommerville, Ian. 2005. Ingeniería del software. Ingeniería del software. Madrid : Pearson, 2005.

3 Sommerville, Ian. 2005. Ingeniería del software. Ingeniería del software. Madrid : Pearson, 2005.

22

eventos independientes. Los objetos software reflejan estas características; por lo tanto,

son abstracciones naturales para los componentes de sistemas distribuidos.”

Este enfoque de desarrollo se puede traducir en la generación de grandes silos aplicativos que a

pesar de llegar a tener comunicación con otros componentes no dejan de tener de manera aislada

la lógica del negocio y si dicha lógica se quiere implementar en otra aplicación esta se porta

completamente al nuevo desarrollo.

La empresa LANSA en su sitio web describe las situaciones que se pueden presentar en una

organización referente a la dificultad de la integración de aplicaciones.

“Muchas veces las empresas tienen diferentes aplicaciones de negocio desplegadas

durante el transcurso del tiempo en diferentes lenguajes, que usan diferentes tecnologías,

se despliegan en diferentes plataformas de hardware y sistemas operativos con interfaces

de usuario inconsistentes

El resultado es funcionalidad aislada, múltiples instancias de los mismos datos, actividades

manuales redundantes, costos más altos y respuestas ineficientes para sus clientes.

Además existe la necesidad creciente de integrar con sus socios de negocio y otras

compañías fuera y dentro de las fronteras de su empresa.”4

Las dificultades anteriormente planteadas son una constante en las empresas, estas situaciones

llegan a ser aprovechadas por distintos proveedores para vender soluciones de integración (como

lo es el caso de LANSA), esto representa un gasto fuerte que no tendría que realizarse con una

adecuada planeación de los desarrollos, para que estos en conjunto soporten los procesos de

negocio que reditúen en las ganancias y continuidad de operación de una organización.

4 LANSA. Integración de Aplicaciones y Procesos de Negocio. s.l. :

http://www.lansa.com/es/products/integration.htm.

23

1.3 ¿QUÉ ES UN SERVICIO?

Un servicio de puede definir como a la agrupación de una o más capacidades funcionales que de

forma individual pueden ser consumidas (utilizadas y/o invocadas) mediante el uso de los

componentes técnicos que las implementan.

El término es puramente funcional (conceptual) si bien al final termina "recayendo" en uno o más

componentes técnicos que posibilitan que las capacidades que representan se materialicen desde

un punto de vista técnico mediante el intercambio de información entre uno o más sistemas, a

pesar de ello es importante recalcar que la capacidad funcional representada es independiente y

está desligada de la implementación técnica que más tarde se adopte para darle solución.

1.4 ¿QUÉ ES UNA OPERACIÓN?

Una operación se puede definir como la capacidad funcional individual que puede ser consumida

mediante el uso de los componentes técnicos que la implementa.

Forma parte de un Servicio, es decir, cuando definimos en el punto anterior Servicio como

"agrupación de capacidades funcionales" nos referimos a "agrupación de operaciones". El término

operación a menudo se confunde con el término servicio, debido a que existen numerosos

servicios de una sola operación.

1.5 ¿QUÉ ES SOA?

SOA es un acrónimo que significa Service Oriented Architecture, o sea, arquitectura orientada a

servicios. Una arquitectura orientada a servicios es una forma de abordar los desarrollos

informáticos, intentando encapsular funcionalidades, de tal manera que sean reutilizables desde

diferentes puntos de la infraestructura informática de una organización. Con esta orientación, se

esperan obtener diferentes beneficios como la reutilización, la eliminación de redundancias, y más

ventajas desde el punto de vista técnico. Desde el punto de vista de negocio, ayuda a la expansión

de herramientas de BPM (Business Process Management), ya que la necesaria abstracción de los

procesos sobre el software que proporciona la funcionalidad de la empresa, se consigue gracias al

uso de servicios.

24

IBM indica que la arquitectura orientada a servicios (SOA) presenta varios conceptos

fundamentales que la organización debe de considerar en su proceso de transformación hacia

SOA:5

Un conjunto de servicios que la empresa desea ofrecer a sus clientes y a las áreas internas

de la organización.

Un estilo de arquitectura que requiere un proveedor de servicios, mediación (gobierno) y un

solicitante del servicio con una descripción del servicio.

Un conjunto de principios, modelos y criterios arquitectónicos que aborden características

como modularidad, encapsulación, acoplamiento abierto, separación de elementos de

interés y reutilización.

Un modelo de programación completo con estándares, herramientas y tecnologías que

admite servicios web, servicios REST y otros tipos de servicios.

Una solución de middleware optimizada para la coordinación, orquestación, supervisión y

gestión de los servicios.

La arquitectura orientada a servicios es una ventaja competitiva ya que permite lo siguiente:

Aumenta la eficiencia en los procesos.

Reducir la inversión realizada en sistemas.

Reducir costes de mantenimiento.

Fomenta la innovación orientada al desarrollo de servicios.

Simplifica el diseño, optimizando la capacidad de organización.

La arquitectura SOA se caracteriza por exponer una serie de servicios a una serie de

consumidores, los cuales pueden variar en el tiempo. La capacidad para que los servicios

expuestos puedan ser utilizados por más de un consumidor, y a su vez para que estos servicios

sean interoperables se basan, entre otros conceptos, en la utilización de un lenguaje o semántica

5IBM. Arquitectura orientada a servicios (SOA): simplemente, un buen diseño. [En línea]

https://www-01.ibm.com/software/es/solutions/soa/.

25

común. La semántica común o “Modelo Canónico” tiene por tanto como razón de ser garantizar

la interoperabilidad semántica.

La siguiente imagen representa el cambio en cómo funciona una organización cuando trabaja bajo

una arquitectura de servicios:

Repositorios de datos

Aplicación 1 Aplicación 1 Aplicación 1

Repositorios de datos

Aplicación 1 Aplicación 1 Aplicación 1

Serv Serv

Serv

Serv

Serv Serv

Serv Serv

Serv

Serv

Serv Serv

Ca

pa

de

se

rvic

ios

Arquitectura de serviciosArquitectura tradicional

Fig. 2 Funcionamiento de arquitectura de servicios.

(Autoría propia)

1.6 GOBIERNO DE SERVICIOS

Es un equipo dentro de la organización encargado de definir y establecer políticas y

procedimientos para gobernar el desarrollo, despliegue y gestión de los servicios y procesos de

negocio que se definan y desarrollen, su objetivo es asegurar:

Que los servicios desarrollados en un proyecto puedan ser consumidos por el resto de la

organización.

Que el mismo servicio, con una funcionalidad equivalente, solo se implemente una vez.

26

Que exista una manera eficaz de catalogar y localizar los servicios cuando se necesiten,

antes de crear un nuevo o cuando se vayan a reutilizar.

1.7 ¿QUÉ ES UN ARQUITECTO?

El arquitecto es la figura dentro de la organización que se encarga del diseño de alto nivel de las

soluciones (es decir, la arquitectura), ya sea un proyecto individual o los procesos de toda una

empresa. Estos diseños son la base en que la empresa lleva a cabo sus funciones (los procesos

de negocio) y en cómo los sistemas que soportan estos procesos de negocio. El trabajo del

arquitecto se logra mejor, cuando lidera el esfuerzo de diseño e involucra a todas las áreas

participantes.

En la siguiente figura se muestra la figura del arquitecto mostrada en la película “The Matrix

Reloaded”

Fig. 3 Matrix the architect

(Imagen tomada de http://thematrix101.com/reloaded/meaning.php)

En la película “The Matrix Reloaded” el arquitecto es la figura que se encarga de todo lo referente

al diseño de “la Matrix” en mismo rol juega un arquitecto dentro de una organización, ya sea desde

plantear un modelo de solución para alguna aplicación, hasta el rediseño de un proceso de

negocio.

CIERRE CAPÍTULO 1

En este capítulo repasamos el proceso de desarrollo tradicional que siguen las organizaciones y el

contraste que se tiene con el paradigma de la arquitectura de servicios, adicional se explica cómo

los servicios deben de ser “gobernados” (controlados) por una figura dedicada únicamente a esto.

27

CAPÍTULO 2 DEL PARADIGMA TRADICIONAL AL CLOUD COMPUTING

En este capítulo conoceremos de manera general los conceptos referentes al cloud computing, las

formas en que se clasifican y la modalidad de servicios que ofrecen, las consideraciones de

seguridad que se deben de tener en este tipo de entornos y la descripción de Openstack.

2.1 INTRODUCCIÓN AL CLOUD COMPUTING

Los modelos tradicionales de infraestructura de cómputo están basados en recursos físicos de

hardware (servidores, almacenamiento, telecomunicaciones, etc.) y recursos intangibles

(información de la organización, software) la infraestructura del modelo Cloud Computing está

basada en servicios. Este paradigma es totalmente diferente.

En un modelo tradicional todos los recursos interactúan y afectan la infraestructura general,

mientras la arquitectura orientada al servicio (SOA, por sus siglas en inglés) del modelo Cloud

Computing crea una separación más natural entre las dos capas principales.6

Una está formada por la tecnología dentro de la infraestructura Cloud (hardware y aplicaciones) y

la otra está formada por los recursos de información. Los servicios pueden ser configurados,

provistos o escalados internamente sin la intervención del usuario o sin que este se percate

(Orquestación). En los sistemas computacionales tradicionales, es más difícil determinar la línea

divisoria entre la infraestructura técnica y funcional del módulo computacional.

2.2 DEFINICIÓN DE CLOUD COMPUTING

En su sitio web, Salesforce define al cloud computing de la siguiente manera:

“Dicho de manera simple, el Cloud Computing aprovecha la conectividad y la mega escala

de Internet. El Cloud Computing democratiza el acceso a capacidades de software de

primer nivel, dado que una aplicación de software proporciona servicio a varios clientes. El

entorno multiusuario es una distinción arquitectónica clave que diferencia el Cloud

Computing de la simple tercerización o los antiguos modelos de proveedor de servicio de

6 itechcareer. blog.itechcareer.com. [En línea]

http://blog.itechcareer.com/index.php?option=com_content&view=article&id=39:icual-es-la-

diferencia-entre-un-modelo-tradicional-de-computacion-y-una-infraestructura-en-

nube&catid=17:tecnologia

28

aplicaciones. Ahora, las empresas pequeñas pueden sacar partido de la potencia de las

grandes tecnologías de una manera que les permita expandirse.” 7

El Cloud Computing ofrece a personas y empresas de todos los tamaños la potencia de un

conjunto de recursos informáticos bien mantenido, seguro, de fácil acceso y On Demand, como

servidores, almacenamiento y datos y software de aplicación. Además, proporciona mayor

flexibilidad con los datos y la información, a los que es posible acceder en cualquier momento y

desde cualquier lugar.

Esto es clave para empresas con oficinas en todo el mundo o en diferentes entornos laborales,

incluidas ubicaciones remotas. Y, gracias a la gestión mínima, es posible expandir todos los

elementos del software de Cloud Computing a petición (Elasticidad). Todo lo que se necesita es

una conexión a Internet.

2.3 ¿CÓMO FUNCIONA EL CLOUD COMPUTING?

Salesforce define en su sitio web el funcionamiento del cloud computing de la siguiente manera:

“Los proveedores de Cloud Computing utilizan una capa de red para conectar los

dispositivos de punto final de los usuarios (como equipos portátiles o teléfonos

inteligentes), a recursos centralizados en un su centro de datos. Antes del Cloud

Computing, las empresas que proporcionaban servicios solo podían ejecutar aplicaciones

de manera confiable si también podían pagar la factura para mantener la infraestructura de

los servidores necesarios. Por otra parte, a menudo, el software tradicional requería la

contratación o la tercerización de un equipo completo de profesionales de TI para solventar

errores o la administración y operación de los componentes. El concepto de Cloud

Computing se deshace de todos esos problemas y requisitos”

Lo anteriormente mencionado permite que todos los usuarios puedan acceder a los datos o a las

aplicaciones únicamente dependiendo de tener una conexión a internet, por lo cual se lograr tener

un mayor alcance a los usuarios y un esquema de disponibilidad sin tener que invertir en

infraestructura.

7Salesforce. Salesforce . [En línea] https://www.salesforce.com/mx/cloud-computing/.

29

2.4 ARQUITECTURA GENERAL DEL CLOUD COMPUTING

Para lograr la separación técnica y funcional, los sistemas computacionales en cloud dependen de

ciertos componentes básicos de arquitectura:

En su página web itechcareer indica que las infraestructuras de cloud computing están divididas en

las siguientes tres partes:8

La arquitectura tecnológica: es la primera capa de la plataforma en Cloud (servidores,

sistemas operativos, dispositivos de red, etc.)

La arquitectura de la aplicación: es parte de la capa funcional y está formada por todas

las aplicaciones de la empresa bajo la plataforma de Cloud Computing.

La arquitectura de la información: es la capa que permite la disponibilidad de la

información desde cualquier lugar en la nube y garantiza que la información es

consistente, confiable y segura.

La infraestructura deja de ser una dependencia para la organización ya que no es necesario

realizar ninguna inversión y solo puede consumir el poder de cómputo que requiere, en caso de ser

necesario se puede incrementar el poder de cómputo ya sea de manera permanente o temporal

(escalabilidad y elasticidad) estas características son fundamentales ya que al pagar únicamente

por lo que se está usando se permite reducir costos para las empresas.

8 itechcareer. blog.itechcareer.com. [En línea]

http://blog.itechcareer.com/index.php?option=com_content&view=article&id=39:icual-es-la-

diferencia-entre-un-modelo-tradicional-de-computacion-y-una-infraestructura-en-

nube&catid=17:tecnologia

30

2.5 CARACTERÍSTICAS CENTRALES DEL CLOUD COMPUTING

Dentro de las características que destacan del Cloud Computing se tienen las siguientes:

Bajo demanda: No hay necesidad de consultar a otra persona ni involucrar a un

profesional de tecnología para aprovisionar los componentes que se necesiten. Se

puede obtener el incremento en la capacidad de cómputo en el momento que sea

necesario.

Multiplataforma: Lo único que se necesita es una conexión a Internet para poder

acceder al servicio desde un equipo portátil, o cualquier dispositivo móvil no es

necesario cumplir con requisitos especiales de hardware.

Elasticidad: El usuario puede aumentar o disminuir la capacidad de procesamiento

según la demanda y el uso de los recursos en tiempo real.

Servicio medido: El uso de los recursos se monitorea, se controla y se reporta de

manera anticipada. Esto hace que el Cloud Computing sean básicamente lo mismo

que pagar por un servicio, como lo sería una línea telefónica.

Bajo costo: Productos gratuitos (servicios básicos) o pagos mensuales fijos por su

utilización, no se tienen costos adicionales y no se tiene que invertir en infraestructura,

licencias o mantenimientos.

Seguridad: Los datos siempre están seguros y se deben de cumplir con altos

estándares de seguridad para poder ofertar servicios de Cloud Computing,

adicionalmente se cuentan con contratos en donde se especifican las

responsabilidades de cada parte y el manejo que se va a tener de los datos.

Disponibilidad: Al tener redundancia en las capacidades de procesamiento y

almacenamiento se logra poder acceder a los recursos en cualquier momento.

2.6 MULTITENANT (MULTITENENCIA)

En el sitio “http://blog.itechcareer.com” se describe la multitenencia de la siguiente forma:

“Este concepto hace referencia a la posibilidad de que en los recursos agrupados de una

plataforma residan “múltiples ocupantes” (multitenant). El concepto de Multitenant significa

31

que un recurso de cómputo puede ser utilizado por más de un consumidor. Los recursos

como el almacenamiento, procesamiento, memoria, aplicaciones y otros pueden ser

compartidos entre diferentes clientes. Estos clientes pueden pertenecer a la misma

organización o pueden ser de empresas totalmente diferentes

Para lograr el Multitenant, son necesarias algunas tecnologías como virtualización y

segmentación de red, así como estrategias para el gobierno y aislamiento entre

aplicaciones.”9

La principal ventaja del Multitenant es la reducción de costos en las plataformas de clud computing

ya que al ser recursos compartidos se dividen los costos entre todos los participantes.

2.7 TIPOS DE CLOUD

En el mundo de las tecnologías de información, una Cloud representa una gran red de cables,

servidores y las aplicaciones que estos proporcionan. Al igual que las nubes pueden formarse de

diferentes maneras, desde pequeños nimbos hasta tormentas gigantes, existen varias maneras en

que el Cloud Computing puede adquirir forma. Las diferentes opciones basadas en Cloud son las

siguientes:10

Cloud Pública

Cloud Privada

Cloud híbrida

2.7.1 CLOUD PÚBLICA

Es un servicio estandarizado que permite el acceso y brinda servicios a cualquier usuario u

organización de manera simultánea pero independiente en cuanto a los componentes se refiere. El

9 itechcareer. blog.itechcareer.com. [En línea] http://blog.itechcareer.com/index.php?option=com_content&view=article&id=39:icual-es-la-diferencia-entre-un-modelo-tradicional-de-computacion-y-una-infraestructura-en-nube&catid=17:tecnologia. 10 Blanquer, Manuel Agudo. 2015. Openwebinars. [En línea] 14 de Mayo de 2015. https://openwebinars.net/blog/tipos-de-cloud-computing/

32

proveedor del Cloud administra la creación, el mantenimiento, la seguridad, la flexibilidad y la

escalabilidad de los recursos para todos los usuarios, estas clouds pueden adaptarse a empresas

u organizaciones tanto de fines académicos como gubernamentales; Las nubes públicas

pertenecen a empresas que tienen por objetivo la venta de servicios basados en cloud.11

La siguiente imagen muestra una representación gráfica de cloud pública:

Fig. 4 Cloud Pública.

(Imagen tomada de http://datacollaborationservices.com/services/cloud-solutions/)

2.7.2 CLOUD PRIVADA

Una cloud privada consiste en una empresa que monta soluciones hardware y software dentro de

su propia infraestructura para el uso de aplicaciones y servicios internos, es decir no se tiene un

punto de acceso a cualquier usuario o empresa. Todas las tareas de administración se realizan de

manera interna pero se puede recibir soporte de terceros.12

11 Salesforce . [En línea] https://www.salesforce.com/mx/cloud-computing/. 12 Salesforce . [En línea] https://www.salesforce.com/mx/cloud-computing/.

33

La siguiente imagen muestra una representación gráfica de cloud privada:

Fig. 5 Cloud Privada.

(Autoría propia)

2.7.3 CLOUDS HÍBRIDAS

Las clouds híbridas combinan las características de las clouds públicas y privadas para generar

una sola solución de cloud. La unión se da mediante tecnología o infraestructura y esto permite

que las aplicaciones y los datos puedan fluir, un ejemplo es en el caso donde una aplicación es

crítica y maneja datos sensitivos de una organización, en este caso esto se puede montar en la

parte privada y un servicio que esté abierto a cualquier usuario se puede montar en la parte

pública.

La siguiente imagen muestra una representación gráfica de cloud híbrida:

Hibrida

Fig. 6 Clouds Híbridas.

(Autoría propia, en base a la siguiente referencia: https://www.linkedin.com/pulse/architecture-iot-hybrid-cloud-chris-segura)

34

2.8 MODELOS DE SERVICIO CLOUD (SAAS, PAAS E IAAS)

Las soluciones cloud pueden den catalogarse en base a los modelos de servicios que ofrecen

como lo muestra la siguiente imagen:

Fig. 7 Modelo de servicio cloud

(Autoría propia)

2.8.1 SAAS (SOFTWARE AS A SERVICE)

El concepto de SaaS o Software as a Service (Software como Servicio) es la distribución de

software por parte de un proveedor de servicios, pero no como pieza de software que el usuario

puede descargar en su sistema para usarlo de manera local e indefinida, si no en forma de servicio

que el usuario puede contratar o utilizar de manera gratuita a través internet.

Las soluciones cloud basadas en SaaS empezaron a llegar a los usuarios en forma de espacios de

almacenamiento online, hoy en día van mucho más allá de esa funcionalidad, pudiendo ofrecer las

mismas funcionalidades que muchas de las aplicaciones que podemos tener en nuestro sistema,

pero sin la necesidad de poseer el software y ejecutarlo de manera local.13

Hoy en día tenemos multitud de muestras de soluciones de SaaS (Software as a Service), y

muchos de ellos son utilizados día a día de forma inconsciente. Algunos ejemplos de SaaS son: la

13 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/.

SaaS

PaaS

IaaS Infraestructura

Plataforma

Aplicaciones

35

suite de Google (Google Drive, Gmail, Google Docs), Dropbox, iCloud, Microsoft One Drive y Office

365.

La siguiente imagen muestra una representación gráfica de SaaS:

Fig. 8 SaaS.

(Autoría propia)

2.8.1.1 VENTAJAS Y DESVENTAJAS

En el sitio web “computernewage.com” se mencionan las siguientes ventajas y desventajas del

SaaS:

“Las principales ventajas de los modelos de software basados en SaaS son la obtención de

funcionalidades específicas de todo tipo de software sin necesidad de instalar y ejecutar

ninguna aplicación de manera local, lo que posibilita el acceso desde cualquier sistema

operativo, dispositivo y ubicación física con el único requisito de disponer de conexión a

internet.

Además, todo el mantenimiento del software, como lo son las actualizaciones, upgrades de

versión, etc, corre a cargo del proveedor de servicios, de este modo el usuario no tiene por

qué preocuparse por estas tareas y solo se dedica a consumir el servicio.

36

Las desventajas principales surgen del hecho de no ser el dueño del software como si

fuera un producto que compramos una vez y tenemos para siempre, sino que solo

podemos disfrutar de la funcionalidad, pero en forma de servicio que nos ofrece un tercero

(Proveedor de servicio), y en muchos casos, pagando por uso o por tiempo.

Adicionalmente, en el momento en que un producto nos es vendido como servicio,

perdemos el control del producto, los usuarios pasamos a perder de vista el concepto de

software como tal, y solo vemos un servicio que reúne unas características y que cumple

unas funciones, pero no vemos el producto que hay detrás, ni podemos configurar o

modificar a nuestro gusto.”14

2.8.2 PAAS (PLATFORM AS A SERVICE)

El concepto de PaaS o Platform as a Service (Plataforma como Servicio) es el siguiente escalón

respecto a las soluciones SaaS, y representa el punto intermedio entre SaaS e IaaS. En las

soluciones PaaS, el proveedor de servicios ofrece la plataforma o el sistema operativo en forma de

servicio y se encarga de la gestión, con todo lo que implica como la instalación de parches de

seguridad o las actualizaciones de sistema operativo.15

Si las soluciones SaaS tienen como objetivo principal a usuarios individuales, las soluciones PaaS

son destinadas a desarrolladores de aplicaciones y empresas, que en muchos casos las utilizaran

como plataforma para desarrollar aplicaciones, ofrecer soluciones SaaS, etc.

Como ejemplos de PaaS es Google App Engine, la plataforma de Google para que usuarios y

desarrolladores puedan subir, probar sus aplicaciones y ofrecerlas en forma de SaaS o Amazon

Web Services. Las aplicaciones que se construyen en estas plataformas pueden consumir una

cantidad limitada de recursos de manera gratuita, o en su defecto pagar solo por los recursos que

14 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-

cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015.

https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-

computing-saas-paas-y-iaas/. 15 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/.

37

se ocupan y a partir de eso se puede optar por una serie de planes de pago, dependiendo de las

capacidades y recursos adicionales que se necesiten.

La siguiente imagen muestra una representación gráfica de PaaS:

Fig. 9 PaaS.

(Autoría propia)

2.8.2.1 VENTAJAS Y DESVENTAJAS

En el sitio web “computernewage.com” se mencionan las siguientes ventajas y desventajas del

PaaS:

“La principal fortaleza del PaaS es la posibilidad de disponer de una plataforma adaptada,

gestionada y mantenida por un proveedor externo, permitiendo a los usuarios

despreocuparse por completo de este tipo de tareas y solo dedicarse a la construcción de

aplicaciones.

La desventaja es la dependencia que se genera con el proveedor de servicios. En PaaS

esto se traduce básicamente en las limitaciones de la propia plataforma elegida por el

38

proveedor de servicios, que ya de por si nos puede condicionar o limitar en gran medida en

los desarrollos que queramos llevar a cabo.”16

2.8.3 IAAS (INFRAESTRUCTURE AS A SERVICE)

El concepto de IaaS o Infraestructure as a Service (Infraestructura como Servicio) es el último

escalón en cuanto a modelos de servicio Cloud, y representa en cierto modo la disponibilidad de

recursos de hardware (CPU, RAM, almacenamiento de disco, red, etc.) en forma de servicio, de

modo que usuarios, o en este caso más bien desarrolladores o empresas, puedan construir sus

plataformas o soluciones de software online, en forma de soluciones PaaS o SaaS. IaaS es la capa

base sobre la que cualquier plataforma de tipo cloud se monta.17

En el caso de adoptar un modelo basado en IaaS, el proveedor se hace cargo de la gestión de los

recursos físicos, y los usuarios únicamente son responsables de la plataforma adoptada y de las

aplicaciones diseñadas o ejecutadas.

La siguiente imagen muestra una representación gráfica de IaaS:

Fig. 10 IaaS.

(Autoría propia)

16 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. 17 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/.

39

2.8.3.1 VENTAJAS Y DESVENTAJAS

En el sitio web “computernewage.com” se mencionan las siguientes ventajas y desventajas del

IaaS:

“La ventaja principal que ofrecen las soluciones IaaS es básicamente la disponibilidad de

recursos de hardware en forma de servicio, de forma relativamente accesible y muy

escalable, para permitir una implementación rápida de servicios web y proyectos de todo

tipo, que de otra forma sería más lenta y costosa.

Comparativamente con SaaS y PaaS, IaaS es el modelo de servicio que ofrece mayor

libertad y flexibilidad al usuario, ya que lo único que pone el proveedor son los recursos

físicos, pudiendo el usuario construir plataformas a la medida adaptadas completamente a

las necesidades que se tengan.

Las principales desventajas son la centralización y el control de los recursos por parte de

un proveedor externo.”18

En resumen, los modelos de servicio anteriormente mencionados han abierto la puerta a una

amplia gama de posibilidades de soluciones y aplicaciones de software a muchos sectores ya que

eliminan la barrera de la necesidad de conocimientos técnicos para configurar y mantener la

infraestructura; De este modo las empresas pueden optar por una alternativa personalizable,

confiable y segura.

18 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/.

40

2.9 SEGURIDAD EN LA NUBE

Las principales consideraciones de seguridad a tomar en cuenta son las siguientes:

“Una duda recurrente acerca cualquier servicio que consumimos en la nube, ya sea en

forma de aplicaciones (SaaS), plataforma de desarrollo (PaaS), o recursos de hardware

(IaaS), es sobre la seguridad que nos garantizan los proveedores de servicios, y si son

más o menos seguras que las soluciones tradicionales.

Lo cierto es que el simple hecho que las aplicaciones, plataformas o recurso de hardware

se ofrezcan en forma de servicio a través de la nube, de entrada, no las hace ni más ni

menos seguras. La única diferencia es que el proveedor de servicio es el encargado de

gestionar ciertos aspectos de seguridad, que de otro modo quedaría del lado del usuario.

Partiendo de la premisa de que una empresa siempre tendrá muchos más recursos y

presupuesto para invertir en seguridad, en la mayoría de los casos es bastante razonable

pensar en que, por regla general, un servicio cloud debería ofrecer cierta seguridad extra

en varios aspectos ya que cuenta con los recursos especializados para ello.

Como desventaja importante, está el hecho de que se deja de tener el control de los datos,

las aplicaciones que se usan, o los recursos de hardware que sean contratados,

dependiendo en cada caso de si se trata de un servicio SaaS, PaaS o IaaS.

Por lo tanto, utilizar o contratar un servicio cloud, desde una aplicación como iCloud o

desde una solución como Amazon Web Services, se requiere confiar y tener la certeza de

que el proveedor realizará una gestión de la seguridad responsable.

Al final, como con casi todo, una solución Cloud será más o menos segura dependiendo

del interés que le preste la empresa a este aspecto. Para el usuario, un servicio Cloud es

en cierto modo como una “caja negra”, y el éxito depende en gran medida de la confianza

entre usuario y proveedor.”19

19 Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015.

41

Las consideraciones anteriormente mencionadas nos permiten entender que no por el hecho de

tener los datos en la nube estos automáticamente están expuestos o por el contrario estarán más

seguros, el nivel de seguridad depende de los usuarios y de las empresas si no se realiza un

adecuado entendimiento de un contrato o cláusulas del mismo podemos estar aceptando riesgos

los cuales no se debería, adicionalmente es las plataformas cloud nos permiten establecer los

mecanismos y controles de seguridad que se crean necesarios y adecuados en función del servicio

que vayamos consumir.

Esta vertiente la aborda Salesforce en su sitio web:

“El Cloud Computing también puede ser extremadamente seguro y, a menudo, superar los

niveles de seguridad de la informática tradicional. El Cloud Computing permite a las

empresas atraer y conservar personal de seguridad informática más capacitado; También

permite implementar las tecnologías y las mejores prácticas más recientes, con la ayuda de

una visión más amplia de patrones de amenazas globales que la disponible incluso para la

mayoría de los gobiernos nacionales.

Con decenas o, incluso, cientos de usuarios potencialmente en riesgo de exposición a

programas maliciosos, mantener a las organizaciones a salvo puede ser costoso. Los

proveedores de Cloud Computing trabajan con un presupuesto mucho mayor debido a que

necesitan proteger a todos sus clientes de este modo todas las empresas o usuarios que

contraten un servicio se benefician ya que significa un mayor nivel de seguridad para

todos.”20

Una alternativa para tratar de estandarizar los controles que se deben de seguir la brinda el Cloud

Security Alliance y van a ser descritos a continuación.

El Cloud Security Alliance en su “SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD

COMPUTING V3.0” propone los siguientes 14 dominios para la seguridad del cloud computing: 21

Marco de referencia de arquitectura para cloud computing.

20 Salesforce . [En línea] https://www.salesforce.com/mx/cloud-computing/. 21 Alliance, Cloud Security. 2011. cloudsecurityalliance.org. [En línea] 2011.

https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf.

42

Gobierno y gestión del riesgo corporativo.

Cuestiones legales.

Cumplimiento legal y gestión de auditoría.

Gestión de la información y de la seguridad de los datos.

Interoperabilidad y portabilidad.

Seguridad tradicional, continuidad de negocio y recuperación de desastres.

Actividades del CPD.

Respuesta a incidentes.

Seguridad de aplicaciones.

Cifrado y gestión de claves.

Identidad, autorización y gestión de accesos.

Virtualización

Security as a Service (SECaaS)

De los de los dominios anteriormente mencionados nos centraremos en el último Security as a

Service (SECaaS) el cual se describe a continuación.

2.10 SECAAS

El concepto de SECaaS o Security as a Service lo define de la siguiente manera SVT Cloud

proveedor de Servicios Cloud y Seguridad en España:

43

“Es la provisión de servicios de seguridad desde la nube, lo que permite que algunos servicios y

tecnologías que tradicionalmente sólo estaban al alcance de empresas grandes, estén accesibles a

Pymes y Administraciones públicas”.22

Las principales ventajas que plantea SVT Cloud son las siguientes:

Provisión del servicio de una manera más rápida, ágil y mucho más fácil escalable,

inclusive puede llegar a darse despliegue de manera automatizada.

Se reduce el presupuesto de inversión en materia de tecnologías y recursos dedicados a la

seguridad ya que solo se paga por lo que se utiliza.

La gestión de las actualizaciones de las tecnologías de seguridad necesarias para

mantener el nivel de riesgo aceptable, gracias a que el proveedor de servicios absorbe

estas actividades se disminuyen los costos de mantenimiento y el tiempo a dedicar por

personal especializado.

Se reduce el gasto continúo debido a los constantes cambios tecnológicos y se mantiene

un nivel de seguridad adecuado.

La SCA (Cloud Security Alliance), publica un documento que sirve de base para identificar y

agrupar los principales servicios de seguridad que se pueden ofrecer desde un entorno de nube.

La Cloud Security Alliance (SCA) definió por primera vez las siguientes categorías en 2011 y hoy

siguen siendo la base de SECaaS:23

1. Gestión de Identidades y Accesos: Servicios como Web Single-Sign-On, Federación de

Identidades, Gestión de Identidades, Firma electrónica, Gestión de autorizaciones, etc.

2. DLP (Data Loss Prevention): Soluciones de prevención de pérdida de datos.

22 Cloud Security Services. 2012. Cloud Security Services. [En línea] 06 de Octubre de 2012.

http://blog.svtcloud.com/secaas-o-seguridad-como-servicio-no-solo-para-las-grandes-empresas/.

23 Alliance, Cloud Security. 2011. cloudsecurityalliance.org. [En línea] 2011.

https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf.

44

3. Seguridad Web: Algunos ejemplos pueden ser soluciones de Filtrado Web, Análisis de

Vulnerabilidades Web, Monitorización o Anti-phising.

4. Seguridad del Correo Electrónico: Mail Relay, Anti-Spam, Antivirus / Atni-malware.

5. Evaluación de la Seguridad: Auditorias de servicios Cloud, o evaluaciones de sistemas e

infraestructura instalados en el cliente (on-premise) basados en estándares, como por

ejemplo pen-testing, evaluación de la seguridad perimetral, evaluación de la seguridad del

entorno virtual, etc.

6. Gestión de la Intrusión: Detección, prevención y reacción ante eventos inusuales,

incluyendo reconfiguración de la infraestructura o los sistemas en tiempo real para detener

o prevenir una intrusión.

7. Gestión de la Información de Seguridad y Gestión de eventos (SIEM): Servicios basado en

recopilación y análisis de logs de los componentes de la infraestructura para

correlacionarlos, analizarlos y proporcionar informes en tiempo real y alertas ante

incidentes de seguridad.

8. Encriptación: Servicios de red privada virtual (VPN), encriptación de las comunicaciones o

la gestión de claves.

9. Continuidad de negocio y Recuperación ante desastres (Disaster Recovery): Orientados a

garantizar las actividades de la organización en caso de problemas con la infraestructura o

servicios proporcionados.

10. Seguridad de las Redes: Orientados a implementar los controles de seguridad en la

infraestructura de red, como pueden ser soluciones de Firewall, IDS/IPS o el monitoreo de

la infraestructura.

Este modelo de servicio tiende a desarrollarse cada día más principalmente debido a que las

empresas no requieren tener una compleja administración de estos componentes y se limitan a

pagar por el uso sin tener que hacer una gran inversión en infraestructura (y el personal

45

especializado). De este modo las empresas pueden aspirar a incrementar el nivel de seguridad

dentro de la organización y conseguir un nivel de riesgo bajo o aceptable.

Adicionalmente es necesario contar con un acuerdo de confidencialidad como lo menciona David

Gutiérrez en su artículo “SecaaS (Security as a Service): ¿Está listo?”24

“Un punto a cuidar al adoptar este tipo de servicios para nuestras organizaciones es el de

la confidencialidad con la que se maneja la información, ya sea cuando se encuentra en

tránsito o bien como cuando es procesada y almacenada por el proveedor de servicios de

seguridad en la nube. Deben existir algunos controles básicos dentro del contrato con el

proveedor de servicios de seguridad en la nube para atender esta situación.

Como mínimo, el proveedor de servicios debe firmar un acuerdo de confidencialidad y no

divulgación que lo obligue a no revelar datos a los que pudiera tener acceso durante la

provisión del servicio, además de que el proveedor deberá contar con políticas muy

estrictas para la destrucción de información que pudiera encontrarse en hardware que se

retira de servicio activo.

La tolerancia al riesgo que tengamos en la organización dictará qué tan estrictas serán las

medidas de control que deberemos tomar al adoptar un servicio de seguridad administrada

en la nube. Si la información que será procesada a través del servicio es altamente

sensible, probablemente requerimos reservarnos el derecho de auditar al proveedor de

servicio para garantizar que la confidencialidad, integridad y disponibilidad de la misma

estén correctamente gestionadas, pudiendo inclusive pedir documentación con los detalles

sobre la manera en que el proveedor atenderá nuestras necesidades de seguridad en la

transmisión, procesamiento y almacenamiento de nuestra información.”

24 SecaaS (Security as a Service): ¿Está listo? CISA, David Gutiérrez. CISSP y. 2010. [ed.]

Magazcitum. 08 de Octubre de 2010, Magazcitum.

46

2.11 INTRODUCCIÓN A OPENSTACK

Openstack tiene por objetivo crear una plataforma en software libre para cloud computing que

cumpla con las necesidades de los proveedores de nubes públicas y privadas, independientemente

de su tamaño, que sea fácil de implementar y masivamente escalable.

El proyecto de Openstack inició en el año 2010 por la empresa Rackspace Cloud y por la agencia

espacial norteamericana (NASA). Actualmente más de 300 empresas se han unido al proyecto,

entre las que se encuentran AMD, Intel, Canonical, SUSE Linux, Red Hat, IBM, Dell, HP, Cisco,

etc. Openstack es software libre bajo los términos de la licencia Apache.25

Openstack reúne un conjunto de tecnologías código abierto que proporcionan la plataforma de

software para el despliegue de un cloud computing fácilmente escalable. Puede ser utilizado por

cualquier organización ya sea pequeña, mediana o grande que busquen tener una nube escalable

ya sea para uso público o privado.

2.11.1 ¿QUÉ ES OPENSTACK?

Desde el punto de vista de software, Openstack es un conjunto de proyectos de software libre

mantenidos por la comunidad que incluyen varios componentes. A través de estos servicios, se

proporciona una completa plataforma operativa para la administración y gestión de la

infraestructura como servicio (IaaS).26

Definir a Openstack es mucho más sencillo una vez que los principales conceptos sobre

Computación en la Nube se hacen más aparentes. La misión principal del proyecto es proporcionar

un software que cubra el ciclo completo de este tipo de despliegues y que proporcione el poder

desplegar de forma sencilla, escalable, elástica y de cualquier tamaño infraestructura tanto para

nubes públicas como privadas.

Uno de los aspectos clave de Openstack es que los servicios son compatibles con sus

funcionalidades equivalentes de Amazon Web Services (AWS). Esto implica que, si ya se tiene de

una aplicación que se ejecuta en AWS se podrá migrar de forma transparente y se ejecutará en el

25 OpenStack. OpenStack. [En línea] https://www.openstack.org/. 26 OpenStack. OpenStack. [En línea] https://www.openstack.org/.

47

entorno de Openstack. Esta funcionalidad permite reducir costos ya que no es necesario realizar

un desarrollo adicional o pagar el servicio de algún integrador ya que todo se puede realizar de

manera interna.

2.11.2 DISEÑO DE OPENSTACK

Openstack es modular en cuanto al diseño, y consta de un conjunto de proyectos de desarrollo

independientes, todos agrupados y trabajando en conjunto. Los servicios de Openstack resultantes

pueden emplearse para crear grandes “pools” de recursos de procesamiento, almacenamiento y

redes, gestionados mediante una consola que otorga control a los administradores y permite que

los usuarios aprovisionen recursos mediante una interfaz web. Los usuarios de un cloud de

Openstack pueden seleccionar y configurar servicios manualmente. Las aplicaciones que se

ejecutan en un cloud de Openstack pueden seleccionar y configurar servicios mediante

programación utilizando las API de Openstack.27

A pesar de que los módulos de los componentes están diseñados para funcionar conjuntamente,

se pueden elegir únicamente los componentes que se necesiten.

2.11.3 COMPONENTES DE OPENSTACK

Los componentes principales de Openstack son los siguientes:

2.11.3.1 COMPUTE (NOVA)

Es el controlador de la estructura básica del Cloud. Es el encargado de iniciar las instancias

(máquinas virtuales) de los usuarios y grupos. También es el servicio encargado de la gestión de la

red virtual para cada instancia o para las múltiples instancias que formen parte de un proyecto.28

2.11.3.2 OBJECT STORE (SWIFT)

Es el servicio encargado del almacenamiento masivo de objetos a través de un sistema escalable,

redundante y tolerante a fallos. Las posibles aplicaciones de Object Storage son numerosas, como

27 OpenStack. OpenStack. [En línea] https://www.openstack.org/. 28 Openstack Compute. [En línea] 27 de 04 de 2017. https://docs.openstack.org/admin-guide/compute.html.

48

por ejemplo: almacenamiento simple de archivos, copias de seguridad, almacenamiento de

audio/vídeo, almacenamiento secundario/terciario, desarrollo de nuevas aplicaciones con

almacenamiento integrado, etc.29

2.11.3.3 BLOCK STORAGE (CINDER)

Proporciona dispositivos de almacenamiento a nivel de bloque persistentes para usar con

instancias de Openstack Compute. El sistema de almacenamiento de bloques gestiona la creación,

aplicación y el desmontaje de los dispositivos de bloque a los servidores. 30

2.11.3.4 NETWORKING (NEUTRON)

Es un sistema para la gestión de redes y direcciones IP, cuida el rendimiento de la red

asegurándose que no se presenten “cuellos de botella”, proporciona modelos de redes para

diferentes aplicaciones o grupos de usuarios y ofrece a los usuarios un autoservicio real, incluso a

través de sus configuraciones de red.31

2.11.3.5 DASHBOARD (HORIZON)

Es un portal web para el manejo de instancias y volúmenes. Este servicio es realmente una

aplicación web desarrollada en django que permite comunicarse con las diferentes APIs de

Openstack de una forma sencilla. Openstack Dashboard es fundamental para usuarios noveles y

en general para realizar acciones sencillas sobre las instancias.32

29 Openstack Object Storage. [En línea] 27 de 04 de 2017. https://docs.openstack.org/admin-

guide/objectstorage.html. 30 Openstack. 2017. Openstack Block Storage. [En línea] 27 de 04 de 2017.

https://docs.openstack.org/admin-guide/blockstorage.html. 31 Openstack Networking. [En línea] 27 de 04 de 2017. https://docs.openstack.org/admin-

guide/networking.html. 32 Openstack Dashboard. [En línea] 27 de 04 de 2017. https://docs.openstack.org/admin-guide/dashboard.html.

49

2.11.3.6 IDENTITY (KEYSTONE)

Es un servicio usado para la autenticación entre el resto de componentes. Este servicio utiliza un

sistema de autenticación basado en tokens y se incorporó en la versión 2012.1 de Openstack.33

2.11.3.7 IMAGE SERVICE (GLANCE)

Es un servicio para la búsqueda y recuperación de imágenes de máquinas virtuales. Este servicio

puede almacenar las imágenes directamente o utilizar mecanismos más avanzados como usar

Object Storage como servicio de almacenamiento.34

El siguiente diagrama muestra los principales componentes de Openstack para el despliegue de

infraestructura como servicio (IaaS):

Fig. 11 Componentes básicos de Openstack.

(Figura tomada del sitiohttp://www.sdnstack.com/product/Openstack-100/)

33 Openstack Identity management. [En línea] 27 de 04 de 2017.

https://docs.openstack.org/admin-guide/identity-management.html. 34 Openstack Image. [En línea] 27 de 04 de 2017. https://docs.openstack.org/admin-

guide/image.html.

50

2.11.4 ARQUITECTURA CONCEPTUAL DE OPENSTACK

Desde una perspectiva global, Openstack está diseñado para ser un sistema operativo base para

el despliegue de infraestructura como servicio para el cómputo en la nube. Para poder lograrlo,

cada uno de los servicios que conforman Openstack están diseñados para trabajar conjuntamente.

Esta integración se consigue a través de APIs (Application Programming Interfaces) que cada

servicio ofrece, y que cada servicio puede consumir. Mientras que estas APIs permiten a cada uno

de los servicios utilizar el resto, también permiten al desarrollador poder reemplazar cualquier

servicio con otra implementación, siempre y cuando se respeten estas APIs. Dichas APIs también

se encuentran disponibles para el usuario final de la infraestructura.

En el siguiente diagrama conceptual se muestran las interacciones entre los componentes de

Openstack:

Fig. 12 Interacción de componentes de Openstack

(Figura tomada del sitio http://vmartinezdelacruz.com/en-pocas-palabras-como-funciona-Openstack/)

51

Victoria Martínez de la Cruz en su sitio web describe las siguientes interacciones entre los

componentes de Openstack:35

Dashboard (Horizon): Provee una interfaz web a los usuarios finales y a los

administradores.

Compute (Nova): Recupera imágenes y metadatos asociados para generar las

máquinas virtuales.

Network (Neutron): Provee redes virtuales como servicio entre dispositivos

administrados por otros servicios de Openstack, como puede ser una máquina virtual

de Nova. Permite a los usuarios crear sus propias redes y luego vincularlas con los

dispositivos que deseen.

Block Storage (Cinder): Provee almacenamiento persistente a las máquinas virtuales.

Image (Glance): Provee un catálogo y un repositorio para las imágenes que servirán de

base para las máquinas virtuales.

Object Store (Swift): Provee almacenamiento de objetos.

Identity (Keystone): Provee autenticación y autorización para todos los servicios de

Openstack.

CIERRE CAPÍTULO 2

Este capítulo nos permitió conocer los conceptos básicos de cloud computing, las modalidades en

que podemos consumirlos con sus pros y contras en cada uno de los esquemas y las

consideraciones de seguridad que se deben de tener al pasar a este tipo de esquema de trabajo.

Es importante mencionar que el cloud computing va a ser tan seguro como nosotros lo queramos

ya sea solicitando al proveedor del servicio o implementando los controles que consideremos

pertinentes para esto.

35 Cruz, Victoria Martínez de la. 2013. En pocas palabras: ¿Cómo funciona OpenStack? [En línea] 1 de Febrero de 2013. http://vmartinezdelacruz.com/en-pocas-palabras-como-funciona-openstack

52

CAPÍTULO 3 ANÁLISIS DE CUMPLIMIENTO SECAAS

3.1 SERVICIOS DE CUMPLIMIENTO DE SECAAS

De los principales servicios de seguridad que publica la SCA (Cloud Security Alliance), daremos

cumplimiento a los siguientes debido a que son los principales y con ello se puede lograr un nivel

de seguridad adecuado.

1. Gestión de Identidades y Accesos

2. Seguridad Web

3. Evaluación de la Seguridad

4. Gestión de la Intrusión

5. Gestión de la Información de Seguridad y Gestión de eventos

6. Seguridad de las Redes

Para realizar dicho cumplimiento usaremos las herramientas de seguridad descritas a continuación.

3.2 SERVIDOR PROXY INVERSO (REVERSE PROXY)

IBM define un servidor proxy inverso de la siguiente manera:

“Es un dispositivo de seguridad que suele desplegarse en la DMZ de una red para proteger

a los servidores HTTP de una intranet corporativa, realizando funciones de seguridad que

protegen a los servidores internos de ataques de usuarios en Internet.

53

El servidor proxy inverso protege a los servidores HTTP internos proporcionando un punto

de acceso único a la red interna.”36

Al proporcionar un único punto de acceso a los servidores web se obtienen las siguientes ventajas:

El proxy inverso puede ser habilitado como componente de autenticación y de autorización

(Control de acceso) para brindar acceso a las aplicaciones WEB protegiendo los servidores

donde estas residen y simplificando la administración de usuarios y permisos.

Todo el tráfico hacia los servidores llega de una única dirección IP (la IP del proxy inverso).

La dirección IP del proxy inverso puede ser asociada a varios dominios y solo esta se

expone a los usuarios internos o externos.

El proxy inverso reescribe el URL sustituyendo la dirección del servidor proporcionada por

el usuario de Internet (una dirección de proxy inverso) con la dirección real del servidor

interno. La solicitud HTTP se envía entonces a la red interna desde el servidor proxy

inverso al servidor interno.

Todo el tráfico enviado a los usuarios de Internet desde los servidores internos parece

proceder de una única dirección IP.

El proxy inverso se puede configurar para realizar un cache de componentes estáticos, de

este modo acelera los tiempos de respuesta y reduce la carga del servidor web.

Cuando un servidor web responde a una solicitud de un usuario, el servidor web envía la

respuesta al servidor proxy inverso y el servidor proxy inverso envía la respuesta al

usuario, de este modo no se expone el direccionamiento IP de la red interna ya que el

usuario solo observa la IP del proxy inverso.

36 Center, IBM Knowledge. IBM Knowledge Center. [En línea]

https://www.ibm.com/support/knowledgecenter/es/SSKTXQ_8.5.0/com.ibm.help.sametime.v85.

doc/config/st_adm_port_rvprxy_overview_c.html.

54

La siguiente figura muestra el funcionamiento de un esquema de proxy inverso:

Proxy Inverso Servidor WEB

Fig. 13 Funcionamiento de Proxy inverso

(Autoría propia)

3.2.1 EJEMPLOS DE PROXY INVERSO MÁS USADOS

Los principales proxys inversos que se tienen en el mercado son los siguientes:

IBM Security Access Manager

Apache

Nginx

3.3 LDAP

LDAP Lightweight Directory Access Protocol (Protocolo ligero de acceso a directorios) es un

conjunto de protocolos abiertos usados para acceder información guardada centralmente a través

de la red. Está basado en el estándar X.500 para compartir directorios, pero es menos complejo e

intensivo en el uso de recursos. Por esta razón, a veces se habla de LDAP como "X.500 Lite." El

estándar X.500 es un directorio que contiene información de forma jerárquica y categorizada, que

puede incluir nombres, directorios y números telefónicos.37

37 Red Hat. 2005. Red Hat Enterprise Linux 4: Manual de referencia. [En línea] 2005.

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/ch-ldap.html.

55

El Servicio de Directorio o simplemente el Directorio LDAP es un término utilizado para referirse

tanto a la información que almacena, las aplicaciones y la infraestructura que soporta el servicio.

Los directorios permiten localizar de manera más fácil la información, ya que esta se almacena en

una estructura de árbol esto permite optimizar las búsquedas de información.

La información generalmente está relacionada con los usuarios, pero, algunas veces, se utilizan

con otros propósitos, como administrar la infraestructura (los servidores Linux/UNIX se pueden

configurar para que autentiquen los usuarios mediante LDAP).

El protocolo LDAP define el método para acceder a datos en el servidor a nivel cliente, pero no la

manera en la que se almacena la información. El protocolo LDAP actualmente se encuentra en su

tercera versión y se puede consultar todo su detalle en el RFC 2251 para LDAP v3

(https://tools.ietf.org/html/rfc2251)

LDAP proporciona las siguientes funcionalidades:

Conexión

Desconexión

Búsquedas de Información

Insertar entry’s

Modificar atributos y entry´s

Eliminar entry´s

Manejo de grupos estáticos y dinámicos.

Soporte para SSL

Autenticación

56

3.3.1 ESTRUCTURA DE ÁRBOL DE LA INFORMACIÓN (DIT)

LDAP presenta la información bajo la forma de una estructura jerárquica de árbol denominada DIT,

en la que la información, denominada entradas, es representada por bifurcaciones. Una bifurcación

ubicada en la raíz de una bifurcación se denomina entrada raíz. 38

La siguiente imagen muestra una representación gráfica de la estructura de árbol de un directorio:

Fig. 14 Estructura de datos de LDAP

(Autoría propia)

38 CCM Protocolo LDAP. [En línea] Mayo de 2017. http://es.ccm.net/contents/269-protocolo-ldap.

o=Ejemplo

ou=Usuarios

ou=Finanzas

cn=Juan

o=RH

ou=Servidores

57

3.3.2 ENTRY (ENTRADA)

Cada entry (entrada) en el directorio LDAP corresponde a un objeto abstracto o real (como un

usuario o un área de una organización). etc.). Cada entrada está conformada por un conjunto de

pares clave/valor denominados atributos.

Cada entry está compuesta por un conjunto de atributos (clave/valor) que lo caracteriza o

describen; Existen dos tipos de atributos: 39

Atributos normales: Son los atributos comunes que distinguen al objeto (apellido, nombre,

etc.)

Atributos operativos: Son atributos a los que sólo el LDAP puede acceder para manipular

los datos del directorio (fechas de modificación, creación).

Una entrada se indexa mediante un nombre completo (DN) que permite identificar de manera única

un elemento de la estructura de árbol. Un DN se constituye tomando el nombre del elemento

denominado Nombre distintivo relativo (RDN, es decir, la ruta de la entrada en relación con sus

entradas superiores) y agregándole el nombre entero de la entrada principal.

3.3.3 EJEMPLOS DE LDAP MÁS USADOS

Oracle directory server

IBM Tivoli Directory Server

OpenLDAP

39 CCM Protocolo LDAP. [En línea] Mayo de 2017. http://es.ccm.net/contents/269-protocolo-ldap.

58

3.4 FIREWALL

Un firewall es un dispositivo de seguridad de la red que monitorea el tráfico de red tanto entrante

como saliente y decide mediante “reglas” (políticas) definidas si permite o bloquea tráfico

específico. Un firewall puede ser hardware, software o ambos.40

Los firewalls han constituido una primera línea de defensa en seguridad de la red durante más de

25 años. Establecen una barrera entre las redes internas protegidas y controladas en las que se

puede confiar y redes externas que no son de confianza, como Internet.

3.4.1 TIPOS DE FIREWALL

CISCO cataloga los firewalls de la siguiente manera:41

3.4.1.1 FIREWALL PROXY

Un firewall proxy, uno de los primeros tipos de dispositivos de firewall, funciona como gateway de

una red a otra para una aplicación específica. Los servidores proxy pueden brindar funcionalidad

adicional, como seguridad y almacenamiento de contenido en caché, evitando las conexiones

directas desde el exterior de la red.

3.4.1.2 FIREWALL DE INSPECCIÓN ACTIVA

Un firewall de inspección activa, ahora considerado un firewall “tradicional”, permite o bloquea el

tráfico en función del estado, el puerto y el protocolo. Este tipo de firewall monitorea toda la

actividad, desde la apertura de una conexión hasta su cierre. Las decisiones de filtrado se toman

de acuerdo con las reglas definidas por el administrador y con el contexto, lo que refiere a usar

información de conexiones anteriores y paquetes que pertenecen a la misma conexión.

40 CISCO. CISCO Firewall. [En línea]

http://www.cisco.com/c/es_mx/products/security/firewalls/what-is-a-firewall.html. 41 CISCO. CISCO Firewall. [En línea]

http://www.cisco.com/c/es_mx/products/security/firewalls/what-is-a-firewall.html.

59

3.4.1.3 FIREWALL DE ADMINISTRACIÓN UNIFICADA DE AMENAZAS

(UTM)

Un dispositivo UTM suele combinar en forma flexible las funciones de un firewall de inspección

activa con prevención de intrusiones y antivirus. Además, puede incluir servicios adicionales y, a

menudo, administración de la nube. Los UTM se centran en la simplicidad y la facilidad de uso.

3.4.1.4 FIREWALL DE SIGUIENTE GENERACIÓN (NGFW)

Los firewalls han evolucionado más allá de la inspección activa y el filtrado simple de paquetes. La

mayoría de las empresas están implementando firewalls de próxima generación para bloquear las

amenazas modernas, como los ataques de la capa de aplicación y el malware avanzado.

Funcionalidades de firewall estándares, como la inspección con estado

Prevención integrada de intrusiones

Reconocimiento y control de aplicaciones para ver y bloquear las aplicaciones peligrosas

Rutas de actualización para incluir fuentes de información futuras

Técnicas para abordar las amenazas de seguridad en evolución

3.4.1.5 FIREWALL DE SIGUIENTE GENERACIÓN (NGFW) CENTRADO

EN AMENAZAS

Estos firewalls incluyen todas las funcionalidades de un NGFW tradicional y adicionalmente brindan

funciones de detección y corrección de amenazas avanzadas. Con un NGFW centrado en

amenazas, puede hacer lo siguiente:

Estar al tanto de cuáles son los activos que corren mayor riesgo con reconocimiento del

contexto completo

60

Reaccionar rápidamente ante los ataques con automatización de seguridad inteligente que

establece políticas y fortalece las defensas en forma dinámica

Detectar mejor la actividad sospechosa o evasiva con correlación de eventos de terminales

y la red

Reducir significativamente el tiempo necesario desde la detección hasta la eliminación de

la amenaza con seguridad retrospectiva que monitorea continuamente la presencia de

actividad y comportamiento sospechosos, incluso después de la inspección inicial

Facilitar la administración y reducir la complejidad con políticas unificadas que brindan

protección en toda la secuencia del ataque

La siguiente imagen muestra como un firewall es conectado frente al equipo (o equipos) que se

deseen proteger:

Firewall

Fig. 15 Protección por firewall

(Autoría propia)

61

3.4.2 EJEMPLOS DE FIREWALLS MÁS USADOS

CISCO ASA

Palo Alto Networks

Checkpoint

pfSense

OPNsense

3.5 IPS

Un IPS (Intrusion Prevention System) es un dispositivo de seguridad dedicado a la prevención de

intrusiones a partir de la identificación y bloqueo de patrones específicos de ataque en su flujo por

la red; Están diseñados para prestar de manera dedicada este tipo de funcionalidades, con una

base amplia de firmas y algunas detecciones basadas en métodos relacionados con

comportamiento.

3.5.1 CLASIFICACIONES

Los sistemas de prevención de intrusiones se pueden clasificar en cuatro tipos diferentes:42

Basado en la red Lan (NIPS): Monitorea la red Lan para identificar el tráfico sospechoso.

Basado en la red inalámbrica (WIPS): Monitorea la red inalámbrica para identificar el tráfico

sospechoso.

Basado en análisis de comportamiento de red (NBA): Examina el tráfico de red para

identificar desviaciones (flujos de tráfico inusuales), a los comportamientos “normales” que

se tienen dentro de la red.

Basado en host (HIPS): Se instala software en un único equipo y se realiza el monitoreo en

búsqueda de actividades sospechosas que ocurran dentro de ese equipo.

42 Wikipedia. [En línea] 7 de Febrero de 2017.

https://es.wikipedia.org/wiki/Sistema_de_prevenci%C3%B3n_de_intrusos.

62

3.5.2 MÉTODOS DE DETECCIÓN

Los métodos de detección utilizados por los IPS son los siguientes:43

3.5.2.1 DETECCIÓN BASADA EN FIRMAS

Una firma tiene la capacidad de reconocer una determinada cadena de bytes en cierto contexto, y

entonces lanza una alerta. Para que este tipo de detección funcione de manera adecuada es

necesario verificar que las firmas estén constantemente actualizadas.

3.5.2.2 DETECCIÓN BASADA EN POLÍTICAS

En este tipo de detección, el IPS requiere que se declaren muy específicamente las políticas de

seguridad. Por ejemplo, determinar que hosts pueden tener comunicación con determinadas redes.

El IPS reconoce el tráfico fuera del perfil permitido y lo descarta.

3.5.2.3 DETECCIÓN BASADA EN ANOMALÍAS

Este tipo de detección tiende a generar muchos falsos positivos, ya que es sumamente difícil

determinar y medir una condición “normal”. En este tipo de detección tenemos dos opciones:44

1. Detección estadística de anormalidades: El IPS analiza el tráfico de red por un

determinado periodo de tiempo y crea una línea base de comparación (modo aprendizaje).

Cuando el tráfico varía demasiado con respecto a la línea base de comportamiento, se

genera una alarma.

2. Detección no estadística de anormalidades: En este tipo de detección, es el administrador

quien define el patrón “normal” de tráfico. Sin embargo, debido a que con este enfoque no

se realiza un análisis dinámico y real del uso de la red, es susceptible a generar muchos

falsos positivos.

43 Wikipedia. [En línea] 7 de Febrero de 2017.

https://es.wikipedia.org/wiki/Sistema_de_prevenci%C3%B3n_de_intrusos. 44 Wikipedia. 2017. [En línea] 7 de Febrero de 2017.

https://es.wikipedia.org/wiki/Sistema_de_prevenci%C3%B3n_de_intrusos.

63

La siguiente imagen muestra cómo se conecta un IPS en conjunto con un firewall:

IPS

Fig. 16 Integración de IPS

(Autoría propia)

3.5.3 EJEMPLOS DE IPS MÁS USADOS

Snort

CISCO Firepower

Checkpoint

Suricata

3.6 IDS

Un Intrusion Detection System (IDS) detectar actividades inapropiadas, incorrectas o anómalas en

la red de una organización.45

Los sistemas de detección de intrusos pueden clasificarse, según su función y comportamiento en:

Basados en host: Se instalan en un equipo para detectar actividad maliciosa en el mismo.

45 Wikipedia. [En línea] 15 de Marzo de 2017.

https://es.wikipedia.org/wiki/Sistema_de_detecci%C3%B3n_de_intrusos.

64

Basados en red: Monitorea la red para identificar el tráfico sospechoso.

Basados en conocimiento: Sistemas basados firmas.

Basados en Comportamiento. Se detecta una intrusión mediante una desviación en el

comportamiento normal.

Las características de un sistema IDS son las siguientes:

Debe funcionar continuamente sin supervisión humana.

Debe ser tolerante a fallos.

Debe de poder detectar si ha sido comprometido.

No debe de degradar en flujo de comunicaciones

Debe observar desviaciones sobre el comportamiento estándar.

Debe ser fácilmente adaptable al sistema ya instalado.

La siguiente imagen muestra cómo se conecta un IDS en conjunto con un firewall:

IDS

Fig. 17 Integración de IDS

(Autoría propia)

El IDS al ser un sistema pasivo el cual no previene y no puede remediar una intrusión no es tan

usado como un IPS, un IPS puede hacer las funciones de un IDS pero un IDS no puede hacer las

65

funciones de IPS, este último es el componente más usado. La única forma de lograr la mitigación

de una intrusión con un IDS es integrándolo a otro dispositivo de red como un Firewall.

3.6.1 EJEMPLOS DE IDS MÁS USADOS

Snort

Suricata

3.7 ESCANEO DE VULNERABILIDADES

El Escaneo de Vulnerabilidades es la identificación, análisis y reporte sistemático de las

vulnerabilidades de seguridad técnica que terceros e individuos no autorizados pueden usar para

explotar y amenazar la confidencialidad, integridad y disponibilidad del negocio, los datos técnicos

y la información.46

3.7.1 VULNERABILIDAD

Norton define las vulnerabilidades de la siguiente manera:

“Las vulnerabilidades son imperfecciones del programa informático que crean debilidades

en la seguridad general del equipo o la red. Las vulnerabilidades también pueden crearse

por configuraciones incorrectas de seguridad o del equipo. Las amenazas explotan las

debilidades de las vulnerabilidades que dan como resultado posibles daños al equipo o a

los datos personales.”47

3.7.2 TIPOS DE ESCÁNERS

Las herramientas de escaneo de vulnerabilidades pueden clasificarse de la siguiente manera:

Escáner de Red: Escáner de uso general usado para encontrar vulnerabilidades

potenciales en la red de la empresa.

46 Control Case. Control Case Managed Compliance. [En línea]

http://www.controlcase.com/es/managed_compliance_int_vulnerability_scan.html. 47 Norton by Symantec. [En línea] https://mx.norton.com/security_response/vulnerabilities.jsp

66

Escáner de Puerto: Es software diseñado para buscar en una red los puertos abiertos que

podrían ser usados por los atacantes como puntos de entrada.

Escáner de aplicaciones web: Permite identificar las vulnerabilidades en aplicaciones web

y así evitar ataques.

Escáner de Base de datos: Permite identificar vulnerabilidades en bases de datos.

3.7.3 TIPOS DE ESCANEOS

En base a la forma en que se realicen los escaneos se pueden clasificar en dos tipos:

Escaneo Interno: Se realiza dentro de la organización y está enfocado a los sistemas que

se encuentran dentro del perímetro de seguridad de la organización.

Escaneo Externo: Se realiza por un proveedor o desde un ambiente ajeno a la

organización con el fin de identificar las vulnerabilidades expuestas desde el punto de vista

de alguien externo.

La siguiente imagen muestra el escaneo de vulnerabilidades a los componentes:

Fig. 18 Escaneo de Vulnerabilidades

(Autoría propia)

67

3.7.4 EJEMPLOS DE SISTEMAS DE ESCANEO DE

VULNERABILIDADES MÁS USADOS

Nessus

Nmap

OpenVAS

3.8 ELECCIÓN DE SOLUCIONES DE SEGURIDAD PARA LA

PROPUESTA DE SOLUCIÓN

Usaremos En esta elección de tecnologías se ha buscado el uso de software libre de código

abierto, que sea fácil de implementar y amigable con el usuario.

3.8.1 NGINX

Usaremos Nginx debido a que es un servidor web y además podemos realizar otra instalación para

ser configurado como proxy inverso, es de código abierto, de bajo consumo de recursos, pero de

alto rendimiento, incluye servicios de correo electrónico y tiene la funcionalidad de balanceo de

carga entre los servidores back-end y proporcionar almacenamiento en caché para un servidor

back-end lo que permite reducir los tiempos de respuesta.

Las características adicionales que ayudan a tomar la determinación de realizar el uso de Nginx

son las siguientes:

Manejo de más de 10.000 conexiones concurrentes con un bajo consumo de memoria.

Alta tolerancia a fallos.

Soporte para TSL.

Compatible con IPv6.

Compresión y descompresión con Gzip, que permite comprimir al vuelo los archivos y

datos que se mueven por la red, desde el servidor web hasta el navegador del usuario.

68

Reescritura de urls, para crear urls amigables que nos ayuden en el proceso del

posicionamiento web.

Permite limitar el número de conexiones concurrentes.

La siguiente figura muestra el logo oficial de Nginx

Fig. 19 Logo Nginx

(Logo tomado de https://www.nginx.com/)

3.8.2 OPENLDAP

Al utilizar un LDAP logramos tenemos una autenticación centralizada, para realizar esto se usará

OpenLDAP ya que es una implementación libre y de código abierto del protocolo Lightweight

Directory Access Protocol. Un servidor LDAP no es más que un gestor de bases de datos

jerárquico, debido a esto permite realizar cientos de consultas simultáneas de forma eficiente ya

que es la operación más común.

Las características que ayudan a tomar la determinación de realizar el uso de OpenLDAP son las

siguientes:

Soporta mecanismos fuertes de autenticación y cuida la integridad de los datos.

Soporta la autenticación mediante certificados mediante el uso de TLS y SSL (Este último

en desuso)

Puede ser configurado para restringir el acceso a la capa de conexión en base a

información de la topología de red.

Se pueden generar listas de control de acceso (ACLs) para restringir el acceso a la

información contenida en el directorio.

69

Permite generar múltiples instancias en un mismo servidor para brindar servicios a

diferentes aplicaciones.

Es multi hilo ya que un solo proceso de LDAP maneja todas las peticiones lo que permite

reducir la carga de trabajo en el servidor donde se esté ejecutando.

Se puede configurar la replicación de datos con otra instancia de LDAP para los entornos

en los que se cuenta con un gran volumen de información.

Es de fácil configuración mediante un único archivo y es sumamente parametrizable.

La siguiente imagen muestra el logo oficial de OpenLDAP:

Fig. 20 Logo OpenLDAP

(Logo tomando de http://freecodelinux.blogspot.mx/2015/11/how-to-install-openldap-in-gnulinux.html )

3.8.3 SURICATA

Usaremos Suricata debido a que es un software libre, desarrollado para utilizar sistemas

multiprocesador lo que permite tener un buen rendimiento.

Las características que ayudan a tomar la determinación de realizar el uso de Suricata son las

siguientes:

Puede ser configurado como IPS o IDS

Multi hilo

Soporte para IPV6

Detección automática de protocolos

Soporte para la aceleración por GPU

Análisis avanzado de HTTP

70

Puede realizar análisis fuera de línea de archivos pcap

Se puede integrar con distintos firewalls

Ayuda a identificar de dónde provienen los ataques que se sufren.

Recoge evidencias que pueden ser usadas para identificar intrusos.

La posibilidad de detectar intrusiones desconocidas e imprevistas.

Menor costo de implementación y mantenimiento al ubicarse en puntos estratégicos de la

red.

La siguiente imagen muestra el logo oficial de Suricata:

Fig. 21 Logo Suricata

(Logo tomado de https://seguridadyredes.wordpress.com/2012/02/01/suricata-idsips-1-2-1-extraccion-de-ficheros-de-

sesiones-http-trafico-de-red/ )

3.8.4 OPNSENSE

OPNsense es un firewall y una plataforma de enrutamiento basados en FreeBSD de código

abierto, fácil de usar y fácil de construir. OPNsense incluye la mayoría de las funciones disponibles

en costosos firewalls comerciales, y más en muchos casos. Tiene un amplio conjunto de

características de las ofertas comerciales con los beneficios de las fuentes abiertas y verificables.48

48 Natali, Eduardo. 2014. Root Solutions. [En línea] 2014.

http://www.rootsolutions.com.ar/opnsense-firewall-utm-opensource-cuenta/.

71

Adicional a las funcionalidades de Firewall puede usarse como routers, puntos de acceso

inalámbrico, Servidores DHCP y DNS.

Las características que ayudan a tomar la determinación de realizar el uso de OPNsense son las

siguientes:

Permite la autenticación con dos factores para iniciar sesión en la administración del

sistema.

Se puede habilitar un portal cautivo para el inicio de sesión de los usuarios.

Proxy caché transparente con soporte para lista negra.

Tiene la opción de HA (High Availability) y hardware failover, para que en caso de caída de

un firewall automáticamente entre una vía alterna.

Soporta el estándar 802.1Q VLAN para segmentar la red adecuadamente.

Nota: Aunque OPNsense se puede configurar como IPS esa funcionalidad no la ocuparemos para

generar un punto único de falla.

La siguiente imagen muestra el logo oficial de OPNsense tomando del sitio de documentación del

mismo:

Fig. 22 Logo OPNsense

(Tomado del sitio web de documentación de OPNsense https://docs.opnsense.org/)

72

3.8.5 OPENVAS

OpenVAS (Open Vulnerability Assessment System) es una herramienta totalmente gratuita que nos

provee una solución para todo lo relacionado con el análisis de vulnerabilidades que pueda estar

presentando nuestro entorno tanto aplicativo como a nivel infraestructura.49

La base del funcionamiento de OpenVAS son los siguientes servicios:

Un servicio de escaneo para realizar los análisis de las vulnerabilidades.

Un servicio de interfaz gráfica de usuario.

Un servicio de administración que es el que interactuar con todos los módulos.

Las características que ayudan a tomar la determinación de realizar el uso de OpenVAS son las

siguientes:

Es capaz de realizar un escaneo de forma simultánea en varios equipos

Soporta el protocolo SSL

Podemos implementar escaneos programados

Podemos detener o reiniciar las tareas de escaneo en cualquier momento

Podemos administrar usuarios desde la consola

Soporta HTTP y HTTPS

Soporta multilenguaje

Multiplataforma

Reportes claros y completos

49 Wikipedia. [En línea] 2 de Noviembre de 2016. https://es.wikipedia.org/wiki/OpenVAS.

73

La siguiente imagen muestra el logo oficial de OpenVAS:

Fig. 23 Logo OpenVAS

(Tomado del sitio https://hackertarget.com/openvas-9-install-ubuntu-1604/)

3.9 ARQUITECTURA DE SEGURIDAD

El arquitecto es quien define y mantiene las relaciones entre los elementos, le da forma a la

estructura y define su propio funcionamiento. Ser un arquitecto es encontrarle el sentido a cada

unión de los componentes, entendiendo su función en conjunto, y encontrando la forma de

combinar diferentes puntos de vista de los participantes e interesados.50

Todo aquel que en seguridad de la información acepte el reto de ser un arquitecto, deberá de dejar

de enfocarse solo en la infraestructura tecnológica y ampliar su visión a todas las áreas de

negocio, no para alcanzar mayor reconocimiento corporativo, sino para aportar valor a la estrategia

corporativa, y transformando la estrategia de seguridad en una ventaja competitiva en un mercado

altamente cambiante.

Los arquitectos de seguridad de la información deben encontrar en la organización, el mejor

entorno para poner a prueba su entendimiento del negocio con el fin de diseñar con mayor detalle

los procesos y/o estructuras más adecuadas para anticiparse a los incidentes de seguridad de la

información.

En consecuencia, avanzar en una vista empresarial de la arquitectura de seguridad de la

información, es reconocer las capacidades del negocio, fuerzas y mecanismos anticipatorios, que

permitan proteger los flujos de información que alimentan la estrategia corporativa.

50 IT-Insecurity. [En línea] 14 de Febrero de 2011. http://insecurityit.blogspot.mx/2011/02/.

74

Es adquirir de los incidentes de seguridad el conocimiento requerido para generar las respuestas

de la organización frente a sus amenazas; Si bien existen múltiples formas de aproximarse al

diseño de una arquitectura de seguridad, es necesario considerar lo siguiente:

La información.

Las estrategias y metas de negocio.

Los fundamentos de seguridad.

La administración de los riesgos.

Estos cuatro elementos, revelan las necesidades propias de una organización frente al reto de

hacer de la información un activo valioso que debe ser protegido.

Debido a lo anterior, los arquitectos de seguridad de la información deberán compartir y alinear la

agenda interna de la alta gerencia, con la agenda interna del área de seguridad de la información,

no para estar enterados de los retos y ajustes empresarial, sino para afinar y ajustar sus acciones

frente a las amenazas empresariales del entorno y, cómo desde el entendimiento de los riesgos de

la información, generar escenarios predictivos y preventivos que custodien la forma como la

empresa genera valor para sus accionistas y empleados.

3.9.1 LA IMPORTANCIA DE CONTAR CON UNA ARQUITECTURA DE

SEGURIDAD

Esteban San Román en su artículo “La importancia de la arquitectura de seguridad” para la revista

Magazcitum describe la importancia de contar con una arquitectura de seguridad de la siguiente

manera:

“Durante mucho tiempo las organizaciones han sido más “reactivas” que “proactivas” en el

ámbito de la seguridad informática. La incorporación de elementos de seguridad se ha

dado en ocasiones por moda y en otros debido a la necesidad inminente de resolver

incidente.

75

En una misma organización se pueden encontrar diversas plataformas de diferentes

fabricantes haciendo que la infraestructura sea un cúmulo de tecnologías. Los recortes

presupuestales correspondientes a las tecnologías de información en las organizaciones

hace más difícil mantenerlas actualizadas y en funcionamiento, incluso pueden llevar a

hacer más compleja su operación.

En estos entornos se suele encontrar más de una plataforma que ofrece la misma

funcionalidad, por lo que el administrador deberá desarrollar un proceso sistematizado que

le permita evaluar las distintas opciones para elegir la que mejor se adecúe a sus

necesidades. En otros casos existen alternativas como los servicios administrados, que

pueden economizar los gastos asociados con el monitoreo, el manejo de incidentes y la

elaboración de reportes, adicional al costo de mantenimiento de infraestructura.

De acuerdo con lo anterior, esta estrategia de operación involucra la definición de un

modelo en la organización, en el cual se puede tener una infraestructura básica de

seguridad de la información con una inversión propia y complementarlo con un servicio

administrado (outsourcing) de monitoreo que correlacione todos los eventos de seguridad.

El modelo de arquitectura de seguridad define esta estrategia. El arquitecto de seguridad

comenzará por realizar un análisis de riesgos donde determinará tanto el grado de

exposición de la organización a amenazas como el balance adecuado de elementos y

servicios de seguridad requeridos. Para realizar este análisis de riesgos el arquitecto de

seguridad debe tomar en cuenta la normatividad aplicable a la organización y hacer

coincidir los objetivos de tecnología de información con los objetivos del negocio.”51

En base a lo anterior podemos identificar el rol tan importante que juega el arquitecto de seguridad

dentro de la organización ya que no solo es el responsable de implementar componentes de

seguridad, en caso de ser necesario puede participar el rediseño de un proceso de negocio con

miras a que sea más eficiente y seguro y siempre alineado a los objetivos del negocio para que de

esta forma tenga el respaldo de la dirección.

Cuando se habla de arquitectura de seguridad se incluyen muchas áreas de conocimiento, como

son las siguientes:

51 Román, Esteban San. 2010. Magazcitum. [En línea] 24 de Junio de 2010. http://www.magazcitum.com.mx/?p=409#.WVmZdYg19hE.

76

Desarrollo y administración de sistemas.

Aplicaciones de escritorio y puestos de trabajo.

Infraestructura de telecomunicaciones.

Repositorios de información.

Normatividad y legislaciones aplicables.

Gobierno de plataformas.

Por lo que Arquitectura de seguridad no se limita a elementos tan puntuales como lo pueden ser el

desarrollo de un sistema o la conformación de un grupo de trabajo.

Los siguientes pasos permiten definir una arquitectura de seguridad:52

Dejar de usar los valores por defecto: No está permitido hacer las instalaciones de los

productos de seguridad o de cualquier otro componente con los valores por defecto.

Decisiones sustentadas: Cada nuevo elemento o eliminación de un elemento de seguridad

en la arquitectura debe estar sustentada como mejora o depuración de alguna que haya

sido previamente acordada.

Dar acceso solo a lo necesario: Cuando en una arquitectura de seguridad se respeta el

que nada tenga más permisos de los necesarios, se disminuye la posibilidad de que en un

ataque se puedan elevar privilegios y con esto se acota el daño potencial que se pudiese

sufrir.

Diseño en capas: Una adecuada arquitectura de seguridad considera varias funciones de

seguridad operando en diferentes niveles, de manera que se evite manejar una sola

plataforma que, en caso de ser comprometida, deje expuestos los recursos de información.

52 Román, Esteban San. 2010. Magazcitum. [En línea] 24 de Junio de 2010.

http://www.magazcitum.com.mx/?p=409#.WVmZdYg19hE.

77

Asegurar la trazabilidad: Con el fin de tener elementos de mejora continua hay que

mantener historiales de todos los eventos de seguridad. Una de las primeras actividades

de un hacker al hacer una intrusión a un sistema es ocultar sus huellas. Es muy importante

desarrollar una estrategia de generación, protección y preservación de evidencias.

Flexibilidad: La arquitectura de seguridad de la información debe ser flexible y adaptable al

entorno cambiante y a las nuevas necesidades de la organización.

Adicionalmente, hay que tener en cuenta que una arquitectura de seguridad es tan robusta como

su eslabón más débil y que la tarea de fortalecer la arquitectura de seguridad es una tarea

constante. Hay que seguir informándose y mantener un sentido autocrítico con el fin de estar listo

para tomar las decisiones y realizar los ajustes más apropiados.53

No es tarea fácil materializar esta disciplina arquitectónica en los diseños actuales de seguridad de

la información, es un reto hacerlos realidad en las nuevas iniciativas, que permitan cambiar el

paradigma de “protección de información y aseguramiento del cumplimiento normativo”, por otro

donde la seguridad es parte de los modelos de negocio confiables y productivos y la información es

el eje fundamental de la relación con los clientes y los usuarios.

CIERRE CAPÍTULO 3

En este capítulo logramos identificar los controles de cloud computing que vamos a estar

abarcando en la propuesta de solución y la definición y funcionalidad de los componentes

necesarios para cubrir dichos requisitos. Realizamos la selección de los componentes de software

libre que utilizaremos para respaldar dicha propuesta, adicionalmente identificamos el rol de un

arquitecto de seguridad y el papel tan importante que juega dentro de una organización.

53 Román, Esteban San. 2010. Magazcitum. [En línea] 24 de Junio de 2010. http://www.magazcitum.com.mx/?p=409#.WVmZdYg19hE.

78

CAPÍTULO 4 PROPUESTA DE ARQUITECTURA DE SEGURIDAD PARA UNA

ORGANIZACIÓN

4.1 ARQUITECTURA DE LAS APLICACIONES

En esta propuesta de solución se indica el cambio de paradigma a la arquitectura basada en

servicios para desarrollar sistemas distribuidos escalables, flexibles y de fácil integración con

sistemas “legacy”. De este modo el consumidor del servicio no tiene por qué preocuparse por la

complejidad tecnológica, por ello se apuesta por el uso de APIs y todo lo que ello conlleva. Por lo

anterior usaremos las siguientes funcionalidades de una Arquitectura de Servicios:

Mediación

Gobierno

Monitorización

Seguridad

La siguiente imagen muestra las características del paradigma actual y las de Arquitectura de

Servicios.

Fig. 24 Cambio de Paradigma.

(Autoría propia)

Actualidad:

•Orientación a funciones

•Creado para durar

•Ciclos de desarrollo prolongados

•Silos de aplicaciones

•Fuerte acoplamiento

•Orientado a Objetos

• Implementación conocida

Arquitectura de Servicios:

•Oientación a procesos

•Creada para el cambio

•Desarrollo e implementación incremental

•Soluciones orquestadas

•Acoplamiento débil

•Orientado a mensajes

•Abstracto

79

La siguiente imagen muestra las características de los componentes que se usan en la

Arquitectura de servicios propuesta:

Fig. 25 Componentes de Arquitectura de Servicios.

(Autoría propia)

4.2 MODELO DE SEGURIDAD EN CAPAS

Para permitir que las aplicaciones sean seguras se propone el siguiente modelo de seguridad en

capas:

La capa de presentación se encarga de ofrecer los datos al consumidor de servicios en un

formato que dicho consumidor pueda entender.

La capa de servicios se encarga de proveer toda la infraestructura de servicios que

demandan los consumidores.

La capa de lógica de negocio se encarga de asegurar que las acciones realizadas por los

consumidores de servicios cumplan con las reglas del negocio.

La capa de datos se encarga de garantizar el correcto almacenamiento de los datos y de la

integridad, confidencialidad y disponibilidad de los mismos para el resto de capas.

•Lógica de Presentación y Navegación Front

•Funciones de Negocio

•Mediación con el Backend, control de acceso y monitorización

•Interfaz para desarrolladores Servicios

•Contiene la logica del negocio

•Los datos solo pueden ser accesados mediante servicios

•Plataforma orientada a tecnologias Open Source Backend

80

La siguiente figura muestra de manera gráfica el modelo en capas propuesto:

Fig. 26 Modelo en capas.

(Autoría propia)

Para poder controlar los servicios que se generan, se rehúsan o se eliminan es necesario contar

con un Gobierno de Servicios, las tareas que debe de realizar esta área son las siguientes:

Definir políticas y procedimientos

Establecer buenas prácticas

Fomentar estándares de diseño y seguridad

Plantear mejoras

Priorizar la reutilización de componentes

Establecer el ciclo de vida de un servicio y de la seguridad requerida

El área de gobierno de servicios debe de concentrar todas las peticiones de nuevos servicios

incluyendo las especificaciones de éstos, en base a esto se puede identificar si un servicio ya

existe para fomentar la reutilización del mismo.

BACKEND

Capa de Lógica de Negocio Capa de Datos

SERVICIOS

Capa de Servicios

FRONT

Capa de Presentación

81

Debe de considerar el correcto diseño de los servicios ya que tendrá que evaluar si es necesario

realizar la ampliación de funcionalidad de un servicio o si se debe de generar un nuevo servicio;

Adicionalmente debe de ajustar las normativas de diseño (En caso de ser necesario) o bien validar

la nomenclatura utilizada esto a favor de la estandarización.

Una tarea importante del Gobierno de servicios es la de autorizar el acceso al uso de servicios y la

forma en que esto se debe de realizar para llevar el control adecuado de los consumidores de

servicios.

Los servicios deben de tener las siguientes características:

Deben de soportar una función de Negocio

Deben de abstraer el Backend

Deben de tener un manejo adecuado de cambios

Se debe de generar documentación a nivel técnico, nivel funcional y de seguridad

Se debe de tener un monitoreo del servicio para conocer el uso y rendimiento del servicio

Los errores presentados en los servicios deben de tener las siguientes características:

Deben de contar con una estructura organizada

Deben de ser parametrizables

Debe de realizarse un monitoreo (tanto en línea como poder tener un registro histórico de

estos).

Deben de ser fácilmente localizables e identificables

Deben de estar centralizados

82

4.3 CICLO DE VIDA DE UN SERVICIO

El siguiente diagrama muestra el ciclo de vida de un servicio:

Fig. 27 Ciclo de vida de un servicio.

(Autoría propia)

Solicitud:

Estado inicial de un servicio, implica la aceptación del diseño y la construcción de un

servicio.

Análisis:

Enriquecimiento del servicio con información adicional.

Revisión:

Solicitud

Análisis

Revisión

Construcción Ejecución

Obsoleto

Eliminado

83

Revisión por parte de Gobierno de Servicios de la información proporcionada por el

solicitante de un servicio.

Construcción:

Construcción del servicio.

Ejecución:

Es un servicio que se encuentra disponible para ser consumido.

Obsoleto:

Es el servicio en el cual la funcionalidad expuesta ya no es necesaria y ya no cuenta con

mantenimiento.

Eliminado:

El servicio ya no está disponible para ser consumido.

Mediante el flujo anteriormente mencionado se pretende tener los siguientes objetivos:

Conocer cuando un servicio está disponible para su consumo

Contar con un método de organización que permita lo siguiente:

o Agilidad para el consumidor del servicio.

o Calidad y Eficiencia para quien desarrolla el servicio.

o Orden y Reutilización para el Gobierno del Servicio.

84

La siguiente figura muestra de manera gráfica el flujo que debe de seguir un servicio:

Fig. 28 Flujo de un Servicio.

(Autoría propia)

4.4 DISEÑO DE SERVICIOS

Con el fin de favorecer la homogeneidad y reutilización, así como promover el uso, los servicios

estarán diseñados conforme a unas pautas establecidas por el Gobierno de Servicios.

Las recomendaciones que emitan serán de ámbito funcional y de ámbito técnico, en función de la

naturaleza que contengan. Para facilitar el diseño de un servicio es necesario la creación de

documentación que sirva como referencia y guía rápida; Se debe de contar como mínimo con los

siguientes documentos:

“Diseño de Servicios”: Este documento debe de explicar de manera detallada todo lo

necesario para poder diseñar un servicio; Tanto el diseño técnico como el funcional.

“Líneas base de diseño de servicios”: En este documento se deben de explicar los puntos

fundamentales a tener en cuenta en el diseño de los servicios.

Diseño de Servicios

Construcción de Servicios

Consumo de Servicios

Evolución de un Servicio

85

“Guía rápida de diseño de servicios”: Se debe de contar con un documento que sirva de

guía rápida de diseño de servicios; Este documento permitirá localizar fácilmente los pasos

a seguir en función de las necesidades relacionadas con el diseño y gestión del ciclo de

vida de los servicios.

Las interfaces de los servicios deben estar normalizadas y estandarizadas, es por ello que se debe

de definir un Modelo de Datos que permite identificar las entidades más importantes de cada uno

de los aplicativos.

Del mismo modo que el punto anterior, se deben normalizar los errores funcionales con el objetivo

de que sean comunes a todos los aplicativos y más comprensibles y amigables para los usuarios.

Por último, se debe de definir una plantilla para ayudar en la definición de los servicios. Esta

plantilla se utilizará para comenzar a identificar los servicios y entidades implicadas y, por

último, será el resultado final del diseño y el punto de arranque para la fase de construcción de los

servicios por parte del desarrollador.

4.5 CONSTRUCCIÓN DE SERVICIOS

Una vez se tenga el diseño del servicio y que el mismo haya sido validado por Gobierno de

Servicios en base a las definiciones puesta en el Diseño de servicios se puede comenzar a

construirlo.

Es necesario al igual que en el punto anterior generar como mínimo la siguiente documentación de

referencia.

“Construcción de un servicio”: En este documento se debe de identificar y explicar las

pautas de construcción de Servicios.

“Guía rápida de construcción de Servicios”: Esta guía debe especificar desde un punto de

vista técnico, la estructura de los servicios, nomenclatura, etcétera. Así como todas las

funcionalidades de las que puede hacer uso el desarrollador para construir servicios.

86

“Gestión de errores”: Este documento debe de especificar el tratamiento, normalización y

estructura de los errores.

Se puede usar herramientas que faciliten la creación de servicios, el control del desarrollo o el

versionado de los mismos, en este caso dichas herramientas deben de estar alineadas a las

pautas marcadas en la guía de construcción de servicios.

4.6 CONSUMO DE SERVICIOS

Una vez diseñado y construido el servicio, éste se pone a disposición de las distintas aplicaciones.

Para poder consumir un servicio es necesario que sea autorizado por el gobierno de

proporcionando las credenciales suficientes para poder consumir dicho servicio.

Para identificar el servicio a consumir se debe de utilizar el Repositorio de Servicios. Del listado de

resultados habrá que tener en cuenta si los servicios que se quieren utilizar están disponibles en el

entorno que se requiere, a través de las estadísticas de monitorización disponibles en el repositorio

y el estado del ciclo de vida del servicio.

Todas estas consideraciones de consumo, deben de estar disponibles en un documento en este

caso se propone “Cómo consumir un servicio”.

4.7 EVOLUCIÓN DE UN SERVICIO

A lo largo de la vida de un servicio, éste va evolucionando y pasando por diferentes etapas:

análisis, diseño, revisión, etcétera. Durante todas estas etapas los servicios tienen que ser

gobernados.

Desde el momento en el que se está analizando un conjunto de funcionalidades que pueden dar

lugar a servicios hasta que se decide que dicho servicio no tiene sentido continuar siendo

consumido, bien porque existen versiones nuevas del servicio que hacen que la versión en

cuestión esté totalmente desactualizada o bien porque el servicio ha dejado de tener un público

objetivo.

87

Para poder seguir la evolución de un servicio se ha definido un Ciclo de Vida, en el que se han

identificado las diferentes etapas por las que atraviesa un servicio.

Asimismo, para poder saber cómo diferenciar las distintas versiones de un servicio, es necesario a

definir un proceso de cómo versionar un servicio y qué implicaciones tiene, y esto debe de estar

reflejado en el documento “Cómo versionar un servicio”.

4.8 ROBUSTECIENDO EL MODELO DE ARQUITECTURA DE

SERVICIOS

Como lo planteamos en los puntos anteriores las ventajas de estar en un esquema basado en

Arquitectura de Servicios como lo son la flexibilidad y la independencia que se puede alcanzar con

este modelo se puede robustecer aún más agregando una capa y esta es la capa de autenticación.

Al tener esta división y quitar la parte de autenticación de la aplicación se permite tener un control

centralizado de los usuarios (Para aplicaciones internas) o Clientes (Para aplicaciones expuestas a

clientes) de este modo el aplicativo deja de preocuparse por mantener un ABC (Altas, Bajas y

Cambios) de usuarios y solo se tiene que preocupar por recibir los parámetros que le proporciona

la capa de autenticación.

Al agregar esta nueva capa al modelo se logra poner un control adicional para el consumo de

servicios ya que como se mencionó en puntos anteriores solo la capa Front puede acceder a los

servicios y del mismo modo sólo la capa de autenticación va a permitir que sea consumida la capa

Front. La propuesta del modelo quedaría de la siguiente manera:

Capa 1 Autenticación

o Es la capa responsable de resolver las autenticaciones de clientes y usuarios.

Capa 2 Front

o Son responsables de la presentación y la lógica de navegación.

Capa 3 Capa de servicios

88

o La capa de servicios proporciona a las aplicaciones toda la funcionalidad

requerida, junto con los mecanismos de seguridad y control de acceso apropiados.

Capa 4 Backends

o En esta se encuentra la lógica de negocio; De este modo los Fronts únicamente

podrán acceder a los datos a través de la capa de servicios siempre y cuando el

usuario y/o cliente se encuentre autenticado proporcionando seguridad, flexibilidad

y elasticidad a la plataforma aplicativa de una organización.

La siguiente figura muestra de manera gráfica el modelo en capas propuesto anteriormente

sumando la capa de autenticación:

Fig. 29 Modelo de 4 capas.

(Autoría propia)

4.9 OPENSTACK COMO CAPA BASE DE INFRAESTRUCTURA

La mayoría de soluciones de infraestructura de nube o virtualización, (o la combinación de ambas)

pueden no satisfacer todas las necesidades de la organización. Con Openstack se paga menos

BACKEND

Capa de Lógica de Negocio Capa de Datos

SERVICIOS

Capa de Servicios

FRONT

Capa de Presentación

AUTENTICACIÓN

Clientes Usuarios

89

que por otras soluciones alternativas, funciona con la infraestructura existente y permite

implementar más opciones, así como controlar su despliegue alineado a la visión estratégica de la

organización, de este modo se puede crear y gestionar la nube privada al ritmo que lo requiere la

organización.

Openstack es una plataforma de cloud computing de código abierto que permite aprovechar la

infraestructura actual para implantar rápidamente una nube (cloud) privada y gestionarla con

seguridad.

Con el uso de Openstack logramos obtener las siguientes ventajas:

Flexibilidad.

Se elimina la dependencia de un proveedor.

Alto rendimiento y alta disponibilidad.

Gestión del ciclo de vida.

Confianza.

Seguridad integrada.

Gestión unificada.

El modelo de infraestructura como servicio (IaaS) permite contar con un modelo de

aprovisionamiento automático que permite a los usuarios generar infraestructura conforme a sus

necesidades o a la demanda de recursos que tengan, esto permite la continuidad de las

operaciones, el despliegue rápido de soluciones o el uso de alguna herramienta de la plataforma

en cuestión de minutos.

Se recomienda ampliamente el uso de Openstack ya que se tiene la certeza de contar con una

solución segura, sólida y estable que se encuentra abierta a la comunidad en la cual se puede

sumar funcionalidades diferentes o en su defecto contar con mucha documentación que permita

entender a detalle la plataforma y solucionar algún incidente que se llegara a presentar.

90

El futuro de la tecnología informática y de la infraestructura en general consiste en ofrecer servicios

de forma innovadora y con gran capacidad de respuesta, y las soluciones cloud desempeñar un

papel clave para realizar esto. Openstack es una solución diseñada para fomentar la innovación

con una plataforma de cloud flexible, modular y abierta.

La propuesta se centra en los siguientes componentes:

Capa de autenticación.

Segmentación de Red.

Detectando y Previniendo.

Uso de protocolos seguros.

Administración de logs.

Análisis periódico de vulnerabilidades.

Aplicación de Actualizaciones y remediación de vulnerabilidades

Definir un área de monitoreo.

91

La siguiente figura muestra el diseño general de la arquitectura de seguridad y la infraestructura y

los componentes que la conforman:

Capa de

Presentación

Capa de Servicios

Capa de Lógica de

negocios y acceso a

datos

Capa de

Autenticación

Fig. 30 Diagrama general de Arquitectura de seguridad de la infraestructura.

(Autoría propia)

4.10 DESCRIPCIÓN DE LA PROPUESTA DE ARQUITECTURA DE

SEGURIDAD DE LA INFRAESTRUCTURA

En los puntos anteriores hemos revisado la arquitectura propuesta de cómo se deben de

desarrollar las aplicaciones y el gobierno (Control) que se tienen de estas; En la siguiente sección

se emiten las recomendaciones para montar la infraestructura (Tanto Hardware como Software)

que soporten las aplicaciones, la propuesta de solución que se realiza está basada en software

“libre” (OpenSocurce).

92

4.10.1 CAPA DE AUTENTICACIÓN

La capa de autenticación está basada en el uso de Nginx como proxy inverso, este componente se

va a encargar de recibir todo el tráfico de internet (o en su defecto de la red interna) sin necesidad

de exponer los servidores donde residen las aplicaciones de este modo se vuelve una capa

adicional de seguridad; Adicionalmente debe de ser configurado para realizar la distribución de

cargas entre los servidores web y almacenar el contenido estático (Cache) como imágenes u otro

contenido gráfico para bajar la carga en los servidores web.

Para complementar el uso de Nginx se puede debe de configurar usando un OpenLDAP para que

sea el repositorio donde se encuentren los usuarios que pueden usar las aplicaciones, de este

modo es más sencillo llevar la administración de los usuarios ya que se deben de desarrollar

componentes que permitan el ABC (Altas, Bajas y Cambios) de usuarios y el resto de las

aplicaciones pueden consumir estas piezas sacado de este modo dicho componente de la

aplicación.

Para tener una segregación adecuada de los usuarios se debe de contar con un repositorio LDAP

para usuarios internos (Empleados) y otro LDAP para usuarios externos (clientes).

El diagrama de la capa de autenticación quedaría de la siguiente manera:

Capa de

Presentación

Capa de

Autenticación

Fig. 31 Capa de Autenticación.

(Autoría propia)

93

4.10.2 SEGMENTACIÓN DE RED

El siguiente punto en la propuesta de Arquitectura de Seguridad es la segmentación de red, con

esto se busca que el acceso a los componentes se encuentre restringido. La primera consideración

que se debe de tener es que si la organización tiene aplicaciones públicas expuestas a internet se

debe de implementar una DMZ o red perimetral que es una zona segura entre la red interna y la

red expuesta (Externa), esto permite que los equipos en DMZ protejan la red interna, ya que si esta

se ve comprometida no permitirá el acceso a la red interna. Esto se logra mediante la

implementación de un firewall.

Red InternaDMZ

Fig. 32 Segmentación de red.

(Autoría propia)

Adicional al uso de DMZ es necesario proteger el segmento de servidores del segmento de red de

usuarios esto nuevamente lo vamos a lograr mediante la implementación de un firewall, de este

modo se garantiza que únicamente los usuarios que se encuentran debidamente autorizados

pueden acceder (RDP, SSH, Telnet, etc.) a los servidores.

Segmento de

Servidores

Fig. 33 Segmento de servidores.

(Autoría propia)

94

Para la implementación del firewall se debe de usar OPNsense ya que es un completo sistema

operativo, de código abierto, y orientado a su uso como firewall que incorpora de manera gratuita

una gran cantidad de opciones de configuración que solo los firewalls comerciales más caros

tienen.

Las características de OPNsense que utilizaremos son las siguientes:

Network Address Translation (NAT)

Balanceo de carga y configuración de alta disponibilidad

Creación de DMZs

Módulo de monitoreo para generar gráficos del tráfico en tiempo real.

4.10.2.1 RESPONSABILIDADES GENERALES DEL ADMINISTRADOR

DE SEGURIDAD

Llevar el control de todas las conexiones a nivel de dispositivos de Seguridad, en un

diagrama de red y resguardo de los dictámenes emitidos que sustenten dicho diagrama,

así como la actualización en caso de migraciones o cambios significativos en la topología

de Seguridad de la red.

Dictar la configuración de los dispositivos de Seguridad (Firewalls, IPS) dentro de la

topología de red con el fin de proteger las conexiones en base a los estándares de

Seguridad y la segregación de redes, para esta tarea es imprescindible la coordinación con

las áreas de Seguridad e Infraestructura.

Generar procedimientos que permitan el mantenimiento de las políticas configuradas a

nivel de dispositivos de Seguridad (Firewalls, IPS), las cuales deberán tener actividad en

un periodo de 3 meses, cuando una política de firewall no tenga actividad en ese tiempo,

se debe deshabilitar la regla y su baja definitiva en el mes posterior.

Regular y autorizar todas las conexiones entre la organización y los terceros,

independientemente del tipo de enlace a través del estudio y análisis, lo cual se plasmará

95

en un dictamen basado en los principios de Integridad, Disponibilidad y Confidencialidad de

la información, que servirá para documentar a nivel técnico las soluciones de

comunicaciones, dicho dictamen también será referencia en la configuración de las reglas

en los dispositivos de Seguridad.

Analizará las funcionalidades de los protocolos definidos, sin embargo, debido a que un

atacante puede utilizar cualquier puerto con el fin de vulnerar un sistema, la definición de

puertos y servicios que se consideren inseguros quedará a criterio del Administrador de

Seguridad.

Generación y mantenimiento de “Estándar de configuración de firewall” el cual contendrá

los elementos mínimos necesarios que debe tener un firewall de la organización con el fin

de que se encuentre dentro de las mejores prácticas en Seguridad.

Establecer circuitos formales de solicitud, revisión, autorización en caso procedente y

puesta en producción de los cambios de configuración de los elementos de seguridad

perimetral.

4.10.2.2 RESPONSABILIDADES GENERALES DEL USUARIO FINAL

El usuario siempre deberá solicitar la comunicación cumpliendo con el dictamen generado

por el Administrador de Seguridad.

Cumplir con los procedimientos de solicitud de conexión previamente definidos por el

Administrador de Seguridad, con el fin de que la petición de conexión se documente de

forma adecuada.

4.10.2.3 SEGREGACIÓN DE REDES EN LA ORGANIZACIÓN

La siguiente sección describe las responsabilidades del administrador de seguridad en todo lo

referente a la segregación de red de la organización.

96

4.10.2.3.1 RESPONSABILIDADES DEL ADMINISTRADOR DE

SEGURIDAD

Segregación de todas las redes involucradas en los sistemas de la organización, de tal forma que

cumplan con las siguientes características:

Redes de acceso públicas: concentrarán conexiones contratadas con los proveedores de

internet (ISPs). Desde estas redes sólo se podrá acceder a redes desmilitarizadas (DMZ),

hacia estas redes la comunicación será a través de proxy, o en su caso servicios

específicos que tengan una justificación válida evaluada por el administrador para ser

configurada a través de Firewall.

Redes de acceso con terceros: Concentrarán conexiones privadas dedicadas con

proveedores y terceras empresas a través de Firewall.

Redes Desmilitarizadas (DMZ): Las redes desmilitarizadas son aquellas que, aun

encontrándose dentro de la compañía, están aisladas de las redes corporativas y cuyo

principal objetivo es ofrecer servicios del negocio accesibles desde Internet y que por su

naturaleza implican un alto riesgo.

Redes de servidores: Las redes de servidores son aquellas que contienen servidores con

lógica de negocio o datos reales; Los servidores deberán tener un tratamiento específico

diferente al de los puestos de trabajo de los usuarios y deberán dotarse de medidas de

control de acceso apropiadas. Se considerará la segregación en redes independientes de

los servidores que contengan los datos, en función de la criticidad de los mismos y de la

exposición de los servidores que contengan la lógica de negocio a vulnerabilidades que no

puedan ser bloqueadas mediante controles de acceso de red.

Redes de desarrollo y calidad (entornos previos): Son aquellas que agrupan sistemas

sobre los que se efectúan los desarrollos y pruebas de calidad previas a su puesta en

producción y que no deben tener interconexión con entornos de producción.

Redes de usuarios internos (Empleados): Las redes de usuarios son aquellas que agrupan

los puestos de trabajo de los usuarios internos. Su segregación permitirá ofrecer a cada

grupo de usuarios únicamente los servicios que necesitan, reduciendo el riesgo de

incidentes internos y reducir el alcance de incidentes.

97

4.10.2.4 SOLICITUD DE CONEXIONES EN INTERNET CON LA

ORGANIZACIÓN

La siguiente sección describe las responsabilidades del administrador de seguridad en todo lo

referente a las conexiones en internet con la organización.

4.10.2.4.1 RESPONSABILIDADES DEL ADMINISTRADOR DE

SEGURIDAD

Garantizar que todas las conexiones desde Internet hacia la red de la organización

sean únicas y exclusivamente a las definidas para esa función, llamadas

perimetrales. Para la definición de este tipo de comunicaciones debe existir, sin

excepción, un Firewall que permita a nivel de servicios las comunicaciones y un IPS

para el monitoreo de toda la actividad que se genere con el fin de que sea

monitoreada y evaluada en caso de posibles ataques hacia la Infraestructura de la

organización.

Garantizar que las conexiones hacia Internet vía WEB pasen a través de los equipos

proxy que tienen esa función los cuales están sujetos a su propia norma de

conexión, si el usuario requiere algún servicio distinto a WEB, deberá analizar la

viabilidad técnica de mandar esa conexión por firewall utilizando NAT.

Implementar controles que garanticen el monitoreo de Seguridad en los dispositivos

instalados en el perímetro de la red de la organización con Internet, con el fin de

detectar oportunamente posibles ataques informáticos hacia la Infraestructura.

Con el fin de que esta actividad sea lo más acertada posible, el Administrador de Seguridad deberá

implementar planes de respuesta a incidentes y procedimientos de obtención de Información,

realizar el análisis de dicha información y toma de decisiones en caso de contingencia que

declaren un incidente de Seguridad y contención inmediata o documentación de falsos positivos

con el fin de crear una base de conocimientos que permita la afinación de las herramientas de

monitoreo de Seguridad.

98

4.10.2.4.2 RESPONSABILIDADES DEL USUARIO FINAL

Respetar la asignación de privilegios otorgados para la Navegación en Internet, no

haciendo uso de programas o proxies que le permitan escalar dichos privilegios

ampliando las páginas a las cuales pueda ingresar.

Utilización de Navegadores WEB única y exclusivamente autorizados por el área de

seguridad

Si se requiere un enlace a Internet por puertos o servicios distintos a los definidos

para WEB, debe solicitar al Administrador de Seguridad, un análisis de la conexión y

apegarse al dictamen que dicho administrador genere, ya que la navegación WEB

hacia Internet desde cualquier punto de la red de la organización, será definida vía

proxy.

4.10.2.4.3 RESTRICCIONES

Queda prohibida la publicación de servicios desde Internet hacia equipos en redes de

usuarios.

Queda estrictamente prohibida la navegación utilizando técnicas de navegación de

anonimato.

La red Wifi que presta el servicio de Internet, debe estar totalmente aislada de

cualquier red interna de la organización, con el fin de proteger el acceso no deseado

desde la red inalámbrica. Además de que la red Wifi debe estar sujeta a autenticación

utilizando protocolos avanzados y dicha red protegida por un firewall.

Restricciones de uso de DMZ:

o No deberán contener datos etiquetados como confidenciales.

o Los equipos en DMZ estarán bastionados (Hardening) y serán actualizados dada

su exposición pública a terceros.

o Como protección mínima se emplearán firewalls para la segregación de las redes

desmilitarizadas (DMZ).

Los servicios que se pueden prestar en las redes DMZ, y por lo tanto los servicios habilitados en

los Firewalls son los siguientes:

99

Servicios Web

Servicios de servidor de terminales

Servicios específicos de proveedores de información

Servicios de infraestructura

o Proxy de navegación

o Proxy inverso

o Monitorización de conectividad

o Independientemente de su naturaleza, todos los elementos conectados a redes

DMZ deberán cumplir estrictamente los estándares de militarización y deberán

contar con un nivel de servicio para la actualización de software con motivo de la

aparición de vulnerabilidades de seguridad.

La conexión entre la red de usuarios y la DMZ perimetral siempre será en dicho

sentido, en caso de que por necesidad de un proyecto o servicio de negocio se

requiera en sentido inverso, deberá estar plenamente justificada y avalada por el

Administrador de Seguridad.

4.10.3 DETECTANDO Y PREVINIENDO (IPS/IDS)

Se debe de implementar un sistema IPS (Intrusion Prevention System) y un sistema IDS

(Intrusion Detection System) para aumentar la seguridad de nuestra red, vigilando el

tráfico, examinando y analizando los paquetes en busca de datos sospechosos o comportamientos

anómalos.

La principal diferencia entre un sistema y otro es el tipo de acción que llevan a cabo al detectar un

ataque ya sea mediante un análisis de red o un escaneo de puertos.

El Sistema de Detección de Intrusos (IDS) nos brinda una seguridad de tipo preventiva ya

que no está diseñado para detener ataques.

100

El Sistema de Prevención de Intrusos (IPS) nos brinda una seguridad de tipo reactiva ya

que permite identificar y detener ataques mediante la comunicación con otros dispositivos

de seguridad por ejemplo puede cerrar un acceso generando una política que sea aplicada

en un firewall.

Para solventar estos puntos se debe de usar Suricata, este sistema está basado en Snort y es

capaz de realizar análisis multihilo, de forma nativa decodificar flujos de red y ensamblar archivos

de secuencias de red mientras realiza el análisis, esto es muy valioso ya que no consume

demasiados recursos, en caso de ser necesario se puede habilitar para ejecutar varias instancias y

balanceo de carga de este modo no se presentan problemas de consumo de recursos mientras se

realiza el análisis o si aumenta la volumetría prevista.

Se debe de implementar Suricata en la parte externa de nuestra red para que trabaje en conjunto

con el firewall perimetral y también en el firewall que da acceso a la capa de servicios, de este

modo estaremos protegiendo las dos capas más importantes de nuestra arquitectura. El diseño

general de red quedaría de la siguiente manera:

Capa de

Presentación

Capa de Servicios

Capa de Lógica de

negocios y acceso a

datos

Capa de

Autenticación

Fig. 34 IPS e IDS.

(Autoría propia)

101

4.10.4 USO DE PROTOCOLOS SEGUROS Y BLOQUEO DE SERVICIOS

PROHIBIDOS.

Solo se permiten las versiones cifradas de los protocolos (Se prohíbe las versiones no cifradas de

los mismos); Siempre se debe utilizar el protocolo más seguro disponible.

La siguiente tabla muestra un resumen de los protocolos que son admitidos en la red:

Categoría Permitido No permitido

Acceso al navegador web HTTPS HTTP

Acceso a la línea de comandos SSH Telnet

Envío de correos SMTPS/IMAPS SMTP/IMAP

Transferencia de Archivos SFTP/SCP FTP

Cifrado de comunicaciones TLS SSL

Tabla. 1 Protocolos permitidos.

(Autoría propia)

La siguiente tabla muestra los servicios que se encuentran prohibidos en la red:

No. Puerto Descripción

20/21 TCP File Transfer Protocol (Protocolo de Transferencia de Archivos) Control y

Datos.

23 TCP TELNET: Conexión remota a equipos, sin encripción del medio.

79 TCP/UDP Finger, protocolo que proporciona información de los usuarios de una

máquina, estén o no conectados en el momento de acceder al servicio.

6881 TCP BitTorrent es un protocolo diseñado para el intercambio de archivos

punto a punto (peer-to-peer) en Internet.

5400, 5500, 5600, 5700, 5800, 5900 TCP VNC protocolo de escritorio remoto inseguro

Tabla. 2 Servicios prohibidos.

(Autoría propia)

102

4.10.5 ADMINISTRACIÓN DE LOGS

Todos los componentes de seguridad que hemos mencionado generan información, es decir tienen

un log, es necesario consolidar todos los logs generados en único repositorio centralizado de este

modo la explotación de la información que se genera es más fácil y nos permite identificar

comportamientos, patrones y en base a esto identificar más rápido algún evento de seguridad,

como por ejemplo intentos de acceso en un horario atípico, adicional a eso la información puede

ser usada para cumplimiento de auditorías o para reportes de uso y volumetría.

Esto es la base para que en el momento que la organización lo decida pueda adquirir una solución

de SIEM (Security Information and Event Management) estas soluciones permiten realizar un

análisis en tiempo real de los eventos reportados en los componentes de seguridad, correlacionar

eventos, generar reportes de cumplimiento y tener tableros (Dashboards) de control.

Capa de

Presentación

Capa de Servicios

Capa de Lógica de

negocios y acceso a

datos

Capa de

Autenticación

Fig. 35 Administración de logs.

(Autoría propia)

103

4.10.6 ANÁLISIS PERIÓDICO DE VULNERABILIDADES

No solo es necesario aprovisionar y configurar la infraestructura necesaria para dar servicio;

También es necesario realizar revisiones periódicas de las vulnerabilidades que se pueden llegar a

descubrir a lo largo del tiempo, dichas vulnerabilidades pueden ser explotadas por un atacante

para infiltrarse en la red ya sea para tomar control de los equipos, robar la información de la

organización o propagar algún malware, para reducir este riesgo es necesario establecer

calendarios para escaneos de vulnerabilidades que sean como mínimo de manera bimestral.

Se debe de usar OpenVAS (Open Vulnerability Assessment System), como herramienta de

escaneo de vulnerabilidades de uso libre para identificar y corregir fallas de seguridad. Las

funcionalidades que usaremos de la herramienta son las siguientes:

Escaneo concurrente de múltiples equipos.

Escaneo automático temporizado.

Módulo de reportes.

El escaneo de vulnerabilidades debe de realizarse a todos los componentes de la organización y

debe de generarse una excepción para los componentes de seguridad de la red para que no se

generen alertamientos.

104

El siguiente diagrama muestra la solución integrando el proceso de análisis de vulnerabilidades

mediante el uso de OpenVAS:

Capa de

Presentación

Capa de Servicios

Capa de Lógica de

negocios y acceso a

datos

Capa de

Autenticación

Fig. 36 Escaneo de Vulnerabilidades.

(Autoría propia)

4.10.7 APLICACIÓN DE ACTUALIZACIONES Y REMEDIACIÓN DE

VULNERABILIDADES

Las actualizaciones proporcionan revisiones para el equipo, agregan funcionalidades nuevas,

eliminan funcionalidades desactualizadas, actualizan controladores, proporcionan correcciones de

errores y, lo que es aún más importante, reparan vulnerabilidades detectadas ya sea en las

aplicaciones o en los sistemas operativos; Si no se realiza la tarea de actualizar los sistemas de

manera constante los atacantes aprovechan las debilidades que no han sido corregidas para robar

datos, tomar control del equipo u otros fines maliciosos.

105

Las actualizaciones deben de aplicar tanto a un servidor como al equipo de cómputo de un usuario

ya que esta última puede ser la puerta de entrada para un atacante; No todas las vulnerabilidades

se solventan mediante la aplicación de actualizaciones, en algunos casos es necesario realizar

ajustes en las configuraciones de las aplicaciones o los servicios (Por ejemplo, deshabilitar el

soporte para SSL en un servidor web).

Se debe de realizar un calendario de aplicación de actualizaciones donde las actividades se

realicen en un periodo no mayor a dos meses, el ideal es que las actualizaciones se realicen y

finalicen una semana antes de realizar el escaneo de vulnerabilidades mencionado en el punto

anterior.

4.10.8 DEFINIR UN ÁREA DE MONITOREO

Se debe de contar en la organización con un área o persona dedicada al monitoreo de seguridad

ya que de nada sirve implementar controles, tecnologías o alertamientos que no van a ser vistos.

El área de monitoreo debe de canalizar las alertas con los responsables de solventar la desviación

identificada o ejecutar algún proceso de corrección en caso de que este les sea proporcionado, es

necesario que se les proporcione una matriz de escalamiento (Debe de mantenerse actualizada)

para que puedan contactar a las áreas de soporte lo más rápido posible para minimizar los

impactos de cualquier incidente.

4.10.9 IMPLEMENTAR UN SISTEMA DE GESTIÓN DE LA SEGURIDAD

DE LA INFORMACIÓN (SGSI)

La siguiente sección de la propuesta de solución realiza una descripción general de ISO 27001 que

es la base para establecer un Sistema de Gestión de la Seguridad de la Información (SGSI), las

referencias fueron tomadas de la página de ISO 27001 http://www.iso27000.es/sgsi.html y no

pretende ser una descripción detalla.

Se debe de documentar todo lo referente los procesos de seguridad y que dicha documentación

esté referenciada en una normativa de la organización, la normativa es de carácter general y se

apoya en los procesos, dice el que de las cosas y los procesos dicen él como.

La norma ISO 27001 especifica los requisitos para establecer, implantar, documentar y evaluar un

Sistema de Gestión de la Seguridad de la Información (SGSI). La seguridad de la información,

106

según ISO 27001, consiste en la preservación de su confidencialidad, integridad y disponibilidad,

así como de los sistemas implicados en su tratamiento, dentro de una organización. 54

La siguiente figura muestra el “triángulo” de la seguridad de la información:

Fig. 37 Triada de la seguridad.

(Autoría propia)

Un Sistema de Gestión de la Seguridad de la Información (SGSI) es un enfoque sistemático para

establecer, implementar, operar, monitorear, revisar, mantener y mejorar la seguridad de la

información de una organización para conseguir los objetivos de negocio.

Se basa en una evaluación del riesgo y de los niveles de aceptación del mismo para que estos

seas gestionados de manera eficaz; Para que la aplicación de un Sistema de Gestión de la

Seguridad de la Información (SGSI) sea exitosa debe de considerar lo siguiente:

Analizar los requisitos de protección de los activos de la organización.

Aplicar controles para garantizar la protección de los activos de la organización.

Todo lo que sea implementado debe ser controlado y medido, lo que es controlado y medido debe

de ser administrado.

54 Portal de ISO 27001 en Español. [En línea] http://www.iso27000.es/sgsi.html.

Confidencialiad

Integridad Disponibilidad

107

Las principales ventajas del uso de un Sistema de Gestión de la Seguridad de la Información

(SGSI) son las siguientes:

Permite el establecimiento de una metodología de gestión de la seguridad clara y

estructurada.

Reducción del riesgo de pérdida, robo o corrupción de información.

Los clientes y usuarios tienen acceso a la información a través medidas de seguridad.

Los riesgos y sus controles son continuamente revisados.

Confianza de clientes y socios estratégicos por la garantía de calidad y

confidencialidad comercial.

Posibilidad de integrarse con otros sistemas de gestión

Garantiza la continuidad de las operaciones de negocio tras algún incidente.

Conformidad con la legislación vigente sobre información personal, propiedad

intelectual y otras.

Se vuelve un elemento diferenciador de la competencia.

Aumento de la seguridad en base a la gestión de procesos en vez de en la compra

sistemática de productos y tecnologías.

Los documentos que podemos obtener como resultado de la implementación de un Sistema de

Gestión de la Seguridad de la Información (SGSI) son los siguientes:

Política y objetivos de seguridad.

Alcance del Sistema de Gestión de la Seguridad de la Información (SGSI).

Procedimientos y controles que apoyan el Sistema de Gestión de la Seguridad de la

Información (SGSI).

Descripción de la metodología de evaluación del riesgo.

Informe resultante de la evaluación del riesgo.

108

Plan de tratamiento de riesgos.

Procedimientos de planificación, manejo y control de los procesos de seguridad de la

información y de medición de la eficacia de los controles.

Procedimiento de gestión de toda la documentación del SGSI.

Para establecer y gestionar un Sistema de Gestión de la Seguridad de la Información (SGSI) en

base a ISO 27001:2005, se utiliza el ciclo continuo PDCA, tradicional en los sistemas de gestión de

la calidad.

Plan (Planificar): Se realizan las evaluaciones de riesgos de seguridad de la información y

la selección de controles adecuados.

Do (Hacer): Esta fase tiene por objetivo realizar la implantación y operación de los

controles.

Check (Controlar): Esta fase tiene por objetivo revisar y evaluar el desempeño (eficiencia y

eficacia) del Sistema de Gestión de la Seguridad de la Información (SGSI).

Act (Actuar): Esta fase tiene por objetivo realizar cambios cuando sea necesario para llevar

de vuelta el de Gestión de la Seguridad de la Información (SGSI) a máximo rendimiento.

Fig. 38 Mejora continua.

(Autoría propia, en base al modelo mostrado en el ISO 27001)

•Monitorear y revisar el SGSI

• Implementar y operar el SGSI

•Manteber y mejorar el SGSI

•Establecer el SGSI

Plan Do

Check Act

109

Las principales tareas para el establecimiento de un Sistema de Gestión de la Seguridad de la

Información (SGSI) dentro de cada fase de la mejora continua son las siguientes:

Plan:

Involucrar a la Dirección (Sin el apoyo de esta no se van a lograr resultados).

Definir el alcance del Sistema de Gestión de la Seguridad de la Información (SGSI).

Definir políticas de seguridad.

Definir una metodología de evaluación de riesgos.

Realizar un inventario de los activos.

Identificar amenazas y vulnerabilidades.

Identificar impactos.

Realizar un análisis y evaluación de riesgos.

Do:

Definir e implantar un plan de tratamiento de riesgos.

Implementar controles.

Realizar campañas de formación y concientización.

Operar el Sistema de Gestión de la Seguridad de la Información (SGSI).

Check:

Revisar el Sistema de Gestión de la Seguridad de la Información (SGSI).

Medir la eficacia de los controles.

Revisar los riesgos residuales.

110

Realizar auditorías internas del Sistema de Gestión de la Seguridad de la Información

(SGSI).

Act:

Implantar mejoras.

Realizar acciones preventivas y correctivas.

Comprobar la eficacia de las acciones.55

Como se mencionó anteriormente este apartado no pretende ser una descripción detallada de ISO

27001, solo es la recomendación del uso de esta norma y una visión general de la misma, en caso

de requerir mayor detalle respecto a este se puede consultar en la página oficial de ISO, la URL es

la siguiente: https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-2:v1:en

55 Portal de ISO 27001 en Español. [En línea] http://www.iso27000.es/sgsi.html.

111

CONCLUSIÓN

Toda la infraestructura que se menciona en esta propuesta de solución puede ser aprovisionada

desde Openstack de este modo tendremos un esquema de nube privada que nos permite escalar

los recursos en funciones de las necesidades y demandas de la organización inclusive si en algún

determinado momento es necesario migrar el modelo a una nube privada (Como Amazon o

Google) esto se podría realizar sin problema inclusive el modelo se conserva, es escalable y puede

ser robustecido gracias a los servicios que cada proveedor puede ofrecer, en el caso de esta

propuesta todo está basado en el uso de “Software Libre” para no generar dependencia de ningún

fabricante y pensando en no incrementar los costos debido a licenciamiento.

Como se puede observar en esta propuesta de solución no es necesaria una fuerte inversión de

recursos para implementar una Arquitectura de Seguridad y es algo que se puede implementar de

manera gradual, se puede tener un proyecto a largo plazo que se divida en varias fases y al final

de cada una de estas se tenga un entregable que permita evaluar la efectividad de lo

implementado.

Adicionalmente es necesario contar con el apoyo de la dirección y sobre todo concientizar al

usuario para que no vea la implementación de mecanismos de control como una forma de

entorpecer el trabajo, la mejor seguridad es la que no se ve ya que al ser transparente no se

contara con renuencia a un cambio en la forma de hacer las cosas. La seguridad está para

proteger los intereses de la organización dando un valor agregado a los servicios que se ofrecen,

esto se puede tomar como un diferenciador ante los competidores ya que refleja el grado de

compromiso, orden y cumplimento que puede tener la organización.

El mundo tecnológico se encuentra en cambio constante, se generan nuevas aplicaciones o

tecnologías que cambian la manera de realizar las cosas, del mismo modo la seguridad se

encuentra en evolución constante, no se puede alcanzar un estado final ya que el entorno se

transforma y este proceso de transformación debe de ir acompañado por la seguridad.

Todas las implementaciones de controles tecnológicos de seguridad deben de estar basados en

procesos, en este caso la implementación de un Sistema de Gestión de la Seguridad de la

Información nos ayuda a que todo el modelo este soportado mediante el uso de una metodología

ampliamente utilizada por las organizaciones; El modelo de gestión de la seguridad contempla los

procedimientos adecuados y la planificación e implantación de controles de seguridad basados en

una evaluación de riesgos y en una medición de la eficacia de los mismos. Adicionalmente ayuda a

112

establecer políticas y procedimientos en relación a los objetivos de negocio de la organización, con

objeto de mantener un nivel de exposición menor al nivel de riesgo que la propia organización ha

decidido asumir. La siguiente tabla muestra a manera de resumen los servicios de seguridad de un

entorno cloud y cómo se están cumpliendo:

Servicios de Seguridad Forma de Cumplimiento Objetivos Específicos

Gestión de Identidades y Accesos

SGSI Nginx OpenLDAP

Garantizar la protección de las aplicaciones Luchar contra la suplantación y otros fraudes que se producen en Internet. Reducir los tiempos de desarrollo de la aplicación al evitar “preocuparse” por el desarrollo del módulo de autenticación de usuarios.

Seguridad Web

SGSI Arquitectura de Servicios Nginx OpenLDAP

Garantizar la protección de las aplicaciones

Evaluación de la Seguridad

SGSI Área de Monitoreo Aplicación de Actualizaciones y remediación de vulnerabilidades OpenVas

Garantizar la protección de las aplicaciones

Gestión de la Intrusión SGSI Área de Monitoreo Suricata

Minimizar el riesgo de posibles intrusiones no autorizadas o compromiso de la información

Gestión de la Información de Seguridad y Gestión de eventos

SGSI Administración de logs

Garantizar la protección de las aplicaciones. Minimizar el riesgo de posibles intrusiones no autorizadas o compromiso de la información. Incrementar la confianza de clientes. Luchar contra la suplantación y otros fraudes que se producen en Internet. Diseñar una arquitectura de seguridad que sea estándar para cualquier aplicación WEB.

Seguridad de las Redes

SGSI Área de Monitoreo OpnSense Suricata

Minimizar el riesgo de posibles intrusiones no autorizadas o compromiso de la información

Tabla. 3 Resumen de cumplimiento.

(Autoría propia)

113

TRABAJOS FUTUROS

Como se mencionó anteriormente la tecnología está en un proceso de cambio constante al igual

que la seguridad que se debe de brindar para dicha tecnología, como siguientes pasos está el uso

de la mejora continua para asegurarse que la arquitectura de seguridad propuesta continua vigente

y logrando los objetivos planteados, en caso de que no sea así se tendrá que evaluar si puede

continuar con la misma o si es necesario un rediseño o en su defecto implementar algún

componente adicional que le permita seguir en funcionamiento, los ataques y las amenazas a la

organizaciones no se detienen y al contrario cada día son más constantes por lo tanto es mejor

estar preparado y planear para lo peor ya que de este modo se logra anticiparse a estos eventos

de seguridad.

114

GLOSARIO.

Sistemas Legacy: También es conocido como un sistema heredado y es aquel que ha sido

desarrollado con tecnología obsoleta y que no requiere cambio en su funcionamiento pero que

sigue siendo ampliamente usado por los usuarios, al ser “anticuados” presentan muchas

dependencias de la infraestructura en la que se ejecutan por lo cual es difícil por no decir imposible

migrarlos a una nueva tecnología.

Ataque informático: Son acciones diseñadas para causar daños o evitar el uso de redes, sistemas

o aplicaciones por medio de sobreexplotar los recursos informáticos como las unidades de

procesamientos o el ancho de banda de las redes.

DMZ: Se ha definido como redes desmilitarizadas aquellas con perímetro común y flujos de

comunicación con redes de acceso públicas. Los sistemas pertenecientes a este perímetro son los

que ofrecen servicios, por lo general, a través de Internet y en caso de un ataque no deben permitir

la propagación del mismo hacia la red interna.

ISP: Internet Service Provider: Empresa encargada de brindar el servicio de conexión a Internet.

Segregación: Separación de redes en función de los servicios que presta cada una de ellas, por lo

general están separadas por ruteo o por Firewall.

NAT: Traducción de direcciones IP: Mecanismo utilizado para proporcionar comunicaciones entre

redes que no se conocen por ruteo.

BPM: Business Process Management es una metodología corporativa y disciplina de gestión, cuyo

objetivo es mejorar el desempeño (eficiencia y eficacia) y la optimización de los procesos de

negocio de una organización, a través de la gestión de los procesos que se deben diseñar, modelar,

organizar, documentar y optimizar de forma continua.

Middleware: Hace referencia a una capa de software que ayuda a una aplicación para interactuar o

comunicarse con otras aplicaciones, hardware y/o sistemas operativos. Ésta capa permite

simplificar el trabajo de los programadores en la compleja tarea de generar las conexiones y

sincronizaciones que son necesarias en los sistemas distribuidos.

115

BIBLIOGRAFÍA

Alliance, Cloud Security. 2011. cloudsecurityalliance.org. [En línea] 2011.

https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf.

Amazon. Amazon Web Services. [En línea] https://aws.amazon.com/es/.

Blanquer, Manuel Agudo. 2015. Openwebinars. [En línea] 14 de Mayo de 2015.

https://openwebinars.net/blog/tipos-de-cloud-computing/.

CCM. 2017. CCM Protocolo LDAP. [En línea] Mayo de 2017. http://es.ccm.net/contents/269-

protocolo-ldap.

Center, IBM Knowledge. IBM Knowledge Center. [En línea]

https://www.ibm.com/support/knowledgecenter/es/SSKTXQ_8.5.0/com.ibm.help.sametime.v85.

doc/config/st_adm_port_rvprxy_overview_c.html.

CISCO. CISCO Firewall. [En línea]

http://www.cisco.com/c/es_mx/products/security/firewalls/what-is-a-firewall.html.

Cloud Security Alliance. 2011. SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD

COMPUTING V3.0. United States : Cloud Security Alliance, 2011.

Cloud Security Services. 2012. Cloud Security Services. [En línea] 06 de Octubre de 2012.

http://blog.svtcloud.com/secaas-o-seguridad-como-servicio-no-solo-para-las-grandes-empresas/.

Control Case. Control Case Managed Compliance. [En línea]

http://www.controlcase.com/es/managed_compliance_int_vulnerability_scan.html.

Cruz, Victoria Martínez de la. 2013. En pocas palabras: ¿Cómo funciona Openstack? [En línea] 1 de

Febrero de 2013. http://vmartinezdelacruz.com/en-pocas-palabras-como-funciona-Openstack/.

EcuRed. EcuRed. [En línea] https://www.ecured.cu/Arquitectura_Cliente_Servidor.

Google. Google Cloud Platform. [En línea] https://cloud.google.com/?hl=es.

IBM. Arquitectura orientada a servicios (SOA): simplemente, un buen diseño. [En línea]

https://www-01.ibm.com/software/es/solutions/soa/.

itechcareer. blog.itechcareer.com. [En línea]

http://blog.itechcareer.com/index.php?option=com_content&view=article&id=39:icual-es-la-

diferencia-entre-un-modelo-tradicional-de-computacion-y-una-infraestructura-en-

nube&catid=17:tecnologia.

IT-Insecurity. 2011. IT-Insecurity. [En línea] 14 de Febrero de 2011.

http://insecurityit.blogspot.mx/2011/02/.

116

LANSA. Integración de Aplicaciones y Procesos de Negocio. s.l. :

http://www.lansa.com/es/products/integration.htm.

Microsoft. Microsoft Azure. [En línea] https://azure.microsoft.com/es-mx/.

Natali, Eduardo. 2014. Root Solutions. [En línea] 2014.

http://www.rootsolutions.com.ar/opnsense-firewall-utm-opensource-cuenta/.

Norton by Symantec. https://mx.norton.com/security_response/vulnerabilities.jsp. [En línea]

https://mx.norton.com/security_response/vulnerabilities.jsp.

Openstack. Openstack. [En línea] https://www.Openstack.org/.

Openstack. 2017. Openstack Block Storage. [En línea] 27 de 04 de 2017.

https://docs.Openstack.org/admin-guide/blockstorage.html.

2017. Openstack Compute. [En línea] 27 de 04 de 2017. https://docs.Openstack.org/admin-

guide/compute.html.

2017. Openstack Dashboard. [En línea] 27 de 04 de 2017. https://docs.Openstack.org/admin-

guide/dashboard.html.

2017. Openstack Identity management. [En línea] 27 de 04 de 2017.

https://docs.Openstack.org/admin-guide/identity-management.html.

2017. Openstack Image. [En línea] 27 de 04 de 2017. https://docs.Openstack.org/admin-

guide/image.html.

2017. Openstack Networking. [En línea] 27 de 04 de 2017. https://docs.Openstack.org/admin-

guide/networking.html.

2017. Openstack Object Storage. [En línea] 27 de 04 de 2017. https://docs.Openstack.org/admin-

guide/objectstorage.html.

Oriol. 2015. https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-

cloud-computing-saas-paas-y-iaas/. [En línea] 7 de Junio de 2015.

https://computernewage.com/2015/06/07/todo-lo-que-necesitas-saber-sobre-el-cloud-

computing-saas-paas-y-iaas/.

Portal de ISO 27001 en Español. [En línea] http://www.iso27000.es/sgsi.html.

Red Hat. 2005. Red Hat Enterprise Linux 4: Manual de referencia. [En línea] 2005.

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/ch-ldap.html.

Román, Esteban San. 2010. Magazcitum. [En línea] 24 de Junio de 2010.

http://www.magazcitum.com.mx/?p=409#.WVmZdYg19hE.

117

Salesforce. Salesforce . [En línea] https://www.salesforce.com/mx/cloud-computing/.

SecaaS (Security as a Service): ¿Está listo? CISA, David Gutiérrez. CISSP y. 2010. [ed.] Magazcitum.

08 de Octubre de 2010, Magazcitum.

Sommerville, Ian. 2005. Ingeniería del software. Ingeniería del software. Madrid : Pearson, 2005.

Universidad CAECE. Universidad CAECE. [En línea] https://sistemasdistribuidos2012-

caece.wikispaces.com/Arquitectura+de+Sistemas+Distribuidos+-+Parte+I.

Wikipedia. 2017. Wikipedia. [En línea] 7 de Febrero de 2017.

https://es.wikipedia.org/wiki/Sistema_de_prevenci%C3%B3n_de_intrusos.

2017. Wikipedia. [En línea] 15 de Marzo de 2017.

https://es.wikipedia.org/wiki/Sistema_de_detecci%C3%B3n_de_intrusos.

2016. Wikipedia. [En línea] 2 de Noviembre de 2016. https://es.wikipedia.org/wiki/OpenVAS.

118

ANEXO I INSTALACIÓN BÁSICA DE OPENSTACK EN FEDORA

1.- Para poder realizar la instalación de Openstack es necesario generar el usuario “stack” con el

comando “useradd”, como lo muestra la siguiente imagen:

sudo useradd stack

Fig. 1 Agregar usuario

2.- Se debe de asignar un password al usuario “stack” con el comando “passwd”, como lo muestra

la siguiente imagen:

sudo passwd stack

Fig. 2 Asignar password a usuario

119

3.- Se deben de agregar privilegios de administrador al usuario “stack” con el comando “visudo”,

como lo muestra la siguiente imagen:

sudo visudo

Fig. 3 Comando visudo

Se muestra en la pantalla el archivo para editar, agregamos la línea mostrada a continuación, como lo

muestra la siguiente imagen:

stack ALL=(ALL) NOPASSWD: ALL

Fig. 4 Asignación de privilegios

120

4.- Se debe de iniciar sesión con el usuario “stack”, como lo muestra la siguiente imagen:

Fig. 5 Inicio de sesión

5.- Se debe de instalar “git” (En caso de no tenerlo instalado en la distribución) con el comando

“yum –y install git”, como lo muestra la siguiente imagen:

sudo yum -y install git

Fig. 6 Instalación de git

121

6.- Se debe de ingresar al directorio “/var” con el comando “cd”, como lo muestra la siguiente

imagen:

cd /var

Fig. 7 Directorio var

7.- Se debe de clonar el repositorio “git” con el comando “git clone”, como lo muestra la siguiente

imagen:

sudo git clone git://github.com/Openstack-dev/devstack.git

Fig. 8 Git clone

122

8.- Se deben de ajustar los permisos de los directorios generados tras clonar el repositorio “git” de

Openstack con el comando “chwon”, como lo muestra la siguiente imagen:

sudo chown -R stack:stack /var/devstack

Fig. 9 Ajuste de permisos

9.- Se debe configurar el archivo “local.conf” con las credenciales y parámetros de red.

Se debe de crear el archivo “localrc.localrc” en la ruta “/var/devstack”, en el directorio “samples” se

encuentra un ejemplo del archivo, lo copiamos con el comando “cp”, como lo muestra la siguiente

imagen:

cp /home/stack/devstack/samples/local.conf /home/stack/devstack/local.conf

Fig. 10 Copia de archivo de configuración

123

10. Consultamos los parámetros de red definidos en el equipo con el comando “ifconfig”, como lo

muestra la siguiente imagen:

Ifconfig -a

Fig. 11 Parámetros de red

11. Editamos el archivo “local.conf” que copiamos en el punto 9 y agregamos los siguientes valores

al final:

HOST_IP=10.0.2.15

FLAT_INTERFACE=eth0

FLOATING_RANGE=10.0.2.224/28yum

ADMIN_PASSWORD=c0ntr4s3n4

DATABASE_PASSWORD= c0ntr4s3n4

RABBIT_PASSWORD= c0ntr4s3n4

SERVICE_PASSWORD= c0ntr4s3n4

SERVICE_TOKEN= c0ntr4s3n4

En donde:

HOST_IP: Es la dirección IP de nuestro equipo.

FLAT_INTERFACE: Es la interfaz de red de nuestro equipo.

124

FLOATING_RANGE: Es el rango de direcciones IPs que utilizaran los equipos generados

en Openstack.

ADMIN_PASSWORD: Es la contraseña del usuario administrador.

MYSQL_PASSWORD: Es la contraseña del usuario administrador de MySQL

RABBIT_PASSWORD: Es la contraseña del usuario administrador de rabbit

SERVICE_PASSWORD: Es la contraseña del usuario administrador

SERVICE_TOKEN: Es la contraseña para el servicio de token

La siguiente imagen muestra cómo queda el archivo “local.conf”:

Fig. 11 Parámetros de red

10.- Ingresar al directorio “/var/devstack” y ejecutar el archivo “stack.sh”, como lo muestra la

siguiente imagen:

./stack.sh

Fig. 12 Ejecución stack.sh

125

11.- Comienza el proceso de instalación, es un proceso que puede llegar a tardar más de 50

minutos, la siguiente imagen muestra un ejemplo del proceso de instalación:

Fig. 13 Progreso de instalación

11.- Al finalizar la instalación se muestran las urls y la versión de Openstack que fue instalada en el

sistema, como lo muestra la siguiente imagen:

Fig. 13 Fin de instalación

126

12. Para ingresar a la consola de administración ingresamos desde un navegador a la url de

“Dashboard” mostrada en el punto anterior, en este caso “http://10.0.2.15/dashboard”, se mostrará

la página de login, como lo muestra la siguiente imagen:

Fig. 14 Login Openstack.

13. Ingresamos con el usuario “admin” y la contraseña que definimos para que nos muestre

Dashboard (consola de administración), como lo muestra la siguiente imagen:

Fig. 13 Dashboard

127

ANEXO II INSTALACIÓN DE NGINX EN UBUNTU

1.- Se debe de instalar los paquetes de “nginx” con el siguiente comando, como lo muestra la

siguiente imagen:

sudo apt-get install nginx

Fig. 1 Progreso de instalación

2.- Se debe de habilitar el uso de https en el firewall del equipo con el siguiente comando, como lo

muestra la siguiente imagen:

sudo ufw allow 'Nginx HTTPS'

Fig. 2 Habilitar https

128

3.- Se puede validar la correcta aplicación con el siguiente comando, como lo muestra la siguiente

imagen:

sudo ufw status

Fig. 3 Validar estatus

4.- Para validar que el proceso se encuentre activo usamos el siguiente comando, como lo muestra

la siguiente imagen:

systemctl status nginx

Fig. 4 Validar el proceso

129

5.- Para ingresar a la aplicación usamos el siguiente comando, como lo muestra la siguiente

imagen:

http://10.0.2.15

Fig. 4 Ingresar a nginx

130

ANEXO III INSTALACIÓN DE OPENLDAP EN UBUNTU

1.- Se debe de instalar los paquetes de “OpenLDAP” con el siguiente comando, como lo muestra

la siguiente imagen:

sudo sudo yum -y install slapd ldap-utils

Fig. 1 Descarga de paquetes.

2.- Después de la descarga de los paquetes se solicita una contraseña para el usuario

administrador del LDAP, ingresamos la contraseña, como lo muestra la siguiente imagen:

Fig. 2 Contraseña de administrador

131

3.- El asistente de instalación nos solicita nuevamente la contraseña, como lo muestra la siguiente

imagen:

Fig. 3 Confirmación de contraseña.

4.- Después de confirmar los datos continúa el proceso de instalación y al final nos regresa el

prompt, como lo muestra la siguiente imagen:

Fig. 4 Final de la instalación.