2009-01-09 169 views
1

我目前正在建立一個商用SFTP服務器,我只是想找一些關於我目前正在考慮實施的設置的意見,以及關於什麼商業安全FTP服務器軟件的建議最好適合。請記住,我負責的數據非常敏感,所以任何意見/反饋都非常感謝。實現SFTP服務器解決方案的最佳方法?

這裏的情景:

1)文件上傳之前,文件壓縮&使用AES 256用鹽加密。

2)通過SFTP(端口22)從客戶端的服務器上傳到我們的SFTP服務器的文件。

3)文件,然後通過我們的(強10字符的字母數字密碼)

我想執行的細節是其他客戶端使用一次性密碼驗證下載了HTTPS:

對於部分(2)中,使用主機密鑰匹配,公共密鑰認證和用戶名/密碼組合打開連接。雙方的防火牆都僅限於允許客戶端服務器的靜態IP連接。

對於第(3)部分,爲每個用戶提供一個用戶名/密碼(用於審計)以登錄到服務器上的監獄帳戶。文件本身的加密密碼是以每個文件爲基礎提供的,因此我試圖在這裏的所有時間應用兩種加密模式(文件停放在服務器上時除外)。

隨着雙方的專用防火牆,SFTP服務器上的訪問控制將被配置爲在短時間內以一定次數的失敗嘗試阻止IP地址,無效的密碼嘗試將鎖定用戶,密碼策略將被實施等等

我喜歡認爲我已經儘可能多地覆蓋了,但我很想聽聽你們對這個實現的看法嗎?

對於商業服務器端的東西,我已經縮小到GloalSCAPE SFTP W/SSH & HTTP模塊或JSCAPE安全FTP服務器 - 我會評估每個週末的適合性,但如果你們中的任何一方有任何經驗,我也很想聽到它。

+0

沒有真正的編程相關。我可以建議一些替代的地方要求:http://stackoverflow.com/questions/321618/where-can-i-ask-questions-that-arent-programming-questions – Kev 2009-01-09 12:32:43

回答

2

那麼Linux和BSD附帶的OpenSSH有什麼問題?

7

由於從客戶的角度來看,數據顯然既重要又敏感,我建議您諮詢安全專家。本土解決方案通常是過度和不足的組合,導致既低效又不安全的機制。試想一下:

  • 的文件是加密前的,所以從SFTP/HTTPS的唯一收穫是會議本身(如登錄)的加密,但...

  • 您使用PKI上傳和OTP下載,所以沒有暴露密碼的風險,只有用戶ID - 對你來說很重要嗎?

  • 您將如何傳輸一次性密碼?傳輸是否安全?

  • 請記住,任何鎖定方案應該是臨時的,否則黑客可以通過鎖定每個帳戶來禁用整個系統。

問題要問自己:

  • 我是什麼保護?
  • 我從哪裏保護它?
  • 什麼是攻擊媒介?
  • 違規的可能性和風險是什麼?

一旦你回答了這些問題,你就會對實現有更好的瞭解。

一般:

  • 您的選擇AES256 +鹽是非常合理的。
  • 多因素認證可能比多重加密更好。它通常被認爲是「你有的東西,加上你知道的東西」,例如證書和密碼,它們都需要訪問。

只要可用的實用程序,許多現成的軟件包既安全又易於使用。查看OpenSSH,OpenVPN和vsftp的初學者。

祝你好運 - 請讓我們知道你選擇什麼方法!

+0

+1建議引入一個人做這個爲了生活 – kdgregory 2009-01-09 12:53:25

+0

我猜想在通過sftp頻道之前對內容進行加密的重點在於內容在服務器上保持加密,所以服務器人員不能偷看它。使用sftp服務器可能只是爲了方便(用於安全認證)。 – PolyThinker 2009-01-09 12:53:29

1
Before file upload, files are compressed & encrypted using AES 256 with a salt. 

這部分環一些警鐘...你寫了一些代碼來執行此加密/壓縮?你如何做密鑰管理?你還說你的密鑰是密碼派生的,所以你使用AES 256和salt會給你一種錯誤的安全感 - 你真正的密鑰空間要少得多。此外,「鹽」一詞在這裏不適用,這表明還有其他弱點。

你最好使用經過很好驗證的實現(例如PGP或GPG)。另外,如果對文件本身(以及體面的密鑰管理)使用PGP樣式的公鑰加密,那麼SFTP服務器的安全性就會大大降低。您的文件可以在休息時加密。

對於系統其餘部分的安全性的爭論非常複雜(大量的協議,認證方案和控制) - 要穩健地保護文件要容易得多,然後爲其餘的做好最佳實踐(這會少得多,也是獨立控制)。