# # Translators: msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" "POT-Creation-Date: 2014-03-18 06:30+0000\n" "PO-Revision-Date: 2014-03-18 06:31+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: Catalan (http://www.transifex.com/projects/p/openstack/language/ca/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Language: ca\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #. When image changes, this message will be marked fuzzy or untranslated for #. you. #. It doesn't matter what you translate it to: it's not used at all. #: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml30(None) #: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml33(None) msgid "@@image: 'static/group.png'; md5=aec1f0af66d29c1a5d1f174df1f12812" msgstr "" #: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml3(title) msgid "Why and how we wrote this book" msgstr "" #: ./doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml4(para) msgid "" "As OpenStack adoption continues to grow and the product matures, security " "has become a priority. The OpenStack Security Group has recognized the need " "for a comprehensive and authoritative security guide. The OpenStack Security Guide 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 OpenStack Operations " "Guide 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 "Bryan D. Payne, 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 "Robert Clark, 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 "Keith Basil, 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 "Cody Bunch, 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 "Malini Bhandaru, 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 "" "Gregg Tally, 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 "Eric Lopez, 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 "Shawn Wells, 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 "Ben de Bont, 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 "" "Nathanael Burton, 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 "Eric Windisch, 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 "Andrew Hay, 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 http://www.booksprints.net." 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 "Rodney D. Beede, 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: http://wiki.openstack.org/Documentation/HowTo." 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, \"Guide to Security for Full Virtualization " "Technologies\"." 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:Team Expertise 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 OpenStack " "Hypervisor Support Matrix 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 how 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 "" "\"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\"" 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 (DAC) restricts access " "to file system objects based on Access Control Lists (ACLs) that include the standard " "UNIX permissions for user, group and others. Access control mechanisms also " "protect IPC objects from unauthorized access." msgstr "" #: ./doc/security-guide/ch051_vss-intro.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 "Descripció" #: ./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 "" "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 use of LXC in " "Nova." 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 "" #: ./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 "" #: ./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 "" #: ./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 (CA) - 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 "Resum" #: ./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 " "OpenStack Announce mailing list. 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: https://wiki.openstack.org/wiki/Vulnerability_Management" 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 https://launchpad.net/ossn/" msgstr "" #: ./doc/security-guide/ch012_configuration-management.xml33(para) msgid "" "OpenStack releases security information through two channels. " "" 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 " "nova.conf 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: Chef and " "Puppet. A non-exhaustive listing of tools in this " "space is provided below:" msgstr "" #: ./doc/security-guide/ch012_configuration-management.xml223(para) msgid "Chef" msgstr "" #: ./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.xml67(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.xml43(title) #: ./doc/security-guide/ch026_compute.xml80(title) #: ./doc/security-guide/ch058_forensicsincident-response.xml43(title) msgid "References" msgstr "" #: ./doc/security-guide/ch012_configuration-management.xml279(para) msgid "" "OpenStack Operations Guide on backup and recovery" 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, SCAP 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 "Fundació OpenStack" #: ./doc/security-guide/bk_openstack-sec-guide.xml18(year) msgid "2013" msgstr "2013" #: ./doc/security-guide/bk_openstack-sec-guide.xml21(releaseinfo) msgid "havana" 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 "Els drets d'autor s'omplen per la plantilla." #: ./doc/security-guide/bk_openstack-sec-guide.xml31(para) msgid "" "This book provides best practices and conceptual information about securing " "an OpenStack cloud." msgstr "" #: ./doc/security-guide/bk_openstack-sec-guide.xml38(date) msgid "2013-12-02" msgstr "" #: ./doc/security-guide/bk_openstack-sec-guide.xml42(para) msgid "Chapter on Object Storage added." msgstr "" #: ./doc/security-guide/bk_openstack-sec-guide.xml48(date) msgid "2013-10-17" msgstr "" #: ./doc/security-guide/bk_openstack-sec-guide.xml52(para) msgid "Havana release." msgstr "" #: ./doc/security-guide/bk_openstack-sec-guide.xml58(date) msgid "2013-07-02" msgstr "" #: ./doc/security-guide/bk_openstack-sec-guide.xml62(para) msgid "Initial creation..." msgstr "" #: ./doc/security-guide/ch065_privacy.xml3(title) msgid "Privacy" msgstr "" #: ./doc/security-guide/ch065_privacy.xml4(para) msgid "" "Privacy is an increasingly important element of a compliance program. " "Businesses are being held to a higher standard by their customers, who have " "increased interest in understanding how their data is treated from a privacy" " perspective." msgstr "" #: ./doc/security-guide/ch065_privacy.xml5(para) msgid "" "An OpenStack deployment will likely need to demonstrate compliance with an " "organization’s Privacy Policy, with the U.S. – E.U. Safe Harbor framework, " "the ISO/IEC 29100:2011 privacy framework or with other privacy-specific " "guidelines. In the U.S. the AICPA has defined" " 10 privacy areas of focus, 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 \"Guide to Protecting the Confidentiality of Personally " "Identifiable Information (PII).\" This guide steps through the " "process of protecting:" msgstr "" #: ./doc/security-guide/ch065_privacy.xml8(para) msgid "" "\"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\"" 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 gateway that connects one or more private L2 " "networks to a shared external 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 gateway 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 Plugin, Brocade Neutron Plugin Brocade Neutron Plugin," " Cisco UCS/Nexus Plugin, Cloudbase Hyper-V Plugin, Extreme Networks Plugin, " "Juniper Networks Neutron Plugin, Linux Bridge Plugin, Mellanox Neutron " "Plugin, MidoNet Plugin, NEC OpenFlow Plugin, Open vSwitch Plugin, PLUMgrid " "Plugin, Ruijie Networks Plugin, Ryu OpenFlow Controller Plugin, VMware NSX " "plugin" msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml72(para) msgid "" "For a more detailed comparison of all features provided by plug-ins as of " "the Folsom release, see Sebastien Han's " "comparison." msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml75(title) msgid "Networking Services Limitations" msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml76(para) msgid "OpenStack Networking has the following known limitations:" msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml78(para) msgid "" "Overlapping IP addresses — If nodes that " "run either neutron-l3-agent or neutron-dhcp-" "agent use overlapping IP addresses, those nodes must use Linux " "network namespaces. By default, the DHCP and L3 agents use Linux network " "namespaces. However, if the host does not support these namespaces, run the " "DHCP and L3 agents on different hosts." msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml79(para) msgid "" "If network namespace support is not present, a further limitation of the L3 " "Agent is that only a single logical router is supported." msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml82(para) msgid "" "Multi-Host DHCP-agent — OpenStack " "Networking supports multiple l3-agent and dhcp-agents with load balancing. " "However, tight coupling of the location of the virtual machine is not " "supported." msgstr "" #: ./doc/security-guide/ch032_networking-best-practices.xml85(para) msgid "" "No IPv6 Support for L3 agents — 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.xml47(None) #: ./doc/security-guide/ch055_security-services-for-instances.xml50(None) msgid "" "@@image: 'static/filteringWorkflow1.png'; " "md5=c144af5cbdee1bd17a7bde0bea5b5fe7" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml3(title) msgid "Security Services for Instances" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml4(para) msgid "" "One of the virtues of running instances in a virtualized 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.xml88(title) msgid "Trusted Images" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml17(para) #: ./doc/security-guide/ch055_security-services-for-instances.xml153(title) msgid "Instance Migrations" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml21(title) msgid "Entropy To Instances" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml22(para) msgid "" "We consider entropy to refer to the quality and source of random data that " "is available to an instance. Cryptographic technologies typically rely " "heavily on randomness, requiring a high quality pool of entropy to draw " "from. It is typically hard for a virtual machine to get enough entropy to " "support these operations. Entropy starvation can manifest in instances as " "something seemingly unrelated for example, slow boot times because the " "instance is waiting for ssh key generation. Entropy starvation may also " "motivate users to employ poor quality entropy sources from within the " "instance, making applications running in the cloud less secure overall." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml23(para) msgid "" "Fortunately, a cloud architect may address these issues by providing a high " "quality source of entropy to the cloud instances. This can be done by having" " enough hardware random number generators (HRNG) in the cloud to support the" " instances. In this case, \"enough\" is somewhat domain specific. For " "everyday operations, a modern HRNG is likely to produce enough entropy to " "support 50-100 compute nodes. High bandwidth HRNGs, such as the RdRand " "instruction available with Intel Ivy Bridge and newer processors could " "potentially handle more nodes. For a given cloud, an architect needs to " "understand the application requirements to ensure that sufficient entropy is" " available." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml24(para) msgid "" "Once the entropy is available in the cloud, the next step is getting that " "entropy into the instances. Tools such as the entropy gathering daemon " "(EGD) 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 nova-scheduler which determines how to dispatch compute and " "volume requests." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml30(para) msgid "" "The default nova scheduler in Grizzly is the Filter Scheduler, although " "other schedulers exist (see the section Scheduling in the " "OpenStack Configuration Reference). 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.xml53(para) msgid "" "The use of scheduler filters may be used to segregate customers, data, or " "even discard machines of the cloud that cannot be attested as secure. This " "generally applies to all OpenStack projects offering a scheduler. When " "building a cloud, you may choose to implement scheduling filters for a " "variety of security-related purposes." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml54(para) msgid "" "Below we highlight a few of the filters that may be useful in a security " "context, depending on your requirements, the full set of filter " "documentation is documented in the Filter Scheduler section of the OpenStack" " Configuration Reference." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml55(emphasis) msgid "Tenant Driven Whole Host Reservation" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml56(para) msgid "" "There currently exists a blueprint for whole host reservation - This would allow " "a tenant to exclusively reserve hosts for only it's instances, incurring " "extra costs." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml58(title) msgid "Host Aggregates" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml59(para) msgid "" "While not a filter in themselves, host aggregates allow administrators to " "assign key-value pairs to groups of machines. This allows cloud " "administrators, not users, to partition up their compute host resources. " "Each node can have multiple aggregates (see the Host Aggregates section of the OpenStack" " Configuration Reference for more information on creating and " "managing aggregates)." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml70(title) msgid "AggregateMultiTenancyIsolation" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml71(para) msgid "" "Isolates tenants to specific host aggregates. If a host is in an aggregate " "that has the metadata key filter_tenant_id it will only " "create instances from that tenant (or list of tenants). A host can be in " "multiple aggregates. If a host does not belong to an aggregate with the " "metadata key, it can create instances from all tenants." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml74(title) msgid "DifferentHostFilter" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml75(para) msgid "" "Schedule the instance on a different host from a set of instances. To take " "advantage of this filter, the requester must pass a scheduler hint, using " "different_host as the key and a list of instance uuids as" " the value. This filter is the opposite of the " "SameHostFilter." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml78(title) msgid "GroupAntiAffinityFilter" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml79(para) msgid "" "The GroupAntiAffinityFilter ensures that each instance in a group is on a " "different host. To take advantage of this filter, the requester must pass a " "scheduler hint, using group as the key and a list of " "instance uuids as the value." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml82(title) msgid "Trusted Compute Pools" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml83(para) msgid "" "There exists a scheduler filter which integrates with the Open Attestation" " Project (OATS) to define scheduler behavior according to the " "attestation of PCRs received from a system using Intel TXT." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml84(para) msgid "" "It is unclear if this feature is compatible with AMD's similar SEM, although" " the OpenAttestation agent relies on the vendor-agnostic TrouSerS library." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml89(para) msgid "" "With regards to images, users will be working with pre-installed images or " "images that they upload themselves. In both cases, users will want to ensure" " that the image they are ultimately running has not been tampered with. This" " requires some source of truth such as a checksum for the known good version" " of an image as well as verification of the running image. This section " "describes the current best practices around image handling, while also " "calling out some of the existing gaps in this space." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml91(title) msgid "Image Creation Process" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml92(para) msgid "" "The OpenStack Documentation provides guidance on how to create and upload an" " image to Glance. Additionally it is assumed that you have a process by " "which you install and harden operating systems. Thus, the following items " "will provide additional guidance on how to ensure your images are built " "securely prior to upload. There are a variety of options for obtaining " "images. Each has specific steps that help validate the image's provenance." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml93(para) msgid "The first option is to obtain boot media from a trusted source." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml103(para) msgid "" "The second option is to use the OpenStack Virtual Machine Image " "Guide. In this case, you will want to follow your " "organizations OS hardening guidelines or those provided by a trusted third-" "party such as the RHEL6 STIG." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml104(para) msgid "" "The final option is to use an automated image builder. The following example" " uses the Oz image builder. The OpenStack community has recently created a " "newer tool worth investigating: disk-image-builder. We have not evaluated " "this tool from a security perspective." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml105(para) msgid "" "Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section " "AC-19(d) in Oz." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml142(para) msgid "" "Note, it is the recommendation of this guide to shy away from the manual " "image building process as it is complex and prone to error. Further, using " "an automated system like Oz or disk-image-builder for image building, or a " "configuration management utility like Chef or Puppet for post boot image " "hardening gives you the ability to produce a consistent image as well as " "track compliance of your base image to its respective hardening guidelines " "over time." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml143(para) msgid "" "If subscribing to a public cloud service, you should check with the cloud " "provider for an outline of the process used to produce their default images." " If the provider allows you to upload your own images, you will want to " "ensure that you are able to verify that your image was not modified before " "you spin it up. To do this, refer to the following section on Image " "Provenance." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml146(title) msgid "Image Provenance and Validation" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml147(para) msgid "" "Unfortunately, it is not currently possible to force Compute to validate an " "image hash immediately prior to starting an instance. To understand the " "situation, we begin with a brief overview of how images are handled around " "the time of image launch." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml148(para) msgid "" "Images come from the glance service to the nova service on a node. This " "transfer should be protected by running over SSL. Once the image is on the " "node, it is verified with a basic checksum and then it's disk is expanded " "based on the size of the instance being launched. If, at a later time, the " "same image is launched with the same instance size on this node, it will be " "launched from the same expanded image. Since this expanded image is not re-" "verified before launching, it could be tampered with and the user would not " "have any way of knowing, beyond a manual inspection of the files in the " "resulting image." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml149(para) msgid "" "We hope that future versions of Compute and/or the Image Service will offer " "support for validating the image hash before each instance launch. An " "alternative option that would be even more powerful would be allow users to " "sign an image and then have the signature validated when the instance is " "launched." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml154(para) msgid "" "OpenStack and the underlying virtualization layers provide for the live " "migration of images between OpenStack nodes allowing you to seamlessly " "perform rolling upgrades of your OpenStack compute nodes without instance " "downtime. However, live migrations also come with their fair share of risk. " "To understand the risks involved, it is important to first understand how a " "live migration works. The following are the high level steps preformed " "during a live migration." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml165(para) msgid "Start instance on destination host" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml166(para) msgid "Transfer memory" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml167(para) msgid "Stop the guest & sync disks" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml168(para) msgid "Transfer state" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml169(para) msgid "Start the guest" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml172(title) msgid "Live Migration Risks" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml173(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.xml175(para) msgid "" "Denial of Service (DoS) : If something fails during the" " migration process, the instance could be lost." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml178(para) msgid "" "Data Exposure : Memory or disk transfers must be " "handled securely." msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml181(para) msgid "" "Data Manipulation : 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.xml184(para) msgid "" "Code Injection : 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.xml189(title) msgid "Live Migration Mitigations" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml190(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.xml192(para) #: ./doc/security-guide/ch055_security-services-for-instances.xml202(title) msgid "Disable Live Migration" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml195(para) msgid "Isolated Migration Network" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml198(para) #: ./doc/security-guide/ch055_security-services-for-instances.xml213(title) msgid "Encrypted Live Migration" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml203(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.xml209(title) msgid "Migration Network" msgstr "" #: ./doc/security-guide/ch055_security-services-for-instances.xml210(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.xml214(para) msgid "" "If your use case involves keeping live migration enabled, then libvirtd can " "provide tunneled, encrypted live migrations. That said, this feature is not " "currently exposed in OpenStack Dashboard, nor the nova-client commands and " "can only be accessed through manual configuration of libvritd. Encrypted " "live migration modifies the live migration process by first copying the " "instance data from the running hypervisor to libvirtd. From there an " "encrypted tunnel is created between the libvirtd processes on both hosts. " "Finally, the destination libvirtd process copies the instance back to the " "underlying hypervisor." msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml3(title) msgid "Compliance Overview" msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml4(para) msgid "" "An OpenStack deployment may require compliance activities for many purposes," " such as regulatory and legal requirements, customer need, privacy " "considerations, and security best practices. Compliance, when done " "correctly, unifies and strengthens the other security topics discussed in " "this guide. This chapter has several objectives:" msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml6(para) msgid "Review common security principles." msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml9(para) msgid "" "Discuss common control frameworks and certification resources to achieve " "industry certifications or regulator attestations." msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml12(para) msgid "Act as a reference for auditors when evaluating OpenStack deployments." msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml15(para) msgid "" "Introduce privacy considerations specific to OpenStack and cloud " "environments." msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml19(title) msgid "Security Principles" msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml20(para) msgid "" "Industry standard security principles provide a baseline for compliance " "certifications and attestations. If these principles are considered and " "referenced throughout an OpenStack deployment, certification activities may " "be simplified." msgstr "" #: ./doc/security-guide/ch061_compliance-overview.xml22(para) msgid "" "Layered Defenses: 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 "" "Fail Securely: 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 "" "Least Privilege: 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 "" "Compartmentalize: 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 "" "Promote Privacy: 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 "" "Logging Capability: 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 American Institute of Certified Public " "Accountants (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 AICPA" " Report on Controls at a Service Organization Relevant to User Entities’ " "Internal Control over Financial Reporting." 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 AICPA" " Report on Controls at a Service Organization Relevant to Security, " "Availability, Processing Integrity, Confidentiality or Privacy." 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 AICPA" " Trust Services Report for Service Organizations." 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 ISO " "27001." 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 Health Insurance " "Portability And Accountability Act." 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 PCI " "security standards." 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 Federal Risk and Authorization " "Management Program (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 http://www.gsa.gov/portal/category/102371." 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 http://pmddtc.state.gov/regulations_laws/itar_official.html." 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 "" "System CategorizationThe 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 "" "Control SelectionBased 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 "" "Control TailoringOnce 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 (list of SRGs). 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 middleware. 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 http://pythonpaste.org/deploy/." 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.xml119(title) msgid "Namespaces" msgstr "" #: ./doc/security-guide/ch021_paste-and-middleware.xml55(para) msgid "" "Many operating systems now provide compartmentalization support. Linux " "supports namespaces to assign processes into independent domains. System " "compartmentalization is covered in more detail in other parts of the guide." msgstr "" #: ./doc/security-guide/ch021_paste-and-middleware.xml58(title) #: ./doc/security-guide/ch038_transport-security.xml124(title) msgid "Network Policy" msgstr "" #: ./doc/security-guide/ch021_paste-and-middleware.xml59(para) msgid "" "API endpoints typically bridge multiple security domains, as such particular" " attention should be paid to the compartmentalization of the API processes." "  See the Security Domain Bridging section for " "additional information in this area." msgstr "" #: ./doc/security-guide/ch021_paste-and-middleware.xml60(para) msgid "" "With careful modeling, network ACLs and IDS technologies can be use to " "enforce explicit point to point communication between network services. As " "critical cross domain service, this type of explicit enforcement works well " "for OpenStack's message queue service." msgstr "" #: ./doc/security-guide/ch021_paste-and-middleware.xml61(para) msgid "" "Policy enforcement can be implemented through the configuration of services," " host-based firewalls (such as IPTables), local policy (SELinux or " "AppArmor), and optionally enforced through global network policy." msgstr "" #: ./doc/security-guide/ch021_paste-and-middleware.xml64(title) #: ./doc/security-guide/ch038_transport-security.xml129(title) #: ./doc/security-guide/ch052_devices.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, nova-manage, glance-" "manage)" 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.xml50(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 Django 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, or " "), 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, nova, glance). 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 "" "OpenStack End User Guide section command-line clients " "overview" msgstr "" #: ./doc/security-guide/ch014_best-practices-for-operator-mode-access.xml147(para) msgid "" "OpenStack End User Guide section Download and source the OpenStack RC " "file" 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 " "BMC/IPMI, always use the SSL interface, such as https" " or port 443. This SSL interface should NOT 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 "" #: ./doc/security-guide/ch026_compute.xml4(para) msgid "" "The Compute Service (Nova) is one of the more complex OpenStack services.  " "It runs in many locations throughout the cloud and interacts with a variety " "of internal services.  For this reason, most of our recommendations " "regarding best practices for Compute Service configuration are distributed " "throughout this book. We provide specific details in the sections on " "Management, API Endpoints, Messaging, and Database." msgstr "" #: ./doc/security-guide/ch026_compute.xml6(title) msgid "Virtual Console Selection" msgstr "" #: ./doc/security-guide/ch026_compute.xml7(para) msgid "" "One decision a cloud architect will need to make regarding Compute Service " "configuration is whether to use VNC or SPICE. Below we " "provide some details on the differences between these options." msgstr "" #: ./doc/security-guide/ch026_compute.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 " "nova-novncproxy service to bridge" " from the public network to the management network." msgstr "" #: ./doc/security-guide/ch026_compute.xml22(para) msgid "" "The command-line utility can return a URL for the VNC " "console for access by the nova " "Java VNC client. This requires the nova-" "xvpvncproxy service to bridge from the public network to the " "management network." msgstr "" #: ./doc/security-guide/ch026_compute.xml35(para) msgid "" "The nova-novncproxyand nova-" "xvpvncproxy services by default open public-facing ports that are token " "authenticated." msgstr "" #: ./doc/security-guide/ch026_compute.xml38(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.xml44(link) msgid "Secure Connections to VNC ports" msgstr "" #: ./doc/security-guide/ch026_compute.xml47(title) msgid "Simple Protocol for Independent Computing Environments (SPICE)" msgstr "" #: ./doc/security-guide/ch026_compute.xml48(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.xml52(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.xml55(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.xml60(title) msgid "Limitations" msgstr "" #: ./doc/security-guide/ch026_compute.xml62(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.xml69(para) msgid "" "The nova-spicehtml5proxy service by default opens public-facing ports that " "are token authenticated." msgstr "" #: ./doc/security-guide/ch026_compute.xml72(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.xml75(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.xml81(link) msgid "SPICE Console" msgstr "" #: ./doc/security-guide/ch026_compute.xml82(link) msgid "Red Hat bug 913607" msgstr "" #: ./doc/security-guide/ch026_compute.xml83(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 secure boot technologies. 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" " Chef or Puppet, 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 secure boot will validate the code" " run at each step in the process, and stop the boot if code is incorrect. " "Boot attestation 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 security technical implementation " "guides (STIG) and the NSA" " guides 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 /etc/fstab." 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 dm-" "verity." 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. Snort 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.xml86(para) msgid "" "NOTE: A bug exists in the current version of OpenStack Grizzly where if " "'kombu_ssl_version' is currently specified in the configuration file for any" " of the OpenStack services it will cause the following python traceback " "error: 'TypeError: an integer is required'. The current workaround is to " "remove 'kombu_ssl_version' from the configuration file. Refer to bug report " "1195431 for current status." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml89(title) msgid "Authentication Configuration Example - Qpid" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml90(para) msgid "For configuration information see:" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml92(link) msgid "Apache Qpid Authentication" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml95(link) msgid "Apache Qpid Authorization" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml100(title) msgid "OpenStack Service Configuration - Qpid" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml109(para) msgid "" "Optionally, if using SASL with Qpid specify the SASL mechanisms in use by " "adding:" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml115(title) msgid "Message Queue Process Isolation & Policy" msgstr "" #: ./doc/security-guide/ch038_transport-security.xml116(para) msgid "" "Each project provides a number of services which send and consume messages. " "Each binary which sends a message is expected to consume messages, if only " "replies, from the queue." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml117(para) msgid "" "Message queue service processes should be isolated from each other and other" " processes on a machine." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml120(para) msgid "" "Network namespaces are highly recommended for all services running on " "OpenStack Compute Hypervisors. This will help prevent against the bridging " "of network traffic between VM guests and the management network." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml121(para) msgid "" "When using ZeroMQ messaging, each host must run at least one ZeroMQ message " "receiver to receive messages from the network and forward messages to local " "processes via IPC. It is possible and advisable to run an independent " "message receiver per project within an IPC namespace, along with other " "services within the same project." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml125(para) msgid "" "Queue servers should only accept connections from the management network. " "This applies to all implementations. This should be implemented through " "configuration of services and optionally enforced through global network " "policy." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml126(para) msgid "" "When using ZeroMQ messaging, each project should run a separate ZeroMQ " "receiver process on a port dedicated to services belonging to that project. " "This is equivalent to the AMQP concept of control exchanges." msgstr "" #: ./doc/security-guide/ch038_transport-security.xml130(para) msgid "" "The configuration for these processes should be restricted to those " "processes, not only by Directory Access Controls, but through Mandatory " "Access Controls. The goal of such restrictions is to prevent isolation from " "other processes running on the same machine(s)." msgstr "" #: ./doc/security-guide/ch044_case-studies-database.xml3(title) msgid "Case Studies: Database" msgstr "" #: ./doc/security-guide/ch044_case-studies-database.xml4(para) msgid "" "In this case study we discuss how Alice and Bob would address database " "selection and configuration for their respective private and public clouds." msgstr "" #: ./doc/security-guide/ch044_case-studies-database.xml7(para) msgid "" "Alice's organization has high availability concerns, so she has elected to " "use MySQL for the database. She further places the database on the " "Management network and uses SSL with mutual authentication among the " "services to ensure secure access. Given there will be no external access of " "the database, she uses certificates signed with the organization's self-" "signed root certificate on the database and its access endpoints. Alice " "creates separate user accounts for each database user, and configures the " "database to use both passwords and X.509 certificates for authentication. " "She elects not to use the nova-" "conductor 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 nova-conductor 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) definition" " of cloud 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 OpenStack " "Hypervisor Support Matrix." 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 API 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 "" #: ./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, DNS, DHCP," " 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 shared service 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 Compute, 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 (AMQP). Similar to " "most OpenStack services, it supports pluggable components. Today the " "implementation backend could be RabbitMQ, " "Qpid, or ZeroMQ." 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 " "ISO/IEC 27001/2, " "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 Microsoft" " SDL, 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 " "OpenStack Storage documentation." 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 ." msgstr "" #: ./doc/security-guide/ch027_storage.xml83(para) msgid "" "Rule: 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 "Port" #: ./doc/security-guide/ch027_storage.xml154(td) msgid "Type" msgstr "Tipus" #: ./doc/security-guide/ch027_storage.xml160(td) msgid "6002" msgstr "" #: ./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 "" #: ./doc/security-guide/ch027_storage.xml165(td) msgid "6001" msgstr "" #: ./doc/security-guide/ch027_storage.xml170(td) msgid "6000" msgstr "" #: ./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 "" " 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 Apache" " Deployment Guide" msgstr "" #: ./doc/security-guide/ch027_storage.xml272(para) msgid "Modify file /etc/apache2/envvars 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 swift directory in your Apache document root:" msgstr "" #: ./doc/security-guide/ch027_storage.xml284(para) msgid "" "Create the file $YOUR_APACHE_DOC_ROOT/swift/proxy-" "server.wsgi:" 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 " "https://identity.cloud.example.org:55443/v1/auth and gets a " "response with their authentication key and Storage URL (the URL of the proxy" " nodes or load balancer) of " "https://swift.cloud.example.org:44443/v1/AUTH_8980." 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 "" #: ./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 ." 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 http://gholt.github.io/swauth/." 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 chmod 0600, 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 http://www.openssl.org/docs/apps/ciphers.html" " 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, postgresql.conf." 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 " "https://github.com/cloudkeep/barbican/wiki/_pages" " 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 Python Fabric library. 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 " "(CMDB). 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 "Topologia de Xarxa" #: ./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 Django deployment " "and security documentation." msgstr "" #: ./doc/security-guide/ch025_web-dashboard.xml21(para) msgid "" "The dashboard ships with reasonable default security settings, and has good " "deployment" " and configuration documentation." 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 gunicorn 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 mod_wsgi" " to host dashboard." msgstr "" #: ./doc/security-guide/ch025_web-dashboard.xml44(title) msgid "HTTPS" msgstr "" #: ./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 Django documentation on modifying the SECURE_PROXY_SSL_HEADER " "variable." 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 openstack.example.org. In this context, there are " "often many other applications deployed in the same second-level namespace, " "often serving user-controlled content. This name structure is convenient and" " simplifies name server maintenance." msgstr "" #: ./doc/security-guide/ch025_web-dashboard.xml85(para) msgid "" "We strongly recommend deploying horizon to a second-level " "domain, such as https://example.com, and advise " "against deploying horizon on a shared subdomain of any " "level, for example https://openstack.example.org or " "https://horizon.openstack.example.org. We also advise against " "deploying to bare internal domains like https://horizon/." 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 https://docs.djangoproject.com/en/1.5/ref/settings/#static-" "root." msgstr "" #: ./doc/security-guide/ch025_web-dashboard.xml120(para) msgid "" "Dashboard's default configuration uses django_compressor 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 " "(django.contrib.sessions.backends.signed_cookies) " "stores user data in signed but unencrypted " "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 storing sensitive access tokens in the " "client browser 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 " "django.contrib.sessions.backends.cache 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 Django session backend " "documentation." 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 Django documentation on settings." 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 cross-site request forgery (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 disable HORIZON_IMAGES_ALLOW_UPLOAD 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 KVM documentation." 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 Ironic. 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 "" "Implementation and Operation of Security " "ControlsAligning 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 "" "Independent Verification and " "ValidationDemonstration 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 Cloud " "Security Alliance Cloud Controls Matrix (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 SCAP " "Security Guide 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 and 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 nova-" "conductor 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 :sql_connection 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 nova-conductor which proxies database connections, with the " "primary purpose of having the nova compute nodes interfacing with " "nova-conductor 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 nova-conductor 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 nova-" "conductor 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" " nova-conductor is not used " "throughout OpenStack Compute. Depending on one's configuration, the use of " "nova-conductor 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 nova-conductor 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 nova-" "conductor service. We are not yet prepared to recommend the use" " of nova-conductor 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 nova-conductor, " "place the following into your nova.conf 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 " "etc/keystone.conf file provides the mapping from the " "LDAP attributes to Identity attributes." msgstr "" #: ./doc/security-guide/ch024_authentication.xml91(para) msgid "" "The Identity Service MUST NOT 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 OpenStack Security " "Note (OSSN) regarding keystone.conf permissions." msgstr "" #: ./doc/security-guide/ch024_authentication.xml105(para) msgid "" "There is an OpenStack Security " "Note (OSSN) regarding potential DoS attacks." 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 OpenStack Cloud Administrator " "Guide, 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 " "/etc/keystone.conf 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 insecure=False in " "the [filter:authtoken] section in the " "/etc/nova/api.paste.ini 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 "Polonès" #: ./doc/security-guide/ch024_authentication.xml237(para) msgid "" "Each OpenStack service has a policy file in json format, called policy.json. 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 default 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 lifespan is 24 " "hours. 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 "" "neutron server (neutron-" "server and neutron-*-plugin): 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 "" "plugin agent " "(neutron-*-agent): 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. Optional depending on plugin." msgstr "" #: ./doc/security-guide/ch031_neutron-architecture.xml13(para) msgid "" "DHCP agent (neutron-dhcp-" "agent): 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 "" "l3 agent " "(neutron-l3-agent): Provides L3/NAT forwarding for " "external network access of VMs on tenant networks. Requires message queue " "access. Optional depending on plug-in." msgstr "" #: ./doc/security-guide/ch031_neutron-architecture.xml19(para) msgid "" "network provider services (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" " cloud controller host, a network " "host, and a set of compute 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 "" "Management network 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 "" "Guest network 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 "" "External network 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 "" "API network 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 Networking chapter in" " the OpenStack Cloud Administrator Guide." 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 "Pública" #: ./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 untrusted." 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 untrusted. Private " "cloud providers may want to consider this network as internal and therefore " "trusted 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 trusted. " "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 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 bridge 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 "" "Intelligence Services — 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 "" "Serious Organized Crime — 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 "" "Highly Capable Groups — 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 "" "Motivated Individuals — 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 "" "Script Kiddies — 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 " "untrusted 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 ACL 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, " "policy.json, 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 Authentication and authorization " "section in the OpenStack Cloud Administrator " "Guide." 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 "Grups de Seguretat" #: ./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, nova.conf 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 nova-compute 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 "Quotes" #: ./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 " "quota_driver in neutron.conf." 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: How to assign devices with VT-d in" " KVM" msgstr "" #: ./doc/security-guide/ch052_devices.xml13(para) msgid "Xen: VTd Howto" 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 link:Management/Node Bootstrapping, 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 " "./configure --help 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 checksec.sh." msgstr "" #: ./doc/security-guide/ch052_devices.xml61(para) msgid "" "RELocation Read-Only (RELRO): 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 "" "Stack Canaries: Places values on the stack and verifies" " their presence to help prevent buffer overflow attacks." msgstr "" #: ./doc/security-guide/ch052_devices.xml67(para) msgid "" "Never eXecute (NX): 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 "" "Position Independent Executable (PIE): Produces a " "position independent executable, which is necessary for ASLR.  " msgstr "" #: ./doc/security-guide/ch052_devices.xml73(para) msgid "" "Address Space Layout Randomization (ASLR) : 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: Hardening " "Walkthrough" msgstr "" #: ./doc/security-guide/ch052_devices.xml85(para) msgid "" "RPM packages: How to " "create an RPM package" 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 "" "Hypervisor threats 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 "" "Virtual Machine (multi-tenant) threats 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: ciphers." 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 Perfect Forward " "Secrecy (PFS)." 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 RSA " "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 On the Security of " "RC4 in TLS and WPA." 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 OpenStack Operations " "Guide." 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 , YEAR1, YEAR2 #: ./doc/security-guide/ch058_forensicsincident-response.xml0(None) msgid "translator-credits" msgstr "traductors-crèdits"