https://www.linkedin.com/pulse/zero-admin-network-design-andrew-kosakowski
TEXT:
Creator
This is the base layer of the Zero-Admin network model. This is the most secured, isolated, and powerful domain. This entire network should be treated very much like a root certificate authority. The Creator domain is responsible for the creation and management of all portions of the Architect domain and security for itself and for the Architect domain.
Creator Isolation and Security
This domain should literally be an isolated domain in an air-gapped network. There should be only a very small number of users whom have physical or logical access to this network from secured hosts. Maximum technical security should be applied to include streamed containerized desktops to “dumb” terminals, dedicated and isolated user storage, whitelisting software, no external media connection capabilities other than the “embarkation” one-way write device.
Content Bubble
The content bubble is where all the “action” happens. It is where the Architect domain is created and managed. This is a virtual network that is similar in concept to a Dev network. This is where Creators configure and build container images for every device that will be part of the Architect network.
Once the container images have been created a hash is taken then added to the Architect domain verification container image. This hash will be used by the Architect domain to verify each container image before it is permitted to be deployed to the Architect domain production network.
Content Admins
The Creator admins are the only personnel whom have the ability to perform privileged functions, processes, and configurations on the creator domain. Content admins have administrative privileges within the container images that will be pushed to the Architect domain. Content Admins have all the responsibilities of traditional admins to include identity and access management, server management, patching and upgrades, and configuration changes.
Content Admins do not have administrative rights or privileges on the production Architect domain. All privileged accounts are removed from the images prior to deployment where possible. Where removal is not possible all privileged accounts have their passwords dynamically changed to a random password of no less than 101 characters or the longest permitted.
Once the containers are build they are pushed to the continuous deliver/continuous integration queue. In this queue automation is used to verify patch, version, configuration, software, and embedded account permission levels. Once these checks are passed the container is passed to the embarkation device which is a one-direction write-only connection. The device can not access the Creator domain nor can it be read by the Creator domain. Once on this device the device is physically transferred to the Architect domain Registry.
Architect
The Architect domain is where unprivileged users create the container images that will be used to architect and maintain the Consumer domain. The users of this domain should consist of level two and above administrators who perform regular to rare administrative tasks.
The users on this network will have privileged access within the Content Bubble but will have no privileged capabilities pertaining to the Architect domain. No device, software, or service within this domain should have privileged or trusted capabilities either unless required to permit required functionality.
Any such services or privileged commands should not be accessible or alterable within this domain as no device, software, patch, or configuration changes are permitted within this domain. This is the first true Zero-Admin domain in the Zero-Admin network architecture.
Architect Registry
Every component of the Architect domain uses containers that are pulled from the Architect Registry. This registry receives the containers from the embarkation connection in the Creator domain via a physically transferred device. When the device is connected to the read-only Architect domain connection all containers are automatically transferred to the registry.
When the containers are transferred to the registry they maintain the name throughout the life of the Architect domain. This causes the previous containers to be over-written. Version histories are maintained in the Creator domain. This registry is used to replace every asset on the Architect domain twice daily.
Every asset in this domain are built in pairs. This permits the desired wiping capability. Every twelve hours one of the devices is taken offline, replaced by a container image pulled from the registry then brough back online. This prevents any tampering, hacking, or other persistence of bad juju for greater than one day.
Verification
Verification is the process where container image hashes are compared against a read-only database of image hashes. When a container image is requested the verification process is automatically started. The container image is hashed, then the hash compared against the authorized hashes in the verification database to determine both the hash and container image name match.
Content Bubble
The content bubble is where all Consumer domain container images are created, updated, configures, and managed. This is a virtual development environment where admins can do admin things to the most widely deployed and utilized network.
User accounts are a notable mention here. No user accounts are managed, created, updated, or removed in the Consumer domain. All account changes are made in the “higher level” domain and propagated to the production domain by updating the associated container image. This holds true for firewall, other network, and software changes too.
Consumer Library – CD/CI
The Consumer domain library is where all Consumer domain container images are maintained. It is the only place where container images on this domain can be maintained without being wiped. There are three setting for images in this library: Working, Verifying, Deployable.
All images in the working library are in the process of being created, updated, or maintained. Verifying is the process of ensuring the images are properly updated, patched, and configured with all privileged user accounts removed or secured as previously specified. Deployable is the consumption point for the CD/CI process which moves the images to the Consumer domain registry.
Consumer Domain
This is where organizations conduct their business. This domain has the most users and the least privileged access to perform any tasks. Even the security folks on this domain can only view and access systems. They have no capability of making any changes. Of course, this domain is also powered by the container registry.
Consumer Registry
The consumer registry is a one direction read-only connection to a device which is one direction write-only from the Architect domain. This permits the Architect domain to pass images to the consumer domain without any data flowing in the reverse direction.
This registry is consulted by every device group every five minutes. Like the Architect domain, every device in this domain should be deployed in pairs and use fail-over replacement of images. Because this domain has the largest attack surface all assets are wiped using the registry every ten minutes in five-minute failover intervals.
Verification
All images in the registry follow the same verification process as the Architect domain prior to wiping existing assets. If any container image fails a verification check a high security alert is forwarded to both security and network admins for immediate attention. Any failed verification could permit unwanted code to persist on devices for an extended period and facilitate more covert exfiltration because data can be chopped into smaller segments.
Contents
The Consumer domain contains everything that makes the business run. As all devices are wiped every ten minutes it is imperative for storage to be configured correctly within container images. Dedicated storage spaces should be persistent and integrated into every image using the appropriate protocols and services to ensure when a desktop does fail over while a user is logged in, all content will persist. Additionally, all whitelisted software, cookies, and session data should be migrated to the ‘new’ image upon failover to permit no interruption or inhibition of work capability.
Legacy Devices
It always comes down to legacy devices. I say let them be themselves. The Consumer domain has no privileged capabilities does not preclude it from being connected to legacy devices which only operated on dedicated hardware or with legacy software. Legacy devices should be placed on their own micro-subnet which is only reachable from a single hardened device. The hardened device should be a container image configured to only permit connections from a small number of IP addresses using a small list of authorized accounts.
Conclusion
I am sure I have not articulated the Zero-Admin network idea as thoroughly as I envision it but this provides a good overview of the concepts. I do believe there are solid ideas here that can be implemented. At its most basic level, the Zero-Admin network in a way takes and modified the CD/CI concept and adapts it to enterprise creation and management. The three domain design permits the creation and management of assets in lower security domains while eliminating privileged capabilities within the current domain. This idea is open for development, discussion, and improvement. It is free to the world and can be implemented, adapted, or rejected anywhere in the cloud or on premises.
Thanks for Reading,
From the desk of Anthko