Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 58288B5DC2A for ; Sat, 29 Oct 2011 01:20:07 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 07098-06 for ; Sat, 29 Oct 2011 04:19:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from zql.com (zql.com [206.222.31.58]) by mail.postgresql.org (Postfix) with ESMTP id 2DA5CB5DC1F for ; Sat, 29 Oct 2011 01:19:53 -0300 (ADT) Received: from localhost.localdomain ([127.0.0.1] helo=localhost) by zql.com with smtp (Exim 4.68) (envelope-from ) id 1RK0Oe-0007h2-LX; Sat, 29 Oct 2011 00:19:52 -0400 From: "Greg Sabino Mullane" To: pgsql-admin@postgresql.org Subject: Re: audit trail for viewed data X-PGP-Key: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8 X-Request-PGP: http://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 In-Reply-To: <9B23E699D2D157499F6DCDE78306E85B09C6B128@VARUNA.omni.imsweb.com> Date: Sat, 29 Oct 2011 04:19:52 -0000 X-Mailer: JoyMail 2.4.0 Message-ID: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201110/131 X-Sequence-Number: 38583 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I have been asked to investigate creating an > "audit trail" for viewed data. ... > My first pass attempt at a solution was to use a set returning > function that inserted to the audit trail... ... > I'm sure this has to do with the function not knowing anything > about the join inclusion/exclusion nor the where clause, but > I'm wondering if this is a problem that anyone else has > experienced in the past. Is there a way to do this at the > database level or do we need to try to build something > into the application to do the tracking? It's easy enough at the database level: just make all access go through stored procedures. In the example you gave, disallow direct access to table 'a' and if they need something like that query, make them call this: select rows_a_join_b_id_less(4250); Obviously you can make the functions a little more generic, but the golden rule is all direct table access is forbidden. They want something from the database, they must go through one of your special procs. Then you can log who viewed what data and when :). That's going to probably end up a /very/ large audit log, but without getting into a lot more complexity, that's the price you pay for such detailed logging. The only other non-application option I can see is to have something recording things at a low-level, e.g. wireshark. Which makes the database and application changes easy (e.g. no changes at all!) at the high cost of parsing the logs when you need to make sense of them. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201110290019 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk6rfs0ACgkQvJuQZxSWSsg9AwCeKRF+lPlX+lpxIxkjOacoYXMO 1WQAn1ONgX8T9aZffHejetCY+yOq5PTP =/54K -----END PGP SIGNATURE-----