9 Replies
No, but they are restricted under the same persmissions granted
Any actions done via their API Key will be logged under their account in audit
I'll be quite frank here but that does not seem secure in the least to be honest with you.
There are countless instances where you'd want people to have access to GDRP protected information like IP-addresses in the context of their responsibilities whilst using BM but you by no means would ever want to grant them the ability to export said data through an API where it can be distributed without prior consent or used in contexts in which it shouldn't be.
It seems reckless not even having the minimum amount of safeguards granting the ability to restrict that through roles.
It's primarily a problem of logistics. The user needs API access in order to use the site itself. The only reasonable restriction we could put in place would be to try and differentiate between browser traffic and non-browser traffic. The exercise is kinda futile though since there are many ways to fake a browser to gain the same level of access.
If we force them into the browser impersonation route it would undermine the quality of your audit logs since you would no longer be able to tell what was automated vs what was viewed with their own eyes (both would appear under the "website" category)
As for the IPs, are you not using hashed identifiers for these low-trust admins?
I can see your point, but I'm sure you can also see where I'm coming from. And for those, yes we do. But that's only a temporary phase till people grow into their full moderation capabilities. That still doesn't mean that cause we trust them within the confines of the website to use that information, that we'd be comfortable with any of them building out tools which allows them to extract the entirety of the dataset we have, that should be a right only granted to very select individuals for very specific tasks I feel like.
I completely understand the concern. It's just a difficult problem to actually "solve" since there will inevitably be a way around whatever we do
Somewhere trust has to come into the equation
and perhaps NDAs with your staff to keep them on a leash
I'll definitely have to re-evaluate and look how we can adopt a more secure way of working. I appreciate the response.
For sure. If we can find some reasonable restrictions that don't have major drawbacks, I'm all ears as well.
For now we at least have some mechanisms in place for monitoring this user activity
Without having the knowledge of how your infrastructure works its kind of hard to do so but the lowest hanging fruit to me would have seemed to have an option in the roles creation that allows a role to create an API key or not. That'd be my initial thoughts but again without a clearer picture its hard to make suggestions.
Simply put, the way the system works, everything is run off API.
This includes the full website.
So when you log on via website, your login is assigned an API Key which has permissions to access the orgs they have,
The org owner then sets the permissions on what they can & can't do within the org.
That same permission is accessible via the API Endpoint also.
Which as hordicus stated, it's hard to restrict, even if you restrict key creation, they could still do it via browser emulation as they both run via the API Backend.