Hi Job, group, world You said you would welcome my thoughts...so here they are...I know the data model is a taboo subject. But I hope you and others will actually read this email and think about what I said. It is quite clear that every time I mention it with other matters in any email the bit where I mention the data model is cut out of replies, never discussed, never even acknowledged. I am starting to believe my own conspiratorial theories about why the small group of people who 'control' the development of the RIPE Database don't want a simplified data model so that new members (commercial competitors?) don't need a full day course to learn how to make the most basic entries, and still get it wrong. This model was designed way back in the 90s. It has passed it's sell by date and is no longer fit for purpose in the 21st century. We are constantly dancing round the constraints of this old design. Instead of fixing the root cause we keep trying to invent ever more complex high level solutions to bolt on top of a bad design. Security of data and permissions in the RIPE Database is one of these areas that is fundamentally broken and cannot be fixed with this data model, no matter how many tweaks you make. Who else, but the RIRs, publish to the world so much detail about how you manage and secure your data? Do you see Google, Apple, Microsoft, Facebook, Twitter, Yahoo, Anyone publishing details of their users accounts? There are basically two types of data in the RIPE Database: Operational data - the stuff this public registry exists to record and publish along with details of who to contact if you have any issue with any operational data. Management data - the details of how you, as an individual or corporate entity, manage your operational data in this database. This includes details of your security credentials, who has permission to do what, who gets notified when things happen, etc. So the MNTNER object for example is clearly management data. Who, outside of your organisation, needs to see anything in your MNTNER object? Why do we tell the world that you have 3 passwords, 2 PGP and 4 SSO accounts managing your data? Why do we tell everyone who has permission to create more specific customer operational data in the database for your organisation ("mnt-lower:")? Why do we let the world know that you have not set up any notifications so you will not notice if this data is changed? A few years ago I did a presentation to Wilfried and Nigel about how easy it would be to separate the operational and management data in the database so that the whole of the management data could be hidden. User accounts for organisations/people who manage the operational data could be created to manage security, permissions, notifications, audit trails, etc. I even showed how it could be done in a backwards compatible way so that no one would be forced to change anything. I even threw in significant improvements using inheritance in a backwards compatible way. But then for a year or so I was not in a position to discuss any database issues publicly so the whole idea ground to a halt. If you are serious about improving security, the time has come to stop dancing round these issues with ever more complex solutions and address the problems head on. All I am proposing is that members/users/interested parties acknowledge that the data model is old and could be improved and be willing to seriously discuss the possibilities. If you are willing to throw off the constraints of this old model many new and improved possibilities open up. cheers denis On 01/12/2015 13:52, Job Snijders wrote:
Hi Denis, group,
On Tue, Dec 01, 2015 at 01:23:21PM +0100, denis wrote:
You now have a situation where updates using the API must be done with a password, updates done with Webupdates must be done with SSO and updates done by email should be done with PGP. So you have actually increased the complexity of the already over complex authorisation model.
This is an excellent summary, I wonder what a good way forward would be. Possibly enable PGP authenticated API access? Or introduce a concept of "API Keys" which a user can tie to an application and for instance restrict which source IP addresses are allowed to use that key? I welcome your thoughts on this matter
Kind regards,
Job