Add security segregation usecase
Change-Id: I5a1ff68e3dc89ef9cda07ac80c7d75dcca5e1d03
This commit is contained in:
Daniel Schabarum
parent
40eb43b886
commit
e8e502e5b6
195
usecases/sec_segregation.rst
Normal file
195
usecases/sec_segregation.rst
Normal file
@ -0,0 +1,195 @@
|
|||||||
|
..
|
||||||
|
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
..
|
||||||
|
|
||||||
|
======================================
|
||||||
|
Security Segregation (Placement Zones)
|
||||||
|
======================================
|
||||||
|
|
||||||
|
The goal of this use-case is to present the need for a (partly) segregation
|
||||||
|
of physical resources to support the well-known classic separation of DMZ
|
||||||
|
and MZ, which is still needed by several applications (VNFs) and requested
|
||||||
|
by telco security rules.
|
||||||
|
|
||||||
|
Glossary
|
||||||
|
========
|
||||||
|
|
||||||
|
**AZ**
|
||||||
|
Availability Zone (OpenStack terminology)
|
||||||
|
|
||||||
|
**DMZ**
|
||||||
|
Demilitarized Zone provides access to the public network,
|
||||||
|
but adds an additional security layer (e.g. virtual firewall). Designed for
|
||||||
|
security critical customer facing services (e.g. customer control center).
|
||||||
|
|
||||||
|
**EHD**
|
||||||
|
Exposed Host Domain provides direct access from the public network (e.g.
|
||||||
|
Internet).
|
||||||
|
Designed for services which require a high traffic volume (e.g. CDN) and are
|
||||||
|
not security critical.
|
||||||
|
|
||||||
|
**MZ**
|
||||||
|
Militarized Zone is a logical network without any access from the public
|
||||||
|
network. Designed for systems without direct customer connectivity (e.g.
|
||||||
|
databases containing sensitive data) and high security demands.
|
||||||
|
|
||||||
|
**PZ**
|
||||||
|
Placement Zone is a concept to classify different securiy areas based on
|
||||||
|
different security requirements. PZ are separated on a per host basis.
|
||||||
|
|
||||||
|
**SEC**
|
||||||
|
Secure Network Zone for all devices providing a security function including
|
||||||
|
devices providing connectivity between Placement Zones (e.g. virtual firewall
|
||||||
|
for DMZ-MZ traffic).
|
||||||
|
|
||||||
|
**VNF**
|
||||||
|
Virtual Network Function is an implementation of an functional building block
|
||||||
|
within a network infrastructure that can be deployed on a virtualization
|
||||||
|
infrastructure or rather an OpenStack based cloud platform (a non virtualized
|
||||||
|
network function is today often a physical appliance).
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
The main driver therefore is that a vulnerability
|
||||||
|
of a single system must not affect further critical systems or endanger
|
||||||
|
exposure of sensitive data. On the one side the benefits of virtualization
|
||||||
|
and automation techniques are mandatory for telcos but on the other side
|
||||||
|
telecommunication data and involved systems must be protected by the
|
||||||
|
highest level of security and comply to local regulatory laws (which are
|
||||||
|
often more strict in comparison with enterprise).
|
||||||
|
Placement Zones should act as multiple lines of defense against a security
|
||||||
|
breach. If a security breach happens in a placement zone, all other
|
||||||
|
placement zones and related VNFs must not be affected. This must be ensured
|
||||||
|
by the design.
|
||||||
|
This use case affects all of the main OpenStack modules.
|
||||||
|
|
||||||
|
Current Situation
|
||||||
|
-----------------
|
||||||
|
Today the DMZ and MZ concept is an essential part of the security design
|
||||||
|
of nearly every telco application deployment. Today this separation is
|
||||||
|
done by a consequent physical segregation including hosts, network and
|
||||||
|
management systems. This separation leads to high investment and
|
||||||
|
operational costs.
|
||||||
|
|
||||||
|
Enable the following
|
||||||
|
--------------------
|
||||||
|
Placement Zones should be used to reduce the risk that the whole cloud platform
|
||||||
|
is affected by a serious security breach.
|
||||||
|
|
||||||
|
If the hypervisor is breached, there is a risk to all of the VNFs on that
|
||||||
|
hypervisor. To reduce this risk, a physical separation of VMs not assigned to
|
||||||
|
the same security class is necessary. Placement Zones should be used to ensure
|
||||||
|
that only VMs following the same security classification will run on the same
|
||||||
|
group of physical hosts.
|
||||||
|
This should avoid a mix of VMs from different zones (e.g. DMZ and MZ),
|
||||||
|
coming up with different security requirements, running on the same group
|
||||||
|
of hosts. Therefore a host (respectively multiple hosts) must be classified
|
||||||
|
and assigned to only one placement zone. During the deployment process of a
|
||||||
|
VM it must be possible to assign it to one placement zone (or use the
|
||||||
|
default one), which automatically leads to a grouping of VMs.
|
||||||
|
|
||||||
|
The security separation within the network can be done on a logical layer
|
||||||
|
using the same physical elements but adding segregation through VLANs
|
||||||
|
(Virtual LAN), virtual firewalls and other overlay techniques.
|
||||||
|
|
||||||
|
The security separation for virtual machine storage can be done on a logical
|
||||||
|
layer. It must be ensured that a hypervisor belonging to a specific placement
|
||||||
|
zone can not access the storage of a different placement zone. Otherwise an
|
||||||
|
attacker could inject malicious code into the virtual disk of a VM.
|
||||||
|
|
||||||
|
Examples
|
||||||
|
--------
|
||||||
|
|
||||||
|
An application presentation layer (e.g. webserver) must be decoupled from
|
||||||
|
the systems containing sensitive data (e.g. database) through at least one
|
||||||
|
security enforcement device (e.g. virtual firewall) and a separation of
|
||||||
|
underlying infrastructure (hypervisor).
|
||||||
|
|
||||||
|
*Potential candidate for Group Based Policy with Service Function Chaining from
|
||||||
|
a network perspective? GBP would need updates for this concept.*
|
||||||
|
|
||||||
|
https://wiki.openstack.org/wiki/File:TelcoWG_Placementzones.png
|
||||||
|
|
||||||
|
|
||||||
|
Affected By
|
||||||
|
-----------
|
||||||
|
|
||||||
|
unknown
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
============
|
||||||
|
|
||||||
|
* One OpenStack installation must be capable to manage different placement
|
||||||
|
zones. All resources (compute, network and storage) are assigned to one
|
||||||
|
placement zone. By default, all resources are assigned to the "default"
|
||||||
|
placement zone of OpenStack
|
||||||
|
* It must be possible to configure the allowed communication between
|
||||||
|
placement zones on the network layer
|
||||||
|
* SEC is a special placement zone - it provides the glue to connect the
|
||||||
|
placement zones on the network layer using VNFs. SEC VNFs may be attached to
|
||||||
|
resources of other placement zones
|
||||||
|
* Placement zone usage requires a permission (in SEC, tenants cannot start VMs,
|
||||||
|
this zone supports only the deployment of Xaas services FWaas, LBaas,...])
|
||||||
|
* If placement zones are required in a cloud, VMs must be assigned to one
|
||||||
|
placement zone
|
||||||
|
* All resources, which are needed to run a VM must belong to the same placement
|
||||||
|
zone
|
||||||
|
* Physical Hosts (compute nodes) must be able to assigned to only one placement
|
||||||
|
zone and re-assigning should possible due to changing utilization
|
||||||
|
|
||||||
|
* Several assignments must be restricted by the API
|
||||||
|
* If a host is reassigned it must evacuate all existing VM
|
||||||
|
|
||||||
|
* ...and the whole thing must be optional :-)
|
||||||
|
|
||||||
|
Related Use Cases
|
||||||
|
=================
|
||||||
|
|
||||||
|
none
|
||||||
|
|
||||||
|
Gaps
|
||||||
|
====
|
||||||
|
|
||||||
|
**Nova issues:**
|
||||||
|
|
||||||
|
* Usage of availability zone(AZ)/host aggregates to assign a vm to a placement
|
||||||
|
zone is feasable [Ref.1], but:
|
||||||
|
|
||||||
|
* By default a physical host can be assigned to multiple host aggregates
|
||||||
|
* It is up to the operator to ensure security using non OpenStack mechanisms
|
||||||
|
* Maybe Congress [Ref. 2] (Policy as a Service) could be a solution?
|
||||||
|
|
||||||
|
|
||||||
|
**Neutron issues:**
|
||||||
|
|
||||||
|
* AZs or PZs are not known to Neutron services
|
||||||
|
|
||||||
|
* It's up to the operator to ensure that the right networks are attached to VMs
|
||||||
|
|
||||||
|
**Cinder/Manila/Storage issues:**
|
||||||
|
|
||||||
|
* Storage can be segregated with volume-types
|
||||||
|
* AZs are not known to the storage services
|
||||||
|
|
||||||
|
* Must be ensured from the deployment tool that the right storage is accessible
|
||||||
|
|
||||||
|
**OpenStack regions** provide a segregation of all resources. The region concept
|
||||||
|
can be used to implement placement zones, but:
|
||||||
|
|
||||||
|
* Complex and resource consuming installation for the Openstack management
|
||||||
|
systems
|
||||||
|
* Tenants must deal with additional regions
|
||||||
|
* No L2 network sharing for VMs in the SEC placement zone required to glue the
|
||||||
|
zones together
|
||||||
|
* No real enforcement
|
||||||
|
* Complex operations
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
* [1]: http://docs.openstack.org/openstack-ops/content/scaling.html
|
||||||
|
* [2]: https://wiki.openstack.org/wiki/Congress
|
||||||
Loading…
Reference in New Issue
Block a user