we are using SQL2012 Enterprise Edition and have a small problem with one of our DBA (5 persons with more than 100 instances). is it possible to check who has changed given, denied or revoked permissions and when this was done? I could not find any trigger or audits.
Thanks for your help and best regards from HAMBURG in GERMANY
Two choices spring to mind here:
Use SQL Server Audit, and create audit specifications to capture the events that you are interested in (see http://technet.microsoft.com/en-us/library/cc280386.aspx for more details)
Use server level triggers to capture all DDL events (see http://www.mssqltips.com/sqlservertip/2085/sql-server-ddl-triggers-to-track-all-database-changes/ for an example of how to do this)
We basically use the second approach across our production instances for audit purposes, and to record a complete history of all schema changes across all databases so that we can accurately identify what has changed (and by whom, and when) to assist with production troubleshooting of issues.
Related
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
I have 2 different systems with SAP installed on them. First installation running on SQLServer, and the other installation running on Oracle.
In the first installation of SAP running on SqlServer, when i run DBACOCKPIT tcode, i get the following subfolders;
Performance, Space, Backup And Recovery, Configuration, Jobs, Alerts, Diagnostics, Download.
However, on the second installation of SAP running on Oracle. I get the following sub folders only: Performance, Space, Jobs, Diagnostics.
Why don't i get the other folders?
Both systems run ECC 6.0
SAP Basis components of both are a bit different:
Despite the difference of DBACOCKPIT layouts between MS SQL system (A) and Oracle system (B), I think it is normal. Possible reasons for this are:
lack of necessary user authorizations on system B
different set of authorizations of user A and user B
Oracle database was configured incorrectly or was not configured at all
SAP Note 1028624 regarding Oracle DBACOCKPIT says
Some performance monitors within the DBA Cockpit require special database objects. These objects are created using an SQL script. See Note 706927 for this script and more information.
Some functions in the DBA Cockpit require the Oracle Active Workload Repository. This Oracle option must therefore be available for selection (see Note 1028068).
This note also exactly specifies set of functions available in DBACOCKPIT for Oracle, and this set fully corresponds to your screenshot.
The DBA Cockpit has a navigation area that is visible in all the functions of the DBA Cockpit. This area contains a menu tree with the following access points:
- Performance (corresponds to the old transaction ST04)
- Space (corresponds to the old transaction DB02)
- Jobs (corresponds to the old transactions DB13, DB12, DB14, DB13C)
- Diagnostics
At the same time MS SQL DBACOCKPIT also corresponds to SAP standard, which is confirmed by SAP Note 1027512 and by this datasheet, for example.
Possible steps for research:
check if authorizations S_RZL_ADMIN and S_BTCH_ALL are assigned to you, as it stated in detailed DBACOCKPIT description from note 1028624.
check SAP Database Oracle Guide for compliance with you system B setup
This is absolutely standard situation.
I am also have a two systems with the same version of ECC.
One on MS SQL Server 2014
Another one on SAP HANA SPS03
and
DBACOCKPIT t-code looks different in these two systems.
All OK!
I'm looking for an auditing solution that does exactly what Change Data Capture (CDC) does, except I need it to also track the application user that made the change. I'm currently using SQL Server 2012 Enterprise and may be upgrading to 2014 later this year.
We already have an auditing solution in place that leverages Delete, Insert, and Update triggers, but some new requirements might force us to update every audit trigger and corresponding audit table. Given various problems we've run in to with that solution over the years, this seems like as good a time as any to reevaluate and potentially replace the solution.
To give you an idea of what I'm currently working with (and may be able to leverage), we use a stored procedure (ConnectionInitialize) to store a user id with a SPID in a table (ApplicationUser) and then we delete the row using another stored procedure (ConnectionReset) once we're done making our deletes, inserts, and updates.
Were we to use CDC, I looked into adding a trigger to something like the cdc.lsn_time_mapping table, but I couldn't find a way to map the LSN back to the SPID (and therefore the user id) that was being used. This also presented some other issues in that CDC is always a little bit behind.
I looked into SQL Server Audit a little bit, but that presented some challenges of its own. We're using Transparent Data Encryption (TDE) to appease some of our security requirements, but SQL Server Audit looks like it'd need a separate encryption strategy; that and I'm more interested in the columns than in the actual SQL statements. Even so, these aren't deal-breakers for me, so I'm still looking into it.
Given what I'm trying to accomplish, does anyone have any feedback or recommendations?
By itself, CDC doesn't meet the requirements. The reason being is that CDC only grabs changes to your data, not any underlying context under which those changes were made. You can, however, get what you're looking for if you're willing to tag your data with some audit columns. The basic idea is that you append a column to your table (or to a different table if you aren't able to modify the actual table for whatever reason) and populate it with the user who last modified the record (pretty simple to do via an insert/update trigger). Once that is actual data, you can consume it however you need to (CDC being one possible mechanism).
Late answer but hopefully useful.
There is a third party tool, ApexSQL Audit, capable of meeting your requirements. My previous company is using it for years and they have been satisfied with it.
There is a helpful comparison article you can read to find more details about audited data, auditing mechanisms, integrity protection etc, for both CDC & Audit tool at one place.
I'm using Oracle 11g Standard Edition.
I would like to log all SQL queries, that are being executed by users, into a table.
How can this be done?
If you're using a modern version of the database (9i or later) and you have an Enterprise Edition license you can use Fine-Graining Auditing. It allows us to audit user queries at a very low level of granularity, through defined policies.
To capture SQL text and bind variables you will need to set the AUDIT_TRAIL parameter appropriately when adding an FGA Policy. Find out more.
"i'm using an 11g standard, so auditing functions are not supported."
Not exactly. The AUDIT command is part of the standard Oracle build, but it only allows us to capture when a given user issues a SELECT against a given table. But, yes, to find out exactly what they are selecting requires Enterprise Edition license.
Also there is no ON SELECT trigger, so we cannot roll our own.
"So can i use AUDIT command in the standard edition? ... But then a
consultant told me, that i cannot use it without paying enterprise
license? "
Speaking as a consultant myself, I do have to say those guys don't always know what they are talking about.
So let's be clear:
the AUDIT command is part of Oracle SQL. It is usable with the Standard Edition. In fact since 11g it is enabled by default. It audits general activity. Find out more.
Fine Grained Auditing is a PL/SQL package with is only usable if you have the Enterprise Edition. It allows us to audit user activity at a very low level. Find out more.
For QUICK, EASY logging of SQL, try my monitoring answer here. Not for long-term logging, but works great just to see what is going on in a small time window. :-)
I would like to log changes made to all fields in a table to another table. This will be used to keep a history of all the changes made to that table (Your basic change log table).
What is the best way to do it in SQL Server 2005?
I am going to assume the logic will be placed in some Triggers.
What is a good way to loop through all the fields checking for a change without hard coding all the fields?
As you can see from my questions, example code would be veeery much appreciated.
I noticed SQL Server 2008 has a new feature called Change Data Capture (CDC). (Here is a nice Channel9 video on CDC). This is similar to what we are looking for except we are using SQL Server 2005, already have a Log Table layout in-place and are also logging the user that made the changes. I also find it hard to justify writing out the before and after image of the whole record when one field might change.
Our current log file structure in place has a column for the Field Name, Old Data, New Data.
Thanks in advance and have a nice day.
Updated 12/22/08: I did some more research and found these two answers on Live Search QnA
You can create a trigger to do this. See
How do I audit changes to sql server data.
You can use triggers to log the data changes into the log tables. You can also purchase Log Explorer from www.lumigent.com and use that to read the transaction log to see what user made the change. The database needs to be in full recovery for this option however.
Updated 12/23/08: I also wanted a clean way to compare what changed and this looked like the reverse of a PIVOT, which I found out in SQL is called UNPIVOT. I am now leaning towards a Trigger using UNPIVOT on the INSERTED and DELETED tables. I was curious if this was already done so I am going through a search on "unpivot deleted inserted".
Posting Using update function from an after trigger had some different ideas but I still believe UNPIVOT is going to be the route to go.
Quite late but hopefully it will be useful for other readers…
Below is a modification of my answer I posted last week on a similar topic.
Short answer is that there is no “right” solution that would fit all. It depends on the requirements and the system being audited.
Triggers
Advantages: relatively easy to implement, a lot of flexibility on what is audited and how is audit data stored because you have full control
Disadvantages: It gets messy when you have a lot of tables and even more triggers. Maintenance can get heavy unless there is some third party tool to help. Also, depending on the database it can cause a performance impact.
Creating audit triggers in SQL Server
Log changes to database table with trigger
CDC
Advantages: Very easy to implement, natively supported
Disadvantages: Only available in enterprise edition, not very robust – if you change the schema your data will be lost. I wouldn’t recommend this for keeping a long term audit trail
Reading transaction log
Advantages: all you need to do is to put the database in full recovery mode and all info will be stored in transaction log
Disadvantages: You need a third party log reader in order to read this effectively
Read the log file (*.LDF) in sql server 2008
SQL Server Transaction Log Explorer/Analyzer
Third party tools
I’ve worked with several auditing tools from ApexSQL but there are also good tools from Idera (compliance manager) and Krell software (omni audit)
ApexSQL Audit – Trigger based auditing tool. Generated and manages auditing triggers
ApexSQL Log – Allows auditing by reading transaction log
Under SQL '05 you actually don't need to use triggers. Just take a look at the OUTPUT clause. OUTPUT works with inserts, updates, and deletes.
For example:
INSERT INTO mytable(description, phone)
OUTPUT INSERTED.description, INSERTED.phone INTO #TempTable
VALUES('blah', '1231231234')
Then you can do whatever you want with the #TempTable, such as inserting those records into a logging table.
As a side note, this is an extremely easy way of capturing the value of an identity field.
You can use Log Rescue. It quite the same as Log Explorer, but it is free.
It can view history of each row in any tables with logging info of user, action and time.
And you can undo to any versions of row without set database to recovery mode.