openstack/openstack-manuals
Code Issues Proposed changes
2d1f5f3d95
openstack-manuals/doc/security-guide/locale/gl.po
Tom Fifield 5447eb4035 Imported Translations from Transifex 
Change-Id: Ia67097d964b62d2fef2b32d93b5988400bb27bfa
2014-01-18 01:02:05 +08:00

9995 lines
409 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

#
# Translators:
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-01-17 07:15+0000\n"
"PO-Revision-Date: 2014-01-10 15:44+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"Language-Team: Galician (http://www.transifex.com/projects/p/openstack/language/gl/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: gl\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml30(None)
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml33(None)
msgid "@@image: 'static/group.png'; md5=aec1f0af66d29c1a5d1f174df1f12812"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml3(title)
msgid "Why and how we wrote this book"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml4(para)
msgid ""
"As OpenStack adoption continues to grow and the product matures, security "
"has become a priority. The OpenStack Security Group has recognized the need "
"for a comprehensive and authoritative security guide. The <emphasis "
"role=\"bold\">OpenStack Security Guide</emphasis> has been written to "
"provide an overview of security best practices, guidelines, and "
"recommendations for increasing the security of an OpenStack deployment. The "
"authors bring their expertise from deploying and securing OpenStack in a "
"variety of environments."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml5(para)
msgid ""
"The guide augments the <link "
"href=\"http://docs.openstack.org/ops/\"><citetitle>OpenStack Operations "
"Guide</citetitle></link> and can be referenced to harden existing OpenStack "
"deployments or to evaluate the security controls of OpenStack cloud "
"providers."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml7(title)
msgid "Objectives"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml9(para)
msgid "Identify the security domains in OpenStack"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml12(para)
msgid "Provide guidance to secure your OpenStack deployment"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml15(para)
msgid ""
"Highlight security concerns and potential mitigations in present day "
"OpenStack"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml18(para)
msgid "Discuss upcoming security features"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml21(para)
msgid ""
"To provide a community driven facility for knowledge capture and "
"dissemination"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml26(title)
msgid "How"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml27(para)
msgid ""
"As with the OpenStack Operations Guide, we followed the book sprint "
"methodology. The book sprint process allows for rapid development and "
"production of large bodies of written work. Coordinators from the OpenStack "
"Security Group re-enlisted the services of Adam Hyde as facilitator. "
"Corporate support was obtained and the project was formally announced during"
" the OpenStack summit in Portland, Oregon."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml28(para)
msgid ""
"The team converged in Annapolis, MD due to the close proximity of some key "
"members of the group. This was a remarkable collaboration between public "
"sector intelligence community members, silicon valley startups and some "
"large, well-known technology companies. The book sprint ran during the last "
"week in June 2013 and the first edition was created in five days."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml36(para)
msgid "The team included:"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml39(para)
msgid "<emphasis role=\"bold\">Bryan D. Payne</emphasis>, Nebula"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml40(para)
msgid ""
"Dr. Bryan D. Payne is the Director of Security Research at Nebula and co-"
"founder of the OpenStack Security Group (OSSG). Prior to joining Nebula, he "
"worked at Sandia National Labs, the National Security Agency, BAE Systems, "
"and IBM Research. He graduated with a Ph.D. in Computer Science from the "
"Georgia Tech College of Computing, specializing in systems security."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml43(para)
msgid "<emphasis role=\"bold\">Robert Clark</emphasis>, HP"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml44(para)
msgid ""
"Robert Clark is the Lead Security Architect for HP Cloud Services and co-"
"founder of the OpenStack Security Group (OSSG). Prior to being recruited by "
"HP, he worked in the UK Intelligence Community. Robert has a strong "
"background in threat modeling, security architecture and virtualization "
"technology. Robert has a master's degree in Software Engineering from the "
"University of Wales."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml47(para)
msgid "<emphasis role=\"bold\">Keith Basil</emphasis>, Red Hat"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml48(para)
msgid ""
"Keith Basil is a Principal Product Manager for Red Hat OpenStack and is "
"focused on Red Hat's OpenStack product management, development and strategy."
" Within the US public sector, Basil brings previous experience from the "
"design of an authorized, secure, high-performance cloud architecture for "
"Federal civilian agencies and contractors."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml51(para)
msgid "<emphasis role=\"bold\">Cody Bunch</emphasis>, Rackspace"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml52(para)
msgid ""
"Cody Bunch is a Private Cloud architect with Rackspace. Cody has co-authored"
" an update to \"The OpenStack Cookbook\" as well as books on VMware "
"automation."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml55(para)
msgid "<emphasis role=\"bold\">Malini Bhandaru</emphasis>, Intel"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml56(para)
msgid ""
"Malini Bhandaru is a security architect at Intel. She has a varied "
"background, having worked on platform power and performance at Intel, speech"
" products at Nuance, remote monitoring and management at ComBrio, and web "
"commerce at Verizon. She has a Ph.D. in Artificial Intelligence from the "
"University of Massachusetts, Amherst."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml59(para)
msgid ""
"<emphasis role=\"bold\">Gregg Tally</emphasis>, Johns Hopkins University "
"Applied Physics Laboratory"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml60(para)
msgid ""
"Gregg Tally is the Chief Engineer at JHU/APL's Cyber Systems Group within "
"the Asymmetric Operations Department. He works primarily in systems security"
" engineering. Previously, he has worked at SPARTA, McAfee, and Trusted "
"Information Systems where he was involved in cyber security research "
"projects."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml63(para)
msgid "<emphasis role=\"bold\">Eric Lopez</emphasis>, Nicira / VMware"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml64(para)
msgid ""
"Eric Lopez is Senior Solution Architect at VMware's Networking and Security "
"Business Unit where he helps customer implement OpenStack and Nicira's "
"Network Virtualization Platform. Prior to joining Nicira, he worked for Q1 "
"Labs, Symantec, Vontu, and Brightmail. He has a B.S in Electrical "
"Engineering/Computer Science and Nuclear Engineering from U.C. Berkeley and "
"MBA from the University of San Francisco."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml67(para)
msgid "<emphasis role=\"bold\">Shawn Wells</emphasis>, Red Hat"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml68(para)
msgid ""
"Shawn Wells is the Director, Innovation Programs at Red Hat, focused on "
"improving the process of adopting, contributing to, and managing open source"
" technologies within the U.S. Government. Additionally, Shawn is an upstream"
" maintainer of the SCAP Security Guide project which forms virtualization "
"and operating system hardening policy with the U.S. Military, NSA, and DISA."
" Formerly an NSA civilian, Shawn developed SIGINT collection systems "
"utilizing large distributed computing infrastructures."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml71(para)
msgid "<emphasis role=\"bold\">Ben de Bont</emphasis>, HP"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml72(para)
msgid ""
"Ben de Bont is the CSO for HP Cloud Services. Prior to his current role Ben "
"led the information security group at MySpace and the incident response team"
" at MSN Security. Ben holds a master's degree in Computer Science from the "
"Queensland University of Technology."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml75(para)
msgid ""
"<emphasis role=\"bold\">Nathanael Burton</emphasis>, National Security "
"Agency"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml76(para)
msgid ""
"Nathanael Burton is a Computer Scientist at the National Security Agency. He"
" has worked for the Agency for over 10 years working on distributed systems,"
" large-scale hosting, open source initiatives, operating systems, security, "
"storage, and virtualization technology. He has a B.S. in Computer Science "
"from Virginia Tech."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml79(emphasis)
msgid "Vibha Fauver"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml80(para)
msgid ""
"Vibha Fauver, GWEB, CISSP, PMP, has over fifteen years of experience in "
"Information Technology. Her areas of specialization include software "
"engineering, project management and information security. She has a B.S. in "
"Computer &amp; Information Science and a M.S. in Engineering Management with"
" specialization and a certificate in Systems Engineering."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml83(para)
msgid "<emphasis role=\"bold\">Eric Windisch</emphasis>, Cloudscaling"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml84(para)
msgid ""
"Eric Windisch is a Principal Engineer at Cloudscaling where he has been "
"contributing to OpenStack for over two years. Eric has been in the trenches "
"of hostile environments, building tenant isolation and infrastructure "
"security through more than a decade of experience in the web hosting "
"industry. He has been building cloud computing infrastructure and automation"
" since 2007."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml87(para)
msgid "<emphasis role=\"bold\">Andrew Hay</emphasis>, CloudPassage"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml88(para)
msgid ""
"Andrew Hay is the Director of Applied Security Research at CloudPassage, "
"Inc. where he leads the security research efforts for the company and its "
"server security products purpose-built for dynamic public, private, and "
"hybrid cloud hosting environments."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml91(emphasis)
msgid "Adam Hyde"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml92(para)
msgid ""
"Adam facilitated this Book Sprint. He also founded the Book Sprint "
"methodology and is the most experienced Book Sprint facilitator around. Adam"
" founded FLOSS Manuals—a community of some 3,000 individuals developing Free"
" Manuals about Free Software. He is also the founder and project manager for"
" Booktype, an open source project for writing, editing, and publishing books"
" online and in print."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml95(para)
msgid ""
"During the sprint we also had help from Anne Gentle, Warren Wang, Paul "
"McMillan, Brian Schott and Lorin Hochstein."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml96(para)
msgid ""
"This Book was produced in a 5 day book sprint. A book sprint is an intensely"
" collaborative, facilitated process which brings together a group to produce"
" a book in 3-5 days. It is a strongly facilitated process with a specific "
"methodology founded and developed by Adam Hyde. For more information visit "
"the book sprint web page at <link "
"href=\"http://www.booksprints.net\">http://www.booksprints.net</link>."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml104(para)
msgid "After initial publication, the following added new content:"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml107(para)
msgid "<emphasis role=\"bold\">Rodney D. Beede</emphasis>, Seagate Technology"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml110(para)
msgid ""
"Rodney D. Beede is the Cloud Security Engineer for Seagate Technology. He "
"contributed the missing chapter on securing OpenStack Object Storage "
"(Swift). He holds a M.S. in Computer Science from the University of "
"Colorado."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml119(title)
msgid "How to contribute to this book"
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml120(para)
msgid ""
"The initial work on this book was conducted in an overly air-conditioned "
"room that served as our group office for the entirety of the documentation "
"sprint."
msgstr ""
#: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml123(para)
msgid ""
"Learn more about how to contribute to the OpenStack docs: <link "
"href=\"http://wiki.openstack.org/Documentation/HowTo\">http://wiki.openstack.org/Documentation/HowTo</link>."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml3(title)
msgid "Hypervisor Selection"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml4(para)
msgid ""
"Virtualization provides flexibility and other key benefits that enable cloud"
" building. However, a virtualization stack also needs to be secured "
"appropriately to reduce the risks associated with hypervisor breakout "
"attacks. That is, while a virtualization stack can provide isolation between"
" instances, or guest virtual machines, there are situations where that "
"isolation can be less than perfect. Making intelligent selections for "
"virtualization stack as well as following the best practices outlined in "
"this chapter can be included in a layered approach to cloud security. "
"Finally, securing your virtualization stack is critical in order to deliver "
"on the promise of multitennancy, either between customers in a public cloud,"
" between business units in a private cloud, or some mixture of the two in a "
"hybrid cloud."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml5(para)
msgid ""
"In this chapter, we discuss the hypervisor selection process.  In the "
"chapters that follow, we provide the foundational information needed for "
"securing a virtualization stack."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml7(title)
msgid "Hypervisors in OpenStack"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml8(para)
msgid ""
"Whether OpenStack is deployed within private data centers or as a public "
"cloud service, the underlying virtualization technology provides enterprise-"
"level capabilities in the realms of scalability, resource efficiency, and "
"uptime. While such high-level benefits are generally available across many "
"OpenStack-supported hypervisor technologies, there are significant "
"differences in each hypervisor's security architecture and features, "
"particularly when considering the security threat vectors which are unique "
"to elastic OpenStack environments. As applications consolidate into single "
"Infrastructure as a Service (IaaS) platforms, instance isolation at the "
"hypervisor level becomes paramount. The requirement for secure isolation "
"holds true across commercial, government, and military communities."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml9(para)
msgid ""
"Within the framework of OpenStack you can choose from any number of "
"hypervisor platforms and corresponding OpenStack plugins to optimize your "
"cloud environment. In the context of the OpenStack Security guide, we will "
"be highlighting hypervisor selection considerations as they pertains to "
"feature sets that are critical to security. However, these considerations "
"are not meant to be an exhaustive investigation into the pros and cons of "
"particular hypervisors. NIST provides additional guidance in Special "
"Publication 800-125, \"<emphasis>Guide to Security for Full Virtualization "
"Technologies</emphasis>\"."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml12(title)
msgid "Selection Criteria"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml13(para)
msgid ""
"As part of your hypervisor selection process, you will need to consider a "
"number of important factors to help increase your security posture. "
"Specifically, we will be looking into the following areas:"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml15(para)
msgid "Team Expertise"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml18(para)
msgid "Product or Project maturity"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml21(para)
msgid "Certifications, Attestations"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml24(para)
#: ./doc/security-guide/ch051_vss-intro.xml266(title)
msgid "Additional Security Features"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml27(para)
#: ./doc/security-guide/ch051_vss-intro.xml259(title)
msgid "Hypervisor vs. Baremetal"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml30(para)
#: ./doc/security-guide/ch051_vss-intro.xml221(title)
msgid "Hardware Concerns"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml33(para)
#: ./doc/security-guide/ch051_vss-intro.xml67(title)
msgid "Common Criteria"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml37(para)
msgid ""
"Has the hypervisor undergone Common Criteria certification? If so, to what "
"levels?"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml40(para)
msgid "Is the underlying cryptography certified by a third-party?"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml36(para)
msgid ""
"Additionally, the following security-related criteria are highly encouraged "
"to be evaluated when selecting a hypervisor for OpenStack "
"deployments:<placeholder-1/><bridgehead>Team Expertise</bridgehead> Most "
"likely, the most important aspect in hypervisor selection is the expertise "
"of your staff in managing and maintaining a particular hypervisor platform. "
"The more familiar your team is with a given product, its configuration, and "
"its eccentricities, the less likely will there be configuration mistakes. "
"Additionally, having staff expertise spread across an organization on a "
"given hypervisor will increase availability of your systems, allow for "
"developing a segregation of duties, and mitigate problems in the event that "
"a team member is unavailable."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml44(title)
msgid "Product or Project Maturity"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml45(para)
msgid ""
"The maturity of a given hypervisor product or project is critical to your "
"security posture as well. Product maturity will have a number of effects "
"once you have deployed your cloud, in the context of this security guide we "
"are interested in the following:"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml47(para)
msgid "Availability of expertise"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml50(para)
msgid "Active developer and user communities"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml53(para)
msgid "Timeliness and Availability of updates"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml56(para)
msgid "Incidence response"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml59(para)
msgid ""
"One of the biggest indicators of a hypervisor's maturity is the size and "
"vibrancy of the community that surrounds it. As this concerns security, the "
"quality of the community will affect the availability of expertise should "
"you need additional cloud operators. It is also a sign of how widely "
"deployed the hypervisor is, in turn leading to the battle readiness of any "
"reference architectures and best practices."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml60(para)
msgid ""
"Further, the quality of community, as it surrounds an open source hypervisor"
" like KVM or Xen, will have a direct impact on the timeliness of bug fixes "
"and security updates. When investigating both commercial and open source "
"hypervisors, you will want to look into their release and support cycles as "
"well as the time delta between the announcement of a bug or security issue "
"and a patch or response. Lastly, the supported capabilities of OpenStack "
"compute vary depending on the hypervisor chosen. Refer to the <link "
"href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack "
"Hypervisor Support Matrix</link> for OpenStack compute feature support by "
"hypervisor."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml63(title)
msgid "Certifications and Attestations"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml64(para)
msgid ""
"One additional consideration when selecting a hypervisor is the availability"
" of various formal certifications and attestations. While they may not be "
"requirements for your specific organization, these certifications and "
"attestations speak to the maturity, production readiness, and thoroughness "
"of the testing a particular hypervisor platform has been subjected to."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml68(para)
msgid ""
"Common Criteria is an internationally standardized software evaluation "
"process, used by governments and commercial companies to validate software "
"technologies perform as advertised. In the government sector, NSTISSP No. 11"
" mandates that U.S. Government agencies only procure software which has been"
" Common Criteria certified, a policy which has been in place since July "
"2002. It should be specifically noted that OpenStack has not undergone "
"Common Criteria certification, however many of the available hypervisors "
"have."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml69(para)
msgid ""
"In addition to validating a technologies capabilities, the Common Criteria "
"process evaluates <emphasis>how</emphasis> technologies are developed."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml71(para)
msgid "How is source code management performed?"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml74(para)
msgid "How are users granted access to build systems?"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml77(para)
msgid "Is the technology cryptographically signed before distribution?"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml80(para)
msgid ""
"The KVM hypervisor has been Common Criteria certified through the U.S. "
"Government and commercial distributions, which have been validated to "
"separate the runtime environment of virtual machines from each other, "
"providing foundational technology to enforce instance isolation. In addition"
" to virtual machine isolation, KVM has been Common Criteria certified to"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml82(para)
msgid ""
"\"<emphasis>provide system-inherent separation mechanisms to the resources "
"of virtual machines. This separation ensures that large software component "
"used for virtualizing and simulating devices executing for each virtual "
"machine cannot interfere with each other. Using the SELinux multi-category "
"mechanism, the virtualization and simulation software instances are "
"isolated. The virtual machine management framework configures SELinux multi-"
"category settings transparently to the administrator</emphasis>\""
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml84(para)
msgid ""
"While many hypervisor vendors, such as Red Hat, Microsoft, and VMWare have "
"achieved Common Criteria Certification their underlying certified feature "
"set differs. It is recommended to evaluate vendor claims to ensure they "
"minimally satisfy the following requirements:"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml91(para)
msgid "Identification and Authentication"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml92(para)
msgid ""
"Identification and authentication using pluggable authentication modules "
"(PAM) based upon user passwords. The quality of the passwords used can be "
"enforced through configuration options."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml95(para)
msgid "Audit"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml96(para)
msgid ""
"The system provides the capability to audit a large number of events "
"including individual system calls as well as events generated by trusted "
"processes. Audit data is collected in regular files in ASCII format. The "
"system provides a program for the purpose of searching the audit records."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml96(para)
msgid ""
"The system administrator can define a rule base to restrict auditing to the "
"events they are interested in. This includes the ability to restrict "
"auditing to specific events, specific users, specific objects or a "
"combination of all of this. "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml96(para)
msgid "Audit records can be transferred to a remote audit daemon."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml99(para)
msgid "Discretionary Access Control"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml100(para)
msgid ""
"Discretionary Access Control (DAC) restricts access to file system objects "
"based on Access Control Lists (ACLs) that include the standard UNIX "
"permissions for user, group and others. Access control mechanisms also "
"protect IPC objects from unauthorized access."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml100(para)
msgid ""
"The system includes the ext4 file system, which supports POSIX ACLs. This "
"allows defining access rights to files within this type of file system down "
"to the granularity of a single user."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml103(para)
msgid "Mandatory Access Control"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml104(para)
msgid ""
"Mandatory Access Control (MAC) restricts access to objects based on labels "
"assigned to subjects and objects. Sensitivity labels are automatically "
"attached to processes and objects. The access control policy enforced using "
"these labels is derived from the BellLaPadula access control model."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml104(para)
msgid ""
"SELinux categories are attached to virtual machines and its resources. The "
"access control policy enforced using these categories grant virtual machines"
" access to resources if the category of the virtual machine is identical to "
"the category of the accessed resource."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml104(para)
msgid ""
"The TOE implements non-hierarchical categories to control access to virtual "
"machines."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml107(para)
msgid "Role-Based Access Control"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml108(para)
msgid ""
"Role-based access control (RBAC) allows separation of roles to eliminate the"
" need for an all-powerful system administrator."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml111(para)
msgid "Object Reuse"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml112(para)
msgid ""
"File system objects as well as memory and IPC objects will be cleared before"
" they can be reused by a process belonging to a different user."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml115(para)
msgid "Security Management"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml116(para)
msgid ""
"The management of the security critical parameters of the system is "
"performed by administrative users. A set of commands that require root "
"privileges (or specific roles when RBAC is used) are used for system "
"management. Security parameters are stored in specific files that are "
"protected by the access control mechanisms of the system against "
"unauthorized access by users that are not administrative users."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml119(para)
msgid "Secure Communication"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml120(para)
msgid ""
"The system supports the definition of trusted channels using SSH. Password "
"based authentication is supported. Only a restricted number of cipher suites"
" are supported for those protocols in the evaluated configuration."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml123(para)
msgid "Storage Encryption"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml124(para)
msgid ""
"The system supports encrypted block devices to provide storage "
"confidentiality via dm_crypt."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml127(para)
msgid "TSF Protection"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml128(para)
msgid ""
"While in operation, the kernel software and data are protected by the "
"hardware memory protection mechanisms. The memory and process management "
"components of the kernel ensure a user process cannot access kernel storage "
"or storage belonging to other processes."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml128(para)
msgid ""
"Non-kernel TSF software and data are protected by DAC and process isolation"
"  mechanisms. In the evaluated configuration, the reserved user ID root owns"
" the directories and files that define the TSF configuration. In general, "
"files and directories containing internal TSF data (e.g., configuration "
"files, batch job queues) are also protected from reading by DAC permissions."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml128(para)
msgid ""
"The system and the hardware and firmware components are required to be "
"physically protected from unauthorized access. The system kernel mediates "
"all access to the hardware mechanisms themselves, other than program visible"
" CPU instruction functions."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml128(para)
msgid ""
"In addition, mechanisms for protection against stack overflow attacks are "
"provided."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml135(title)
msgid "Cryptography Standards"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml136(para)
msgid ""
"Several cryptography algorithms are available within OpenStack for "
"identification and authorization, data transfer and protection of data at "
"rest. When selecting a hypervisor, the following are recommended algorithms "
"and implementation standards to ensure the virtualization layer supports:"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml146(emphasis)
msgid "Algorithm"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml147(emphasis)
msgid "Key Length"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml148(emphasis)
msgid "Intended Purpose"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml149(emphasis)
msgid "Security Function"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml150(emphasis)
msgid "Implementation Standard"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml153(para)
msgid "AES"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml154(para)
msgid "128 bits,192 bits,"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml154(para)
msgid "256 bits"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml155(para)
#: ./doc/security-guide/ch051_vss-intro.xml162(para)
msgid "Encryption / Decryption"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml156(para)
msgid "Protected Data Transfer, Protection for Data at Rest"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml157(para)
#: ./doc/security-guide/ch051_vss-intro.xml164(para)
msgid "RFC 4253"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml160(para)
msgid "TDES"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml161(para)
msgid "168 bits"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml163(para)
msgid "Protected Data Transfer"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml167(para)
msgid "RSA"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml168(para)
msgid "1024 bits,2048 bits,"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml168(para)
msgid "3072 bits "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml169(para)
#: ./doc/security-guide/ch051_vss-intro.xml176(para)
msgid "Authentication,Key Exchange "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml170(para)
#: ./doc/security-guide/ch051_vss-intro.xml177(para)
msgid "Identification and Authentication, Protected Data Transfer"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml171(para)
#: ./doc/security-guide/ch051_vss-intro.xml178(para)
msgid "U.S. NIST FIPS PUB 186-3"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml174(para)
msgid "DSA"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml175(para)
msgid "L=1024,N=160 bits "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml181(para)
msgid "Serpent"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml182(para)
#: ./doc/security-guide/ch051_vss-intro.xml189(para)
msgid "128, 196, or256 bit "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml183(para)
#: ./doc/security-guide/ch051_vss-intro.xml190(para)
msgid "Encryption /Decryption "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml184(para)
#: ./doc/security-guide/ch051_vss-intro.xml191(para)
msgid "Protection of Data at Rest"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml185(link)
msgid "http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml188(para)
msgid "Twofish"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml192(link)
msgid "http://www.schneier.com/paper-twofish-paper.html"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml195(para)
msgid "SHA-1"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml196(para)
#: ./doc/security-guide/ch051_vss-intro.xml203(para)
msgid "-"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml197(para)
#: ./doc/security-guide/ch051_vss-intro.xml204(para)
msgid "MessageDigest "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml198(para)
msgid "Protection of Data at Rest,Protected Data Transfer"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml199(para)
#: ./doc/security-guide/ch051_vss-intro.xml206(para)
msgid "U.S. NIST FIPS 180-3"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml202(para)
msgid "SHA-2(224-, 256-,"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml202(para)
msgid "384-, 512 bit)"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml205(para)
msgid "Protection for Data at Rest,Identification and Authentication "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml212(title)
msgid "FIPS 140-2"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml213(para)
msgid ""
"In the United States the National Institute of Science and Technology (NIST)"
" certifies cryptographic algorithms through a process known the "
"Cryptographic Module Validation Program. NIST certifies algorithms for "
"conformance against Federal Information Processing Standard 140-2 (FIPS "
"140-2), which ensures:"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml215(emphasis)
msgid ""
"Products validated as conforming to FIPS 140-2 are accepted by the Federal "
"agencies of both countries [United States and Canada] for the protection of "
"sensitive information (United States) or Designated Information (Canada). "
"The goal of the CMVP is to promote the use of validated cryptographic "
"modules and provide Federal agencies with a security metric to use in "
"procuring equipment containing validated cryptographic modules."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml217(para)
msgid ""
"When evaluating base hypervisor technologies, consider if the hypervisor has"
" been certified against FIPS 140-2. Not only is conformance against FIPS "
"140-2 mandated per U.S. Government policy, formal certification indicates "
"that a given implementation of a cryptographic algorithm has been reviewed "
"for conformance against module specification, cryptographic module ports and"
" interfaces; roles, services, and authentication; finite state model; "
"physical security; operational environment; cryptographic key management; "
"electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-"
"tests; design assurance; and mitigation of other attacks."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml222(para)
msgid ""
"Further, when evaluating a hypervisor platform the supportability of the "
"hardware the hypervisor will run on should be considered. Additionally, "
"consider the additional features available in the hardware and how those "
"features are supported by the hypervisor you chose as part of the OpenStack "
"deployment. To that end, hypervisors will each have their own hardware "
"compatibility lists (HCLs). When selecting compatible hardware it is "
"important to know in advance which hardware-based virtualization "
"technologies are important from a security perspective."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml230(emphasis)
msgid "Description"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml231(emphasis)
msgid "Technology"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml232(emphasis)
msgid "Explanation"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml235(para)
msgid "I/O MMU"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml236(para)
msgid "VT-d / AMD-Vi"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml237(para)
msgid "Required for protecting PCI-passthrough"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml240(para)
msgid "Intel Trusted Execution Technology"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml241(para)
msgid "Intel TXT / SEM"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml242(para)
msgid "Required for dynamic attestation services"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml245(para)
msgid ""
"<anchor xml:id=\"PCI-SIG_I.2FO_virtualization_.28IOV.29\"/>PCI-SIG I/O "
"virtualization"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml246(para)
msgid "SR-IOV, MR-IOV, ATS"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml247(para)
msgid "Required to allow secure sharing of PCI Express devices"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml250(para)
msgid "Network virtualization"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml251(para)
msgid "VT-c"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml252(para)
msgid "Improves performance of network I/O on hypervisors"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml260(para)
msgid ""
"To wrap up our discussion around hypervisor selection, it is important to "
"call out the differences between using LXC (Linux Containers) or Baremetal "
"systems vs using a hypervisor like KVM. Specifically, the focus of this "
"security guide will be largely based on having a hypervisor and "
"virtualization platform. However, should your implementation require the use"
" of a baremetal or LXC environment, you will want to pay attention to the "
"particular differences in regard to deployment of that environment. In "
"particular, you will need to provide your end users with assurances that the"
" node has been properly sanitized of their data prior to re-provisioning. "
"Additionally, prior to reusing a node, you will need to provide assurances "
"that the hardware has not been tampered or otherwise compromised."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml261(para)
msgid ""
"It should be noted that while OpenStack has a baremetal project, a "
"discussion of the particular security implications of running baremetal is "
"beyond the scope of this book."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml262(para)
msgid ""
"Finally, due to the time constraints around a book sprint, the team chose to"
" use KVM as the hypervisor in our example implementations and architectures."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml263(para)
msgid ""
"There is an OpenStack Security Note pertaining to the <link "
"href=\"https://bugs.launchpad.net/ossn/+bug/1098582\">use of LXC in "
"Nova</link>."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml267(para)
msgid ""
"Another thing to look into when selecting a hypervisor platform is the "
"availability of specific security features. In particular, we are referring "
"to features like Xen Server's XSM or Xen Security Modules, sVirt, Intel TXT,"
" and AppArmor. The presence of these features will help increase your "
"security profile as well as provide a good foundation."
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml268(para)
msgid ""
"The following table calls out these features by common hypervisor platforms."
" "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml281(para)
#: ./doc/security-guide/ch051_vss-intro.xml293(para)
#: ./doc/security-guide/ch051_vss-intro.xml302(para)
#: ./doc/security-guide/ch051_vss-intro.xml304(para)
#: ./doc/security-guide/ch051_vss-intro.xml306(para)
#: ./doc/security-guide/ch051_vss-intro.xml307(para)
#: ./doc/security-guide/ch051_vss-intro.xml312(para)
#: ./doc/security-guide/ch051_vss-intro.xml313(para)
#: ./doc/security-guide/ch051_vss-intro.xml314(para)
#: ./doc/security-guide/ch051_vss-intro.xml316(para)
#: ./doc/security-guide/ch051_vss-intro.xml317(para)
#: ./doc/security-guide/ch051_vss-intro.xml318(para)
#: ./doc/security-guide/ch051_vss-intro.xml322(para)
#: ./doc/security-guide/ch051_vss-intro.xml323(para)
#: ./doc/security-guide/ch051_vss-intro.xml324(para)
#: ./doc/security-guide/ch051_vss-intro.xml325(para)
#: ./doc/security-guide/ch051_vss-intro.xml326(para)
#: ./doc/security-guide/ch051_vss-intro.xml327(para)
#: ./doc/security-guide/ch051_vss-intro.xml328(para)
#: ./doc/security-guide/ch012_configuration-management.xml39(para)
#: ./doc/security-guide/ch012_configuration-management.xml43(emphasis)
msgid " "
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml282(para)
msgid "KSM"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml283(para)
msgid "XSM"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml284(para)
msgid "sVirt"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml285(para)
msgid "TXT"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml286(para)
msgid "AppArmor"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml287(para)
msgid "cGroups"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml288(para)
msgid "MAC Policy"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml291(para)
msgid "KVM"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml292(para)
#: ./doc/security-guide/ch051_vss-intro.xml294(para)
#: ./doc/security-guide/ch051_vss-intro.xml295(para)
#: ./doc/security-guide/ch051_vss-intro.xml303(para)
msgid "X"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml296(address)
#: ./doc/security-guide/ch051_vss-intro.xml297(para)
#: ./doc/security-guide/ch051_vss-intro.xml298(para)
#: ./doc/security-guide/ch051_vss-intro.xml308(para)
msgid "x"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml301(para)
msgid "Xen"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml305(para)
#: ./doc/security-guide/ch051_vss-intro.xml315(para)
msgid " X"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml311(para)
msgid "ESXi"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml321(para)
msgid "Hyper-V"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml333(link)
msgid "KSM: Kernel Samepage Merging"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml334(link)
msgid "XSM: Xen Security Modules"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml335(link)
msgid "xVirt: Mandatory Access Control for Linux-based virtualization"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml336(link)
msgid "TXT: Intel Trusted Execution Technology"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml337(link)
msgid "AppArmor: Linux security module implementing MAC"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml338(link)
msgid "cgroups: Linux kernel feature to control resource usage"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml339(para)
msgid ""
"MAC Policy: Mandatory Access Control; may be implemented with SELinux or "
"other operating systems"
msgstr ""
#: ./doc/security-guide/ch051_vss-intro.xml340(para)
msgid ""
"* Features in this table may not be applicable to all hypervisors or "
"directly mappable between hypervisors."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml3(title)
msgid "Introduction to SSL/TLS"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml4(para)
msgid ""
"OpenStack services receive requests on behalf of users on public networks as"
" well as from other internal services over management networks. Inter-"
"service communications can also occur over public networks depending on "
"deployment and architecture choices."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml5(para)
msgid ""
"While it is commonly accepted that data over public networks should be "
"secured using cryptographic measures, such as Secure Sockets Layer or "
"Transport Layer Security (SSL/TLS) protocols, it is insufficient to rely on "
"security domain separation to protect internal traffic. Using a security-in-"
"depth approach, we recommend securing all domains with SSL/TLS, including "
"the management domain services. It is important that should a tenant escape "
"their VM isolation and gain access to the hypervisor or host resources, "
"compromise an API endpoint, or any other service, they must not be able to "
"easily inject or capture messages, commands, or otherwise affect or control "
"management capabilities of the cloud. SSL/TLS provides the mechanisms to "
"ensure authentication, non-repudiation, confidentiality, and integrity of "
"user communications to the OpenStack services and between the OpenStack "
"services themselves."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml6(para)
msgid ""
"Public Key Infrastructure (PKI) is the set of hardware, software, and "
"policies to operate a secure system which provides authentication, non-"
"repudiation, confidentiality, and integrity. The core components of PKI are:"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml8(para)
msgid ""
"End Entity - user, process, or system that is the subject of a certificate"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml11(para)
msgid ""
"Certification Authority (<glossterm>CA</glossterm>) - defines certificate "
"policies, management, and issuance of certificates"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml14(para)
msgid ""
"Registration Authority (RA) - an optional system to which a CA delegates "
"certain management functions"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml17(para)
msgid ""
"Repository - Where the end entity certificates and certificate revocation "
"lists are stored and looked up - sometimes referred to as the \"certificate "
"bundle\""
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml20(para)
msgid "Relying Party - The end point that is trusting that the CA is valid."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml23(para)
msgid ""
"PKI builds the framework on which to provide encryption algorithms, cipher "
"modes, and protocols for securing data and authentication. We strongly "
"recommend securing all services with Public Key Infrastructure (PKI), "
"including the use of SSL/TLS for API endpoints. It is impossible for the "
"encryption or signing of transports or messages alone to solve all these "
"problems. Hosts themselves must be secure and implement policy, namespaces, "
"and other controls to protect their private credentials and keys. However, "
"the challenges of key management and protection do not reduce the necessity "
"of these controls, or lessen their importance."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml25(title)
msgid "Certification Authorities"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml26(para)
msgid ""
"Many organizations have an established Public Key Infrastructure with their "
"own certification authority (CA), certificate policies, and management for "
"which they should use to issue certificates for internal OpenStack users or "
"services. Organizations in which the public security domain is Internet "
"facing will additionally need certificates signed by a widely recognized "
"public CA. For cryptographic communications over the management network, it "
"is recommended one not use a public CA. Instead, we expect and recommend "
"most deployments deploy their own internal CA."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml27(para)
msgid ""
"It is recommended that the OpenStack cloud architect consider using separate"
" PKI deployments for internal systems and customer facing services. This "
"allows the cloud deployer to maintain control of their PKI infrastructure "
"and among other things makes requesting, signing and deploying certificates "
"for internal systems easier. Advanced configurations may use separate PKI "
"deployments for different security domains. This allows deployers to "
"maintain cryptographic separation of environments, ensuring that "
"certificates issued to one are not recognised by another."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml28(para)
msgid ""
"Certificates used to support SSL/TLS on internet facing cloud endpoints (or "
"customer interfaces where the customer is not expected to have installed "
"anything other than standard operating system provided certificate bundles) "
"should be provisioned using Certificate Authorities that are installed in "
"the operating system certificate bundle. Typical well known vendors include "
"Verisign and Thawte but many others exist."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml29(para)
msgid ""
"There are many management, policy, and technical challenges around creating "
"and signing certificates as such is an area where cloud architects or "
"operators may wish to seek the advice of industry leaders and vendors in "
"addition to the guidance recommended here."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml32(title)
msgid "SSL/TLS Libraries"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml33(para)
msgid ""
"Various components, services, and applications within the OpenStack "
"ecosystem or dependencies of OpenStack are implemented and can be configured"
" to use SSL/TLS libraries. The SSL/TLS and HTTP services within OpenStack "
"are typically implemented using OpenSSL which has been proven to be fairly "
"secure and has a module that has been validated for FIPS 140-2. However, "
"keep in mind that each application or service can still introduce weaknesses"
" in how they use the OpenSSL libraries."
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml36(title)
msgid "Cryptographic Algorithms, Cipher Modes, and Protocols"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml37(para)
msgid ""
"We recommend only using TLS v1.1 or v1.2. SSLv3 and TLSv1.0 may be used for "
"compatibility but we recommend using caution and only enabling these "
"protocols if you have a strong requirement to do so. Other SSL/TLS versions,"
" explicitly older versions, should not be used. These older versions include"
" SSLv1 and SSLv2. As this book does not intend to be a thorough reference on"
" cryptography we do not wish to be prescriptive about what specific "
"algorithms or cipher modes you should enable or disable in your OpenStack "
"services. However, there are some authoritative references we would like to "
"recommend for further information:"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml39(link)
msgid "National Security Agency, Suite B Cryptography"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml42(link)
msgid "OWASP Guide to Cryptography"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml45(link)
msgid "OWASP Transport Layer Protection Cheat Sheet"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml48(link)
msgid ""
"SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate "
"trust model enhancements"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml51(link)
msgid ""
"The Most Dangerous Code in the World: Validating SSL Certificates in Non-"
"Browser Software"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml54(link)
msgid "OpenSSL and FIPS 140-2"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml59(title)
msgid "Summary"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml60(para)
msgid ""
"Given the complexity of the OpenStack components and the number of "
"deployment possibilities, you must take care to ensure that each component "
"gets the appropriate configuration of SSL certificates, keys, and CAs. The "
"following services will be discussed in later sections of this book where "
"SSL and PKI is available (either natively or possible via SSL proxy):"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml62(para)
msgid "Compute API endpoints"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml65(para)
msgid "Identity API endpoints"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml68(para)
msgid "Networking API endpoints"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml71(para)
msgid "Storage API endpoints"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml74(para)
msgid "Messaging server"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml77(para)
msgid "Database server"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml80(para)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml23(title)
#: ./doc/security-guide/ch004_book-introduction.xml103(title)
#: ./doc/security-guide/ch025_web-dashboard.xml3(title)
msgid "Dashboard"
msgstr ""
#: ./doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml83(para)
msgid ""
"Throughout this book we will use SSL as shorthand to refer to these "
"recommendations for SSL/TLS protocols."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml3(title)
msgid "Continuous Systems Management"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml4(para)
msgid ""
"A cloud will always have bugs. Some of these will be security problems. For "
"this reason, it is critically important to be prepared to apply security "
"updates and general software updates. This involves smart use of "
"configuration management tools, which are discussed below. This also "
"involves knowing when an upgrade is necessary."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml6(title)
#: ./doc/security-guide/ch063_compliance-activities.xml43(title)
msgid "Vulnerability Management"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml7(para)
msgid ""
"For announcements regarding security relevant changes, subscribe to the "
"<link href=\"http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-"
"announce\">OpenStack Announce mailing list</link>. The security "
"notifications are also posted through the downstream packages for example "
"through Linux distributions that you may be subscribed to as part of the "
"package updates."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml12(para)
msgid ""
"The OpenStack components are only a small fraction of the software in a "
"cloud. It is important to keep up to date with all of these other "
"components, too. While the specific data sources will be deployment "
"specific, the key idea is to ensure that a cloud administrator subscribes to"
" the necessary mailing lists for receiving notification of any related "
"security updates. Often this is as simple as tracking an upstream Linux "
"distribution."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml15(para)
msgid ""
"OpenStack Security Advisories (OSSA) are created by the OpenStack "
"Vulnerability Management Team (VMT). They pertain to security holes in core "
"OpenStack services. More information on the VMT can be found here: <link "
"href=\"https://wiki.openstack.org/wiki/Vulnerability_Management\">https://wiki.openstack.org/wiki/Vulnerability_Management</link>"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml19(para)
msgid ""
"OpenStack Security Notes (OSSN) were created by the OpenStack Security Group"
" (OSSG) to support the work of the VMT. OSSN address issues in supporting "
"software and common deployment configurations. They're referenced throughout"
" this guide. Security Notes are archived at <link "
"href=\"https://launchpad.net/ossn/\">https://launchpad.net/ossn/</link>"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml13(para)
msgid ""
"OpenStack releases security information through two channels. "
"<placeholder-1/>"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml29(title)
msgid "Triage"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml30(para)
msgid ""
"After receiving notification about a security update, the next step is to "
"determine how critical this update is to a given cloud deployment. In this "
"case, it is useful to have a pre-defined policy. Existing vulnerability "
"rating systems such as the common vulnerability scoring system (CVSS) v2 do "
"not properly account for cloud deployments."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml31(para)
msgid ""
"In this example we introduce a scoring matrix that places vulnerabilities in"
" three categories: Privilege Escalation, Denial of Service and Information "
"Disclosure. Understanding the type of vulnerability and where it occurs in "
"your infrastructure will enable you to make reasoned response decisions."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml32(para)
msgid ""
"Privilege Escalation describes the ability of a user to act with the "
"privileges of some other user in a system, bypassing appropriate "
"authorization checks. For example a standard Linux user running code or "
"performing an operation that allows them to conduct further operations with "
"the privileges of the root users on the system."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml33(para)
msgid ""
"Denial of Service refers to an exploited vulnerability that may cause "
"service or system disruption. This includes both distributed attacks to "
"overwhelm network resources, and single-user attacks that are typically "
"caused through resource allocation bugs or input induced system failure "
"flaws."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml34(para)
msgid ""
"Information Disclosure vulnerabilities reveal information about your system "
"or operations. These vulnerabilities range from debugging information "
"disclosure, to exposure of critical security data, such as authentication "
"credentials and passwords."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml40(emphasis)
msgid "Attacker Position / Privilege Level"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml44(emphasis)
msgid "External"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml45(emphasis)
msgid "Cloud User"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml46(emphasis)
msgid "Cloud Admin"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml47(emphasis)
msgid "Control Plane"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml50(emphasis)
msgid "Privilege Elevation (3 levels)"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml51(para)
#: ./doc/security-guide/ch012_configuration-management.xml58(para)
#: ./doc/security-guide/ch012_configuration-management.xml59(para)
#: ./doc/security-guide/ch012_configuration-management.xml65(para)
#: ./doc/security-guide/ch012_configuration-management.xml66(para)
#: ./doc/security-guide/ch012_configuration-management.xml67(para)
msgid "Critical"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml52(para)
#: ./doc/security-guide/ch012_configuration-management.xml53(para)
#: ./doc/security-guide/ch012_configuration-management.xml54(para)
#: ./doc/security-guide/ch012_configuration-management.xml60(para)
#: ./doc/security-guide/ch012_configuration-management.xml61(para)
#: ./doc/security-guide/ch012_configuration-management.xml68(para)
msgid "n/a"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml57(emphasis)
msgid "Privilege Elevation (2 levels)"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml64(emphasis)
msgid "Privilege Elevation (1 level)"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml71(emphasis)
msgid "Denial of Service"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml72(para)
msgid "High"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml73(para)
msgid "Medium"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml74(para)
#: ./doc/security-guide/ch012_configuration-management.xml75(para)
#: ./doc/security-guide/ch012_configuration-management.xml82(para)
msgid "Low"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml78(emphasis)
msgid "Information Disclosure"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml79(para)
#: ./doc/security-guide/ch012_configuration-management.xml80(para)
msgid "Critical / High"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml81(para)
msgid "Medium / Low"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml86(para)
msgid ""
"The above table illustrates a generic approach to measuring the impact of a "
"vulnerability based on where it occurs in your deployment and the effect; "
"for example, a single level privilege escalation on a Compute API node would"
" potentially allow a standard user of the API to escalate to have the same "
"privileges as the root user on the node."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml87(para)
msgid ""
"We suggest cloud administrators customize and expand this table to suit "
"their needs. Then work to define how to handle the various severity levels. "
"For example, a critical-level security update might require the cloud to be "
"upgraded on a specified time line, whereas a low-level update might be more "
"relaxed."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml90(title)
msgid "Testing the Updates"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml91(para)
msgid ""
"Any update should be fully tested before deploying in a production "
"environment. Typically this requires having a separate test cloud setup that"
" first receives the update.  This cloud should be as close to the production"
" cloud as possible, in terms of software and hardware. Updates should be "
"tested thoroughly in terms of performance impact, stability, application "
"impact, and more. Especially important is to verify that the problem "
"theoretically addressed by the update (e.g., a specific vulnerability) is "
"actually fixed."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml94(title)
msgid "Deploying the Updates"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml95(para)
msgid ""
"Once the updates are fully tested, they can be deployed to the production "
"environment. This deployment should be fully automated using the "
"configuration management tools described below."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml99(title)
msgid "Configuration Management"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml100(para)
msgid ""
"A production quality cloud should always use tools to automate configuration"
" and deployment. This eliminates human error, and allows the cloud to scale "
"much more rapidly. Automation also helps with continuous integration and "
"testing."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml101(para)
msgid ""
"When building an OpenStack cloud it is strongly recommended to approach your"
" design and implementation with a configuration management tool or framework"
" in mind. Configuration management allows you to avoid the many pitfalls "
"inherent in building, managing, and maintaining an infrastructure as complex"
" as OpenStack. By producing the manifests, cookbooks, or templates required "
"for a configuration management utility, you are able to satisfy a number of "
"documentation and regulatory reporting requirements. Further, configuration "
"management can also function as part of your BCP and DR plans wherein you "
"can rebuild a node or service back to a known state in a DR event or given a"
" compromise."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml102(para)
msgid ""
"Additionally, when combined with a version control system such as Git or "
"SVN, you can track changes to your environment over time and remediate "
"unauthorized changes that may occur. For example, a nova.conf or other "
"configuration file falls out of compliance with your standard, your "
"configuration management tool will be able to revert or replace the file and"
" bring your configuration back into a known state. Finally a configuration "
"management tool can also be used to deploy updates; simplifying the security"
" patch process. These tools have a broad range of capabilities that are "
"useful in this space. The key point for securing your cloud is to choose a "
"tool for configuration management and use it."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml103(para)
msgid ""
"There are many configuration management solutions; at the time of this "
"writing there are two in the marketplace that are robust in their support of"
" OpenStack environments: <glossterm>Chef</glossterm> and "
"<glossterm>Puppet</glossterm>. A non-exhaustive listing of tools in this "
"space is provided below:"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml105(para)
msgid "Chef"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml108(para)
msgid "Puppet"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml111(para)
msgid "Salt Stack"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml114(para)
msgid "Ansible"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml118(title)
msgid "Policy Changes"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml119(para)
msgid ""
"Whenever a policy or configuration management is changed, it is good "
"practice to log the activity, and backup a copy of the new set. Often, such "
"policies and configurations are stored in a version controlled repository "
"such as git."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml123(title)
msgid "Secure Backup and Recovery"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml124(para)
msgid ""
"It is important to include Backup procedures and policies in the overall "
"System Security Plan. For a good overview of OpenStack's Backup and Recovery"
" capabilities and procedures, please refer to the OpenStack Operations "
"Guide."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml126(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml45(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml82(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml113(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml132(title)
#: ./doc/security-guide/ch026_compute.xml23(title)
#: ./doc/security-guide/ch026_compute.xml57(title)
msgid "Security Considerations"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml128(para)
msgid ""
"Ensure only authenticated users and backup clients have access to the backup"
" server."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml131(para)
msgid "Use data encryption options for storage and transmission of backups."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml134(para)
msgid ""
"Use a dedicated and hardened backup server(s). The backup server's logs "
"should be monitored daily and should be accessible by only few individuals."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml137(para)
msgid ""
"Test data recovery options regularly. One of the things that can be restored"
" from secured backups is the images. In case of a compromise, the best "
"practice would be to terminate running instances immediately and then "
"relaunch the instances from the images in the secured backup repository."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml142(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml64(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml123(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml149(title)
#: ./doc/security-guide/ch026_compute.xml33(title)
#: ./doc/security-guide/ch026_compute.xml70(title)
#: ./doc/security-guide/ch058_forensicsincident-response.xml43(title)
msgid "References"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml144(para)
msgid ""
"<citetitle>OpenStack Operations Guide</citetitle> on <link "
"href=\"http://docs.openstack.org/trunk/openstack-"
"ops/content/backup_and_recovery.html\">backup and recovery</link>"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml147(link)
msgid ""
"http://www.sans.org/reading_room/whitepapers/backup/security-considerations-"
"enterprise-level-backups_515"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml150(link)
msgid "OpenStack Security Primer"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml156(title)
msgid "Security Auditing Tools"
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml157(para)
msgid ""
"Security auditing tools can complement the configuration management tools.  "
"Security auditing tools automate the process of verifying that a large "
"number of security controls are satisfied for a given system configuration. "
"These tools help to bridge the gap from security configuration guidance "
"documentation (for example, the STIG and NSA Guides) to a specific system "
"installation. For example, <link href=\"https://fedorahosted.org/scap-"
"security-guide/\">SCAP</link> can compare a running system to a pre-defined "
"profile. SCAP outputs a report detailing which controls in the profile were "
"satisfied, which ones failed, and which ones were not checked."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml158(para)
msgid ""
"Combining configuration management and security auditing tools creates a "
"powerful combination. The auditing tools will highlight deployment concerns."
" And the configuration management tools simplify the process of changing "
"each system to address the audit concerns. Used together in this fashion, "
"these tools help to maintain a cloud that satisfies security requirements "
"ranging from basic hardening to compliance validation."
msgstr ""
#: ./doc/security-guide/ch012_configuration-management.xml159(para)
msgid ""
"Configuration management and security auditing tools will introduce another "
"layer of complexity into the cloud.  This complexity brings with it "
"additional security concerns. We view this as an acceptable risk trade-off, "
"given their security benefits. Securing the operational use of these tools "
"is beyond the scope of this guide."
msgstr ""
#: ./doc/security-guide/ch059_case-studies-monitoring-logging.xml3(title)
msgid "Case Studies: Monitoring and Logging"
msgstr ""
#: ./doc/security-guide/ch059_case-studies-monitoring-logging.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address monitoring and"
" logging in the public vs a private cloud. In both instances, time "
"synchronization and a centralized store of logs become extremely important "
"for performing proper assessments and troubleshooting of anomalies. Just "
"collecting logs is not very useful, a robust monitoring system must be built"
" to generate actionable events."
msgstr ""
#: ./doc/security-guide/ch059_case-studies-monitoring-logging.xml6(title)
#: ./doc/security-guide/ch039_case-studies-messaging.xml6(title)
#: ./doc/security-guide/ch066_case-studies-compliance.xml6(title)
#: ./doc/security-guide/ch028_case-studies-identity-management.xml6(title)
#: ./doc/security-guide/ch044_case-studies-database.xml6(title)
#: ./doc/security-guide/ch009_case-studies.xml6(title)
#: ./doc/security-guide/ch056_case-studies-instance-management.xml6(title)
#: ./doc/security-guide/ch022_case-studies-api-endpoints.xml6(title)
#: ./doc/security-guide/ch015_case-studies-management.xml29(title)
#: ./doc/security-guide/ch018_case-studies-pkissl.xml6(title)
#: ./doc/security-guide/ch035_case-studies-networking.xml6(title)
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml6(title)
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml6(title)
msgid "Alice's Private Cloud"
msgstr ""
#: ./doc/security-guide/ch059_case-studies-monitoring-logging.xml7(para)
msgid ""
"In the private cloud, Alice has a better understanding of the tenants "
"requirements and accordingly can add appropriate oversight and compliance on"
" monitoring and logging. Alice should identify critical services and data "
"and ensure that logging is turned at least on those services and is being "
"aggregated to a central log server. She should start with simple and known "
"use cases and implement correlation and alerting to limit the number of "
"false positives. To implement correlation and alerting, she sends the log "
"data to her organization's existing SIEM tool. Security monitoring should be"
" an ongoing process and she should continue to define use cases and alerts "
"as she has better understanding of the network traffic activity and usage "
"over time."
msgstr ""
#: ./doc/security-guide/ch059_case-studies-monitoring-logging.xml10(title)
#: ./doc/security-guide/ch039_case-studies-messaging.xml10(title)
#: ./doc/security-guide/ch066_case-studies-compliance.xml13(title)
#: ./doc/security-guide/ch028_case-studies-identity-management.xml12(title)
#: ./doc/security-guide/ch044_case-studies-database.xml10(title)
#: ./doc/security-guide/ch009_case-studies.xml11(title)
#: ./doc/security-guide/ch056_case-studies-instance-management.xml12(title)
#: ./doc/security-guide/ch022_case-studies-api-endpoints.xml10(title)
#: ./doc/security-guide/ch015_case-studies-management.xml34(title)
#: ./doc/security-guide/ch018_case-studies-pkissl.xml10(title)
#: ./doc/security-guide/ch035_case-studies-networking.xml24(title)
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml23(title)
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml12(title)
msgid "Bob's Public Cloud"
msgstr ""
#: ./doc/security-guide/ch059_case-studies-monitoring-logging.xml11(para)
msgid ""
"When it comes to logging, as a public cloud provider, Bob is interested in "
"logging both for situational awareness as well as compliance. That is, "
"compliance that Bob as a provider is subject to as well as his ability to "
"provide timely and relevant logs or reports on the behalf of his customers "
"for their compliance audits. With that in mind, Bob configures all of his "
"instances, nodes, and infrastructure devices to perform time synchronization"
" with an external, known good time device. Additionally, Bob's team has "
"built a Django based web applications for his customers to perform self-"
"service log retrieval from Bob's SIEM tool. Bob also uses this SIEM tool "
"along with a robust set of alerts and integration with his CMDB to provide "
"operational awareness to both customers and cloud administrators."
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml6(title)
msgid "OpenStack Security Guide"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml14(orgname)
#: ./doc/security-guide/bk_openstack-sec-guide.xml19(holder)
msgid "OpenStack Foundation"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml18(year)
msgid "2013"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml21(releaseinfo)
msgid "havana"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml22(productname)
msgid "OpenStack"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml26(remark)
msgid "Copyright details are filled in by the template."
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml31(para)
msgid ""
"This book provides best practices and conceptual information about securing "
"an OpenStack cloud."
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml38(date)
msgid "2013-12-02"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml42(para)
msgid "Chapter on Object Storage added."
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml48(date)
msgid "2013-10-17"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml52(para)
msgid "Havana release."
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml58(date)
msgid "2013-07-02"
msgstr ""
#: ./doc/security-guide/bk_openstack-sec-guide.xml62(para)
msgid "Initial creation..."
msgstr ""
#: ./doc/security-guide/ch065_privacy.xml3(title)
msgid "Privacy"
msgstr ""
#: ./doc/security-guide/ch065_privacy.xml4(para)
msgid ""
"Privacy is an increasingly important element of a compliance program. "
"Businesses are being held to a higher standard by their customers, who have "
"increased interest in understanding how their data is treated from a privacy"
" perspective."
msgstr ""
#: ./doc/security-guide/ch065_privacy.xml5(para)
msgid ""
"An OpenStack deployment will likely need to demonstrate compliance with an "
"organization’s Privacy Policy, with the U.S. – E.U. Safe Harbor framework, "
"the ISO/IEC 29100:2011 privacy framework or with other privacy-specific "
"guidelines. In the U.S. the AICPA has <link "
"href=\"http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/generallyacceptedprivacyprinciples/\">defined"
" 10 privacy areas of focus</link>, OpenStack deployments within a commercial"
" environment may desire to attest to some or all of these principles."
msgstr ""
#: ./doc/security-guide/ch065_privacy.xml6(para)
msgid ""
"To aid OpenStack architects in the protection of personal data, it is "
"recommended that OpenStack architects review the NIST publication 800-122, "
"titled \"<emphasis>Guide to Protecting the Confidentiality of Personally "
"Identifiable Information (PII)</emphasis>.\" This guide steps through the "
"process of protecting:"
msgstr ""
#: ./doc/security-guide/ch065_privacy.xml8(para)
msgid ""
"\"<emphasis>any information about an individual maintained by an agency, "
"including (1) any information that can be used to distinguish or trace an "
"individual‘s identity, such as name, social security number, date and place "
"of birth, mother‘s maiden name, or biometric records; and (2) any other "
"information that is linked or linkable to an individual, such as medical, "
"educational, financial, and employment information</emphasis>\""
msgstr ""
#: ./doc/security-guide/ch065_privacy.xml10(para)
msgid ""
"Comprehensive privacy management requires significant preparation, thought "
"and investment. Additional complications are introduced when building global"
" OpenStack clouds, for example navigating the differences between U.S. and "
"more restrictive E.U. privacy laws. In addition, extra care needs to be "
"taken when dealing with sensitive PII that may include information such as "
"credit card numbers or medical records. This sensitive data is not only "
"subject to privacy laws but also regulatory and governmental regulations. By"
" deferring to established best practices, including those published by "
"governments, a holistic privacy management policy may be created and "
"practiced for OpenStack deployments."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml3(title)
msgid "Networking Services"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml4(para)
msgid ""
"In the initial architectural phases of designing your OpenStack Network "
"infrastructure it is important to ensure appropriate expertise is available "
"to assist with the design of the physical networking infrastructure, to "
"identify proper security controls and auditing mechanisms."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml5(para)
msgid ""
"OpenStack Networking adds a layer of virtualized network services - giving "
"tenants the capability to architect their own, virtual networks. These "
"virtualized services are not as currently as mature as their traditional "
"networking counterparts. It is important to be aware of the current state of"
" these virtualized services and what controls may need to be implemented at "
"the virtualized and traditional network boundary."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml7(title)
msgid "L2 Isolation using VLANs and Tunneling"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml8(para)
msgid ""
"OpenStack networking can employ two different mechanisms for traffic "
"segregation on a per tenant/network combination: VLANs (IEEE 802.1Q tagging)"
" or L2 tunnels using GRE encapsulation. Which method you choose for traffic "
"segregation and isolation is determined by the scope and scale of your "
"OpenStack deployment."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml10(title)
msgid "VLANs"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml11(para)
msgid ""
"VLANs are realized as packets on a specific physical network containing IEEE"
" 802.1Q headers with a specific VLAN ID (VID) field value. VLAN networks "
"sharing the same physical network are isolated from each other at L2, and "
"can even have overlapping IP address spaces. Each distinct physical network "
"supporting VLAN networks is treated as a separate VLAN trunk, with a "
"distinct space of VID values. Valid VID values are 1 through 4094."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml12(para)
msgid ""
"VLAN configuration complexity depends on your OpenStack design requirements."
" In order to allow OpenStack Networking to efficiently use VLANs, you must "
"allocate a VLAN range (one for each tenant) and turn each compute node "
"physical switch port into a VLAN trunk port."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml14(para)
msgid ""
"NOTE: If you intend for your network to support more than 4094 tenants VLAN "
"is probably not the correct option for you as multiple 'hacks' are required "
"to extend the VLAN tags to more than 4094 tenants."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml18(title)
msgid "L2 Tunneling"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml19(para)
msgid ""
"Network tunneling encapsulates each tenant/network combination with a unique"
" \"tunnel-id\" that is used to identify the network traffic belonging to "
"that combination. The tenant's L2 network connectivity is independent of "
"physical locality or underlying network design. By encapsulating traffic "
"inside IP packets, that traffic can cross Layer-3 boundaries, removing the "
"need for preconfigured VLANs and VLAN trunking. Tunneling adds a layer of "
"obfuscation to network data traffic, reducing the visibility of individual "
"tenant traffic from a monitoring point of view."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml20(para)
msgid ""
"OpenStack Networking currently only supports GRE encapsulation with planned "
"future support of VXLAN due in the Havana release."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml21(para)
msgid ""
"The choice of technology to provide L2 isolation is dependent upon the scope"
" and size of tenant networks that will be created in your deployment. If "
"your environment has limited VLAN ID availability or will have a large "
"number of L2 networks, it is our recommendation that you utilize tunneling."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml25(title)
msgid "Network Services"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml26(para)
msgid ""
"The choice of tenant network isolation affects how the network security and "
"control boundary is implemented for tenant services. The following "
"additional network services are either available or currently under "
"development to enhance the security posture of the OpenStack network "
"architecture."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml28(title)
msgid "Access Control Lists"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml29(para)
msgid ""
"OpenStack Compute supports tenant network traffic access controls directly "
"when deployed with the legacy nova-network service, or may defer access "
"control to the OpenStack Networking service."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml30(para)
msgid ""
"Note, legacy nova-network security groups are applied to all virtual "
"interface ports on an instance using IPTables."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml31(para)
msgid ""
"Security groups allow administrators and tenants the ability to specify the "
"type of traffic, and direction (ingress/egress) that is allowed to pass "
"through a virtual interface port. Security groups rules are stateful L2-L4 "
"traffic filters."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml32(para)
msgid ""
"It is our recommendation that you enable security groups via OpenStack "
"Networking."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml35(title)
msgid "L3 Routing and NAT"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml36(para)
msgid ""
"OpenStack Networking routers can connect multiple L2 networks, and can also "
"provide a <emphasis>gateway</emphasis> that connects one or more private L2 "
"networks to a shared <emphasis>external</emphasis> network, such as a public"
" network for access to the Internet."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml37(para)
msgid ""
"The L3 router provides basic Network Address Translation (NAT) capabilities "
"on <emphasis>gateway</emphasis> ports that uplink the router to external "
"networks. This router SNATs (Static NAT) all traffic by default, and "
"supports floating IPs, which creates a static one-to-one mapping from a "
"public IP on the external network to a private IP on one of the other "
"subnets attached to the router."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml38(para)
msgid ""
"It is our recommendation to leverage per tenant L3 routing and Floating IPs "
"for more granular connectivity of tenant VMs."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml41(title)
msgid "Quality of Service (QoS)"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml42(para)
msgid ""
"The ability to set QoS on the virtual interface ports of tenant instances is"
" a current deficiency for OpenStack Networking. The application of QoS for "
"traffic shaping and rate-limiting at the physical network edge device is "
"insufficient due to the dynamic nature of workloads in an OpenStack "
"deployment and can not be leveraged in the traditional way.  QoS-"
"as-a-Service (QoSaaS) is currently in development for the OpenStack "
"Networking Havana release as an experimental feature. QoSaaS is planning to "
"provide the following services:"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml44(para)
msgid "Traffic shaping via DSCP markings"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml47(para)
msgid "Rate-limiting on a per port/network/tenant basis."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml50(para)
msgid "Port mirroring (via open source or third-party plugins)"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml53(para)
msgid "Flow analysis (via open source or third-party plugins)"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml56(para)
msgid ""
"Tenant traffic port mirroring or Network Flow monitoring is currently not an"
" exposed feature in OpenStack Networking. There are third-party plugin "
"extensions that do provide Port Mirroring on a per port/network/tenant "
"basis. If Open vSwitch is used on the networking hypervisor, it is possible "
"to enable sFlow and port mirroring, however it will require some operational"
" effort to implement."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml59(title)
msgid "Load Balancing"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml60(para)
msgid ""
"An experimental feature in the Grizzly release of OpenStack Networking is "
"Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and "
"vendors a chance to build implementations of the technology. The reference "
"implementation however, is still experimental and should likely not be run "
"in a production environment. The current reference implementation is based "
"on HA-Proxy. There are third-party plugins in development for extensions in "
"OpenStack Networking to provide extensive L4-L7 functionality for virtual "
"interface ports."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml63(title)
msgid "Firewalls"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml64(para)
msgid ""
"FW-as-a-Service (FWaaS) is currently in development for the OpenStack "
"Networking Havana release as an experimental feature. FWaaS will address the"
" need to manage and leverage the rich set of security features provided by "
"typical firewall products which are typically far more comprehensive than "
"what is currently provided by security groups. There are third-party plugins"
" in development for extensions in OpenStack Networking to support this."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml65(para)
msgid ""
"It is critical during the design of an OpenStack Networking infrastructure "
"to understand the current features and limitations of network services that "
"are available. Understanding where the boundaries of your virtual and "
"physical networks will help you add the required security controls in your "
"environment."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml69(title)
msgid "Network Services Extensions"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml70(para)
msgid ""
"Here is a list of known plugins provided by the open source community or by "
"SDN companies that work with OpenStack Networking:"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml71(para)
msgid ""
"Big Switch Controller Plugin, Brocade Neutron Plugin Brocade Neutron Plugin,"
" Cisco UCS/Nexus Plugin, Cloudbase Hyper-V Plugin, Extreme Networks Plugin, "
"Juniper Networks Neutron Plugin, Linux Bridge Plugin, Mellanox Neutron "
"Plugin, MidoNet Plugin, NEC OpenFlow Plugin, Nicira Network Virtualization "
"Platform (NVP) Plugin, Open vSwitch Plugin, PLUMgrid Plugin, Ruijie Networks"
" Plugin, Ryu OpenFlow Controller Plugin"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml72(para)
msgid ""
"For a more detailed comparison of all features provided by plugins as of the"
" Folsom release, see <link href=\"http://www.sebastien-"
"han.fr/blog/2012/09/28/quantum-plugin-comparison/\">Sebastien Han's "
"comparison</link>."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml75(title)
msgid "Networking Services Limitations"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml76(para)
msgid "OpenStack Networking has the following known limitations:"
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml78(para)
msgid ""
"<emphasis role=\"bold\">Overlapping IP addresses</emphasis> — If nodes that "
"run either <literal>neutron-l3-agent</literal> or <literal>neutron-dhcp-"
"agent</literal> use overlapping IP addresses, those nodes must use Linux "
"network namespaces. By default, the DHCP and L3 agents use Linux network "
"namespaces. However, if the host does not support these namespaces, run the "
"DHCP and L3 agents on different hosts."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml79(para)
msgid ""
"If network namespace support is not present, a further limitation of the L3 "
"Agent is that only a single logical router is supported."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml82(para)
msgid ""
"<emphasis role=\"bold\">Multi-Host DHCP-agent</emphasis> — OpenStack "
"Networking supports multiple l3-agent and dhcp-agents with load balancing. "
"However, tight coupling of the location of the virtual machine is not "
"supported."
msgstr ""
#: ./doc/security-guide/ch032_networking-best-practices.xml85(para)
msgid ""
"<emphasis role=\"bold\">No IPv6 Support for L3 agents</emphasis> — The "
"neutron-l3-agent, used by many plugins to implement L3 forwarding, supports "
"only IPv4 forwarding."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch055_security-services-for-instances.xml47(None)
#: ./doc/security-guide/ch055_security-services-for-instances.xml50(None)
msgid ""
"@@image: 'static/filteringWorkflow1.png'; "
"md5=c144af5cbdee1bd17a7bde0bea5b5fe7"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml3(title)
msgid "Security Services for Instances"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml4(para)
msgid ""
"One of the virtues of running instances in a virtualized environments is "
"that it opens up new opportunities for security controls that are not "
"typically available when deploying onto bare metal. There are several "
"technologies that can be applied to the virtualization stack that bring "
"improved information assurance for cloud tenants."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml5(para)
msgid ""
"Deployers or users of OpenStack with strong security requirements may want "
"to consider deploying these technologies. Not all are applicable in every "
"situation, indeed in some cases technologies may be ruled out for use in a "
"cloud because of prescriptive business requirements. Similarly some "
"technologies inspect instance data such as run state which may be "
"undesirable to the users of the system."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml6(para)
msgid ""
"In this chapter we explore these technologies and describe the situations "
"where they can be used to enhance security for instances or underlying "
"instances. We also seek to highlight where privacy concerns may exist. These"
" include data pass through, introspection, or providing a source of entropy."
" In this section we highlight the following additional security services:"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml8(para)
msgid "Entropy to Instances"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml11(para)
#: ./doc/security-guide/ch055_security-services-for-instances.xml28(title)
msgid "Scheduling Instances to Nodes"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml14(para)
#: ./doc/security-guide/ch055_security-services-for-instances.xml88(title)
msgid "Trusted Images"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml17(para)
#: ./doc/security-guide/ch055_security-services-for-instances.xml153(title)
msgid "Instance Migrations"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml21(title)
msgid "Entropy To Instances"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml22(para)
msgid ""
"We consider entropy to refer to the quality and source of random data that "
"is available to an instance. Cryptographic technologies typically rely "
"heavily on randomness, requiring a high quality pool of entropy to draw "
"from. It is typically hard for a virtual machine to get enough entropy to "
"support these operations. Entropy starvation can manifest in instances as "
"something seemingly unrelated for example, slow boot times because the "
"instance is waiting for ssh key generation. Entropy starvation may also "
"motivate users to employ poor quality entropy sources from within the "
"instance, making applications running in the cloud less secure overall."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml23(para)
msgid ""
"Fortunately, a cloud architect may address these issues by providing a high "
"quality source of entropy to the cloud instances. This can be done by having"
" enough hardware random number generators (HRNG) in the cloud to support the"
" instances. In this case, \"enough\" is somewhat domain specific. For "
"everyday operations, a modern HRNG is likely to produce enough entropy to "
"support 50-100 compute nodes. High bandwidth HRNGs, such as the RdRand "
"instruction available with Intel Ivy Bridge and newer processors could "
"potentially handle more nodes. For a given cloud, an architect needs to "
"understand the application requirements to ensure that sufficient entropy is"
" available."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml24(para)
msgid ""
"Once the entropy is available in the cloud, the next step is getting that "
"entropy into the instances. Tools such as the entropy gathering daemon "
"(<link href=\"http://egd.sourceforge.net/\">EGD</link>) provide a way to "
"fairly and securely distribute entropy through a distributed system. Support"
" exists for using the EGD as an entropy source for LibVirt."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml25(para)
msgid ""
"Compute support for these features is not generally available, but it would "
"only require a moderate amount of work for implementors to integrate this "
"functionality."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml29(para)
msgid ""
"Before an instance is created, a host for the image instantiation must be "
"selected. This selection is performed by the <systemitem class=\"service"
"\">nova-scheduler</systemitem> which determines how to dispatch compute and "
"volume requests."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml30(para)
msgid ""
"The default nova scheduler in Grizzly is the Filter Scheduler, although "
"other schedulers exist (see the section <link "
"href=\"http://docs.openstack.org/trunk/config-reference/content"
"/section_compute-scheduler.html\">Scheduling</link> in the "
"<citetitle>OpenStack Configuration Reference</citetitle>). The filter "
"scheduler works in collaboration with 'filters' to decide where an instance "
"should be started. This process of host selection allows administrators to "
"fulfil many different security requirements. Depending on the cloud "
"deployment type for example, one could choose to have tenant instances "
"reside on the same hosts whenever possible if data isolation was a primary "
"concern, conversely one could attempt to have instances for a tenant reside "
"on as many different hosts as possible for availability or fault tolerance "
"reasons. The following diagram demonstrates how the filter scheduler works:"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml53(para)
msgid ""
"The use of scheduler filters may be used to segregate customers, data, or "
"even discard machines of the cloud that cannot be attested as secure. This "
"generally applies to all OpenStack projects offering a scheduler. When "
"building a cloud, you may choose to implement scheduling filters for a "
"variety of security-related purposes."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml54(para)
msgid ""
"Below we highlight a few of the filters that may be useful in a security "
"context, depending on your requirements, the full set of filter "
"documentation is documented in the <link "
"href=\"http://docs.openstack.org/trunk/config-reference/content/filter-"
"scheduler.html\">Filter Scheduler</link> section of the <citetitle>OpenStack"
" Configuration Reference</citetitle>."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml55(emphasis)
msgid "Tenant Driven Whole Host Reservation"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml56(para)
msgid ""
"There currently exists a <link "
"href=\"https://blueprints.launchpad.net/nova/+spec/whole-host-"
"allocation\">blueprint for whole host reservation</link> - This would allow "
"a tenant to exclusively reserve hosts for only it's instances, incurring "
"extra costs."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml58(title)
msgid "Host Aggregates"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml59(para)
msgid ""
"While not a filter in themselves, host aggregates allow administrators to "
"assign key-value pairs to groups of machines. This allows cloud "
"administrators, not users, to partition up their compute host resources. "
"Each node can have multiple aggregates (see the <link "
"href=\"http://docs.openstack.org/trunk/config-reference/content/host-"
"aggregates.html\">Host Aggregates</link> section of the <citetitle>OpenStack"
" Configuration Reference</citetitle> for more information on creating and "
"managing aggregates)."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml70(title)
msgid "AggregateMultiTenancyIsolation"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml71(para)
msgid ""
"Isolates tenants to specific host aggregates. If a host is in an aggregate "
"that has the metadata key <literal>filter_tenant_id</literal> it will only "
"create instances from that tenant (or list of tenants). A host can be in "
"multiple aggregates. If a host does not belong to an aggregate with the "
"metadata key, it can create instances from all tenants."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml74(title)
msgid "DifferentHostFilter"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml75(para)
msgid ""
"Schedule the instance on a different host from a set of instances. To take "
"advantage of this filter, the requester must pass a scheduler hint, using "
"<literal>different_host</literal> as the key and a list of instance uuids as"
" the value. This filter is the opposite of the "
"<literal>SameHostFilter</literal>."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml78(title)
msgid "GroupAntiAffinityFilter"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml79(para)
msgid ""
"The GroupAntiAffinityFilter ensures that each instance in a group is on a "
"different host. To take advantage of this filter, the requester must pass a "
"scheduler hint, using <literal>group</literal> as the key and a list of "
"instance uuids as the value."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml82(title)
msgid "Trusted Compute Pools"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml83(para)
msgid ""
"There exists a scheduler filter which integrates with the <link "
"href=\"https://github.com/OpenAttestation/OpenAttestation\">Open Attestation"
" Project</link> (OATS) to define scheduler behavior according to the "
"attestation of PCRs received from a system using Intel TXT."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml84(para)
msgid ""
"It is unclear if this feature is compatible with AMD's similar SEM, although"
" the OpenAttestation agent relies on the vendor-agnostic <link "
"href=\"http://trousers.sourceforge.net/\">TrouSerS library</link>."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml89(para)
msgid ""
"With regards to images, users will be working with pre-installed images or "
"images that they upload themselves. In both cases, users will want to ensure"
" that the image they are ultimately running has not been tampered with. This"
" requires some source of truth such as a checksum for the known good version"
" of an image as well as verification of the running image. This section "
"describes the current best practices around image handling, while also "
"calling out some of the existing gaps in this space."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml91(title)
msgid "Image Creation Process"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml92(para)
msgid ""
"The OpenStack Documentation provides guidance on how to create and upload an"
" image to Glance. Additionally it is assumed that you have a process by "
"which you install and harden operating systems. Thus, the following items "
"will provide additional guidance on how to ensure your images are built "
"securely prior to upload. There are a variety of options for obtaining "
"images. Each has specific steps that help validate the image's provenance."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml93(para)
msgid "The first option is to obtain boot media from a trusted source."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml103(para)
msgid ""
"The second option is to use the <link href=\"http://docs.openstack.org/trunk"
"/image-guide/content/\"><citetitle>OpenStack Virtual Maschine Image "
"Guide</citetitle></link>. In this case, you will want to follow your "
"organizations OS hardening guidelines or those provided by a trusted third-"
"party such as the <link "
"href=\"http://iase.disa.mil/stigs/os/unix/red_hat.html\">RHEL6 STIG</link>."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml104(para)
msgid ""
"The final option is to use an automated image builder. The following example"
" uses the Oz image builder. The OpenStack community has recently created a "
"newer tool worth investigating: disk-image-builder. We have not evaluated "
"this tool from a security perspective."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml105(para)
msgid ""
"Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section "
"<emphasis>AC-19(d) in</emphasis> Oz."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml142(para)
msgid ""
"Note, it is the recommendation of this guide to shy away from the manual "
"image building process as it is complex and prone to error. Further, using "
"an automated system like Oz or disk-image-builder for image building, or a "
"configuration management utility like Chef or Puppet for post boot image "
"hardening gives you the ability to produce a consistent image as well as "
"track compliance of your base image to its respective hardening guidelines "
"over time."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml143(para)
msgid ""
"If subscribing to a public cloud service, you should check with the cloud "
"provider for an outline of the process used to produce their default images."
" If the provider allows you to upload your own images, you will want to "
"ensure that you are able to verify that your image was not modified before "
"you spin it up. To do this, refer to the following section on Image "
"Provenance."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml146(title)
msgid "Image Provenance and Validation"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml147(para)
msgid ""
"Unfortunately, it is not currently possible to force Compute to validate an "
"image hash immediately prior to starting an instance. To understand the "
"situation, we begin with a brief overview of how images are handled around "
"the time of image launch."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml148(para)
msgid ""
"Images come from the glance service to the nova service on a node. This "
"transfer should be protected by running over SSL. Once the image is on the "
"node, it is verified with a basic checksum and then it's disk is expanded "
"based on the size of the instance being launched. If, at a later time, the "
"same image is launched with the same instance size on this node, it will be "
"launched from the same expanded image. Since this expanded image is not re-"
"verified before launching, it could be tampered with and the user would not "
"have any way of knowing, beyond a manual inspection of the files in the "
"resulting image."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml149(para)
msgid ""
"We hope that future versions of Compute and/or the Image Service will offer "
"support for validating the image hash before each instance launch. An "
"alternative option that would be even more powerful would be allow users to "
"sign an image and then have the signature validated when the instance is "
"launched."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml154(para)
msgid ""
"OpenStack and the underlying virtualization layers provide for the Live "
"Migration of images between OpenStack nodes allowing you to seamlessly "
"perform rolling upgrades of your OpenStack Compute nodes without instance "
"downtime. However, Live Migrations also come with their fair share of risk. "
"To understand the risks involved, it is important to first understand how a "
"live migration works. The following are the high level steps preformed "
"during a live migration."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml156(para)
msgid "Start instance on destination host"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml157(para)
msgid "Transfer memory"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml158(para)
msgid "Stop the guest &amp; sync disks"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml159(para)
msgid "Transfer state"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml160(para)
msgid "Start the guest"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml163(title)
msgid "Live Migration Risks"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml164(para)
msgid ""
"At various stages of the live migration process the contents of an instances"
" run time memory and disk are transmitted over the network in plain text. "
"Thus there are several risks that need to be addressed when using live "
"migration. The following in-exhaustive list details some of these risks:"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml166(para)
msgid ""
"<emphasis>Denial of Service (DoS)</emphasis> : If something fails during the"
" migration process, the instance could be lost."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml169(para)
msgid ""
"<emphasis>Data Exposure</emphasis> : Memory or disk transfers must be "
"handled securely."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml172(para)
msgid ""
"<emphasis>Data Manipulation</emphasis> : If memory or disk transfers are not"
" handled securely, then an attacker could manipulate user data during the "
"migration."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml175(para)
msgid ""
"<emphasis>Code Injection</emphasis> : If memory or disk transfers are not "
"handled securely, then an attacker could manipulate executables, either on "
"disk or in memory, during the migration."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml180(title)
msgid "Live Migration Mitigations"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml181(para)
msgid ""
"There are several methods to mitigate some of the risk associated with live "
"migrations, the following list details some of these:"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml183(para)
#: ./doc/security-guide/ch055_security-services-for-instances.xml193(title)
msgid "Disable Live Migration"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml186(para)
msgid "Isolated Migration Network"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml189(para)
#: ./doc/security-guide/ch055_security-services-for-instances.xml204(title)
msgid "Encrypted Live Migration"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml194(para)
msgid ""
"At this time, live migration is enabled in OpenStack by default. Live "
"migrations can be disabled by adding the following lines to the nova "
"policy.json file:"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml200(title)
msgid "Migration Network"
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml201(para)
msgid ""
"As a general practice, live migration traffic should be restricted to the "
"management security domain. Indeed live migration traffic, due to its plain "
"text nature and the fact that you are transferring the contents of disk and "
"memory of a running instance, it is recommended you further separate live "
"migration traffic onto a dedicated network. Isolating the traffic to a "
"dedicated network can reduce the risk of exposure."
msgstr ""
#: ./doc/security-guide/ch055_security-services-for-instances.xml205(para)
msgid ""
"If your use case involves keeping live migration enabled, then libvirtd can "
"provide tunneled, encrypted live migrations. That said, this feature is not "
"currently exposed in OpenStack Dashboard, nor the nova-client commands and "
"can only be accessed through manual configuration of libvritd. Encrypted "
"live migration modifies the live migration process by first copying the "
"instance data from the running hypervisor to libvirtd. From there an "
"encrypted tunnel is created between the libvirtd processes on both hosts. "
"Finally, the destination libvirtd process copies the instance back to the "
"underlying hypervisor."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml3(title)
msgid "Compliance Overview"
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml4(para)
msgid ""
"An OpenStack deployment may require compliance activities for many purposes,"
" such as regulatory and legal requirements, customer need, privacy "
"considerations, and security best practices. Compliance, when done "
"correctly, unifies and strengthens the other security topics discussed in "
"this guide. This chapter has several objectives:"
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml6(para)
msgid "Review common security principles."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml9(para)
msgid ""
"Discuss common control frameworks and certification resources to achieve "
"industry certifications or regulator attestations."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml12(para)
msgid "Act as a reference for auditors when evaluating OpenStack deployments."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml15(para)
msgid ""
"Introduce privacy considerations specific to OpenStack and cloud "
"environments."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml19(title)
msgid "Security Principles"
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml20(para)
msgid ""
"Industry standard security principles provide a baseline for compliance "
"certifications and attestations. If these principles are considered and "
"referenced throughout an OpenStack deployment, certification activities may "
"be simplified."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml22(para)
msgid ""
"<emphasis>Layered Defenses</emphasis>: Identify where risks exist in a cloud"
" architecture and apply controls to mitigate the risks. In areas of "
"significant concern, layered defences provide multiple complementary "
"controls to further mitigate risk. For example, to ensure adequate isolation"
" between cloud tenants, we recommend hardening QEMU, using a hypervisor with"
" SELinux support, enforcing mandatory access control policies, and reducing "
"the overall attack surface. The foundational principle is to harden an area "
"of concern with multiple layers of defense such that if any one layer is "
"compromised, other layers will exist to offer protection and minimize "
"exposure."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml25(para)
msgid ""
"<emphasis>Fail Securely</emphasis>: In the case of failure, systems should "
"be configured to fail into a closed secure state. For example, SSL "
"certificate verification should fail closed by severing the network "
"connection if the CNAME doesn't match the server's DNS name. Software often "
"fails open in this situation, allowing the connection to proceed without a "
"CNAME match, which is less secure and not recommended."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml28(para)
msgid ""
"<emphasis>Least Privilege</emphasis>: Only the minimum level of access for "
"users and system services is granted. This access is based upon role, "
"responsibility and job function. This security principal of least privilege "
"is written into several international government security policies, such as "
"NIST 800-53 Section AC-6 within the United States. "
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml31(para)
msgid ""
"<emphasis>Compartmentalize</emphasis>: Systems should be segregated in a "
"such way that if one machine, or system-level service, is compromised the "
"security of the other systems will remain intact. Practically, the "
"enablement and proper usage of SELinux helps accomplish this goal."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml34(para)
msgid ""
"<emphasis>Promote Privacy</emphasis>: The amount of information that can be "
"gathered about a system and its users should be minimized."
msgstr ""
#: ./doc/security-guide/ch061_compliance-overview.xml37(para)
msgid ""
"<emphasis>Logging Capability</emphasis>: Appropriate logging is implemented "
"to monitor for unauthorized use, incident response and forensics. It is "
"highly recommended that selected audit subsystems be Common Criteria "
"certified, which provides non-attestable event records in most countries."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml3(title)
msgid "Certification &amp; Compliance Statements"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml4(para)
msgid ""
"Compliance and security are not exclusive, and must be addressed together. "
"OpenStack deployments are unlikely to satisfy compliance requirements "
"without security hardening. The listing below provides an OpenStack "
"architect foundational knowledge and guidance to achieve compliance against "
"commercial and government certifications and standards."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml6(title)
msgid "Commercial Standards"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml7(para)
msgid ""
"For commercial deployments of OpenStack, it is recommended that SOC 1/2 "
"combined with ISO 2700 1/2 be considered as a starting point for OpenStack "
"certification activities. The required security activities mandated by these"
" certifications facilitate a foundation of security best practices and "
"common control criteria that can assist in achieving more stringent "
"compliance activities, including government attestations and certifications."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml8(para)
msgid ""
"After completing these initial certifications, the remaining certifications "
"are more deployment specific. For example, clouds processing credit card "
"transactions will need PCI-DSS, clouds storing health care information "
"require HIPAA, and clouds within the federal government may require "
"FedRAMP/FISMA, and ITAR, certifications. "
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml10(title)
msgid "SOC 1 (SSAE 16) / ISAE 3402"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml11(para)
msgid ""
"Service Organization Controls (SOC) criteria are defined by the <link "
"href=\"http://www.aicpa.org/\">American Institute of Certified Public "
"Accountants</link> (AICPA). SOC controls assess relevant financial "
"statements and assertions of a service provider, such as compliance with the"
" Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing "
"Standards No. 70 (SAS 70) Type II report. These controls commonly include "
"physical data centers in scope."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml13(para)
msgid "There are two types of SOC 1 reports:"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml15(para)
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml28(para)
msgid ""
"Type 1 – report on the fairness of the presentation of management’s "
"description of the service organization’s system and the suitability of the "
"design of the controls to achieve the related control objectives included in"
" the description as of a specified date."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml18(para)
msgid ""
"Type 2 – report on the fairness of the presentation of management’s "
"description of the service organization’s system and the suitability of the "
"design and operating effectiveness of the controls to achieve the related "
"control objectives included in the description throughout a specified period"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml21(para)
msgid ""
"For more details see the <link "
"href=\"http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC1Report.aspx\">AICPA"
" Report on Controls at a Service Organization Relevant to User Entities’ "
"Internal Control over Financial Reporting</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml24(title)
msgid "SOC 2"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml25(para)
msgid ""
"Service Organization Controls (SOC) 2 is a self attestation of controls that"
" affect the security, availability, and processing integrity of the systems "
"a service organization uses to process users' data and the confidentiality "
"and privacy of information processed by these system. Examples of users are "
"those responsible for governance of the service organization; customers of "
"the service organization; regulators; business partners; suppliers and "
"others who have an understanding of the service organization and its "
"controls."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml26(para)
msgid "There are two types of SOC 2 reports:"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml31(para)
msgid ""
"Type 2 – report on the fairness of the presentation of management’s "
"description of the service organization’s system and the suitability of the "
"design and operating effectiveness of the controls to achieve the related "
"control objectives included in the description throughout a specified "
"period."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml34(para)
msgid ""
"For more details see the <link "
"href=\"http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx\">AICPA"
" Report on Controls at a Service Organization Relevant to Security, "
"Availability, Processing Integrity, Confidentiality or Privacy</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml38(title)
msgid "SOC 3"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml39(para)
msgid ""
"Service Organization Controls (SOC) 3 is a trust services report for service"
" organizations. These reports are designed to meet the needs of users who "
"want assurance on the controls at a service organization related to "
"security, availability, processing integrity, confidentiality, or privacy "
"but do not have the need for or the knowledge necessary to make effective "
"use of a SOC 2 Report. These reports are prepared using the AICPA/Canadian "
"Institute of Chartered Accountants (CICA) Trust Services Principles, "
"Criteria, and Illustrations for Security, Availability, Processing "
"Integrity, Confidentiality, and Privacy. Because they are general use "
"reports, SOC 3 Reports can be freely distributed or posted on a website as a"
" seal."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml40(para)
msgid ""
"For more details see the <link "
"href=\"http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx\">AICPA"
" Trust Services Report for Service Organizations</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml43(title)
msgid "ISO 27001/2"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml44(para)
msgid ""
"The ISO/IEC 27001/2 standards replace BS7799-2, and are specifications for "
"an Information Security Management System (ISMS). An ISMS is a comprehensive"
" set of policies and processes that an organization creates and maintains to"
" manage risk to information assets.  These risks are based upon the "
"confidentiality, integrity, and availability (CIA) of user information. The "
"CIA security triad has been used as a foundation for much of the chapters in"
" this book."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml45(para)
msgid ""
"For more details see <link href=\"http://www.27000.org/iso-27001.htm\">ISO "
"27001</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml48(title)
msgid "HIPAA / HITECH"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml49(para)
msgid ""
"The Health Insurance Portability and Accountability Act (HIPAA) is a United "
"States congressional act that governs the collection, storage, use and "
"destruction of patient health records. The act states that Protected Health "
"Information (PHI) must be rendered \"unusable, unreadable, or "
"indecipherable\" to unauthorized persons and that encryption for data 'at-"
"rest' and 'inflight' should be addressed."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml50(para)
msgid ""
"HIPAA is not a certification, rather a guide for protecting healthcare data."
"  Similar to the PCI-DSS, the most important issues with both PCI and HIPPA "
"is that a breach of credit card information, and health data, do not occur. "
"In the instance of a breach the cloud provider will be scrutinized for "
"compliance with PCI and HIPPA controls. If proven compliant, the provider "
"can be expected to immediately implement remedial controls, breach "
"notification responsibilities, and significant expenditure on additional "
"compliance activities.  If not compliant, the cloud provider can expect on-"
"site audit teams, fines, potential loss of merchant ID (PCI), and massive "
"reputational impact."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml51(para)
msgid ""
"Users or organizations that possess PHI must support HIPAA requirements and "
"are HIPAA covered entities. If an entity intends to use a service, or in "
"this case, an OpenStack cloud that might use, store or have access to that "
"PHI, then a Business Associate Agreement must be signed. The BAA is a "
"contract between the HIPAA covered entity and the OpenStack service provider"
" that requires the provider to handle that PHI in accordance with HIPAA "
"requirements. If the service provider does not handle the PHI (e.g. with "
"security controls and hardening) then they are subject to HIPAA fines and "
"penalties."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml52(para)
msgid ""
"OpenStack architects interpret and respond to HIPAA statements, with data "
"encryption remaining a core practice. Currently this would require any "
"protected health information contained within an OpenStack deployment to be "
"encrypted with industry standard encryption algorithms. Potential future "
"OpenStack projects such as object encryption will facilitate HIPAA "
"guidelines for compliance with the act."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml53(para)
msgid ""
"For more details see the <link href=\"https://www.cms.gov/Regulations-and-"
"Guidance/HIPAA-Administrative-"
"Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf\">Health Insurance "
"Portability And Accountability Act</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml55(title)
msgid "PCI-DSS"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml56(para)
msgid ""
"The Payment Card Industry Data Security Standard (PCI DSS) is defined by the"
" Payment Card Industry Standards Council, and created to increase controls "
"around card holder data to reduce credit card fraud. Annual compliance "
"validation is assessed by an external Qualified Security Assessor (QSA) who "
"creates a Report on Compliance (ROC), or by a Self-Assessment Questionnaire "
"(SAQ) dependent on volume of card-holder transactions.  "
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml57(para)
msgid ""
"OpenStack deployments which stores, processes, or transmits payment card "
"details are in scope for the PCI-DSS. All OpenStack components that are not "
"properly segmented from systems or networks that handle payment data fall "
"under the guidelines of the PCI-DSS. Segmentation in the context of PCI-DSS "
"does not support multi-tenancy, but rather physical separation "
"(host/network). "
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml58(para)
msgid ""
"For more details see <link "
"href=\"https://www.pcisecuritystandards.org/security_standards/\">PCI "
"security standards</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml62(title)
msgid "Government Standards"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml64(title)
msgid "FedRAMP"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml65(para)
msgid ""
"\"The <link href=\"http://www.fedramp.gov\">Federal Risk and Authorization "
"Management Program</link> (FedRAMP) is a government-wide program that "
"provides a standardized approach to security assessment, authorization, and "
"continuous monitoring for cloud products and services\". NIST 800-53 is the "
"basis for both FISMA and FedRAMP which mandates security controls "
"specifically selected to provide protection in cloud environments. FedRAMP "
"can be extremely intensive from specificity around security controls, and "
"the volume of documentation required to meet government standards."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml66(para)
msgid ""
"For more details see <link "
"href=\"http://www.gsa.gov/portal/category/102371\">http://www.gsa.gov/portal/category/102371</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml69(title)
msgid "ITAR"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml70(para)
msgid ""
"The International Traffic in Arms Regulations (ITAR) is a set of United "
"States government regulations that control the export and import of defense-"
"related articles and services on the United States Munitions List (USML) and"
" related technical data. ITAR is often approached by cloud providers as an "
"\"operational alignment\" rather than a formal certification. This typically"
" involves implementing a segregated cloud environment following practices "
"based on the NIST 800-53 framework, as per FISMA requirements, complemented "
"with additional controls restricting access to \"U.S. Persons\" only and "
"background screening."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml72(para)
msgid ""
"For more details see <link "
"href=\"http://pmddtc.state.gov/regulations_laws/itar_official.html\">http://pmddtc.state.gov/regulations_laws/itar_official.html</link>."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml75(title)
msgid "FISMA"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml76(para)
msgid ""
"The Federal Information Security Management Act requires that government "
"agencies create a comprehensive plan to implement numerous government "
"security standards, and was enacted within the E-Government Act of 2002. "
"FISMA outlines a process, which utilizing multiple NIST publications, "
"prepares an information system to store and process government data."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml77(para)
msgid "This process is broken apart into three primary categories:"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml79(para)
msgid ""
"<emphasis role=\"bold\">System Categorization</emphasis>The information "
"system will receive a security category as defined in Federal Information "
"Processing Standards Publication 199 (FIPS 199). These categories reflect "
"the potential impact of system compromise."
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml83(para)
msgid ""
"<emphasis role=\"bold\">Control Selection</emphasis>Based upon system "
"security category as defined in FIPS 199, an organization utilizes FIPS 200 "
"to identify specific security control requirements for the information "
"system. For example, if a system is categorized as “moderate” a requirement "
"may be introduced to mandate “secure passwords.”"
msgstr ""
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml86(para)
msgid ""
"<emphasis role=\"bold\">Control Tailoring</emphasis>Once system security "
"controls are identified, an OpenStack architect will utilize NIST 800-53 to "
"extract tailored control selection, e.g. specification of what constitutes a"
" “secure password.”"
msgstr ""
#: ./doc/security-guide/ch039_case-studies-messaging.xml3(title)
msgid "Case Studies: Messaging"
msgstr ""
#: ./doc/security-guide/ch039_case-studies-messaging.xml4(para)
msgid ""
"The message queue is a critical piece of infrastructure that supports a "
"number of OpenStack services but is most strongly associated with the "
"Compute service. Due to the nature of the message queue service, Alice and "
"Bob have similar security concerns. One of the larger concerns that remains "
"is that many systems have access to this queue and there is no way for a "
"consumer of the queue messages to verify which host or service placed the "
"messages on the queue. An attacker who is able to successfully place "
"messages on the queue is able to create and delete VM instances, attach the "
"block storage of any tenant and a myriad of other malicious actions. There "
"are a number of solutions on the horizon to fix this, with several proposals"
" for message signing and encryption making their way through the OpenStack "
"development process."
msgstr ""
#: ./doc/security-guide/ch039_case-studies-messaging.xml7(para)
msgid ""
"In this case Alice's controls mimic those Bob has deployed for the public "
"cloud."
msgstr ""
#: ./doc/security-guide/ch039_case-studies-messaging.xml11(para)
msgid ""
"Bob assumes that at some point infrastructure or networks underpinning the "
"Compute service may become compromised. Due to this, he recognizes the "
"importance of locking down access to the message queue. To do this Bob "
"deploys his RabbitMQ servers with SSL and X.509 client auth for access "
"control. This in turn limits the capabilities of an attacker who has "
"compromised a system that does not have queue access."
msgstr ""
#: ./doc/security-guide/ch039_case-studies-messaging.xml12(para)
msgid ""
"Additionally, Bob adds strong network ACL rulesets to enforce which "
"endpoints can communicate with the message servers. This second control "
"provides some additional assurance should the other protections fail."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml3(title)
msgid "Case Studies: Compliance"
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address common "
"compliance requirements. The preceding chapter refers to a wide variety of "
"compliance certifications and standards. Alice will address compliance in a "
"private cloud, while Bob will be focused on compliance for a public cloud."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml7(para)
msgid ""
"Alice is building an OpenStack private cloud for the United States "
"government, specifically to provide elastic compute environments for signal "
"processing. Alice has researched government compliance requirements, and has"
" identified that her private cloud will be required to certify against FISMA"
" and follow the FedRAMP accreditation process, which is required for all "
"federal agencies, departments and contractors to become a Certified Cloud "
"Provider (CCP). In this particular scenario for signal processing, the FISMA"
" controls required will most likely be FISMA High, which indicates possible "
"\"severe or catastrophic adverse effects\" should the information system "
"become compromised. In addition to FISMA Moderate controls Alice must ensure"
" her private cloud is FedRAMP certified, as this is a requirement for all "
"agencies that currently utilize, or host federal information within a cloud "
"environment."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml8(para)
msgid ""
"To meet these strict government regulations Alice undertakes a number of "
"activities. Scoping of requirements is particularly important due to the "
"volume of controls that must be implemented, which will be defined in NIST "
"Publication 800-53."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml9(para)
msgid ""
"All technology within her private cloud must be FIPS certified technology, "
"as mandated within NIST 800-53 and FedRAMP. As the U.S. Department of "
"Defense is involved, Security Technical Implementation Guides (STIGs) will "
"come into play, which are the configuration standards for DOD IA and IA-"
"enabled devices / systems. Alice notices a number of complications here as "
"there is no STIG for OpenStack, so she must address several underlying "
"requirements for each OpenStack service, e.g. the networking SRG and "
"Application SRG will both be applicable (<link "
"href=\"http://iase.disa.mil/srgs/index.html\">list of SRGs</link>). Other "
"critical controls include ensuring that all identities in the cloud use PKI,"
" that SELinux is enabled, that encryption exists for all wire-level "
"communications, and that continuous monitoring is in place and clearly "
"documented. Alice is not concerned with object encryption, as this will be "
"the tenants responsibility rather than the provider."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml10(para)
msgid ""
"If Alice has adequately scoped and executed these compliance activities, she"
" may begin the process to become FedRAMP compliant by hiring an approved "
"third-party auditor. Typically this process takes up to 6 months, after "
"which she will receive an Authority to Operate and can offer OpenStack cloud"
" services to the government."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml14(para)
msgid ""
"Bob is tasked with compliance for a new OpenStack public cloud deployment, "
"that is focused on providing cloud services to both small developers and "
"startups, as well as large enterprises. Bob recognizes that individual "
"developers are not necessarily concerned with compliance certifications, but"
" to larger enterprises certifications are critical. Specifically Bob desires"
" to achieve SOC 1, SOC 2 Security, as well as ISO 27001/2 as quickly as "
"possible. Bob references the Cloud Security Alliance Cloud Control Matrix "
"(CCM) to assist in identifying common controls across these three "
"certifications (such as periodic access reviews, auditable logging and "
"monitoring services, risk assessment activities, security reviews, etc). Bob"
" then engages an experienced audit team to conduct a gap analysis on the "
"public cloud deployment, reviews the results and fills any gaps identified. "
"Bob works with other team members to ensure that these security controls and"
" activities are regularly conducted for a typical audit period (~6-12 "
"months)."
msgstr ""
#: ./doc/security-guide/ch066_case-studies-compliance.xml31(para)
msgid ""
"At the end of the audit period Bob has arranged for an external audit team "
"to review in-scope security controls at randomly sampled points of time over"
" a 6 month period. The audit team provides Bob with an official report for "
"SOC 1 and SOC 2, and separately for ISO 27001/2. As Bob has been diligent in"
" ensuring security controls are in place for his OpenStack public cloud, "
"there are no additional gaps exposed on the report. Bob can now provide "
"these official reports to his customers under NDA, and advertise that he is "
"SOC 1, SOC 2 and ISO 27001/2 compliant on his website."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml3(title)
msgid "API Endpoint Configuration Recommendations"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml4(para)
msgid ""
"This chapter provides recommendations for improving the security of both "
"public and internal endpoints."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml6(title)
msgid "Internal API Communications"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml7(para)
msgid ""
"OpenStack provides both public facing and private API endpoints. By default,"
" OpenStack components use the publicly defined endpoints. The recommendation"
" is to configure these components to use the API endpoint within the proper "
"security domain."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml8(para)
msgid ""
"Services select their respective API endpoints based on the OpenStack "
"service catalog.  The issue here is these services may not obey the listed "
"public or internal API end point values. This can lead to internal "
"management traffic being routed to external API endpoints."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml10(title)
msgid "Configure Internal URLs in Identity Service Catalog"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml11(para)
msgid ""
"The Identity Service catalog should be aware of your internal URLs. While "
"this feature is not utilized by default, it may be leveraged through "
"configuration. Additionally, it should be forward-compatible with expectant "
"changes once this behavior becomes the default."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml12(para)
msgid "To register an internal URL for an endpoint:"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml22(title)
msgid "Configure Applications for Internal URLs"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml23(para)
msgid ""
"Some services can be forced to use specific API endpoints.  Therefore, it is"
" recommended that each OpenStack service communicating to the API of another"
" service must be explicitly configured to access the proper internal API "
"endpoint."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml24(para)
msgid ""
"Each project may present an inconsistent way of defining target API "
"endpoints. Future releases of OpenStack seek to resolve these "
"inconsistencies through consistent use of the Identity Service catalog."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml26(title)
msgid "Configuration Example #1: Nova"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml37(title)
msgid "Configuration Example #2: Cinder"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml44(title)
msgid "Paste and Middleware"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml45(para)
msgid ""
"Most API endpoints and other HTTP services in OpenStack utilize the Python "
"Paste Deploy library. This is important to understand from a security "
"perspective as it allows for manipulation of the request filter pipeline "
"through the application's configuration. Each element in this chain is "
"referred to as <emphasis>middleware</emphasis>. Changing the order of "
"filters in the pipeline or adding additional middleware may have "
"unpredictable security impact."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml46(para)
msgid ""
"It is not uncommon that implementors will choose to add additional "
"middleware to extend OpenStack's base functionality. We recommend "
"implementors make careful consideration of the potential exposure introduced"
" by the addition of non-standard software components to their HTTP request "
"pipeline."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml47(para)
msgid ""
"Additional information on Paste Deploy may be found at <link "
"href=\"http://pythonpaste.org/deploy/\">http://pythonpaste.org/deploy/</link>."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml51(title)
msgid "API Endpoint Process Isolation &amp; Policy"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml52(para)
msgid ""
"API endpoint processes, especially those that reside within the public "
"security domain should be isolated as much as possible. Where deployments "
"allow, API endpoints should be deployed on separate hosts for increased "
"isolation."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml54(title)
#: ./doc/security-guide/ch038_transport-security.xml119(title)
msgid "Namespaces"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml55(para)
msgid ""
"Many operating systems now provide compartmentalization support. Linux "
"supports namespaces to assign processes into independent domains. System "
"compartmentalization is covered in more detail in other parts of the guide."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml58(title)
#: ./doc/security-guide/ch038_transport-security.xml124(title)
msgid "Network Policy"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml59(para)
msgid ""
"API endpoints typically bridge multiple security domains, as such particular"
" attention should be paid to the compartmentalization of the API processes."
"  See the <emphasis>Security Domain Bridging</emphasis> section for "
"additional information in this area."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml60(para)
msgid ""
"With careful modeling, network ACLs and IDS technologies can be use to "
"enforce explicit point to point communication between network services. As "
"critical cross domain service, this type of explicit enforcement works well "
"for OpenStack's message queue service."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml61(para)
msgid ""
"Policy enforcement can be implemented through the configuration of services,"
" host-based firewalls (such as IPTables), local policy (SELinux or "
"AppArmor), and optionally enforced through global network policy."
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml64(title)
#: ./doc/security-guide/ch038_transport-security.xml129(title)
#: ./doc/security-guide/ch052_devices.xml87(title)
msgid "Mandatory Access Controls"
msgstr ""
#: ./doc/security-guide/ch021_paste-and-middleware.xml65(para)
msgid ""
"API endpoint processes should be isolated from each other and other "
"processes on a machine. The configuration for those processes should be "
"restricted to those processes not only by Discretionary Access Controls, but"
" through Mandatory Access Controls. The goal of these enhanced access "
"control is to aid in the containment and escalation of API endpoint security"
" breaches.  With mandatory access controls, such breaches will severely "
"limit access to resources and provide earlier alerting on such events."
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml3(title)
msgid "Database Backend Considerations"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml4(para)
msgid ""
"The choice of database server is an important consideration in the security "
"of an OpenStack deployment. While security considerations are not the only "
"basis on which a database server must be chosen, security considerations are"
" the only ones within the scope of this book. In practice, OpenStack only "
"supports two database types: PostgreSQL and MySQL."
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml5(para)
msgid ""
"PostgreSQL has a number of desirable security features such as Kerberos "
"authentication, object-level security, and encryption support. The "
"PostgreSQL community has done well to provide solid guidance, documentation,"
" and tooling to promote positive security practices."
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml6(para)
msgid ""
"MySQL has a large community, wide-spread adoption, and provides high "
"availability options. MySQL also has the ability to provide enhanced client "
"authentication by way of plug-in authentication mechanisms. Forked "
"distributions in the MySQL community provide many options for consideration."
" It is important to choose a specific implementation of MySQL based on a "
"thorough evaluation of the security posture and the level of support "
"provided for the given distribution."
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml8(title)
msgid "Security References for Database Backends"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml9(para)
msgid ""
"Those deploying MySQL or PostgreSQL are advised to refer to existing "
"security guidance. Some references are listed below:"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml10(para)
msgid "MySQL:"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml12(link)
msgid "OWASP MySQL Hardening"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml15(link)
msgid "MySQL Pluggable Authentication"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml18(link)
msgid "Security in MySQL"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml21(para)
msgid "PostgreSQL:"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml23(link)
msgid "OWASP PostgreSQL Hardening"
msgstr ""
#: ./doc/security-guide/ch041_database-backend-considerations.xml26(link)
msgid "Total security in a PostgreSQL database"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml3(title)
msgid "Management Interfaces"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml4(para)
msgid ""
"It is necessary for administrators to perform command and control over the "
"cloud for various operational functions. It is important these command and "
"control facilities are understood and secured."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml5(para)
msgid ""
"OpenStack provides several management interfaces for operators and tenants:"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml7(para)
msgid "OpenStack Dashboard (Horizon)"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml10(para)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml69(title)
msgid "OpenStack API"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml13(para)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml93(title)
msgid "Secure Shell (SSH)"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml16(para)
msgid "OpenStack Management Utilities (nova-manage, glance-manage, etc.)"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml19(para)
msgid "Out-of-Band Management Interfaces (IPMI, etc.)"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml24(para)
msgid ""
"The OpenStack Dashboard (Horizon) provides administrators and tenants a web-"
"based graphical interface to provision and access cloud-based resources. The"
" dashboard communicates with the back-end services via calls to the "
"OpenStack API (discussed above)."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml26(title)
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml72(title)
#: ./doc/security-guide/ch026_compute.xml13(title)
#: ./doc/security-guide/ch026_compute.xml40(title)
msgid "Capabilities"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml28(para)
msgid ""
"As a cloud administrator, the dashboard provides an overall view of the size"
" and state of your cloud. You can create users and tenants/projects, assign "
"users to tenant/projects and set limits on the resources available for them."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml31(para)
msgid ""
"The dashboard provides tenant-users a self-service portal to provision their"
" own resources within the limits set by administrators."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml34(para)
msgid ""
"The dashboard provides GUI support for routers and load-balancers. For "
"example, the dashboard now implements all of the main Networking features."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml37(para)
msgid ""
"It is an extensible <glossterm>Django</glossterm> web application that "
"allows easy plug-in of third-party products and services, such as billing, "
"monitoring, and additional management tools."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml40(para)
msgid ""
"The dashboard can also be branded for service providers and other commercial"
" vendors."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml47(para)
msgid ""
"The dashboard requires cookies and JavaScript to be enabled in the web "
"browser."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml50(para)
msgid ""
"The web server that hosts dashboard should be configured for SSL to ensure "
"data is encrypted."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml53(para)
msgid ""
"Both the Horizon web service and the OpenStack API it uses to communicate "
"with the back-end are susceptible to web attack vectors such as denial of "
"service and must be monitored."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml56(para)
msgid ""
"It is now possible (though there are numerous deployment/security "
"implications) to upload an image file directly from a user’s hard disk to "
"Glance through Horizon. For multi-GB images it is still strongly recommended"
" that the upload be done using the Glance CLI"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml59(para)
msgid ""
"Create and manage security groups through dashboard. The security groups "
"allows L3-L4 packet filtering for security policies to protect virtual "
"machines"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml65(citetitle)
msgid "Grizzly Release Notes"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml70(para)
msgid ""
"The OpenStack API is a RESTful web service endpoint to access, provision and"
" automate cloud-based resources.  Operators and users typically access the "
"API through command-line utilities (i.e. Nova, Glance, etc.), language-"
"specific libraries, or third-party tools."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml74(para)
msgid ""
"To the cloud administrator the API provides an overall view of the size and "
"state of the cloud deployment and allows the creation of users, "
"tenants/projects, assigning users to tenants/projects and specifying "
"resource quotas on a per tenant/project basis."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml77(para)
msgid ""
"The API provides a tenant interface for provisioning, managing, and "
"accessing their resources."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml84(para)
msgid ""
"The API service should be configured for SSL to ensure data is encrypted."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml87(para)
msgid ""
"As a web service, OpenStack API is susceptible to familiar web site attack "
"vectors such as denial of service attacks."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml94(para)
msgid ""
"It has become industry practice to use secure shell (SSH) access for the "
"management of Linux and Unix systems. SSH uses secure cryptographic "
"primitives for communication. With the scope and importance of SSH in "
"typical OpenStack deployments, it is important to understand best practices "
"for deploying SSH."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml96(title)
msgid "Host Key Fingerprints"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml97(para)
msgid ""
"Often overlooked is the need for key management for SSH hosts. As most or "
"all hosts in an OpenStack deployment will provide an SSH service, it is "
"important to have confidence in connections to these hosts. It cannot be "
"understated that failing to provide a reasonably secure and accessible "
"method to verify SSH host key fingerprints is ripe for abuse and "
"exploitation."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml98(para)
msgid ""
"All SSH daemons have private host keys and, upon connection, offer a host "
"key fingerprint. This host key fingerprint is the hash of an unsigned public"
" key. It is important these host key fingerprints are known in advance of "
"making SSH connections to those hosts. Verification of host key fingerprints"
" is instrumental in detecting man-in-the-middle attacks."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml99(para)
msgid ""
"Typically, when an SSH daemon is installed, host keys will be generated. It "
"is necessary that the hosts have sufficient entropy during host key "
"generation. Insufficient entropy during host key generation can result in "
"the possibility to eavesdrop on SSH sessions."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml100(para)
msgid ""
"Once the SSH host key is generated, the host key fingerprint should be "
"stored in a secure and queriable location. One particularly convenient "
"solution is DNS using SSHFP resource records as defined in RFC-4255. For "
"this to be secure, it is necessary that DNSSEC be deployed."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml104(title)
msgid "Management Utilities"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml105(para)
msgid ""
"The OpenStack Management Utilities are open-source Python command-line "
"clients that make API calls. There is a client for each OpenStack service "
"(nova, glance, etc.). In addition to the standard CLI client, most of the "
"services have a management command line which makes direct calls to the "
"database. These dedicated management utilities are slowly being deprecated."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml115(para)
msgid ""
"The dedicated management utilities (*-manage) in some cases use the direct "
"database connection."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml118(para)
msgid ""
"Ensure that the .rc file which has your credential information is secured."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml124(para)
msgid ""
"<citetitle>OpenStack End User Guide</citetitle> section <link "
"href=\"http://docs.openstack.org/user-"
"guide/content/section_cli_overview.html\">command line clients "
"overview</link>"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml125(para)
msgid ""
"<citetitle>OpenStack End User Guide</citetitle> section <link "
"href=\"http://docs.openstack.org/user-"
"guide/content/cli_openrc.html\">Download and source the OpenStack RC "
"file</link>"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml129(title)
msgid "Out-of-Band Management Interface"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml130(para)
msgid ""
"OpenStack management relies on out-of-band management interfaces such as the"
" IPMI protocol to access into nodes running OpenStack components. IPMI is a "
"very popular specification to remotely manage, diagnose and reboot servers "
"whether the operating system is running or the system has crashed."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml134(para)
msgid ""
"Use strong passwords and safeguard them, or use client-side SSL "
"authentication."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml137(para)
msgid ""
"Ensure that the network interfaces are on their own private(management or a "
"separate) network. Segregate management domains with firewalls or other "
"network gear."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml140(para)
msgid ""
"If you use a web interface to interact with the "
"<glossterm>BMC</glossterm>/IPMI, always use the SSL interface (e.g. https or"
" port 443). This SSL interface should <emphasis role=\"bold\">NOT</emphasis>"
" use self-signed certificates, as is often default, but should have trusted "
"certificates using the correctly defined fully qualified domain names "
"(FQDNs)."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml143(para)
msgid ""
"Monitor the traffic on the management network. The anomalies may be easier "
"to track than on the busier compute nodes"
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml146(para)
msgid ""
"Out of band management interfaces also often include graphical machine "
"console access. It is often possible, although not necessarily default, that"
" these interfaces are encrypted. Consult with your system software "
"documentation for encrypting these interfaces."
msgstr ""
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml150(link)
msgid "Hacking servers that are turned off"
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml3(title)
msgid "Case Studies: Identity Management"
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address configuration "
"of OpenStack core services. These include the Keystone Identity service, "
"Dashboard, and Compute services. Alice will be concerned with integration "
"into the existing government directory services, while Bob will need to "
"provide access to the public."
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml7(para)
msgid ""
"Alice's enterprise has a well-established directory service with two-factor "
"authentication for all users. She configures Keystone to support an external"
" authentication service supporting authentication with government-issued "
"access cards. She also uses an external LDAP server to provide role "
"information for the users that is integrated with the access control policy."
" Due to FedRAMP compliance requirements, Alice implements two-factor "
"authentication on the Management network for all administrator access."
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml8(para)
msgid ""
"Alice also deploys the Dashboard to manage many aspects of the cloud.  She "
"deploys the Dashboard with HSTS to ensure that only HTTPS is used.  The "
"Dashboard resides within an internal subdomain of the private network domain"
" name system."
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml9(para)
msgid ""
"Alice decides to use SPICE instead of VNC for the virtual console.  She "
"wants to take advantage of the emerging capabilities in SPICE."
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml13(para)
msgid ""
"Bob must support authentication by the general public, so he elects to use "
"provide for username / password authentication. He has concerns about brute "
"force attacks attempting to crack user passwords, so he also uses an "
"external authentication extension that throttles the number of failed login "
"attempts. Bob's Management network is separate from the other networks "
"within his cloud, but can be reached from his corporate network via ssh. As "
"recommended earlier, Bob requires administrators to use two-factor "
"authentication on the Management network to reduce the risk from compromised"
" administrator passwords."
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml14(para)
msgid ""
"Bob also deploys the Dashboard to manage many aspects of the cloud.  He "
"deploys the Dashboard with HSTS to ensure that only HTTPS is used.  He has "
"ensured that the Dashboard is deployed on a second-level domain due to the "
"limitations of the same-origin policy. He also disables "
"HORIZON_IMAGES_ALLOW_UPLOAD to prevent resource exhaustion."
msgstr ""
#: ./doc/security-guide/ch028_case-studies-identity-management.xml15(para)
msgid ""
"Bob decides to use VNC for his virtual console for its maturity and security"
" features."
msgstr ""
#: ./doc/security-guide/ch037_risks.xml3(title)
msgid "Message Queuing Architecture"
msgstr ""
#: ./doc/security-guide/ch037_risks.xml4(para)
msgid ""
"Inter-process communication within OpenStack is facilitated via message "
"queueing services. Today, three messaging service backends are supported:"
msgstr ""
#: ./doc/security-guide/ch037_risks.xml6(para)
msgid "RabbitMQ"
msgstr ""
#: ./doc/security-guide/ch037_risks.xml9(para)
msgid "Qpid"
msgstr ""
#: ./doc/security-guide/ch037_risks.xml12(para)
msgid "ZeroMQ"
msgstr ""
#: ./doc/security-guide/ch037_risks.xml15(para)
msgid ""
"Both RabbitMQ and Qpid are Advanced Message Queuing Protocol (AMQP) "
"frameworks which provide message queues for peer-to-peer communication. "
"Queue implementations are typically deployed as centralized or decentralized"
" pool of queue servers. ZeroMQ differs by communicating directly using TCP "
"sockets between peers."
msgstr ""
#: ./doc/security-guide/ch037_risks.xml16(para)
msgid ""
"Message queues effectively facilitate command and control functions across "
"OpenStack deployments. Once access to the queue is permitted no further "
"authorization checks are performed. Services accessible via the queue do "
"validate the contexts and tokens within the actual message payload. However,"
" awareness of the token's expiration value should be noted as these tokens "
"are potentially replayable and may provide authorization for other services "
"within the infrastructure."
msgstr ""
#: ./doc/security-guide/ch037_risks.xml17(para)
msgid ""
"OpenStack does not support message-level confidence (i.e., message signing)."
" Because of this, the message transport itself must be secured and "
"authentication to the queue server must be performed. For HA configurations,"
" queue to queue authentication and encryption should to be performed as "
"well."
msgstr ""
#: ./doc/security-guide/ch037_risks.xml18(para)
msgid ""
"With ZeroMQ messaging, IPC sockets are used on individual machines. These "
"sockets may be vulnerable to attack for local message injection and snooping"
" unless secured by an operator."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml3(title)
#: ./doc/security-guide/ch004_book-introduction.xml71(title)
msgid "Compute"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml4(para)
msgid ""
"The Compute Service (Nova) is one of the more complex OpenStack services.  "
"It runs in many locations throughout the cloud and interacts with a variety "
"of internal services.  For this reason, most of our recommendations "
"regarding best practices for Compute Service configuration are distributed "
"throughout this book. We provide specific details in the sections on "
"Management, API Endpoints, Messaging, and Database."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml6(title)
msgid "Virtual Console Selection"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml7(para)
msgid ""
"One decision a cloud architect will need to make regarding Compute Service "
"configuration is whether to use VNC or SPICE. Below we provide some details "
"on the differences between these options."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml9(title)
msgid "Virtual Network Computer (VNC)"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml10(para)
msgid ""
"OpenStack can be configured to provide remote desktop console access to "
"instances for tenants and/or administrators using the Virtual Network "
"Computer (VNC) protocol.  "
msgstr ""
#: ./doc/security-guide/ch026_compute.xml15(para)
msgid ""
"The OpenStack Dashboard (Horizon) can provide a VNC console for instances "
"directly on the web page using the HTML5 noVNC client.  This requires the "
"<systemitem class=\"service\">nova-novncproxy</systemitem> service to bridge"
" from the public network to the management network."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml18(para)
msgid ""
"The nova command line utility can return a URL for the VNC console for "
"access by the nova Java VNC client. This requires the nova-xvpvncproxy "
"service to bridge from the public network to the management network."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml25(para)
msgid ""
"The <systemitem class=\"service\">nova-novncproxy</systemitem>and nova-"
"xvpvncproxy services by default open public-facing ports that are token "
"authenticated."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml28(para)
msgid ""
"By default, the remote desktop traffic is not encrypted. Havana is expected "
"to have VNC connections secured by Kerberos."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml34(link)
msgid "Secure Connections to VNC ports"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml37(title)
msgid "Simple Protocol for Independent Computing Environments (SPICE)"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml38(para)
msgid ""
"As an alternative to VNC, OpenStack provides remote desktop access to guest "
"virtual machines using the Simple Protocol for Independent Computing "
"Environments (SPICE) protocol."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml42(para)
msgid ""
"SPICE is supported by the OpenStack Dashboard (Horizon) directly on the "
"instance web page.  This requires the nova-spicehtml5proxy service."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml45(para)
msgid ""
"The nova command line utility can return a URL for SPICE console for access "
"by a SPICE-html client."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml50(title)
msgid "Limitations"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml52(para)
msgid ""
"Although SPICE has many advantages over VNC, the spice-html5 browser "
"integration currently doesn't really allow admins to take advantage of any "
"of the benefits. To take advantage of SPICE features like multi-monitor, USB"
" pass through, etc. admins are recommended to use a standalone SPICE client "
"within the Management Network."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml59(para)
msgid ""
"The nova-spicehtml5proxy service by default opens public-facing ports that "
"are token authenticated."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml62(para)
msgid ""
"The functionality and integration are still evolving. We will access the "
"features in the next release and make recommendations."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml65(para)
msgid ""
"As is the case for VNC, at this time we recommend using SPICE from the "
"management network in addition to limiting use to few individuals."
msgstr ""
#: ./doc/security-guide/ch026_compute.xml71(link)
msgid "SPICE Console"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml72(link)
msgid "Red Hat bug 913607"
msgstr ""
#: ./doc/security-guide/ch026_compute.xml73(link)
msgid "SPICE support in RDO Grizzly"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch013_node-bootstrapping.xml14(None)
#: ./doc/security-guide/ch013_node-bootstrapping.xml17(None)
msgid ""
"@@image: 'static/node-provisioning-pxe.png'; "
"md5=51b76c5aced74f935490b37ba921dc43"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml3(title)
msgid "Integrity Life-cycle"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml4(para)
msgid ""
"We define integrity lifecycle as a deliberate process that provides "
"assurance that we are always running the expected software with the expected"
" configurations throughout the cloud. This process begins with secure "
"bootstrapping and is maintained through configuration management and "
"security monitoring. This chapter provides recommendations on how to "
"approach the integrity life-cycle process."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml6(title)
msgid "Secure Bootstrapping"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml7(para)
msgid ""
"Nodes in the cloud -- including compute, storage, network, service, and "
"hybrid nodes -- should have an automated provisioning process. This ensures "
"that nodes are provisioned consistently and correctly. This also facilitates"
" security patching, upgrading, bug fixing, and other critical changes. Since"
" this process installs new software that runs at the highest privilege "
"levels in the cloud, it is important to verify that the correct software is "
"installed. This includes the earliest stages of the boot process."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml8(para)
msgid ""
"There are a variety of technologies that enable verification of these early "
"boot stages. These typically require hardware support such as the trusted "
"platform module (TPM), Intel Trusted Execution Technology (TXT), dynamic "
"root of trust measurement (DRTM), and Unified Extensible Firmware Interface "
"(UEFI) secure boot. In this book, we will refer to all of these collectively"
" as <emphasis>secure boot technologies</emphasis>. We recommend using secure"
" boot, while acknowledging that many of the pieces necessary to deploy this "
"require advanced technical skills in order to customize the tools for each "
"environment. Utilizing secure boot will require deeper integration and "
"customization than many of the other recommendations in this guide. TPM "
"technology, while common in most business class laptops and desktops for "
"several years, and is now becoming available in servers together with "
"supporting BIOS. Proper planning is essential to a successful secure boot "
"deployment."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml9(para)
msgid ""
"A complete tutorial on secure boot deployment is beyond the scope of this "
"book. Instead, here we provide a framework for how to integrate secure boot "
"technologies with the typical node provisioning process. For additional "
"details, cloud architects should refer to the related specifications and "
"software configuration manuals."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml11(title)
msgid "Node Provisioning"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml12(para)
msgid ""
"Nodes should use Preboot eXecution Environment (PXE) for provisioning. This "
"significantly reduces the effort required for redeploying nodes. The typical"
" process involves the node receiving various boot stages (i.e., "
"progressively more complex software to execute) from a server."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml20(para)
msgid ""
"We recommend using a separate, isolated network within the management "
"security domain for provisioning. This network will handle all PXE traffic, "
"along with the subsequent boot stage downloads depicted above. Note that the"
" node boot process begins with two insecure operations: DHCP and TFTP. Then "
"the boot process downloads over SSL the remaining information required to "
"deploy the node. This information might include an initramfs and a kernel. "
"This concludes by downloading the remaining information needed to deploy the"
" node. This may be an operating system installer, a basic install managed by"
" <link href=\"http://www.opscode.com/chef/\">Chef</link> or <link "
"href=\"https://puppetlabs.com/\">Puppet</link>, or even a complete file "
"system image that is written directly to disk."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml21(para)
msgid ""
"While utilizing SSL during the PXE boot process is somewhat more "
"challenging, common PXE firmware projects (e.g., iPXE) provide this support."
" Typically this involves building the PXE firmware with knowledge of the "
"allowed SSL certificate chain(s) so that it can properly validate the server"
" certificate.  This raises the bar for an attacker by limiting the number of"
" insecure, plaintext network operations."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml24(title)
msgid "Verified Boot"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml25(para)
msgid ""
"In general, there are two different strategies for verifying the boot "
"process. Traditional <emphasis>secure boot</emphasis> will validate the code"
" run at each step in the process, and stop the boot if code is incorrect. "
"<emphasis>Boot attestation</emphasis> will record which code is run at each "
"step, and provide this information to another machine as proof that the boot"
" process completed as expected. In both cases, the first step is to measure "
"each piece of code before it is run. In this context, a measurement is "
"effectively a SHA-1 hash of the code, taken before it is executed.  The hash"
" is stored in a platform configuration register (PCR) in the TPM."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml26(para)
msgid "Note: SHA-1 is used here because this is what the TPM chips support."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml27(para)
msgid ""
"Each TPM has at least 24 PCRs. The TCG Generic Server Specification, v1.0, "
"March 2005, defines the PCR assignments for boot-time integrity "
"measurements. The table below shows a typical PCR configuration. The context"
" indicates if the values are determined based on the node hardware "
"(firmware) or the software provisioned onto the node. Some values are "
"influenced by firmware versions, disk sizes, and other low-level "
"information. Therefore, it is important to have good practices in place "
"around configuration management to ensure that each system deployed is "
"configured exactly as desired."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml35(emphasis)
msgid "Register"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml36(emphasis)
msgid "What Is Measured"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml37(emphasis)
msgid "Context"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml40(para)
msgid "PCR-00"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml41(para)
msgid ""
"Core Root of Trust Measurement (CRTM), Bios code, Host platform extensions"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml42(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml47(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml52(para)
msgid "Hardware"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml45(para)
msgid "PCR-01"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml46(para)
msgid "Host Platform Configuration"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml50(para)
msgid "PCR-02"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml51(para)
msgid "Option ROM Code "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml55(para)
msgid "PCR-03"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml56(para)
msgid "Option ROM Configuration and Data "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml57(para)
msgid "Hardware "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml60(para)
msgid "PCR-04"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml61(para)
msgid "Initial Program Loader (IPL) Code (e.g., master boot record) "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml62(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml67(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml72(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml77(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml82(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml87(para)
#: ./doc/security-guide/ch013_node-bootstrapping.xml92(para)
msgid "Software "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml65(para)
msgid "PCR-05"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml66(para)
msgid "IPL Code Configuration and Data "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml70(para)
msgid "PCR-06"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml71(para)
msgid "State Transition and Wake Events "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml75(para)
msgid "PCR-07"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml76(para)
msgid "Host Platform Manufacturer Control "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml80(para)
msgid "PCR-08"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml81(para)
msgid "Platform specific, often Kernel, Kernel Extensions, and Drivers"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml85(para)
msgid "PCR-09"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml86(para)
msgid "Platform specific, often Initramfs"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml90(para)
msgid "PCR-10 to PCR-23"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml91(para)
msgid "Platform specific "
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml97(para)
msgid ""
"At the time of this writing, very few clouds are using secure boot "
"technologies in a production environment. As a result, these technologies "
"are still somewhat immature. We recommend planning carefully in terms of "
"hardware selection (e.g., ensure that you have a TPM and Intel TXT support)."
" Then verify how the node hardware vendor populates the PCR values (e.g., "
"which values will be available for validation). Typically the PCR values "
"listed under the software context in the table above are the ones that a "
"cloud architect has direct control over. But even these may change as the "
"software in the cloud is upgraded.  Configuration management should be "
"linked into the PCR policy engine to ensure that the validation is always up"
" to date."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml98(para)
msgid ""
"Each manufacturer must provide the BIOS and firmware code for their servers."
" Different servers, hypervisors, and operating systems will choose to "
"populate different PCRs.  In most real world deployments, it will be "
"impossible to validate every PCR against a known good quantity (\"golden "
"measurement\"). Experience has shown that, even within a single vendor's "
"product line, the measurement process for a given PCR may not be consistent."
" We recommend establishing a baseline for each server and monitoring the PCR"
" values for unexpected changes. Third-party software may be available to "
"assist in the TPM provisioning and monitoring process, depending upon your "
"chosen hypervisor solution."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml99(para)
msgid ""
"The initial program loader (IPL) code will most likely be the PXE firmware, "
"assuming the node deployment strategy outlined above. Therefore, the secure "
"boot or boot attestation process can measure all of the early stage boot "
"code (e.g., bios, firmware, etc), the PXE firmware, and the node kernel. "
"Ensuring that each node has the correct versions of these pieces installed "
"provides a solid foundation on which to build the rest of the node software "
"stack."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml100(para)
msgid ""
"Depending on the strategy selected, in the event of a failure the node will "
"either fail to boot or it can report the failure back to another entity in "
"the cloud. For secure boot, the node will fail to boot and a provisioning "
"service within the management security domain must recognize this and log "
"the event. For boot attestation, the node will already be running when the "
"failure is detected. In this case the node should be immediately quarantined"
" by disabling its network access. Then the event should be analyzed for the "
"root cause. In either case, policy should dictate how to proceed after a "
"failure. A cloud may automatically attempt to reprovision a node a certain "
"number of times. Or it may immediately notify a cloud administrator to "
"investigate the problem. The right policy here will be deployment and "
"failure mode specific."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml103(title)
msgid "Node Hardening"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml104(para)
msgid ""
"At this point we know that the node has booted with the correct kernel and "
"underlying components. There are many paths for hardening a given operating "
"system deployment. The specifics on these steps are outside of the scope of "
"this book.  We recommend following the guidance from a hardening guide "
"specific to your operating system.  For example, the <link "
"href=\"http://iase.disa.mil/stigs/\">security technical implementation "
"guides</link> (STIG) and the <link "
"href=\"http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/\">NSA"
" guides</link> are useful starting places."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml105(para)
msgid ""
"The nature of the nodes makes additional hardening possible. We recommend "
"the following additional steps for production nodes:"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml107(para)
msgid ""
"Use a read-only file system where possible. Ensure that writeable file "
"systems do not permit execution.  This can be handled through the mount "
"options provided in <literal>/etc/fstab</literal>."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml110(para)
msgid ""
"Use a mandatory access control policy to contain the instances, the node "
"services, and any other critical processes and data on the node.  See the "
"discussions on sVirt / SELinux and AppArmor below."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml113(para)
msgid ""
"Remove any unnecessary software packages. This should result in a very "
"stripped down installation because a compute node has a relatively small "
"number of dependencies."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml116(para)
msgid ""
"Finally, the node kernel should have a mechanism to validate that the rest "
"of the node starts in a known good state. This provides the necessary link "
"from the boot validation process to validating the entire system. The steps "
"for doing this will be deployment specific. As an example, a kernel module "
"could verify a hash over the blocks comprising the file system before "
"mounting it using <link "
"href=\"https://code.google.com/p/cryptsetup/wiki/DMVerity\">dm-"
"verity</link>."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml120(title)
msgid "Runtime Verification"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml121(para)
msgid ""
"Once the node is running, we need to ensure that it remains in a good state "
"over time. Broadly speaking, this includes both configuration management and"
" security monitoring. The goals for each of these areas are different. By "
"checking both, we achieve higher assurance that the system is operating as "
"desired. We discuss configuration management in the management section, and "
"security monitoring below."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml123(title)
msgid "Intrusion Detection System"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml124(para)
msgid ""
"Host-based intrusion detection tools are also useful for automated "
"validation of the cloud internals. There are a wide variety of host-based "
"intrusion detection tools available. Some are open source projects that are "
"freely available, while others are commercial. Typically these tools analyze"
" data from a variety of sources and produce security alerts based on rule "
"sets and/or training. Typical capabilities include log analysis, file "
"integrity checking, policy monitoring, and rootkit detection. More advanced "
"-- often custom -- tools can validate that in-memory process images match "
"the on-disk executable and validate the execution state of a running "
"process."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml125(para)
msgid ""
"One critical policy decision for a cloud architect is what to do with the "
"output from a security monitoring tool. There are effectively two options. "
"The first is to alert a human to investigate and/or take corrective action. "
"This could be done by including the security alert in a log or events feed "
"for cloud administrators. The second option is to have the cloud take some "
"form of remedial action automatically, in addition to logging the event. "
"Remedial actions could include anything from re-installing a node to "
"performing a minor service configuration. However, automated remedial action"
" can be challenging due to the possibility of false positives."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml126(para)
msgid ""
"False positives occur when the security monitoring tool produces a security "
"alert for a benign event. Due to the nature of security monitoring tools, "
"false positives will most certainly occur from time to time. Typically a "
"cloud administrator can tune security monitoring tools to reduce the false "
"positives, but this may also reduce the overall detection rate at the same "
"time. These classic trade-offs must be understood and accounted for when "
"setting up a security monitoring system in the cloud."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml127(para)
msgid ""
"The selection and configuration of a host-based intrusion detection tool is "
"highly deployment specific. We recommend starting by exploring the following"
" open source projects which implement a variety of host-based intrusion "
"detection and file monitoring features."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml129(link)
msgid "OSSEC"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml132(link)
msgid "Samhain"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml135(link)
msgid "Tripwire"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml138(link)
msgid "AIDE"
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml141(para)
msgid ""
"Network intrusion detection tools complement the host-based tools. OpenStack"
" doesn't have a specific network IDS built-in, but OpenStack's networking "
"component, Neutron, provides a plugin mechanism to enable different "
"technologies via the Neutron API. This plugin architecture will allow "
"tenants to develop API extensions to insert and configure their own advanced"
" networking services like a firewall, an intrusion detection system, or a "
"VPN between the VMs."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml142(para)
msgid ""
"Similar to host-based tools, the selection and configuration of a network-"
"based intrusion detection tool is deployment specific. <link "
"href=\"http://www.snort.org/\">Snort</link> is the leading open source "
"networking intrusion detection tool, and a good starting place to learn "
"more."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml143(para)
msgid ""
"There are a few important security considerations for network and host-based"
" intrusion detection systems."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml145(para)
msgid ""
"It is important to consider the placement of the Network IDS on the cloud "
"(e.g., adding it to the network boundary and/or around sensitive networks). "
"The placement depends on your network environment but make sure to monitor "
"the impact the IDS may have on your services depending on where you choose "
"to add it. Encrypted traffic, such as SSL, cannot generally be inspected for"
" content by a Network IDS. However, the Network IDS may still provide some "
"benefit in identifying anomalous unencrypted traffic on the network."
msgstr ""
#: ./doc/security-guide/ch013_node-bootstrapping.xml148(para)
msgid ""
"In some deployments it may be required to add host-based IDS on sensitive "
"components on security domain bridges.  A host-based IDS may detect "
"anomalous activity by compromised or unauthorized processes on the "
"component. The IDS should transmit alert and log information on the "
"Management network."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml3(title)
msgid "Messaging Security"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml4(para)
msgid ""
"This chapter discusses security hardening approaches for the three most "
"common message queuing solutions use in OpenStack: RabbitMQ, Qpid, and "
"ZeroMQ."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml6(title)
msgid "Messaging Transport Security"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml7(para)
msgid ""
"AMQP based solutions (Qpid and RabbitMQ) support transport-level security "
"using SSL. ZeroMQ messaging does not natively support SSL, but transport-"
"level security is possible using labelled IPSec or CIPSO network labels."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml8(para)
msgid ""
"We highly recommend enabling transport-level cryptography for your message "
"queue. Using SSL for the messaging client connections provides protection of"
" the communications from tampering and eavesdropping in-transit to the "
"messaging server. Below is guidance on how SSL is typically configured for "
"the two popular messaging servers Qpid and RabbitMQ. When configuring the "
"trusted certificate authority (CA) bundle that your messaging server uses to"
" verify client connections, it is recommended that this be limited to only "
"the CA used for your nodes, preferably an internally managed CA. The bundle "
"of trusted CAs will determine which client certificates will be authorized "
"and pass the client-server verification step of the setting up the SSL "
"connection. Note, when installing the certificate and key files, ensure that"
" the file permissions are restricted, for example chmod 0600, and the "
"ownership is restricted to the messaging server daemon user to prevent "
"unauthorized access by other processes and users on the messaging server."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml10(title)
msgid "RabbitMQ Server SSL Configuration"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml11(para)
msgid ""
"The following lines should be added to the system-wide RabbitMQ "
"configuration file, typically /etc/rabbitmq/rabbitmq.config:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml24(para)
msgid ""
"Note, the 'tcp_listeners' option is set to '[]' to prevent it from listening"
" an on non-SSL port. 'ssl_listeners' option should be restricted to only "
"listen on the management network for the services."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml25(para)
msgid "For more information on RabbitMQ SSL configuration see:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml27(link)
msgid "RabbitMQ Configuration"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml30(link)
msgid "RabbitMQ SSL"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml35(title)
msgid "Qpid Server SSL Configuration"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml36(para)
msgid "The Apache Foundation has a messaging security guide for Qpid. See:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml38(link)
msgid "Apache Qpid SSL"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml44(title)
msgid "Queue Authentication and Access Control"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml45(para)
msgid ""
"RabbitMQ and Qpid offer authentication and access control mechanisms for "
"controlling access to queues. ZeroMQ offers no such mechanisms."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml46(para)
msgid ""
"Simple Authentication and Security Layer (SASL) is a framework for "
"authentication and data security in Internet protocols. Both RabbitMQ and "
"Qpid offer SASL and other pluggable authentication mechanisms beyond simple "
"usernames and passwords that allow for increased authentication security. "
"While RabbitMQ supports SASL, support in OpenStack does not currently allow "
"for requesting a specific SASL authentication mechanism. RabbitMQ support in"
" OpenStack allows for either username and password authentication over an "
"unencrypted connection or username and password in conjunction with X.509 "
"client certificates to establish the secure SSL connection."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml47(para)
msgid ""
"We recommend configuring X.509 client certificates on all the OpenStack "
"service nodes for client connections to the messaging queue and where "
"possible (currently only Qpid) perform authentication with X.509 client "
"certificates. When using usernames and passwords, accounts should be created"
" per-service and node for finer grained auditability of access to the queue."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml48(para)
msgid ""
"The SSL libraries in use by these queuing servers should also be considered "
"prior to deployment. Qpid uses Mozilla's NSS library, whereas RabbitMQ uses "
"Erlang's SSL module which uses OpenSSL."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml50(title)
msgid "Authentication Configuration Example - RabbitMQ"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml51(para)
msgid "On the RabbitMQ server, delete the default 'guest' user:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml54(para)
msgid ""
"On the RabbitMQ server, for each OpenStack service or node that communicates"
" with the message queue set up user accounts and privileges:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml58(para)
msgid "For additional configuration information see:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml60(link)
msgid "RabbitMQ Access Control"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml63(link)
msgid "RabbitMQ Authentication"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml66(link)
msgid "RabbitMQ Plugins"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml69(link)
msgid "RabbitMQ SASL External Auth"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml74(title)
msgid "OpenStack Service Configuration - RabbitMQ"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml86(para)
msgid ""
"NOTE: A bug exists in the current version of OpenStack Grizzly where if "
"'kombu_ssl_version' is currently specified in the configuration file for any"
" of the OpenStack services it will cause the following python traceback "
"error: 'TypeError: an integer is required'. The current workaround is to "
"remove 'kombu_ssl_version' from the configuration file. Refer to <link "
"href=\"https://bugs.launchpad.net/oslo/+bug/1195431\">bug report "
"1195431</link> for current status."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml89(title)
msgid "Authentication Configuration Example - Qpid"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml90(para)
msgid "For configuration information see:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml92(link)
msgid "Apache Qpid Authentication"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml95(link)
msgid "Apache Qpid Authorization"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml100(title)
msgid "OpenStack Service Configuration - Qpid"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml109(para)
msgid ""
"Optionally, if using SASL with Qpid specify the SASL mechanisms in use by "
"adding:"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml115(title)
msgid "Message Queue Process Isolation &amp; Policy"
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml116(para)
msgid ""
"Each project provides a number of services which send and consume messages. "
"Each binary which sends a message is expected to consume messages, if only "
"replies, from the queue."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml117(para)
msgid ""
"Message queue service processes should be isolated from each other and other"
" processes on a machine."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml120(para)
msgid ""
"Network namespaces are highly recommended for all services running on "
"OpenStack Compute Hypervisors. This will help prevent against the bridging "
"of network traffic between VM guests and the management network."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml121(para)
msgid ""
"When using ZeroMQ messaging, each host must run at least one ZeroMQ message "
"receiver to receive messages from the network and forward messages to local "
"processes via IPC. It is possible and advisable to run an independent "
"message receiver per project within an IPC namespace, along with other "
"services within the same project."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml125(para)
msgid ""
"Queue servers should only accept connections from the management network. "
"This applies to all implementations. This should be implemented through "
"configuration of services and optionally enforced through global network "
"policy."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml126(para)
msgid ""
"When using ZeroMQ messaging, each project should run a separate ZeroMQ "
"receiver process on a port dedicated to services belonging to that project. "
"This is equivalent to the AMQP concept of control exchanges."
msgstr ""
#: ./doc/security-guide/ch038_transport-security.xml130(para)
msgid ""
"The configuration for these processes should be restricted to those "
"processes, not only by Directory Access Controls, but through Mandatory "
"Access Controls. The goal of such restrictions is to prevent isolation from "
"other processes running on the same machine(s)."
msgstr ""
#: ./doc/security-guide/ch044_case-studies-database.xml3(title)
msgid "Case Studies: Database"
msgstr ""
#: ./doc/security-guide/ch044_case-studies-database.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address database "
"selection and configuration for their respective private and public clouds."
msgstr ""
#: ./doc/security-guide/ch044_case-studies-database.xml7(para)
msgid ""
"Alice's organization has high availability concerns, so she has elected to "
"use MySQL for the database. She further places the database on the "
"Management network and uses SSL with mutual authentication among the "
"services to ensure secure access. Given there will be no external access of "
"the database, she uses certificates signed with the organization's self-"
"signed root certificate on the database and its access endpoints. Alice "
"creates separate user accounts for each database user, and configures the "
"database to use both passwords and X.509 certificates for authentication. "
"She elects not to use the <systemitem class=\"service\">nova-"
"conductor</systemitem> sub-service due to the desire for fine-grained access"
" control policies and audit support."
msgstr ""
#: ./doc/security-guide/ch044_case-studies-database.xml11(para)
msgid ""
"Bob is concerned about strong separation of his tenants' data, so he has "
"elected to use the Postgres database , known for its stronger security "
"features.  The database resides on the Management network and uses SSL with "
"mutual authentication with the services. Since the database is on the "
"Management network, the database uses certificates signed with the company's"
" self-signed root certificate. Bob creates separate user accounts for each "
"database user, and configures the database to use both passwords and X.509 "
"certificates for authentication. He elects not to use the <systemitem "
"class=\"service\">nova-conductor</systemitem> sub-service due to a desire "
"for fine-grained access control."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch001_acknowledgements.xml8(None)
#: ./doc/security-guide/ch001_acknowledgements.xml11(None)
msgid ""
"@@image: 'static/book-sprint-all-logos.png'; "
"md5=f2d97c3130c32f31412f5af41ad72d39"
msgstr ""
#: ./doc/security-guide/ch001_acknowledgements.xml3(title)
msgid "Acknowledgments"
msgstr ""
#: ./doc/security-guide/ch001_acknowledgements.xml4(para)
msgid ""
"The OpenStack Security Group would like to acknowledge contributions from "
"the following organizations who were instrumental in making this book "
"possible. These are:"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch033_securing-neutron-services.xml24(None)
#: ./doc/security-guide/ch033_securing-neutron-services.xml27(None)
msgid ""
"@@image: 'static/1aa-logical-neutron-flow.png'; "
"md5=63bd2e81863b9b381adb1c6951517498"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml3(title)
msgid "Securing OpenStack Networking Services"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml4(para)
msgid ""
"In order to secure OpenStack Networking, an understanding of the workflow "
"process for tenant instance creation needs to be mapped to security domains."
" "
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml5(para)
msgid ""
"There are four main services that interact with OpenStack Networking. In a "
"typical OpenStack deployment these services map to the following security "
"domains:"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml7(para)
msgid "OpenStack Dashboard: Public and Management"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml10(para)
msgid "OpenStack Identity: Management"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml13(para)
msgid "OpenStack Compute Node: Management and Guest"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml16(para)
msgid ""
"OpenStack Network Node: Management, Guest, and possibly Public depending "
"upon neutron-plugin in use."
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml19(para)
msgid ""
"SDN Services Node: Management, Guest and possibly Public depending upon "
"product used."
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml30(para)
msgid ""
"In order to isolate sensitive data communication between the OpenStack "
"Networking services and other OpenStack core services, we strongly recommend"
" that these communication channels be configured to only allow "
"communications over an isolated management network."
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml32(title)
msgid "OpenStack Networking Service Configuration"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml34(title)
msgid "Restrict Bind Address of the API server: neutron-server"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml35(para)
msgid ""
"To restrict the interface or IP address on which the OpenStack Networking "
"API service binds a network socket for incoming client connections, specify "
"the bind_host and bind_port in the neutron.conf file as shown:"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml44(title)
msgid ""
"Restrict DB and RPC communication of the OpenStack Networking services:"
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml45(para)
msgid ""
"Various components of the OpenStack Networking services use either the "
"messaging queue or database connections to communicate with other components"
" in OpenStack Networking."
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml46(para)
msgid ""
"It is recommended that you follow the guidelines provided in the Database "
"Authentication and Access Control chapter in the Database section for all "
"components that require direct DB connections."
msgstr ""
#: ./doc/security-guide/ch033_securing-neutron-services.xml47(para)
msgid ""
"It is recommended that you follow the guidelines provided in the Queue "
"Authentication and Access Control chapter in the Messaging section for all "
"components that require RPC communication."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch004_book-introduction.xml64(None)
#: ./doc/security-guide/ch004_book-introduction.xml67(None)
msgid ""
"@@image: 'static/marketecture-diagram.png'; "
"md5=4ab13a64f80c210be3120abc5c7aee8a"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml3(title)
msgid "Introduction to OpenStack"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml4(para)
msgid ""
"This guide provides security insight into OpenStack deployments. The "
"intended audience is cloud architects, deployers, and administrators. In "
"addition, cloud users will find the guide both educational and helpful in "
"provider selection, while auditors will find it useful as a reference "
"document to support their compliance certification efforts. This guide is "
"also recommended for anyone interested in cloud security."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml11(para)
msgid ""
"Each OpenStack deployment embraces a wide variety of technologies, spanning "
"Linux distributions, database systems, messaging queues, OpenStack "
"components themselves, access control policies, logging services, security "
"monitoring tools, and much more. It should come as no surprise that the "
"security issues involved are equally diverse, and their in-depth analysis "
"would require several guides. We strive to find a balance, providing enough "
"context to understand OpenStack security issues and their handling, and "
"provide external references for further information. The guide could be read"
" from start to finish or sampled as necessary like a reference."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml12(para)
msgid ""
"We briefly introduce the kinds of clouds: private, public, and hybrid before"
" presenting an overview of the OpenStack components and their related "
"security concerns in the remainder of the chapter."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml14(title)
msgid "Cloud types"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml15(para)
msgid ""
"OpenStack is a key enabler in adoption of cloud technology and has several "
"common deployment use cases. These are commonly known as Public, Private, "
"and Hybrid models. The following sections use the National Institute of "
"Standards and Technology (NIST) <link "
"href=\"http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf\">definition"
" of cloud</link> to introduce these different types of cloud as they apply "
"to OpenStack."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml17(title)
msgid "Public cloud"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml18(para)
msgid ""
"According to NIST, a public cloud is one in which the infrastructure is open"
" to the general public for consumption. OpenStack public clouds are "
"typically run by a service provider and can be consumed by individuals, "
"corporations, or any paying customer. A public cloud provider may expose a "
"full set of features such as software defined networking, block storage, in "
"addition to multiple instance types. Due to the nature of public clouds, "
"they are exposed to a higher degree of risk. As a consumer of a public cloud"
" you should validate that your selected provider has the necessary "
"certifications, attestations, and other regulatory considerations. As a "
"public cloud provider, depending on your target customers, you may be "
"subject to one or more regulations. Additionally, even if not required to "
"meet regulatory requirements, a provider should ensure tenant isolation as "
"well as protecting management infrastructure from external attacks."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml36(title)
msgid "Private cloud"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml37(para)
msgid ""
"At the opposite end of the spectrum is the private cloud. As NIST defines "
"it, a private cloud is provisioned for exclusive use by a single "
"organization comprising multiple consumers (e.g. business units). It may be "
"owned, managed, and operated by the organization, a third-party, or some "
"combination of them, and it may exist on or off premises. Private cloud use "
"cases are diverse, as such, their individual security concerns vary."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml47(title)
msgid "Community cloud"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml48(para)
msgid ""
"NIST defines a community cloud as one whose  infrastructure is provisioned "
"for the exclusive use by a specific community of consumers from "
"organizations that have shared concerns (e.g., mission, security "
"requirements, policy, and compliance considerations). It may be owned, "
"managed, and operated by one or more of the organizations in the community, "
"a third-party, or some combination of them, and it may exist on or off "
"premises."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml51(title)
msgid "Hybrid cloud"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml52(para)
msgid ""
"A hybrid cloud is defined by NIST as a composition of two or more distinct "
"cloud infrastructures (private, community, or public) that remain unique "
"entities, but are bound together by standardized or proprietary technology "
"that enables data and application portability (e.g., cloud bursting for load"
" balancing between clouds). For example an online retailer may have their "
"advertising and catalogue presented on a public cloud that allows for "
"elastic provisioning. This would enable them to handle seasonal loads in a "
"flexible, cost-effective fashion. Once a customer begins to process their "
"order, they are transferred to the more secure private cloud backend that is"
" PCI compliant."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml53(para)
msgid ""
"For the purposes of this document, we treat Community and Hybrid similarly, "
"dealing explicitly only with the extremes of Public and Private clouds from "
"a security perspective. Your security measures depend where your deployment "
"falls upon the private public continuum."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml61(title)
msgid "OpenStack service overview"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml62(para)
msgid ""
"OpenStack embraces a modular architecture to provide a set of core services "
"that facilitates scalability and elasticity as core design tenets. This "
"chapter briefly reviews OpenStack components, their use cases and security "
"considerations."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml72(para)
msgid ""
"OpenStack Compute Service (Nova) provides services to support the management"
" of virtual machine instances at scale, instances that host multi-tiered "
"applications, dev/test environments, \"Big Data\" crunching Hadoop clusters,"
" and/or high performance computing."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml73(para)
msgid ""
"The Compute Service facilitates this management through an abstraction layer"
" that interfaces with supported hypervisors, which we address later on in "
"more detail."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml74(para)
msgid ""
"Later in the guide, we focus generically on the virtualization stack as it "
"relates to hypervisors."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml76(para)
msgid ""
"For information about the current state of feature support, see <link "
"href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack "
"Hypervisor Support Matrix</link>."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml80(para)
msgid ""
"The security of Compute is critical for an OpenStack deployment. Hardening "
"techniques should include support for strong instance isolation, secure "
"communication between Compute sub-components, and resiliency of public-"
"facing <glossterm>API</glossterm> endpoints."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml83(title)
#: ./doc/security-guide/ch027_storage.xml3(title)
msgid "Object Storage"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml84(para)
msgid ""
"The OpenStack Object Storage Service (Swift) provides support for storing "
"and retrieving arbitrary data in the cloud. The Object Storage Service "
"provides both a native API and an Amazon Web Services S3 compatible API. The"
" service provides a high degree of resiliency through data replication and "
"can handle petabytes of data."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml85(para)
msgid ""
"It is important to understand that object storage differs from traditional "
"file system storage. It is best used for static data such as media files "
"(MP3s, images, videos), virtual machine images, and backup files."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml86(para)
msgid ""
"Object security should focus on access control and encryption of data in "
"transit and at rest. Other concerns may relate to system abuse, illegal or "
"malicious content storage, and cross authentication attack vectors."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml89(title)
msgid "Block Storage"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml90(para)
msgid ""
"The OpenStack Block Storage service (Cinder) provides persistent block "
"storage for compute instances. The Block Storage Service is responsible for "
"managing the life-cycle of block devices, from the creation and attachment "
"of volumes to instances, to their release."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml95(para)
msgid ""
"Security considerations for block storage are similar to that of object "
"storage."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml98(title)
msgid "OpenStack Networking"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml99(para)
msgid ""
"The OpenStack Networking Service (Neutron, previously called Quantum) "
"provides various networking services to cloud users (tenants) such as IP "
"address management, <glossterm>DNS</glossterm>, <glossterm>DHCP</glossterm>,"
" load balancing, and security groups (network access rules, like firewall "
"policies). It provides a framework for software defined networking (SDN) "
"that allows for pluggable integration with various networking solutions."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml100(para)
msgid ""
"OpenStack Networking allows cloud tenants to manage their guest network "
"configurations. Security concerns with the networking service include "
"network traffic isolation, availability, integrity and confidentiality."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml104(para)
msgid ""
"The OpenStack Dashboard Service (Horizon) provides a web-based interface for"
" both cloud administrators and cloud tenants. Through this interface "
"administrators and tenants can provision, manage, and monitor cloud "
"resources. Horizon is commonly deployed in a public facing manner with all "
"the usual security concerns of public web portals."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml107(title)
msgid "Identity Service"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml108(para)
msgid ""
"The OpenStack Identity Service (Keystone) is a <emphasis "
"role=\"bold\">shared service</emphasis> that provides authentication and "
"authorization services throughout the entire cloud infrastructure. The "
"Identity Service has pluggable support for multiple forms of authentication."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml109(para)
msgid ""
"Security concerns here pertain to trust in authentication, management of "
"authorization tokens, and secure communication."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml112(title)
msgid "Image Service"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml113(para)
msgid ""
"The OpenStack Image Service (Glance) provides disk image management "
"services. The Image Service provides image discovery, registration, and "
"delivery services to Compute, the compute service, as needed."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml114(para)
msgid ""
"Trusted processes for managing the life cycle of disk images are required, "
"as are all the previously mentioned issues with respect to data security."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml117(title)
msgid "Other supporting technology"
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml118(para)
msgid ""
"OpenStack relies on messaging for internal communication between several of "
"its services. By default, OpenStack uses message queues based on the "
"Advanced Message Queue Protocol (<glossterm>AMQP</glossterm>). Similar to "
"most OpenStack services, it supports pluggable components. Today the "
"implementation backend could be <glossterm>RabbitMQ</glossterm>, "
"<glossterm>Qpid</glossterm>, or <glossterm>ZeroMQ</glossterm>."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml119(para)
msgid ""
"As most management commands flow through the message queueing system, it is "
"a primary security concern for any OpenStack deployment. Message queueing "
"security is discussed in detail later in this guide."
msgstr ""
#: ./doc/security-guide/ch004_book-introduction.xml120(para)
msgid ""
"Several of the components use databases though it is not explicitly called "
"out. Securing the access to the databases and their contents is yet another "
"security concern, and consequently discussed in more detail later in this "
"guide."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml3(title)
msgid "Compliance Activities"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml4(para)
msgid ""
"There are a number of standard activities that will greatly assist with the "
"compliance process. In this chapter we outline some of the most common "
"compliance activities. These are not specific to OpenStack, however we "
"provide references to relevant sections in this book as useful context."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml6(title)
msgid "Information Security Management System (ISMS)"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml7(para)
msgid ""
"An Information Security Management System (ISMS) is a comprehensive set of "
"policies and processes that an organization creates and maintains to manage "
"risk to information assets. The most common ISMS for cloud deployments is "
"<link href=\"http://www.27000.org/iso-27001.htm\">ISO/IEC 27001/2</link>, "
"which creates a solid foundation of security controls and practices for "
"achieving more stringent compliance certifications."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml10(title)
msgid "Risk Assessment"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml11(para)
msgid ""
"A Risk Assessment framework identifies risks within an organization or "
"service, and specifies ownership of these risks, along with implementation "
"and mitigation strategies. Risks apply to all areas of the service, from "
"technical controls to environmental disaster scenarios and human elements, "
"for example a malicious insider (or rogue employee). Risks can be rated "
"using a variety of mechanisms, for example likelihood vs impact. An "
"OpenStack deployment risk assessment can include control gaps that are "
"described in this book."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml14(title)
msgid "Access &amp; Log Reviews"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml15(para)
msgid ""
"Periodic access and log reviews are required to ensure authentication, "
"authorization, and accountability in a service deployment. Specific guidance"
" for OpenStack on these topics are discussed in-depth in the logging "
"section."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml18(title)
msgid "Backup and Disaster Recovery"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml19(para)
msgid ""
"Disaster Recovery (DR) and Business Continuity Planning (BCP) plans are "
"common requirements for ISMS and compliance activities. These plans must be "
"periodically tested as well as documented. In OpenStack key areas are found "
"in the management security domain, and anywhere that single points of "
"failure (SPOFs) can be identified. See the section on secure backup and "
"recovery for additional details."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml22(title)
msgid "Security Training"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml23(para)
msgid ""
"Annual, role-specific, security training is a mandatory requirement for "
"almost all compliance certifications and attestations. To optimise the "
"effectiveness of security training, a common method is to provide role "
"specific training, for example to developers, operational personnel, and "
"non-technical employees. Additional cloud security or OpenStack security "
"training based on this hardening guide would be ideal."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml26(title)
msgid "Security Reviews"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml27(para)
msgid ""
"As OpenStack is a popular open source project, much of the codebase and "
"architecture has been scrutinized by individual contributors, organizations "
"and enterprises. This can be advantageous from a security perspective, "
"however the need for security reviews is still a critical consideration for "
"service providers, as deployments vary, and security is not always the "
"primary concern for contributors. A comprehensive security review process "
"may include architectural review, threat modelling, source code analysis and"
" penetration testing. There are many techniques and recommendations for "
"conducting security reviews that can be found publicly posted. A well-tested"
" example is the <link "
"href=\"http://www.microsoft.com/security/sdl/process/release.aspx\">Microsoft"
" SDL</link>, created as part of the Microsoft Trustworthy Computing "
"Initiative."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml44(para)
msgid ""
"Security updates are critical to any IaaS deployment, whether private or "
"public. Vulnerable systems expand attack surfaces, and are obvious targets "
"for attackers. Common scanning technologies and vulnerability notification "
"services can help mitigate this threat. It is important that scans are "
"authenticated and that mitigation strategies extend beyond simple perimeter "
"hardening. Multi-tenant architectures such as OpenStack are particularly "
"prone to hypervisor vulnerabilities, making this a critical part of the "
"system for vulnerability management. See the section on instance isolation "
"for additional details."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml47(title)
msgid "Data Classification"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml48(para)
msgid ""
"Data Classification defines a method for classifying and handling "
"information, often to protect customer information from accidental or "
"deliberate theft, loss, or inappropriate disclosure. Most commonly this "
"involves classifying information as sensitive or non-sensitive, or as "
"personally identifiable information (PII). Depending on the context of the "
"deployment various other classifying criteria may be used (government, "
"health-care etc). The underlying principle is that data classifications are "
"clearly defined and in-use. The most common protective mechanisms include "
"industry standard encryption technologies. See the data security section for"
" additional details."
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml51(title)
msgid "Exception Process"
msgstr ""
#: ./doc/security-guide/ch063_compliance-activities.xml52(para)
msgid ""
"An exception process is an important component of an ISMS. When certain "
"actions are not compliant with security policies that an organization has "
"defined, they must be logged. Appropriate justification, description and "
"mitigation details need to be included, and signed off by appropriate "
"authorities. OpenStack default configurations may vary in meeting various "
"compliance criteria, areas that fail to meet compliance requirements should "
"be logged, with potential fixes considered for contribution to the "
"community."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch027_storage.xml37(None)
msgid ""
"@@image: 'static/swift_network_diagram-1.png'; "
"md5=83c094bb051cbe5e6161d3f7442f6136"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch027_storage.xml90(None)
#: ./doc/security-guide/ch027_storage.xml96(None)
msgid ""
"@@image: 'static/swift_network_diagram-2.png'; "
"md5=69f8effe3f5d0f3cbccfb8c5a5dd299e"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml4(para)
msgid ""
"OpenStack Object Storage (Swift) is a service that provides storage and "
"retrieval of data over HTTP. Objects (blobs of data) are stored in an "
"organizational hierarchy that offers anonymous read-only access or ACL "
"defined access based on the authentication mechanism."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml9(para)
msgid ""
"A consumer can store objects, modify them, or access them using the HTTP "
"protocol and REST APIs. Backend components of Object Storage use different "
"protocols for keeping the information synchronized in a redundant cluster of"
" services. For more details on the API and the backend components see the "
"<link href=\"http://docs.openstack.org/api/openstack-object-"
"storage/1.0/content/\">OpenStack Storage documentation</link>."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml15(para)
msgid ""
"For this document the components will be grouped into the following primary "
"groups:"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml19(para)
msgid "Proxy services"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml20(para)
msgid "Auth services"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml23(para)
#: ./doc/security-guide/ch027_storage.xml140(td)
msgid "Account service"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml24(para)
#: ./doc/security-guide/ch027_storage.xml145(td)
msgid "Container service"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml25(para)
#: ./doc/security-guide/ch027_storage.xml150(td)
msgid "Object service"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml21(para)
msgid "Storage services <placeholder-1/>"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml31(title)
msgid ""
"An example diagram from the OpenStack Object Storage Administration Guide "
"(2013)"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml42(para)
msgid ""
"An Object Storage environment does not have to necessarily be on the "
"Internet and could also be a private cloud with the \"Public Switch\" being "
"part of the organization’s internal network infrastructure."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml50(title)
msgid "First thing to secure – the network"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml51(para)
msgid ""
"The first aspect of a secure architecture design for Object Storage is in "
"the networking component. The Storage service nodes use rsync between each "
"other for copying data to provide replication and high availability. In "
"addition, the proxy service communicates with the Storage service when "
"relaying data back and forth between the end-point client and the cloud "
"environment."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml58(para)
msgid ""
"None of these use any type of encryption or authentication at this "
"layer/tier."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml60(para)
msgid ""
"This is why you see a \"Private Switch\" or private network ([V]LAN) in "
"architecture diagrams. This data domain should be separate from other "
"OpenStack data networks as well. For further discussion on security domains "
"please see <xref linkend=\"ch005_security-domains\"/>."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml66(para)
msgid ""
"<emphasis>Rule:</emphasis> Use a private (V)LAN network segment for your "
"Storage services in the data domain."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml69(para)
msgid ""
"This necessitates that the Proxy service nodes have dual interfaces "
"(physical or virtual):"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml72(para)
msgid "One as a \"public\" interface for consumers to reach"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml74(para)
msgid "Another as a \"private\" interface with access to the storage nodes"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml77(para)
msgid "The following figure demonstrates one possible network architecture."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml82(title)
msgid "Object storage network architecture with a management node (OSAM)"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml103(title)
msgid "Securing services – general"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml105(title)
msgid "Service runas user"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml106(para)
msgid ""
"It is recommended that you configure each service to run under a non-root "
"(UID 0) service account. One recommendation is the username \"swift\" with "
"primary group \"swift.\""
msgstr ""
#: ./doc/security-guide/ch027_storage.xml112(title)
msgid "File permissions"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml113(para)
msgid ""
"/etc/swift contains information about the ring topology and environment "
"configuration. The following permissions are recommended:"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml121(para)
msgid ""
"This restricts only root to be able to modify configuration files while "
"allowing the services to read them via their group membership in \"swift.\""
msgstr ""
#: ./doc/security-guide/ch027_storage.xml127(title)
msgid "Securing storage services"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml128(para)
msgid ""
"The following are the default listening ports for the various storage "
"services:"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml133(td)
msgid "Service Name"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml134(td)
msgid "Port"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml135(td)
msgid "Type"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml141(td)
msgid "6002"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml142(td)
#: ./doc/security-guide/ch027_storage.xml147(td)
#: ./doc/security-guide/ch027_storage.xml152(td)
#: ./doc/security-guide/ch027_storage.xml157(td)
msgid "TCP"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml146(td)
msgid "6001"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml151(td)
msgid "6000"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml155(td)
msgid "Rsync"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml156(td)
msgid "873"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml161(para)
msgid ""
"Authentication does not happen at this level in Object Storage. If someone "
"was able to connect to a Storage service node on one of these ports they "
"could access or modify data without authentication. In order to secure "
"against this issue you should follow the recommendations given previously "
"about using a private storage network."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml168(title)
msgid "Object storage \"account\" terminology"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml169(para)
msgid ""
"An Object Storage \"Account\" is not a user account or credential. The "
"following explains the relations:"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml174(td)
msgid "OpenStack Object Storage Account"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml175(td)
msgid ""
"Collection of containers; not user accounts or authentication. Which users "
"are associated with the account and how they may access it depends on the "
"authentication system used. See authentication systems later. Referred to in"
" this document as OSSAccount."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml184(td)
msgid "OpenStack Object Storage Containers"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml185(td)
msgid ""
"Collection of objects. Metadata on the container is available for ACLs. The "
"meaning of ACLs is dependent on the authentication system used."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml191(td)
msgid "OpenStack Object Storage Objects"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml192(td)
msgid ""
"The actual data objects. ACLs at the object level are also possible with "
"metadata. It is dependent on the authentication system used."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml200(para)
msgid ""
"<?dbhtml bgcolor=\"#DDFADE\" ?><?dbfo bgcolor=\"#DDFADE\" ?> Another way of "
"thinking about the above would be: A single shelf (Account) holds zero or "
"more -&gt; buckets (Containers) which each hold zero or more -&gt; objects. "
"A garage (Object Storage cloud environment) may have multiple shelves "
"(Accounts) with each shelf belonging to zero or more users."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml210(para)
msgid ""
"At each level you may have ACLs that dictate who has what type of access. "
"ACLs are interpreted based on what authentication system is in use. The two "
"most common types of authentication providers used are Keystone and SWAuth. "
"Custom authentication providers are also possible. Please see the Object "
"Storage Authentication section for more information."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml220(title)
msgid "Securing proxy services"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml221(para)
msgid ""
"A Proxy service node should have at least two interfaces (physical or "
"virtual): one public and one private. The public interface may be protected "
"via firewalls or service binding. The public facing service is an HTTP web "
"server that processes end-point client requests, authenticates them, and "
"performs the appropriate action. The private interface does not require any "
"listening services but is instead used to establish outgoing connections to "
"storage service nodes on the private storage network."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml231(title)
msgid "Use SSL/TLS"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml232(para)
msgid ""
"The built-in or included web server that comes with Swift supports SSL, but "
"it does not support transmission of the entire SSL certificate chain. This "
"causes issues when you use a third party trusted and signed certificate (ex:"
" Verisign) for your cloud. The current work around is to not use the built-"
"in web server but an alternative web server instead that supports sending "
"both the public server certificate as well as the CA signing authorities "
"intermediate certificate(s). This allows for end-point clients that have the"
" CA root certificate in their trust store to be able to successfully "
"validate your cloud environment’s SSL certificate and chain. An example of "
"how to do this with mod_wsgi and Apache is given below. Also consult the "
"<link "
"href=\"http://docs.openstack.org/developer/swift/apache_deployment_guide.html\">Apache"
" Deployment Guide</link>"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml248(para)
msgid "Modify file <filename>/etc/apache2/envvars</filename> with"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml254(para)
msgid "An alternative is to modify your Apache conf file with"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml260(para)
msgid "Create a \"swift\" directory in your Apache document root:"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml263(para)
msgid ""
"Create the file <filename>$YOUR_APACHE_DOC_ROOT/swift/proxy-"
"server.wsgi</filename>:"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml269(title)
msgid "HTTP listening port"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml270(para)
msgid ""
"You should run your Proxy service web server as a non-root (no UID 0) user "
"such as \"swift\" mentioned before. The use of a port greater than 1024 is "
"required to make this easy and avoid running any part of the web container "
"as root. Doing so is not a burden as end-point clients are not typically "
"going to type in the URL manually into a web browser to browse around in the"
" object storage. Additionally, for clients using the HTTP REST API and "
"performing authentication they will normally automatically grab the full "
"REST API URL they are to use as provided by the authentication response. "
"OpenStack’s REST API allows for a client to authenticate to one URL and then"
" be told to use a completely different URL for the actual service. Example: "
"Client authenticates to "
"<uri>https://identity.cloud.example.org:55443/v1/auth</uri> and gets a "
"response with their authentication key and Storage URL (the URL of the proxy"
" nodes or load balancer) of "
"<uri>https://swift.cloud.example.org:44443/v1/AUTH_8980</uri>."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml291(para)
msgid ""
"The method for configuring your web server to start and run as a non-root "
"user varies by web server and OS."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml296(title)
msgid "Load balancer"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml297(para)
msgid ""
"If the option of using Apache is not feasible or for performance you wish to"
" offload your SSL work you may employ a dedicated network device load "
"balancer. This is also the common way to provide redundancy and load "
"balancing when using multiple proxy nodes."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml302(para)
msgid ""
"If you choose to offload your SSL ensure that the network link between the "
"load balancer and your proxy nodes is on a private (V)LAN segment such that "
"other nodes on the network (possibly compromised) cannot wiretap (sniff) the"
" unencrypted traffic. If such a breach were to occur the attacker could gain"
" access to end-point client or cloud administrator credentials and access "
"the cloud data."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml310(para)
msgid ""
"The authentication service you use (e.g. Keystone, SWAuth) will determine "
"how you configure a different URL in the responses to end-clients so they "
"use your load balancer instead of an individual Proxy service node."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml318(title)
msgid "Object storage authentication"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml319(para)
msgid ""
"Object Storage uses wsgi to provide a middleware for authentication of end-"
"point clients. The authentication provider defines what roles and user types"
" exist. Some use traditional username and password credentials while others "
"may leverage API key tokens or even client-side x.509 SSL certificates. "
"Custom providers can be integrated in using the wsgi model."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml327(title)
msgid "Keystone"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml328(para)
msgid ""
"Keystone is the commonly used Identity provider in OpenStack. It may also be"
" used for authentication in Object Storage. Coverage of securing Keystone is"
" already provided in <xref linkend=\"ch024_authentication\"/>."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml334(title)
msgid "SWAuth"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml335(para)
msgid ""
"SWAuth is another alternative to Keystone. In contrast to Keystone it stores"
" the user accounts, credentials, and metadata in object storage itself. More"
" information can be found on the SWAuth website at <link "
"href=\"http://gholt.github.io/swauth/\">http://gholt.github.io/swauth/</link>."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml344(title)
msgid "Other notable items"
msgstr ""
#: ./doc/security-guide/ch027_storage.xml345(para)
msgid ""
"In /etc/swift/swift.conf on every service node there is a "
"\"swift_hash_path_suffix\" setting. This is provided to reduce the chance of"
" hash collisions for objects being stored and avert one user overwriting the"
" data of another user."
msgstr ""
#: ./doc/security-guide/ch027_storage.xml350(para)
msgid ""
"This value should be initially set with a cryptographically secure random "
"number generator and consistent across all service nodes. Ensure that it is "
"protected with proper ACLs and that you have a backup copy to avoid data "
"loss."
msgstr ""
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml3(title)
msgid "Introduction to Case Studies"
msgstr ""
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml4(para)
msgid ""
"Throughout this guide we will refer to two running case studies. We "
"introduce them here and will return to them at the end of each chapter."
msgstr ""
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml6(title)
msgid "Case Study : Alice the private cloud builder"
msgstr ""
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml7(para)
msgid ""
"Alice is deploying a private cloud for use by a government department in the"
" US. The cloud must comply with relevant standards such as FedRAMP. The "
"security paperwork requirements for this cloud are very high. It will have "
"no direct access to the internet: its API endpoints, compute instances and "
"other resources will be exposed only to systems within the department's "
"network which is entirely air-gapped from all other networks. The cloud can "
"access other network services on the Organization's Intranet e.g. the "
"authentication and logging services."
msgstr ""
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml10(title)
msgid "Case Study : Bob the public cloud provider"
msgstr ""
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml11(para)
msgid ""
"Bob is a lead architect for a company deploying a large greenfield public "
"cloud. This cloud will provide IaaS for the masses, allowing any consumer "
"with a valid credit card access to utility computing and storage but the "
"primary focus is enterprise customers. Data privacy concerns are a big "
"priority for Bob as they are seen as a major barrier to large-scale adoption"
" of the cloud by organizations."
msgstr ""
#: ./doc/security-guide/ch030_state-of-networking.xml3(title)
msgid "State of Networking"
msgstr ""
#: ./doc/security-guide/ch030_state-of-networking.xml4(para)
msgid ""
"OpenStack Networking in the Grizzly release enables the end-user or tenant "
"to define, utilize, and consume networking resources in new ways that had "
"not been possible in previous OpenStack Networking releases. OpenStack "
"Networking provides a tenant-facing API for defining network connectivity "
"and IP addressing for instances in the cloud in addition to orchestrating "
"the network configuration. With the transition to an API-centric networking "
"service, cloud architects and administrators should take into consideration "
"best practices to secure physical and virtual network infrastructure and "
"services."
msgstr ""
#: ./doc/security-guide/ch030_state-of-networking.xml5(para)
msgid ""
"OpenStack Networking was designed with a plug-in architecture that provides "
"extensibility of the API via open source community or third-party services. "
"As you evaluate your architectural design requirements, it is important to "
"determine what features are available in OpenStack Networking core services,"
" any additional services that are provided by third-party products, and what"
" supplemental services are required to be implemented in the physical "
"infrastructure."
msgstr ""
#: ./doc/security-guide/ch030_state-of-networking.xml6(para)
msgid ""
"This section is a high-level overview of what processes and best practices "
"should be considered when implementing OpenStack Networking. We will talk "
"about the current state of services that are available, what future services"
" will be implemented, and the current limitations in this project."
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml3(title)
msgid "Database Transport Security"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml4(para)
msgid ""
"This chapter covers issues related to network communications to and from the"
" database server. This includes IP address bindings and encrypting network "
"traffic with SSL."
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml6(title)
msgid "Database Server IP Address Binding"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml7(para)
msgid ""
"To isolate sensitive database communications between the services and the "
"database, we strongly recommend that the database server(s) be configured to"
" only allow communications to and from the database over an isolated "
"management network. This is achieved by restricting the interface or IP "
"address on which the database server binds a network socket for incoming "
"client connections."
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml9(title)
msgid "Restricting Bind Address for MySQL"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml10(para)
#: ./doc/security-guide/ch043_database-transport-security.xml33(para)
msgid "In my.cnf:"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml17(title)
msgid "Restricting Listen Address for PostgreSQL"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml18(para)
msgid "In postgresql.conf:"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml24(title)
msgid "Database Transport"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml25(para)
msgid ""
"In addition to restricting database communications to the management "
"network, we also strongly recommend that the cloud administrator configure "
"their database backend to require SSL. Using SSL for the database client "
"connections  protects the communications from tampering and eavesdropping. "
"As will be discussed in the next section, using SSL also provides the "
"framework for doing database user authentication via X.509 certificates "
"(commonly referred to as PKI). Below is guidance on how SSL is typically "
"configured for the two popular database backends MySQL and PostgreSQL."
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml27(para)
msgid ""
"NOTE: When installing the certificate and key files, ensure that the file "
"permissions are restricted, for example <literal>chmod 0600</literal>, and "
"the ownership is restricted to the database daemon user to prevent "
"unauthorized access by other processes and users on the database server."
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml31(title)
msgid "MySQL SSL Configuration"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml32(para)
msgid ""
"The following lines should be added in the system-wide MySQL configuration "
"file:"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml40(para)
#: ./doc/security-guide/ch043_database-transport-security.xml50(para)
msgid ""
"Optionally, if you wish to restrict the set of SSL ciphers used for the "
"encrypted connection. See <link "
"href=\"http://www.openssl.org/docs/apps/ciphers.html\">http://www.openssl.org/docs/apps/ciphers.html</link>"
" for a list of ciphers and the syntax for specifying the cipher string:"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml46(title)
msgid "PostgreSQL SSL Configuration"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml47(para)
msgid ""
"The following lines should be added in the system-wide PostgreSQL "
"configuration file, <literal>postgresql.conf</literal>."
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml53(para)
msgid ""
"The server certificate, key, and certificate authority (CA) files should be "
"placed in the $PGDATA directory in the following files:"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml55(para)
msgid "$PGDATA/server.crt - Server certificate"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml58(para)
msgid "$PGDATA/server.key - Private key corresponding to server.crt"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml61(para)
msgid "$PGDATA/root.crt - Trusted certificate authorities"
msgstr ""
#: ./doc/security-guide/ch043_database-transport-security.xml64(para)
msgid "$PGDATA/root.crl - Certificate revocation list"
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml3(title)
msgid "Key Management"
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml4(para)
msgid ""
"To address the often mentioned concern of tenant data privacy and limiting "
"cloud provider liability, there is greater interest within the OpenStack "
"community to make data encryption more ubiquitous. It is relatively easy for"
" an end-user to encrypt their data prior to saving it to the cloud, and this"
" is a viable path for tenant objects such as media files, database archives "
"among others. However, when client side encryption is used for virtual "
"machine images, block storage etc, client intervention is necessary in the "
"form of presenting keys to unlock the data for further use. To seamlessly "
"secure the data and yet have it accessible without burdening the client with"
" having to manage their keys and interactively provide them calls for a key "
"management service within OpenStack. Providing encryption and key management"
" services as part of OpenStack eases data-at-rest security adoption, "
"addresses customer concerns about the privacy and misuse of their data with "
"the added advantage of limiting cloud provider liability. Provider liability"
" is of concern in multi-tenant public clouds with respect to handing over "
"tenant data during a misuse investigation."
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml5(para)
msgid ""
"A key management service is in the early stages of being developed and has a"
" way to go before becoming an official component of OpenStack. Refer to "
"<link "
"href=\"https://github.com/cloudkeep/barbican/wiki/_pages\">https://github.com/cloudkeep/barbican/wiki/_pages</link>"
" for details."
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml6(para)
msgid ""
"It shall support the creation of keys, and their secure saving (with a "
"service master-key). Some of the design questions still being debated are "
"how much of the Key Management Interchange Protocol (KMIP) to support, key "
"formats, and certificate management.  The key manager will be pluggable to "
"facilitate deployments that need a third-party Hardware Security Module "
"(HSM)."
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml7(para)
msgid ""
"OpenStack Block Storage, Cinder, is the first service looking to integrate "
"with the key manager to provide volume encryption."
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml9(title)
msgid "References:"
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml11(link)
msgid "Barbican"
msgstr ""
#: ./doc/security-guide/ch048_key-management.xml14(link)
msgid "KMIP"
msgstr ""
#: ./doc/security-guide/ch009_case-studies.xml3(title)
msgid "Case Studies: System Documentation"
msgstr ""
#: ./doc/security-guide/ch009_case-studies.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address their system "
"documentation requirements. The documentation suggested above includes "
"hardware and software records, network diagrams, and system configuration "
"details."
msgstr ""
#: ./doc/security-guide/ch009_case-studies.xml7(para)
msgid ""
"Alice needs detailed documentation to satisfy FedRamp requirements.  She "
"sets up a configuration management database (CMDB) to store information "
"regarding all of the hardware, firmware, and software versions used "
"throughout the cloud. She also creates a network diagram detailing the cloud"
" architecture, paying careful attention to the security domains and the "
"services that span multiple security domains."
msgstr ""
#: ./doc/security-guide/ch009_case-studies.xml8(para)
msgid ""
"Alice also needs to record each network service running in the cloud, what "
"interfaces and ports it binds to, the security domains for each service, and"
" why the service is needed. Alice decides to build automated tools to log "
"into each system in the cloud over secure shell (SSH) using the <link "
"href=\"http://fabfile.org\">Python Fabric library</link>. The tools collect "
"and store the information in the CMDB, which simplifies the audit process."
msgstr ""
#: ./doc/security-guide/ch009_case-studies.xml12(para)
msgid "In this case, Bob will approach these steps the same as Alice."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml3(title)
msgid "Case Studies: Instance Management"
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would architect their clouds"
" with respect to instance entropy, scheduling instances, trusted images, and"
" instance migrations."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml7(para)
msgid ""
"Alice has a need for lots of high quality entropy in the instances. For this"
" reason, she decides to purchase hardware with Intel Ivy Bridge chip sets "
"that support the RdRand instruction on each compute node. Using the entropy "
"gathering daemon (EGD) and LibVirt's EGD support, Alice ensures that this "
"entropy pool is distributed to the instances on each compute node."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml8(para)
msgid ""
"For instance scheduling, Alice uses the trusted compute pools to ensure that"
" all cloud workloads are deployed to nodes that presented a proper boot time"
" attestation. Alice decides to disable user permissions for image uploading "
"to help ensure that the images used in the cloud are generated in a known "
"and trusted manner by the cloud administrators."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml9(para)
msgid ""
"Finally, Alice disables instance migrations as this feature is less critical"
" for the high performance application workloads expected to run in this "
"cloud. This helps avoid the various security concerns related to instance "
"migrations."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml13(para)
msgid ""
"Bob is aware that entropy will be a concern for some of his customers, such "
"as those in the financial industry. However, due to the added cost and "
"complexity, Bob has decided to forgo integrating hardware entropy into the "
"first iteration of his cloud. He adds hardware entropy as a fast-follow to "
"do for a later improvement for the second generation of his cloud "
"architecture."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml14(para)
msgid ""
"Bob is interested in ensuring that customers receive a high quality of "
"service. He is concerned that providing too much explicit user control over "
"instance scheduling could negatively impact the quality of service. So he "
"disables this feature. Bob provides images in the cloud from a known trusted"
" source for users to use. Additionally, he also allows users to upload their"
" own images. However, users cannot generally share their images. This helps "
"prevent a user from sharing a malicious image, which could negatively impact"
" the security of other users in the cloud."
msgstr ""
#: ./doc/security-guide/ch056_case-studies-instance-management.xml15(para)
msgid ""
"For migrations, Bob wants to enable secure instance migrations in order to "
"support rolling upgrades with minimal user downtime. Bob ensures that all "
"migrations occur on an isolated VLAN. He plans to defer implementing "
"encrypted migrations until this is better supported in Nova client tools. "
"However, he makes a note to track this carefully and switch to encrypted "
"migrations as soon as possible."
msgstr ""
#: ./doc/security-guide/ch_preface.xml10(title)
msgid "Preface"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch008_system-roles-types.xml43(None)
#: ./doc/security-guide/ch008_system-roles-types.xml46(None)
msgid ""
"@@image: 'static/services-protocols-ports.png'; "
"md5=fb1e9f47d969127b7a5ca683d38cfe20"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml3(title)
msgid "System Documentation Requirements"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml4(para)
msgid ""
"The system documentation for an OpenStack cloud deployment should follow the"
" templates and best practices for the Enterprise Information Technology "
"System in your organization. Organizations often have compliance "
"requirements which may require an overall System Security Plan to inventory "
"and document the architecture of a given system. There are common challenges"
" across the industry related to documenting the dynamic cloud infrastructure"
" and keeping the information up-to-date."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml6(title)
msgid "System Roles &amp; Types"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml7(para)
msgid ""
"It is necessary to describe the two broadly defined types of nodes that "
"generally make up an OpenStack installation."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml9(para)
msgid ""
"Infrastructure nodes, or the nodes that run the cloud related services such "
"as the OpenStack Identity service, the message queuing service, storage, "
"networking, and other services required to support the operation of the "
"cloud."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml12(para)
msgid ""
"The other type of nodes are compute, storage, or other resource nodes, those"
" that provide storage capacity or virtual machines for your cloud."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml17(title)
msgid "System Inventory"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml18(para)
msgid ""
"Documentation should provide a general description of the OpenStack "
"environment and cover all systems used (production, development, test, "
"etc.). Documenting system components, networks, services, and software often"
" provides the bird's-eye view needed to thoroughly cover and consider "
"security concerns, attack vectors and possible security domain bridging "
"points.  A system inventory may need to capture ephemeral resources such as "
"virtual machines or virtual disk volumes that would otherwise be persistent "
"resources in a traditional IT system."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml20(title)
msgid "Hardware Inventory"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml21(para)
msgid ""
"Clouds without stringent compliance requirements for written documentation "
"may at least benefit from having a Configuration Management Database "
"(<glossterm>CMDB</glossterm>). CMDB's are normally used for hardware asset "
"tracking and overall life-cycle management. By leveraging a CMDB, an "
"organization can quickly identify cloud infrastructure hardware (e.g. "
"compute nodes, storage nodes, and network devices) that exists on the "
"network but may not be adequately protected and/or forgotten. OpenStack "
"provisioning system may provide some CMDB-like functions especially if auto-"
"discovery features of hardware attributes are available."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml24(title)
msgid "Software Inventory"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml25(para)
msgid ""
"Just as with hardware, all software components within the OpenStack "
"deployment should be documented. Components here should include system "
"databases; OpenStack software components and supporting sub-components; and,"
" supporting infrastructure software such as load-balancers, reverse proxies,"
" and network address translators. Having an authoritative list like this may"
" be critical toward understanding total system impact due to a compromise or"
" vulnerability of a specific class of software."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml29(title)
msgid "Network Topology"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml30(para)
msgid ""
"A Network Topology should be provided with highlights specifically calling "
"out the data flows and bridging points between the security domains. Network"
" ingress and egress points should be identified along with any OpenStack "
"logical system boundaries. Multiple diagrams may be needed to provide "
"complete visual coverage of the system.  A network topology document should "
"include virtual networks created on behalf of tenants by the system along "
"with virtual machine instances and gateways created by OpenStack."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml33(title)
msgid "Services, Protocols and Ports"
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml34(para)
msgid ""
"The Service, Protocols and Ports table provides important additional detail "
"of an OpenStack deployment. A table view of all services running within the "
"cloud infrastructure can immediately inform, guide, and help check security "
"procedures. Firewall configuration, service port conflicts, security "
"remediation areas, and compliance requirements become easier to manage when "
"you have concise information available. E.g. tabular information as shown "
"below."
msgstr ""
#: ./doc/security-guide/ch008_system-roles-types.xml49(para)
msgid ""
"Referencing a table of services, protocols and ports can help in "
"understanding the relationship between OpenStack components. It is highly "
"recommended that OpenStack deployments have information similar to this on "
"record."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml4(para)
msgid ""
"Horizon is the OpenStack dashboard, providing access to a majority of the "
"capabilities available in OpenStack. These include provisioning users, "
"defining instance flavors, uploading VM images, managing networks, setting "
"up security groups, starting instances, and accessing the instances via a "
"console."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml5(para)
msgid ""
"The dashboard is based on the Django web framework, therefore secure "
"deployment practices for Django apply directly to Horizon. This guide "
"provides a popular set of Django security recommendations, further "
"information can be found by reading the <link "
"href=\"https://docs.djangoproject.com/en/1.5/#security\">Django deployment "
"and security documentation</link>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml6(para)
msgid ""
"The dashboard ships with reasonable default security settings, and has good "
"<link "
"href=\"http://docs.openstack.org/developer/horizon/topics/deployment.html\">deployment"
" and configuration documentation</link>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml8(title)
msgid "Basic Web Server Configuration"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml9(para)
msgid ""
"The dashboard should be deployed as a Web Services Gateway Interface (WSGI) "
"application behind an HTTPS proxy such as Apache or nginx. If Apache is not "
"already in use, we recommend nginx since it is lighter weight and easier to "
"configure correctly."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml10(para)
msgid ""
"When using nginx, we recommend <link "
"href=\"http://docs.gunicorn.org/en/latest/deploy.html\">gunicorn</link> as "
"the wsgi host with an appropriate number of synchronous workers. We strongly"
" advise against deployments using fastcgi, scgi, or uWSGI. We strongly "
"advise against the use of synthetic performance benchmarks when choosing a "
"wsgi server."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml11(para)
msgid ""
"When using Apache, we recommend <link "
"href=\"https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/\">mod_wsgi</link>"
" to host dashboard."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml14(title)
msgid "HTTPS"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml15(para)
msgid ""
"The dashboard should be deployed behind a secure HTTPS server using a valid,"
" trusted certificate from a recognized certificate authority (CA). Private "
"organization-issued certificates are only appropriate when the root of trust"
" is pre-installed in all user browsers."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml16(para)
msgid ""
"HTTP requests to the dashboard domain should be configured to redirect to "
"the fully qualified HTTPS URL."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml19(title)
msgid "HTTP Strict Transport Security (HSTS)"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml20(para)
msgid "It is highly recommended to use HTTP Strict Transport Security (HSTS)."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml21(para)
msgid ""
"NOTE: If you are using an HTTPS proxy in front of your web server, rather "
"than using an HTTP server with HTTPS functionality, follow the <link "
"href=\"https://docs.djangoproject.com/en/1.5/ref/settings/#secure-proxy-ssl-"
"header\">Django documentation on modifying the SECURE_PROXY_SSL_HEADER "
"variable</link>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml22(para)
msgid ""
"See the chapter on PKI/SSL Everywhere for more specific recommendations and "
"server configurations for HTTPS configurations, including the configuration "
"of HSTS."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml25(title)
msgid "Frontend Caching"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml26(para)
msgid ""
"Since dashboard is rendering dynamic content passed directly from OpenStack "
"API requests, we do not recommend frontend caching layers such as varnish. "
"In Django, static media is directly served from Apache or nginx and already "
"benefits from web host caching."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml29(title)
msgid "Domain Names"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml30(para)
msgid ""
"Many organizations typically deploy web applications at subdomains of an "
"overarching organization domain. It is natural for users to expect a domain "
"of the form openstack.example.org. In this context, there are often many "
"other applications deployed in the same second-level namespace, often "
"serving user-controlled content. This name structure is convenient and "
"simplifies nameserver maintenance."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml31(para)
msgid ""
"We strongly recommend deploying horizon to a <emphasis>second-level "
"domain</emphasis>, for example <uri>https://example.com</uri>, and advise "
"against deploying horizon on a<emphasis> shared subdomain</emphasis> of any "
"level, for example <uri>https://openstack.example.org</uri> or "
"<uri>https://horizon.openstack.example.org</uri>. We also advise against "
"deploying to bare internal domains like <uri>https://horizon/</uri>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml32(para)
msgid ""
"This recommendation is based on the limitations browser same-origin-policy. "
"The recommendations in this guide cannot effectively protect users against "
"known attacks if dashboard is deployed on a domain which also hosts user-"
"generated content (e.g. scripts, images, uploads of any kind) even if the "
"user-generated content is on a different subdomain. This approach is used by"
" most major web presences (e.g. googleusercontent.com, fbcdn.com, github.io,"
" twimg.com) to ensure that user generated content stays separate from "
"cookies and security tokens."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml33(para)
msgid ""
"Additionally, if you decline to follow this recommendation above about "
"second-level domains, it is vital that you avoid the cookie backed session "
"store and employ HTTP Strict Transport Security (HSTS). When deployed on a "
"subdomain, dashboard's security is only as strong as the weakest application"
" deployed on the same second-level domain."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml36(title)
msgid "Static Media"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml37(para)
msgid ""
"Dashboard's static media should be deployed to a subdomain of the dashboard "
"domain and served by the web server. The use of an external content delivery"
" network (CDN) is also acceptable. This subdomain should not set cookies or "
"serve user-provided content. The media should also be served with HTTPS."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml38(para)
msgid ""
"Django media settings are documented at <link "
"href=\"https://docs.djangoproject.com/en/1.5/ref/settings/#static-"
"root\">https://docs.djangoproject.com/en/1.5/ref/settings/#static-"
"root</link>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml39(para)
msgid ""
"Dashboard's default configuration uses <link href=\"http://django-"
"compressor.readthedocs.org/\">django_compressor</link> to compress and "
"minify css and JavaScript content before serving it. This process should be "
"statically done before deploying dashboard, rather than using the default "
"in-request dynamic compression and copying the resulting files along with "
"deployed code or to the CDN server. Compression should be done in a non-"
"production build environment. If this is not practical, we recommend "
"disabling resource minification entirely. Online compression dependencies "
"(less, nodejs) should not be installed on production machines."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml42(title)
msgid "Secret Key"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml43(para)
msgid ""
"Dashboard depends on a shared SECRET_KEY setting for some security "
"functions. It should be a randomly generated string at least 64 characters "
"long. It must be shared across all active Horizon instances. Compromise of "
"this key may allow a remote attacker to execute arbitrary code. Rotating "
"this key invalidates existing user sessions and caching. Do not commit this "
"key to public repositories."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml46(title)
msgid "Session Backend"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml47(para)
msgid ""
"Horizon's default session backend "
"(<emphasis>django.contrib.sessions.backends.signed_cookies</emphasis>) "
"stores user data in <emphasis>signed</emphasis> but <emphasis>unencrypted "
"</emphasis>cookies stored in the browser. This approach allows the most "
"simple session backend scaling since each Horizon instance is stateless, but"
" it comes at the cost of <emphasis>storing sensitive access tokens in the "
"client browser</emphasis> and transmitting them with every request. This "
"backend ensures that session data has not been tampered with, but the data "
"itself is not encrypted other than the encryption provided by HTTPS."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml48(para)
msgid ""
"If your architecture allows it, we recommend using "
"<emphasis>django.contrib.sessions.backends.cache</emphasis> as your session "
"backend with memcache as the cache. Memcache must not be exposed publicly, "
"and should communicate over a secured private channel. If you choose to use "
"the signed cookies backend, refer to the Django documentation understand the"
" security tradeoffs."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml49(para)
msgid ""
"For further details, consult the <link "
"href=\"https://docs.djangoproject.com/en/1.5/topics/http/sessions"
"/#configuring-the-session-engine\">Django session backend "
"documentation</link>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml52(title)
msgid "Allowed Hosts"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml53(para)
msgid ""
"Configure the ALLOWED_HOSTS setting with the domain or domains where Horizon"
" is available. Failure to configure this setting (especially if not "
"following the recommendation above regarding second level domains) opens "
"Horizon to a number of serious attacks. Wildcard domains should be avoided."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml54(para)
msgid ""
"For further details, see the <link "
"href=\"https://docs.djangoproject.com/en/1.5/ref/settings/#allowed-"
"hosts\">Django documentation on settings</link>."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml57(title)
msgid "Cookies"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml58(para)
msgid "Session Cookies should be set to HTTPONLY:"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml61(para)
msgid ""
"Never configure CSRF or session cookies to have a wildcard domain with a "
"leading dot. Horizon's session and CSRF cookie should be secured when "
"deployed with HTTPS:"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml67(title)
msgid "Password Auto Complete"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml68(para)
msgid ""
"We recommend that implementers do not change the default password "
"autocomplete behavior. Users choose stronger passwords in environments that "
"allow them to use the secure browser password manager. Organizations which "
"forbid the browser password manager should enforce this policy at the "
"desktop level."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml71(title)
msgid "Cross Site Request Forgery (CSRF)"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml72(para)
msgid ""
"Django has a dedicated middleware for <link "
"href=\"https://docs.djangoproject.com/en/1.5/ref/contrib/csrf/#how-it-works"
"\">cross-site request forgery</link> (CSRF)."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml73(para)
msgid ""
"Dashboard is designed to discourage developers from introducing cross-site "
"scripting vulnerabilities with custom dashboards. However, it is important "
"to audit custom dashboards, especially ones that are javascript-heavy for "
"inappropriate use of the @csrf_exempt decorator. Dashboards which do not "
"follow these recommended security settings should be carefully evaluated "
"before restrictions are relaxed."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml76(title)
msgid "Cross Site Scripting (XSS)"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml77(para)
msgid ""
"Unlike many similar systems, OpenStack dashboard allows the entire unicode "
"character set in most fields. This means developers have less latitude to "
"make escaping mistakes that open attack vectors for cross-site scripting "
"(XSS)."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml78(para)
msgid ""
"Dashboard provides tools for developers to avoid creating XSS "
"vulnerabilities, but they only work if developers use them correctly. Audit "
"any custom dashboards, paying particular attention to use of the mark_safe "
"function, use of is_safe with custom template tags, the safe template tag, "
"anywhere autoescape is turned off, and any javascript which might evaluate "
"improperly escaped data."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml81(title)
msgid "Cross Origin Resource Sharing (CORS)"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml82(para)
msgid ""
"Configure your web server to send a restrictive CORS header with each "
"response, allowing only the Horizon domain and protocol:"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml85(para)
msgid "Never allow the wildcard origin."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml88(title)
msgid "Horizon Image Upload"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml89(para)
msgid ""
"We recommend that implementers <link "
"href=\"http://docs.openstack.org/developer/horizon/topics/deployment.html"
"#file-uploads\">disable HORIZON_IMAGES_ALLOW_UPLOAD</link> unless they have "
"implemented a plan to prevent resource exhaustion and denial of service."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml92(title)
msgid "Upgrading"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml93(para)
msgid ""
"Django security releases are generally well tested and aggressively "
"backwards compatible. In almost all cases, new major releases of Django are "
"also fully backwards compatible with previous releases. Dashboard "
"implementers are strongly encouraged to run the latest stable release of "
"Django with up-to-date security releases."
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml96(title)
msgid "Debug"
msgstr ""
#: ./doc/security-guide/ch025_web-dashboard.xml97(para)
msgid ""
"Make sure DEBUG is set to False in production. In Django, DEBUG displays "
"stack traces and sensitive web server state information on any exception."
msgstr ""
#: ./doc/security-guide/ch022_case-studies-api-endpoints.xml3(title)
msgid "Case Studies: API Endpoints"
msgstr ""
#: ./doc/security-guide/ch022_case-studies-api-endpoints.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address endpoint "
"configuration to secure their private and public clouds. Alice's cloud is "
"not publicly accessible, but she is still concerned about securing the "
"endpoints against improper use.  Bob's cloud, being public, must take "
"measures to reduce the risk of attacks by external adversaries."
msgstr ""
#: ./doc/security-guide/ch022_case-studies-api-endpoints.xml7(para)
msgid ""
"Alice's organization requires that the security architecture protect the "
"access to the public and private endpoints, so she elects to use the Apache "
"SSL proxy on both public and internal services. Alice's organization has "
"implemented its own certificate authority. Alice contacts the PKI office in "
"her agency that manages her PKI and certificate issuance. Alice obtains "
"certificates issued by this CA and configures the services within both the "
"public and management security domains to use these certificates. Since "
"Alice's OpenStack deployment exists entirely on a disconnected from the "
"Internet network, she makes sure to remove all default CA bundles that "
"contain external public CA providers to ensure the OpenStack services only "
"accept client certificates issued by her agency's CA. Alice has registered "
"all of the services in the Keystone Services Catalog, using the internal "
"URLs for access by internal services. She has installed host-based intrusion"
" detection on all of the API endpoints."
msgstr ""
#: ./doc/security-guide/ch022_case-studies-api-endpoints.xml11(para)
msgid ""
"Bob must also protect the access to the public and private endpoints, so he "
"elects to use the Apache SSL proxy on both public and internal services. On "
"the public services, he has configured the certificate key files with "
"certificates signed by a well-known Certificate Authority. He has used his "
"organization's self-signed CA to sign certificates in the internal services "
"on the Management network. Bob has registered his services in the Keystone "
"Services Catalog, using the internal URLs for access by internal services. "
"Bob's public cloud runs services on SELinux, which he has configured with a "
"mandatory access control policy to reduce the impact of any publicly "
"accessible services that may be compromised. He has also configured the "
"endpoints with a host-based IDS."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml3(title)
msgid "Data Privacy Concerns"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml4(para)
msgid ""
"OpenStack is designed to support multitenancy and those tenants will most "
"probably have different data requirements. As a cloud builder and operator "
"you need to ensure your OpenStack environment can address various data "
"privacy concerns and regulations. In this chapter we will address the "
"following topics around Data Privacy as it pertains to OpenStack "
"implementations:"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml6(para)
#: ./doc/security-guide/ch046_data-residency.xml13(title)
msgid "Data Residency"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml9(para)
#: ./doc/security-guide/ch046_data-residency.xml64(title)
msgid "Data Disposal"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml14(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml15(para)
msgid ""
"Numerous OpenStack services maintain data and metadata belonging to tenants "
"or reference tenant information."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml16(para)
msgid ""
"Tenant data stored in an OpenStack cloud may include the following items:"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml18(para)
msgid "Swift objects"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml21(para)
msgid "Compute instance ephemeral filesystem storage"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml24(para)
msgid "Compute instance memory"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml27(para)
#: ./doc/security-guide/ch046_data-residency.xml113(title)
msgid "Cinder volume data"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml30(para)
msgid "Public keys for Compute Access"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml33(para)
msgid "Virtual Machine Images in Glance"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml36(para)
msgid "Machine snapshots"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml39(para)
msgid "Data passed to OpenStack Compute's configuration-drive extension"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml42(para)
msgid ""
"Metadata stored by an OpenStack cloud includes the following non-exhaustive "
"items:"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml44(para)
msgid "Organization name"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml47(para)
msgid "User's \"Real Name\""
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml50(para)
msgid ""
"Number or size of running instances, buckets, objects, volumes, and other "
"quota-related items"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml53(para)
msgid "Number of hours running instances or storing data"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml56(para)
msgid "IP addresses of users"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml59(para)
msgid "Internally generated private keys for compute image bundling"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml65(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml67(para)
msgid ""
"\"Sanitization is the process used to remove information from system media "
"such that there is reasonable assurance that the information cannot be "
"retrieved or reconstructed. Sanitization techniques, including clearing, "
"purging, and destroying media information, prevent the disclosure of "
"organizational information to unauthorized individuals when such media is "
"reused or released for disposal.\" [NIST Special Publication 800-53 Revision"
" 3]"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml69(para)
msgid ""
"General data disposal and sanitization guidelines as adopted from NIST "
"recommended security controls. Cloud Operators should:"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml71(para)
msgid "Track, document and verify media sanitization and disposal actions."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml74(para)
msgid "Test sanitation equipment and procedures to verify proper performance."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml78(para)
msgid ""
"Sanitize portable, removable storage devices prior to connecting such "
"devices to the cloud infrastructure."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml81(para)
msgid "Destroy cloud system media that cannot be sanitized."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml84(para)
msgid "In an OpenStack deployment you will need to address the following:"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml86(para)
msgid "Secure data erasure"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml89(para)
#: ./doc/security-guide/ch046_data-residency.xml106(title)
msgid "Instance memory scrubbing"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml92(para)
msgid "Block Storage volume data"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml95(para)
#: ./doc/security-guide/ch046_data-residency.xml119(title)
msgid "Compute instance ephemeral storage"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml98(para)
#: ./doc/security-guide/ch046_data-residency.xml126(title)
msgid "Bare metal server sanitization"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml102(title)
msgid "Data not securely erased"
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml103(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml107(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml108(para)
msgid ""
"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 href=\"http://www.linux-"
"kvm.org/page/Memory\">KVM documentation</link>."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml109(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml110(para)
msgid ""
"For these and other hypervisors, we recommend referring to hypervisor-"
"specific documentation."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml114(para)
msgid ""
"Plugins to OpenStack Block Storage will store data in a variety of ways. "
"Many plugins 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 plugin to another, from one vendor's "
"solution to another, and from one filesystem to another."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml115(para)
msgid ""
"Some backends such as ZFS will support copy-on-write to prevent data "
"exposure. In these cases, reads from unwritten blocks will always return "
"zero. Other backends such as LVM may not natively support this, thus the "
"Cinder plugin takes the responsibility to override previously written blocks"
" before handing them to users. It is important to review what assurances "
"your chosen volume backend provides and to see what mediations may be "
"available for those assurances not provided."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml116(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml120(para)
msgid ""
"The creation and destruction of ephemeral storage will be somewhat dependent"
" on the chosen hypervisor and the OpenStack Compute plugin."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml121(para)
msgid ""
"The libvirt plugin 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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml122(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml123(para)
msgid ""
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml127(para)
msgid ""
"A bare metal server driver for Nova was under development and has since "
"moved into a separate project called <link "
"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."
msgstr ""
#: ./doc/security-guide/ch046_data-residency.xml128(para)
msgid ""
"Additionally, it is possible for tenants of a bare metal system to modify "
"system firmware. TPM technology, described in ##link:Management/Node "
"Bootstrapping##, provides a solution for detecting unauthorized firmware "
"changes."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml3(title)
msgid "Understanding the Audit Process"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml4(para)
msgid ""
"Information system security compliance is reliant on the completion of two "
"foundational processes:"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml6(para)
msgid ""
"<emphasis role=\"bold\">Implementation and Operation of Security "
"Controls</emphasis>Aligning the information system with in-scope standards "
"and regulations involves internal tasks which must be conducted before a "
"formal assessment. Auditors may be involved at this state to conduct gap "
"analysis, provide guidance, and increase the likelihood of successful "
"certification."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml9(para)
msgid ""
"<emphasis role=\"bold\">Independent Verification and "
"Validation</emphasis>Demonstration to a neutral third-party that system "
"security controls are implemented and operating effectively, in compliance "
"with in-scope standards and regulations, is required before many information"
" systems achieve certified status. Many certifications require periodic "
"audits to ensure continued certification, considered part of an overarching "
"continuous monitoring practice.  "
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml13(title)
msgid "Determining Audit Scope"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml14(para)
msgid ""
"Determining audit scope, specifically what controls are needed and how to "
"design or modify an OpenStack deployment to satisfy them, should be the "
"initial planning step."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml15(para)
msgid ""
"When scoping OpenStack deployments for compliance purposes, consider "
"prioritizing controls around sensitive services, such as command and control"
" functions and the base virtualization technology. Compromises of these "
"facilities may impact an OpenStack environment in its entirety."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml16(para)
msgid ""
"Scope reduction helps ensure OpenStack architects establish high quality "
"security controls which are tailored to a particular deployment, however it "
"is paramount to ensure these practices do not omit areas or features from "
"security hardening. A common example is applicable to PCI-DSS guidelines, "
"where payment related infrastructure may be scrutinized for security issues,"
" but supporting services are left ignored, and vulnerable to attack."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml17(para)
msgid ""
"When addressing compliance, you can increase efficiency and reduce work "
"effort by identifying common areas and criteria that apply across multiple "
"certifications. Much of the audit principles and guidelines discussed in "
"this book will assist in identifying these controls, additionally a number "
"of external entities provide comprehensive lists. The following are some "
"examples:"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml18(para)
msgid ""
"The <link href=\"https://cloudsecurityalliance.org/research/ccm/\">Cloud "
"Security Alliance Cloud Controls Matrix</link> (CCM) assists both cloud "
"providers and consumers in assessing the overall security of a cloud "
"provider. The CSA CMM provides a controls framework that map to many "
"industry-accepted standards and regulations including the ISO 27001/2, "
"ISACA, COBIT, PCI, NIST, Jericho Forum and NERC CIP."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml19(para)
msgid ""
"The <link href=\"https://fedorahosted.org/scap-security-guide/\">SCAP "
"Security Guide</link> is another useful reference. This is still an emerging"
" source, but we anticipate that this will grow into a tool with controls "
"mappings that are more focused on the US federal government certifications "
"and recommendations. For example, the SCAP Security Guide currently has some"
" mappings for security technical implementation guides (STIGs) and "
"NIST-800-53."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml20(para)
msgid ""
"These control mappings will help identify common control criteria across "
"certifications, and provide visibility to both auditors and auditees on "
"problem areas within control sets for particular compliance certifications "
"and attestations."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml23(title)
msgid "Internal Audit"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml24(para)
msgid ""
"Once a cloud is deployed, it is time for an internal audit. This is the time"
" compare the controls you identified above with the design, features, and "
"deployment strategies utilized in your cloud. The goal is to understand how "
"each control is handled and where gaps exist. Document all of the findings "
"for future reference."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml25(para)
msgid ""
"When auditing an OpenStack cloud it is important to appreciate the multi-"
"tenant environment inherent in the OpenStack architecture. Some critical "
"areas for concern include data disposal, hypervisor security, node "
"hardening, and authentication mechanisms."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml28(title)
msgid "Prepare for External Audit"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml29(para)
msgid ""
"Once the internal audit results look good, it is time to prepare for an "
"external audit. There are several key actions to take at this stage, these "
"are outlined below:"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml31(para)
msgid ""
"Maintain good records from your internal audit. These will prove useful "
"during the external audit so you can be prepared to answer questions about "
"mapping the compliance controls to a particular deployment."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml34(para)
msgid ""
"Deploy automated testing tools to ensure that the cloud remains compliant "
"over time."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml37(para)
msgid "Select an auditor."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml40(para)
msgid ""
"Selecting an auditor can be challenging. Ideally, you are looking for "
"someone with experience in cloud compliance audits. OpenStack experience is "
"another big plus. Often it is best to consult with people who have been "
"through this process for referrals. Cost can vary greatly depending on the "
"scope of the engagement and the audit firm considered."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml43(title)
msgid "External Audit"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml44(para)
msgid ""
"This is the formal audit process. Auditors will test security controls in "
"scope for a specific certification, and demand evidentiary requirements to "
"prove that these controls were also in place for the audit window (for "
"example SOC 2 audits generally evaluate security controls over a 6-12 months"
" period).  Any control failures are logged, and will be documented in the "
"external auditors final report.  Dependent on the type of OpenStack "
"deployment, these reports may be viewed by customers, so it is important to "
"avoid control failures. This is why audit preparation is so important."
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml47(title)
msgid "Compliance Maintenance"
msgstr ""
#: ./doc/security-guide/ch062_audit-guidance.xml48(para)
msgid ""
"The process doesn't end with a single external audit. Most certifications "
"require continual compliance activities which means repeating the audit "
"process periodically.  We recommend integrating automated compliance "
"verification tools into a cloud to ensure that it is compliant at all times."
" This should be in done in addition to other security monitoring tools. "
"Remember that the goal is both security <emphasis>and</emphasis> compliance."
" Failing on either of these fronts will significantly complicate future "
"audits."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch042_database-overview.xml13(None)
#: ./doc/security-guide/ch042_database-overview.xml16(None)
msgid ""
"@@image: 'static/databaseusername.png'; md5=a6a5dadedbc1517069ca388c7ac5940a"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch042_database-overview.xml37(None)
#: ./doc/security-guide/ch042_database-overview.xml40(None)
msgid ""
"@@image: 'static/databaseusernamessl.png'; "
"md5=9c43242c47eb159b6f61ac41f3d8bced"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch042_database-overview.xml101(None)
#: ./doc/security-guide/ch042_database-overview.xml104(None)
msgid ""
"@@image: 'static/novaconductor.png'; md5=dbc1ba139bd1af333f0415bb48704843"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml3(title)
msgid "Database Access Control"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml4(para)
msgid ""
"Each of the core OpenStack services (Compute, Identity, Networking, Block "
"Storage) store state and configuration information in databases. In this "
"chapter, we discuss how databases are used currently in OpenStack. We also "
"explore security concerns, and the security ramifications of database "
"backend choices."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml6(title)
msgid "OpenStack Database Access Model"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml7(para)
msgid ""
"All of the services within an OpenStack project access a single database. "
"There are presently no reference policies for creating table or row based "
"access restrictions to the database."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml8(para)
msgid ""
"There are no general provisions for granular control of database operations "
"in OpenStack. Access and privileges are granted simply based on whether a "
"node has access to the database or not.  In this scenario, nodes with access"
" to the database may have full privileges to DROP, INSERT, or UPDATE "
"functions."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml10(title)
msgid "Granular Access Control"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml11(para)
msgid ""
"By default, each of the OpenStack services and their processes access the "
"database using a shared set of credentials. This makes auditing database "
"operations and revoking access privileges from a service and its processes "
"to the database particularly difficult."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml21(title)
#: ./doc/security-guide/ch042_database-overview.xml96(title)
msgid "Nova Conductor"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml22(para)
msgid ""
"The compute nodes are the least trusted of the services in OpenStack because"
" they host tenant instances. The <systemitem class=\"service\">nova-"
"conductor</systemitem> service has been introduced to serve as a database "
"proxy, acting as an intermediary between the compute nodes and the database."
" We discuss its ramifications later in this chapter."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml23(para)
msgid "We strongly recommend:"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml25(para)
msgid "All database communications be isolated to a management network"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml28(para)
msgid "Securing communications using SSL"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml31(para)
msgid ""
"Creating unique database user accounts per OpenStack service endpoint "
"(illustrated below)"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml47(title)
msgid "Database Authentication and Access Control"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml48(para)
msgid ""
"Given the risks around access to the database, we strongly recommend that "
"unique database user accounts be created per node needing access to the "
"database. Doing this facilitates better analysis and auditing for ensuring "
"compliance or in the event of a compromise of a node allows you to isolate "
"the compromised host by removing access for that node to the database upon "
"detection. When creating these per service endpoint database user accounts, "
"care should be taken to ensure that they are configured to require SSL.  "
"Alternatively, for increased security it is recommended that the database "
"accounts be configured using X.509 certificate authentication in addition to"
" usernames and passwords."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml50(title)
msgid "Privileges"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml51(para)
msgid ""
"A separate database administrator (DBA) account should be created and "
"protected that has full privileges to create/drop databases, create user "
"accounts, and update user privileges. This simple means of separation of "
"responsibility helps prevent accidental misconfiguration, lowers risk and "
"lowers scope of compromise."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml52(para)
msgid ""
"The database user accounts created for the OpenStack services and for each "
"node should have privileges limited to just the database relevant to the "
"service where the node is a member."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml56(title)
msgid "Require User Accounts to Require SSL Transport"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml58(title)
#: ./doc/security-guide/ch042_database-overview.xml75(title)
msgid "Configuration Example #1: (MySQL)"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml63(title)
#: ./doc/security-guide/ch042_database-overview.xml82(title)
msgid "Configuration Example #2: (PostgreSQL)"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml64(para)
msgid "In file pg_hba.conf:"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml67(para)
msgid ""
"Note this command only adds the ability to communicate over SSL and is non-"
"exclusive. Other access methods that may allow unencrypted transport should "
"be disabled so that SSL is the sole access method."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml68(para)
msgid ""
"The 'md5' parameter defines the authentication method as a hashed password. "
"We provide a secure authentication example in the section below."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml72(title)
msgid "Authentication with X.509 Certificates"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml73(para)
msgid ""
"Security may be enhanced by requiring X.509 client certificates for "
"authentication.  Authenticating to the database in this manner provides "
"greater identity assurance of the client making the connection to the "
"database and ensures that the communications are encrypted."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml88(title)
msgid "OpenStack Service Database Configuration"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml89(para)
msgid ""
"If your database server is configured to require X.509 certificates for "
"authentication you will need to specify the appropriate SQLAlchemy query "
"parameters for the database backend. These parameters specify the "
"certificate, private key, and certificate authority information for use with"
" the initial connection string."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml90(para)
msgid ""
"Example of an <literal>:sql_connection</literal> string for X.509 "
"certificate authentication to MySQL:"
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml97(para)
msgid ""
"OpenStack Compute offers a sub-service called <systemitem class=\"service"
"\">nova-conductor</systemitem> which proxies database connections, with the "
"primary purpose of having the nova compute nodes interfacing with "
"<systemitem class=\"service\">nova-conductor</systemitem> to meet data "
"persistence needs as opposed to directly communicating with the database."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml98(para)
msgid ""
"Nova-conductor receives requests over RPC and performs actions on behalf of "
"the calling service without granting granular access to the database, its "
"tables, or data within. Nova-conductor essentially abstracts direct database"
" access away from compute nodes."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml99(para)
msgid ""
"This abstraction offers the advantage of restricting services to executing "
"methods with parameters, similar to stored procedures, preventing a large "
"number of systems from directly accessing or modifying database data. This "
"is accomplished without having these procedures stored or executed within "
"the context or scope of the database itself, a frequent criticism of typical"
" stored procedures."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml107(para)
msgid ""
"Unfortunately, this solution complicates the task of more fine-grained "
"access control and the ability to audit data access. Because the <systemitem"
" class=\"service\">nova-conductor</systemitem> service receives requests "
"over RPC, it highlights the importance of improving the security of "
"messaging. Any node with access to the message queue may execute these "
"methods provided by the <systemitem class=\"service\">nova-"
"conductor</systemitem> and effectively modifying the database."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml108(para)
msgid ""
"Finally, it should be noted that as of the Grizzly release, gaps exist where"
" <systemitem class=\"service\">nova-conductor</systemitem> is not used "
"throughout OpenStack Compute. Depending on one's configuration, the use of "
"<systemitem class=\"service\">nova-conductor</systemitem> may not allow "
"deployers to avoid the necessity of providing database GRANTs to individual "
"compute host systems."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml109(para)
msgid ""
"Note, as <systemitem class=\"service\">nova-conductor</systemitem> only "
"applies to OpenStack Compute, direct database access from compute hosts may "
"still be necessary for the operation of other OpenStack components such as "
"Telemetry (Ceilometer), Networking, and Block Storage."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml110(para)
msgid ""
"Implementors should weigh the benefits and risks of both configurations "
"before enabling or disabling the <systemitem class=\"service\">nova-"
"conductor</systemitem> service. We are not yet prepared to recommend the use"
" of <systemitem class=\"service\">nova-conductor</systemitem> in the Grizzly"
" release. However, we do believe that this recommendation will change as "
"additional features are added into OpenStack."
msgstr ""
#: ./doc/security-guide/ch042_database-overview.xml111(para)
msgid ""
"To disable the <systemitem class=\"service\">nova-conductor</systemitem>, "
"place the following into your <filename>nova.conf</filename> file (on your "
"compute hosts):"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml3(title)
msgid "Identity"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml4(para)
msgid ""
"The OpenStack Identity Service (Keystone) supports multiple methods of "
"authentication, including username &amp; password, LDAP, and external "
"authentication methods.  Upon successful authentication, The Identity "
"Service provides the user with an authorization token used for subsequent "
"service requests."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml5(para)
msgid ""
"Transport Layer Security TLS/SSL provides authentication between services "
"and persons using X.509 certificates.  Although the default mode for SSL is "
"server-side only authentication, certificates may also be used for client "
"authentication."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml7(title)
msgid "Authentication"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml9(title)
msgid "Invalid Login Attempts"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml10(para)
msgid ""
"The Identity Service does not provide a method to limit access to accounts "
"after repeated unsuccessful login attempts. Repeated failed login attempts "
"are likely brute-force attacks (Refer figure Attack-types). This is a more "
"significant issue in Public clouds."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml11(para)
msgid ""
"Prevention is possible by using an external authentication system that "
"blocks out an account after some configured number of failed login attempts."
" The account then may only be unlocked with further side-channel "
"intervention."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml12(para)
msgid ""
"If prevention is not an option, detection can be used to mitigate "
"damage.Detection involves frequent review of access control logs to identify"
" unauthorized attempts to access accounts. Possible remediation would "
"include reviewing the strength of the user password, or blocking the network"
" source of the attack via firewall rules. Firewall rules on the keystone "
"server that restrict the number of connections could be used to reduce the "
"attack effectiveness, and thus dissuade the attacker."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml13(para)
msgid ""
"In addition, it is useful to examine account activity for unusual login "
"times and suspicious actions, with possibly disable the account. Often times"
" this approach is taken by credit card providers for fraud detection and "
"alert."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml16(title)
msgid "Multi-factor Authentication"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml17(para)
msgid ""
"Employ multi-factor authentication for network access to privileged user "
"accounts. The Identity Service supports external authentication services "
"through the Apache web server that can provide this functionality. Servers "
"may also enforce client-side authentication using certificates."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml18(para)
msgid ""
"This recommendation provides insulation from brute force, social "
"engineering, and both spear and mass phishing attacks that may compromise "
"administrator passwords."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml22(title)
msgid "Authentication Methods"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml24(title)
msgid "Internally Implemented Authentication Methods"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml25(para)
msgid ""
"The Identity Service can store user credentials in an SQL Database, or may "
"use an LDAP-compliant directory server. The Identity database may be "
"separate from databases used by other OpenStack services to reduce the risk "
"of a compromise of the stored credentials."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml26(para)
msgid ""
"When authentication is provided via username and password, the Identity "
"Service does not enforce policies on password strength, expiration, or "
"failed authentication attempts as recommended by NIST Special Publication "
"800-118 (draft). Organizations that desire to enforce stronger password "
"policies should consider using Keystone Identity Service Extensions or "
"external authentication services."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml27(para)
msgid ""
"LDAP simplifies integration of Identity authentication into an "
"organization's existing directory service and user account management "
"processes."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml28(para)
msgid ""
"Authentication and authorization policy in OpenStack may be delegated to an "
"external LDAP server. A typical use case is an organization that seeks to "
"deploy a private cloud and already has a database of employees, the users. "
"This may be in an LDAP system. Using LDAP as a source of authority "
"authentication, requests to Identity Service are delegated to the LDAP "
"service, which will authorize or deny requests based on locally set "
"policies. A token is generated on successful authentication."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml29(para)
msgid ""
"Note that if the LDAP system has attributes defined for the user such as "
"admin, finance, HR etc, these must be mapped into roles and groups within "
"Identity for use by the various OpenStack services. The "
"<emphasis>etc/keystone.conf</emphasis> file provides the mapping from the "
"LDAP attributes to Identity attributes."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml30(para)
msgid ""
"The Identity Service <emphasis role=\"bold\">MUST NOT</emphasis> be allowed "
"to write to LDAP services used for authentication outside of the OpenStack "
"deployment as this would allow a sufficiently privileged keystone user to "
"make changes to the LDAP directory. This would allow privilege escalation "
"within the wider organization or facilitate unauthorized access to other "
"information and resources. In such a deployment, user provisioning would be "
"out of the realm of the OpenStack deployment."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml32(para)
msgid ""
"There is an <link "
"href=\"https://bugs.launchpad.net/ossn/+bug/1168252\">OpenStack Security "
"Note (OSSN) regarding keystone.conf permissions</link>."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml33(para)
msgid ""
"There is an <link "
"href=\"https://bugs.launchpad.net/ossn/+bug/1155566\">OpenStack Security "
"Note (OSSN) regarding potential DoS attacks</link>."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml37(title)
msgid "External Authentication Methods"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml38(para)
msgid ""
"Organizations may desire to implement external authentication for "
"compatibility with existing authentication services or to enforce stronger "
"authentication policy requirements. Although passwords are the most common "
"form of authentication, they can be compromised through numerous methods, "
"including keystroke logging and password compromise. External authentication"
" services can provide alternative forms of authentication that minimize the "
"risk from weak passwords."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml39(para)
msgid "These include:"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml41(para)
msgid ""
"Password Policy Enforcement: Requires user passwords to conform to minimum "
"standards for length, diversity of characters, expiration, or failed login "
"attempts."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml44(para)
msgid ""
"Multi-factor authentication: The authentication service requires the user to"
" provide information based on something they have (e.g., a one-time password"
" token or X.509 certificate) and something they know (e.g., a password)."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml47(para)
msgid "Kerberos"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml53(title)
msgid "Authorization"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml54(para)
msgid ""
"The Identity Service supports the notion of groups and roles. Users belong "
"to groups. A group has a list of roles. OpenStack services reference the "
"roles of the user attempting to access the service. The OpenStack policy "
"enforcer middleware takes into consideration the policy rule associated with"
" each resource and the user's group/roles and tenant association to "
"determine if he/she has access to the requested resource."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml55(para)
msgid ""
"The Policy enforcement middleware enables fine-grained access control to "
"OpenStack resources. Only admin users can provision new users and have "
"access to various management functionality. The cloud tenant would be able "
"to only spin up instances, attach volumes, etc."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml57(title)
msgid "Establish Formal Access Control Policies"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml58(para)
msgid ""
"Prior to configuring roles, groups, and users, document your required access"
" control policies for the OpenStack installation. The policies should be "
"consistent with any regulatory or legal requirements for the organization. "
"Future modifications to access control configuration should be done "
"consistently with the formal policies. The policies should include the "
"conditions and processes for creating, deleting, disabling, and enabling "
"accounts, and for assigning privileges to the accounts. Periodically review "
"the policies and ensure that configuration is in compliance with approved "
"policies."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml61(title)
msgid "Service Authorization"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml62(para)
msgid ""
"As described in the <link href=\"http://docs.openstack.org/admin-guide-"
"cloud/content/index.html\"><citetitle>OpenStack Cloud Administrator "
"Guide</citetitle></link>, cloud administrators must define a user for each "
"service, with a role of Admin. This service user account provides the "
"service with the authorization to authenticate users."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml63(para)
msgid ""
"The Compute and Object Storage services can be configured to use either the "
"\"tempAuth\" file or Identity Service to store authentication information. "
"The \"tempAuth\" solution MUST NOT be deployed in a production environment "
"since it stores passwords in plain text."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml64(para)
msgid ""
"The Identity Service supports client authentication for SSL which may be "
"enabled. SSL client authentication provides an additional authentication "
"factor, in addition to the username / password, that provides greater "
"reliability on user identification. It reduces the risk of unauthorized "
"access when usernames and passwords may be compromised.  However, there is "
"additional administrative overhead and cost to issue certificates to users "
"that may not be feasible in every deployment."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml66(para)
msgid ""
"We recommend that you use client authentication with SSL for the "
"authentication of services to the Identity Service."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml68(para)
msgid ""
"The cloud administrator should protect sensitive configuration files for "
"unauthorized modification. This can be achieved with mandatory access "
"control frameworks such as SELinux, including "
"<literal>/etc/keystone.conf</literal> and X.509 certificates."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml70(para)
msgid ""
"For client authentication with SSL, you need to issue certificates. These "
"certificates can be signed by an external authority or by the cloud "
"administrator. OpenStack services by default check the signatures of "
"certificates and connections fail if the signature cannot be checked. If the"
" administrator uses self-signed certificates, the check might need to be "
"disabled. To disable these certificates, set <code>insecure=False</code> in "
"the <code>[filter:authtoken]</code> section in the "
"<filename>/etc/nova/api.paste.ini</filename> file. This setting also "
"disables certificates for other components."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml84(title)
msgid "Administrative Users"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml85(para)
msgid ""
"We recommend that admin users authenticate using Identity Service and an "
"external authentication service that supports 2-factor authentication, such "
"as a certificate.  This reduces the risk from passwords that may be "
"compromised. This recommendation is in compliance with NIST 800-53 IA-2(1) "
"guidance in the use of multifactor authentication for network access to "
"privileged accounts."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml88(title)
msgid "End Users"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml89(para)
msgid ""
"The Identity Service can directly provide end-user authentication, or can be"
" configured to use external authentication methods to conform to an "
"organization's security policies and requirements."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml93(title)
msgid "Policies"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml94(para)
msgid ""
"Each OpenStack service has a policy file in json format, called <emphasis "
"role=\"bold\">policy.json</emphasis>. The policy file specifies rules, and "
"the rule that governs each resource. A resource could be API access, the "
"ability to attach to a volume, or to fire up instances."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml95(para)
msgid ""
"The policies can be updated by the cloud administrator to further control "
"access to the various resources. The middleware could also be further "
"customized. Note that your users must be assigned to groups/roles that you "
"refer to in your policies."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml96(para)
msgid "Below is a snippet of the Block Storage service policy.json file."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml115(para)
msgid ""
"Note the <emphasis role=\"bold\">default</emphasis> rule specifies that the "
"user must be either an admin or the owner of the volume. It essentially says"
" only the owner of a volume or the admin may create/delete/update volumes. "
"Certain other operations such as managing volume types are accessible only "
"to admin users."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml118(title)
msgid "Tokens"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml119(para)
msgid ""
"Once a user is authenticated, a token is generated and used internally in "
"OpenStack for authorization and access. The default token <emphasis "
"role=\"bold\">lifespan</emphasis> is<emphasis role=\"bold\"> 24 "
"hours</emphasis>. It is recommended that this value be set lower but caution"
" needs to be taken as some internal services will need sufficient time to "
"complete their work. The cloud may not provide services if tokens expire too"
" early. An example of this would be the time needed by the Compute Service "
"to transfer a disk image onto the hypervisor for local caching."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml120(para)
msgid ""
"Below is an example of a PKI token. Note that, in practice, the token id "
"value is very long (e.g., around 3500 bytes), but for brevity we shorten it "
"in this example."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml133(para)
msgid ""
"Note that the token is often passed within the structure of a larger context"
" of a Identity Service response. These responses also provide a catalog of "
"the various OpenStack services. Each service is listed with its name, access"
" endpoints for internal, admin, and public access."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml134(para)
msgid ""
"The Identity Service supports token revocation. This manifests as an API to "
"revoke a token, to list revoked tokens and individual OpenStack services "
"that cache tokens to query for the revoked tokens and remove them from their"
" cache and append the same to their list of cached revoked tokens."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml137(title)
msgid "Future"
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml138(para)
msgid ""
"Domains are high-level containers for projects, users and groups. As such, "
"they can be used to centrally manage all Keystone-based identity components."
" With the introduction of account Domains, server, storage and other "
"resources can now be logically grouped into multiple Projects (previously "
"called Tenants) which can themselves be grouped under a master account-like "
"container. In addition, multiple users can be managed within an account "
"Domain and assigned roles that vary for each Project."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml139(para)
msgid ""
"Keystone's V3 API supports multiple domains. Users of different domains may "
"be represented in different authentication backends and even have different "
"attributes that must be mapped to a single set of roles and privileges, that"
" are used in the policy definitions to access the various service resources."
msgstr ""
#: ./doc/security-guide/ch024_authentication.xml140(para)
msgid ""
"Where a rule may specify access to only admin users and users belonging to "
"the tenant, the mapping may be trivial. In other scenarios the cloud "
"administrator may need to approve the mapping routines per tenant."
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml9(title)
msgid "Case Studies: Management Interfaces"
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml10(para)
msgid ""
"Previously we discussed typical OpenStack management interfaces and "
"associated backplane issues. We will now approach these issues by returning "
"to our Alice and Bob case study. Specifically, we will look into how both "
"Alice and Bob will address:"
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml16(para)
msgid "Cloud Administration"
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml19(para)
msgid "Self Service"
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml22(para)
msgid "Data Replication &amp; Recovery"
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml25(para)
msgid "SLA &amp; Security Monitoring."
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml30(para)
msgid ""
"When building her private cloud, while air-gapped, Alice still needs to "
"consider her service management interfaces. Before deploying her private "
"cloud, Alice has completed her system documentation. Specifically she has "
"identified which OpenStack services will exist in each security domain. From"
" there Alice has further restricted access to management interfaces by "
"deploying a combination of IDS, SSL encryption, and physical network "
"isolation. Additionally, Alice requires high availability and redundant "
"services. Thus, Alice sets up redundant infrastructure for various OpenStack"
" API services."
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml31(para)
msgid ""
"Alice also needs to provide assurances that the physical servers and "
"hypervisors have been built from a known secure state into a well-defined "
"configuration. To enable this, Alice uses a combination of a Configuration "
"Management platform to configure each machine according to the standards and"
" regulations she must comply with. It will also enable Alice to report "
"periodically on the state of her cloud and perform remediation to a known "
"state should anything be out of the ordinary. Additionally, Alice provides "
"hardware assurances by using a PXE system to build her nodes from a known "
"set of base images. During the boot process, Alice provides further "
"assurances by enabling Intel TXT and related trusted boot technologies "
"provided by the hardware."
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml35(para)
msgid ""
"As a public cloud provider, Bob is concerned with both the continuous "
"availability of management interfaces and the security of transactions to "
"the management interfaces. To that end Bob implements multiple redundant "
"OpenStack API endpoints for the services his cloud will run. Additionally on"
" the public network Bob uses SSL to encrypt all transactions between his "
"customers and his cloud interfaces. To isolate his cloud operations Bob has "
"physically isolated his management, instance migration, and storage "
"networks."
msgstr ""
#: ./doc/security-guide/ch015_case-studies-management.xml36(para)
msgid ""
"To ease scaling and reduce management overhead Bob implements a "
"configuration management system. For customer data assurances, Bob offers a "
"backup as a service product as requirements will vary between customers. "
"Finally, Bob does not provide a \"baremetal\" or the ability to schedule an "
"entire node, so to reduce management overhead and increase operational "
"efficiency Bob does not implement any node boot time security."
msgstr ""
#: ./doc/security-guide/ch018_case-studies-pkissl.xml3(title)
msgid "Case Studies: PKI and Certificate Management"
msgstr ""
#: ./doc/security-guide/ch018_case-studies-pkissl.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address deployment of "
"PKI certification authorities (CA) and certificate management."
msgstr ""
#: ./doc/security-guide/ch018_case-studies-pkissl.xml7(para)
msgid ""
"Alice as a cloud architect within a government agency knows that her agency "
"operates its own certification authority. Alice contacts the PKI office in "
"her agency that manages her PKI and certificate issuance. Alice obtains "
"certificates issued by this CA and configures the services within both the "
"public and management security domains to use these certificates. Since "
"Alice's OpenStack deployment exists entirely on a disconnected from the "
"Internet network, she makes sure to remove all default CA bundles that "
"contain external public CA providers to ensure the OpenStack services only "
"accept client certificates issued by her agency's CA."
msgstr ""
#: ./doc/security-guide/ch018_case-studies-pkissl.xml11(para)
msgid ""
"Bob is architecting a public cloud and needs to ensure that the publicly "
"facing OpenStack services are using certificates issued by a major public "
"CA. Bob acquires certificates for his public OpenStack services and "
"configures the services to use PKI and SSL and includes the public CAs in "
"his trust bundle for the services. Additionally, Bob also wants to further "
"isolate the internal communications amongst the services within the "
"management security domain. Bob contacts the team within his organization "
"that is responsible for managing his organizations PKI and issuance of "
"certificates using their own internal CA. Bob obtains certificates issued by"
" this internal CA and configures the services that communicate within the "
"management security domain to use these certificates and configures the "
"services to only accept client certificates issued by his internal CA."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch031_neutron-architecture.xml24(None)
#: ./doc/security-guide/ch031_neutron-architecture.xml27(None)
msgid ""
"@@image: 'static/sdn-connections.png'; md5=3fb0f3e2bea0784fea8832526d2b2832"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch031_neutron-architecture.xml36(None)
#: ./doc/security-guide/ch031_neutron-architecture.xml39(None)
msgid ""
"@@image: 'static/1aa-network-domains-diagram.png'; "
"md5=57ae4448b05a3852180f75f3995711b9"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml3(title)
msgid "Networking Architecture"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml4(para)
msgid ""
"OpenStack Networking is a standalone service that often involves deploying "
"several processes across a number of nodes. These processes interact with "
"each other and with other OpenStack services. The main process of the "
"OpenStack Networking service is neutron-server, a Python daemon that exposes"
" the OpenStack Networking API and passes tenant requests to a suite of "
"plugins for additional processing."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml5(para)
msgid "OpenStack Networking components encompasses the following elements:"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml7(para)
msgid ""
"<emphasis role=\"bold\">neutron server</emphasis> (<literal>neutron-"
"server</literal> and <literal>neutron-*-plugin</literal>): This service runs"
" on the network node to service the Networking API and its extensions. It "
"also enforces the network model and IP addressing of each port. The neutron-"
"server and plugin agents require access to a database for persistent storage"
" and access to a message queue for inter-communication."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml10(para)
msgid ""
"<emphasis role=\"bold\">plugin agent</emphasis> "
"(<literal>neutron-*-agent</literal>): Runs on each compute node to manage "
"local virtual switch (vswitch) configuration. The agents to be run will "
"depend on which plugin you are using. This service requires message queue "
"access. <emphasis>Optional depending on plugin.</emphasis>"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml13(para)
msgid ""
"<emphasis role=\"bold\">DHCP agent</emphasis> (<literal>neutron-dhcp-"
"agent</literal>): Provides DHCP services to tenant networks. This agent is "
"the same across all plugins and is responsible for maintaining DHCP "
"configuration. The neutron-dhcp-agent requires message queue access."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml16(para)
msgid ""
"<emphasis role=\"bold\">l3 agent</emphasis> "
"(<literal>neutron-l3-agent</literal>): Provides L3/NAT forwarding for "
"external network access of VMs on tenant networks. Requires message queue "
"access. <emphasis>Optional depending on plugin.</emphasis>"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml19(para)
msgid ""
"<emphasis role=\"bold\">network provider services</emphasis> (SDN "
"server/services). Provide additional networking services that are provided "
"to tenant networks. These SDN services may interact with the neutron-server,"
" neutron-plugin, and/or plugin-agents via REST APIs or other communication "
"channels."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml22(para)
msgid ""
"The figure that follows provides an architectural and networking flow "
"diagram of the OpenStack Networking components:"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml31(title)
msgid "OS Networking Service placement on Physical Servers"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml32(para)
msgid ""
"In this guide, we focus primarily on a standard architecture that includes a"
" <emphasis>cloud controller</emphasis> host, a <emphasis>network</emphasis> "
"host, and a set of <emphasis>compute</emphasis> hypervisors for running VMs."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml34(title)
msgid "Network Connectivity of Physical Servers"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml42(para)
msgid ""
"A standard OpenStack Networking setup has up to four distinct physical data "
"center networks:"
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml44(para)
msgid ""
"<emphasis role=\"bold\">Management network</emphasis> Used for internal "
"communication between OpenStack Components. The IP addresses on this network"
" should be reachable only within the data center and is considered the "
"Management Security Domain."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml47(para)
msgid ""
"<emphasis role=\"bold\">Guest network</emphasis> Used for VM data "
"communication within the cloud deployment. The IP addressing requirements of"
" this network depend on the OpenStack Networking plugin in use and the "
"network configuration choices of the virtual networks made by the tenant. "
"This network is considered the Guest Security Domain."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml50(para)
msgid ""
"<emphasis role=\"bold\">External network</emphasis> Used to provide VMs with"
" Internet access in some deployment scenarios. The IP addresses on this "
"network should be reachable by anyone on the Internet and is considered to "
"be in the Public Security Domain."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml53(para)
msgid ""
"<emphasis role=\"bold\">API network</emphasis> Exposes all OpenStack APIs, "
"including the OpenStack Networking API, to tenants. The IP addresses on this"
" network should be reachable by anyone on the Internet. This may be the same"
" network as the external network, as it is possible to create a subnet for "
"the external network that uses IP allocation ranges to use only less than "
"the full range of IP addresses in an IP block. This network is considered "
"the Public Security Domain."
msgstr ""
#: ./doc/security-guide/ch031_neutron-architecture.xml56(para)
msgid ""
"For additional information see the <link href=\"http://docs.openstack.org"
"/admin-guide-cloud/content/ch_networking.html\">Networking chapter</link> in"
" the <citetitle>OpenStack Cloud Administrator Guide</citetitle>."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml3(title)
msgid "Data Encryption"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml4(para)
msgid ""
"The option exists for implementors to encrypt tenant data wherever it is "
"stored on disk or transported over a network. This is above and beyond the "
"general recommendation that users encrypt their own data before sending it "
"to their provider."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml5(para)
msgid ""
"The importance of encrypting data on behalf of tenants is largely related to"
" the risk assumed by a provider that an attacker could access tenant data. "
"There may be requirements here in government, as well as requirements per-"
"policy, in private contract, or even in case law in regard to private "
"contracts for public cloud providers. It is recommended that a risk "
"assessment and legal consul advised before choosing tenant encryption "
"policies."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml6(para)
msgid ""
"Per-instance or per-object encryption is preferable over, in descending "
"order, over per-project, per-tenant, per-host, and per-cloud aggregations. "
"This recommendation is inverse to the complexity and difficulty of "
"implementation. Presently, in some projects it is difficult or impossible to"
" implement encryption as loosely granular as even per-tenant. We recommend "
"implementors make a best-effort in encrypting tenant data."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml7(para)
msgid ""
"Often, data encryption relates positively to the ability to reliably destroy"
" tenant and per-instance data, simply by throwing away the keys. It should "
"be noted that in doing so, it becomes of great importance to destroy those "
"keys in a reliable and secure manner."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml8(para)
msgid "Opportunities to encrypt data for users are present:"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml10(para)
msgid "Object Storage objects"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml13(para)
msgid "Block Storage volumes &amp; Instance Ephemeral Filesystems"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml16(para)
msgid "Network data"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml20(title)
msgid "Object Storage Objects"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml21(para)
msgid ""
"The ability to encrypt objects in Object Stoarge is presently limited to "
"disk-level encryption per node. However, there does exist third-party "
"extensions and modules for per-object encryption. These modules have been "
"proposed upstream, but have not per this writing been formally accepted. "
"Below are some pointers: "
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml22(link)
msgid "https://github.com/Mirantis/swift-encrypt"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml23(link)
msgid ""
"http://www.mirantis.com/blog/on-disk-encryption-prototype-for-openstack-"
"swift/"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml26(title)
msgid "Block Storage Volumes &amp; Instance Ephemeral Filesystems"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml27(para)
msgid ""
"The ability to encrypt volumes depends on the service backends chosen. Some "
"backends may not support this at all."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml28(para)
msgid ""
"As both block storage and compute support LVM backed storage, we can easily "
"provide an example applicable to both systems. In deployments using LVM, "
"encryption may be performed against the backing physical volumes. An "
"encrypted block device would be created using the standard Linux tools, with"
" the LVM physical volume (PV) created on top of the decrypted block device "
"using pvcreate. Then, the vgcreate or vgmodify tool may be used to add the "
"encrypted physical volume to an LVM volume group (VG)."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml29(para)
msgid ""
"A feature aimed for the Havana release provides encryption of the VM's data "
"before it is written to disk. This allows the privacy of data to be "
"maintained while residing on the storage device. The idea is similar to how "
"self-encrypting drives work. This feature presents a normal block storage "
"device to the VM but encrypts the bytes in the virtualization host before "
"writing them to the disk. The block server operates exactly as it does when "
"reading and writing unencrypted blocks, except special handling will be "
"required for Block Storage features such as snapshots and live migration.  "
"Note that this feature uses an independent key manager."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml32(title)
msgid "Network Data"
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml33(para)
msgid ""
"Tenant data for compute could be encrypted over IPSec or other tunnels. This"
" is not functionality common or standard in OpenStack, but is an option "
"available to motivated and interested implementors."
msgstr ""
#: ./doc/security-guide/ch047_data-encryption.xml37(para)
msgid ""
"Block storage supports a variety of mechanisms for supplying mountable "
"volumes. It is outside the scope of this guide to specify recommendations "
"for each Block Storage backend driver. For the purpose of performance, many "
"storage protocols are unencrypted. Some protocols such as iSCSI can provide "
"authentication and encrypted sessions, it is our recommendation to enable "
"these features."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch005_security-domains.xml24(None)
#: ./doc/security-guide/ch005_security-domains.xml27(None)
msgid ""
"@@image: 'static/untrusted_trusted.png'; "
"md5=a582dac2ad0b3f439fd4b08386853056"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch005_security-domains.xml55(None)
#: ./doc/security-guide/ch005_security-domains.xml58(None)
msgid ""
"@@image: 'static/bridging_security_domains_1.png'; "
"md5=0d5ca26c51882ce3253405e91a597715"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch005_security-domains.xml63(None)
#: ./doc/security-guide/ch005_security-domains.xml66(None)
msgid ""
"@@image: 'static/bridging_domains_clouduser.png'; "
"md5=17c8a233ee7de17d2f600c7f6f6afe24"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch005_security-domains.xml95(None)
#: ./doc/security-guide/ch005_security-domains.xml98(None)
msgid ""
"@@image: 'static/threat_actors.png'; md5=114c2f9bd9d0319bdd83f9e229d44649"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch005_security-domains.xml116(None)
#: ./doc/security-guide/ch005_security-domains.xml119(None)
msgid ""
"@@image: 'static/high-capability.png'; md5=b7ab599c8b40558a52c0ca86aad89741"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml3(title)
msgid "Security Boundaries and Threats"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml4(para)
msgid ""
"A cloud can be abstracted as a collection of logical components by virtue of"
" their function, users, and shared security concerns, which we call security"
" domains. Threat actors and vectors are classified based on their motivation"
" and access to resources. Our goal is to provide you a sense of the security"
" concerns with respect to each domain depending on your risk/vulnerability "
"protection objectives."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml6(title)
msgid "Security Domains"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml7(para)
msgid ""
"A security domain comprises users, applications, servers or networks that "
"share common trust requirements and expectations within a system. Typically "
"they have the same authentication and authorization (AuthN/Z) requirements "
"and users."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml8(para)
msgid ""
"Although you may desire to break these domains down further (we later "
"discuss where this may be appropriate), we generally refer to four distinct "
"security domains which form the bare minimum that is required to deploy any "
"OpenStack cloud securely. These security domains are:"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml10(para)
#: ./doc/security-guide/ch005_security-domains.xml31(title)
msgid "Public"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml13(para)
#: ./doc/security-guide/ch005_security-domains.xml36(title)
msgid "Guest"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml16(para)
#: ./doc/security-guide/ch005_security-domains.xml41(title)
msgid "Management"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml19(para)
#: ./doc/security-guide/ch005_security-domains.xml46(title)
msgid "Data"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml22(para)
msgid ""
"We selected these security domains because they can be mapped independently "
"or combined to represent the majority of the possible areas of trust within "
"a given OpenStack deployment. For example, some deployment topologies "
"combine both guest and data domains onto one physical network versus others,"
" which have these networks physically separated. In each case, the cloud "
"operator should be aware of the appropriate security concerns. Security "
"domains should be mapped out against your specific OpenStack deployment "
"topology. The domains and their trust requirements depend upon whether the "
"cloud instance is public, private, or hybrid."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml32(para)
msgid ""
"The public security domain is an entirely untrusted area of the cloud "
"infrastructure. It can refer to the Internet as a whole or simply to "
"networks over which you have no authority. Any data that transits this "
"domain with confidentiality or integrity requirements should be protected "
"using compensating controls."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml33(para)
msgid ""
"This domain should always be considered <emphasis>untrusted</emphasis>."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml37(para)
msgid ""
"Typically used for compute instance-to-instance traffic, the guest security "
"domain handles compute data generated by instances on the cloud but not "
"services that support the operation of the cloud, such as API calls."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml38(para)
msgid ""
"Public cloud providers and private cloud providers who do not have stringent"
" controls on instance use or who allow unrestricted internet access to VMs "
"should consider this domain to be <emphasis>untrusted</emphasis>. Private "
"cloud providers may want to consider this network as internal and therefore "
"<emphasis>trusted</emphasis> only if they have controls in place to assert "
"that they trust instances and all their tenants."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml42(para)
msgid ""
"The management security domain is where services interact. Sometimes "
"referred to as the \"control plane\", the networks in this domain transport "
"confidential data such as configuration parameters, usernames, and "
"passwords. Command and Control traffic typically resides in this domain, "
"which necessitates strong integrity requirements. Access to this domain "
"should be highly restricted and monitored. At the same time, this domain "
"should still employ all of the security best practices described in this "
"guide."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml43(para)
msgid ""
"In most deployments this domain is considered <emphasis>trusted</emphasis>. "
"However, when considering an OpenStack deployment, there are many systems "
"that bridge this domain with others, potentially reducing the level of trust"
" you can place on this domain. See <xref linkend=\"ch005_security-domains-"
"idp61360\"/> for more information."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml47(para)
msgid ""
"The data security domain is concerned primarily with information pertaining "
"to the storage services within OpenStack. Much of the data that crosses this"
" network has high integrity and confidentiality requirements and depending "
"on the type of deployment there may also be strong availability "
"requirements."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml48(para)
msgid ""
"The trust level of this network is heavily dependent on deployment decisions"
" and as such we do not assign this any default level of trust."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml52(title)
msgid "Bridging Security Domains"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml53(para)
msgid ""
"A <emphasis>bridge</emphasis> is a component that exists inside more than "
"one security domain. Any component that bridges security domains with "
"different trust levels or authentication requirements must be carefully "
"configured. These bridges are often the weak points in network architecture."
" A bridge should always be configured to meet the security requirements of "
"the highest trust level of any of the domains it is bridging. In many cases "
"the security controls for bridges should be a primary concern due to the "
"likelihood of attack."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml61(para)
msgid ""
"The diagram above shows a compute node bridging the data and management "
"domains, as such the compute node should be configured to meet the security "
"requirements of the management domain. Similarly the API Endpoint in this "
"diagram is bridging the untrusted public domain and the management domain, "
"and should be configured to protect against attacks from the public domain "
"propagating through to the management domain."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml69(para)
msgid ""
"In some cases deployers may want to consider securing a bridge to a higher "
"standard than any of the domains in which it resides. Given the above "
"example of an API endpoint, an adversary could potentially target the API "
"endpoint from the public domain, leveraging it in the hopes of compromising "
"or gaining access to the management domain."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml70(para)
msgid ""
"The design of OpenStack is such that separation of security domains is "
"difficult - as core services will usually bridge at least two domains, "
"special consideration must be given when applying security controls to them."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml73(title)
msgid "Threat Classification, Actors and Attack Vectors"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml74(para)
msgid ""
"Most types of cloud deployment, public or private, are exposed to some form "
"of attack. In this chapter we categorize attackers and summarize potential "
"types of attacks in each security domain."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml76(title)
msgid "Threat Actors"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml77(para)
msgid ""
"A threat actor is an abstract way to refer to a class of adversary that you "
"may attempt to defend against. The more capable the actor, the more "
"expensive the security controls that are required for successful attack "
"mitigation and prevention. Security is a tradeoff between cost, usability "
"and defense. In some cases it will not be possible to secure a cloud "
"deployment against all of the threat actors we describe here. Those "
"deploying an OpenStack cloud will have to decide where the balance lies for "
"their deployment / usage."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml79(para)
msgid ""
"<emphasis role=\"bold\">Intelligence Services</emphasis> — Considered by "
"this guide as the most capable adversary. Intelligence Services and other "
"state actors can bring tremendous resources to bear on a target. They have "
"capabilities beyond that of any other actor. It is very difficult to defend "
"against these actors without incredibly stringent controls in place, both "
"human and technical."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml82(para)
msgid ""
"<emphasis role=\"bold\">Serious Organized Crime</emphasis> — Highly capable "
"and financially driven groups of attackers. Able to fund in-house exploit "
"development and target research. In recent years the rise of organizations "
"such as the Russian Business Network, a massive cyber-criminal enterprise "
"has demonstrated how cyber attacks have become a commodity. Industrial "
"espionage falls within the SOC group."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml85(para)
msgid ""
"<emphasis role=\"bold\">Highly Capable Groups</emphasis> — This refers to "
"'Hacktivist' type organizations who are not typically commercially funded "
"but can pose a serious threat to service providers and cloud operators."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml88(para)
msgid ""
"<emphasis role=\"bold\">Motivated Individuals</emphasis> — Acting alone, "
"these attackers come in many guises, such as rogue or malicious employees, "
"disaffected customers, or small-scale industrial espionage."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml91(para)
msgid ""
"<emphasis role=\"bold\">Script Kiddies</emphasis> — Automated vulnerability "
"scanning/exploitation. Non-targeted attacks. Often only a nuisance, "
"compromise by one of these actors presents a major risk to an organization's"
" reputation."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml103(title)
msgid "Public / Private Considerations"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml104(para)
msgid ""
"Private clouds are typically deployed by enterprises or institutions inside "
"their networks and behind their firewalls. Enterprises will have strict "
"policies on what data is allowed to exit their network and may even have "
"different clouds for specific purposes. Users of a private cloud are "
"typically employees of the organization that owns the cloud and are able to "
"be held accountable for their actions. Employees often attend training "
"sessions before accessing the cloud and will likely take part in regular "
"scheduled security awareness training. Public clouds by contrast cannot make"
" any assertions about their users, cloud use-cases or user motivations. This"
" immediately pushes the guest security domain into a completely "
"<emphasis>untrusted</emphasis> state for public cloud providers."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml105(para)
msgid ""
"A notable difference in the attack surface of public clouds is that they "
"must provide internet access to their services. Instance connectivity, "
"access to files over the internet and the ability to interact with the cloud"
" controlling fabric such as the API endpoints and dashboard are must-haves "
"for the public cloud."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml106(para)
msgid ""
"Privacy concerns for public and private cloud users are typically "
"diametrically opposed. The data generated and stored in private clouds is "
"normally owned by the operator of the cloud, who is able to deploy "
"technologies such as data loss prevention (DLP) protection, file inspection,"
" deep packet inspection and prescriptive firewalling. In contrast, privacy "
"is one of the primary barriers to adoption for the public cloud, as many of "
"these controls do not exist."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml109(title)
msgid "Outbound attacks and reputational risk"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml110(para)
msgid ""
"Careful consideration should be given to potential outbound abuse from a "
"cloud deployment.  Whether public or private, clouds tend to have lots of "
"resource available. An attacker who has established a point of presence "
"within the cloud, either through hacking in or via entitled access (rogue "
"employee), can bring these resources to bear against the internet at large. "
"Clouds with compute services make for ideal DDoS and brute force engines. "
"This is perhaps a more pressing issue for public clouds as their users are "
"largely unaccountable, and can quickly spin up numerous disposable instances"
" for outbound attacks.  Major damage can be inflicted upon a company's "
"reputation if it becomes known for hosting malicious software or launching "
"attacks on other networks. Methods of prevention include egress security "
"groups, outbound traffic inspection, customer education and awareness, and "
"fraud and abuse mitigation strategies."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml113(title)
msgid "Attack Types"
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml114(para)
msgid ""
"The diagram shows the types of attacks that may be expected from the actors "
"described in the previous section. Note that there will always be exceptions"
" to this diagram but in general, this describes the sorts of attack that "
"could be typical for each actor."
msgstr ""
#: ./doc/security-guide/ch005_security-domains.xml122(para)
msgid ""
"The prescriptive defense for each form of attack is beyond the scope of this"
" document. The above diagram can assist you in making an informed decision "
"about which types of threats, and threat actors, should be protected "
"against. For commercial public cloud deployments this might include "
"prevention against serious crime. For those deploying private clouds for "
"government use, more stringent protective mechanisms should be in place, "
"including carefully protected facilities and supply chains. In contrast "
"those standing up basic development or test environments will likely require"
" less restrictive controls (middle of the spectrum)."
msgstr ""
#: ./doc/security-guide/ch035_case-studies-networking.xml3(title)
msgid "Case Studies: Networking"
msgstr ""
#: ./doc/security-guide/ch035_case-studies-networking.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would address providing "
"networking services to the user."
msgstr ""
#: ./doc/security-guide/ch035_case-studies-networking.xml7(para)
msgid ""
"A key objective of Alice's cloud is to integrate with the existing auth "
"services and security resources. The key design parameters for this private "
"cloud are a limited scope of tenants, networks and workload type. This "
"environment can be designed to limit what available network resources are "
"available to the tenant and what are the various default quotas and security"
" policies are available. The network policy engine can be modified to "
"restrict creation and changes to network resources. In this environment, "
"Alice might want to leverage nova-network in the application of security "
"group polices on a per instance basis vs. Neutron's application of security "
"group polices on a per port basis. L2 isolation in this environment would "
"leverage VLAN tagging. The use of VLAN tags will allow great visibility of "
"tenant traffic by leveraging existing features and tools of the physical "
"infrastructure."
msgstr ""
#: ./doc/security-guide/ch035_case-studies-networking.xml25(para)
msgid ""
"A major business driver for Bob is to provide an advanced networking "
"services to his customers. Bob's customers would like to deploy multi-tiered"
" application stacks. This multi-tiered application are either existing "
"enterprise application or newly deployed applications. Since Bob's public "
"cloud is a multi-tenancy enterprise service, the choice to use for L2 "
"isolation in this environment is to use overlay networking. Another aspect "
"of Bob's cloud is the self-service aspect where the customer can provision "
"available networking services as needed. These networking services encompass"
" L2 networks, L3 Routing, Network <glossterm>ACL</glossterm> and NAT. It is "
"important that per-tenant quota's be implemented in this environment."
msgstr ""
#: ./doc/security-guide/ch035_case-studies-networking.xml38(para)
msgid ""
"An added benefit with utilizing OpenStack Networking is when new advanced "
"networking services become available, these new features can be easily "
"provided to the end customers."
msgstr ""
#: ./doc/security-guide/ch011_management-introduction.xml3(title)
msgid "Management Introduction"
msgstr ""
#: ./doc/security-guide/ch011_management-introduction.xml4(para)
msgid ""
"A cloud deployment is a living system. Machines age and fail, software "
"becomes outdated, vulnerabilities are discovered. When errors or omissions "
"are made in configuration, or when software fixes must be applied, these "
"changes must be made in a secure, but convenient, fashion. These changes are"
" typically solved through configuration management."
msgstr ""
#: ./doc/security-guide/ch011_management-introduction.xml5(para)
msgid ""
"Likewise, it is important to protect the cloud deployment from being "
"configured or manipulated by malicious entities. With many systems in a "
"cloud employing compute and networking virtualization, there are distinct "
"challenges applicable to OpenStack which must be addressed through integrity"
" lifecycle management."
msgstr ""
#: ./doc/security-guide/ch011_management-introduction.xml6(para)
msgid ""
"Finally, administrators must perform command and control over the cloud for "
"various operational functions. It is important these command and control "
"facilities are understood and secured."
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml3(title)
msgid "Case Studies: Tenant Data"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml4(para)
msgid ""
"Returning to Alice and Bob, we will use this section to dive into their "
"particular tenant data privacy requirements. Specifically, we will look into"
" how Alice and Bob both handle tenant data, data destruction, and data "
"encryption."
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml7(para)
msgid ""
"As stated during the introduction to Alice's case study, data protection is "
"of an extremely high priority. She needs to ensure that a compromise of one "
"tenant's data does not cause loss of other tenant data. She also has strong "
"regulator requirements that require documentation of data destruction "
"activities. Alice does this using the following:"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml15(para)
msgid ""
"Establishing procedures to sanitize tenant data when a program or project "
"ends"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml16(para)
msgid ""
"Track the destruction of both the tenant data and metadata via ticketing in "
"a CMDB"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml17(para)
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml28(para)
msgid "For Volume storage:"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml18(para)
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml29(para)
msgid "Physical Server Issues"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml19(para)
msgid ""
"To provide secure ephemeral instance storage, Alice implements qcow2 files "
"on an encrypted filesystem."
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml24(para)
msgid ""
"As stated during the introduction to Bob's case study, tenant privacy is of "
"an extremely high priority. In addition to the requirements and actions Bob "
"will take to isolate tenants from one another at the infrastructure layer, "
"Bob also needs to provide assurances for tenant data privacy. Bob does this "
"using the following:"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml26(para)
msgid ""
"Establishing procedures to sanitize customer data when a customer churns"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml27(para)
msgid ""
"Track the destruction of both the customer data and metadata via ticketing "
"in a CMDB"
msgstr ""
#: ./doc/security-guide/ch049_case-studies-tenant-data.xml30(para)
msgid ""
"To provide secure ephemeral instance storage, Bob implements qcow2 files on "
"an encrypted filesystems."
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml3(title)
msgid "Case Studies: Instance Isolation"
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml4(para)
msgid ""
"In this case study we discuss how Alice and Bob would ensure that  their "
"instances are properly isolated. First we consider hypervisor selection, and"
" then techniques for hardening QEMU and applying mandatory access controls."
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml7(para)
msgid ""
"Alice chooses Xen for the hypervisor in her cloud due to a strong internal "
"knowledge base and a desire to use the Xen security modules (XSM) for fine-"
"grained policy enforcement."
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml8(para)
msgid ""
"Alice is willing to apply a relatively large amount of resources to software"
" packaging and maintenance. She will use these resources to build a highly "
"customized version of QEMU that has many components removed, thereby "
"reducing the attack surface. She will also ensure that all compiler "
"hardening options are enabled for QEMU. Alice accepts that these decisions "
"will increase long-term maintenance costs."
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml9(para)
msgid ""
"Alice writes XSM policies (for Xen) and SELinux policies (for Linux domain "
"0, and device domains) to provide stronger isolation between the instances. "
"Alice also uses the Intel TXT support in Xen to measure the hypervisor "
"launch in the TPM."
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml13(para)
msgid ""
"Bob is very concerned about instance isolation since the users in a public "
"cloud represent anyone with a credit card, meaning they are inherently "
"untrusted. Bob has just started hiring the team that will deploy the cloud, "
"so he can tailor his candidate search for specific areas of expertise. With "
"this in mind, Bob chooses a hypervisor based on its technical features, "
"certifications, and community support. KVM has an EAL 4+ common criteria "
"rating, with a layered security protection profile (LSPP) to provide added "
"assurance for instance isolation. This, combined with the strong support for"
" KVM within the OpenStack community drives Bob's decision to use KVM."
msgstr ""
#: ./doc/security-guide/ch053_case-studies-instance-isolation.xml14(para)
msgid ""
"Bob weighs the added cost of repackaging QEMU and decides that he cannot "
"commit those resources to the project. Fortunately, his Linux distribution "
"has already enabled the compiler hardening options. So he decides to use "
"this QEMU package. Finally, Bob leverages sVirt to manage the SELinux "
"polices associated with the virtualization stack."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml3(title)
msgid "Networking Services Security Best Practices"
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml4(para)
msgid ""
"This section discusses OpenStack Networking configuration best practices as "
"they apply to tenant network security within your OpenStack deployment."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml6(title)
msgid "Tenant Network Services Workflow"
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml7(para)
msgid ""
"OpenStack Networking provides users real self services of network resources "
"and configurations. It is important that Cloud Architects and Operators "
"evaluate the their design use cases in providing users the ability to "
"create, update, and destroy available network resources."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml10(title)
msgid "Networking Resource Policy Engine"
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml11(para)
msgid ""
"A policy engine and its configuration file, "
"<filename>policy.json</filename>, within OpenStack Networking provides a "
"method to provide finer grained authorization of users on tenant networking "
"methods and objects. It is important that cloud architects and operators "
"evaluate their design and use cases in providing users and tenants the "
"ability to create, update, and destroy available network resources as it has"
" a tangible effect on tenant network availability, network security, and "
"overall OpenStack security. For a more detailed explanation of OpenStack "
"Networking policy definition, please refer to the <link "
"href=\"http://docs.openstack.org/admin-guide-"
"cloud/content/section_auth.html\">Authentication and authorization "
"section</link> in the <citetitle>OpenStack Cloud Administrator "
"Guide</citetitle>."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml25(address)
msgid ""
"It is important to review the default networking resource policy and modify "
"the policy appropriately for your security posture."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml26(para)
msgid ""
"If your deployment of OpenStack provides multiple external access points "
"into different security domains it is important that you limit the tenant's "
"ability to attach multiple vNICs to multiple external access points -- this "
"would bridge these security domains and could lead to unforseen security "
"compromise. It is possible mitigate this risk by utilizing the host "
"aggregates functionality provided by OpenStack Compute or through splitting "
"the tenant VMs into multiple tenant projects with different virtual network "
"configurations."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml29(title)
msgid "Security Groups"
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml30(para)
msgid ""
"The OpenStack Networking Service provides security group functionality using"
" a mechanism that is more flexible and powerful than the security group "
"capabilities built into OpenStack Compute. Thus, when using OpenStack "
"Networking, <emphasis>nova.conf</emphasis> should always disable built-in "
"security groups and proxy all security group calls to the OpenStack "
"Networking API. Failure to do so will result in conflicting security "
"policies being simultaneously applied by both services. To proxy security "
"groups to OpenStack Networking, use the following configuration values:"
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml32(para)
msgid ""
"firewall_driver : must be set to 'nova.virt.firewall.NoopFirewallDriver' so "
"that <systemitem class=\"service\">nova-compute</systemitem> does not "
"perform iptables-based filtering itself."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml35(para)
msgid ""
"security_group_api : must be set to 'neutron' so that all security group "
"requests are proxied to the OpenStack Network Service."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml38(para)
msgid ""
"Security groups and security group rules allow administrators and tenants "
"the ability to specify the type of traffic and direction (ingress/egress) "
"that is allowed to pass through a virtual interface port. A security group "
"is a container for security group rules. When a virtual interface port is "
"created in OpenStack Networking it is associated with a security group. If a"
" security group is not specified, the port will be associated with a "
"'default' security group. By default this group will drop all ingress "
"traffic and allow all egress. Rules can be added to this group in order to "
"change the behaviour."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml39(para)
msgid ""
"When using the security group API through OpenStack Compute, security groups"
" are applied to all virtual interface ports on an instance. The reason for "
"this is that OpenStack Compute security group APIs are instance based and "
"not virtual interface port based as OpenStack Networking."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml42(title)
msgid "Quotas"
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml43(para)
msgid ""
"Quotas provide the ability to limit the number of network resources "
"available to tenants. You can enforce default quotas for all tenants."
msgstr ""
#: ./doc/security-guide/ch034_tenant-secure-networking-best-practices.xml70(para)
msgid ""
"OpenStack Networking also supports per-tenant quotas limit via a quota "
"extension API. To enable per-tenant quotas, you need to set "
"<literal>quota_driver</literal> in <literal>neutron.conf</literal>."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for
#. you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/security-guide/ch052_devices.xml113(None)
#: ./doc/security-guide/ch052_devices.xml116(None)
msgid ""
"@@image: 'static/sVirt Diagram 1.png'; md5=ffcdbb45d9054670ad4c270a7c7d3925"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml3(title)
msgid "Hardening the Virtualization Layers"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml4(para)
msgid ""
"In the beginning of this chapter we discuss the use of both physical and "
"virtual hardware by instances, the associated security risks, and some "
"recommendations for mitigating those risks. We conclude the chapter with a "
"discussion of sVirt, an open source project for integrating SELinux "
"mandatory access controls with the virtualization components."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml6(title)
msgid "Physical Hardware (PCI Passthrough)"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml7(para)
msgid ""
"Many hypervisors offer a functionality known as PCI passthrough. This allows"
" an instance to have direct access to a piece of hardware on the node. For "
"example, this could be used to allow instances to access video cards "
"offering the compute unified device architecture (CUDA) for high performance"
" computation. This feature carries two types of security risks: direct "
"memory access and hardware infection."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml8(para)
msgid ""
"Direct memory access (DMA) is a feature that permits certain hardware "
"devices to access arbitrary physical memory addresses in the host computer. "
"Often video cards have this capability. However, an instance should not be "
"given arbitrary physical memory access because this would give it full view "
"of both the host system and other instances running on the same node. "
"Hardware vendors use an input/output memory management unit (IOMMU) to "
"manage DMA access in these situations. Therefore, cloud architects should "
"ensure that the hypervisor is configured to utilize this hardware feature."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml10(para)
msgid ""
"KVM: <link href=\"http://www.linux-kvm.org/page"
"/How_to_assign_devices_with_VT-d_in_KVM\">How to assign devices with VT-d in"
" KVM</link>"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml13(para)
msgid "Xen: <link href=\"http://wiki.xen.org/wiki/VTd_HowTo\">VTd Howto</link>"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml17(para)
msgid "The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml19(para)
msgid ""
"A hardware infection occurs when an instance makes a malicious modification "
"to the firmware or some other part of a device. As this device is used by "
"other instances, or even the host OS, the malicious code can spread into "
"these systems. The end result is that one instance can run code outside of "
"its security domain. This is a potential problem in any hardware sharing "
"scenario. The problem is specific to this scenario because it is harder to "
"reset the state of physical hardware than virtual hardware."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml20(para)
msgid ""
"Solutions to the hardware infection problem are domain specific. The "
"strategy is to identify how an instance can modify hardware state then "
"determine how to reset any modifications when the instance is done using the"
" hardware. For example, one option could be to re-flash the firmware after "
"use. Clearly there is a need to balance hardware longevity with security as "
"some firmwares will fail after a large number of writes. TPM technology, "
"described in <literal>link:Management/Node Bootstrapping</literal>, provides"
" a solution for detecting unauthorized firmware changes. Regardless of the "
"strategy selected, it is important to understand the risks associated with "
"this kind of hardware sharing so that they can be properly mitigated for a "
"given deployment scenario."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml21(para)
msgid ""
"Additionally, due to the risk and complexities associated with PCI "
"passthrough, it should be disabled by default. If enabled for a specific "
"need, you will need to have appropriate processes in place to ensure the "
"hardware is clean before re-issue."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml24(title)
msgid "Virtual Hardware (QEMU)"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml25(para)
msgid ""
"When running a virtual machine, virtual hardware is a software layer that "
"provides the hardware interface for the virtual machine. Instances use this "
"functionality to provide network, storage, video, and other devices that may"
" be needed. With this in mind, most instances in your environment will "
"exclusively use virtual hardware, with a minority that will require direct "
"hardware access. The major open source hypervisors use QEMU for this "
"functionality. While QEMU fills an important need for virtualization "
"platforms, it has proven to be a very challenging software project to write "
"and maintain. Much of the functionality in QEMU is implemented with low-"
"level code that is difficult for most developers to comprehend. Furthermore,"
" the hardware virtualized by QEMU includes many legacy devices that have "
"their own set of quirks. Putting all of this together, QEMU has been the "
"source of many security problems, including hypervisor breakout attacks."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml41(para)
msgid ""
"For the reasons stated above, it is important to take proactive steps to "
"harden QEMU. We recommend three specific steps: minimizing the codebase, "
"using compiler hardening, and using mandatory access controls, for example: "
"sVirt, SELinux, or AppArmor."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml43(title)
msgid "Minimizing the Qemu Codebase"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml44(para)
msgid ""
"One classic security principle is to remove any unused components from your "
"system. QEMU provides support for many different virtual hardware devices. "
"However, only a small number of devices are needed for a given instance. "
"Most instances will use the virtio devices. However, some legacy instances "
"will need access to specific hardware, which can be specified using glance "
"metadata:"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml51(para)
msgid ""
"A cloud architect should decide what devices to make available to cloud "
"users. Anything that is not needed should be removed from QEMU. This step "
"requires recompiling QEMU after modifying the options passed to the QEMU "
"configure script. For a complete list of up-to-date options simply run "
"<literal>./configure --help</literal> from within the QEMU source directory."
" Decide what is needed for your deployment, and disable the remaining "
"options."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml54(title)
msgid "Compiler Hardening"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml55(para)
msgid ""
"The next step is to harden QEMU using compiler hardening options. Modern "
"compilers provide a variety of compile time options to improve the security "
"of the resulting binaries. These features, which we will describe in more "
"detail below, include relocation read-only (RELRO), stack canaries, never "
"execute (NX), position independent executable (PIE), and address space "
"layout randomization (ASLR)."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml56(para)
msgid ""
"Many modern linux distributions already build QEMU with compiler hardening "
"enabled, so you may want to verify your existing executable before "
"proceeding with the information below. One tool that can assist you with "
"this verification is called <link "
"href=\"http://www.trapkit.de/tools/checksec.html\"><literal>checksec.sh</literal></link>."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml58(para)
msgid ""
"<emphasis>RELocation Read-Only (RELRO)</emphasis>: Hardens the data sections"
" of an executable. Both full and partial RELRO modes are supported by gcc. "
"For QEMU full RELRO is your best choice. This will make the global offset "
"table read-only and place various internal data sections before the program "
"data section in the resulting executable."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml61(para)
msgid ""
"<emphasis>Stack Canaries</emphasis>: Places values on the stack and verifies"
" their presence to help prevent buffer overflow attacks."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml64(para)
msgid ""
"<emphasis>Never eXecute (NX)</emphasis>: Also known as Data Execution "
"Prevention (DEP), ensures that data sections of the executable can not be "
"executed."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml67(para)
msgid ""
"<emphasis>Position Independent Executable (PIE)</emphasis>: Produces a "
"position independent executable, which is necessary for ASLR.  "
msgstr ""
#: ./doc/security-guide/ch052_devices.xml70(para)
msgid ""
"<emphasis>Address Space Layout Randomization (ASLR)</emphasis> : This "
"ensures that both code and data regions will be randomized. Enabled by the "
"kernel (all modern linux kernels support ASLR), when the executable is built"
" with PIE."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml73(para)
msgid ""
"Putting this all together, and adding in some additional useful protections,"
" we recommend the following compiler options for gcc when compiling QEMU:"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml76(para)
msgid ""
"We recommend testing your QEMU executable file after it is compiled to "
"ensure that the compiler hardening worked properly."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml77(para)
msgid ""
"Most cloud deployments will not want to build software such as QEMU by hand."
" It is better to use packaging to ensure that the process is repeatable and "
"to ensure that the end result can be easily deployed throughout the cloud. "
"The references below provide some additional details on applying compiler "
"hardening options to existing packages."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml79(para)
msgid ""
"DEB packages: <link "
"href=\"http://wiki.debian.org/HardeningWalkthrough\">Hardening "
"Walkthrough</link>"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml82(para)
msgid ""
"RPM packages: <link "
"href=\"http://fedoraproject.org/wiki/How_to_create_an_RPM_package\">How to "
"create an RPM package</link>"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml88(para)
msgid ""
"Compiler hardening makes it more difficult to attack the QEMU process. "
"However, if an attacker does succeed, we would like to limit the impact of "
"the attack. Mandatory access controls accomplish this by restricting the "
"privileges on QEMU process to only what is needed. This can be accomplished "
"using sVirt / SELinux or AppArmor. When using sVirt, SELinux is configured "
"to run every QEMU process under a different security context. AppArmor can "
"be configured to provide similar functionality. We provide more details on "
"sVirt in the instance isolation section below."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml92(title)
msgid "sVirt: SELinux + Virtualization"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml93(para)
msgid ""
"With unique kernel-level architecture and National Security Agency (NSA) "
"developed security mechanisms, KVM provides foundational isolation "
"technologies for multitenancy. With developmental origins dating back to "
"2002, the Secure Virtualization (sVirt) technology is the application of "
"SELinux against modern day virtualization. SELinux, which was designed to "
"apply separation control based upon labels, has been extended to provide "
"isolation between virtual machine processes, devices, data files and system "
"processes acting upon their behalf."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml94(para)
msgid ""
"OpenStack's sVirt implementation aspires to protect hypervisor hosts and "
"virtual machines against two primary threat vectors:"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml96(para)
msgid ""
"<emphasis role=\"bold\">Hypervisor threats</emphasis> A compromised "
"application running within a virtual machine attacks the hypervisor to "
"access underlying resources (e.g. the host OS, applications, or devices "
"within the physical machine). This is a threat vector unique to "
"virtualization and represents considerable risk as the underlying real "
"machine can be compromised due to vulnerability in a single virtual "
"application."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml99(para)
msgid ""
"<emphasis role=\"bold\">Virtual Machine (multi-tenant) threats</emphasis> A "
"compromised application running within a VM attacks the hypervisor to "
"access/control another virtual machine and its resources. This is a threat "
"vector unique to virtualization and represents considerable risk as a "
"multitude of virtual machine file images could be compromised due to "
"vulnerability in a single application. This virtual network attack is a "
"major concern as the administrative techniques for protecting real networks "
"do not directly apply to the virtual environment."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml111(para)
msgid ""
"Each KVM-based virtual machine is a process which is labeled by SELinux, "
"effectively establishing a security boundary around each virtual machine. "
"This security boundary is monitored and enforced by the Linux kernel, "
"restricting the virtual machine's access to resources outside of its "
"boundary such as host machine data files or other VMs."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml119(para)
msgid ""
"As shown above, sVirt isolation is provided regardless of the guest "
"Operating System running inside the virtual machine -- Linux or Windows VMs "
"can be used. Additionally, many Linux distributions provide SELinux within "
"the operating system, allowing the virtual machine to protect internal "
"virtual resources from threats. "
msgstr ""
#: ./doc/security-guide/ch052_devices.xml121(title)
msgid "Labels and Categories"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml122(para)
msgid ""
"KVM-based virtual machine instances are labelled with their own SELinux data"
" type, known as svirt_image_t. Kernel level protections prevent unauthorized"
" system processes, such as malware, from manipulating the virtual machine "
"image files on disk. When virtual machines are powered off, images are "
"stored as svirt_image_t as shown below:"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml128(para)
msgid ""
"The svirt_image_t label uniquely identifies image files on disk, allowing "
"for the SELinux policy to restrict access. When a KVM-based Compute image is"
" powered on, sVirt appends a random numerical identifier to the image. sVirt"
" is technically capable of assigning numerical identifiers to 524,288 "
"virtual machines per hypervisor node, however OpenStack deployments are "
"highly unlikely to encounter this limitation."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml129(para)
msgid "An example of the sVirt category identifier is shown below:"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml135(title)
msgid "Booleans"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml136(para)
msgid ""
"To ease the administrative burden of managing SELinux, many enterprise Linux"
" platforms utilize SELinux Booleans to quickly change the security posture "
"of sVirt."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml137(para)
msgid ""
"Red Hat Enterprise Linux-based KVM deployments utilize the following sVirt "
"booleans:"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml144(emphasis)
msgid "sVirt SELinux Boolean"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml145(emphasis)
msgid " Description"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml148(para)
msgid "virt_use_common"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml149(para)
msgid "Allow virt to use serial/parallel communication ports."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml152(para)
msgid "virt_use_fusefs"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml153(para)
msgid "Allow virt to read FUSE mounted files."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml156(para)
msgid "virt_use_nfs"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml157(para)
msgid "Allow virt to manage NFS mounted files."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml160(para)
msgid "virt_use_samba"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml161(para)
msgid "Allow virt to manage CIFS mounted files."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml164(para)
msgid "virt_use_sanlock"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml165(para)
msgid "Allow confined virtual guests to interact with the sanlock."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml168(para)
msgid "virt_use_sysfs"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml169(para)
msgid "Allow virt to manage device configuration (PCI)."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml172(para)
msgid "virt_use_usb"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml173(para)
msgid "Allow virt to use USB devices."
msgstr ""
#: ./doc/security-guide/ch052_devices.xml176(para)
msgid "virt_use_xserver"
msgstr ""
#: ./doc/security-guide/ch052_devices.xml177(para)
msgid "Allow virtual machine to interact with the X Window System."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml3(title)
msgid "SSL Proxies and HTTP Services"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml4(para)
msgid ""
"OpenStack endpoints are HTTP services providing APIs to both end-users on "
"public networks and to other OpenStack services within the same deployment "
"operating over the management network. It is highly recommended these "
"requests, both those internal and external, operate over SSL."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml5(para)
msgid ""
"In order for API requests to be encrypted by SSL it's necessary to position "
"the API services behind a proxy that will establish and terminate SSL "
"sessions. The following table offers a non-exhaustive list of software "
"services that can proxy SSL traffic for API requests:"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml7(link)
msgid "Pound"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml10(link)
#: ./doc/security-guide/ch020_ssl-everywhere.xml80(title)
msgid "Stud"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml13(link)
#: ./doc/security-guide/ch020_ssl-everywhere.xml119(title)
msgid "nginx"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml16(link)
msgid "Apache httpd"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml19(para)
msgid "Hardware appliance SSL acceleration proxies"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml22(para)
msgid ""
"It is important to be mindful of the size of requests that will be processed"
" by any chosen SSL proxy."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml24(title)
msgid "Examples"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml25(para)
msgid ""
"Below we provide some sample configuration setting for enabling SSL in some "
"of the most popular web servers/SSL terminators with recommended "
"configurations. Note that we have SSL v3 enabled in some of these examples "
"as this will be required in many deployments for client compatibility."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml27(title)
msgid "Pound - with AES-NI acceleration"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml81(para)
msgid ""
"This stud example enables SSL v3 for client compatibility.  The ciphers line"
" can be tweaked based on your needs, however this is a reasonable starting "
"place."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml120(para)
msgid ""
"This nginx example requires TLS v1.1 or v1.2 for maximum security. The "
"ssl_ciphers line can be tweaked based on your needs, however this is a "
"reasonable starting place."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml137(title)
msgid "Apache"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml163(para)
msgid ""
"Compute API SSL endpoint in Apache2, which needs to be paired with a short "
"WSGI script."
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml188(title)
msgid "HTTP Strict Transport Security"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml189(para)
msgid ""
"We recommend that all production deployments use HSTS. This header prevents "
"browsers from making insecure connections after they have made a single "
"secure one. If you have deployed your HTTP services on a public or an "
"untrusted domain, HSTS is especially important. To enable HSTS, configure "
"your web server to send a header like this with all requests:"
msgstr ""
#: ./doc/security-guide/ch020_ssl-everywhere.xml192(para)
msgid ""
"Start with a short timeout of 1 day during testing, and raise it to one year"
" after testing has shown that you haven't introduced problems for users. "
"Note that once this header is set to a large timeout, it is (by design) very"
" difficult to disable."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml3(title)
msgid "Forensics and Incident Response"
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml4(para)
msgid ""
"A lot of activity goes on within a cloud environment. It is a mix of "
"hardware, operating systems, virtual machine managers, the OpenStack "
"services, cloud-user activity such as creating instances and attaching "
"storage, the network underlying the whole, and finally end-users using the "
"applications running on the various instances."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml5(para)
msgid ""
"The generation and collection of logs is an important component of securely "
"monitoring an OpenStack infrastructure. Logs provide visibility into the "
"day-to-day actions of administrators, tenants, and guests, in addition to "
"the activity in the compute, networking, and storage and other components "
"that comprise your OpenStack deployment."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml6(para)
msgid ""
"The basics of logging: configuration, setting log level, location of the log"
" files, and how to use and customize logs, as well as how to do centralized "
"collections of logs is well covered in the <link "
"href=\"http://docs.openstack.org/ops/\"><citetitle>OpenStack Operations "
"Guide</citetitle></link>."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml7(para)
msgid ""
"Logs are not only valuable for proactive security and continuous compliance "
"activities, but they are also a valuable information  source for "
"investigating and responding to incidents."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml8(para)
msgid ""
"For instance, analyzing the access logs of Identity Service or its "
"replacement authentication system would alert us to failed logins, their "
"frequency, origin IP, whether the events are restricted to select accounts "
"etc. Log analysis supports detection."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml9(para)
msgid ""
"On detection, further action may be to black list an IP, or recommend "
"strengthening user passwords, or even de-activating a user account if it is "
"deemed dormant."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml11(title)
msgid "Monitoring Use Cases"
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml12(para)
msgid ""
"Monitoring events is more pro-active and provides real-time detection and "
"response.  There are several tools to aid in monitoring."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml13(para)
msgid ""
"In the case of a OpenStack cloud instance, we need to monitor the hardware, "
"the OpenStack services, and the cloud resource usage. The last stems from "
"wanting to be elastic, to scale to the dynamic needs of the users."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml14(para)
msgid ""
"Here are a few important use cases to consider when implementing log "
"aggregation, analysis and monitoring. These use cases can be implemented and"
" monitored through various commercial and open source tools, homegrown "
"scripts, etc. These tools and scripts can generate events that can then be "
"sent to the administrators through email or integrated dashboard. It is "
"important to consider additional use cases that may apply to your specific "
"network and what you may consider anomalous behavior."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml16(para)
msgid ""
"Detecting the absence of log generation is an event of high value. Such an "
"event would indicate a service failure or even an intruder who has "
"temporarily switched off logging or modified the log level to hide their "
"tracks."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml20(para)
msgid ""
"Application events such as start and/or stop that were unscheduled would "
"also be events to monitor and examine for possible security implications."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml24(para)
msgid ""
"OS events on the OpenStack service machines such as user logins, restarts "
"also provide valuable insight into use/misuse"
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml28(para)
msgid ""
"Being able to detect the load on the OpenStack servers also enables "
"responding by way of introducing additional servers for load balancing to "
"ensure high availability."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml32(para)
msgid ""
"Other events that are actionable are networking bridges going down, ip "
"tables being flushed on compute nodes and consequential loss of access to "
"instances resulting in unhappy customers. "
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml36(para)
msgid ""
"To reduce security risks from orphan instances on a user/tenant/domain "
"deletion in the Identity service there is discussion to generate "
"notifications in the system and have OpenStack components respond to these "
"events as appropriate such as terminating instances, disconnecting attached "
"volumes, reclaiming CPU and storage resources etc. "
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml39(para)
msgid ""
"A cloud will host many virtual instances, and monitoring these instances "
"goes beyond hardware monitoring and log files which may just contain CRUD "
"events."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml40(para)
msgid ""
"Security monitoring controls such as intrusion detection software, antivirus"
" software, and spyware detection and removal utilities can generate logs "
"that show when and how an attack or intrusion took place. Deploying these "
"tools on the cloud machines provides value and protection. Cloud users, "
"those running instances on the cloud may also want to run such tools on "
"their instances."
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml44(link)
msgid "http://www.mirantis.com/blog/openstack-monitoring/"
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml45(link)
msgid "http://blog.sflow.com/2012/01/host-sflow-distributed-agent.html"
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml46(link)
msgid "http://blog.sflow.com/2009/09/lan-and-wan.html"
msgstr ""
#: ./doc/security-guide/ch058_forensicsincident-response.xml47(link)
msgid ""
"http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html"
msgstr ""
#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2
#: ./doc/security-guide/ch058_forensicsincident-response.xml0(None)
msgid "translator-credits"
msgstr ""
View Git Blame Copy Permalink