blob: ab2e8f1aacb6f314e848d486d344a46b6c05a3b4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
# Policy
> Policy is a planned system of rules and guidelines that directs users and automation to execute within purposeful boundaries. [1][1]
The parts of a policy include: [1][1]
* name: used to label the policy for future reference
* purpose: the reason this policy exists
* situation: the context in which the policy will be used
* rules: individual controls or prescribed behaviours;
* actions: action taken if a policy rule is violated
> A policy is a statement that declares which principals are explicitly
> permitted, or explicitly forbidden, to perform an action on a resource. - [2][2]
## Policy Language
A policy language facilitates: [3][3]
1. the specification of composite policies, which in turn forms the basis of trust delegation.
1. **the static analysis of policies and system configuration.**
### Policy as Code (PaC)
These are policies that are written, stored, managed and interpreted as code
artifacts.
> A policy engine is a program or process that is able to ingest
> machine-readable policies and apply them to a particular problem domain to
> constrain the behaviour of network resources. [1][1]
PaC policy engine characteristics: [1][1]
* Ingeting machine-readable policies (PaC)
* Applying policies to specific problem domains (data)
* Constraining behaviors (outcomes)
```plaintext
----------
| Policy |--------- A
---------- | / \
V / \
-------- --------- / \ -------------- --------
| Data |------>| Input |--->< match >--->| Evaluation |--->( Outcom )
-------- --------- \ / -------------- --------
A \ /
--------- | \ /
| Query |---------- V
---------
```
Selection Criteria: [1][1]
* Alignment
- Technical Capabilities of team.
- Internal strategy for how tools and applications are adopted/managed.
- Fits the need and internal standards driving the decision
- Primary use cases match our use cases
* Analytics
- logging
- metrics
- auditing
* Automation
- CI/CD Pipelines
- Automated Deployments
* Documentation
- Examples
- Patterns
- Understandable
* Adoption
- Who is using this?
- How much adoption has this project seen?
- Active?
- Project Maturity
- Support Model
- Intuitive
* Complexity
- Installation
- Deployment
- Configuration
- Operation Modes (server, library, CLI)
* Reporting
* Standard reporting tools e.g. [OSCAL](https://pages.nist.gov/OSCAL/)
* Security
* Risks, vulnerabilities
* Tools and processes for security issue discovery
* Extensibility
* Can custom code be written to extend the language.
Scorecard [1][1]
| Selection Criteria | Casbin | Cedar | Rego |
| ------------------ | ------ | ----- | ---- |
| Alignment | | | |
| Analytics | | | |
| Adoption | | | |
| Automation | | | |
| Documentation | | | |
| Complexity | | | |
| Reporting | | | |
| Security | | | |
| Extensibility | | | |
| Total | | | |
### Cedar
### Rego
[Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) is a declarative assertion language that provides reasoning. This is a DSL
for applying reasoning and assertions to domain-agnostic, structured data.
* [Regorus](https://github.com/microsoft/regorus)
* [Go binding](https://github.com/microsoft/regorus/tree/main/bindings/go)
* [Ruby binding](https://github.com/microsoft/regorus/tree/main/bindings/ruby)
## See Also
* [Zanzibar](./ZANZIBAR.md)
* [Dafny](https://dafny.org)
* [Policy as Code by Jimmy Ray][1]
[1]: https://learning.oreilly.com/library/view/policy-as-code/
[2]: https://docs.cedarpolicy.com/overview/terminology.html#term-policy
[3]: https://ucalgary.scholaris.ca/server/api/core/bitstreams/833a86a8-eb7f-4c50-af4d-696b8deb6fd8/content
|
