Stories
Slash Boxes
Comments

SoylentNews is people

posted by hubie on Thursday October 06 2022, @04:49PM   Printer-friendly
from the cloud-will-bring-me-some-security dept.

Most developers aren't particularly good at building authorization into their applications, but would they trust a third-party provider like Oso?:

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."


Original Submission

 
This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by bloodnok on Thursday October 06 2022, @06:28PM (3 children)

    by bloodnok (2578) on Thursday October 06 2022, @06:28PM (#1275291)

    I found myself unable to either properly understand or take seriously, the fine article.

    Security as code sounds great but IIUIC it tackles the security of a process. For me (I'm a relational database guy) the thing that you need to secure is the database. If your database won't let you do things you are not authorised for, then it pretty much doesn't matter how crappily your application is implemented.

    Of course, securing your database is not easy, and most implementations do it by attempting to secure the applications that connect to it. This generally means that your application has the rights to do pretty much anything in the database, which in turn means that security bugs anywhere in the application infrastructure can be catastrophic.

    With microservices the problem can be worse because you have to secure each service.

    If we could just ensure that the database knows who is using the service and let the database protect itself, life might get easier. Enter Relational Security: https://marcmunro.github.io/veil2/html/ch01.html [github.io]

    I think it makes sense but I'm retired and never got to deploy a Veil2-based system in anger. If anyone's interested in trying it, I'll try to help out.

    __
    The Major

    Starting Score:    1  point
    Moderation   +3  
       Insightful=1, Interesting=1, Informative=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by RS3 on Saturday October 08 2022, @11:31PM (2 children)

    by RS3 (6367) on Saturday October 08 2022, @11:31PM (#1275607)

    I'm not a DB expert by any means, but I admin some servers that include WordPress which is based on and in mysql. Upcoming soon new server build will use mariadb. (For those who don't know, mysql is pretty much owned by Oracle, so mariadb is an independent fork).

    Like most (all?) database "engines", mysql (mariadb) can contain many completely independent databases (and many tables within them).

    mysql requires an authentication before a process gets access to data. Each WordPress site has a login (name & password) and can only access the database for which that login has access. Access rights can be "granted" to other users if needed.

    There is a default "root" user whose password needs to be well protected.

    I'm not sure if that answers your concerns about databases and access rights, but if it doesn't, please ask any questions- we'll both learn.

    • (Score: 3, Informative) by bloodnok on Thursday October 20 2022, @05:58PM

      by bloodnok (2578) on Thursday October 20 2022, @05:58PM (#1277569)

      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:

    • (Score: 2) by bloodnok on Thursday October 20 2022, @06:03PM

      by bloodnok (2578) on Thursday October 20 2022, @06:03PM (#1277570)

      Hmmm, that last post got away from me. The reference I meant to provide was this: https://marcmunro.github.io/veil2/html/ch01.html [github.io]

      __
      The major