Ok... with that I can help.
I implemented it in some customers and I use it in virtually all instances
on the customer where I spend more time.
You don't have to fear the impact if what you're going to do is exactly
what you mentioned (I'd say you'll want to do more...).
Native auditing is configured by specified "audit masks". You must specify
a mask for each user (or apply a template mask to several users). The mask
defines the user and the operations that will be audited. There is a table
in the security guide, but you have a "menemonic" (4 letter code) for each
operation like CREATE TABLE, GRANT, REVOKE, EXECUTE PROCEDURE, START
SESSION, OPEN DATABASE etc.
So in your case you'll need a mask for user informix with grant, and some
other admin tasks...
You just need to create a location for the audit trails and run "onaudit"
two times:
1- To activate the auditing
2- To define the mask
It's that simple. Now... You'll ask yourself some more questions that will
increase the complexity:
1- Do I want to prevent user Informix to cover or hide his actions? If so,
you'll need role separation and some OS filesystem permission tweeks
2- What happens if the audit trail location fills up? -> Bad things
independently of the configuration you choose in step 1. Never let it fill!
3- Hmmm... It's that easy? Why not audit more users?
4- Hmmm... and about table operations? -> Danger: It's where you may impact
performance
People usually are very afraid of the performance impact of auditing. This
is mostly exaggerated but yes, you can have performance impacts. Let's
imagine how it works... (I never saw the code). But:
1- You have a mask for every user which includes the operations that are
audited...
2- The code the engine runs is the same whether you have audit turned on or
off (you don't have to stop the engine....)
Considering these two points I'm almost sure it works like this:
1- When a session is created, the mask is put inside the session structure.
Smal delay certainly. You should not notice it.
2- For each operation that can be audited, the engine code tests if
auditing is turned on and/or the user has the operation in his mask. (let's
consider the test is always done...). Again, a test is not heavy... Each
operation does probably tens or hundreds of other tests...
3- IF (and only if) the user has that operation in his mask, audit trail
will be done. This is really the heavy part.
As you can imagine, if 3) is the only part that can cause some impact, the
real impact will clearly depend on the number of times the audited
operations are run.
Now consider things like GRANT... or CREATE/DROP TABLE... how often do they
happen? Specially if you audit users that should NOT do them?
Hope I made my point clear.
Now... For table operations you have 5 mmemonics:
ACTB - Acess table : Every time a table is "touched"
INRW - Insert Row - For evey row inserted
RDRW - For every row retrieved
DLRW - For every row deleted
These operations can kill you if applied on the majority of the users,
specially if you're running on versions before 11.7. On 11.70 you may
configure the audit facility to use these masks only on tables wher you
turned on auditing. Yes, before this you cannot filter by objects on the
masks. This makes it simpler for the engine, but may cause much more impact
than needed (why audit non-sensitive tables...?). But on 11.7 we (finally)
fixed that.
Feel free to send more questions... I do like this topic :)
Regards.
Post by t***@gmail.comI have read about the native auditing functionality but have never used it
and have not heard from others in their experience with it use. It would be
great to hear from people who have used it or are currently using it.
My biggest concern would be its possible impact on the production system
(btw, we are on 11.7.FC6 on AIX 6.1 with HDR)
Post by Fernando NunesI may be influenced by the fact that you used the term "auditing", but
have you consider using the native audit functionality?
Post by Fernando NunesOr do you mean some tool to process the audit trail?
Informix native auditing sees a perfect fit for this and will not cost
you money. If you have any concern regarding it, or if you have some other
requirement that it does not fulfill can you elaborate on it?
Post by Fernando NunesRegards.
Hello
We are being asked to look into how to record for auditing certain
events not normally captured, such as granting/revoking privileges to
tables or other admin tasks performed by user Informix. Are there tools out
there that folks already use?
Post by Fernando NunesThanks,
Tom
_______________________________________________
Informix-list mailing list
http://www.iiug.org/mailman/listinfo/informix-list
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
_______________________________________________
Informix-list mailing list
http://www.iiug.org/mailman/listinfo/informix-list
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...