Unauthorised access tracking

[ravisuhag]

Problem? Guardian approval flow with policies makes sure only approved users get access to resources. But if someone was authorized to access directly through the provider platform e.g users are given access to Metabase through its admin portal. Guardian does not have a way to track if access is given to the provider resources which are not being tracked or approved through guardian access workflows.

Solution

• Periodically check authorized users at the provider level and track unauthorized access to resources.
• Provide reports and alerts when unauthorized access is detected.
• Raised alert severity can be based on the privacy level of resources.

[rahmatrhd]

continuing the discussion for this.

assuming we have completed these issues:

1. https://github.com/odpf/guardian/issues/246
2. https://github.com/odpf/guardian/issues/206

there are two kind of cases that we want to collect the information of:

1. accesses that are created from guardian but don't exist in the provider
2. existing accesses in the provider that are not created through the guardian

Collecting information

The current decided approach in #206 is only for fetching accesses in provider and create the accesses for them. By that, apart from the access state/mapping itself, we only have the creation source information whether the access is created through guardian with approval flow or from outside of guardian (grant=import/policy). Additional information that needs to be added is the current activeness of each access in the provider itself.

We can add an active_in_provider: boolean flag in the access entity for tracking the access activeness. This is different with status="active where status is for the access status in guardian and active_in_provider is for the current status in the provider. We can use the "import existing access" function to update this information in accesses. And since in #206 it was decided that importing existing access going to be an api-based action, maybe we can consider it to run on a job as well so that the active_in_provider information is kept up to date.

Presenting information

Options:

1. add more query parameters in the list accesses API so that client can generate report and customize by passing params
   • pros: more flexible and let the client generate their own report based on their use case
2. ~~create a new API that returns the summary of the track drift result. It can be at the provider level (GET /providers/report or GET /providers/:id/report) or resource level (GET /resources/report or GET /resources/:id/report)~~
   • pros: information is summarized, and also can show list of recommendations
   • cons: can't be customized, and the report might not suits what the user needs

[ravisuhag]

@rahmatrhd will both of these statuses live in access objects? If yes, we will have three fields to be tracked?

grant: policy/import
active_in_provider/provider_status: true/false
active_in_policy/policy_status: true/false

[rahmatrhd]

for tracking access drift, essentially we only need to track two statuses which are active_in_provider: true/false and status: pending/active/inactive (active_in_policy/policy_status). While grant is only to track the creation of the access itself (whether created through guardian (with approval) or not)

[ravisuhag]

And all these statuses are at access object or status is on appeal?

[mabdh]

if we use active_in_provider: true/false, do we assume (only track) if provider only have two states of activeness active & inactive and ignore other possible statuses (if any)?

[rahmatrhd]

@ravisuhag grant, status, and active_in_provider are in access

@mabdh makes sense, I think we can make it equivalent to access.status: pending/canceled/active/inactive

[rahmatrhd]

schema changes

- type Access struct {
+ type Grant struct {
	...
- 	Grant		string // policy | import
+ 	Source		string // appeal | import
  	Status		string // active | inactive
+ 	ProviderStatus	string // active | inactive
- 	CreatedBy	string // [email protected] 
+ 	Owner		*string // [email protected] | nil
  	...
  }

scenarios

access exists in Grant tables	access exists in provider	Grant.source	Grant.status	Grant.provider_status	doable actions	notes
✅	✅	appeal	active	active	revoke Grant
✅	❌	appeal	active	inactive	deactivate Grant OR grant access to the provider
❌	✅	import	active	active	assign Grant.owner to a user OR revoke access from the provider	will create new entry of Grant

---

1. will rename access entity to grant to avoid confusion since "access" is the main scope of guardian itself
2. rename grant to source with value appeal for grant that is created from appeal, and import for grant that is imported from provider
3. add ProviderStatus to track the status of the actual access in the provider
4. rename created_by to owner. For source=appeal Grants, the value of this field going to be the Appeal.created_by, and for source=import, initial value going to be nil until the Grant got assigned to someone