audit

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

In SQL Server 2005, is there a way of deleting rows and being told how many were actually deleted? I could do a select count(*) with the same conditions, but I need this to be utterly trustworthy. My first guess was to use the @@ROWCOUNT variables - but that isn't set, e.g. delete from mytable where datefield = '5-Oct-2008' select @@ROWCOUNT always returns a 0. MSDN suggests the OUTPUT construction, e.g. delete from mytable where datefield = '5-Oct-2008' output datefield into #doomed select count(*) from #doomed this actually fails with a syntax error. Any ideas? wcm Have you tried SET NOCOUNT

We're implementing a New system using Java/Spring/Hibernate on PostgreSQL. This system needs to make a copy of Every Record as soon as a modification/deletion is done on the record(s) in the Tables(s). Later, the Audit Table(s) will be queried by Reports to display the data to the users. I was planning to implement this auditing/versioning feature by having a trigger on the table(s) which would make a copy of the modified row(deleted row) "TO" a TABLE called ENTITY_VERSIONS which would have about 20 columns called col1, col2, col3, col4, etc which would store the columns from the above Table(s

First, we currently have the behavior that's desired, but it's not trivial to maintain when any changes to the database are needed. I'm looking for anything simpler, more efficient, or easier to maintain (anything that does any of those 3 would be most welcome). When we perform an update, a history row is created that is a copy of the current row, and the current row's values are then updated. The result being that we have a history record of how the row was before it was updated. Reasoning: We have to be compliant with a number of federal rules, and went this route to have a full audit

To be more precise: According to rest style, it's generally assummed that POST, GET, PUT, and DELETE http methods should be used for CREATE, READ, UPDATE and DELETE (CRUD) operations. In fact, if we stick to the http methods definition the thing might not be so clear In this article it's explained that: In a nutshell: use PUT if and only if you know both the URL where the resource will live, and the entirety of the contents of the resource. Otherwise, use POST. Mainly because PUT is a much more restrictive verb. It takes a complete resource and stores it at the given URL. If there was a

It's quite easy to impersonate another user in Gitlab. See this topic for more details. It's possible to find out which user performed a push by examining "Activity" log of a repository. But for audit purposes I'd also like to know the IP address from which the push was done. Is it possible in Gitlab CE/EE? Pushes done through HTTP(S) You can examine access logs of nginx ( nginx/gitlab_access.log ): 192.168.21.150 - johndoe [19/Dec/2016:08:05:58 +0100] "POST /TEST/test.git/git-receive-pack HTTP/1.1" 200 52 "-" "git/2.9.2.windows.1 Pushes done through SSH You can examine gitlab-shell logs (