Unified audit

The person disappears behind a shared account

The user authenticates at the WAS. After the connection pool, the database session usually shows only a shared account such as APP_USER. An investigation then means lining up timestamps by hand.

What one event holds

When WAS authentication finishes, the real user and the WAS session id are bound to the database session. The audit record keeps that context with the SQL, the object, and the column.

• Only objects and columns named in advance. Not every statement, scored later with a regular expression.
• On Oracle, columns that Unified Audit does not cover are handled with a DBMS_FGA policy, and the policy history is kept.
• Application access and direct access can be searched for the same user and the same object.
• SQL that ran without an approval sits next to the audit record.

Oracle audit logs and Gate metadata are kept so they can be searched together. Real user, WAS session, database session, and SQL can be sent to a SIEM as one event over syslog or a standard API.

Existing access control, account management, audit, and log storage stay. AUDIGATE is the layer that connects the real user and the approval time to those records.

Where this differs from DAM and JIT

PNP, WV, and SW are initials for the domestic database access-control products. The table describes the usual limits of packet or statement DAM, and of JIT that lends an account. It does not score every option of a named product.

Item	Existing DAM (PNP·WV·SW)	AUDIGATE	Note
Audit of access through a view, synonym, DB link, or stored program	Sees only names that appear in the packet or the SQL text. The object actually touched inside a view, synonym, DB link, or procedure is missed when it never shows up in that text.	Audits the object and column after the database resolves the name. Access through a synonym, view, or PL/SQL is recorded when that target was named in advance.	JIT that lends an account or a password for a window does not audit the resolved object.
Column-level audit	Infers column names from the SQL text. SELECT * and columns behind a view often leave no column trail.	Audits columns named in advance with DBMS_FGA. That policy covers the columns Oracle Unified Audit does not.	JIT has no column-audit axis.
Wrapped columns, such as substr(national_id, 7)	A pattern match works only when the function and the column text appear together. A view or a procedure hides them.	Reading a column still hits the column audit when the column is wrapped in a function.	JIT does not look at the SQL expression.
Column usage log and block	Blocks and logs by statement pattern. Which column was read depends on the original SQL text.	Access to a named column is kept as an audit record. SQL from a session without the dynamic role is rejected by the database.	JIT only closes the login window. It does not keep a column trail or block inside the session.
A different privilege on each session	Policy is by account and IP. The privilege stays on the account. A different role is not raised per session.	apply_my_roles turns the dynamic role on for that session only. The AUTH-KEY cannot be used from another session.	JIT often opens a shared account for a period, so one session and the column audit are not one record.
What is stored	Logs every SQL statement that passes, including statements that do not touch an important column.	Logs 100% of the important tables and columns. SQL outside that set is not stored in full.	JIT keeps connection and approval history, not the SQL text.
Vendor NNE and TLS	No. When the packet is encrypted with vendor NNE or TLS, the SQL is not visible.	Yes. Named tables and columns are recorded in the database session, not from the encrypted packet.	JIT cannot see the SQL inside the encrypted stream either.