01 · Audit and access
Tie the person behind the shared application account to the audit log, and put a dynamic role on the session only for the approved window.
Collecting logs and connecting them are different problems.
The real user authenticates at the WAS, but requests reach the database via connection pools showing only APP_USER. No matter how many logs are collected, they cannot prove who executed the query without tedious manual guesswork.
Conventional least-privilege models restrict table or column scopes but ignore time windows. Privileges remain active 24/7 overnight and on weekends, leaving organizations vulnerable to credential theft and insider threats.
TLS and native network encryption blind network sniffing appliances. Furthermore, access control (Gate) and auditing (Audit) operate as siloed systems unable to correlate approval intent with query execution.
AUDIGATE does not replace existing security investments. It sits alongside them as a complementary layer, binding real user context to sessions and activating dynamic roles only during approved windows.
After WAS authentication, the real user and the WAS session id are bound to the database session. The audit record keeps that context with the SQL, object, and column. AUDIGATE watches targets you named in advance, rather than hauling every statement out for a regular-expression pass.
A SELECT or UPDATE granted for the job does not stay on overnight and over the weekend. Only an approved session holds the dynamic role. SQL outside that scope is rejected by the database. Existing access control, account management, audit, and SIEM stay in place.
PLATE 04
Existing SQL tools, one event
No dedicated SQL client. Connect through DBeaver, SQL Developer, or PL/SQL Developer. If TLS or native network encryption hides the packet, the approved role and the session trace still record the SQL. Real user, WAS and database session, and SQL can go to a SIEM as one event over syslog or a standard API.
