dia$par data security and resilience
Due to the extreme complexity and heterogeneity of its internal structure, each active dia$par is unique (while maintaining the benefits of the packaged software in distro).
Two arbitrarily chosen active dia$par differ from each other more significantly than any two people in the world (rather, like an elephant and a whale).
Over time, each dia$par evolves independently.
The number of differences constantly increases, resulting in independent "branches of evolution" moving farther away (the cybernetic symmetry of the cosmological law of the Universe expansion).
As a universally dangerous biological virus (affecting all living organisms) is impossible, a computer virus capable of capturing more than one dia$par is also impossible.
Moreover, cybernetic Law of Requisite Variety guarantees the failure of attempts to create even a specialized virus (like Stuxnet) designed to capture a particular dia$par.
Luke Skywalker could not take over the Death Star for the same reason.
He was able just to destroy it but only due to the corruption of the chief designer himself.
dia$par architecture that guarantees its stability
Dualistic composition solution prescribed by the IEM System paradigm implemented in dia$par architecture by opposing dia$par.Mirror mmizer, and a virtual enterprise model in dia$par.Matrix.
Like an axis and a wheel, individually have opposite characteristics, but together form a system that combines everything useful from both.
Actually, dia$par.Matrix is a cybernetic "reflection" of a real company (having a sufficient degree of detailing for the cybernetically optimal control) and ensures the uniqueness of every active dia$par: all social organizations, as well as people themselves, are much alike fundamentally, but it's impossible to find an absolutely identical pair.
Disassembling dia$par, while theoretically possible, is both a Herculean task (millions and millions of lines of code), as well Sisyphean one in terms of its results due to, again, the continuous evolution of a cybernetic model.
Moreover, the updates of even invariant mmizer are supplied by the vendor about a thousand times faster than the effective laboratory disassembly of a certainly outdated version (while the operator has the updated one) would require.
MMizer level
Access rights control
Outstanding power and functionality of the dia$par access control system, providing additional control at the DBMS level without the possibility of circumvention.
Multifunctional mmizer provides unprecedented access control capabilities: as for the level of logical objects in dia$par.Matrix (cybernetic "reflections" of real warehouses, counterparts, offices), and for the individual records.
There are two unique, concurrently functioning access control mechanisms of mmizer at dia$par.Matrix application developer's disposal:
-
dia$par Role Tree (branching mechanism)
Role Tree, in conjunction with the rights grouping mechanism ("roles"), represents the next stage in the evolution of the classical abstraction of "rights".
"Branching" — because of depending on the presence or absence of permission, one or another "branch" of the program code is executed.
For example, the presence of a specific "permit" may allow shipment to the customer with outstanding debt.
With the help of dia$par Role Tree, you can implement way more complex access control policies. In fact, the only limitation is the fantasy of the business processes architect.
dia$par Role Tree dramatically simplifies the life of the administrator by providing him with tools such as combining several roles into one, explicitly excluding the role (semantics of "give the rights of the storekeeper without the right for stocktaking"), filter users with specified roles, etc.
- dia$par Predicate Based Access
The mechanism of predicative access allows you to specify so-called predicates (Boolean functions that return either 0 or 1).
dia$par PBA allows the administrator to formulate arbitrarily complex constraints: for example, to see only documents that the current user created or see customer accounts created by department colleagues, and edit only "his own".
And again, there are no bounds for possible scenarios.
dia$par Big Brother Center logs all data change events.
The author of changes of any object is known at any moment of time (there is enough capacity not to affect the speed of performance).
If necessary, even "view" events can be logged.
Physical layer
dia$par client terminals — from workstations to mobile terminals of storekeepers, including integration interfaces for external systems — do not have direct access to a central data repository.
Server cluster that processes the mmizer's logic is located in a separate network (usually of a remote data centre) that is not accessible to ordinary users.
dia$par does not store data in client applications at all — except for websites where locally stored data is limited to the minimum necessary information to display a functional online catalogue (in fact, by definition, public information).
dia$par.Mirror mmizer performs two functions simultaneously:
- it generates a virtual reality for the dia$par.Matrix cybernetics model
- it replicates bidirectional changes in the real organization and its cybernetic model
Sites communicate with the cluster of dia$par.Matrix M-servers exclusively through web-services. Thus, even if there is a successful attack on a web server, the attackers will not gain access to the dia$par data storage.
A client-server communication channel is encrypted by the symmetric block cipher algorithm AES, adopted as the United States standard.
Zero knowledge proof protocol is used to authenticate users thus, no password in any form (including hashes) is transmitted over the network.
