Disconnected Environments

Isolation is a vital cybersecurity tactic in system design and architecture (SDA). Its goal is to safeguard sensitive data by limiting external access. It includes concepts such as air-gapped systems and disconnected environments.

Disconnected or isolated environments are networks or systems intentionally void of internet connectivity to ensure security requirements. Some systems or components require disconnection because they handle sensitive data or operate under stringent regulatory compliance. Disconnecting these systems from the internet reduces potential cyberattack avenues, enhancing overall security posture.

This isolation is often achieved logically using virtual local area networks (VLANs), non-routable subnets, and firewalls. Such systems can share the same networking infrastructure as their internet-connected counterparts yet remain distinct and secure.

 

 

Disconnected Environment Feature Image

Typical scenarios for disconnected environments

Disconnected environments are powerful tools to mitigate specific operational risks. Let’s examine their applications for data security, access control, and secure multi-tenancy.

Securing data

Securing data

Disconnected environments help prevent unauthorized access and exfiltration of sensitive data. They eliminate the usual routes for cyber threats, providing an extra layer of protection for systems containing high-value data.

The key benefit of disconnected environments lies in their limited access points. Eliminating standard internet connectivity drastically reduces the avenues for potential cyber attacks. This principle is especially crucial when systems house sensitive data like financial transactions, popular targets for cyber threats. Data transfer in these settings requires strict protocols to ensure uncompromised isolation.

Connect

Securing access

Disconnected environments efficiently control system access by eliminating standard internet connectivity. These environments significantly reduce potential access points to systems and applications, creating a more secure operational landscape.

This level of stringency is paramount in environments where even a minor breach could lead to significant disruption or damage, including those requiring high-integrity operations, processing classified information, and where strict regulatory compliance is a must. Here, disconnected environments function as secure citadels, stopping unwarranted intrusions and ensuring smooth operations.

Connect

Secure multi-tenancy

Disconnected environments can play a vital role in multi-tenant architectures by ensuring tenant isolation and preventing a breach in one tenant’s setup from affecting others. Container-based applications run as an isolated process on the host OS, making them less prone to interference. These applications share a kernel, making them lightweight and scalable.

With multi-tenancy, applications can share data within the isolated environment without exposure to the internet, boosting the data’s security. Access control ensures only relevant and necessary applications reach the database’s sensitive information.

Implementing disconnected environments

Building and managing disconnected environments necessitate a comprehensive toolkit and strategic planning. Red Hat brings these capabilities to the table with its product suite.

Securing data

Disconnected install of OpenShift

Red Hat OpenShift is an enterprise Kubernetes platform that functions seamlessly in connected and disconnected environments. Installing OpenShift in disconnected environments involves pre-downloading the required software and images to establish a local OpenShift cluster since it can’t access the internet. Only relevant servers can access this install, ensuring optimal security.

In collaboration with OpenShift’s Source-to-Image (S2I) builder, which helps build container images, this local cluster facilitates transforming your source code into a deployable containerized application, simplifying development and deployment in these environments.

Connect

Security constraints within OpenShift

After a service account creates a pod, OpenShift employs Security Context Constraints (SCCs) to define the pod’s actions and resources. SCCs are instrumental in setting up and implementing disconnected environments. They govern running pods as non-root users, prohibiting access to the host network, and preventing pods from using host volumes.

OpenShift also uses role-based access control (RBAC) and integrates Security-Enhanced Linux (SELinux) to enforce a configurable security policy over user and application behaviors, mitigating the risk of security breaches. SELinux labels all Linux OS aspects and only allows processes with exactly the same label to interact with the objects.

Connect

Local image registries

A local container image registry is a necessity in a disconnected environment. OpenShift has a built-in container image registry, managed by an infrastructure Operator, which integrates seamlessly with the cluster’s user authentication and authorization system. The local registry audits new images with stringent control to enhance supply-chain security with an additional layer of protection.

The disconnected install stands up an instance of Red Hat Quay, a private, distributed image registry platform, to serve images for the installation. This enterprise-level container image registry offers functions such as security scanning, robot accounts, and fine-grained access control for more complex requirements.

Latest articles on Disconnected Environments

.Net Core
May 29, 2018

Using .NET Core in a "Disconnected" Environment

Rick Wagner

For added security, .NET Core applications that require access to external...

Learn more
View All