SoylentNews is people
SoylentNews
from the cloud-will-bring-me-some-security dept.
It's increasingly evident that for security to work, security must be baked into the development process — not a bolt-on afterthought that a dedicated security team manages. This newfound appreciation for developers' roles in security has given rise to things like DevSecOps as well as open source projects like Oso.
Oso, which just announced today the general availability of Oso Cloud, offers an open source policy engine for authorization that represents security as code so developers can express security as a natural extension of their applications.
[...] Authorization is hard to get right, and while crucially important, it's not necessarily central to anyone's business. As such, authorization tends to be something that every company requires yet often goes about in ineffective ways. Arguably, it's time we stop thinking about authorization, or security in general, as an off-the-shelf product that someone can buy, and more about a new model or mindset that developers must apply.
[...] This brings us to authorization. Authorization has so far evaded becoming a third-party service offering, largely because no one has been able to make it generic enough to be broadly relevant while still being flexible enough to be useful. Oso thinks it has cracked that code.
[...] Some developers, Neray said, may have heard of RBAC or ABAC. More cutting-edge developers may have heard of Google's Zanzibar. None of these really handle the core problem. What does work, Neray continued, is to think of authorization as composed of three core abstractions — logic, data and enforcement — and "once you understand how each of them works, you can build (or adopt) structured solutions that let you bend authorization to your will."
In practice, this means it's a bit like SQL, where if you put your data in a standard format and give it a schema, you can then query it arbitrarily. In a similar manner, in Oso you put your authorization data in a standard format, write arbitrarily simple or complex authorization logic, and then can ask any question you want.
[...] But really, it comes down to whether a little bit of trust is worth the removal of a lot of bother from your application infrastructure. As Oso co-founder and CTO Sam Scott stressed: "Our vision is to decrease the amount of time and brain calories that developers spend thinking about authorization by 10x in the next 10 years."
(Score: 3, Informative) by bloodnok on Thursday October 20 2022, @05:58PM
Thanks for this. And yes I understand about authenticating to a database as a database user. The problem is that this is way too coarse a level of authentication. For fine grained access controls in the database you need access rights based on the person that is using the service rather than a blanket authorisation for the service itself. What I mean is that if Alice is using service X, the database needs to know that it is Alice and not X that is making requests.
No database that I know of can do this. This is why I developed veil and https://github.com/marcmunro/veil2 [github.com]
. If you try to create a database account for each user (even just switching roles), you encounter a number of problems:
1) the resources required per database user are not insignificant and you can expect performance problems once you get into thousands of accounts;
2) having your service switch database accounts for each new request tends to be very slow;
3) switching database accounts (or roles) tends to invalidate any process level caching that has been done.
And even if you could get reasonable performance from a scheme like this you would still need to implement the details of the security system. For instance, Alice should be able to see her own records, but not Bob's. This means that you have to implement row-level security. I have tried to do this using roles in both PostgreSQL and Oracle and it is a horrible task. You really need a framework for managing this sort of thing, and again I'd point you at Veil2. This section of the Veil2 documentation should clarify things a little: