Access Control and Security in a DDD-Developed Micro Service (Military example)
What is Dataparency D-DDN?
We have designed and patented a distributed means of access control and data persistence that restricts access of data to people/Entities[1] that are designated to receive it as determined by the relationships to which they are authorized. This is exclusively under the control of an administrator. For the military, this means that a commander can absolutely restrict access to information to people, units, devices etc. that he designates and a hacker or interloper, being undesignated, cannot see the information. The relationship of the entities themselves is the access control point and not just access to the entire network.
On the network, entities are associated with each other through the use of RDIDs (Relationship Distributed IDentifiers – a byte string encoding of the entities comprising the relationship) that are created by D-DDN as the network is designed and provisioned. In the case of a network based upon a collection of microservices and user entities, a RDID might exist between the user and the microservice itself.
So, again, a hacker, without the possibility of acquiring such a relationship, cannot retrieve the data that is being used in the application. For example, a micro service entity and each of its users would be designated as in such relationships. No hacker, even on gaining access to network, would have access to the data being used to support the application. So, in a combat situation, the access to content associated with an application supporting the activity would be securely restricted to designated users. No one else would be able to see the data or observe and/or participate in the activity.
Distributed Data Network Operation
Dataparency’s D-DDN network is enabled by the use of D-ISP, the Dataparency LLC patented Information Sharing Platform[2], and the use of an embedded NATS messaging system. D-DDN is a shared data messaging network comprised of a set of cooperating D-ISP servers, each with its own database and each receiving requests on the network’s request queue-id. These requests, for retrieving and posting data, are supported by a cluster of NATS embedded D-ISP servers. Real-time updating of each server’s database is accomplished by sending the encrypted, updated data to an “update-queue” which is listened to and subsequently updated by each server. This provides multiple backups of data protecting it from loss and ransomware.
For Zero-Trust, D-DDN provides the infrastructure to implement the three core components of NIST.SP.800-207 Zero-Trust Architecture[3].
D-DDN enables the creation of specialized distributed data networks – for example, a collection or series of microservices created to support a particular activity (see Figure 1 – DDN Network) that ties together the microservices and other entities that comprise the network.
The Figure below depicts a network receiving IoT device events.
Figure 1 – DDN Network
The Domain
Domain Driven Design (“DDD”) can be used to map or align the microservices in D-DDN powered distributed networks. DDD provides the means for matching up the network framework to the organization that it will support. In a distributed network environment, it leads to identifying and locating the microservices that comprise the ongoing network operations. This is how it would fit together.
We start with the Wikipedia definition:
Domain-driven design (DDD) is the concept that the structure and language of your code (class names, class methods, and class variables) should match the business domain. For example, if your software processes loan applications, it might have classes such as LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.
DDD requires splitting up of the Application’s Domain into ‘Bounding Contexts’ (BC) that represent the organization of the ‘objects’ making up the Enterprise and therefore as they will be represented in the application. A BC object groups objects of like responsibilities under a name understood by all. One decomposes the bounding contexts, and their objects of responsibilities, from the top down and implementations of them from the bottom up.
A “type” library is developed for each BC object containing the data, “values” in DDD talk, as structures in Go[4]. These types are not exported as that would allow ‘coupling’ the data to external objects. A type library is also created which details the structures returned by the microservice(s) managing the BC objects. These structs become the ‘contract’ data between the microservice and its callers[5].
From here, developers create the ”queue ids”’, which are used as connection points, to communicate requests and responses from the callers of the respective network microservices to their responses. These queues ids are strings that provide an indication of type of service action requested from the microservice, i.e., “create_user”. They are the interface connection points that comprise the microservice operation. This activity takes the place of what is referred to as ‘service discovery’ in other systems[6], and it is handled in D-DDN supported networks by the network messaging service (NATS) that is embedded in the D-DDN cluster controller. This network service maintains the connections between the microservices and their callers (users of the network) and brokers the data between each such request.[7]
NATS messaging enables the posting of a message in the network to the “queue-ids” referred to above, that will be picked up by users, microservices or other entities that have been created to “listen” for such requests as part of the network framework.
When implementing a microservice in D-DDN, one implements a function that is invoked when a message of a request action is received on the microservice’s queue id. Due to the nature of the D-DDN supported network, a microservice, from a set of microservices deployed to the network from anywhere in the world, will respond to the request. This affords High-Availability (HA) of services to all users of the network. The network will route the request to one of the available microservices running and ‘listening’ for messages on the queue id.[8] Unlike with other systems, there are no routing tables that must be maintained with the subsequent reduction of effort in keeping a service operating.
The roles ascribed to each of the entities supporting and participating in the network would be as follows:
Figure 2 – Entity Roles
The entities supporting the D-DDN enabled distributed network could appear as shown in Figure 3 below. The flow of information, access control, and use of microservices is as follows:
Figure 3: D-DDN microservices entities.
There is a great deal of flexibility in the creation and use of D-DDN supported networks. They are designed to be created quickly and securely without a bunch of complex security protocols. In a proposed Federal Information Sharing Network[9], the D-DDN supported microservices could appear as follows:
Figure 4 F-ISN – Federal Information Sharing Network
Instances of D-DDN supported distributed networks could be used on an adhoc basis to support various interagency activities. They could be set up quickly and securely without effort beyond setting them up….no real need to set up large scale secure networks.
Potential Structure of D-DDN Supported Network for Military Combat Activity
In the example application reflected in Figures 5 and 6 below, the Domain in which we are working we’ll call ‘Theater of Operations’ or TOps for short. It is one of the Domains within the Data Mesh represented in Figure 5 below. As D_ISP is an example of Resource-oriented access, for partitioning data, we use the URL path convention; /<domain>/<class>/<RDID>/<collection>. We will use ‘TOps’ as the domain segment in the Path used for data storage and retrieval. For the class segment we’ll have – Group, Commandant, Operations Officer, Soldier, Resource, Task, etc., which represent the type of Entity the data belongs to. Each Entity we create will be entered into an Access Group(s)’ list (i.e., an aggregation) of those for whom access to the resources are authorized. Such groups might include – TaskGroup, UserGroup, ResourceGroup, etc.
A RDID between entities controlled by the group and the requesting entity are stored in the group list. This allows retrieval of the requesting entity to validate it has access privileges to the group’s resources and to include its information in tasks performed by them and persisted as log entries in the system. It also allows adding and removing entities from those allowed authority to access the resources of the group, either by removing the RDID or by marking the group entry as invalid.
By using appropriately named aggregation collections, per entity (resource) events of a type occurring within the group can be tracked (by posting) in a time-dependent ‘log’ for further analysis. For example, the resource group may collect device events in a collection named ‘read_events’ and an up-time collection labeled ‘online_events’. Due to the nature of D-ISP data handling, where a collection of posts are tracked in occurrence order, the log of events may be retrieved in historical order where an ‘audit’ of events is required or as the ‘latest’ when using the collection’s log as the current state of the entity, its current value. This is often called ‘event sourcing’ except here it is bound to a single entity and aggregated through entries in the group, making it simple to retrieve events from a single resource. By using the resource entity or a composite retrieval of resource entity logs, analysis of the group’s list of resources can be made.
This simplifies programming as there is always a historical way of looking at data, and a state-full way of retrieving data at a certain state (first/latest) and/or at a time in the past. This is all part of the standard way D-ISP processes data.
Consider the following data designs that could be easily implemented with D-DDN.
Figure 5 – TOps Domain Entities in the DataMesh
Figure 6 – Mapping Data Mesh to D-ISP
Access Control
Access control flows from the top entities to the authorization groups to the individual entities created to deal with data. Authorization at each level derives from the RDIDs created and held between entities at one level to those at a lower level ending at the source entities. Authorization results from having the appropriate RDID without which entities are not knowable and/or access is denied.
Access control of the creation, relationships, and role are handled by the application running Tops. This app is considered to be an entity in D-ISP and would have a passCode and relationship identifiers that control who and what a person may do. The app can retrieve the person’s identity and the roles and groups to which they belong. This configures the app to determine what to offer to the user as task/commands it might execute.
Data Security
Data security is enforced as all data is encrypted at rest and in transfer by system and entity data keys and per/session keys and therefore unavailable without the proper access control credentials for the entity by which to decrypt the returned data.
During Entity Login, in addition to returning a JWT and the server’s public key, a unique, one-time key pair is created, the public key of which is passed to the server in the login request. The server uses this public key to encrypt subsequent server responses. Only the process that executed the Entity Login will have the session private key by which to decrypt the server’s response to a request. The login JWT passed in all requests is checked by the D-ISP server(s) for validity and prevention of credential stealing.
Advanced Developer Support; Unifying SecOps and DevOps
With the advent of ChatGPT and other AI functionalities, a D-DDN/D-ISP Develop and Governance IDE will provide developer resource multipliers where the IDE will actually use the AI to provide best-practices in code and data design.
Using ChatGPT, the data design for access control and security in a DDD-developed micro service could be enhanced by providing natural language processing capabilities to the application. This could allow developers to interact with the application in a more natural way, making the developer experience more intuitive. For example, ChatGPT could be used to help developers create and manage authorization groups, as well as to provide automated assistance when setting up access control credentials. Additionally, ChatGPT could be leveraged to help developers understand the data security measures they need to take to keep their data secure. This could help to reduce the chances of data breaches and unauthorized access to data, making the microservice more secure.
DevOps and SecDevOps are built into the infrastructure eliminating the need for discrete DevOps and SecOps groups. Security is easily planned and implemented in the development process. As access control is limited to those entities in approved relationships, secure access is created once the relationships are identified and implemented as part of the application being developed. No doubt, in some respects, developers will want to continue with some measure of traditional security and protection from such things as viruses and malware. However, the core access control issues are resolved automatically in the development process.
Data Governance is provided by the simple fact that D-ISP ‘knows’ the structure of all documents it holds. Heuristic reporting can drive the IDE AI in suggesting data structures for a project. This is automatic and greatly reduces the developer’s “technical debt” and chance of error.
Concluding Statement
Dataparency™ D-DDN is a revolutionary new way to control access to data in distributed networks. It provides administrators with the ability to restrict data access to those users and entities that have been designated to receive it. Using unique identifiers for the relationships between users and entities, it allows for an unprecedented level of control over data access. With Dataparency™ D-DDN, administrators can be sure that their data is secure and only available to those who are authorized to view it. While it is still important to provide traditional security measures for the network itself, D-DDN is a mandatory addition for secure operations.
[1] An Entity is a nameable object, real or virtual, for which data control is desired. Entities include such things as: users, customers, companies, devices, programs, logical groups, etc. The D-DDN supported distributed network is collection of entities tied together through the use of an embedded NATS messaging system and powered by D-ISP, the patented Dataparency Information Sharing Platform.
[2] Patent US11,531,724 and additional international patents.
[3] https://doi.org/10.6028/NIST.SP.800-207, Logical Components of Zero-Trust Architecture, page 9.
[4] Go (also known as Golang) is a programming language.
[5] Callers is a general reference to the users requesting microservices on the distributed network.
[6] For example, the use of Istio in Kubernetes or Active Directory in Microsoft supported networks.
[7] NATS is a widely used open source messaging service and is used in D-DDN without compromising D-DDN’s approach to securing network access.
[8] The system anticipates operations where availability of the microservices or other entities may not be constant. For example, a microservice may be offline and then come back on line at a later time and still pick up the NATS messages that where posted to the “queue-id”.
[9] Federal Information Sharing Networks (“FISNs”) are set up to share information between various agencies in the federal government’s operations.