Access control systems need to provide two fundamental use cases: ● Making access decisions check ( Principal, Operation, Resource ) = allow/deny ● Configure access policies Access Control at a glance Who What (Authenticated Principal)
Access Control at a glance Access control systems need to provide two fundamental use cases: ● Making access decisions check ( Principal, Operation, Resource ) = allow/deny ● Configure access policies ○ Types of policy ■ Role based ■ Attribute based ■ Discretionary access ■ ... ○ Policy APIs ○ Policy language Who What (Authenticated Principal)
Role Based Access Control (RBAC) ● Easy to understand ● Easy to author correct policy ● Brittle, hard to model everything (role explosion!) Access Control systems Attribute Based Access Control (ABAC) ● Hard to understand ● Hard to author correct policy ● (Infinitely) flexible, easy to model anything
Access Control systems NGAC has the flexibility of ABAC, but has a set of guardrails that keep it structured and understandable. Role Based Access Control (RBAC) ● Easy to understand ● Easy to author correct policy ● Brittle, hard to model everything (role explosion!) Attribute Based Access Control (ABAC) ● Hard to understand ● Hard to author correct policy ● (Infinitely) flexible, easy to model anything
Next Generation Access Control (NGAC) Developed by NIST ● By David Ferraiolo and team at NIST Works by closely modeling the system under control in a graph ● Model the Users and Objects in the system, and their relations, directly ● Policies you write create new relations (edges in the graph) ● Makes access control decisions by walking the graph Can compute a policy decision across many classes of policy in a single pass ● e.g. RBAC + Location + Time ○ “SRE team members can READ, WRITE the service” ○ “US employees cannot read data stored in the EU” ○ “contractors lose access after 3 months” Audit and Explain ● Why a policy decision was made, before or after the fact
Example The following example shows a simple NGAC graph with: ● A User DAG representing an organization structure ● Object DAG representing files and folders in a filesystem, and a categorization of the files ● Two different policies - file system and scope - that can be combined to make access decisions. ● The association edges between the two DAGs define the permissions the actors have on the target resources.
Why NGAC? ● Policy modeling capabilities ● Ease of Administration ○ Administrative policies can be modeled directly in NGAC ○ Policies live in the same graph as user-policies ○ First-class delegation ■ Uniform access control over resources as well as admin data ■ We can write policy that governs federation ● Decision-time Performance ● Policy Review
Why NGAC? ● Policy modeling capabilities ● Ease of Administration ● Decision-time Performance ● Policy Review ○ Audit (incl. “before the fact”): see what resources are (will be) affected by a policy ○ Explain: understand why a particular access was allowed, in human-readable terms; eg: ■ “Nic was allowed access because: ● He is a member of group A which has RBAC policy B (authored by Zack on Sep 1, 2021) granting permissions X,Y,Z on container C, which contains the target resource Foo ● He is a member of group F which was granted a location based policy G (authored by Varun on August 27, 2021) which grants permission X on container H, which contains the target resource Foo ● Only location and RBAC policies applied, therefore Nic is able to take action X on target resource Foo.”
NGAC Architecture PEP- Policy Enforcement Point PDP - Policy Decision Point EPP - Event Processing Point PAP - Policy Administration Point PIP - Policy Information Point RAP - Resource Access Point
NGAC Architecture 1. A process attempts to gain access to a resource via a PEP 2. The PEP issues an access request to a PDP for adjudication 3. The PDP queries the PAP for policy information needed to compute an access decision 4. The PAP issues the requisite commands to the PIP to retrieve the information 5. The PAP returns the queried information to the PDP; 6. The PDP renders a decision on the access request, resolves the resource location (only for a positive decision), and returns the decision and locator to the PEP; 7. The PEP issues a directive to the RAP associated with the resource to carry out the access; 8. The RAP carries out the operation on the resource and receives the status information and result data (if any); 9. Status information and data (if any) are returned from the RAP to the PEP; and 10. Status information and data (if any) are returned from the PEP to the process.
NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US Policy Classes User Attributes Users Object Attributes Objects Associations
Benefits and Use cases Benefits ○ Single Policy framework for Organization ○ Capabilities: ABAC, LBAC, RBAC -- all into one Use cases ○ Can compute a policy decision across many classes of policy in a single pass ○ e.g. RBAC + Labels + Location + Time ■ User X with clearance Y can view data from streaming service ■ User X from US Eng, can access table X and row Y ■ User X above a rank from US Eng can access the folder but not a specific file
A Service Mesh enables cross- cutting change A mesh allows for centralized control with distributed enforcement. Central teams can manage policy on behalf of the org. NIST SP 800-204A
Envoy is a universal Policy Enforcement Point Envoy intercepts all traffic and can apply policies at the application layer. It is a reference monitor. NIST SP 800-204B
NGAC Architecture PEP- Policy Enforcement Point PDP - Policy Decision Point EPP - Event Processing Point PAP - Policy Administration Point PIP - Policy Information Point RAP - Resource Access Point
Collaboration with NIST ● CRADA for the application of Next Generation Access Control (NGAC) ○ as well as NDAC (NGAC over Database Queries) ○ INCITS 499-2018 ● Collaboration on Microservice Security Standards (SP800-204 series) ○ SP800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture ○ SP800-204B (public draft): Attribute-based Access Control for Microservices-based Applications using a Service Mesh ○ SP800-204C (upcoming): Application of DevSecOps using a Service Mesh in Microservices-based Infrastructure ● Co-hosted conferences with NIST: ○ Jan 2020: Identity Management & Access Control in Multiclouds Workshop and Conference ○ Jan 2021: DevSecOps and Zero Trust Architecture (ZTA) for Multi-Cloud Environments
TSB - NGAC in production now ● Tetrate Service Bridge (TSB) is the PIP, NGAC the PDP, and Envoy the PEP ● Tetrate Service Bridge uses NGAC to enforce user access to service mesh config and operations ○ Imports data from existing identity providers (LDAP, AD) ○ Unifies user data with observed runtime services and workloads ○ Enforces user access to TSB with Envoy PEP, per NIST SP 800-204B, with RBAC and time based APIs ● Will use NGAC to implement service-to-service authz by EOY ○ Gain benefits of NGAC’s audit and explain ○ Implement runtime enforcement via existing Envoy filters
nacx
line_developers
sat
sbtechnight
sakaik
tsubakimoto_s
renjikari
harukasakihara
okunokentaro
eliasnogueira
foursue
addyosmani
tanoku
geeforr
sachag
rmw
searls
hatefulcrawdad
holman
scottboms
destraynor
akmur
jennybc