在 Oracle 數據庫中，我可以跟蹤訪問同一架構的不同個人的登錄嗎？

Question

我的組織在 Oracle 數據庫中有許多模式，需要由許多個人開發人員訪問。 在大多數情況下，開發人員可以使用自己的 id 登錄並通過角色權限訪問這些其他模式，但對於某些任務，個別開發人員需要直接登錄這些模式。

這方面的一個例子是模式 A，它需要由用戶 X 和 Y 訪問。用戶 X 和用戶 Y 可以使用他們自己的 id 登錄，但是為了充分利用模式 A 的潛力，他們需要模式 A 密碼。

我有興趣跟蹤用戶 Y 是否以及何時使用模式 A 密碼登錄模式 A。 這可以做到嗎？

我對此的需求主要與密碼安全和員工離開我們組織時的離職程序有關。 例如，如果我有模式 A 並且密碼被至少一些用戶 X、Y、Z 和 Q 知道，並且用戶 Q 離開了，這是一個威脅嗎？ 如果檢查顯示用戶 Q 不知道模式 A 的密碼，那么我沒有安全風險，但如果檢查顯示用戶 Q 知道模式 A 的密碼，那么我需要更改模式的密碼A，可能影響用戶 X、Y 和 Z。

因此，我的問題是，Oracle 中是否有一種方法可以讓我作為 DBA 識別哪些人登錄到這些模式，無論是通過跟蹤他們的客戶標識符還是其他途徑？

謝謝

Answer 1

對於這個特定的場景，使用代理身份驗證：它一次性解決了與開發環境相關的幾個問題。

[代理身份驗證] 允許用戶以一個用戶身份連接到數據庫，並在連接時成為不同的用戶。 此功能最初由 Oracle 部署，作為應用程序通過通用應用程序帳戶向單個數據庫帳戶驗證最終用戶身份的一種方式，但反過來它也同樣有效。

在這個模型中……每個開發人員在數據庫中都有一個單獨的個人帳戶。 大多數應用程序開發現在都可以通過這些個人帳戶進行處理和審計。 由於登錄帳戶與個人用戶相關聯，因此開發人員沒有動力與其他任何人共享他們的憑據。 判斷是否共享個人帳戶相對簡單，這樣做將成為大多數公司終止的理由。

為了演示這一點，我將創建一個應用程序模式並對其進行配置，以便只能通過代理身份驗證來訪問它：

 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> create user app_schema no authentication proxy only connect; User created. SQL> grant connect, resource to app_schema; Grant succeeded.

“無身份驗證”選項創建沒有憑據的共享帳戶。 [這不是嚴格要求，但是] 它消除了為永遠不會直接使用的帳戶維護密碼或證書的需要。 “僅代理連接”選項僅允許代理連接到共享帳戶。 [這也不是必需的，但根據您的情況可能會有用。]“連接”和“資源”角色授予使用帳戶和創建對象的基本權限。 接下來，我將創建一個示例開發用戶：

 SQL> create user dev_user identified by oracle; User created.

現在可以更改應用程序架構以允許來自各個開發人員帳戶的連接，如下所示：

 alter user app_owner grant connect through dev_user;

請注意語法：APP_OWNER 模式已更改為允許通過或通過 DEV_USER 帳戶進行連接。 這不是直接分配給開發用戶的特權。 一旦分配了此代理權限，開發人員就可以使用他們的個人憑據連接到應用程序模式。 他們所需要做的就是將應用程序帳戶名稱附加到其開發帳戶名稱的末尾，如下所示：

 SQL> connect dev_user[app_schema]/oracle Connected. SQL> show user; USER is "APP_SCHEMA"

通過以這種方式連接，開發人員仍然可以執行所需的操作，但無需知道應用程序所有者帳戶的真實密碼（假設甚至分配了一個）。 代理帳戶名稱（開發人員的個人帳戶）在系統會話上下文中可用，並且可以通過數據庫觸發器自動在 v$session 視圖中可見，以便 DBA 可以隨時知道誰連接到共享帳戶。

 CREATE OR REPLACE TRIGGER db_session_trig AFTER LOGON ON DATABASE v_proxy_user varchar2; BEGIN v_proxy_user := sys_context('userenv','proxy_user'); if v_proxy_user is not null then dbms_session.set_identifier(v_proxy_user); end if; END; select username, osuser, client_identifier from v$session where username='APEX_040000'; USERNAME OSUSER CLIENT_IDENTIFIER ----------------- --------------- ---------------------- APEX_040000 oracle PETE

使用 PROXY_USERS 視圖很容易准確地確定哪些開發人員也可以訪問每個應用程序所有者帳戶。

 PROXY CLIENT AUTHENTICATION FLAGS ------- -------------- -------------- ----------------------------------- PETE APEX_040000 NO PROXY MAY ACTIVATE ALL CLIENT ROLES

因為即使是基本審計也會捕獲開發人員的操作系統用戶名，審計跟蹤將記錄作為應用程序所有者執行 DDL 操作的實際開發人員。

 Sep 4 10:04:07 testdb Oracle Audit: SESSIONID: "12345" ENTRYID: "1" STATEMENT: "6" USERID: "APP_SCHEMA" USERHOST: "myserver" TERMINAL: "pts/2" ACTION: "7" RETURNCODE: "0" OBJ$CREATOR: "APP_SCHEMA" OBJ$NAME: "TEST_TABLE" SES$TID "4567" OS$USERID: "PETE"

使用具有代理帳戶訪問應用程序模式的個人開發人員用戶帳戶，可以允許開發人員在共享帳戶中工作，同時仍保持帳戶憑據安全性、連接用戶的可見性和准確的審計歷史記錄。

全文在這里： https ://pmdba.wordpress.com/2021/10/15/shared-application-accounts-revisited/

Answer 2

您可以為此使用代理用戶。 這樣就無需共享密碼，定期審計就可以完成它的工作。

另一種選擇可能是在開發人員可以調用的其他模式中定義包。 需要使用定義者權限定義包，因此當開發人員調用包時，執行是使用直接授予架構的權限完成的。 這樣做可以避免討厭的“任何”特權。