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: 5, Funny) by istartedi on Thursday October 06 2022, @05:39PM (1 child)
Most developers aren't particularly good at building simplicity in to their applications, but would they trust a 3rd party provider like Cachorro?
It's increasingly evident that for simplicity to work, simplicity must be baked in to the development process -- not a bolt on afterthought that dedicated developers manage. This new found role of developers roles in simplicity has given rise to things like ContainerizedDecentralizedNetworkOperationalStorage as well as open source projects like Cachorro.
Cachorroa, which just announced today the general availability of chmod, offers an open source policy engine for simplicity that represents simplicity as giving your wallet to Snake, because he's the Wallet Inspector.
Simplicity is hard to get right, and while crucially important it's not necessarily central to anyone's business. As such, simplicity tends to be something that every company requires yet often goes about in ineffective ways. Arguably it's time we stop thinking about simplicity, or simplicity 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 simplicity. Simplicity has so far evaded becoming a third party service offering, largely because no one has been about to make it complex enough to be broadly relevant while still being flexible enough to be useful. Cacharro thinks it has cracked that code.
Some developers, DJ said, may have heard of ZWIBAC or TABAC. More cuting-edge developes may have heard of Google's Stadia. None of these really handle the core problem. What does work, Joe siad, is to think of simplicity as composed of three core abstractions -- growth, development, and change -- and "once you understand how each of them works you can build (or adopt) structured solutions that let you bend simplicity to your will".
In practice, this means it's a bit like INTERCAL, where if you put your data in a standard format and give it a schema, you might accidentally launch a nuclear attack on Greenland. In a similar manner, in Cacharro you put your simple code in a standard format, write arbitrarily simple or complex logic, and then can ask any question you want.
But really, it comes down to whether a little bit of simplicity is worth the removal of a lot of bother from your application infrastructure. As Caharro co-founder and CTO Sam Ligma stressed, "Our vision is to decrease the ammount of time and brain calories that developers spend thinking about simplicity by 10X in the next 10 years"
Appended to the end of comments you post. Max: 120 chars.
(Score: 0) by Anonymous Coward on Thursday October 06 2022, @06:01PM
"Our vision is to decrease the amount of time and brain calories that developers spend thinking"
(Score: 5, Insightful) by bloodnok on Thursday October 06 2022, @06:28PM (3 children)
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
(Score: 2) by RS3 on Saturday October 08 2022, @11:31PM (2 children)
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
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
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
(Score: 2, Informative) by Anonymous Coward on Thursday October 06 2022, @06:45PM (1 child)
Third party is not secure, by definition. Many times even the second party is suspect
(Score: 4, Informative) by Rich on Thursday October 06 2022, @08:48PM
Maybe if the third party is financially independent buddhist monks in Switzerland who have an urge to further the greater good from meditating over the mantra "Everyone's abilities to everyone's needs." for ten years.
But even then we couldn't be sure that it's not just an In-Q-Tel front pretending to be financially independent buddhist monks in Switzerland who have an urge to further the greater good from meditating over the mantra "Everyone's abilities to everyone's needs." for ten years...
(Score: 4, Informative) by ilsa on Thursday October 06 2022, @07:20PM (1 child)
I'm so sick of the entire XYZOps umbrella. Every time I see anything Ops, I now automatically assume some jackass is trying to peddle yet another silver bullet to people who really have no idea what the problem space even is. And that tool does absolutely nothing but add yet another leaky abstraction layer instead of just doing what you should have done in the first place.
DevOps was nothing more than a marketing term some cheapskate companies came up with in an attempt to save money by expecting the same people to fill both the Developer _and_ operations roles, while incredulously not even giving them the necessary training to do it. They just slap a "DevOps" label on everything and expect it to magically work.
DevSecOps? I want to say it will be hilarious how badly people fuck _that_ up, but we are already seeing exponential increases in the number of successful hacking attempts against companies, and DevSecOps is just going to make it even worse. And the people who suffer will be the people there never even had a say in the matter.
(Score: 5, Informative) by Opportunist on Thursday October 06 2022, @10:45PM
Same bullshit as "agile", which essentially only means in most cases "we eliminate the few managers who actually did their job and cut the red tape, now engineers who would have better things to do need to waste time on it".