?操作系統(tǒng) 、 虛擬機管理程序

我們在操作系統(tǒng)和虛擬機管理程序級別遇到的問題在其他系統(tǒng)領域重新出現(xiàn)，解決方案有時是相似的。在本節(jié)中，我們將簡要討論數(shù)據(jù)庫，作為操作系統(tǒng)安全原則，問題和解決方案如何應用于其他領域的一個例子[77]。數(shù)據(jù)庫系統(tǒng)的安全性遵循與操作系統(tǒng)中類似的原則，主要關注的是身份驗證、特權、訪問控制等。訪問控制也是如此，其中許多數(shù)據(jù)庫默認提供自由訪問控制，以及基于角色的強制訪問控制，以便對更敏感的數(shù)據(jù)進行更嚴格的控制。

將每個用戶表示為一個安全域，我們需要 回答的問題涉及，例如，用戶的權限、應記錄以進行審核的操作以及磁盤配額、CPU 等資源限制處理時間等用戶的權限包括連接到數(shù)據(jù)庫、創(chuàng)建表、在表中插入行或從其他用戶的表中檢索信息的權限，等等。請注意，有時，除非通過特定的SQL查詢，否則無法訪問數(shù)據(jù)庫的用戶可能會在所謂的SQL注入攻擊中制作惡意輸入以提升其權限。

雖然數(shù)據(jù)庫級 訪問控制限制誰可以訪問數(shù)據(jù)庫的哪些元素，但它不會阻止在操作系統(tǒng)級別訪問磁盤上的數(shù)據(jù)。因此，許多數(shù)據(jù)庫支持對磁盤上的敏感表列進行透明數(shù)據(jù)加密，通常將加密密鑰存儲在數(shù)據(jù)庫外部的模塊中。在極端情況下，數(shù)據(jù)庫中的數(shù)據(jù)可能會被加密，而只有客戶端持有密鑰。

查詢此類加密數(shù)據(jù)并非易事。雖然存在復雜的加密解決方案（例如同態(tài)加密），但它們非常昂貴且通常使用更簡單的解決方案。例如，有時存儲信用卡號 的哈希值而不是實際號碼就足夠了，然后在數(shù)據(jù)庫中查詢哈希值。當然， 在這種情況下，只能進行完全匹配 — 因為我們無法查詢數(shù)據(jù)庫中的值是否大于、小于或類似于其他值（平均值或總和等聚合值也是如此）?？赡埽２樵兗用軘?shù)據(jù)庫 的問題是一個活躍的研究領域，超出了本知識領域的范圍。

雖然 常規(guī)數(shù)據(jù)庫中的安全性和訪問控制已經(jīng)不平凡，但在外包數(shù)據(jù)庫（ODB）的情況下，事情變得更加復雜，組織將其數(shù)據(jù)外包對外部服務提供商的管理。具體而言，數(shù)據(jù) 所有者在外部數(shù)據(jù)庫提供程序創(chuàng)建和更新數(shù)據(jù)，然后處理客戶端的查詢。除了我們之前對機密性和加密的擔憂之外，出現(xiàn)的問題還涉及對提供商的信任程度。數(shù)據(jù)所有者或查詢客戶端是否可以信任提供程序向查詢提供由原始數(shù)據(jù)所有者創(chuàng)建的數(shù)據(jù)（真實性）、未修改（完整性）和新結果？

從概念上講，可以通過簽名來保證完整性和真實性。例如，數(shù)據(jù)所有者可以對整個表、表中的行/記錄甚至行中的單個屬性進行簽名，具體取決于 所需的粒度和開銷。通常還提倡基于經(jīng)過身份驗證的數(shù)據(jù)結構的更高級解決方案，例如Merkle哈希樹。在最初用于分發(fā)經(jīng)過身份驗證的公鑰的 Merkle 哈希樹中，樹中的葉節(jié)點包含其數(shù)據(jù)值的哈希（數(shù)據(jù)庫記錄），每個非葉節(jié)點包含 其子節(jié)點的哈希，以及根節(jié)點的哈希已簽名并發(fā)布。驗證葉節(jié)點 中的值是否確實是原始簽名哈希樹的一部分所需要的只是中間哈希節(jié)點， 客戶端可以使用 與樹大小的對數(shù)成比例的哈希數(shù)快速驗證。當然，范圍查詢和聚合涉及更多，研究人員提出了比默克爾哈希樹更復雜的方案，但這些都超出了此知識領域的范圍。要傳達的信息是，通過一些努力，我們可以保證真實性、完整性和新鮮度，即使在 ODB 中也是如此。