When previous devs at my company had to store sensitive user data (for example, medical records), they did the following. I doubt its merits.
There is data considered "insensitive" (user login, profile info), and "sensitive" (user medical records).
There are three databases. Insensitive data in A, medical records in B, and the mapping between A and B in C.
A hacker must hack all three databases to tie users (A) to medical records (B).
Our own backend code calls C to tie A and B data together for user display. I think the ubiquity of this code invalidates the benefit of splitting databases: if the hacker accesses our system, he can call our logic.
What benefits of the above system am I missing (or are there better ways to secure such data)?
I'd say that once your system has been compromised and the assailant is past the threshold with access, then the databases are just a matter of time. What it is doing is at least perhaps delaying to intruder in their intent - but the cost (in terms of maintenance, performance, project clarity and so on) might outweigh the benefits.
I'm sure there will be sufficient information for a determined person to decide that X, Y and Z databases are linked - unless you obfuscate database names, table names and other structural indicators.
Ideally you should be looking to make your system impenetrable, all other things beyond that are mitigations, the treating of symptoms with neglect for the problem (that you've been exploited), of which the trade-off must be considered uniquely to the situation.
In my experience and opinion, splitting the database like this is a strangely contrived approach to security that I find to be ingeniously silly.
In response to the general question "is splitting databases a legitimate security measure", isolation is indeed a well-known, useful tool for implementing security. Whether its benefits outweigh its drawbacks (generally, additional complexity) is very much situation-specific and I don't know the answer in your system's case.
Suppose for example that someone wanted to build an analytics application on top of your data. It would be very useful to have the mapping data completely out of the picture. If the analytics app is breached, the mapping information is not at risk.
Responding to some comments below, even in your system's specific case, it's not a foregone conclusion that "breaching the system" amounts to breaching all databases at once. Suppose that an attacker exploits a SQL injection vulnerability in your application. If the mapping data is separate and hardened (extra controls on code that accesses mappings, say), then isolation can be the difference between exposing unassociated data and associated data.
Not arguing that it is a good design for your system. Just trying to explain different kinds of rationale that can go into this.
I'm using the same isolation strategy in a similar situation. The "databases" in my case are configuration repositories. All of the preprod configuration goes in one repo and the production config goes in a separate repo. All developers have access to the preprod repo, but only release engineers have access to the prod repo. The rationale is that I want defense in depth: while I could certainly implement access controls on the individual repo folders, I'd rather make the production config simply network-unreachable to all unauthorized staff.
Yes, splitting data into separate stores can help security. As James Anderson writes, most database systems allow you to grant different privileges on individual tables.
However, most security analysis looks for the weakest link; I doubt whether your weakest link is the way your databases are split out. So, unless you've nailed down a whole bunch of other things - password management being an obvious one, SQL injection attacks another - at best, the database design is pointless; at worst, it is adding complexity to the application which causes bugs; most security vulnerabilities come from bugs.
It can also lead to a false sense of security - "we're covered on security, we split our databases", or a cavalier attitude to securing the "non-sensitive" data.
Oh, and if you decide that the user's login credentials are "not sensitive", you're basically giving an attacker the option of simply impersonating legitimate users of the system to steal your data once they have penetrated your "non-sensitive" data store.
On most serious DBMS systems you can control access at table (sometimes even row level).
So storing the sensitive data in separate tables is a valid way for restricting the access to the confidential data.
While nothing will protect you from a hacker who gets root (as other posters have pointed out). But this strategy will protect you from unauthorized users within your system gaining access, and, by extension from hackers who have obtained their userids and passwords. As spoofing low level employees into giving password details is still one of the commonest "attacks" this is well worth doing.
The big "if" is can you really split your users into "have access" and "have limited access" groups?
Related
I want to learn how practical using an LDAP server (say AD) as a storage base. To be more clear; how much does it make sense using an LDAP server instead of using RDBMS to store data?
I can guess that most you might just say "it doesn't" but there might be some reasons to make it meaningful (especially business wise);
A few points first;
Each table becomes a container entity and each row becomes a new entity as a child. Row entities contains attributes for columns. So you represent your data in this way. (This should be the most meaningful representation I think, suggestions are welcome)
So storing data like a DB server is possible but lack of FK and PK (not sure about PK) support is an issue. On the other hand it supports attribute (relates to a column) indexing (Not sure how efficient). So consistency of data is responsibility of the application layer.
Why would somebody do this ever?
Data that application uses/stores closely matches with the existing data in AD. (Users, Machines, Department Info etc.) (But still some customization is required to existing entity schema, and new schema definitions are needed for not very much related data.)
(I think strongest reason would be this: business related) Most mid-sized companies have very well configured AD servers (replicated, backed-up etc.) but they don't have such DB setup (you can make comment to this as much as you want). Say when you sell your software which requires a DB setup to these companies, they must manage their DB setup; but if you say "you don't need DB setup and management; you can just use existing AD", it sounds appealing.
Obviously there are many disadvantages of giving up using DB, feel free to mention them but let's assume they are acceptable. (I can mention more if question is not clear enough.)
LDAP is a terrible tool for maintaining most business data.
Think about a typical one-to-many relationship - say, customer and orders. One customer has many orders.
There is no good way to represent this data in an LDAP directory.
You could try having a mock "foreign key" by making every entry of that given object class have a "foreign key" attribute, but your referential integrity just went out the window. Cascade deletes are impossible.
You could try having a "customer" object that has "order" children. However, you've just introduced a specific hierachy - you're now tied to it.
And that's the simplest use case. Once you start getting into more complex relationships, you're basically re-inventing an RDBMS in a system explicity designed for a different purpose. The clue's in the name - directory.
If you're storing a phonebook, then sure, use LDAP. For anything else, use a real database.
For relatively small, flexible data sets I think an LDAP solution is workable. However an RDBMS provides a number significant advantages:
Backup and Recovery: just about any database will provide ACID properties. And, RDBMS backups are generally easy to script and provide several options (e.g. full vs. differential). Just don't know with LDAP, but I imagine these qualities are not as widespread.
Reporting: AFAIK LDAP doesn't offer a way to JOIN values easily, much the less do things like calculate summations. So you would put a lot of effort into application code to reproduce those behaviors when you do need reporting. And what application doesn't ultimately?
Indexing: looks like LDAP solutions have indexing, but again, seems hit or miss. Whereas seemingly all databases out there have put some real effort into getting this right.
I think any serious business system's storage should be backed up in the same fashion you believe LDAP is in most environments. If what you're really after is its flexibility in terms of representing hierarchy and ability to define dynamic schemas I'd suggest looking into NoSQL solutions or the Java Content Repository.
LDAP is very usefull for storing that information and if you want it, you may use it. RDMS is just more comfortable with ORM systems. Your persistence logic with LDAP will so complex.
And worth mentioning that this is not a standard approach -> people who will support the project will spend more time on analysis.
I've used this approach for fun, i generate a phonebook from Active Directory, but i don`t think that it's good idea to use LDAP as a store for business applications.
In short: Use the right tool for the right job.
When people see LDAP you already set an expectation on your system. Don't forget that the L Lightweight. LDAP was designed for accessing directories over a network.
With a “directory database” you can build a certain type of application. If you can map your data to a tree like data structure it will work. I surely would not want to steam videos from LDAP! You can probably hack something but I would prefer a steaming server..
There might be some hidden gotchas down the line if you use a tool not designed for what it is supposed to do. So, the downside is you'll have to test stuff that would have been a given in some cases.
It's not is not just a technical concern. Your operational support team might “frown” on your application as they would have certain expectations/preconceptions based on your applications architectural nature. Imagine their surprise if you give them CRM system (website + files and popped email etc.) in a LDAP server as database to maintain.
If I was in your position, I would steer towards one of the NoSQL db solutions rather than trying to use LDAP. LDAP is fine for things like storing user and employee information, but is terrible to interact with when you need to make changes. A NoSQL db will allow you to store your data how you want without the RDBMS overhead you would like to avoid.
The answer is actually easy. Think of CRUD (Create, Read, Update, Delete). If a lot of Read will be made in your system, you can think of using LDAP. Because LDAP is quick in read operations and designed so. If the other operations will be made more, the RDMS would be a better option.
For a web application database, from a security standpoint only, what are arguments counter to the point for an sp only solution where the app db account has no rights to tables and views and only exec on sps?
If someone intercepts the app db account, the surface area exposed to an attack is much less then when tables and views aren't exposed. What security advantages would a non sp solution offer (or not)? I see many advantages to using a non sp solution, but exposing all the tables leaves me a little worried.
The question is for major database vendor products in general but specifically, sql server 2008.
From a security point of view only, I can't see any advantages a non-SP approach would have over an SP approach because:
you have to grant permissions directly to the underlying tables etc
with a sproc, all the real-underlying schema information can be encapsulated/hidden away (SPs can be encrypted too)
Let's take a system that needs to be really secure, say your company's accounting system. If you use procs and grant access only to the procs, then users cannot do anything other than what the proc does, ever. This is an internal control designed to make sure that the business rules for the system cannot be gotten around by any user of the system. This is what prevents people from making a company purchase and then approving the funds themselves opening up the door to fraud. This also prevents many people in the organization from deleting all records in the accounts table because they do not have delete rights except the ones granted from the proc which will allow only one delete at a time.
Now developers have to have more rights in order to develop, but they should not have more rights on a production machine ever if you want to consider security. True a developer could write a malicous sp which does something bad when put to prod. This same developer though could put the same code into the application version and be as likely to be caught or not causght as if they maliciously change a proc. Personally I think the proc might be easier to catch because it might get reveiwed separately from the code by the dbas which might mean the manager or configuration management person and the dbas had a chance to look at it vice just the manager or configuration management person. We all know reality is that no one pushing code to prod has the time to review each piece of it personally, so hiring trustworthy developers is critical. Having code review and source control in place can help find a malicious change or roll it back to a previous version but the use of sps vice application code are both at risk from developers no matter what.
The same is true for system admins. The must have full rights to the system in order to do their jobs. They can potentially do a lot of damage without being caught. The best you can do in this case is limit this access to as few people as possible and do the best you can in hiring trustworthy people. At least if you have few people with this access, it is easier to find the source of the problem if it occurs. You can minimize risk by having off-site backups (so at least what the admin breaks if they turn bad can be fixed to some extent) but you can never completely get rid of this risk. Again this is true no matter what way you allow the applications to access data.
So the real use of sps is not to eliminate all possible risk, but to make it so fewer people can harm the system. The use of application code to affect database information is inherently unsecure and in my opinion should not be allowed in any system storing financial information or personal information.
The biggest security advantage to not using stored procedures is clarity. You know exactly what an account can do, by seeing what access to tables it has. With stored procedures, this isn't necessarily the case. If an account has the ability to execute procedure X, that does limit the account to executing that and not hitting an underlying table, but X can do anything. It could drop tables, alter data, delete data etc.
To know what an account can do with stored procedures you have to look at the stored procedure. Each time a sproc is updated, someone will have to look at what it does to make sure that something didn't get "accidentally" placed in it. The real problem with security in sprocs comes from inside the organization, not from rogue attackers.
Here's an example:
Let's say you are trying to restrict access to the employee table. Without stored procedures, you just deny access to the table. To get access someone pretty much has to blatantly ask you to grant permissions. Sure they could get you to run a script to grant access, but most people at least try to review a script which alters the database schema (assuming the script doesn't update a sproc, which I will talk about below).
There are potentially hundreds of stored procedures for an application. In my experience, they get updated quite frequently, add a field here, delete one there. For someone to review the number of update procedure scripts all the time becomes daunting, and in most organizations the database team starts to only quickly look at the procedure (or not look at it all), and move it along. This is where the real problem comes in. Now, in this example, if someone on the IT staff wants to allow access to a table, that person just needs to slip in a line of code granting access or doing something else. In a perfect world this would get caught. Most of us don't work in a perfect world.
The real problem with stored procedures is that they add a level of obfuscation to the system. With obfuscation comes complexity, and with complexity comes ultimately more work to understand an administrate the underlying system. Most people in IT are overworked and things slip through. In this instance you don't try and attack the system to gain access, you use the person in charge of the system to get what you want. Mitnick was right, in security people are the problem.
The majority attacks against an organization come from the inside. Any time you introduce complexity into any system, holes appear, things can get overlooked. Don't believe it, think about where you work. Go through the steps about who you would ask to get access to a system. Pretty soon you realize that you can get people to overlook things at the right moment. The key to successfully penetrating a system with people involved is to do something which seems innocuous, but is really subversive.
Remember, if I am trying to attack a system: I am not your friend; I have no interest in your kids or hobbies; I will use you in any way necessary to get what I want; I don't care if I betray you. The idea of "but he was my friend and that's why I trusted him to believe what he was doing was correct," is no comfort after the fact.
This is one of those areas where conventional wisdom is correct: exposing just the stored procedures gives you more control over security. Giving direct access to tables and views is easier, and there are times you need to do it, but it's going to be less secure.
Well, I guess you really captured the core of the problem yourself: if you don't use stored procedures for all CRUD operations, you have to grant at least a app-specific db user account at least SELECT rights on all tables.
If you want to allow the db account to do even more work, that account might also need other permission, like being able to UPDATE and possibly DELETE on certain tables.
I don't see how a non-stored proc approach would have any security benefits - it does open up the gate just a bit more, the question really is: can you afford to? Can you secure that app-specific DB account enough so it won't compromise your system's overall security?
One possible compromise might be to use views or table access to allow SELECT, but handle everything else (UPDATEs, DELETEs, INSERTs) using stored procs - half secure, half convenient...
As it often is - this is a classic trade-off between convenience (non-sp approach; using an ORM possibly) and security (all SProc approach; probably more cumbersome, but a bit safer).
Marc
In addition to the traditional security separation with stored procedures (EXEC permission on procedures, rely on ownership chaining for data access) stored procedures can be code signed, resulting in very granular and specific access control to any server functionality like linked servers, server scoped management views, controlled access to stored procedures and even data in other databases outside of user ordinary access.
Ordinary requests made in T-SQL batches, no matter how fancy and how many layer upon layers of code generation and ORM are behind it, simply cannot be signed and thus cannot use one of the most specific and powerful access control mechanisms available.
It's an imperfect analogy, but I like to compare the tables in the DB's "dbo" schema to "private" data in OO terminology, and Views and Stored Procs to "public." One can even make a "public" schema separate from the dbo schema to make the distinction explicit. If you follow that idea, you get a security advantage as well as an extensibility advantage.
One account (not the web app's account) has dbo access and owns the database, and the web app connects using another account restricted to the public-facing structures.
The only possible argument against is that I have run into cases where certain statements cannot be effectively parameterized in an SP (and dynamic sql is required) and this gives you the possibility of in-SP SQL-injection. This is really a very narrow consideration however and it is a rare case. At least in PostgreSQL I have once in a while seen a few cases where this had to be subject to extra review.
On the whole even in these cases, I think that SP type approaches give you a benefit security-wise because they mean that the application can use generic anti-SQL-Injection mechanisms where it might not otherwise be possible, and your SP can be used by many applications. Additionally if all activity must go through SP's then you can reduce your exposure to sql-injection and centralize the audits for problems.
In general, the less a user can do the less security exposure generally there is. This means the less a user can do with an sql injection attack.
Stored procedures generally give better and more granular security than you can do without.
Most of the answers here specify the security advantages of using stored procedures. Without disregarding those advantages, there are a few big disadvantages that haven't been mentioned:
The data access patterns are sometimes much more important than a specific procedure that is being done. We want to log/monitor/analyze/raise alerts/block who access the data, when, and how. We can't always get this information when using stored procedures.
Some organizations may have tons of stored procedures. It is impossible to review all of them, and it may make more sense to focus on tables (especially when considering that stored procedures may be very complex, have bugs, and introduce other security issues).
Some organizations may require a separation of concerns. Database administrators (or anyone who writes stored procedures) are not always part of the security personal. It is sometimes necessary for the security personal to focus only on the data simply because they are not responsible for the business logic and the guys that do write the business logic, are not completely trusted.
I have an application server which connects to a database server. I would like to be able to supply users with installers and, with a moderate degree of comfort, trust that the database schema is secure.
I understand that there are some risks that I will just have to accept with not controlling the computer on which it installed - a determined person with the right tools and knowledge could look directly at memory and pull out information.
Initially I thought my area of focus would simply be on adding the credentials to the installer without them being trivially viewed in a hex editor.
However, as I began to research, I learned that for PostGreSQL, even if I install the database silently and don't provide the credentials to the user -- they can simply change a text-based configuration file (pg_hba.conf), and restart the server, enabling full access to the database without credentials.
Is this scenario secured in other DBMS? How do most commercial products protect their schemas in this scenario? Would most products use embedded databases?
Edit: I assume (perhaps wrongly so) that some products rely on databases that the user never actually touches directly. And I of course never see them because they have designed it in such a way that the user does not need to - probably using an embedded database.
As far as I remember, there are no commercial products that "protect" their schemas. What do you want the schema to be protected against?
Consider the following points:
After all, the only person who can protect anything in a RDBMS is the database server administrator. And you want the schema to be protected against this person?
If I was a costumer and I had my data inside your schema, I would not only like, but expect, to be able to see and consume it directly.
Do you really need to protect your relational design? Is it really that interesting? Have you invented something worth hiding? I really don't think so. And I apologize in advance if you have.
EDIT: Additional comment:
I don't care about most database internals for the products I use. That's another reason I think most of them don't take any action to protect them. Most of them are not that interesting.
On one side, I strongly believe that users should not need to know or to care about the internals of the database. But at the same level, as a developer, I don't think it is worth trying to protect them. Hiding them from the user, yes. Protect them against direct access, in most cases, no. And not because I think it is wrong to protect your schema. It is because I think it is a very hard thing to do, and it is not worth your time as a developer.
But at the end, as with any security related topic, the only right answer is about what are the risks involved vs the costs of implementing the security measure.
Current database engines, embedded or server-style, are not designed to easily hide the schema of the database, and therefore, the development cost of doing it is much greater than the risk involved, for most people.
But your case might be different.
Most commerical products do not protect their schemas. They fall into one of two camps:
Either they are making use of an enterprise class database for a key component of the product (such as a payroll system), in which case there is no attempt made to hide the schema/data. In most of these cases the customer needs control over the database anyway - to configure how the database is backed up, to be able to make a clustered environment, etc.
The other case is if your "database" is nothing but a small settings or storage file for a desktop application (ex. the history and bookmark databases in FireFox). In that case you should just use an embedded database (like SQLite, same as FireFox) and add a streaming encryption layer (there is an official version of this called SEE), or just use the embedded database and forget about the encryption layer, since the user will need to have to install their own database tools to read the file in the first place.
What problem are you trying to solve? Nothing can stop the DBA* from doing whatever he wants to standard databases, and as others have pointed out it's actively hostile to interfere with site-specific needs like backups and database upgrades. At most you can encrypt the contents of your database, but even then you have to provide a decryption key for your application to actually run and a motivated and hostile DBA can probably subvert it.
The military and intelligence communities undoubtably have databases where even the schema is highly classified, but I don't know if they're protected by technical means or just large men with guns.
(*) DBA or system administrator able to modify files like pg_hba.conf.
How do most commercial products
protect their schemas in this
scenario?
I don't believe most commercial products do anything to protect their schemas.
How an embedded DBMS can stop someone to tinker with its storage (files in this non-embedded hardware context) when such person has physical access to the machine where this DBMS is running? Security through obscurity is a risky proposition.
This idea will suffer from the same problems as DRM. You can't prevent access by the determined, and you will only cause general pain and suffering for your customers. Just don't do it.
SQLite wraps its entire database format into a single file, and you could conceivably encrypt and decrypt it in-place. The flaw, of course, is that users need the key to use the database now, and the only way that can happen is if you give it to them, perhaps by hard-coding it in at compile-time (security by obscurity) or a phone-home scheme (whole host of reasons why this one's a bad idea). Plus now they'll hate you because you've thwarted any attempt at a useful backup system and they get terrible performance to boot.
Besides, nobody actually cares about schemas. Hate to break it to you, but schema design isn't a hard problem, and certainly never a legitimate competitive advantage (outside of maybe a few specific areas like knowledge representation and data warehousing). Schemas are generally not worth protecting in the first place.
If it's really that important to you, do a hosted application instead.
My previous job involved maintenance and programming for a very large database with massive amounts of data. Users viewed this data primarily through an intranet web interface. Instead of having a table of user accounts, each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc., as well as permitting us to control access through the RDBMS itself instead of using our own application logic.
Is this a good setup, assuming you're not on the public intranet and dealing with potentially millions of (potentially malicious) users or something? Or is it always better to define your own means of handling user accounts, your own permissions, your own application security logic, and only hand out RDBMS accounts to power users with special needs?
I don't agree that using the database for user access control is as dangerous others are making it out to be. I come from the Oracle Forms Development realm, where this type of user access control is the norm. Just like any design decision, it has it's advantages and disadvantages.
One of the advantages is that I could control select/insert/update/delete privileges for EACH table from a single setting in the database. On one system we had 4 different applications (managed by different teams and in different languages) hitting the same database tables. We were able to declare that only users with the Manager role were able to insert/update/delete data in a specific table. If we didn't manage it through the database, then each application team would have to correctly implement (duplicate) that logic throughout their application. If one application got it wrong, then the other apps would suffer. Plus you would have duplicate code to manage if you ever wanted to change the permissions on a single resource.
Another advantage is that we did not need to worry about storing user passwords in a database table (and all the restrictions that come with it).
I don't agree that "Database user accounts are inherently more dangerous than anything in an account defined by your application". The privileges required to change database-specific privileges are normally MUCH tougher than the privileges required to update/delete a single row in a "PERSONS" table.
And "scaling" was not a problem because we assigned privileges to Oracle roles and then assigned roles to users. With a single Oracle statement we could change the privilege for millions of users (not that we had that many users).
Application authorization is not a trivial problem. Many custom solutions have holes that hackers can easily exploit. The big names like Oracle have put a lot of thought and code into providing a robust application authorization system. I agree that using Oracle security doesn't work for every application. But I wouldn't be so quick to dismiss it in favor of a custom solution.
Edit: I should clarify that despite anything in the OP, what you're doing is logically defining an application even if no code exists. Otherwise it's just a public database with all the dangers that entails by itself.
Maybe I'll get flamed to death for this post, but I think this is an extraordinarily dangerous anti-pattern in security and design terms.
A user object should be defined by the system it's running in. If you're actually defining these in another application (the database) you have a loss of control.
It makes no sense from a design point of view because if you wanted to extend those accounts with any kind of data at all (email address, employee number, MyTheme...) you're not going to be able to extend the DB user and you're going to need to build that users table anyway.
Database user accounts are inherently more dangerous than anything in an account defined by your application because they could be promoted, deleted, accessed or otherwise manipulated by not only the database and any passing DBA, but anything else connected to the database. You've exposed a critical system element as public.
Scaling is out of the question. Imagine an abstraction where you're going to have tens or hundreds of thousands of users. That's just not going to manageable as DB accounts, but as records in a table it's just data. The age old argument of "well there's onyl ever going to be X users" doesn't hold any water with me because I've seen very limited internal apps become publicly exposed when the business feels it's could add value to the customer or the company just got bought by a giant partner who now needs access. You must plan for reasonable extensibility.
You're not going to be able to share conn pooling, you're not going to be any more secure than if you just created a handful of e.g. role accounts, and you're not necessarily going to be able to affect mass changes when you need to, or backup effectively.
All in there seems to be numerous serious problems to me, and I imagine other more experienced SOers could list more.
I think generally. In your traditional database application they shouldnt be. For all the reason already given. In a traditional database application there is a business layer that handles all the security and this is because there is such a strong line between people who interact with the application, and people who interact with the database.
In this situation is is generally better to manage these users and roles yourself. You can decide what information you need to store about them, and what you log and audit. And most importantly you define access based on pure business rules rather than database rules. Its got nothing to do with which tables they access and everything to do with whether they can insert business action here. However these are not technical issues. These are design issues. If that is what you are required to control then it makes sense to manage your users yourself.
You have described a system where you allow users to query the database directly. In this case why not use DB accounts. They will do the job far better than you will if you attempt to analyse the querys that users write and vet them against some rules that you have designed. That to me sounds like a nightmare system to write and maintain.
Don't lock things down because you can. Explain to those in charge what the security implications are but dont attempt to prevent people from doing things because you can. Especially not when they are used to accessing the data directly.
Our job as developers is to enable people to do what they need to do. And in the situation you have described. Specifically connect to the database and query it with their own tools. Then I think that anything other than database accounts is either going to be insecure, or unneccasarily restrictive.
"each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc.,"
not a good idea if the RDBMS contains:
any information covered by HIPAA or Sarbanes-Oxley or The Official Secrets Act (UK)
credit card information or other customer credit info (POs, lines of credit etc)
personal information (ssn, dob, etc)
competitive, proprietary, or IP information
because when users can use their own non-managed query tools the company has no way of knowing or auditing what information was queried or where the query results were delivered.
oh and what #annakata said.
I would avoid giving any user database access. Later, when this starts causing problems, taking away their access becomes very dificult.
At the very least, give them access to a read-only replica of the database so they can't kill your whole company with a bad query.
A lot of database query tools are very advanced these days, and it can feel a real shame to reimplement the world just to add restrictions. And as long as the database user permissions are properly locked down it might be okay. However in many cases you can't do this, you should be exposing a high-level API to the database to insert objects over many tables properly, without the user needing specific training that they should "just add an address into that table there, why isn't it working?".
If they only want to use the data to generate reports in Excel, etc, then maybe you could use a reporting front end like BIRT instead.
So basically: if the users are knowledgeable about databases, and resources to implement a proper front-end are low, keep on doing this. However is the resource does come up, it is probably time to get people's requirements in for creating a simpler, task-oriented front-end for them.
This is, in a way, similar to: is sql server/AD good for anything
I don't think it's a bad idea to throw your security model, at least a basic one, in the database itself. You can add restrictions in the application layer for cosmetics, but whichever account the user is accessing the database with, be it based on the application or the user, it's best if that account is restricted to only the operations the user is allowed.
I don't speak for all apps, but there are a large number I have seen where capturing the password is as simple as opening the code in notepad, using an included dll to decrypt the configuration file, or finding a backup file (e.g. web.config.bak in asp.net) that can be accessed from the browser.
*not a good idea if the RDBMS contains:
* any information covered by HIPAA or Sarbanes-Oxley or The Official Secrets Act (UK)
* credit card information or other customer credit info (POs, lines of credit etc)
* personal information (ssn, dob, etc)
* competitive, proprietary, or IP information*
Not true, one can perfectly manage which data a database user can see and which data it can modify. A database (at least Oracle) can also audit all activities, including selects. To have thousands of database users is also perfectly normal.
It is more difficult to build good secure applications because you have to program this security, a database offers this security and you can configure it in a declarative way, no code required.
I know, I am replying to a very old post, but recently came across same situation in my current project. I was also thinking on similar lines, whether "Application users be Database users?".
This is what I analysed:
Definitely it doesn't make sense to create that big number of application users on database(if your application is going to be used by many users).
Let's say you created X(huge number) of users on database. You are opening a clear gateway to your database.
Let's take a scenario for the solution:
There are two types of application users (Managers and Assistant). Both needs access to database for some transactions.
It's obvious you would create two roles, one for each type(Manager and Assistant) in database. But how about database user to connect from application. If you create one account per user then you would end up linearly creating the accounts on the database.
What I suggest:
Create one database account per Role. (Let's say Manager_Role_Account)
Let your application have business logic to map an application user with corresponding role.(User Tom with Manager role to Manager_Role_Account)
Use the database user(Manager_Role_Account) corresponding to identified role in #2 to connect to database and execute your query.
Hope this makes sense!
Updated: As I said, I came across similar situation in my project (with respect to Postgresql database at back end and a Java Web app at front end), I found something very useful called as Proxy Authentication.
This means that you can login to the database as one user but limit or extend your privileges based on the Proxy user.
I found very good links explaining the same.
For Postgresql below Choice of authentication approach for
financial app on PostgreSQL
For Oracle Proxy Authentication
Hope this helps!
It depends (like most things).
Having multiple database users negates connection pooling, since most libraries handle pooling based on connection strings and user accounts.
On the other hand, it's probably a more secure solution than anything you or I will do from scratch. It leaves security up to the OS and Database server, which I trust much more than myself. However, this is only the case if you go to the effort to configure the database permissions well. If you're using a bunch of OS/db users with the same permissions,it won't help much. You'll still get an audit trail, but that's about it.
All that said, I don't know that I'd feel comfortable letting normal users connect directly to the database with their own tools.
I think it's worth highlighting what other answers have touched upon:
A database can only define restrictions based on the data. Ie restrict select/insert/update/delete on particular tables or columns. I'm sure some databases can do somewhat cleverer things, but they'll never be able to implement business-rule based restrictions like an application can. What if a certain user is allowed to update a column only to certain values (say <1000) or only increase prices, or change either of two columns but not both?
I'd say unless you are absolutely sure you'll never need anything but table/column granularity, this is reason enough by itself.
This is not a good idea for any application where you store data for multiple users in the same table and you don't want one user to be able to read or modify another user's data. How would you restrict access in this case?
I consider myself to be relatively proficient in terms of application design, but I've never had to work with sensitive data. I've been wondering about what the best practices were for audit trails and how exactly one should implement them. I don't have to do it right now, but it'd be nice to be able to confidently talk with a medical company if they ask me to do some work for them.
Let's say we have a "school" database, with 'teachers', 'classes', 'students' all normalized in a many-to-many 'grades' table. What would you log? Every insert/update on the 'grades table'? Only updates (say, a kid breaks in and wants to change grades, this should send up redflags)? Does this vary entirely based on how paranoid one wants to be? Is there a best practice?
Is this something that should be done in the database? (A trigger on each sensitive SELECT which inserts a row to an 'audit' table logging each query?) What should be logged? Is there functionality automatically built into Oracle/DB2 that do it for you? Should this be application side logic?
If anyone has any formal documentation/books on how to deal with sensitive data (not quite DoD "Trusted Computing" spec, but something along the lines of that :P), I'd appreciate it. I'm sorry if this question is terribly vague. I realize that this varies from application to application. I just want to hear your detailed experiences with dealing with sensitive data.
The first thing to understand is the native auditing capabilities of your chosen DBMS. These vary in detail, but generally provide a way to configure which operations are audited, and provide secure storage for the audit records that they generate.
The next thing to understand is what you want to audit. In the case of HIPAA and SOX, for example, you are probably looking at PII - Personal Identifying Information. Remember the fuss made about people accessing Obama's phone records, or various celebrities medical records, or ... Those were caught because the system audited who read those records, and the audit analysis officer (AAO) spotted that the celebrity records were accessed by people who were not specifically authorized to do so. So, those systems must be logging who accesses each record, and spotting when the user who does so does not have an authentic business reason to do so. In these cases, it appears that the users had read authority for the records, so if their ordinary duties required them to look at the records, they could do so. But, when they were not required to do so, then they were abusing their power and appropriately sanctioned (up to and including losing jobs over it).
What this means is that you probably don't want to track who accesses the table of States which records the state code and full name (and assorted other bits of information about the state). There is nothing confidential about that list - it doesn't matter who reads it. Of course, almost no-one should write to it; the list of states does not change very often - but that can probably be handled by revoking update and delete permission on the table from everyone.
OTOH, you probably do want to record who accesses the records in medical histories (HIPAA), or who modifies the data in the accounting systems (SOX). You might or might not need to worry about who reads the accounting data; a lot of that can be dealt with by basic permissions (accounting staff have permission; IT staff do not). However, auditing is always an extra line of defense.
Bear in mind that audit records are no help whatsoever if they are never looked at. In general, auditing slows a system down (simply because it is doing more work when it writes audit records); it is important to understand how much it slows down before deciding to implement your auditing strategy. However, there are some things that are more important than application speeed, and one of those is keeping yourself and other staff members out of jail. Auditing can be necessary to ensure that happens.
Oracle has a product called Oracle Audit Vault- DB2 probably has an equivalent.
You should start by prevention. The system should not allow invalid actions. Period. If the system allows 'dubious' actions that need to be monitored, that's "business logic", you are probably better of implementing like the rest of your business logic.
If you want to do something in your database, you can look into log shipping (terminology might differ from RDBMS to RDBMS). Basically, any DML operation is logged to a file. You can use this information for backups and point-in-time recovery, even for replication/HA/failover/etc. If you ship your logs to a separate, "trusted" system in an "append-only" (i.e. the log shipping process has privileges to create new log files, but not to modify existing information) fashion, you already have a primitive auditing functionality. If you do it in a secure way (i.e. authentication, non-repudiation), you probably even are quite close to "compliance" :-p
Of course, sifting through lots and lots of INSERT/UPDATE/DELETE statements is not the most sophisticated way to work.