DSI: A New Architecture for Secure Carrier-Class Linux Clusters
DSI introduces original contributions in the area of security on clustered systems. However, some parts, such as Access Control Service and the use of security contexts and identifiers, owe much to existing propositions, like Security Enhanced (SE) Linux.
DSI has two types of components: management and security services.
The DSI management components define a thin layer that includes a security server, security managers and a security communication channel (Figure 1). The service layer is a flexible layer that can be modified or updated through adding, replacing or removing services according to the needs of the cluster.
The security server is the central point of management in DSI, the entry point for secure operation and management and intrusion detection systems from outside the cluster. It is responsible for the distributed security policy. It also defines the dynamic security environment of the whole cluster by broadcasting changes in the distributed policy to all security managers.
Security managers enforce security at each node of the cluster. They are responsible for locally enforcing changes in the security environment. Security managers exchange security information only with the security server.
The secure communication channel provides encrypted and authenticated communications between the security server and the security managers. All communications between the security server and the outside of the cluster take place through the secure communication channel. Two nodes (to avoid a single point of failure) host the security server, and different security service providers, such as the certification authority, are hardened to maximize security. All connections from and to these nodes are encrypted and authenticated.
The security mechanisms are based on widely known, proved and tested algorithms. For the security mechanisms to be effective, users must not be able to bypass them. Hence, the best place to enforce security is at the kernel level; all security decisions, when necessary, are implemented at kernel level, the same as for the main security manager component, which has stubs into the kernel. In the Linux operating system, these stubs are implemented through load modules.
The DSI architecture at each node is based on a set of loosely coupled services (Figure 2).
The security manager controls different security services on the node. This service-based architecture has the following advantages:
The service implementation is separated from the rest of the system. By keeping the same API, the service implementation can be changed without affecting the application. However, an API for accessing security services is provided at user level for applications with special security needs (Figure 3).
It runs only predefined services according to the needs, performance issues or security environment. In addition, services can be replaced during runtime without major drawbacks on the running application. This enables the architecture to be modified and to resist changes throughout the system's lifetime.
It is possible to add, remove or update different services without administrative intervention. This reduces configuration errors due to the numerous security patches that need to be applied manually.
The security manager discovers the different services. Each service, upon its creation, sends a presence announcement to the local security manager, which registers these services and provides their access mechanisms to the internal modules.
There are two types of services: security services (access control, authentication, integration, auditing) and security service providers, which run at the user level and provide services to security managers.
The security server is the reference for all security managers and has the authority to declare a node to be compromised. It subscribes to all updates to keep its cache of different security contexts up to date, which makes it the ideal candidate for running Intrusion Detection Systems (IDSs). It has a local certification authority, as it certifies public keys for secondary certification authorities run by the security managers.
The primary tasks for security server include auditing, triggering alarms and warnings inside and outside the cluster, managing the distributed security policy and propagating security operation and management information.
|PHP for Non-Developers||Jun 30, 2015|
|A Code Boot Camp for Underprivileged Kids||Jun 30, 2015|
|Comprehensive Identity Management and Audit for Red Hat Enterprise Linux||Jun 29, 2015|
|Linux Kernel 4.1 Released||Jun 26, 2015|
|Secure Server Deployments in Hostile Territory||Jun 25, 2015|
|Take Control of Growing Redis NoSQL Server Clusters||Jun 24, 2015|
- Comprehensive Identity Management and Audit for Red Hat Enterprise Linux
- Linux Kernel 4.1 Released
- Secure Server Deployments in Hostile Territory
- Django Templates
- A Code Boot Camp for Underprivileged Kids
- Cinnamon 2.6 Released
- Gettin' Sticky with It
- Attack of the Drones
- Take Control of Growing Redis NoSQL Server Clusters
- Physics Analysis Workstation