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.
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.
Separation of DMZ and MZ is a common requirement of VNFs to meet communication service provider security requirements.
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.
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.
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). The intent being to minimize the likelihood of a breach of a component runing in one zone resulting in a breach of another component running in a separate zone.
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
** 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 :-)
Nova issues:
Neutron issues:
Cinder/Manila/Storage issues:
OpenStack regions provide a segregation of all resources. The region concept can be used to implement placement zones, but: