|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (4)
View page history| h1. Introduction |
| {note:title=This Page Has Moved} This page has [moved|http://kenai.com/projects/isc/pages/Home]. You should change your bookmarks to use the new [Immutable Service Container|http://kenai.com/projects/isc/pages/Home] project page at [Kenai|http://www.kenai.com/]. Note that if you are looking for the ISC network diagrams, you can find them on the new ISC [Networking|http://kenai.com/projects/isc/pages/Networking] page. |
| {note} |
| Immutable Service Containers (ISC) are an architectural deployment pattern used to describe a foundation for highly secure service delivery. ISCs are essentially a container into which a service or set of services is configured and deployed. First and foremost, ISCs are not based upon any one product or technology. In fact, an actual instantiation of an ISC can and often will differ based upon customer and application requirements. That said, each ISC embodies at its core the key principles inherent in the [Sun Systemic Security|http://www.sun.com/blueprints/0206/819-5605.pdf] framework including: self-preservation, defense in depth, least privilege, compartmentalization and proportionality. As part of a more holistic view, it is expected that Immutable Service Containers will form the most basic architectural building block for more complex, highly adaptive and autonomic security architectures. The goal of this project is is to more fully describe the architecture and attributes of ISCs, their inherent benefits, their construction as well as to document practical examples using various web-scale software applications. h1. Benefits Immutable Service Containers offer the following benefits over more traditional deployment models: * Consistent, repeatable and secure packaging for the deployment and management of services. "One service per container", configured once and deployed everywhere. * Specific and clear approach to integrating platform security with services to provide enhanced security beyond what is typically deployed in most IT organizations today. * Strategy for the implementation of recommended security practices in a focused, supported way. * Flexible security to accommodate a variety of application and operational requirements and scenarios. h1. Key Security Principles Immutable Service Containers strive to implement the following key security principles: * Secure by Default * Defense in Depth * Compartmentalization * Least Privilege * Fail in Place * Proportionality For a discussion of these principles, see the Sun BluePrints article titled [Toward Systemically Secure IT Architectures|http://www.sun.com/blueprints/0206/819-5605.pdf]. h1. Design Requirements To qualify as an Immutable Service Container, the implementation must satisfy the majority of the following constraints. Note that due to product limitations, specific implementations may not be able to implement all of these design requirements. In these cases, it is expected than additional compensating controls be used to address any gaps. The Immutable Service Container design requirements include: # The environment into which the ISC and its services are deployed must be hardened in accordance with industry accepted recommended practices. This is common sense and has fast become the standard configuration step for many of our customers today. While this is an important first step in building a solid foundation, ISC design requires us to go further. # The only network ports exposed from the ISC are those directly supporting its deployed services. This means that not only must the ISC support a network secure by default posture, but it should go even further (if possible) by disabling any network ports not directly supporting the deployed service. In its most extreme case, this may also include disabling administrative and management services such as Secure Shell (assuming management can be achieved using other mechanisms). # The deployed service must be configured to run with credentials (UID and GID) that are unique on the system. Unless required by the service or for operational reasons, no supplemental groups should be permitted for the UID either. This promotes an environment in which a successful breach of the service significantly limits the content that can be read or written within the ISC. For example, if a web server was running as the _webservd_ user and group but its configuration and data files were owned by the _www_ user and group (and not writable to world) then this kind of break could help protect against web site defacement or changes to the service's configuration. # The deployed service must be configured to run with only those privileges that are required for successful operation. By configuring the service to run with only those privileges that it needs, further attack vectors can be eliminated. There is a particular benefit for those services that can eliminate the need for proc_exec as it would prevent the service from executing (via the exec(2) family of system calls) any programs on the system - as a result of accidental or malicious action. # Similarly, the operating system context into which the service is deployed should ideally run with as few privileges as possible. This includes limiting the administrative power of users, roles, and services as well as the operating environment itself (where possible). Ideally, an ISC will be configured to help defend against the use of kernel root kits as well as the abuse of administrative power (to the degree possible). # The operating system and service should be accessed through a read-only interface from within the ISC (again, to the extend possible). Using a variety of techniques, the core operating system can be mounted read-only (leaving directories such as /etc and /var as the only remaining potentially writable locations). For applications, the binaries, libraries and often even configuration files can be mounted read-only whereas logs, PID files, and sometimes data must have a read-write interface. By leveraging a read-only interface (that cannot be changed to read-write from within the ISC), the ISC can defend against various user-level root kits, application attacks and other subversion attempts. The specifics as to what can be read-write versus read-only depend on the service and the technologies used to implement the ISC. # The operating system and service must support constrained use of resources. This is necessary to prevent one ISC from denying other ISCs (resident on the same physical hardware) the proper use of resources such as CPU cycles, physical memory, virtual memory, network bandwidth and storage capacity and bandwidth. h1. Architectural Diagrams h3. ISC Architectural Flow [!http://farm4.static.flickr.com/3350/3274119839_3f422a698a.jpg|vspace=4,bordercolor=black,border=2,align=center!|http://www.flickr.com/photos/gbrunett/3274119839/] This is a high level overview of the architectural patterns related to the Immutable Service Container design. For better context, the ISCs are shown in a classical deployment model within a Secure Network Enclave. For more details on each of these architectural patterns, see the Sun BluePrints article titled [Toward Systemically Secure IT Architectures|http://www.sun.com/blueprints/0206/819-5605.pdf]. h3. ISC Architectural Flow Example [!http://farm4.static.flickr.com/3307/3274940214_7f546ac7b5.jpg|vspace=4,bordercolor=black,border=2,align=center!|http://www.flickr.com/photos/gbrunett/3274940214/] This example illustrates how the various architectural patterns can be instantiated with specific products and configurations. In this example, MySQL is running inside of a Solaris sparse-root non-global zone. The ISC architectural approach is product agnostic, however. h3. ISC Large-Scale Deployment Support Structure [!http://farm4.static.flickr.com/3501/3274214987_2228b6afc2.jpg|vspace=4,bordercolor=black,border=2,align=center!|http://www.flickr.com/photos/gbrunett/3274214987/] This example shows additional architectural components (e.g., software library, orchestrator, agent, etc.) that could potentially be leveraged to manage and support a large scale Immutable Service Container deployment. Just as with the ISCs themselves, the actual products used to implement these components can and will vary based on a variety of customer and technology considerations. h1. Customer Deployments * [2008 International Chess Olympics|http://blogs.sun.com/bud/entry/chessolympics_and_sun] h1. Implementation Examples * [OpenSolaris Zones|http://kenai.com/projects/isc/pages/Home] * VirtualBox (Soon) h1. Autonomic Security Use Cases Using Immutable Service Containers as a core building block enables some very interesting use cases in the area of adaptive and autonomic security architectures. Several potential use cases are shown in this [diagram set|http://www.flickr.com/photos/gbrunett/sets/72157613711337202/detail/]. For more information on adaptive and autonomic security, see the [Adaptive Security Sun Blog|http://blogs.sun.com/adaptive_security/]. |