I heard database links are bad for organizations to use. Why is it bad for security?
Where did you hear this?
Database links, like any tool, have their uses and misuses. There is nothing inherently insecure about using a database link. But there are certainly plenty of ways to architect a system using database links that is insecure.
A database link lets you connect one database to another. Broadly speaking, you can define the database link so that it connects to the remote database as a specific fixed user on the remote database or you can define the database link so that it connects to the remote database as the current user. Those configurations have different issues.
If you use a fixed user, you have to be careful that the users that can access the local database link ought to have access to whatever privileges the remote database user has. If you use a relatively powerful account to create the database link but then give access to that link to relatively low-privilege users, that can certainly be a security issue. It can also be challenging to identify situations of concern where this has taken place because no single database has the whole picture. If user Bob on database A has read-only access to a couple of tables but there is a public database link on A that connects to database B as a highly privileged user, someone that compromises Bob's account the ability to execute commands on B as that highly privileged user. Of course, you can mitigate these issues by not creating database links as highly privileged users, taking care when creating public database links, creating private database links when the fixed user is going to have privileges that you don't want to grant to everyone, etc.
If you use current user database links, then the user Bob on database A connects to database B as Bob and has whatever privileges Bob does on database B. In general, that is likely to be easier to secure. It's at least much harder to unintentionally do something stupid. The downside to this approach, however, is that Bob would need to keep his password synchronized on both databases or the database link won't work. That generally involves developing a bit of infrastructure to allow Bob to reset his password on all databases (or use some sort of external authentication) which is a bit of work to set up and maintain. Occasionally, it will also limit what security measures the DBA can configure when you have a mixed environment. When you upgraded database A to 11.2, for example, you probably wouldn't want to enable case-sensitive passwords until database B was similarly upgraded. If you have lots of database links between lots of systems on very different upgrade schedules, this sort of thing might be concerning.
Some years back there was a significant bug where the "System Change Number" could be pushed ahead on a database and this would follow through to any database connected via a database link, resulting in a cascade of failures. Depending on how risk averse the organisation is, it can be a sensible precaution to keep databases isolated from each othe and reduce the effect of any 'outbreak'.
"Where this vulnerability gets interesting is that the SCN is synchronized to the highest SCN when two databases are connected via a database link. Therefore, it is possible to increase a database to the near maximum SCN through a database link, which will cascade through to all other interconnected databases. The result can be ORA-600 errors and potentially database crashes on the database with the lower SCN."
https://www.integrigy.com/oracle-security-blog/critical-oracle-database-bug-system-change-number-scn-cve-2012-0082
Related
Is it possible and (recommended as well) to restrict access on certain AX data to be secured from System Administrator role?
The case is that a company don't want to give access to its financial transactions, also for the employee payroll data, and some other classified information that System Administrator should not be accessed because of irrelevancy.
but, this particular administrator is performing development tasks on forms and reports, also playing the role of SQL DBA who is actually responsible for data maintenance, indexing, mirroring, backups...etc.
so, if we managed to restrict his access on data from AX client, he still can have access on SQL back-end, how can we restrict/encrypt data on SQL itself then?
Any suggestions highly appreciated!
What you're asking is incredibly difficult. It also could/would prevent him from functioning well as a developer.
What I've seen other companies do, and would make the most sense to me is to divide your infrastructure into Production and Test/Dev systems.
You would then backup your Production data and restore that data to Test and scrub the private financial info at the same time.
You would the give him access to Test/Dev systems only for development and SQL changes. Any dev or SQL changes that need to be made to the Production system, which has the sensitive data, would be performed by another person who is allowed to interact with the sensitive data.
Somebody has to have access to the data from SQL. You can't feasibly have accountants and controllers have the only access to the data. So whomever you were planning to have restrict his access...this would be a good candidate.
my question is rather simple.
Can i grant permissions on a database table wise? something in the lines:
User Management has permission to select, update, insert and delete on table Projects
User Supervisor has permission to select, update, insert on table Projects
User Colaborator has permission to select on table Projects
If so, I could set up a system to create database users based on the levels of access of my application, much like the examples above.
Is it a valid mechanism to use this to secure a application?
is it worth on a real world application?
i've used PHP with Oracle and MySQL, but I'm look for a database/language agnostic answer, but any example would be useful.
pushing my luck a bit, what about per record permission granting?
also, what about table schemas, are they a more acceptable then table based permissions?
The main problem with using database security would be that you need separate connections for each user rather than being able to use a "service user" for the connection from your application server to your DB server. That would mean that you would no longer be able to use database connection pooling have to "connect" and "disconnect" from the database for every user request, which is not very efficient as connections are relatively expensive.
Having said that, there is good reason for using separate users in the database, such as DATA_USER (which the application server connects as) and DATA_OWNER (which owns all the tables but is used only for DB maintenance) and then only give DATA_USER the permissions that it needs to, e.g. only select on a lookup table. By separating DATA_USER and DATA_OWNER you can add an additional level of confidence that your application won't issue DDL commands (e.g. dropping a table).
Answer to part 1:
Yes as long as you handle the responses correctly.
Part 2:
It's not as good as implementating security in the application layer, as most applications will need flexibility in the solution (what if you want a user to get increased privledges, have to code in lots of alter/deny/grant scripts)
Part 3: (Speaking from purely MSSQL) Row-level permissions aren't possible. Create custom views for this purpose.
I've just started looking at a system that implements security a little differently to the norm.
They create a new SQL user for each user of the system (of which there are about 32K now). Each query is sent via a connection that is initially using the SA account (lets not get bogged down on this), then after we know who the user is, the EXECUTE AS USER is used each query.
Now that there are so many users, creating new users and switching has a noticeable performance hit and the company is looking at improving the situation.
A few points:
- SQL Code is dynamic sql (not stored procedures)
- The original idea was to alleviate the need for the developers of the company to worry about writing SQL worrying about permissions - and let another layer worry about it.
How does one try and improve the query execution time and avoid the EXECUTE AS USER code and still get the same security scrutiny?
Does SQL Server support session variables to store a user account?
It's difficult to know whether this is helpful without a bit more detail on how your application security model and how it controls and/or pools database connections. Is it a fat client, n-tier or something else?
SQL connections can support a single "session variable" using CONTEXT_INFO - a user-configurable binary(128) field which persists for the duration of the connection. This may meet your requirements, but you need to beware that if you use it to store security information it will be accessible to the end user - you should therefore probably encrypt or salt and hash any security information in the CONTEXT_INFO to prevent users tampering with their permissions; this may have performance implications.
It may not be applicable depending on your application architecture, but have you considered switching to Windows authorisation and organising permissions though Active Directory users and groups?
I am not a DBA and so dont really know anything about SQL 2005 security settings, etc. I am attempting to set up an empty copy of our database by generating the full database from SQL Management Studio generated scripts. Unfortunately I don't know what many of the options do and the MSFT documentation of this processes isn't great.
There is an option to generate script for Schemas, Tables, Views and Users. It is the users I am confused about, because I don't understand how they affect the usage of the database. We have some developers in the team who are in this list and some who are not, yet everyone can do anything on the database, at least when they are hosting it on their own machines.
Do I need to keep these Users in my new generated database and what do they do?
We also have a dbo User who is a db_owner and owns many of our schemas. What is this dbo User? What is the significance of a user Owning Schemas? We use Schemas as "namespaces" to group logically related tables in our database but I take it there is more to them than that?
There is also a username tied to this dbo User, its the windows NT login of one of our developers, but he doesn't have his own User object in the list...is there any significance to this? Is this a bad thing?
Other Users are guest, INFORMATION_SCHEMA and sys, but I think these are all defaults?
Sorry but I am a SQL admin ignoramus and usually left these things to the DBA in my previous job!
Thanks for any help.
Do I need to keep these Users in my new generated database and what do they do
The answer is it depends. If your applications use a mixed mode authentication then you will need the user accounts created in SQL. If you use windows authentication (and it sounds like you are) then you might not need them.
What is the significance of a user Owning Schemas?
In SQL Server 2005 all schemas must be owned by a user. Schemas can be used to group functionality but they can also be used to group security. For example a user account may only have access to a specific schema (or multiple schemas).
Hopefully that helps answer some of your questions
I searched online a bit and couldn't find anything that really nailed the spot or covered the bases how to go about setting up users/roles on a database.
Basically, there would be a user that would be used to access the database from the application (web application in this case) that will need access to database for the regular database operations (select, insert, update, delete) and executing stored procedures (with exec to run stored procedures within other stored procedures/UDFs).
Then, we would also have a user that would be main admin (this is simple enough).
I currently have a development environment where we don't really manage the security too well in my opinion (application uses a user with db_owner role, though it is an intranet application). Even though it is an intranet application, we still have security in mind and would like to see what are some of the ways developers set up the users/roles for this type of environment.
EDIT: Web application and SQL Server reside on separate machines.
EDIT: Forgot to mention that an ORM is used that would need direct read/write access.
Question:
What are the "best practices" on setting up the user for application access? What roles would apply and what are some of the catches?
First, I tend to encapsulate permissions in database roles rather than attach them to single user principals. The big win here is roles are part of your database, so you can completely script security then tell the deployment types to "add a user and add him to this role" and they aren't fighting SQL permission boogeymen. Furthermore, this keeps things clean enough that you can avoid developing in db_owner mode and feel alot better about yourself--as well as practice like you play and generally avoid any issues.
Insofar as applying permissions for that role, I tend to cast the net wider these days, especially if one is using ORMs and handling security through the application. In T-SQL terms, it looks like this:
GRANT SELECT, UPDATE, INSERT, DELETE, EXECUTE on SCHEMA::DBO to [My DB Role]
This might seem a bit scary at first, but it really isn't -- that role can't do anything other than manipulate data. No access to extended procs or system procs or granting user access, etc. The other big advantage is that changing the schema--like adding a table or a procedure--requires no further security work so long as you remain within that schema.
Another thing to take into consideration for SQL 2005+ is to use database schemas to secure groups of objects. Now, the big trick here is that many ORMs and migration tools don't like them, but if you render the default schema [dbo] to the app, you can use alternative schemas for special secured stuff. Eg--create an ADMIN schema for special, brutal database cleanup procedures that should be manually run by admins. Or even a separate schema for a special, highly secured part of the application that needs more granular DB permissions.
Insofar as wiring in users where you have separate boxes, even without a domain you can use Windows authentication (in Sql Server terms integrated authentication). Just make a user with the same credentials (user/pass combo) on both boxes. Setup an app domain to run as that user on the web box and setup a Sql Server user backed by that principal on the sql box and profit. That said, using the database roles can pretty much divorce you from this decision as the deployment types should be able to handle creating sql users and modifying connection strings as required.
For a long time the SQL Server guidelines for application access to the database were to isolate access to data into stored procedures, group procedures into a schema and grant execute on the schema to the principal used by the application. Ownership chaining would guarantee data access to the procedure callers. The access can be reviewed by inspecting the stored procedures. This is a simple model, easy to understand, design, deploy and manage. Use of stored procedure can leverage code signing, the most granular and powerfull access control method, and the only one that is tamper evident (signature is lost if procedure is altered).
The problem is that every bit of technology comming out from the Visual Studio designers flies in the face of this recommendation. Developers are presented with models that are just hard to use exclusively with stored procedures. Developers love to design their class models first and generate the table structure from the logical model. The procedure based guidelines reuire the procedures to exists first, before the first line of the application is written, and this is actually problematic in development due to the iterative way of modern development. This is not unsolvable, as long as the team leadership is aware of the issue and addresses it (ie. have the procedures ready, even as mocks, when the dev cycle starts).
Create a user 'webuser' that the web application uses.
Only grant stored proc execute permissions to this user. Do not allow direct table read/write. If you need to read something from a table, write a proc. If you need to write data, write another proc.
This way everything is kept nice and simple. One app user, with only the relevant permissions. If security is compromised, then all the intruder can do is run the procs.