我們的安全部門不希望我們擁有 JOSS Web 組態檔 (oracle-db.properties)，其中包含我們要連接的資料庫的純文本密碼。有人告訴我，我應該從 JBOSS 密碼保險庫中檢索密碼，但我很難弄清楚如何做到這一點，并發布了一個問題來嘗試找出答案。（請參閱Java/Spring：如何從 JBOSS 保險庫中檢索密碼）
我正在考慮是否將密碼加密密碼存盤在 oracle-db.properties 中并使用此處顯示的 AES 加密演算法https://howtodoinjava.com/java/java-security/aes-256-encryption-decryption/來解密它（我使用加密程序來確定要放入 oracle-db.properties 檔案的加密密碼）。我在想，因為密鑰和鹽都存盤在代碼中，所以有可能對代碼進行反向編譯以獲取這些值。我想知道這種方法與從 JBOSS Vault 檢索密碼的優缺點是什么（https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.3/html/installation_guide/vault_for_jws_) . 對于大多數公司來說，將 AES 256 添加到我們的應用程式通常就足夠了嗎？
uj5u.com熱心網友回復：
我在想，因為 Secret key 和 salt 都存盤在代碼中，所以有可能對代碼進行反向編譯以獲取這些值。
正確的。AES 加密該密碼幾乎一無所獲，實際上使事情變得更糟：它看起來是加密的（因為它是加密的），并且人們會假設進行加密的人不會如此密集以至于將密鑰留在旁邊密碼檔案。
除了它實際上就在那里（他們必須反編譯類檔案，但這并不困難，也不會變得困難），所以你已經造成了錯誤的印象。
您的安全團隊需要為您提供威脅模型以供使用，他們不能只說“不要從檔案中讀取密碼”，因為那是不可能的。為什么你不能那樣做？他們想要減輕哪些攻擊途徑？
例子：
- 我不希望 syadmin 隨便 - 輸入
cat該檔案，從而將密碼涂抹在他們的螢屏上和他們的終端應用程式的歷史緩沖區中，讓任何人都可以隨意瀏覽。
答案：只需 base64 即可。是的，它根本不是加密貨幣，但至少它毫不含糊：人們會看到它的 base64 并假設他們不是白癡知道這意味著密碼就在那里。但它可以防止肩部沖浪和“意外”回憶（有人用眼睛看到它，因此即使他們不打算記住它也可能會記住它）。必須有人不遺余力地 unbase64 它，如果規則說你不能這樣做，至少你現在已經強迫員工徹底違反規則并可能犯罪。
- 恐怕有人會入侵服務器，使其僅讀取檔案并將其回顯給黑客。
然后 base64 什么都不做，AES 計劃也不做（因為他們也可以讓你的網路服務器cat擁有自己的 jar 和類檔案，可能）。一種解決方案可以是啟動服務器的腳本讀取檔案（并且被操作root，在一個帳戶下運行服務器webserver） - 該腳本讀取密碼（從而允許您使該檔案由 root 擁有并且該webserver帳戶不可讀） , 將其作為引數或環境變數傳遞。當然，這要求您考慮泄漏 env var 的風險遠低于文本檔案。這當然是可能的。或者，該腳本可以將密碼寫入一個純文本檔案，該檔案可由webserver用戶，網路服務器將讀取它，然后洗掉該檔案。這并不常見，但它顯示了威脅模型的意義：一旦你知道你在戰斗什么，你就可以制定一個計劃并相應地執行。
- 我想使用 JBoss Password Vault
這不是明智的安全策略：這不是威脅模型。JPV 沒有解決任何這些問題，啟動。
- 我想要一個獲得對盒子的完全訪問權限的黑客，包括用戶的 root 和/或寫訪問權限，以便
webserver用戶無法將其用作破解資料庫的跳板。
這是不可能的，如果安全團隊告訴你這是他們需要你減輕的威脅，你可以告訴他們去拿哈利波特的魔杖，因為沒有它，你就無法交付。例如，黑客可以簡單地重寫您自己的類/jar 以將密碼發送到黑客的服務器。這強烈表明您的安全團隊不知道如何完成他們的作業：無論多么不可能，他們都會考慮風險并要求“防范”它（這不是真正的事情；您可以減少和減輕，安全不是黑色的和白色）不考慮威脅模型或權衡。
讓他們接受教育，或者決定對他們撒謊。當他們這樣做時，您將無法獲勝。也許越過他們的頭腦，讓老板參與進來。
- I want a hacker that manages to obtain a clone of the entire disk to not be able to access the DB.
Doable, but tricky. One easy way is that the server won't know the password either and will boot in an admin-only-mode, where the admin types the db password into a form which then unlocks the server to run properly. The server can then retain this password in memory only, thus foiling any disk copies. Except, you better turn of swap or store that on a different disk!
If you don't want that manual action, there's TPM chips (windows/linux systems generally) or T2 (apple). I don't know of any java-accessible tools that can do this, or DBs that can. These kinds of algorithms require a challenge/response model, you can't just 'store a password' in these in a meaningful way.
Ask the security team for a budget of 80k or so. If they balk, well, they've learned something. Security is a game of tradeoffs.
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/448419.html
上一篇：升級Swift依賴項的加密演算法
下一篇：Flutter保密存盤