Monday, October 20, 2014

Workbench Instances

I would like to describe a few workbench replication utilities and conventions with the example arrangement shown in the picture below. It focuses on workbench instances from the perspective of hardware as a point of access. You may not want or need a replica of every workbench on every device.



Rows and Columns

Every oval represents a workbench of the same project. Each row is a different setup of that project, and accordingly corresponds to what could be called a Purpose (the setup may be temporarily different in one row: green/red). The top row labels the systems that span the entire column, and the vertical black lines show physical hardware boundaries.

Workshop Nodes

The blue, vertical bar separates the green workshop zone from the red-drone zone. For the sake of simplicity, assume the same WS/drone node (global user data) on each side and ignore the details of the system. Ideally, the system would be a blueprint that does not accumulate any data and can therefore be the same everywhere.

The green zone is your safe zone with private data and a higher convenience level. The workshop (WS) nodes here are on hardware you own and trust. The "Laptop" and "Host" system labels hint at harboring a full WS, but it could as well be a green-drone node in a system-container.

The red zone is for experiments, untrusted-code executions, and collaboration on hardware you don't own. You would try to put the least amount of data necessary for the task at hand onto these nodes. The data here may potentially go public. Interestingly, many scheduled tasks may not even need network connectivity, and so not every red-drone is necessarily threatened by information disclosure.

Instances

There are basically two ways to instantiate a workbench. You either intend to use slight variations of a conceptually different setup and consequently create a new Purpose, or you want to replicate a workbench on another system. In the latter case, you want to always synchronize the current Situation. For example, you changed S1 on the "Host" system, and want to continue at exactly that state on the "Laptop" system. I call this Replicate-To-Self (RTS) to distinguish it from a collaboration synchronization done through DM-schemes in modules.

RTS ensures that these workbench replicas appear as one. If you detach a workbench from the RTS-relation, it may either represent a potentially useless past state or you might evolve it into a Purpose of its own. If you think you need a backup, you can create a version manifest and spool all modules of a workbench on demand. Note that RTS may be supported by private, always-on, passive storage systems that are not shown in the sketch.

Data Access

Another aspect is data access. The almond colored rectangle shows shared data access. This is a configuration that may be interpreted by the DM-schemes of modules in different ways, but it usually means that all modifications in other workbenches are visible without further action -- for example, because a shared backend is being replicated.

A more formal way to exchange data between Purposes is explicitly through an external repository. That is the same as collaborating with others, except that you may choose to use a private repository. Let's call it Collaborate-With-Self (CWS).

Danger Zone

Now on to damage control and calculated risk.

Having a modular structure and automation makes it easy to push only the data necessary when you schedule a long running task or when you plan to collaborate abroad. That is shown by the "slice" arrow from the green to the red zone. You can start a red-drone on a virtual system which provides you with the necessary separation.

So far I intend to call all workbench-slices on red-drones bots, independent of just being resource providers or meant for human interaction. The interactivity lock-down is merely a switch and does not need to be blessed with another name. By the way, instantiating another Purpose is very similar to slicing down a workbench for use in the red zone.

The labels of the bots in the red-zone are the same as in the green-zone but with a B suffix to indicate their strong relation to the Situation in the green zone. They are, however, completely independent from green-zone workbenches. RTS as well as sharing data access would undermine the motivation for the green/red separation. It would link the security levels of both contexts.

The drone and bot data puts some limit on what might become public in case of a successful break-in from inside (malicious project scripts) or outside (foreign environment). So slicing helps you contain the threat from information disclosure.

Back in the green zone, you can pull data to a passive state and inspect all modification. You vet them, merge them, and destroy the bot (or just the changes). Here, you have the opportunity to detect tampering or unexpected changes. Note how the modifications on a bot (and drone) have a temporal nature. Their reason for existence is to be absorbed into the green zone to possibly be re-injected into the bot as vetted changes.

Drones are little worlds of their own and bots can RTS within the red-zone drones. The bot Situation S2B demonstrates how you can prepare an abroad collaboration on a foreign system inside a virtualized system and the synchronization with the abroad system is handled automatically.

The slice/detect boundary is not exclusively meant for crossing the green/red context qualification. You can as well create such a boundary from the abroad system with the same red-drone and S2B Situation, just to get an understanding about what the result of an operation is (detect).

To stick with the analogy of a house and rooms, you can see the green/red boundary as kind of the front door. You dress for the public and prepare for the things you take with you to be stolen. In the digital world you can even use your phone in trusted mode to fetch stuff you forgot.

No comments:

Post a Comment