On Fri, Feb 20, 2009 at 9:02 AM, MARK CALLAGHAN <[email protected]> wrote:
> Do web apps need access control? They do. > Stewart has a blog post with the > statement that they don't and that access control is to be done at the > app server. Well, then they still have access control, it's just at the app server. The discussion provided has been pushing the access control to the database server. Are you asking if the access control logic should be in the web application layer? > I don't support a web app. I have to deal with audits and > all of the other fun stuff. But I suspect that at some point many web > apps must also deal with audits if they store personal data which is > subject to many rules in many countries. If you do it in the app server layer, and someone compromises the app server they have all the login information for all the users. There isn't really a way to prevent this (similarly, if someone breaks into a web server and can read the code, they can probaby read the include files or whatever where the access control information is stored). Has anyone here undergone an audit for 'web app' personal data? > In such an audit has access control at the app server been sufficient? > Are managers at such a company comfortable that anyone (such as a > disgruntled employee) with access to the db can read all customer > data? >From 2005-2007 I worked for a popular online dating site, taking in hundreds of thousands of dollars per week, and where I got subpoenad to handing over information for everything from divorce cases, to murder cases and federal cases that the DEA (drug enforcement agency). We did have to go through a PCI compliance audit. Security was taken pretty seriously. Very few people actually logged into the database to retrieve information. Personal information, such as credit card data for recurring payments, and even names and addresses were all encrypted before hitting the database. This made searching for information when we were only given addresses or legal names a pain -- I had to export the encrypted data, decrypt, search, and destroy the decrypted information once my search was over. (it was far better when they gave us a username). Note that once a web app gets big and needs to make some money there > will be just as much internal access to the database as there is > user-facing access and the internal access won't go through the web > app. The internal access will be large queries used for monetization. > And those queries are the ones that might not be allowed access to the > user's personal data. I'm not sure what you mean by "just as much internal access...as user-facing access" -- there are far more users than internal folks, but internal folks have far more powers. Our internal access was that one developer, the systems administrator(s) and the DBA(s) -- we're talking maybe 6 people total, for an active user base of 1 million customers (paid and free) -- had full rights to the database. Marketing and Customer Service representatives used a web interface, and it was mostly Marketing that did the queries for monetization. But Marketing didn't need personal information to run those queries -- just location, which was part of a user's profile (ie, Boston MA), and payment history (ie, if someone gets a free month how likely are they to buy at the end of that free month?) -- - Sheeri K. Cabral http://tinyurl.com/mysqlbook will take you to the Amazon.com page for my upcoming book, "MySQL Administrator's Bible".
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
