security-doc/security-guide/section_data-privacy-concerns.xml

<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  version="5.0"
  xml:id="data-privacy-concerns">
  <?dbhtml stop-chunking?>
    <title>Data privacy concerns</title>
    <section xml:id="data-privacy-concerns-data-residency">
      <title>Data residency</title>
      <para>The privacy and isolation of data has consistently been cited as the primary barrier to cloud adoption over the past few years. Concerns over who owns data in the cloud and whether the cloud operator can be ultimately trusted as a custodian of this data have been significant issues in the past.</para>
      <para>Numerous OpenStack services maintain data and metadata belonging to tenants or reference tenant information.</para>
      <para>Tenant data stored in an OpenStack cloud may include the following items:</para>
      <itemizedlist><listitem>
          <para>Object Storage objects</para>
        </listitem>
        <listitem>
          <para>Compute instance ephemeral filesystem storage</para>
        </listitem>
        <listitem>
          <para>Compute instance memory</para>
        </listitem>
        <listitem>
          <para>Block Storage volume data</para>
        </listitem>
        <listitem>
          <para>Public keys for Compute access</para>
        </listitem>
        <listitem>
          <para>Virtual machine images in the Image service</para>
        </listitem>
        <listitem>
          <para>Machine snapshots</para>
        </listitem>
        <listitem>
          <para>Data passed to OpenStack Compute's configuration-drive extension</para>
        </listitem>
      </itemizedlist>
      <para>Metadata stored by an OpenStack cloud includes the following non-exhaustive items:</para>
      <itemizedlist><listitem>
          <para>Organization name</para>
        </listitem>
        <listitem>
          <para>User's "Real Name"</para>
        </listitem>
        <listitem>
          <para>Number or size of running instances, buckets, objects, volumes, and other quota-related items</para>
        </listitem>
        <listitem>
          <para>Number of hours running instances or storing data</para>
        </listitem>
        <listitem>
          <para>IP addresses of users</para>
        </listitem>
        <listitem>
          <para>Internally generated private keys for compute image bundling</para>
        </listitem>
</itemizedlist>
    </section>
    <section xml:id="data-privacy-concerns-data-disposal">
      <title>Data disposal</title>
      <para>OpenStack operators should strive to provide a certain level of tenant data disposal assurance. Best practices suggest that the operator sanitize cloud system media (digital and non-digital) prior to disposal, release out of organization control or release for reuse. Sanitization methods should implement an appropriate level of strength and integrity given the specific security domain and sensitivity of the information.</para>
      <blockquote>
        <para>"The sanitization process removes information from the media
            such that the information cannot be retrieved or reconstructed.
            Sanitization techniques, including clearing, purging,
            cryptographic erase, and destruction, prevent the disclosure
            of information to unauthorized individuals when such media is
            reused or released for disposal."
            <link xlink:href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf">NIST Special Publication 800-53 Revision 4</link></para>
      </blockquote>
      <para>General data disposal and sanitization guidelines as adopted from NIST recommended security controls. Cloud operators should:</para>
      <orderedlist><listitem>
          <para>Track, document and verify media sanitization and disposal actions.</para>
        </listitem>
<listitem>
          <para>Test sanitation equipment and procedures to verify
          proper performance.</para>
        </listitem>
<listitem>
          <para>Sanitize portable, removable storage devices prior to connecting such devices to the cloud infrastructure.</para>
        </listitem>
<listitem>
          <para>Destroy cloud system media that cannot be sanitized.</para>
        </listitem>
</orderedlist>
      <para>In an OpenStack deployment you will need to address the following:</para>
      <itemizedlist><listitem>
          <para>Secure data erasure</para>
        </listitem>
<listitem>
          <para>Instance memory scrubbing</para>
        </listitem>
<listitem>
          <para>Block Storage volume data</para>
        </listitem>
<listitem>
          <para>Compute instance ephemeral storage</para>
        </listitem>
<listitem>
          <para>Bare metal server sanitization</para>
        </listitem>
</itemizedlist>
      <section xml:id="data-privacy-concerns-data-disposal-data-not-securely-erased">
        <title>Data not securely erased</title>
        <para>Within OpenStack some data may be deleted, but not securely erased in the context of the NIST standards outlined above. This is generally applicable to most or all of the above-defined metadata and information stored in the database. This may be remediated with database and/or system configuration for auto vacuuming and periodic free-space wiping.</para>
      </section>
      <section xml:id="data-privacy-concerns-data-disposal-instance-memory-scrubbing">
        <title>Instance memory scrubbing</title>
        <para>Specific to various hypervisors is the treatment of instance memory. This behavior is not defined in OpenStack Compute, although it is generally expected of hypervisors that they will make a best effort to scrub memory either upon deletion of an instance, upon creation of an instance, or both.</para>
        <para>Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the <link xlink:href="http://www.linux-kvm.org/page/Memory">KVM documentation</link>.</para>
        <para>It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.</para>
        <para>For these and other hypervisors, we recommend referring to hypervisor-specific documentation.</para>
      </section>
      <section xml:id="data-privacy-concerns-data-disposal-cinder-volume-data">
        <title>Cinder volume data</title>
        <para>Use of the OpenStack volume encryption feature is highly encouraged. This is
        discussed in the Data Encryption section below.  When this feature is used,
        destruction of data is accomplished by securely deleting the encryption key.</para>
        <para>If a back end plug-in is being used, there may be independent ways of doing encryption or non-standard overwrite solutions. Plug-ins to OpenStack Block Storage will store data in a variety of ways. Many plug-ins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plug-in to another, from one vendor's solution to another, and from one filesystem to another.</para>
        <para>Some back ends such as ZFS will support copy-on-write to
        prevent data exposure. In these cases, reads from unwritten
        blocks will always return zero. Other back ends such as LVM
        may not natively support this, thus the Block Storage plug-in
        takes the responsibility to override previously written blocks
        before handing them to users. It is important to review what
        assurances your chosen volume back end provides and to see what
        mediations may be available for those assurances not
        provided.</para>
      <para>Finally, while not a feature of OpenStack, vendors and
        implementors may choose to add or support encryption of volumes.
        In this case, destruction of data is as simple as throwing
        away the key.</para>
      </section>
      <section xml:id="data-privacy-concerns-data-disposal-glance-delay-delete">
        <title>Image service delay delete feature</title>
        <para>OpenStack Image service has a delayed delete feature, which will
          pend the deletion of an image for a defined time period. It
          is recommended to disable this feature if it is a security
          concern, by editing the <filename>etc/glance/glance-api.conf</filename>
          file and setting the <literal>delayed_delete</literal> option
          as <replaceable>False</replaceable>.</para>
      </section>
      <section xml:id="data-privacy-concerns-data-disposal-nova-soft-delete">
        <title>Compute soft delete feature</title>
        <para>OpenStack Compute has a soft-delete feature, which enables
          an instance that is deleted to be in a soft-delete state for
          a defined time period. The instance can be restored during
          this time period. To disable the soft-delete feature, edit
          the <filename>etc/nova/nova.conf</filename> file and leave
          the <literal>reclaim_instance_interval</literal> option empty.</para>
      </section>
      <section xml:id="data-privacy-concerns-data-disposal-compute-instnace-ephemeral-storage">
        <title>Compute instance ephemeral storage</title>
        <para>The creation and destruction of ephemeral storage will be
          somewhat dependent on the chosen hypervisor and the OpenStack
          Compute plug-in.</para>
        <para>The libvirt plug-in for compute may maintain ephemeral
          storage directly on a filesystem, or in LVM. Filesystem storage
          generally will not overwrite data when it is removed, although
          there is a guarantee that dirty extents are not provisioned
          to users.</para>
        <para>When using LVM backed ephemeral storage, which is block-based,
          it is necessary that the OpenStack Compute software securely
          erases blocks to prevent information disclosure. There have
          in the past been information disclosure vulnerabilities related
          to improperly erased ephemeral block storage devices.</para>
        <para>Filesystem storage is a more secure solution for ephemeral
          block storage devices than LVM as dirty extents cannot be provisioned
          to users. However, it is important to be mindful that user
          data is not destroyed, so it is suggested to encrypt the
          backing filesystem.</para>
      </section>
      <section xml:id="data-privacy-concerns-data-disposal-bare-metal-server-sanitization">
        <title>Bare metal server sanitization</title>
        <para>
          A bare metal server driver for Compute was under development
          and has since moved into a separate project called <link
          xlink:href="https://wiki.openstack.org/wiki/Ironic">ironic</link>. At
          the time of this writing, ironic does not appear to address
          sanitization of tenant data resident the physical hardware.
        </para>
        <para>
          Additionally, it is possible for tenants of a bare metal
          system to modify system firmware. TPM technology, described
          in <xref linkend="integrity-life-cycle-secure-bootstrapping"/>,
          provides a solution for detecting unauthorized firmware
          changes.
        </para>
      </section>
    </section>
</section>