TL，DR：不需要。

（My-）SQL權限非常精細，因此我建議不要任何明顯的安全問題

即使在記錄級別獲得許可，它也確實易於擴展。如果用戶在表上具有不受限制的 SELECT ，則他們可以選擇該表上的任何記錄，甚至包括那些不屬於它們的記錄。薪水錶會很糟糕。如果任何用戶具有 DELETE 或 UPDATE ，他們可能會忘記 WHERE 子句，然後便會出現在表中。即使是DBA也會發生這種情況，那麼為什麼用戶不會發生這種情況？

性能應該更好，因為我們跳過了整個HTTP通信和Web應用程序代碼

您將放棄使用應用程序來驗證，過濾，授予和拒絕訪問的所有安全性，審核，過濾和非常精細的權限控制。通常，在事務上花費的大部分時間是數據庫處理查詢。應用程序代碼少於此數目，並且您不會刪除HTTP通信，而只是將其替換為SQL通信。

新功能是數據庫遷移的問題，所有內容都反映在架構中

這就是為什麼這麼多的人使用“電子表格作為數據庫”的原因。當您需要協調來自多個來源的數據時，這是一場噩夢。

為用戶提供了強大的查詢功能，而無需付出任何額外的努力

這就像將強大的引擎安裝在骨架底盤，固定在座椅上以及參加比賽。沒有多餘的重量使汽車減速，因此速度非常快！

這裡是一樣的。當然，它是快速而強大的，但是沒有應用程序提供的安全措施，沒有會話，記錄級訪問控制，“用戶盡其所能”或審計。

SQL注入是Web應用程序上最常見的漏洞之一，您正在向用戶提供SQL控制台。您正在給他們各種各樣的槍支，許多子彈，還有腳，手，頭……其中有些人不喜歡您。

有趣的問題。從理論上講，這可以安全地完成。 MS-SQL可以通過加密來保護連接，對用戶進行身份驗證，並提供細粒度的權限和其他安全功能，例如審核。

實際上，它曾經在胖客戶端可以訪問的Intranet環境中很常見。直接建立數據庫，因此數據庫安全控制是主要的安全機制。這往往做得不好，例如，所有用戶以管理員身份連接，並在應用程序中使用硬編碼的密碼。

一個主要問題是特權升級缺陷。數據庫API非常複雜，呈現出巨大的攻擊面，並且這些協議是為提高速度而設計的，而且協議既舊又沒有Internet強化。例如，Oracle有數百個特權升級漏洞。但是，在這方面，MS-SQL是更好的數據庫之一。您還可以通過鎖定用戶權限來減少攻擊面。

從結構上來說，公開一個允許通用查詢並應用安全限制的接口非常有意義。在某種程度上，隨著REST API獲得諸如自定義查詢之類的功能，人們正在重新發明輪子。

能否做到這一點在很大程度上取決於與用戶的關係。如果這些客戶是具有合同關係的付費客戶，那麼在某種程度上要比隨機的Internet用戶更受信任，可以使用此體系結構。特別是如果不同的客戶端被隔離在單獨的數據庫上。小心行走。在這種情況下，即使您要仔細考慮風險和收益，也可能會因此受到批評。如果您正在運行帶有匿名註冊的Web擴展服務，則可以避免這種情況。儘管值得注意的是，大多數雲平台提供商確實提供了將數據庫端口公開給客戶端的功能。

我已經構建了兩個RESTful接口，並為客戶提供了直接的SQL訪問。

這裡的問題是，這個問題從根本上來說是有缺陷的：

很多工作後端開發人員所做的就是通過HTTP為客戶提供CRUD訪問，本質上是將數據映射到內部數據庫以及將其映射到內部數據庫。讓我們將其簡化為4個任務RE數據訪問：

1. 驗證傳入的數據。
2. 身份驗證，授權和日誌記錄。
3. 公開有限的功能集。
4. 提供對用戶敏感的API。

DB通常不提供這些任務所需的工具。例如，我可能想要：

1. 使用外部服務驗證傳入的數據。
2. 使用OAuth提供身份驗證，並使用角色提供對特定行的訪問權限。然後，我有一些要根據角色/數據訪問來寫的特定日誌。
3. 我可能只想公開某些報告（例如，出於性能（考慮DoS）或業務原因）。
> SQL並不是大多數客戶大部分時間想要的格式。 ol>

雖然我確定每個數據庫都有一些功能各異的數據庫在這些情況下...通常，大多數數據庫將不支持這些情況中的大多數，因為它們是數據庫，因此並非旨在處理業務邏輯。

所有這些，在某些情況下，客戶端需要 數據庫級訪問權限-在這種情況下，您 會找到確實提供直接訪問權限的解決方案。沒有什麼可以阻止這種情況的發生-這只是典型的情況。

性能

您說性能應該“更好”，只是現在您已經授予惡意行為者完整的破壞數據庫性能的權限。當然，他們必須進行身份驗證，但是“惡意”演員也可以是“天真，無能”的合法用戶。當用戶開始在他們可以找到的所有表上運行外部聯接，數據庫中每個未索引字段上的where子句以及計算上昂貴的計​​算字段時，您將怎麼辦？除非您的數據庫很小，否則您將面臨這種風險。

我的猜測是您的數據庫很小，因為面向數據庫的Web應用程序應該做的一件大事是緩存最常見的結果。並非每個服務都可以做到這一點，因為某些服務被明確設計為提供完全一致的讀/寫訪問權限。但是許多是只讀的，可以忍受一些延遲。更新一致性。如果這些服務使用內存緩存（如mecached，redis等），則其速度實際上比直接DB訪問快數千倍。

驗證

除非每個表上都有更新觸發器這需要某種業務規則驗證，直接訪問是破壞您誠信的好方法。哦，那是一個有人在其中寫字母字符的郵政編碼字段？沒問題。電話號碼字段包含字母？精細。貨幣字段包含逗號和分號？也許有人試圖通過邏輯黑客給自己免費獎金。您真的相信每個單用戶都可以執行與您的Web應用程序相同級別的驗證嗎？您應該退出編碼並成為牧師，因為您的信仰水平令人難以置信。

維護

有時您需要使數據庫脫機以進行重大維護。發生這種情況時，緩存的Webapp至少可以繼續為讀取提供服務，但是在整個用戶社區中都有直接訪問的麻煩。有時您想將數據庫遷移到功能更強的服務器。那是什麼？您在讓所有用戶同時切換其連接字符串時遇到麻煩嗎？有時您想切換到群集。哦，那些硬編碼的連接字符串現在真的在@ $$中咬你了，不是嗎？安全性是否只是因為端口更新了防火牆規則而要求您切換端口？嗯...是時候通知所有客戶他們的連接字符串需要更新了。

結論

如果您打算從來沒有幾個客戶或一個以上的客戶幾千行，並且您確定您的數據庫/應用程序不會擴展到超出此玩具大小的範圍，那麼直接訪問就是Just Fine（TM）。另一方面，如果您的數據庫有一天可能會超出其當前的版本，或者您想要進行涉及重組，調整規模或重新定位的大型遷移，那麼您將非常幸運，因為您有幸擁有了這一層的間接支持您的培根，並帶來了可擴展的高性能解決方案的所有優點。

在某些情況下，這可能是一種合理的方法：

1. 客戶獲得只讀訪問權限。

2. 他們獲得了對整個數據庫的讀取訪問權限：它是所有客戶的準公共數據，或者僅包含他們自己的數據。特別是，它不得包含用戶PII或受監管控制的數據。

3. 您不必介意他們閱讀他們想要的內容或進行複制。例如，如果洩漏並完全公開，那就太煩人了。

4. 他們不訪問實時生產系統，而是訪問寫後鏡像或數據倉庫。

5. 您已充分考慮並解決了敏感數據或特定於客戶的數據洩漏到倉庫中的風險。

6. 該系統在技術上與您的實際生產系統隔離。我想看看是否可以使用您的數據鏡像創建 Google BigQuery服務，並授予訪問權限。

7. 您有很好的方法來管理訪問權限，包括吊銷，濫用檢測，還包括讓客戶管理授予他們的內部訪問權限。再次，將其外包給BQ的IAM之類的IaaS提供商可能比自己提出要容易得多。

8. 客戶想要可以很容易地用SQL表示的數據，並且他們知道如何編寫SQL。

9. 您導出的架構足夠穩定，或者您的客戶足夠寬容，因此可以更改架構和打破他們的查詢不是一個大問題。

ol>

這些條件並不完全是黑白的，但是直接訪問包含許多用戶信息的實時數據庫會得到以其他答案描述的方式增加風險。

一個合理的假設場景是：您有一個待售物品的複雜零件目錄。有關您擁有哪些零件以及它們的價格是什麼的信息在商業上並不敏感，您也不必擔心人們會保留這些零件的副本。而且它比簡單的清單還要復雜：也許定價之間存在復雜的關係，或者哪些部分可以協同工作。

如果滿足所有這些條件，那麼出發點就是提供下載數據格式為CSV或JSON。如果您不願意這樣做，那麼授予SQL訪問權限也可能不合適。但是，在某些情況下，授予BQ訪問權限比提供下載要好：

• 表太多了，管理導入將使客戶煩惱。

• 數據非常大（TBs），並且用戶查詢讀取的數據相對較少。

• 數據經常被導出，因此，再次，批量下載將很難保持最新。

• 您要提供有趣查詢的罐頭示例並控制查詢引擎。

• 您的客戶有足夠的技術來編寫SQL，但又不想運行自己的導入系統和數據庫的麻煩。

• 模式經常變化得足以使他們的導入自動化會中斷，但不會中斷查詢。

這種模式的一個很好的例子是Biga上 GitHub上的這個3 + TB數據集。儘管所有這些信息都可以通過GitHub API獲得，但是某些查詢在SQL中將變得更加容易或快捷。 其他數據集包括Google上的政治廣告以及舊金山的電影地點。

這是貝葉斯式的答案...

作為一個行業，我們集體擁有大約三十年的設計面向用戶的3層應用程序的經驗，並且積累了關於如何進行操作的大量知識。做對了。正如其他答案所示，不一定錯誤地偏離這種模式，但是您將處在人煙稀少的地區，並且犯重大錯誤的風險更大。

有時會完成。 Esp。如果沒有更好的選擇，並且處於（受控的）受控環境中。成功率很低。

1. RDBMS在安全性方面遠遠落後於HTTP服務器。他們在開發和優化時考慮了不同的目標。他們的一般用例所面臨的環境比典型的HTTP服務器友好得多。甚至無意中將偵聽的DB端口暴露給Internet也被認為是安全故障。

2. 行級訪問控制是一回事，但它很少適合數據庫的業務邏輯和數據庫越規範化，並且您的權限系統越複雜，適合的數據庫就越少。

3. 互操作性：考慮到數據庫訪問協議及其相應驅動程序的深層混亂，您寧願不加限制您的用戶使用某些開發堆棧或平台。每個人都有HTTP或SOAP客戶端可用，您選擇的SQL Server客戶端-您確定嗎？您最好考慮更改數據庫軟件。從Oracle遷移到MySQL還是將過期從PostgreSQL 9.2升級到12？使用HTTP接口，您甚至不需要通知客戶端就可以做到這一點。一些停機時間和一些錯誤，稍後您完成了。

4. 可使用HTTP的安全和網絡管理工具（防火牆，代理，負載均衡器等）可用且種類繁多。 。幸運的是，找到了一個能夠理解TDS協議的入侵檢測系統。

ol>

tl; dr：不要將您的DBMS暴露給公共網絡，因為網絡蠕蟲喜歡攻擊面廣。

運行信息系統的我們正與網絡蠕蟲發生戰爭。他們有反對我們的一切優勢：他們很聰明，有很高的動力，他們只需要在我們的系統中找到一個漏洞來偽造我們。

我們正在捍衛我們的系統。我們必須塞住所有孔。一個好的出發點是限制孔的數量。

Web服務器是漏洞。在限制暴露於公共網絡的Web服務器的攻擊面方面，已經完成並正在進行大量的工作。當網絡蠕蟲提出一些新的Web服務器漏洞時，供應商通常會迅速推出補丁。而且，這些補丁對於我們迅速應用並不困難。

公開暴露的DBMS也是一個漏洞。當然，其中一些具有出色的列，行，視圖和表粒度訪問控制。因此，從理論上講，有可能在保持安全性的同時允許公共網絡訪問。

但是，如果網絡蠕蟲對DBMS進行某種形式的利用，會發生什麼？

1. DBMS服務器比Web服務器更為複雜，因此在緩衝區溢出，特權提升和其他利用方面具有更大的潛力。功能的每一點都是潛在的攻擊媒介。
2. 發現DBMS攻擊次數少於Web服務器攻擊次數，因為大多數DBMS位於防火牆之後。
3. 如果網絡蠕蟲侵入了您的DBMS，則它們會偽裝您的數據和您的應用程序。
4. 確實很難對DBMS服務器應用補丁來插入數據庫。
ol>

此外，如果將DBMS暴露在公共網絡中，則安全審核員將不喜歡它。一點也不。而且出於充分的理由。

請不要這樣做。

似乎沒有人這樣做，所以肯定存在我忽略的安全風險。

人為錯誤，授予錯誤的授權數據庫級別的客戶，可能會產生嚴重後果。

為什麼我們不能向客戶提供公共SQL訪問權限？可能出什麼問題了？

您正在為客戶的系統帶來不必要的麻煩：
-為了對數據庫編寫適當的sql查詢，您的客戶必須了解您的數據庫數據庫模式，還是他只需要數據庫模式的一部分？
-您客戶的代碼將與您的數據庫緊密結合，對模式的任何更改都必須反映在客戶的代碼上。

因此，從第一年開始，我們傾向於編寫應用程序和API端點來抽象化數據庫的結構。

類似的事情實際上是由諸如 Hasura之類的程序完成的，該程序通過GraphQL接口使用PostgreSQL的權限系統對行級和列級權限公開數據庫。客戶端無法獲得SQL查詢的全部功能，但可以通過GraphQL查詢獲得子集。這允許查詢獲取數據的子集（而不是每一列），以及聯接和某種級別的過濾。沒有充分發揮SQL的全部功能，這意味著您無法創建對服務器發起DOS攻擊的查詢。每個查詢都轉換為一個SQL查詢，同時限制對可能會使服務器運行速度降低的功能的訪問。

根據對遷移的關注，您肯定能夠通過遷移數據庫來更新API。如果不需要，Hasura允許您使用自定義SQL視圖將實際表轉換為面向公眾的表，因此您可以更改內部表示形式而不會影響API。此外，您總是可以將Hasura換成其他任何隻公開相同API的服務器，因此您不會被鎖定。

但是，您仍然有HTTP的開銷，但是您也可以使用WebSockets接口，以避免每次都重新連接。

您問的問題

為什麼我不能讓客戶直接連接到我的數據庫？

答案真的取決於您是誰在這種情況下是指客戶。互聯網上隨機的人？正如大多數其他答复所說的那樣，這是一個壞主意，並且給出了許多充分的理由。但是，如果您的客戶是值得信賴的業務合作夥伴，例如B2B，並且您的站點之間甚至還有聯合的SSO解決方案之間都有VPN連接，那麼這並不是一個好主意。這將是一場噩夢，但是除非有充分的文檔證明，否則您將花費一整天的時間回答有關每個表中包含哪些數據的問題。

似乎沒有人這樣做

您可能會感到驚訝。

即使在我所見過的最先進的RDBMS中，也無法獲得足夠好的安全性。除了最瑣碎的應用程序之外的所有業務規則都太複雜了。如果您不希望邪惡的黑客造成嚴重破壞，則需要編寫自定義代碼，限制其以特定方式可以執行的操作。現在，您可能將其全部放入存儲過程中，只允許您的客戶端調用這些存儲過程...但是您又回到了開始的地方-您仍然在基本數據庫之上有一個自定義應用程序。而且，存儲過程語言通常比通用編程語言（PHP / C＃/ Java / Javascript / Ruby / Python / etc）笨拙且難以使用

如果您看一下Elasticsearch API的完成方式，那麼您可能會發現與您的想法相似。如果您的案例很簡單，僅使用Elasticsearch即可避免開發任何自定義後端代碼並構建自己的REST API的需要。客戶直接訪問Elasticsearch REST API就是這樣。（不是我主張Elasticsearch。我只是發現這是您想法的一個很好的真實示例）

您的第三個要點，確實是您的第一個要點，因為這是不允許直接訪問的最重要原因。

• （My-）SQL權限很漂亮細粒度，所以我認為應該不存在任何明顯的安全問題

未執行此操作的主要原因是因為行級安全性尚未實現這麼長的時間，沒有行級安全性，您的方案就沒有安全性。 MySQL甚至還沒有行級安全性。

行級安全性並沒有解決您的安全性和設計問題，這只是必要的第一步。基本上，沒有什麼能比安全問題更重要。

這是可以預期的。我將描述一個包含50到500個表的數據庫較為複雜。即使人們100％誠實，我也不希望他們通過直接交互使用數據庫。

我相信，在大多數組織中，如果可以通過應用程序完成某些事情，那麼即使用戶具有能力和知識，通過這種方式進行的操作也比通過直接數據庫訪問更好。

將用戶拒之門外並要求他們以定義的方式進行更改的能力是離開Access和/或Excel的原因之一。從一個至少可以假設所有用戶即使不是同樣熟練的人都值得信賴的組織擴展到更廣泛的Internet，在這個組織中您應該真正假設任何隨機用戶都是壞演員...

聽起來好像您不太擔心哪些客戶端看到哪些數據行，或者擔心客戶端需要更新而不僅僅是查詢表。

一種可能適合您的使用方式情況是直接或間接向客戶提供數據庫副本。想像一下，僅根據應用程序的複雜程度，將它們作為文件發送給SQLite克隆，要么在應用程序內，要么直接發送給他們。在查詢格式錯誤的情況下（至少對於您的服務器而言），這可以繞開性能方面的顧慮。完整。

如果選擇正確的數據庫服務，這是可能的。實際情況是，很少有提供權限粒度和訪問模型的混合體。無需嘗試推廣產品，但以今天為例，您可以使用“企業級”數據庫系統完成類似的任務，例如

• DB2
• 雪花
• Oracle
• MSSQL

，可能還有其他。

挑戰在於這些系統的管理非常複雜。如果您

1. 有團隊，
2. 可以支持&承擔運營費用，
3. 可以通過這種方式出售數據產品，
ol>

那誰來阻止你？

通常阻止他們這樣做的是

1. 更多的人才可以構建應用。應用程序可能也是他們首選的職業發展方式，而不是罕見的DB配置開發人員
2. 測試這些系統進行質量檢查的方法不同於應用程序的方法。為此進行管理可能需要更多時間，或者遇到同樣的人才挑戰。
3. 銷售團隊通常對技術不是很精明，但是解決方案工程師卻很精明。大多數同行的解決方案工程師都不是數據庫管理員。這增加了銷售摩擦。人們買對他們有意義的東西。
ol>

輕踩一下。創新。做好計劃。

有優點和缺點，但是如果您打算將數據庫公開給客戶端，則僅允許他們訪問特定的架構，從而使它成為一個小的攻擊面。該架構將僅包含您將允許它們運行的存儲過程。這將緩解SQL注入攻擊，用戶具有的授權取決於SQL授權。

如果希望不同的客戶只能訪問他們自己的記錄，並且對同一客戶組織中的不同人員具有不同的授權，則可以在越來越大的存儲過程中進行所有這些操作。本質上，您是在存儲過程中構建自己的API，並且如果要執行此操作，則最好在可維護性方面，在中間層擁有自己的API層。如果您在性能和維護方面都具有復雜的業務邏輯，那麼在中間層要比在存儲過程中更好。

因此，總而言之，您可以將所有內容放入SQL數據庫和存儲過程中。如果你想。無論是從功能角度還是從安全角度來看，您都可以使用較小的攻擊面進行操作。但是，如果您有一個複雜的系統，並且了解其中涉及的內容，那麼大多數時候您將不想這麼做。

為什麼不能只讓客戶直接連接到我的數據庫？為什麼不通過公開SQL端口，完全跳過HTTP API來使客戶訪問數據庫？

您不能/不應該因為 數據庫引擎提供的訪問控制可能缺少您需要的粒度，無法充分控制客戶端的訪問。

大多數數據庫都已規範化，因此會存儲所有相同類型的對象在同一張桌子上。甚至那些屬於不同客戶的服務器。

大多數（所有）數據庫引擎權限系統都會一次授予或拒絕對整個表的訪問，而不是逐條記錄。並且您可能不希望一個客戶看到其他所有客戶的數據。

所以這就是為什麼值得編寫一個API處理程序來代表客戶進行數據庫查詢的原因，並僅返回任何給定客戶有權接收的結果。該API還可以實現數據庫引擎無法實現的計費，費率限制，日誌記錄和其他便捷的業務功能。

因此是的，您可以授予直接數據庫訪問和設置權限一個每晚存儲的過程，它將客戶需要的所有數據轉儲到某個表中，而您只允許他們訪問該表。但是，通常不會為每個客戶創建一個表，這違背了規範化。它將導致客戶看到新數據的延遲，重複出現的IO高峰以重新生成客戶可見的表，並使用大量磁盤空間。

不要為客戶提供直接的數據庫SQL訪問權限。

安全性

應用程序服務器（Web服務器，容器等）應直接暴露給客戶/不受信任的外部參與者，並為此進行更強大的安全性測試。相比之下，數據庫服務器經常發現漏洞，如果直接暴露這些漏洞，很可能會受到利用。

應用程序邏輯&許可通常很重要。儘管數據庫系統提供了一些有限的功能，但將它們集中在功能更強大的系統（應用程序邏輯）中通常可能更具凝聚力。

解耦

允許客戶直接耦合到您的物理數據模型會導致問題，因為您在合同上/商業上有義務維護該完全相同的數據模型。這是非常不可取的，因為由於更改數據模型會破壞客戶，因此無法維護/改進/重構數據模型。 （管理層會告訴您不要這樣做。）

如果您看不到客戶如何使用它，那就特別糟糕。如果您給他們一個原始的數據庫連接，&甚至無法自己解析/重寫他們在做什麼。

後端之間的可移植性也是一個問題。儘管數據庫為您提供了安全性和存儲的proc /腳本編制功能，但這些工具所提供的功能有限且性能不佳，更糟糕的是它們是特定於供應商的。當出於性能/可伸縮性/成本的原因而要遷移到其他數據庫時，您會發現自己陷於困境。

首選解決方案是收縮到一個“邏輯模型”，該模型在某種程度上與物理模型脫鉤實施。這樣做的好處還在於，它通常可以為外部各方提供一個更簡單，更清晰，更有用的模型。

更好的API結構

一些潛在的改進：

1. 如前所述，通常，為客戶使用更容易定義良好的清晰邏輯模型。
2. 通過REST提供它，使其從各種客戶端軟件&工具中得到更廣泛的使用，而不是要求客戶端軟件包括特定的數據庫庫，打開連接&運行SQL。
3. API諸如GraphQL之類的標準可以為您提供真正不錯的&，同時在您的 ologic 模型中實現強大的廣義圖形訪問和數據檢索-即SQL的許多優點-同時提供了更好的權限和控製程度。
ol>

開發效率

軟件工程工具- IDE，調試器，框架，庫，錯誤處理，日誌記錄，性能和概要分析-對於應用程序語言（Java，C＃..還包括Node JS，Rust，Go等其他語言），可能要比存儲過程&好兩個數量級

鑑於生命週期維護成本是初始開發成本的4-10倍，即使是一個“很小”的初始項目，例如將數據暴露給客戶的7天，也可能會導致巨大的生命週期成本差異。 / p>

在開發方面，我希望使用合理的應用程序語言工具&一個現代框架（Spring Boot，GraphQL或類似的工具），可使生產率提高3-4倍。在客戶方面，我希望使用&數據會容易得多，因為中斷不會太多（因為API可以保持穩定）。

聲稱不會為開發人員帶來任何成本公開SQL可能會忽略嘗試實施安全規則，修補數據模型問題以及事後解決安全問題的成本。

編寫自定義的數據庫連接代理以讀取數據庫有線協議，解析SQL查詢並阻止SQL查詢級別的安全性問題要花費多少錢？因為如果您允許使用原始文件， SQL連接和數據庫規則不足（我們非常了解它們），這就是您的安全性後退方法。

建議

您的客戶的青睞。 GraphQL可能適合您，也可能不適合您，但是它確實提供了SQL的許多優勢，同時繞開了許多問題。

使用現代的應用程序語言&框架-我更喜歡Java（SpringBoot）或C＃，但還可以使用NodeJS等其他選項。 （避免使用PHP）。

我建議：

1. 將其插入GraphQL框架中，構建一個邏輯模型，嘗試GraphQL。
2. 或者構建為每個定義明確的視圖提供一個REST API，在應用程序中實現權限邏輯，並在可能的情況下回答JSON －如果您的客戶確實想要平面數據，則可以添加CSV選項。
ol>

希望如此有幫助！

只要您不授予他們對數據的寫訪問權限，就不應允許他們修改或讀取對他們不應該讀取的數據的訪問權限，這似乎是可以接受的。

許多系統將屬於不同客戶的數據放入共享表中，這顯然是不合適的方法。

或者，您可以通過受信任的VPN建立連接。但是，從數據庫服務器安全性的角度來看，需要為屬於數據庫服務器上客戶端數據庫架構的用戶配置更安全的權限和嚴格的訪問權限。內部拓撲。

我不會把它放在安全性觀點上，而是在軟件工程上

為什麼不讓客戶訪問直接CRUD？

因為CRUD（創建，讀取，更新，刪除）原語是 atomic 原語，因此未實現業務邏輯。關係許可模型不考慮數據隔離

假設安全性定義明確，這是CRUD無法正常工作的幾個原因

CRUD是原子的。對於業務來說太原子化了

資金轉移是通過貸方和借方進行的。兩個查詢。您是否100％確定您的客戶將以預期的順序並在交易中運行所有查詢？您的關係數據庫不會強制執行牛頓約束，即“無法創建或銷毀資金，而只能進行轉移”。

REST API保證在事務中運行兩個查詢。

權限受到限制

關係權限未考慮數據語義和業務邏輯。如果您有權使用UPDATE（例如，出於討論目的，您沒有權限訪問DELETE），則不能（輕鬆地）限制客戶想要寫入的值。

如果您更新該數字怎麼辦？當您的公司中實際上沒有多少可用的優惠券時？

REST API將在發出查詢之前驗證輸入中的數據

權限不允許隔離

您通常會通過列值（例如TENANT_ID）來區分租戶。 READ訪問權限授予對每條信息的訪問權限。

SQL權限允許將特定角色的可用列限制為特定角色，而不是行。

REST API將為每個角色添加過濾器查詢

審核和記錄

通過直接CRUD訪問，您將依靠客戶簽發 INSERT INTO AUDIT_LOG 。除了惡意，您確定所有人都會發出該查詢嗎？在預算有限的情況下，我希望一些客戶“忘記”實施該查詢而忘記進行測試。

REST API會在每次調用時發布審核日誌。

總之

向客戶用戶提供CRUD訪問權限太原始了，它通過向無數用戶訪問同一NAS文件夾中的訂單Excel表格來允許授予相同級別的EVIL。

我目睹了你們人類的災難恢復...

直接訪問數據庫時，您將失去對發出的CRUD語句類型的控制。惡意用戶可以發出諸如from table_name中的delete之類的語句，並且所有數據都將丟失。最終用戶現在最有可能知道數據庫的設計。

這就是為什麼我們擁有 Business Intelligence Objects等商業智能軟件的原因：允許用戶在不掌握SQL的情況下建立自己的查詢，並限制了他們所看到的內容。當然，可以基於每個用戶設置權限。

為了給您一個想法，與我合作的一家公司提供了通過SAP Business Objects遠程訪問數據的功能。用戶可以訪問許多現成的報告，並且不能創建自己的報告（這是設計使然）。他們還每天（或每週）收到由BO生成的一些Excel文件。他們對此感到非常滿意，因為我們正在完成他們的工作，或者大部分是工作。一個重要的標準是：您的客戶是否需要實時數據。如果沒有，則可以像 CSV下載那樣以受控方式提供數據。

乍一看，公開數據庫似乎不是一個好主意。我注意到您說的是客戶，而不是開發人員，這些人實際上是圍繞您的系統進行開發的，出於有效的原因需要遠程訪問。我認為不應授予非開發人員如此廣泛的訪問權限。

您的客戶可能沒有惡意或在技術上不足以乾擾您的系統，但總有機會他們中的一員正在受感染的計算機上工作（仍然有太多人在運行破解軟件或下載可疑應用程序...）。從某種程度上說，無辜的用戶可能比有經驗的IT人士更危險，因為他們自己的安全狀況往往很弱。

如果發生洩漏，尤其是個人數據洩漏。您的公司可能受到某些法規的約束，例如GDPR，並可能因未能充分保護您的數據而被罰款。

您沒有像黑客（或滲透測試人員）那樣在盒子外思考。細粒度的權限是最小的，但是您的安全範圍超出了Mysql。您可以使用MySQL編寫文件，顯然不是在任意位置，但這取決於您的設置。如果Mysql配置錯誤（例如，以root用戶身份運行）或您對某些文件夾具有過多權限，則存在一定的妥協空間。

您還從Mysql中讀取文件，例如：

  select load_file（'/ etc / passwd'） 

最明顯的答案是拒絕 FILE 特權。但是您確定您已考慮所有可能的情況嗎？如果事情出了問題並且您為此受了罪責，您是否願意把工作放在一邊？ （我相信墨菲定律）。

由於似乎沒有人這樣做，所以肯定存在我忽略的安全風險。我們為什麼不能向客戶提供公共SQL訪問權限？可能出什麼問題了？ （請記住，這只是出於好奇而進行的思想實驗）

最壞的情況：您的數據庫服務器受到威脅，然後黑客將服務器用作通往該服務器的網關。公司網絡的其餘部分。這就是現實世界中每天發生的事情：一台計算機遭到黑客攻擊，工作站或服務器暴露在Internet上。它通常始於SQL注入或某些常見漏洞，或者僅僅是利用未修補軟件的漏洞（Think Equifax）。當黑客在計算機上立足時，他們會進入您的網絡，他們會發現什麼？

我會認真考慮這個想法，但是無論您做什麼記錄所有內容。