Welcome to Anubis
Anubis is a flexible Policy Enforcement solution that makes easier to reuse security policies across different services, assuming the policies entail the same resource.
Let's think of a user that register some data in platform A. To control who can access his data he develops a set of policies. If he move the data to platform B, most probably he will have to define again the control access policies for that data also in platform B.
Anubis aims to avoid that :) or at least simplify this as much as possible for the data owner.
Why this project?
Data portability often focuses on the mechanisms to exchange data and the formalisation of dat representation: the accent is rarely put on the portability of security & privacy data policies. Enabling security and privacy data policy portability is clearly a step forward in enabling data sovereignty across different services.
This project aims at enabling data sovereignty by introducing data privacy and security policy portability and prototyping distributed data privacy and security policy management, thus contributing to increase trust toward data sharing APIs and platforms.
Approaches as the one proposed, increasing control by owners over their data and portability of data assets, are key to boost the establishment of trusted data spaces.
The project is looking into
- Open standardized security & privacy data policies vocabulary.
- Linking an existing user profiling vocabulary to the security & privacy data policies vocabulary as a way to increase portability of policies and their compatibility to existing standards.
- A middleware supporting decentralised control and audit of security & privacy data policies by data owners (in the context of RESTful APIs).
- Translation from the security & privacy data policies vocabulary to other policy languages or APIs that are actually used for PEP.
Anubis is an ancient Egyptian god, that has multiple roles in the mythology of ancient Egypt. In particular, we opted for this name, because he decides the fate of souls: based on their weights he allows the souls to ascend to a heavenly existence, or condemn them to be devoured by Ammit. Indeed, Anubis was a Policy Enforcement system for souls :)
In our scenario, a client request for a resource to an API, and based on the defined policies, the client is able or not to access the resource. The figure below shows the current architecture.
┌─────────────┐ │ API │ │ Specific │ │ Rules │ └─────────────┘ ▲ 2 │ │ ┌─────────────┐ ┌──────┴──────┐ ┌─────────────┐ │ │ 1 │ Policy │ 4 │ │ │ Client ├───────►│ Enforcement ├───────►│ API │ │ │ │ Point │ │ │ └─────────────┘ └──────┬──────┘ └─────────────┘ │ 3 │ ▼ ┌─────────────┐ │ Policy │ │ Management │ │ API │ └─────────────┘
(The schema is editable at asciiflow)
- A client requests for a resource via the Policy Enforcement Point (PEP) - implemented using a authz envoy authz filter.
- The PEP pass over the request to the PDP (Policy Decision Point), provided by OPA which evaluates a set of rules that apply the abstract policies to the specific API to be protected
- In combination with the policies stored in the Policy Management API, that acts as PAP (Policy Administration Point);
- If the evaluation of the policies return 'allowed', then the request is forwarded to the API.
The User Manual and the Admin Guide cover more advanced topics.