INSTITUTO POLITÉCNICO NACIONAL148.204.210.201/tesis/1506976094517TesisPropuesta.pdfA mi director de...
Transcript of INSTITUTO POLITÉCNICO NACIONAL148.204.210.201/tesis/1506976094517TesisPropuesta.pdfA mi director de...
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.