別再忽視!PostgreSQL Public 模式的風險以及安全遷移
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
問題起因前幾天有群友在群里面咨詢
另外一位群友說到
PG中默認的public模式帶來的問題
public 模式默認對所有數(shù)據(jù)庫用戶都開放訪問權限。換句話說,所有連接到數(shù)據(jù)庫的用戶默認都可以訪問 public 模式中的對象(除非你手動修改權限)。
public 模式是所有用戶和所有擴展默認使用的模式,容易發(fā)生命名沖突。
使用 public 模式進行業(yè)務操作會使數(shù)據(jù)庫的架構設計顯得雜亂無章,隨著時間推移,尤其是在大型項目或多個項目共享數(shù)據(jù)庫時,public模式中的對象數(shù)量會急劇增加
許多 PostgreSQL 擴展默認使用 public 模式,如果修改 public 模式或刪除它,可能會導致擴展無法正常工作 能否重命名 public 模式我們能不能通過下面命令對public 模式名重命名 ?
實際上重命名 public 模式是不推薦的做法,原因如下
因此,最好的做法是保留 public 模式,但不在業(yè)務中使用它。 如何解決這個問題實際上,我們可以使用遷移的方式,新建一個模式,然后把public模式下的所有業(yè)務對象遷移到新建模式下 具體步驟 第一步:創(chuàng)建新的模式
第二步:遷移所有對象:對表、視圖、函數(shù)、存儲過程等對象分別執(zhí)行 SET SCHEMA 操作,將它們從 public 模式遷移到 employee 模式。 遷移對象時小心依賴關系,如外鍵、索引、函數(shù)依賴等,遷移時需要確保這些依賴關系不被破壞 使用以下命令逐個遷移:
使用 SQL 動態(tài)語句和 PL/pgSQL 編寫一個循環(huán)來批量遷移 public 模式中的所有表、視圖、函數(shù)和存儲過程到 employee 模式。
第三步:設置 search_path 通過調(diào)整 search_path 讓數(shù)據(jù)庫默認使用 employee 模式。 search_path 的設置順序非常重要。 將 employee 模式放在前面,確保在業(yè)務操作時優(yōu)先查找 employee 模式的對象,而 public 作為備選模式保留(方便擴展和插件的使用)。 可以修改 PostgreSQL 的 postgresql.conf 文件,或者在會話級別設置 search_path:
第四步:考慮擴展和插件 許多擴展和插件默認使用 public 模式,例如 PostGIS、pgcrypto 等。 為了避免問題,最好不要修改 public 模式,而是保持其作為擴展使用的默認模式。 為什么SQL Server 沒有這個問題SQL Server 沒有像 PostgreSQL 那樣對 public 模式的強烈依賴,并且其設計理念與 PostgreSQL 的 public 模式存在一些關鍵區(qū)別。
在 SQL Server 中,dbo 是默認的 schema,所有數(shù)據(jù)庫用戶默認情況下并不會擁有對 dbo 這個 schema 中對象的完全訪問權限。只有擁有 db_owner 角色的用戶才可以完全控制 dbo 這個 schema。 也就是說,除非用戶顯式授予對 dbo 中對象的訪問或修改權限,否則,普通用戶是不能隨意訪問或修改 dbo 這個 schema 下的對象的。 相比之下,PostgreSQL 的 public 這個 schema 在默認情況下是對所有用戶開放的。這意味著所有用戶都可以在 public 這個 schema 中創(chuàng)建對象,除非手動限制權限。 PostgreSQL的設計會增加意外權限授予和數(shù)據(jù)泄露的風險,因此在 PostgreSQL 中有時需要避免使用 public schema。
在 PostgreSQL 中,public schema 設計為一個所有用戶共享的默認命名空間,因此經(jīng)常發(fā)生命名沖突、權限管理不嚴等問題。 在 SQL Server 中,dbo 是為擁有數(shù)據(jù)庫完全控制權的用戶預留的默認命名空間,通常普通用戶和 DBA 可以自行創(chuàng)建自定義 schema 來組織和隔離各自的數(shù)據(jù)庫對象。 轉自https://www.cnblogs.com/lyhabc/p/18475655 該文章在 2025/7/14 9:07:43 編輯過 |
關鍵字查詢
相關文章
正在查詢... |