@ sphinx.addnodesdocument)}( rawsource children]docutils.nodessection)}(hhh](h title)}(hSecurityh]h TextSecurity}(hhparenth _documenthsourceNlineNuba
attributes}(ids]classes]names]dupnames]backrefs]utagnamehhhhhh[/home/opnfv/slave_root/workspace/cntt-tox-ra1/doc/ref_arch/openstack/chapters/chapter06.rsthKubh)}(hhh](h)}(hIntroductionh]hIntroduction}(hh2hh0hhhNhNubah}(h!]h#]h%]h']h)]uh+hhh-hhhh,hKubh paragraph)}(hX This guide is intended to provide basic security requirements to
architects who are implementing Cloud Infrastructure using
`OpenStack `__ technology. This is a minimal
set of high-level general security practices, not intended to cover all
implementation scenarios. Please ensure to also reference your
enterprise security and compliance requirements in addition to this
guide.h](h|This guide is intended to provide basic security requirements to
architects who are implementing Cloud Infrastructure using
}(h|This guide is intended to provide basic security requirements to
architects who are implementing Cloud Infrastructure using
hh@hhhNhNubh reference)}(h*`OpenStack `__h]h OpenStack}(h OpenStackhhKhhhNhNubah}(h!]h#]h%]h']h)]namehSrefurihttps://www.openstack.org/uh+hIhh@ubh technology. This is a minimal
set of high-level general security practices, not intended to cover all
implementation scenarios. Please ensure to also reference your
enterprise security and compliance requirements in addition to this
guide.}(h technology. This is a minimal
set of high-level general security practices, not intended to cover all
implementation scenarios. Please ensure to also reference your
enterprise security and compliance requirements in addition to this
guide.hh@hhhNhNubeh}(h!]h#]h%]h']h)]uh+h>hh,hKhh-hhubeh}(h!]introductionah#]h%]introductionah']h)]uh+h
hhhhhh,hKubh)}(hhh](h)}(hSecurity Requirementsh]hSecurity Requirements}(hhuhhshhhNhNubah}(h!]h#]h%]h']h)]uh+hhhphhhh,hKubh?)}(hX Chapter 2 (:ref:`ref_arch/openstack/chapters/chapter02:cloud infrastructure security requirements`
and :ref:`ref_arch/openstack/chapters/chapter02:security recommendations`) gathers
all requirements and recommendations regarding security topics developed
in this chapter.h](hChapter 2 (}(hChapter 2 (hhhhhNhNubh pending_xref)}(hW:ref:`ref_arch/openstack/chapters/chapter02:cloud infrastructure security requirements`h]h inline)}(hhh]hPref_arch/openstack/chapters/chapter02:cloud infrastructure security requirements}(hhhhhhhNhNubah}(h!]h#](xrefstdstd-refeh%]h']h)]uh+hhhubah}(h!]h#]h%]h']h)]refdocchapters/chapter06 refdomainhreftyperefrefexplicitrefwarn reftargetPref_arch/openstack/chapters/chapter02:cloud infrastructure security requirementsuh+hhh,hKhhubh
and }(h
and hhhhhNhNubh)}(hE:ref:`ref_arch/openstack/chapters/chapter02:security recommendations`h]h)}(hhh]h>ref_arch/openstack/chapters/chapter02:security recommendations}(hhhhhhhNhNubah}(h!]h#](hstdstd-refeh%]h']h)]uh+hhhubah}(h!]h#]h%]h']h)]refdoch refdomainhČreftyperefrefexplicitrefwarnh>ref_arch/openstack/chapters/chapter02:security recommendationsuh+hhh,hKhhubhc) gathers
all requirements and recommendations regarding security topics developed
in this chapter.}(hc) gathers
all requirements and recommendations regarding security topics developed
in this chapter.hhhhhNhNubeh}(h!]h#]h%]h']h)]uh+h>hh,hKhhphhubeh}(h!]security-requirementsah#]h%]security requirementsah']h)]uh+h
hhhhhh,hKubh)}(hhh](h)}(h%Cloud Infrastructure and VIM Securityh]h%Cloud Infrastructure and VIM Security}(hhhhhhhNhNubah}(h!]h#]h%]h']h)]uh+hhhhhhh,hKubh?)}(hX In the "`Security boundaries and
threats `__"
section of the `OpenStack security
guide `__,
there is extensive description on security domains, threat
classifications, and attack vectors. The following only touches on some
of the topics and at a high level.h](h
In the “}(hIn the "hhhhhNhNubhJ)}(h`Security boundaries and
threats `__h]hSecurity boundaries and
threats}(hSecurity boundaries and
threatshj hhhNhNubah}(h!]h#]h%]h']h)]nameSecurity boundaries and threatsh[[https://docs.openstack.org/security-guide/introduction/security-boundaries-and-threats.htmluh+hIhhubh”
section of the }(h"
section of the hhhhhNhNubhJ)}(ht`OpenStack security
guide `__h]hOpenStack security
guide}(hOpenStack security
guidehj hhhNhNubah}(h!]h#]h%]h']h)]nameOpenStack security guideh[Uhttps://docs.openstack.org/security-guide/introduction/introduction-to-openstack.htmluh+hIhhubh,
there is extensive description on security domains, threat
classifications, and attack vectors. The following only touches on some
of the topics and at a high level.}(h,
there is extensive description on security domains, threat
classifications, and attack vectors. The following only touches on some
of the topics and at a high level.hhhhhNhNubeh}(h!]h#]h%]h']h)]uh+h>hh,hKhhhhubh)}(hhh](h)}(hSystem Hardeningh]hSystem Hardening}(hj< hj: hhhNhNubah}(h!]h#]h%]h']h)]uh+hhj7 hhhh,hK#ubh?)}(hAll infrastructure components should undergo system hardening, establish
processes to govern the hardening, and documents to cover at a minimal
for the following areas.h]hAll infrastructure components should undergo system hardening, establish
processes to govern the hardening, and documents to cover at a minimal
for the following areas.}(hjJ hjH hhhNhNubah}(h!]h#]h%]h']h)]uh+h>hh,hK%hj7 hhubh)}(hhh](h)}(hServer boot hardeningh]hServer boot hardening}(hj[ hjY hhhNhNubah}(h!]h#]h%]h']h)]uh+hhjV hhhh,hK*ubh?)}(hXJ Server boot process must be trusted. For this purpose, the integrity and
authenticity of all BIOS firmware components must be verified at boot.
Per sec.gen.003 requirement, Secure Boot based on UEFI must be used. By
verifying the signatures of all BIOS components, Secure Boot will ensure
that servers start with the firmware expected and without malware
insertion into the system. Secure Boot checks the digital signatures
locally. To implement a chain of trust, Secure Boot must be complemented
by the use of a hardware based Root of Trust provided by a TPM (Trusted
Platform Module).h]hXJ Server boot process must be trusted. For this purpose, the integrity and
authenticity of all BIOS firmware components must be verified at boot.
Per sec.gen.003 requirement, Secure Boot based on UEFI must be used. By
verifying the signatures of all BIOS components, Secure Boot will ensure
that servers start with the firmware expected and without malware
insertion into the system. Secure Boot checks the digital signatures
locally. To implement a chain of trust, Secure Boot must be complemented
by the use of a hardware based Root of Trust provided by a TPM (Trusted
Platform Module).}(hji hjg hhhNhNubah}(h!]h#]h%]h']h)]uh+h>hh,hK,hjV hhubeh}(h!]server-boot-hardeningah#]h%]server boot hardeningah']h)]uh+h
hj7 hhhh,hK*ubh)}(hhh](h)}(h
System Accessh]h
System Access}(hj hj hhhNhNubah}(h!]h#]h%]h']h)]uh+hhj} hhhh,hK7ubh?)}(hhAccess to all the platform’s components must be restricted (sec.gen.013)
applying the following rules:h]hhAccess to all the platform’s components must be restricted (sec.gen.013)
applying the following rules:}(hj hj hhhNhNubah}(h!]h#]h%]h']h)]uh+h>hh,hK9hj} hhubh bullet_list)}(hhh](h list_item)}(h>Remove, or at a minimal, disable all unnecessary user accountsh]h?)}(hj h]h>Remove, or at a minimal, disable all unnecessary user accounts}(hj hj hhhNhNubah}(h!]h#]h%]h']h)]uh+h>hh,hK