Lets say we have a application which has a database - MySQL, SQL Server, or Oracle, for example.
And let's assume that we have multiple people, like db and audit administrators, who have admin access privileges to the database. Let's say one of the people modifies a record and change the audit trail(since they have admin privileges I think they could do anything to the database, but correct me if I am wrong).
Is there any other way to detect this? Since changing the audit trail will cover up the tampering of the database record.
Do any of the database vendors has a solution for this? I guess this goes under the audit log tampering detection under the Database Forensics.
When the database is sufficiently important to mandate an audit, it will probably also have a backup schedule.
One possible way (i may be wrong) would be to compare the suspect database against the backup dump; this may not be feasible if the admin/audit users are also assigned backup privileges.
The standard approach is to get dedicated server at your company or rent a virtual server from a reliable supplier (like Amazon). Make sure that credentials for your app are different from credentials to the server. Whenever user deletes a record - backend should archive it instead. This makes it difficult to tamper the records.
Backup the database. You need backups in case someone breaks bd by mistake.
Use hash chains.
Related
I have a production Server say ServerA I have setup log shipping to ServerB which is left in read-only mode. The purpose of this log shipping is to lower the load on production server for some expensive queries (painful reports).
Now if I have to create some logins using our domain accounts. I cannot do this because the secondary database is in standby mode.
I thought if I create these logins on Primary server it will be copied over to secondary server then the logs are restored there but this isnt the case.
I have done a lot of research online finding a way around to this. I found the following resources for this. I tried every method suggested in this articles but none of them seems to work.
1) Log Shipping in SQL Server 2008 R2 for set BI on replicated database
2) How to transfer logins and passwords between instances of SQL Server
3) Orphaned Users with Database Mirroring and Log Shipping
Has someone experienced the same issue? what did you do? Is there any way around for this issue? Any suggestions any pointer please.
Ali,
Of course I am crafty ...
Check out these articles.
http://technet.microsoft.com/en-us/magazine/2006.05.sqlqa.aspx
http://blogs.msdn.com/b/reedme/archive/2009/04/24/log-shipping-database-snapshots-bummer-dude.aspx
Database mirroring is a better solution since you can create a snapshot and report off that.
However, both mirroring and log shipping have the database in read only state. Therefore, you can not change the orphaned users.
The best way is to make sure your login's on both servers match. Therefore, orphans will not occur.
I your case, you might have to remove log shipping, create the login's on the DR server, drop the database, reseed the DR server with a backup and restart shipping.
In this area, I am not speaking from experience since I always used clustering with a SAN.
Please test this out in a lower environment to work on any gotchas.
My upcoming project will be using Always On (with 1 primary, 1 secondary) = mirroring if synchronous or log shipping if asynchronous. But Always On allows for read only secondaries, which is nice.
Please write back on how you make out. I am curious.
Take care my friend.
J
This is a long question, but please bear with me as I believe it raises important issues about database ownership and access.
I manage and internationally market a "universal" geothermal data management program, written in Delphi, that is a front end to a SQL Server database. The data in the database is derived from many diverse measurements generated and used by the program users over time periods of 30 years or more - i.e. they "own" the data, and the database is primarily a way to efficiently store and manage the data.
Like all databases, the database structure needs to be modified from time to time, including new tables, and this modification is delivered by the release of a new version of the program. The program prompts for a database upgrade, which has to be carried out by a dbo user so that all new tables can be accessed by the other program users. Unfortunately, the program may be used in remote sites and the IT personnel may not be readily available, so that the new version may get installed but the databases are not upgraded. What has frequently happened in such locations is that a program user will upgrade the databases without appropriate SQL Server permissions, and then the other users cannot access the new tables and the program crashes.
One of the program customers has taken another approach. They have created a db_owner role for all the databases used by the program and then make all program users members of the db_owner role. The program has inbuilt permission levels that can restrict the ability to upgrade databases, so normally only one or two users have this permission. However, with everyone a member of the db_owner role, it doesn't matter who upgrades the database, all tables will be accessible to all program users.
The advantage of this approach include the following:
Access permissions can be granted by the group who uses the program, and who has ultimate responsibility for the database.
Knowledge and understanding of the program is passed on within the program users group when staff changes, rather than relying on the IT department as the repository of information on "how it works" (and often they do not know).
Direct data-mining and back-door data modification is possible to selected user experts. While the program has extensive datasearch and editing tools, sometimes these are not enough and the users need hands-on access.
The program users retain "ownership" of their data.
I would appreciate your comments. I believe that in circumstances such as these, it is important that all the database users are db_owners, and the group of users controls access. Not allowing db_owner roles (a strategy commonly employed by IT departments) fails to recognize the importance of data ownership and data accessibility, and the responsibility of the database users to manage their own data.
The way you've stated your question makes it sound like you've already arrived at a conclusion. The one question that I always ask when someone comes to me (a DBA) with this sort of situation is: if someone accidentally deletes data, am I on the hook to get it back? If the answer is "yes", then they don't get db_owner. If the answer is "no", then the db gets moved to its own server and I get the contract in writing.
The only time I wouldn't bother with access control would be with a simple app running on a local single-user database like SqlExpress. As soon as there are multiple users on a centralised database and important data to protect, restricted access is important. I'm not familiar with your domain (geothermal data management), but surely this data is important to your customers, from integrity, tampering and even a data access point of view (theft of data could be resold to a competitor).
the program may be used in remote sites and the IT personnel may not
be readily available, so that the new version may get installed but
the databases are not upgraded
(i.e. I'm assuming an upgrade script needs to be manually and independently run on the database). It is common nowadays for apps to check the database for schema versioning and even for static data population, e.g. Entity Framework code-first migrations on the .net stack. The app will then have the ability to actually perform the schema and data upgrade automatically. It should be quite straightforward for you to add the last N versions of your DB upgrade scripts into your app and then do a version check? (Obviously the app itself would need to prompt for dbo access, assuming that even the app should not have dbo access).
with everyone a member of the db_owner role, it doesn't matter who
upgrades the database
I believe this may place unnecessary responsibility (and power) in the hands of unqualified customer users.
Even the ad-hoc data mining (SELECT) access should be reconsidered, as a badly formed query without consideration can cause performance degradation or block other concurrent writers. If nothing else, providing a few well formed views will at least ensure decent query plans.
/10c
Recently I had to implement transactional replication to have a live copy of that database on another server for reporting purposes. While configuring replication I realized that a lot of tables didn't have a primary key, so I could not publish all the tables I wanted to.
Second option was to implement merge replication but that would have added a GUID column to all the tables. Since it is a database for a vendor application and vendor has warned us to not "touch" the database structure because any change in the database structure can cause their application to break. So merge replication is not an option anymore.
I have been doing some research on other available options for me in this scenario; the only thing I could find is Log Shipping. I know it will leave my database in Read-Only mode but (to my knowledge) since this is the only option I am left with and it will be strictly used for Reporting purposes only I think I can live with this.
Can anyone suggest a better solution for this? Or is Log Shipping the only option left for me?
It is SQL Server 2008 R2 64-bit DataCenter Edition.
Your other options are:
Database mirroring, and using a snapshot for read-only operations. It can be a pain to manage snapshots.
Upgrading to SQL Server 2012, and make use of Readable Secondaries in Availability Groups. This can be a pain in the wallet.
You mention log shipping but, based on your follow-up comments I don't think it's clear that, every time you restore a log to the log shipped copy, you need to kick out all of the users that may be running reports. This is because you need exclusive access to the database in order to restore the log. This is another case of "you get what you pay for" - you can log ship to Express instances, if you want to (and if your database supports it), but it's not exactly a watertight solution.
I need to secure an oracle user for doing inserts/updates/deletes from outside programs written by me.
I googled a bit around to find what I need. I know you can use own written db triggers.
And I now there are two major systems from oracle (at least that is what I found).
You can use fine grained auditing. And you can use the audit trail.
I think in my case the audit trail comes close but just isn't what I am looking for. Because I need to now from which program the connection to the DB is coming. For example I need to register all connections that are doing inserts/updates/deletes with there statements executed that are coming from sql developer or toad. But all the other connections may pass without audit.
On daily basis I have lots of connections so registering everything is too much overload.
I hope one of you have a good idea on how to set this up.
Regards
You can use a product of Oracle: Oracle Audit Vault and Database Firewall. Because you want to know also from which program the connection comes, you need the Database Firewall. It can monitor all traffic through the database, specifying the IP address and the client from which the connection was started. You can also specify if you want to audit DML or DDL,or other statements. Data is stored locally in the product's database,not in the secure target (your database). Just have a look, it it just what you need: http://www.oracle.com/technetwork/products/audit-vault-and-database-firewall/overview/overview-1877404.html
We have a requirement from a client to protect the database our application uses, even from their local administrators (Auditors just gave them that requirement).
In their requirement, protecting the data means that the Sql Server admin cannot read, nor modify sensitive data stored in tables.
We could do that with Encryption in Sql Server 2005, but that would interfere with our third party ORM, and it has other cons, like indexing, etc.
In Sql Server 2008 we could use TDE, but I understand that this solution doesn't protect against a user with Sql Server admin rights to query the database.
Is there any best practice or known solution to this problem?
This problem could be similar to the one of having an application hosted by a host provider, and you want to protect the data from the host admins.
We can use Sql Server 2005 or 2008.
This has been asked a lot in the last few weeks. The answers usually boil down to:
(
a) If you don't control the application you are doomed to trust the DBA
or
b) If you do control the application you can encrypt everything with a key only known to the application, and decrypt on the way out. It'll hurt performance a bit (or a lot) though, that's why TDE exists. A variant of this to prevent tampering is to use a cryptographic hash of the values in the column, checking them upon application access.
)
and
c) Do extensive auditing, so you can control what are your admins doing.
I might have salary information in my tables, and I don't want my trusted dba's to see.
Faced with the same problem we have narrowed are options to:
1- Encrypt outside SQLServer, before inserts and updates and decrypt after selects. ie: Using .net encryption.
Downside: You loose some indexing and searching capabilities, cannot use like and betweens.
2- Use third party tools (at io level) that block crud to the database unless a password is provided. ie: www.Blockkk.com
Downside: You will need to trust a third party tool installed in your server. It might not keep up with SQL Server patches, etc...
3- Use an Auditing Solution that will keep track of selects, inserts, deletes, etc... And will notify (by email or event log)if violations occurred. A sample violation could be a dba running a select on your Salaries table. then fire the dba and change everyone salaries.
Auditors always ask for this, like they ask for other things that can never be done.
What you need to do is put it into risk-mitigation terms and show what controls you do have (tracking when users are elevated to administrators, what they did and that they were de-elevated afterwards) instead of in absolutes.
I once had a boss ask for total system redundancy without defining what he meant or how much he was willing to pay and sacrifice.
I think the right solution would be to only allow trusted people be DBA's.
It is implicit in being DBA, that you have full access, so in my opinion, your auditor should demand that you have procedures for restricting who has DBA access.
That way you work with the system through processes in stead of working aginst the system (ie. sql server).
To have person you don't trust be DBA would be nuts...
If you don't want any people in the admin group on the server to be able to access the database, then remove the "BUILTIN\Administrators" user on the server.
However, make sure you have another user that is a sysadmin on the server!
another way i heard that a company has implemented but i haven't seen it is:
there's a government body which issues kind of timestamped certificate.
each db change is sent to async queue and is timestamped with this certificate and is stored off site. this way noone can delete anything without breaking the timestamp chain.
i don't know how exactly this works on a deeper level.