Re: "While I'm not saying that multiple DB-level users and DB-level access controls are the wrong solution, I would ask up-front what specific real-world problem is being solved by this, and whether it really is the best solution."
At the company I'm currently working for, we have a 'sister' company, which we receive some data. For legal purposes, they must 'own' that data, and it must reside on separate database servers. The web app I'm creating for the my company (which will also be used as a tool by our 'sister' company), has the need to view/update data from both databases. Just wanted to give a real-world scenario in response to the question On May 10, 1:35 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > It's a tightly modelled, configurable, business administration tool. > > If used in a business of significant size, I would expect and hope > > that a DBA was employed to administer the database. Many of the tables > > will contain information that is restricted (sometimes with different > > scope for readability and editablility) to various roles which are > > mapped to individuals or groups in the organisation. > > While I'm not saying that multiple DB-level users and DB-level access > controls are the wrong solution, I would ask up-front what specific > real-world problem is being solved by this, and whether it really is > the best solution. > > Rambling historical anecdote: > > Many large organizations have IT policies which require users to > change their passwords every so often, usually once every 30 or 90 > days. This is touted as a security requirement for sensitive data, and > it's rare that anyone asks what actual security problem the password > changes solve. As it turns out, the origin of this recommendation was > an analysis of how long it would take to brute-force a password on a > 1970s-era mainframe -- the recommended period for changing passwords > was set to be shorter than the time it would take to try every > possible password. > > Modern systems are far faster, and brute-forcing a password can now be > a matter of hours or even minutes. Newer, stronger methods -- such as > better physical and network security controlling access to the system, > and "locking out" a user after a relatively low number of failed login > attempts -- now mitigate this risk far more effectively than any > "change your password every X days" policy. Additionally, such a > policy actually increases the risk of a breach -- frequent password > changes encourage users to choose weaker passwords, or to write down > their passwords and leave the information in easily-accessible places. > > But most companies still have a mandatory password-change policy, > because the organizational inertia of "we've always done it that way, > and everybody else does it that way" discourages questioning. > > Similarly, I have a feeling that segregation of databases and the sort > of access controls you're proposing have their roots in much older > systems where users had more or less direct access to the database > server and this was the most effective way to manage the users. > > But modern applications almost invariably introduce a mediating layer > between the user and the database, effectively moving access controls > to another layer of the stack. For example, in a web application a > user can only access data through the interface exposed by the > application; there's no way to "drop down" and avoid that layer. This > means that the application can control access and hide implementation > details in much the same way as database-level views and stored > procedures. > > This is why so many web applications use only a single logical > database, and access it through a single database-level user; the > application logic should already be taking some access controls into > account (for example, if the user isn't allowed to view records from a > particular table, the application should never even display an option > to do so) anyway, so moving more access-control logic to the > application layer becomes a more attractive option. > > Moving access-control logic "up the stack" into the application layer > also increases the flexibility you have when designing and optimizing > the database (since you're not bound to a particular design from the > start), and allows easier modification of the application; with > pass-through authentication and DB-level segregated access, any change > to the authentication scheme must occur in two places: first, the > change must be made in the database layer, then corresponding changes > must be made in the application layer. By contrast, keeping as much > access-control logic as possible at the application layer means that > you have a single place where changes can be made (and remember that > application-level changes are often easier to manage than > database-level changes); this is the DRY principle at work. > > Given that, it's worth asking whether the solutions you're proposing > are still the most effective, or whether they've reached the > organizational-inertia stage of "we've always done it this way". > Relying heavily on database-level access controls and segregated > databases may be a good fit for a particular application, of course, > but the best thing to do is determine that up-front before making an > architectural decision; committing to it will significantly increase > the complexity -- and, by extension, the cost both for development and > maintenance -- of the application, and if you can avoid that > complexity you should. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
