10125 lines
414 KiB
Plaintext
10125 lines
414 KiB
Plaintext
#
|
||
# Translators:
|
||
msgid ""
|
||
msgstr ""
|
||
"Project-Id-Version: OpenStack Manuals\n"
|
||
"POT-Creation-Date: 2014-04-19 04:10+0000\n"
|
||
"PO-Revision-Date: 2014-04-18 18:25+0000\n"
|
||
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
|
||
"Language-Team: Korean (Korea) (http://www.transifex.com/projects/p/openstack/language/ko_KR/)\n"
|
||
"MIME-Version: 1.0\n"
|
||
"Content-Type: text/plain; charset=UTF-8\n"
|
||
"Content-Transfer-Encoding: 8bit\n"
|
||
"Language: ko_KR\n"
|
||
"Plural-Forms: nplurals=1; plural=0;\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>, 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 customers implement OpenStack and VMware NSX "
|
||
"(formerly known as Nicira's Network Virtualization Platform). Prior to "
|
||
"joining VMware (through the company's acquisition of 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 & 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 multi-tenant, 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.xml17(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.xml19(title)
|
||
msgid "Hypervisors in OpenStack"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml20(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.xml34(para)
|
||
msgid ""
|
||
"Within the framework of OpenStack you can choose from any number of "
|
||
"hypervisor platforms and corresponding OpenStack plug-ins to optimize your "
|
||
"cloud environment. In the context of the OpenStack Security guide, we will "
|
||
"be highlighting hypervisor selection considerations as they pertain 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.xml37(title)
|
||
msgid "Selection Criteria"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml38(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.xml40(para)
|
||
msgid "Team Expertise"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml43(para)
|
||
msgid "Product or Project maturity"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml46(para)
|
||
msgid "Certifications, Attestations"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml49(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml313(title)
|
||
msgid "Additional Security Features"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml52(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml306(title)
|
||
msgid "Hypervisor vs. Baremetal"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml55(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml268(title)
|
||
msgid "Hardware Concerns"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml58(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml92(title)
|
||
msgid "Common Criteria"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml62(para)
|
||
msgid ""
|
||
"Has the hypervisor undergone Common Criteria certification? If so, to what "
|
||
"levels?"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml65(para)
|
||
msgid "Is the underlying cryptography certified by a third-party?"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml61(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.xml69(title)
|
||
msgid "Product or Project Maturity"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml70(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.xml72(para)
|
||
msgid "Availability of expertise"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml75(para)
|
||
msgid "Active developer and user communities"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml78(para)
|
||
msgid "Timeliness and Availability of updates"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml81(para)
|
||
msgid "Incidence response"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml84(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.xml85(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.xml88(title)
|
||
msgid "Certifications and Attestations"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml89(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.xml93(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.xml94(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.xml96(para)
|
||
msgid "How is source code management performed?"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml99(para)
|
||
msgid "How are users granted access to build systems?"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml102(para)
|
||
msgid "Is the technology cryptographically signed before distribution?"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml105(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.xml107(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.xml109(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.xml116(para)
|
||
msgid "Identification and Authentication"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml117(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.xml120(para)
|
||
msgid "Audit"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml121(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.xml121(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.xml121(para)
|
||
msgid "Audit records can be transferred to a remote audit daemon."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml124(para)
|
||
msgid "Discretionary Access Control"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml126(para)
|
||
msgid ""
|
||
"Discretionary Access Control (<glossterm>DAC</glossterm>) restricts access "
|
||
"to file system objects based on <glossterm baseform=\"access control "
|
||
"list\">Access Control Lists</glossterm> (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.xml135(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.xml143(para)
|
||
msgid "Mandatory Access Control"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml144(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.xml144(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.xml144(para)
|
||
msgid ""
|
||
"The TOE implements non-hierarchical categories to control access to virtual "
|
||
"machines."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml147(para)
|
||
msgid "Role-Based Access Control"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml148(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.xml151(para)
|
||
msgid "Object Reuse"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml152(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.xml155(para)
|
||
msgid "Security Management"
|
||
msgstr "보안 관리"
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml156(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.xml159(para)
|
||
msgid "Secure Communication"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml160(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.xml163(para)
|
||
msgid "Storage Encryption"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml164(para)
|
||
msgid ""
|
||
"The system supports encrypted block devices to provide storage "
|
||
"confidentiality via dm_crypt."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml167(para)
|
||
msgid "TSF Protection"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml168(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.xml168(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, such as configuration "
|
||
"files and batch job queues, are also protected from reading by DAC "
|
||
"permissions."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml175(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.xml175(para)
|
||
msgid ""
|
||
"In addition, mechanisms for protection against stack overflow attacks are "
|
||
"provided."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml182(title)
|
||
msgid "Cryptography Standards"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml183(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.xml193(emphasis)
|
||
msgid "Algorithm"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml194(emphasis)
|
||
msgid "Key Length"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml195(emphasis)
|
||
msgid "Intended Purpose"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml196(emphasis)
|
||
msgid "Security Function"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml197(emphasis)
|
||
msgid "Implementation Standard"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml200(para)
|
||
msgid "AES"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml201(para)
|
||
msgid "128 bits,192 bits,"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml201(para)
|
||
msgid "256 bits"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml202(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml209(para)
|
||
msgid "Encryption / Decryption"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml203(para)
|
||
msgid "Protected Data Transfer, Protection for Data at Rest"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml204(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml211(para)
|
||
msgid "RFC 4253"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml207(para)
|
||
msgid "TDES"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml208(para)
|
||
msgid "168 bits"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml210(para)
|
||
msgid "Protected Data Transfer"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml214(para)
|
||
msgid "RSA"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml215(para)
|
||
msgid "1024 bits,2048 bits,"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml215(para)
|
||
msgid "3072 bits "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml216(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml223(para)
|
||
msgid "Authentication,Key Exchange "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml217(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml224(para)
|
||
msgid "Identification and Authentication, Protected Data Transfer"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml218(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml225(para)
|
||
msgid "U.S. NIST FIPS PUB 186-3"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml221(para)
|
||
msgid "DSA"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml222(para)
|
||
msgid "L=1024,N=160 bits "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml228(para)
|
||
msgid "Serpent"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml229(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml236(para)
|
||
msgid "128, 196, or256 bit "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml230(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml237(para)
|
||
msgid "Encryption /Decryption "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml231(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml238(para)
|
||
msgid "Protection of Data at Rest"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml232(link)
|
||
msgid "http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml235(para)
|
||
msgid "Twofish"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml239(link)
|
||
msgid "http://www.schneier.com/paper-twofish-paper.html"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml242(para)
|
||
msgid "SHA-1"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml243(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml250(para)
|
||
msgid "-"
|
||
msgstr "-"
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml244(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml251(para)
|
||
msgid "MessageDigest "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml245(para)
|
||
msgid "Protection of Data at Rest,Protected Data Transfer"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml246(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml253(para)
|
||
msgid "U.S. NIST FIPS 180-3"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml249(para)
|
||
msgid "SHA-2(224-, 256-,"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml249(para)
|
||
msgid "384-, 512 bit)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml252(para)
|
||
msgid "Protection for Data at Rest,Identification and Authentication "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml259(title)
|
||
msgid "FIPS 140-2"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml260(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.xml262(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.xml264(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.xml269(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.xml277(emphasis)
|
||
msgid "Description"
|
||
msgstr "설명"
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml278(emphasis)
|
||
msgid "Technology"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml279(emphasis)
|
||
msgid "Explanation"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml282(para)
|
||
msgid "I/O MMU"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml283(para)
|
||
msgid "VT-d / AMD-Vi"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml284(para)
|
||
msgid "Required for protecting PCI-passthrough"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml287(para)
|
||
msgid "Intel Trusted Execution Technology"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml288(para)
|
||
msgid "Intel TXT / SEM"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml289(para)
|
||
msgid "Required for dynamic attestation services"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml292(para)
|
||
msgid ""
|
||
"<anchor xml:id=\"PCI-SIG_I.2FO_virtualization_.28IOV.29\"/>PCI-SIG I/O "
|
||
"virtualization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml293(para)
|
||
msgid "SR-IOV, MR-IOV, ATS"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml294(para)
|
||
msgid "Required to allow secure sharing of PCI Express devices"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml297(para)
|
||
msgid "Network virtualization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml298(para)
|
||
msgid "VT-c"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml299(para)
|
||
msgid "Improves performance of network I/O on hypervisors"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml307(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.xml308(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.xml309(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.xml310(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.xml314(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.xml315(para)
|
||
msgid ""
|
||
"The following table calls out these features by common hypervisor platforms."
|
||
" "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml328(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml340(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml349(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml351(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml353(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml354(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml359(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml360(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml361(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml363(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml364(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml365(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml369(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml370(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml371(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml372(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml373(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml374(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml375(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml95(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml100(emphasis)
|
||
msgid " "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml329(para)
|
||
msgid "KSM"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml330(para)
|
||
msgid "XSM"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml331(para)
|
||
msgid "sVirt"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml332(para)
|
||
msgid "TXT"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml333(para)
|
||
msgid "AppArmor"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml334(para)
|
||
msgid "cGroups"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml335(para)
|
||
msgid "MAC Policy"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml338(para)
|
||
msgid "KVM"
|
||
msgstr "KVM"
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml339(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml341(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml342(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml350(para)
|
||
msgid "X"
|
||
msgstr "X"
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml343(address)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml344(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml345(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml355(para)
|
||
msgid "x"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml348(para)
|
||
msgid "Xen"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml352(para)
|
||
#: ./doc/security-guide/ch051_vss-intro.xml362(para)
|
||
msgid " X"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml358(para)
|
||
msgid "ESXi"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml368(para)
|
||
msgid "Hyper-V"
|
||
msgstr "Hyper-V"
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml380(link)
|
||
msgid "KSM: Kernel Samepage Merging"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml381(link)
|
||
msgid "XSM: Xen Security Modules"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml382(link)
|
||
msgid "xVirt: Mandatory Access Control for Linux-based virtualization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml383(link)
|
||
msgid "TXT: Intel Trusted Execution Technology"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml384(link)
|
||
msgid "AppArmor: Linux security module implementing MAC"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml385(link)
|
||
msgid "cgroups: Linux kernel feature to control resource usage"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml386(para)
|
||
msgid ""
|
||
"MAC Policy: Mandatory Access Control; may be implemented with SELinux or "
|
||
"other operating systems"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch051_vss-intro.xml387(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.xml34(title)
|
||
#: ./doc/security-guide/ch004_book-introduction.xml186(title)
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml8(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.xml8(title)
|
||
msgid "Continuous Systems Management"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml9(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.xml16(title)
|
||
#: ./doc/security-guide/ch063_compliance-activities.xml43(title)
|
||
msgid "Vulnerability Management"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml17(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.xml24(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.xml36(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.xml44(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.xml33(para)
|
||
msgid ""
|
||
"OpenStack releases security information through two channels. "
|
||
"<placeholder-1/>"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml56(title)
|
||
msgid "Triage"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml57(para)
|
||
msgid ""
|
||
"After you are notified of 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.xml63(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.xml69(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.xml75(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.xml80(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.xml96(emphasis)
|
||
msgid "Attacker Position / Privilege Level"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml102(emphasis)
|
||
msgid "External"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml103(emphasis)
|
||
msgid "Cloud User"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml105(emphasis)
|
||
msgid "Cloud Admin"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml107(emphasis)
|
||
msgid "Control Plane"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml111(emphasis)
|
||
msgid "Privilege Elevation (3 levels)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml113(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml121(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml122(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml129(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml130(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml131(para)
|
||
msgid "Critical"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml114(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml115(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml116(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml123(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml124(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml132(para)
|
||
msgid "n/a"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml119(emphasis)
|
||
msgid "Privilege Elevation (2 levels)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml127(emphasis)
|
||
msgid "Privilege Elevation (1 level)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml135(emphasis)
|
||
msgid "Denial of Service"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml137(para)
|
||
msgid "High"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml138(para)
|
||
msgid "Medium"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml139(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml140(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml148(para)
|
||
msgid "Low"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml143(emphasis)
|
||
msgid "Information Disclosure"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml145(para)
|
||
#: ./doc/security-guide/ch012_configuration-management.xml146(para)
|
||
msgid "Critical / High"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml147(para)
|
||
msgid "Medium / Low"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml152(para)
|
||
msgid ""
|
||
"This 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 "
|
||
"potentially allows 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.xml158(para)
|
||
msgid ""
|
||
"We suggest that cloud administrators use this table as a model to help "
|
||
"define which actions to take for the various security 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.xml165(title)
|
||
msgid "Testing the Updates"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml166(para)
|
||
msgid ""
|
||
"You should test any update before you deploy it 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, such as a specific vulnerability, is actually "
|
||
"fixed."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml177(title)
|
||
msgid "Deploying the Updates"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml178(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.xml185(title)
|
||
msgid "Configuration Management"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml186(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.xml191(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.xml203(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 re-mediate "
|
||
"unauthorized changes that may occur. For example, a "
|
||
"<filename>nova.conf</filename> file or other configuration file falls out of"
|
||
" compliance with your standard, your configuration management tool can "
|
||
"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.xml215(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.xml223(para)
|
||
msgid "Chef"
|
||
msgstr "Chef"
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml226(para)
|
||
msgid "Puppet"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml229(para)
|
||
msgid "Salt Stack"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml232(para)
|
||
msgid "Ansible"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml236(title)
|
||
msgid "Policy Changes"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml237(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.xml244(title)
|
||
msgid "Secure Backup and Recovery"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml245(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.xml250(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml56(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml102(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml135(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml159(title)
|
||
#: ./doc/security-guide/ch026_compute.xml33(title)
|
||
#: ./doc/security-guide/ch026_compute.xml68(title)
|
||
msgid "Security Considerations"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml253(para)
|
||
msgid ""
|
||
"Ensure only authenticated users and backup clients have access to the backup"
|
||
" server."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml257(para)
|
||
msgid "Use data encryption options for storage and transmission of backups."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml261(para)
|
||
msgid ""
|
||
"Use a dedicated and hardened backup servers. The logs for the backup server "
|
||
"must be monitored daily and accessible by only few individuals."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml266(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.xml276(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml75(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml145(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml184(title)
|
||
#: ./doc/security-guide/ch026_compute.xml44(title)
|
||
#: ./doc/security-guide/ch026_compute.xml81(title)
|
||
#: ./doc/security-guide/ch058_forensicsincident-response.xml43(title)
|
||
msgid "References"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml279(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.xml287(link)
|
||
msgid ""
|
||
"http://www.sans.org/reading_room/whitepapers/backup/security-considerations-"
|
||
"enterprise-level-backups_515"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml291(link)
|
||
msgid "OpenStack Security Primer"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml297(title)
|
||
msgid "Security Auditing Tools"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch012_configuration-management.xml298(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.xml310(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.xml317(para)
|
||
msgid ""
|
||
"Configuration management and security auditing tools will introduce another "
|
||
"layer of complexity into the cloud. This complexity brings additional "
|
||
"security concerns with it. 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 "OpenStack 재단"
|
||
|
||
#: ./doc/security-guide/bk_openstack-sec-guide.xml18(year)
|
||
msgid "2013"
|
||
msgstr "2013"
|
||
|
||
#: ./doc/security-guide/bk_openstack-sec-guide.xml21(releaseinfo)
|
||
msgid "current"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/bk_openstack-sec-guide.xml22(productname)
|
||
msgid "OpenStack"
|
||
msgstr "OpenStack"
|
||
|
||
#: ./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 "2013-10-17"
|
||
|
||
#: ./doc/security-guide/bk_openstack-sec-guide.xml52(para)
|
||
msgid "Havana release."
|
||
msgstr "Havana 릴리즈."
|
||
|
||
#: ./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 "VLANs"
|
||
|
||
#: ./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 plug-ins)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch032_networking-best-practices.xml53(para)
|
||
msgid "Flow analysis (via open source or third-party plug-ins)"
|
||
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 plug-in "
|
||
"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 plug-ins 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 plug-"
|
||
"ins 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 plug-ins 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 plug-in, Brocade Neutron plug-in Brocade Neutron plug-"
|
||
"in, Cisco UCS/Nexus plug-in, Cloudbase Hyper-V plug-in, Extreme Networks "
|
||
"plug-in, Juniper Networks Neutron plug-in, Linux Bridge plug-in, Mellanox "
|
||
"Neutron plug-in, MidoNet plug-in, NEC OpenFlow plug-in, Open vSwitch plug-"
|
||
"in, PLUMgrid plug-in, Ruijie Networks plug-in, Ryu OpenFlow Controller plug-"
|
||
"in, VMware NSX plug-in."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch032_networking-best-practices.xml80(title)
|
||
msgid "Networking Services Limitations"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch032_networking-best-practices.xml81(para)
|
||
msgid "OpenStack Networking has the following known limitations:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch032_networking-best-practices.xml83(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.xml84(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.xml87(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.xml90(para)
|
||
msgid ""
|
||
"<emphasis role=\"bold\">No IPv6 Support for L3 agents</emphasis> — The "
|
||
"neutron-l3-agent, used by many plug-ins 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.xml44(None)
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml47(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 environment 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.xml85(title)
|
||
msgid "Trusted Images"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml17(para)
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml150(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 filter scheduler is the default scheduler for OpenStack Compute, "
|
||
"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 "
|
||
"fulfill 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.xml50(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.xml51(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.xml52(emphasis)
|
||
msgid "Tenant Driven Whole Host Reservation"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml53(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.xml55(title)
|
||
msgid "Host Aggregates"
|
||
msgstr "호스트 집합체"
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml56(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.xml67(title)
|
||
msgid "AggregateMultiTenancyIsolation"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml68(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.xml71(title)
|
||
msgid "DifferentHostFilter"
|
||
msgstr "DifferentHostFilter"
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml72(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.xml75(title)
|
||
msgid "GroupAntiAffinityFilter"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml76(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.xml79(title)
|
||
msgid "Trusted Compute Pools"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml80(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.xml81(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.xml86(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.xml88(title)
|
||
msgid "Image Creation Process"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml89(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.xml90(para)
|
||
msgid "The first option is to obtain boot media from a trusted source."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml100(para)
|
||
msgid ""
|
||
"The second option is to use the <link href=\"http://docs.openstack.org/trunk"
|
||
"/image-guide/content/\"><citetitle>OpenStack Virtual Machine 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.xml101(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.xml102(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.xml139(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.xml140(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.xml143(title)
|
||
msgid "Image Provenance and Validation"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml144(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.xml145(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.xml146(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.xml151(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.xml162(para)
|
||
msgid "Start instance on destination host"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml163(para)
|
||
msgid "Transfer memory"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml164(para)
|
||
msgid "Stop the guest & sync disks"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml165(para)
|
||
msgid "Transfer state"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml166(para)
|
||
msgid "Start the guest"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml169(title)
|
||
msgid "Live Migration Risks"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml170(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.xml172(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.xml175(para)
|
||
msgid ""
|
||
"<emphasis>Data Exposure</emphasis> : Memory or disk transfers must be "
|
||
"handled securely."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml178(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.xml181(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.xml186(title)
|
||
msgid "Live Migration Mitigations"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml187(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.xml189(para)
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml199(title)
|
||
msgid "Disable Live Migration"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml192(para)
|
||
msgid "Isolated Migration Network"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml195(para)
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml210(title)
|
||
msgid "Encrypted Live Migration"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml200(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.xml206(title)
|
||
msgid "Migration Network"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch055_security-services-for-instances.xml207(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.xml211(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 libvirtd. 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.xml8(title)
|
||
msgid "Certification & Compliance Statements"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml9(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.xml17(title)
|
||
msgid "Commercial Standards"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml18(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.xml26(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.xml34(title)
|
||
msgid "SOC 1 (SSAE 16) / ISAE 3402"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml35(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.xml44(para)
|
||
msgid "There are two types of SOC 1 reports:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml47(para)
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml84(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.xml54(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.xml62(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.xml70(title)
|
||
msgid "SOC 2"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml71(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.xml81(para)
|
||
msgid "There are two types of SOC 2 reports:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml91(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.xml99(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.xml108(title)
|
||
msgid "SOC 3"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml109(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.xml121(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.xml128(title)
|
||
msgid "ISO 27001/2"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml129(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.xml137(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.xml143(title)
|
||
msgid "HIPAA / HITECH"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml144(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.xml151(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, does 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 "
|
||
"reputation impact."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml163(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, such as with "
|
||
"security controls and hardening, then they are subject to HIPAA fines and "
|
||
"penalties."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml174(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.xml181(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.xml187(title)
|
||
msgid "PCI-DSS"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml188(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.xml196(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.xml203(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.xml209(title)
|
||
msgid "Government Standards"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml212(title)
|
||
msgid "FedRAMP"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml213(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.xml223(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.xml229(title)
|
||
msgid "ITAR"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml230(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.xml241(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.xml247(title)
|
||
msgid "FISMA"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml248(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.xml255(para)
|
||
msgid "This process is broken apart into three primary categories:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch064_certifications-compliance-statements.xml259(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.xml267(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.xml276(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. For example, 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; for example, 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 & 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.xml118(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.xml123(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.xml128(title)
|
||
#: ./doc/security-guide/ch052_devices.xml90(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.xml9(title)
|
||
msgid "Management Interfaces"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml10(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.xml14(para)
|
||
msgid ""
|
||
"OpenStack provides several management interfaces for operators and tenants:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml16(para)
|
||
msgid "OpenStack dashboard (Horizon)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml19(para)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml80(title)
|
||
msgid "OpenStack API"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml22(para)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml113(title)
|
||
msgid "Secure Shell (SSH)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml25(para)
|
||
msgid ""
|
||
"OpenStack Management Utilities (for example, <systemitem class=\"service"
|
||
"\">nova-manage</systemitem>, <systemitem class=\"service\">glance-"
|
||
"manage</systemitem>)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml30(para)
|
||
msgid "Out-of-Band Management Interfaces (IPMI, etc.)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml35(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.xml37(title)
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml88(title)
|
||
#: ./doc/security-guide/ch026_compute.xml17(title)
|
||
#: ./doc/security-guide/ch026_compute.xml51(title)
|
||
msgid "Capabilities"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml39(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.xml42(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.xml45(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.xml48(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.xml51(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.xml58(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.xml61(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.xml64(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.xml67(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 "
|
||
"OpenStack Image Service through the dashboard. 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.xml70(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.xml76(citetitle)
|
||
msgid "Grizzly Release Notes"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml81(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 (for example, <placeholder-1/> or "
|
||
"<placeholder-2/>), language-specific libraries, or third-party tools."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml90(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.xml97(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.xml104(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.xml107(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.xml114(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.xml116(title)
|
||
msgid "Host Key Fingerprints"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml117(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.xml118(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.xml119(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.xml120(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.xml124(title)
|
||
msgid "Management Utilities"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml125(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 "
|
||
"(for example, <systemitem class=\"service\">nova</systemitem>, <systemitem "
|
||
"class=\"service\">glance</systemitem>). In addition to the standard CLI "
|
||
"client, most of the services have a management command-line utility 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.xml137(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.xml140(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.xml146(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.xml147(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.xml151(title)
|
||
msgid "Out-of-Band Management Interface"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml152(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.xml161(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.xml164(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.xml167(para)
|
||
msgid ""
|
||
"If you use a web interface to interact with the "
|
||
"<glossterm>BMC</glossterm>/IPMI, always use the SSL interface, such as 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.xml176(para)
|
||
msgid ""
|
||
"Monitor the traffic on the management network. The anomalies might be easier"
|
||
" to track than on the busier compute nodes."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml181(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.xml185(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.xml8(title)
|
||
msgid "Message Queuing Architecture"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml9(para)
|
||
msgid ""
|
||
"Message queuing services facilitate inter-process communication in "
|
||
"OpenStack. OpenStack supports these message queuing service back ends:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml14(para)
|
||
msgid "RabbitMQ"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml17(para)
|
||
msgid "Qpid"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml20(para)
|
||
msgid "ZeroMQ or 0MQ"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml23(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 a centralized or "
|
||
"decentralized pool of queue servers. ZeroMQ provides direct peer-to-peer "
|
||
"communication through TCP sockets."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml29(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 through the queue do"
|
||
" validate the contexts and tokens within the actual message payload. "
|
||
"However, you must note the expiration date of the token because tokens are "
|
||
"potentially re-playable and can authorize other services in the "
|
||
"infrastructure."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml37(para)
|
||
msgid ""
|
||
"OpenStack does not support message-level confidence, such as message "
|
||
"signing. Consequently, you must secure and authenticate the message "
|
||
"transport itself. For high-availability (HA) configurations, you must "
|
||
"perform queue-to-queue authentication and encryption."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch037_risks.xml42(para)
|
||
msgid ""
|
||
"With ZeroMQ messaging, IPC sockets are used on individual machines. Because "
|
||
"these sockets are vulnerable to attack, ensure that the cloud operator has "
|
||
"secured them."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml3(title)
|
||
#: ./doc/security-guide/ch004_book-introduction.xml122(title)
|
||
msgid "Compute"
|
||
msgstr "Compute"
|
||
|
||
#: ./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 <glossterm baseform=\"Virtual Network "
|
||
"Computing (VNC)\">VNC</glossterm> or <glossterm>SPICE</glossterm>. Below we "
|
||
"provide some details on the differences between these options."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml13(title)
|
||
msgid "Virtual Network Computer (VNC)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml14(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.xml19(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.xml22(para)
|
||
msgid ""
|
||
"The <placeholder-1/> command-line utility can return a URL for the VNC "
|
||
"console for access by the <systemitem class=\"service\">nova</systemitem> "
|
||
"Java VNC client. This requires the <systemitem class=\"service\">nova-"
|
||
"xvpvncproxy</systemitem> service to bridge from the public network to the "
|
||
"management network."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml35(para)
|
||
msgid ""
|
||
"The <systemitem class=\"service\">nova-novncproxy</systemitem>and nova-"
|
||
"xvpvncproxy services by default open public-facing ports that are token "
|
||
"authenticated."
|
||
msgstr ""
|
||
|
||
#. TODO - check if havana had this feature
|
||
#: ./doc/security-guide/ch026_compute.xml39(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.xml45(link)
|
||
msgid "Secure Connections to VNC ports"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml48(title)
|
||
msgid "Simple Protocol for Independent Computing Environments (SPICE)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml49(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.xml53(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.xml56(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.xml61(title)
|
||
msgid "Limitations"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml63(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.xml70(para)
|
||
msgid ""
|
||
"The nova-spicehtml5proxy service by default opens public-facing ports that "
|
||
"are token authenticated."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml73(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.xml76(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.xml82(link)
|
||
msgid "SPICE Console"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml83(link)
|
||
msgid "Red Hat bug 913607"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch026_compute.xml84(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.xml60(None)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml65(None)
|
||
msgid ""
|
||
"@@image: 'static/node-provisioning-pxe.png'; "
|
||
"md5=51b76c5aced74f935490b37ba921dc43"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml8(title)
|
||
msgid "Integrity Life-cycle"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml9(para)
|
||
msgid ""
|
||
"We define integrity life cycle 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.xml17(title)
|
||
msgid "Secure Bootstrapping"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml18(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.xml27(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.xml43(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.xml50(title)
|
||
msgid "Node Provisioning"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml51(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.xml68(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.xml82(para)
|
||
msgid ""
|
||
"While utilizing SSL during the PXE boot process is somewhat more "
|
||
"challenging, common PXE firmware projects, such as 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, plain text network operations."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml92(title)
|
||
msgid "Verified Boot"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml93(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.xml105(para)
|
||
msgid "Note: SHA-1 is used here because this is what the TPM chips support."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml107(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.xml127(emphasis)
|
||
msgid "Register"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml128(emphasis)
|
||
msgid "What Is Measured"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml131(emphasis)
|
||
msgid "Context"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml134(para)
|
||
msgid "PCR-00"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml135(para)
|
||
msgid ""
|
||
"Core Root of Trust Measurement (CRTM), Bios code, Host platform extensions"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml137(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml142(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml147(para)
|
||
msgid "Hardware"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml140(para)
|
||
msgid "PCR-01"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml141(para)
|
||
msgid "Host Platform Configuration"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml145(para)
|
||
msgid "PCR-02"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml146(para)
|
||
msgid "Option ROM Code "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml150(para)
|
||
msgid "PCR-03"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml151(para)
|
||
msgid "Option ROM Configuration and Data "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml152(para)
|
||
msgid "Hardware "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml155(para)
|
||
msgid "PCR-04"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml156(para)
|
||
msgid "Initial Program Loader (IPL) Code. For example, master boot record."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml158(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml163(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml168(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml173(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml179(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml184(para)
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml189(para)
|
||
msgid "Software "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml161(para)
|
||
msgid "PCR-05"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml162(para)
|
||
msgid "IPL Code Configuration and Data "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml166(para)
|
||
msgid "PCR-06"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml167(para)
|
||
msgid "State Transition and Wake Events "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml171(para)
|
||
msgid "PCR-07"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml172(para)
|
||
msgid "Host Platform Manufacturer Control "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml176(para)
|
||
msgid "PCR-08"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml177(para)
|
||
msgid "Platform specific, often Kernel, Kernel Extensions, and Drivers"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml182(para)
|
||
msgid "PCR-09"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml183(para)
|
||
msgid "Platform specific, often Initramfs"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml187(para)
|
||
msgid "PCR-10 to PCR-23"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml188(para)
|
||
msgid "Platform specific "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml194(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. For example, ensure that you have a TPM and Intel TXT "
|
||
"support. Then verify how the node hardware vendor populates the PCR values. "
|
||
"For example, 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.xml207(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.xml219(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, such as, bios, firmware, and the like, 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.xml227(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 re-provision 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.xml243(title)
|
||
msgid "Node Hardening"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml244(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.xml254(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.xml259(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.xml265(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.xml271(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.xml277(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.xml289(title)
|
||
msgid "Runtime Verification"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml290(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.xml298(title)
|
||
msgid "Intrusion Detection System"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml299(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.xml311(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.xml322(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.xml331(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.xml339(link)
|
||
msgid "OSSEC"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml343(link)
|
||
msgid "Samhain"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml348(link)
|
||
msgid "Tripwire"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml352(link)
|
||
msgid "AIDE"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml355(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 plug-in mechanism to enable different "
|
||
"technologies via the Neutron API. This plug-in 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.xml363(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.xml369(para)
|
||
msgid ""
|
||
"There are a few important security considerations for network and host-based"
|
||
" intrusion detection systems."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch013_node-bootstrapping.xml373(para)
|
||
msgid ""
|
||
"It is important to consider the placement of the Network IDS on the cloud "
|
||
"(for example, 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.xml385(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.xml88(title)
|
||
msgid "Authentication Configuration Example - Qpid"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml89(para)
|
||
msgid "For configuration information see:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml91(link)
|
||
msgid "Apache Qpid Authentication"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml94(link)
|
||
msgid "Apache Qpid Authorization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml99(title)
|
||
msgid "OpenStack Service Configuration - Qpid"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml108(para)
|
||
msgid ""
|
||
"Optionally, if using SASL with Qpid specify the SASL mechanisms in use by "
|
||
"adding:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml114(title)
|
||
msgid "Message Queue Process Isolation & Policy"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch038_transport-security.xml115(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.xml116(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.xml119(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.xml120(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.xml124(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.xml125(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.xml129(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=3589a1ef10ea2bbe189ca90e3c932df2"
|
||
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.xml113(None)
|
||
#: ./doc/security-guide/ch004_book-introduction.xml118(None)
|
||
msgid ""
|
||
"@@image: 'static/marketecture-diagram.png'; "
|
||
"md5=4ab13a64f80c210be3120abc5c7aee8a"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml8(title)
|
||
msgid "Introduction to OpenStack"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml9(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.xml16(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.xml27(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.xml32(title)
|
||
msgid "Cloud types"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml33(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.xml42(title)
|
||
msgid "Public cloud"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml43(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.xml61(title)
|
||
msgid "Private cloud"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml62(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, such as 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.xml72(title)
|
||
msgid "Community cloud"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml73(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. For example, 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.xml83(title)
|
||
msgid "Hybrid cloud"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml84(para)
|
||
msgid ""
|
||
"A hybrid cloud is defined by NIST as a composition of two or more distinct "
|
||
"cloud infrastructures, such as private, community, or public, that remain "
|
||
"unique entities, but are bound together by standardized or proprietary "
|
||
"technology that enables data and application portability, such as 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.xml96(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.xml104(title)
|
||
msgid "OpenStack service overview"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml105(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.xml123(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.xml128(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.xml131(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.xml133(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.xml137(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.xml144(title)
|
||
#: ./doc/security-guide/ch027_storage.xml8(title)
|
||
msgid "Object Storage"
|
||
msgstr "오브젝트 저장소"
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml145(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.xml151(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.xml155(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.xml161(title)
|
||
msgid "Block Storage"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml162(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.xml167(para)
|
||
msgid ""
|
||
"Security considerations for block storage are similar to that of object "
|
||
"storage."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml171(title)
|
||
msgid "OpenStack Networking"
|
||
msgstr "OpenStack 네트워킹"
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml172(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.xml180(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.xml187(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.xml195(title)
|
||
msgid "Identity Service"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml196(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.xml201(para)
|
||
msgid ""
|
||
"Security concerns here pertain to trust in authentication, management of "
|
||
"authorization tokens, and secure communication."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml206(title)
|
||
msgid "Image Service"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml207(para)
|
||
msgid ""
|
||
"The OpenStack Image Service (Glance) provides disk image management "
|
||
"services. The Image Service provides image discovery, registration, and "
|
||
"delivery services to the Compute service, as needed."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml211(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.xml216(title)
|
||
msgid "Other supporting technology"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch004_book-introduction.xml217(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.xml226(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.xml230(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 & 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.xml53(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.xml108(None)
|
||
#: ./doc/security-guide/ch027_storage.xml113(None)
|
||
msgid ""
|
||
"@@image: 'static/swift_network_diagram-2.png'; "
|
||
"md5=69f8effe3f5d0f3cbccfb8c5a5dd299e"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml9(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.xml14(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.xml22(para)
|
||
msgid ""
|
||
"For this document the components will be grouped into the following primary "
|
||
"groups:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml26(para)
|
||
msgid "Proxy services"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml29(para)
|
||
msgid "Auth services"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml32(para)
|
||
msgid "Storage services"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml35(para)
|
||
#: ./doc/security-guide/ch027_storage.xml159(td)
|
||
msgid "Account service"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml38(para)
|
||
#: ./doc/security-guide/ch027_storage.xml164(td)
|
||
msgid "Container service"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml41(para)
|
||
#: ./doc/security-guide/ch027_storage.xml169(td)
|
||
msgid "Object service"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml47(title)
|
||
msgid ""
|
||
"An example diagram from the OpenStack Object Storage Administration Guide "
|
||
"(2013)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml58(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.xml64(title)
|
||
msgid "First thing to secure – the network"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml65(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.xml73(para)
|
||
msgid ""
|
||
"None of these use any type of encryption or authentication at this "
|
||
"layer/tier."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml76(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.xml83(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.xml87(para)
|
||
msgid ""
|
||
"This necessitates that the Proxy service nodes have dual interfaces "
|
||
"(physical or virtual):"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml91(para)
|
||
msgid "One as a \"public\" interface for consumers to reach"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml95(para)
|
||
msgid "Another as a \"private\" interface with access to the storage nodes"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml99(para)
|
||
msgid "The following figure demonstrates one possible network architecture."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml102(title)
|
||
msgid "Object storage network architecture with a management node (OSAM)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml120(title)
|
||
msgid "Securing services – general"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml122(title)
|
||
msgid "Service runas user"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml123(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.xml129(title)
|
||
msgid "File permissions"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml130(para)
|
||
msgid ""
|
||
"/etc/swift contains information about the ring topology and environment "
|
||
"configuration. The following permissions are recommended:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml138(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.xml146(title)
|
||
msgid "Securing storage services"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml147(para)
|
||
msgid ""
|
||
"The following are the default listening ports for the various storage "
|
||
"services:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml152(td)
|
||
msgid "Service Name"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml153(td)
|
||
msgid "Port"
|
||
msgstr "포트"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml154(td)
|
||
msgid "Type"
|
||
msgstr "형식"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml160(td)
|
||
msgid "6002"
|
||
msgstr "6002"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml161(td)
|
||
#: ./doc/security-guide/ch027_storage.xml166(td)
|
||
#: ./doc/security-guide/ch027_storage.xml171(td)
|
||
#: ./doc/security-guide/ch027_storage.xml176(td)
|
||
msgid "TCP"
|
||
msgstr "TCP"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml165(td)
|
||
msgid "6001"
|
||
msgstr "6001"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml170(td)
|
||
msgid "6000"
|
||
msgstr "6000"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml174(td)
|
||
msgid "Rsync"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml175(td)
|
||
msgid "873"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml180(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.xml188(title)
|
||
msgid "Object storage \"account\" terminology"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml189(para)
|
||
msgid ""
|
||
"An Object Storage \"Account\" is not a user account or credential. The "
|
||
"following explains the relations:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml195(td)
|
||
msgid "OpenStack Object Storage Account"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml196(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.xml205(td)
|
||
msgid "OpenStack Object Storage Containers"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml206(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.xml212(td)
|
||
msgid "OpenStack Object Storage Objects"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml213(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.xml221(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 -> buckets (Containers) which each hold zero or more -> 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.xml231(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.xml242(title)
|
||
msgid "Securing proxy services"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml243(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.xml253(title)
|
||
msgid "Use SSL/TLS"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml254(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, "
|
||
"such as 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.xml272(para)
|
||
msgid "Modify file <filename>/etc/apache2/envvars</filename> with"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml277(para)
|
||
msgid "An alternative is to modify your Apache conf file with"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml281(para)
|
||
msgid ""
|
||
"Create a <filename>swift</filename> directory in your Apache document root:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml284(para)
|
||
msgid ""
|
||
"Create the file <filename>$YOUR_APACHE_DOC_ROOT/swift/proxy-"
|
||
"server.wsgi</filename>:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml290(title)
|
||
msgid "HTTP listening port"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml291(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.xml311(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.xml316(title)
|
||
msgid "Load balancer"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml317(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.xml322(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.xml330(para)
|
||
msgid ""
|
||
"The authentication service you use, such as Keystone or 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.xml339(title)
|
||
msgid "Object storage authentication"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml340(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.xml348(title)
|
||
msgid "Keystone"
|
||
msgstr "Keystone"
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml349(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.xml356(title)
|
||
msgid "SWAuth"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml357(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.xml367(title)
|
||
msgid "Other notable items"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch027_storage.xml368(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.xml373(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.xml8(title)
|
||
msgid "Introduction to Case Studies"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml9(para)
|
||
msgid ""
|
||
"This guide refers to two running case studies, which are introduced here and"
|
||
" referred to at the end of each chapter."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml12(title)
|
||
msgid "Case Study : Alice the private cloud builder"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml13(para)
|
||
msgid ""
|
||
"Alice deploys 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 must have no direct"
|
||
" access to the internet: its API endpoints, compute instances, and other "
|
||
"resources must be exposed to only 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. For example, the "
|
||
"authentication and logging services."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml25(title)
|
||
msgid "Case Study : Bob the public cloud provider"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch006_introduction-to-case-studies.xml26(para)
|
||
msgid ""
|
||
"Bob is a lead architect for a company that deploys a large greenfield public"
|
||
" cloud. This cloud provides IaaS for the masses and enables 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 ""
|
||
|
||
#. 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.xml101(None)
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml106(None)
|
||
msgid ""
|
||
"@@image: 'static/services-protocols-ports.png'; "
|
||
"md5=fb1e9f47d969127b7a5ca683d38cfe20"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml8(title)
|
||
msgid "System Documentation Requirements"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml9(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.xml18(title)
|
||
msgid "System Roles & Types"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml19(para)
|
||
msgid ""
|
||
"The two broadly defined types of nodes that generally make up an OpenStack "
|
||
"installation are:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml23(para)
|
||
msgid ""
|
||
"Infrastructure nodes. 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.xml30(para)
|
||
msgid ""
|
||
"Compute, storage, or other resource nodes. Provide storage capacity or "
|
||
"virtual machines for your cloud."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml37(title)
|
||
msgid "System Inventory"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml38(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.xml48(title)
|
||
msgid "Hardware Inventory"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml49(para)
|
||
msgid ""
|
||
"Clouds without stringent compliance requirements for written documentation "
|
||
"might benefit from having a Configuration Management Database "
|
||
"(<glossterm>CMDB</glossterm>). CMDBs are normally used for hardware asset "
|
||
"tracking and overall life-cycle management. By leveraging a CMDB, an "
|
||
"organization can quickly identify cloud infrastructure hardware. For "
|
||
"example, compute nodes, storage nodes, and network devices that exist on the"
|
||
" network but that might not be adequately protected and/or forgotten. "
|
||
"OpenStack provisioning system might provide some CMDB-like functions "
|
||
"especially if auto-discovery features of hardware attributes are available."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml63(title)
|
||
msgid "Software Inventory"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml64(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.xml76(title)
|
||
msgid "Network Topology"
|
||
msgstr "네트워크 토폴로지"
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml77(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.xml88(title)
|
||
msgid "Services, Protocols and Ports"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml89(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. Consider the following table:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch008_system-roles-types.xml109(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.xml9(para)
|
||
msgid ""
|
||
"Horizon is the OpenStack dashboard that provides users a self-service portal"
|
||
" to provision their own resources within the limits set by administrators. "
|
||
"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.xml14(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.xml21(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.xml26(title)
|
||
msgid "Basic Web Server Configuration"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml27(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.xml32(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.xml39(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.xml44(title)
|
||
msgid "HTTPS"
|
||
msgstr "HTTPS"
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml45(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.xml50(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.xml54(title)
|
||
msgid "HTTP Strict Transport Security (HSTS)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml55(para)
|
||
msgid "It is highly recommended to use HTTP Strict Transport Security (HSTS)."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml57(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.xml63(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.xml68(title)
|
||
msgid "Front end Caching"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml69(para)
|
||
msgid ""
|
||
"Since dashboard is rendering dynamic content passed directly from OpenStack "
|
||
"API requests, we do not recommend front end 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.xml76(title)
|
||
msgid "Domain Names"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml77(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 <uri>openstack.example.org</uri>. 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 name server maintenance."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml85(para)
|
||
msgid ""
|
||
"We strongly recommend deploying horizon to a <emphasis>second-level "
|
||
"domain</emphasis>, such as <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.xml93(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, such as scripts, images, or uploads of any kind, even if "
|
||
"the user-generated content is on a different subdomain. This approach is "
|
||
"used by most major web presences, such as googleusercontent.com, fbcdn.com, "
|
||
"github.io, and twimg.com, to ensure that user generated content stays "
|
||
"separate from cookies and security tokens."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml103(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.xml111(title)
|
||
msgid "Static Media"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml112(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.xml117(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.xml120(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 compression entirely. Online compression dependencies "
|
||
"(less, nodejs) should not be installed on production machines."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml134(title)
|
||
msgid "Secret Key"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml135(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.xml144(title)
|
||
msgid "Session Backend"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml145(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.xml156(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 trade-offs."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml163(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.xml168(title)
|
||
msgid "Allowed Hosts"
|
||
msgstr "허용된 호스트"
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml169(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. Wild card domains should be avoided."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml174(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.xml179(title)
|
||
msgid "Cookies"
|
||
msgstr "쿠키"
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml180(para)
|
||
msgid "Session Cookies should be set to HTTPONLY:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml183(para)
|
||
msgid ""
|
||
"Never configure CSRF or session cookies to have a wild card 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.xml191(title)
|
||
msgid "Password Auto Complete"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml192(para)
|
||
msgid ""
|
||
"We recommend that implementers do not change the default password auto "
|
||
"complete 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.xml200(title)
|
||
msgid "Cross Site Request Forgery (CSRF)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml201(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.xml204(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.xml213(title)
|
||
msgid "Cross Site Scripting (XSS)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml214(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.xml218(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 auto escape is turned off, and any JavaScript which might evaluate "
|
||
"improperly escaped data."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml227(title)
|
||
msgid "Cross Origin Resource Sharing (CORS)"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml228(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.xml233(para)
|
||
msgid "Never allow the wild card origin."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml236(title)
|
||
msgid "Horizon Image Upload"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml237(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.xml244(title)
|
||
msgid "Upgrading"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml245(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.xml253(title)
|
||
msgid "Debug"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch025_web-dashboard.xml254(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 plug-ins are specific to a vendor or technology, whereas others are "
|
||
"more DIY solutions around filesystems such as LVM or ZFS. Methods to "
|
||
"securely destroy data will vary from one 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 "
|
||
"Block Storage plug-in takes the responsibility to override previously "
|
||
"written blocks before handing them to users. It is important to review what "
|
||
"assurances your chosen volume 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 plug-in."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch046_data-residency.xml121(para)
|
||
msgid ""
|
||
"The libvirt plug-in for compute may maintain ephemeral storage directly on a"
|
||
" filesystem, or in LVM. Filesystem storage generally will not overwrite data"
|
||
" when it is removed, although there is a guarantee that dirty extents are "
|
||
"not provisioned to users."
|
||
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.xml8(title)
|
||
msgid "Identity"
|
||
msgstr "인증"
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml9(para)
|
||
msgid ""
|
||
"The OpenStack Identity Service (Keystone) supports multiple methods of "
|
||
"authentication, including username & 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.xml14(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.xml19(title)
|
||
msgid "Authentication"
|
||
msgstr "인증"
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml21(title)
|
||
msgid "Invalid Login Attempts"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml22(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.xml27(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.xml31(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.xml40(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.xml46(title)
|
||
msgid "Multi-factor Authentication"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml47(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.xml52(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.xml58(title)
|
||
msgid "Authentication Methods"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml60(title)
|
||
msgid "Internally Implemented Authentication Methods"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml61(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.xml66(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.xml73(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.xml76(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.xml85(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.xml91(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.xml101(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.xml105(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.xml112(title)
|
||
msgid "External Authentication Methods"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml113(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.xml122(para)
|
||
msgid "These include:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml125(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.xml130(para)
|
||
msgid ""
|
||
"Multi-factor authentication: The authentication service requires the user to"
|
||
" provide information based on something they have, such as a one-time "
|
||
"password token or X.509 certificate, and something they know, such as a "
|
||
"password."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml137(para)
|
||
msgid "Kerberos"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml143(title)
|
||
msgid "Authorization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml144(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.xml151(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.xml157(title)
|
||
msgid "Establish Formal Access Control Policies"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml158(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.xml171(title)
|
||
msgid "Service Authorization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml172(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.xml179(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.xml184(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 user names 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.xml194(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.xml198(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.xml204(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.xml218(title)
|
||
msgid "Administrative Users"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml219(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 multi factor authentication for network access to "
|
||
"privileged accounts."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml228(title)
|
||
msgid "End Users"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml229(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.xml236(title)
|
||
msgid "Policies"
|
||
msgstr "Policies"
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml237(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.xml242(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.xml247(para)
|
||
msgid "Below is a snippet of the Block Storage service policy.json file."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml250(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.xml258(title)
|
||
msgid "Tokens"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml259(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.xml269(para)
|
||
msgid ""
|
||
"The following example shows a PKI token. Note that, in practice, the token "
|
||
"id value is about 3500 bytes. We shorten it in this example."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml273(para)
|
||
msgid ""
|
||
"Note that the token is often passed within the structure of a larger context"
|
||
" of an 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.xml278(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.xml285(title)
|
||
msgid "Future"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch024_authentication.xml286(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.xml295(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.xml301(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 & Recovery"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch015_case-studies-management.xml25(para)
|
||
msgid "SLA & 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=1de9169834b34c83f574f2a1225b27f0"
|
||
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=135806775939d9e5e750264d8a5fe8de"
|
||
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 plug-"
|
||
"ins 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 plug-ins 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 plug-in.</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 plug-in 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 & 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 Storage 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 & 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 labeled 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 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_networking_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 unforeseen 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 "Quotas"
|
||
|
||
#: ./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.xml131(None)
|
||
#: ./doc/security-guide/ch052_devices.xml134(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 code base, "
|
||
"using compiler hardening, and using mandatory access controls, such as "
|
||
"sVirt, SELinux, or AppArmor."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml47(title)
|
||
msgid "Minimizing the Qemu Code base"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml48(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.xml54(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.xml57(title)
|
||
msgid "Compiler Hardening"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml58(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.xml59(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.xml61(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.xml64(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.xml67(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.xml70(para)
|
||
msgid ""
|
||
"<emphasis>Position Independent Executable (PIE)</emphasis>: Produces a "
|
||
"position independent executable, which is necessary for ASLR. "
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml73(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.xml76(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.xml79(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.xml80(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.xml82(para)
|
||
msgid ""
|
||
"DEB packages: <link "
|
||
"href=\"http://wiki.debian.org/HardeningWalkthrough\">Hardening "
|
||
"Walkthrough</link>"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml85(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.xml91(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.xml95(title)
|
||
msgid "sVirt: SELinux + Virtualization"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml96(para)
|
||
msgid ""
|
||
"With unique kernel-level architecture and National Security Agency (NSA) "
|
||
"developed security mechanisms, KVM provides foundational isolation "
|
||
"technologies for multi tenancy. 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.xml105(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.xml107(para)
|
||
msgid ""
|
||
"<emphasis role=\"bold\">Hypervisor threats</emphasis> A compromised "
|
||
"application running within a virtual machine attacks the hypervisor to "
|
||
"access underlying resources. For example, 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.xml117(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.xml129(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.xml137(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.xml139(title)
|
||
msgid "Labels and Categories"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml140(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.xml146(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.xml147(para)
|
||
msgid "This example shows the sVirt category identifier:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml152(title)
|
||
msgid "Booleans"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml153(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.xml154(para)
|
||
msgid ""
|
||
"Red Hat Enterprise Linux-based KVM deployments utilize the following sVirt "
|
||
"booleans:"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml161(emphasis)
|
||
msgid "sVirt SELinux Boolean"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml162(emphasis)
|
||
msgid " Description"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml165(para)
|
||
msgid "virt_use_common"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml166(para)
|
||
msgid "Allow virt to use serial/parallel communication ports."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml169(para)
|
||
msgid "virt_use_fusefs"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml170(para)
|
||
msgid "Allow virt to read FUSE mounted files."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml173(para)
|
||
msgid "virt_use_nfs"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml174(para)
|
||
msgid "Allow virt to manage NFS mounted files."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml177(para)
|
||
msgid "virt_use_samba"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml178(para)
|
||
msgid "Allow virt to manage CIFS mounted files."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml181(para)
|
||
msgid "virt_use_sanlock"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml182(para)
|
||
msgid "Allow confined virtual guests to interact with the sanlock."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml185(para)
|
||
msgid "virt_use_sysfs"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml186(para)
|
||
msgid "Allow virt to manage device configuration (PCI)."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml189(para)
|
||
msgid "virt_use_usb"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml190(para)
|
||
msgid "Allow virt to use USB devices."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml193(para)
|
||
msgid "virt_use_xserver"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch052_devices.xml194(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.xml149(title)
|
||
msgid "Stud"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml13(link)
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml188(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 recommended configuration settings for enabling"
|
||
" SSL in some of the more popular web servers/SSL terminators. 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.xml26(para)
|
||
msgid ""
|
||
"Before we delve into the configurations, we briefly discuss the ciphers' "
|
||
"configuration element and its format. A more exhaustive treatment on "
|
||
"available ciphers and the OpenSSL cipher list format can be found at: <link "
|
||
"href=\"https://www.openssl.org/docs/apps/ciphers.html\">ciphers</link>."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml30(para)
|
||
msgid "or"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml34(para)
|
||
msgid ""
|
||
"Cipher string options are separated by \":\", while \"!\" provides negation "
|
||
"of the immediately following element. Element order indicates preference "
|
||
"unless overridden by qualifiers such as HIGH. Let us take a closer look at "
|
||
"the elements in the above sample strings."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml37(code)
|
||
msgid "kEECDH:kEDH"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml39(para)
|
||
msgid ""
|
||
"Ephemeral Elliptic Curve Diffie-Hellman (abbreviated as EECDH and ECDHE)."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml40(para)
|
||
msgid ""
|
||
"Ephemeral Diffie-Hellman (abbreviated either as EDH or DHE) uses prime field"
|
||
" groups."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml41(para)
|
||
msgid ""
|
||
"Both approaches provide <link "
|
||
"href=\"http://en.wikipedia.org/wiki/Forward_secrecy\">Perfect Forward "
|
||
"Secrecy (PFS)</link>."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml42(para)
|
||
msgid ""
|
||
"Ephemeral Elliptic Curves require the server to be configured with a named "
|
||
"curve, and provide better security than prime field groups and at lower "
|
||
"computational cost. However, prime field groups are more widely implemented,"
|
||
" and thus typically both are included in list."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml46(code)
|
||
msgid "kRSA"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml48(para)
|
||
msgid ""
|
||
"Cipher suites using the <link "
|
||
"href=\"http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29\">RSA</link> "
|
||
"exchange, authentication or either respectively."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml52(code)
|
||
msgid "HIGH"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml54(para)
|
||
msgid ""
|
||
"Selects highest possible security cipher in the negotiation phase. These "
|
||
"typically have keys of length 128 bits or longer."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml58(code)
|
||
msgid "!RC4"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml60(para)
|
||
msgid ""
|
||
"No RC4. RC4 has flaws in the context of TLS/SSL V3. See <link "
|
||
"href=\"cr.yp.to/streamciphers/rc4biases-20130708.pdf\"> On the Security of "
|
||
"RC4 in TLS and WPA</link>."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml64(code)
|
||
msgid "!MD5"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml66(para)
|
||
msgid ""
|
||
"No MD5. MD5 is not collision resistant, and thus not acceptable for Message "
|
||
"Authentication Codes (MAC) or signatures."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml70(code)
|
||
msgid "!aNULL:!eNULL"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml72(para)
|
||
msgid "Disallows clear text"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml76(code)
|
||
msgid "!EXP"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml78(para)
|
||
msgid ""
|
||
"Disallows export encryption algorithms, which by design tend to were weak, "
|
||
"typically using 40 and 56 bit keys."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml79(para)
|
||
msgid ""
|
||
"US Export restrictions on cryptography systems have been lifted and no "
|
||
"longer need to be supported."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml83(code)
|
||
msgid "!LOW:!MEDIUM"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml85(para)
|
||
msgid ""
|
||
"Disallows low (keys 56 or 64 bits long) and medium (128 bit long keys) "
|
||
"ciphers because of their vulnerability to brute force attacks (example "
|
||
"2-DES). This constraint leaves acceptable Triple Data Encryption Standard "
|
||
"(Triple DES) also known as Triple Data Encryption Algorithm (TDEA) and the "
|
||
"Advanced Encryption Standard (AES), each of which has keys greater than "
|
||
"equal to 128 bits and thus more secure."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml89(code)
|
||
msgid "Protocols"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml91(para)
|
||
msgid ""
|
||
"Protocols are enabled/disabled through SSL_CTX_set_options. We recommend "
|
||
"disabling SSLv2 and enabling TLS or SSLv3 (which was standardised as TLS "
|
||
"with a few changes)."
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml96(title)
|
||
msgid "Pound - with AES-NI acceleration"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml150(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.xml189(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.xml206(title)
|
||
msgid "Apache"
|
||
msgstr "아파치"
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml232(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.xml257(title)
|
||
msgid "HTTP Strict Transport Security"
|
||
msgstr ""
|
||
|
||
#: ./doc/security-guide/ch020_ssl-everywhere.xml258(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.xml261(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 an 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 "Sungjin Gang <ujuc@ujuc.kr>, 2012-2013.\nYeonki Choi < >, 2013.\nJay Lee <hyangii@gmail.com>, 2013"
|