Enterprise networks have multiple zones (using Canadian Government terminology see reading list at end), and having a single data service crossing zone interface points makes every application and exception to security architecture. To implement data flows that comply fully with security zones, without requiring exceptions, one must implement zone interface points, which perform requisite inspection and authentication at each one.
Sarracenia networks implement meteorological real-time networks that supply data to multiple network zones. Each data pump in a Sarracenia network is sovereign over it's authentication mechanism, and takes responsibility for letting data into the zone into which it is deployed. Sarracenia pumps naturally are placed at zone interface points, and customized scanning can be implemented at each one, as appropriate for the needs of the zone being entered.
Serving network zones
duplicates data (bad) ... isolates a zone from dependency on another zone (good.) This is a mechanism to isolate critical operations from business day, or internet users. Having multiple disjoint services to serve different zones means data duplication, but also are essential to ensuring the availability of services within a zone.
provides a potentially out of date version of data (bad) ... provides data in the case of an upstream service failure (good)
means services or clients within the zone can be isolated within the zone (good) ... all outside services must be proxied somehow and inspected (complicated.)
Having separate authentication means there is no global authentication, so assuring end-to-end transfer is not within control of the publisher... instead each hop takes responsibility for data within a zone.
Zones in Practice
So in a typical sample environment, one might have an critical operations restricted zone (RZ), which has an interface with a normal business operations zone (OZ), and an internet facing zone to feed clients and partners (PAZ.)
So the RZ is the source of authoritative versions of data, but most business is not 24x7 mission critical, so it needs to feed the other zones. We don't want excessive uses in the other zones to affect the RZ services. If you have a cloud deployments, it will be external to even those zones... let's call an external zone... intended to be completely external to an enterprise's networks (EZ)
In this kind of plan, there will be Sarracenia pumps to serve all three zones ( for ECCC: ddsr/dsr==RZ, ddi/goc-dx->OZ, dd/hpfx->PAZ) RZ feeds both OZ and PAZ... most internal users are in the OZ and use that zones pumps, most external users are using the PAZ pumps. EZ users have access to the PAZ pumps.
Note that users in the OZ and EZ do not have acces to RZ pumps. So the way to publish data is:
The data is obtained by the authoritative RZ pump(s). it is then duplicated on the OZ and (potentially) PAZ pumps.
PAZ pumps do not have access to OZ or RZ data unless it is specifically published by those zones.
The Problem
We have a current requirement where there is a wish to deploy jupyter networks that access data from the RZ.
The jupyter network is expected to be deployable in any network zone (OZ, PAZ, or EZ) note that, from an EZ
To get data from EZ:
EZ needs to ask a PAZ pump for the data,
PAZ needs to bless the request, and pass it on to an OZ or RZ pump.
the internal pump needs to bless the request and provide a response, sending the data out to the PAZ.
EZ client can then download the response from the PAZ pump.
What is new here?
sr3 can pass messages around, but they have so far been messages about files that exist. the connections between pumps are expected to be pre-established flows. The need here is for ad-hoc RPC-style data requests. Things that are missing from sr3 today:
a request format. Rather than having continuous, pre-established subscriptions, the ask here is for an ad-hoc data flow.
clients need to be able to request a listing, remote pumps can authorize or refuse a listing.
clients can request a file. Remote pumps can authorize of refuse to transfer a given file.
It is like a kind of file system API, but with client and server separated by a number of hops.
petersilva
commented
1 year ago
Enterprise Environments
Enterprise networks have multiple zones (using Canadian Government terminology see reading list at end), and having a single data service crossing zone interface points makes every application and exception to security architecture. To implement data flows that comply fully with security zones, without requiring exceptions, one must implement zone interface points, which perform requisite inspection and authentication at each one.
Sarracenia networks implement meteorological real-time networks that supply data to multiple network zones. Each data pump in a Sarracenia network is sovereign over it's authentication mechanism, and takes responsibility for letting data into the zone into which it is deployed. Sarracenia pumps naturally are placed at zone interface points, and customized scanning can be implemented at each one, as appropriate for the needs of the zone being entered.
Serving network zones
Zones in Practice
So in a typical sample environment, one might have an critical operations restricted zone (RZ), which has an interface with a normal business operations zone (OZ), and an internet facing zone to feed clients and partners (PAZ.)
So the RZ is the source of authoritative versions of data, but most business is not 24x7 mission critical, so it needs to feed the other zones. We don't want excessive uses in the other zones to affect the RZ services. If you have a cloud deployments, it will be external to even those zones... let's call an external zone... intended to be completely external to an enterprise's networks (EZ)
In this kind of plan, there will be Sarracenia pumps to serve all three zones ( for ECCC: ddsr/dsr==RZ, ddi/goc-dx->OZ, dd/hpfx->PAZ) RZ feeds both OZ and PAZ... most internal users are in the OZ and use that zones pumps, most external users are using the PAZ pumps. EZ users have access to the PAZ pumps.
Note that users in the OZ and EZ do not have acces to RZ pumps. So the way to publish data is:
The data is obtained by the authoritative RZ pump(s). it is then duplicated on the OZ and (potentially) PAZ pumps. PAZ pumps do not have access to OZ or RZ data unless it is specifically published by those zones.
The Problem
We have a current requirement where there is a wish to deploy jupyter networks that access data from the RZ.
The jupyter network is expected to be deployable in any network zone (OZ, PAZ, or EZ) note that, from an EZ
To get data from EZ:
What is new here?
sr3 can pass messages around, but they have so far been messages about files that exist. the connections between pumps are expected to be pre-established flows. The need here is for ad-hoc RPC-style data requests. Things that are missing from sr3 today:
It is like a kind of file system API, but with client and server separated by a number of hops.
background reading
Terminology, and Canadian Standards for Zoning: https://www.cyber.gc.ca/en/guidance/network-security-zoning-design-considerations-placement-services-within-zones-itsg-38