作者 主題: 問個煩惱很久的問題!!!請各位大哥可以給予指教!!感恩不盡  (閱讀 18773 次)

0 會員 與 1 訪客 正在閱讀本文。

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
是這樣的!!!
小弟的公司最近要弄個防火牆

我規劃的架構大概是這樣的
請大家給我點指教

公司有一台"重要的資料庫"(真的很重要)
我把它放在網路內部
然後呢
WEB SERVER 放在 DMZ
然後在WEB SERVER這一台同時弄iptables
只開port 80
因為其他的服務放在機房的server

但是公司的股東們還是認為這樣"太危險"
請問一下
大家能給我更好的建議
或者這樣的規劃有問題嗎

mandel

  • 活潑的大學生
  • ***
  • 文章數: 211
  • 性別: 男
    • 檢視個人資料
限制使用,只允許特定的user,特定的ip才能使用
如果還不行,那就用鎖國理論--把網路線拔了,這樣就「不危險」 :D

u8526425

  • 俺是博士!
  • *****
  • 文章數: 1135
  • 性別: 男
    • 檢視個人資料
那弄個vpn如何 ?
多見者博,多聞者智,拒諫者塞,專己者孤

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
既然是網站怎麼可能限制特定user呢?????
拔掉網路線??
把電腦也砸了如何???

引述: "mandel"
限制使用,只允許特定的user,特定的ip才能使用
如果還不行,那就用鎖國理論--把網路線拔了,這樣就「不危險」 :D

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
跟VPN有關係嗎??

引述: "u8526425"
那弄個vpn如何 ?

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17446
    • 檢視個人資料
    • http://www.study-area.org
能請問一下, 股東認為"如何"個危險法呢?
說來聽聽? 才能對症下藥啊...

coffeefish

  • 鑽研的研究生
  • *****
  • 文章數: 572
    • 檢視個人資料
資料庫上的user權限要做一個規劃,不需要寫入,刪除權限的就拿掉!應該就會安全一點!只是不知道貴公司的股東們是擔心哪個部分的!問一下會比較清楚!

梁楓

  • 俺是博士!
  • *****
  • 文章數: 6220
    • 檢視個人資料
安不安全,你現在講的太模糊...
不要太相信 iptables... 現在的世界裡,是根本沒有防火牆的
在現在的網路環境裡,百分之八十的攻擊來自於你不能設防的服務
比如web,email甚至dns

防火牆只是一隻看門狗,一但放行,就不能在給於限制

所以安不安全是要看你整體的架構的
如果你有心的話,就把你現在的架構劃出來給大家看看?

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
我說出來
大家一定會笑我的

股東說你可以保證出了事你負責嗎

說這樣的簡單架quote="netman"]

引述: "netman"
能請問一下, 股東認為"如何"個危險法呢?
說來聽聽? 才能對症下藥啊...

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
資料庫上只能允許公司"內部"同仁"查詢" 而已

因為有弄個網站
她們怕駭客從外部進來把資料庫的資料偷走啦

引述: "coffeefish"
資料庫上的user權限要做一個規劃,不需要寫入,刪除權限的就拿掉!應該就會安全一點!只是不知道貴公司的股東們是擔心哪個部分的!問一下會比較清楚!

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
我也知道我說不清楚
就是因為不太會表達
所以才會沒有辦法說服股東

不相信iptables  ,哪請問有哪各更好呢
因為我懂的不多..........


我這一台只有WEB 80 port,其他的服務在ISP 機房主機

我現在的架構就是公司內部網路(資料庫也在裡面)

然後外部網路有一台WEB SERVER上面弄客IPTABLES
然後這WEB SERVER只能往資料庫丟資料和查詢

這樣說不知道您能聽的懂嗎
不好意思



引述: "梁楓"
安不安全,你現在講的太模糊...
不要太相信 iptables... 現在的世界裡,是根本沒有防火牆的
在現在的網路環境裡,百分之八十的攻擊來自於你不能設防的服務
比如web,email甚至dns

防火牆只是一隻看門狗,一但放行,就不能在給於限制

所以安不安全是要看你整體的架構的
如果你有心的話,就把你現在的架構劃出來給大家看看?

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17446
    • 檢視個人資料
    • http://www.study-area.org
呵... 你是專家啊... 怎會聽股東說的才能決定安全否?

全世界沒人何人可跟別人做安全保證! 杜雷斯也不敢!  ^_^
就算你再弄更多的方案, 他還是可問你同樣的問題啊...
但出問題, 你當然要負責, 但得找出原因才能釐清歸屬.
至於原因如何解釋, 我相信你自己會想法子的了...

kevin5307

  • 可愛的小學生
  • *
  • 文章數: 6
    • 檢視個人資料
單純就架quote="argus"]料庫很重要的話..
那建議你的網路配置要切兩組DMZ,一組Intranet
DMZ1: Web Server
DMZ2: DB Server
Internat: PC User

ACL
Any => Web Server : port 80 or port 443
Web server => DB Server (請只開資料庫連接的Port)
Pc User => Internet : any accpet
PC User => DB Server : Drop (除非你有需要直接存取 DB的需求)


引述: "argus"
我也知道我說不清楚
就是因為不太會表達
所以才會沒有辦法說服股東

不相信iptables  ,哪請問有哪各更好呢
因為我懂的不多..........


我這一台只有WEB 80 port,其他的服務在ISP 機房主機

我現在的架構就是公司內部網路(資料庫也在裡面)

然後外部網路有一台WEB SERVER上面弄客IPTABLES
然後這WEB SERVER只能往資料庫丟資料和查詢

這樣說不知道您能聽的懂嗎
不好意思



引述: "梁楓"
安不安全,你現在講的太模糊...
不要太相信 iptables... 現在的世界裡,是根本沒有防火牆的
在現在的網路環境裡,百分之八十的攻擊來自於你不能設防的服務
比如web,email甚至dns

防火牆只是一隻看門狗,一但放行,就不能在給於限制

所以安不安全是要看你整體的架構的
如果你有心的話,就把你現在的架構劃出來給大家看看?

coffeefish

  • 鑽研的研究生
  • *****
  • 文章數: 572
    • 檢視個人資料
1﹑Web Server存取後端DB是否為必要?如果必要那就沒有選擇餘地非做不可。
2﹑Web Server取後端DB的方法很多,您可以請教一下DB廠商,我想這樣就可以解決。
3 ﹑您是MIS人員,不管怎樣出了事您都必須要負起責任。
4﹑您可以請教專業的資安廠商,選擇符合貴公司的需求。至於股東能否接受,端賴於您的溝通能力。畢竟MIS人員除了技術部分,還有一大部分是『溝通協調』。加油!

Birdman

  • 榮譽博士
  • 懷疑的國中生
  • **
  • 文章數: 40
    • 檢視個人資料
若真的有web程式需要跟後端DB撈資料的需求
在資源允許下,也可以讓後端DB主動餵資料(抄寫)部分網頁需要的資料
給DMZ的DB,當然這台DMZ的DB只給web程式使用
至少,當這台DMZ的DB資料不慎被改變時,會被後端餵上來的資料覆蓋
不過,這要考慮到網頁資料的抄寫的時間差,是否符合 貴公司要求的即時性
當然,web上的程式安全性一定要好好的注意,DB欄位也可以加入一些檢查等等

還有上述其他大大的建議,firewall的rule、架構上的問題,種種的小細節都要注意,防火牆也只是您case裡的一項工具,您可要好好的計畫,我們看過很多很嚴密的防護措施,但是DB的sa或root沒設密碼.........@@"..

風險沒有等於零,只有高或低,誰都沒有把握說出沒有風險的話,若有.....
那就代表全部是風險(因為完全沒有概念及基本認知),當然,我們要盡量降低風險,但花時間去證明,去拍胸口保證不會被入侵,還不如反過來思考,當這些防線被突破,可以用什麼樣的機制來因應,來回復運作,搞不好還更實際一點

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
我不算是專家了
只是稍微懂一點

公司是大家的,股東當然會有意見
盡量讓大家滿意
比較不會有爭執啦


引述: "netman"
呵... 你是專家啊... 怎會聽股東說的才能決定安全否?

全世界沒人何人可跟別人做安全保證! 杜雷斯也不敢!  ^_^
就算你再弄更多的方案, 他還是可問你同樣的問題啊...
但出問題, 你當然要負責, 但得找出原因才能釐清歸屬.
至於原因如何解釋, 我相信你自己會想法子的了...

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
1.當然必要
不然我就把DB server放在內部網路就好了
也就不會那麼多擔心了
2. 這好像跟沒說差不多!!!
引述: "coffeefish"
1﹑Web Server存取後端DB是否為必要?如果必要那就沒有選擇餘地非做不可。
2﹑Web Server取後端DB的方法很多,您可以請教一下DB廠商,我想這樣就可以解決。
3 ﹑您是MIS人員,不管怎樣出了事您都必須要負起責任。
4﹑您可以請教專業的資安廠商,選擇符合貴公司的需求。至於股東能否接受,端賴於您的溝通能力。畢竟MIS人員除了技術部分,還有一大部分是『溝通協調』。加油!

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
您講的非常正確
不過有這麼扯的嗎??
DB 沒有設密碼?
引述: "Birdman"
若真的有web程式需要跟後端DB撈資料的需求
在資源允許下,也可以讓後端DB主動餵資料(抄寫)部分網頁需要的資料
給DMZ的DB,當然這台DMZ的DB只給web程式使用
至少,當這台DMZ的DB資料不慎被改變時,會被後端餵上來的資料覆蓋
不過,這要考慮到網頁資料的抄寫的時間差,是否符合 貴公司要求的即時性
當然,web上的程式安全性一定要好好的注意,DB欄位也可以加入一些檢查等等

還有上述其他大大的建議,firewall的rule、架構上的問題,種種的小細節都要注意,防火牆也只是您case裡的一項工具,您可要好好的計畫,我們看過很多很嚴密的防護措施,但是DB的sa或root沒設密碼.........@@"..

風險沒有等於零,只有高或低,誰都沒有把握說出沒有風險的話,若有.....
那就代表全部是風險(因為完全沒有概念及基本認知),當然,我們要盡量降低風險,但花時間去證明,去拍胸口保證不會被入侵,還不如反過來思考,當這些防線被突破,可以用什麼樣的機制來因應,來回復運作,搞不好還更實際一點

thucop

  • 憂鬱的高中生
  • ***
  • 文章數: 148
    • 檢視個人資料
請問一下,DB 設密碼有用處嗎?
設了密碼能夠防止人家撈資料嗎?
假設你透過程式存取,你要不要把密碼寫在程式裡呢?
如果要寫,那密碼不就被人家看到了嗎?

好,寫在程式裡的密碼可以加密,
但是既然程式可以連,它一定也要解密,
我就可以改程式,把解密的結果印出來!

當然,設密碼對一個資料庫來說是很重要的,
重要的是不是設密碼,而是這一組可以通行的密碼設了之後,
你要如何去設一些規則,讓它只能做它能做的事,
這是最重要的!

一點點想法!

引述: "argus"
您講的非常正確
不過有這麼扯的嗎??
DB 沒有設密碼?
~ 學無止境 ~~

dark

  • 俺是博士!
  • *****
  • 文章數: 1581
    • 檢視個人資料
1. 了解公司的環境需求 , 了解公司的配備 , 怎樣的配備需求 , 小弟可達什麼程度的防範
2. 如此配備的防護 , 對方可打進來 , 小弟只知道對方魔高一丈 , 請公司提供資源並購買更強的產品 , 小弟也肯學
3. 在資料被偷取前 , 先考慮備份是否完善 , 免得公司資料人家有 , 公司沒有


若這資料這麼多人想要 , 則別考慮方便性 , 別說連上網 , 還需訂個 "靠近此電腦條例"

Birdman

  • 榮譽博士
  • 懷疑的國中生
  • **
  • 文章數: 40
    • 檢視個人資料
回覆一下主題發起人

真的很扯的事,是多的離譜,範圍也很廣喔,就看看您有沒有機會遇到,不過這不是主題
我相信您提到的DB真的很重要,您也有很強的責任感要完成股東們的期望
但期望值跟實際值多少都會有點差距,我們來做幾點比喻及假設

狀況
1.您有能力獨立完成這個任務,並做到滴水不漏
2.您透過各方資訊及人脈支援尋找到了解決方法
3.你發現無法可施,突然有個廠商跳出來說,花300萬可以達到目的,因為這個受保護的資料很有價值,所以股東們願意花錢
4.你發現無法可施,突然有個廠商跳出來說,花300萬可以達到目的,因為這個受保護的資料很有價值,但股東只願意花頂多30萬解決
5.您多次評估後,發現,這根本不可能達到這樣滴水不漏的要求
.....

結果
1.您應該不會在這裡上線問問題
2.您也許過了一段時間後解決了問題
3.恭喜您,雖然要花錢,但總是解決了
4.這可頭大了,可能要反過來評估30萬能做到的最佳程度是如何
5.這非常有可能,資訊安全不是只建立在機制或設備上,還有絕大部分在於管理面,及觀念的衍生,我前篇提到的密碼問題,就是這個意思

有沒有比iptables好的東西,當然有,但也有人把好東西做爛了,也有人把iptables發揮到極致

這些狀況及結果再繼續唬爛下去,還很多可以扯,在這裡的人都是專家,也都不是專家,就看從什麼角度跟標準來衡量,這裡的人都在貢獻智慧,我不是很懂,只是剛好有些應用經驗給您參考,也許對您來說,可能跟沒說差不多,但多少注重版面上的禮貌會比較好,這些前輩並沒有義務一定要回答您的所有問題

coffeefish

  • 鑽研的研究生
  • *****
  • 文章數: 572
    • 檢視個人資料
引述: "argus"
1.當然必要
不然我就把DB server放在內部網路就好了
也就不會那麼多擔心了
2. 這好像跟沒說差不多!!!
引述: "coffeefish"
1﹑Web Server存取後端DB是否為必要?如果必要那就沒有選擇餘地非做不可。
2﹑Web Server取後端DB的方法很多,您可以請教一下DB廠商,我想這樣就可以解決。
3 ﹑您是MIS人員,不管怎樣出了事您都必須要負起責任。
4﹑您可以請教專業的資安廠商,選擇符合貴公司的需求。至於股東能否接受,端賴於您的溝通能力。畢竟MIS人員除了技術部分,還有一大部分是『溝通協調』。加油!

不好意思!寫了一些您認為沒有作用的廢話!
我不是貴公司的資訊部門員工,所以我不清楚貴公司的系統架構以及需求,
僅能以您所提出的問題給予我的經驗(顯然不足以有可取的地方)。
但您知道以WEB SERVER讀取DB資料有哪些嗎?
我可以在DMZ裡裝一台DB SERVER作單向的replication嗎?
讓WEB SERVER不直接ACCESS後台主DB SERVER?
但是,不說清楚貴公司的DB是哪一種如何給您建議,那效能的考慮??USER的忍受程度??所有的東西似乎不是三言二語就可以解決的!
這是您作為貴公司MIS人員所必須要瞭解的地方。
最後還是要說聲『不好意思』沒能提供您所需要的資訊,我以為透過討論可以增長見聞、吸收別人的經驗。顯然.........

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
不好意思
實在是煩惱到快要抓狂了
抱歉!!!
還是在煩惱中!!!
引述: "coffeefish"
引述: "argus"
1.當然必要
不然我就把DB server放在內部網路就好了
也就不會那麼多擔心了
2. 這好像跟沒說差不多!!!
引述: "coffeefish"
1﹑Web Server存取後端DB是否為必要?如果必要那就沒有選擇餘地非做不可。
2﹑Web Server取後端DB的方法很多,您可以請教一下DB廠商,我想這樣就可以解決。
3 ﹑您是MIS人員,不管怎樣出了事您都必須要負起責任。
4﹑您可以請教專業的資安廠商,選擇符合貴公司的需求。至於股東能否接受,端賴於您的溝通能力。畢竟MIS人員除了技術部分,還有一大部分是『溝通協調』。加油!

不好意思!寫了一些您認為沒有作用的廢話!
我不是貴公司的資訊部門員工,所以我不清楚貴公司的系統架構以及需求,
僅能以您所提出的問題給予我的經驗(顯然不足以有可取的地方)。
但您知道以WEB SERVER讀取DB資料有哪些嗎?
我可以在DMZ裡裝一台DB SERVER作單向的replication嗎?
讓WEB SERVER不直接ACCESS後台主DB SERVER?
但是,不說清楚貴公司的DB是哪一種如何給您建議,那效能的考慮??USER的忍受程度??所有的東西似乎不是三言二語就可以解決的!
這是您作為貴公司MIS人員所必須要瞭解的地方。
最後還是要說聲『不好意思』沒能提供您所需要的資訊,我以為透過討論可以增長見聞、吸收別人的經驗。顯然.........

shenfive

  • 活潑的大學生
  • ***
  • 文章數: 225
  • 性別: 男
    • 檢視個人資料
    • http://shenfive.pixnet.net/blog
Dear Argus:

看來您還在煩腦中, 不過小弟看您的問題不在技術問題, 而在責任負擔上

資訊安全沒有絶對, 就好像交通安全一樣, 沒人能保證不會出車禍.

你可以騎車不載安全帽, 也可以開裝甲車上路, 但即使開了裝甲車, 也不能百分之百保證你的安全, 因為天上可能有飛機掉下來.

依小弟之見, 您要做的是提出數種安全解決方案, 分析出風險程度與花費後, 由股東們自行選擇, 不然  "你可以保證出了事你負責嗎 " 這句話跟本是沒解的.

資料放在硬碟安全嗎? 不安全, 所以有磁碟陣列, 有了磁碟陣列安全嗎?
無法保證, 所以需要備份, 有了備份安全嗎, 無法保證, 所以有了異地備
援, 有了異地備援安全嗎? 無法保證, 所以第二異地備援, 安全了嗎? 無法保證, 所以初二, 十六要拜拜, 有拜有保祐嗎? 那也還是只有天知道.

wisely

  • 可愛的小學生
  • *
  • 文章數: 2
    • 檢視個人資料
原有設計在個人感覺上的確不"夠"安全, 當然這要看你們的需求而定, 一點建議, 請參考.

先決條件:
1.Web Server/Service必須提供
2.DB data不能洩漏, 不能被竄改, 不能資料遺失 (CIA)
3.Web Service必須能存取DB

幾項建議:
1.DB不要放在內部網路, 可以的話, 獨立一個網段, 也就是設個DMZ2, 與Web Server, Intranet都區隔開, Intranet實在不安全, 要知道有多不安全, 可以問Birdman...XD
2.DB本身規劃不清楚, 不知道所有Data都在一個DB內還是分別有多個不同的資料庫. 建議針對DB Users分別設定權限, 採"least priviledge"方式, 只能讀取就不要有寫入權限, 不該讀取就不要給讀取權限, 不應該存在的使用者就不應該存在, 然後每個使用者採取強密碼保護.
3.DB system administrator的密碼記得不要用default password.
4.DB定期備份, 同時針對對安全的需求程度考量異地備份, 異地備援, 並設計回復計劃定期測試回復流程.
5.Web Service進行code review或penetration test, 確認網站程式設計有無漏洞, 例如SQL Injection, Cross-Site scripting這些常見的問題.
6.Web Server本身系統安全性, 作業系統安全性一樣要注意, 這方面不詳述. web server本身啟動iptables跟啟動tcpwrapper也差不多, 使用了並不能因此增加多少安全性.
7.Web Service如果要跟使用者傳輸比較"敏感"或機密的資料, 建議使用SSL tunnel保護.
8.如果還是有太多疑問不清楚, 建議可以尋求外部專家協助, 有興趣可以跟我聯繫...:P

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
1.您說的DMZ2 是說假如內部網路是192.168.1.x  ,然後設個192.168.2.xxxx是這樣?
2.這個我門有規劃了,只有一個人可以寫入
3.這個有想到
4.這個也有考慮到
5.這個聽不太懂,可以解釋一下嗎
6.您是說例如apache有漏洞這樣???
7.這倒不會,主要還是內部的DB有重要,但是DB外面的人不能查
8.請留下MSN............
引述: "wisely"
原有設計在個人感覺上的確不"夠"安全, 當然這要看你們的需求而定, 一點建議, 請參考.



先決條件:
1.Web Server/Service必須提供
2.DB data不能洩漏, 不能被竄改, 不能資料遺失 (CIA)
3.Web Service必須能存取DB

幾項建議:
1.DB不要放在內部網路, 可以的話, 獨立一個網段, 也就是設個DMZ2, 與Web Server, Intranet都區隔開, Intranet實在不安全, 要知道有多不安全, 可以問Birdman...XD
2.DB本身規劃不清楚, 不知道所有Data都在一個DB內還是分別有多個不同的資料庫. 建議針對DB Users分別設定權限, 採"least priviledge"方式, 只能讀取就不要有寫入權限, 不該讀取就不要給讀取權限, 不應該存在的使用者就不應該存在, 然後每個使用者採取強密碼保護.
3.DB system administrator的密碼記得不要用default password.
4.DB定期備份, 同時針對對安全的需求程度考量異地備份, 異地備援, 並設計回復計劃定期測試回復流程.
5.Web Service進行code review或penetration test, 確認網站程式設計有無漏洞, 例如SQL Injection, Cross-Site scripting這些常見的問題.
6.Web Server本身系統安全性, 作業系統安全性一樣要注意, 這方面不詳述. web server本身啟動iptables跟啟動tcpwrapper也差不多, 使用了並不能因此增加多少安全性.
7.Web Service如果要跟使用者傳輸比較"敏感"或機密的資料, 建議使用SSL tunnel保護.
8.如果還是有太多疑問不清楚, 建議可以尋求外部專家協助, 有興趣可以跟我聯繫...:P

wisely

  • 可愛的小學生
  • *
  • 文章數: 2
    • 檢視個人資料
1.差不多, 更精確的說法是假如Intranet是192.168.1.0/24, 那DMZ2可以設為192.168.2.0/24, 而且與防火牆連結Intranet使用的network interface不一樣.
5.許多DB Security問題來自於前端介面, 以此例來說就是Web Service. 因為DB保護的再好, 如果前端程式設計有疏失, 也是沒有意義的, 因為在DB的角度看來, 同樣都是合法的帳號及密碼登入存取資料. 這部分涉及Web AP Development, 如果你不具備網頁程式開發經驗(例如ASP/PHP/JSP/CGI), 不清楚這部分是很正常的, 可以找你們單位負責這部分的同仁討論一下.
6.沒錯, Apache/Tomcat等AP的安全性要注意, 還有像是作業系統(Linux)安全性, 密碼強固性等等, 都必須兼顧, 作業系統不安全, 也是很難繼續維護DB安全性的(連sa password都能改了...).
8.ccc...有案子要做嗎??:P

引述: "argus"
1.您說的DMZ2 是說假如內部網路是192.168.1.x  ,然後設個192.168.2.xxxx是這樣?
2.這個我門有規劃了,只有一個人可以寫入
3.這個有想到
4.這個也有考慮到
5.這個聽不太懂,可以解釋一下嗎
6.您是說例如apache有漏洞這樣???
7.這倒不會,主要還是內部的DB有重要,但是DB外面的人不能查
8.請留下MSN............
引述: "wisely"
原有設計在個人感覺上的確不"夠"安全, 當然這要看你們的需求而定, 一點建議, 請參考.



先決條件:
1.Web Server/Service必須提供
2.DB data不能洩漏, 不能被竄改, 不能資料遺失 (CIA)
3.Web Service必須能存取DB

幾項建議:
1.DB不要放在內部網路, 可以的話, 獨立一個網段, 也就是設個DMZ2, 與Web Server, Intranet都區隔開, Intranet實在不安全, 要知道有多不安全, 可以問Birdman...XD
2.DB本身規劃不清楚, 不知道所有Data都在一個DB內還是分別有多個不同的資料庫. 建議針對DB Users分別設定權限, 採"least priviledge"方式, 只能讀取就不要有寫入權限, 不該讀取就不要給讀取權限, 不應該存在的使用者就不應該存在, 然後每個使用者採取強密碼保護.
3.DB system administrator的密碼記得不要用default password.
4.DB定期備份, 同時針對對安全的需求程度考量異地備份, 異地備援, 並設計回復計劃定期測試回復流程.
5.Web Service進行code review或penetration test, 確認網站程式設計有無漏洞, 例如SQL Injection, Cross-Site scripting這些常見的問題.
6.Web Server本身系統安全性, 作業系統安全性一樣要注意, 這方面不詳述. web server本身啟動iptables跟啟動tcpwrapper也差不多, 使用了並不能因此增加多少安全性.
7.Web Service如果要跟使用者傳輸比較"敏感"或機密的資料, 建議使用SSL tunnel保護.
8.如果還是有太多疑問不清楚, 建議可以尋求外部專家協助, 有興趣可以跟我聯繫...:P
:P  :P  :P  :P  :P

argus

  • 可愛的小學生
  • *
  • 文章數: 28
    • 檢視個人資料
最後我實在受不了了
預備把這部分外包
您有興趣嗎
請留下MSN

所有有興趣的人也可以跟我連絡
我的MSN
service@24cc.cc

引述: "wisely"
1.差不多, 更精確的說法是假如Intranet是192.168.1.0/24, 那DMZ2可以設為192.168.2.0/24, 而且與防火牆連結Intranet使用的network interface不一樣.
5.許多DB Security問題來自於前端介面, 以此例來說就是Web Service. 因為DB保護的再好, 如果前端程式設計有疏失, 也是沒有意義的, 因為在DB的角度看來, 同樣都是合法的帳號及密碼登入存取資料. 這部分涉及Web AP Development, 如果你不具備網頁程式開發經驗(例如ASP/PHP/JSP/CGI), 不清楚這部分是很正常的, 可以找你們單位負責這部分的同仁討論一下.
6.沒錯, Apache/Tomcat等AP的安全性要注意, 還有像是作業系統(Linux)安全性, 密碼強固性等等, 都必須兼顧, 作業系統不安全, 也是很難繼續維護DB安全性的(連sa password都能改了...).
8.ccc...有案子要做嗎??:P

引述: "argus"
1.您說的DMZ2 是說假如內部網路是192.168.1.x  ,然後設個192.168.2.xxxx是這樣?
2.這個我門有規劃了,只有一個人可以寫入
3.這個有想到
4.這個也有考慮到
5.這個聽不太懂,可以解釋一下嗎
6.您是說例如apache有漏洞這樣???
7.這倒不會,主要還是內部的DB有重要,但是DB外面的人不能查
8.請留下MSN............
引述: "wisely"
原有設計在個人感覺上的確不"夠"安全, 當然這要看你們的需求而定, 一點建議, 請參考.



先決條件:
1.Web Server/Service必須提供
2.DB data不能洩漏, 不能被竄改, 不能資料遺失 (CIA)
3.Web Service必須能存取DB

幾項建議:
1.DB不要放在內部網路, 可以的話, 獨立一個網段, 也就是設個DMZ2, 與Web Server, Intranet都區隔開, Intranet實在不安全, 要知道有多不安全, 可以問Birdman...XD
2.DB本身規劃不清楚, 不知道所有Data都在一個DB內還是分別有多個不同的資料庫. 建議針對DB Users分別設定權限, 採"least priviledge"方式, 只能讀取就不要有寫入權限, 不該讀取就不要給讀取權限, 不應該存在的使用者就不應該存在, 然後每個使用者採取強密碼保護.
3.DB system administrator的密碼記得不要用default password.
4.DB定期備份, 同時針對對安全的需求程度考量異地備份, 異地備援, 並設計回復計劃定期測試回復流程.
5.Web Service進行code review或penetration test, 確認網站程式設計有無漏洞, 例如SQL Injection, Cross-Site scripting這些常見的問題.
6.Web Server本身系統安全性, 作業系統安全性一樣要注意, 這方面不詳述. web server本身啟動iptables跟啟動tcpwrapper也差不多, 使用了並不能因此增加多少安全性.
7.Web Service如果要跟使用者傳輸比較"敏感"或機密的資料, 建議使用SSL tunnel保護.
8.如果還是有太多疑問不清楚, 建議可以尋求外部專家協助, 有興趣可以跟我聯繫...:P
:P  :P  :P  :P  :P