安全機制

Home / Posts tagged "安全機制"
安全機制的階段考量

安全機制的階段考量

一般在擬訂網站安全機制時,受媒體及管理習性的影響,很容易把焦點集中在防範駭客內部監控這兩個訴求點上,而防範駭客往往必須付出較高的有形成本,內部監控則是交換了難以估算的無形成本。但規劃者卻反而容易從而謀取到較高的利益,也較能順應管理者基於技術盲點所產生的心理安全需求。

安全政策初期大致上可以由硬體設備資料庫技術這三項資源的防護措施作為訴求,從預防設備或資料的毀損資訊外流兩個方向考量。

依照可能發生機率提列如下:

(一) 設備或資料毀損的原因: (二) 資訊外流的管道:
1. 人為疏失 1. 蜘蛛程式
2. 病毒 2. 駭客
3. 硬體故障或損耗 3. 內部成員
4. 駭客 4. 其他
5. 內部成員
6. 其他

先從資訊外流的管道來看:
保護觀點基於道德義務要遠甚於資料本身的機密實質,如下

1. 資料對網站的意義?
(1) 會員的行為習慣。
(2) 會員透過網站平台彼此間的互動。
(3) 從資料或互動中能夠整理或分析出的訊息。
(4) 網站對於群組分類等相關定義及經營管理機制。

2. 考量的重點?
(1) 會員個資保護是否完善 ?
(2) 資料包含的市場數據或訊息 ?
(3) 資料或結構中的重要的技術Know-How ?
(4) 資料隱含網站的缺陷或弱點 ?
(5) 資料隱含的管理流程或營運方向 ?

回頭看設備或資料毀損的原因:
八成以上的資料毀損在於人為作業疏失所導致。無關乎技術好壞,隨著資料庫結構及作業流程的日益複雜,DBA或系統管理人員犯錯的機會也相對不斷攀升.. 想要日子過得安穩,再昂貴的設備或保險都難以彌補資料永久消失所造成的傷害,而真正需要的其實只是資料的備份儲存的機制而已..

如果設備或資料發生狀況, 首先要考慮的就是資料救不救得回來, 網站的備份機制從問題發生到發現的最大期限空窗損失(方案1.1)?多少預算成本才能夠將風險降低到可以容忍範圍?以小站而言, 去考慮當機停機對網站使用者所造成的負面影響的成本相對是高的..

沒有絕對安全的機制也沒有永遠適用的政策:
面對企業的成長及網路環境的變遷,因應不同階段及不同性質需求,政策不可能一成不變。一個錯誤的考量,選錯時間或用錯地點,所造成的無形的內耗商機的錯失要遠比駭客或病毒讓系統當機停機兩三天的威力要強大何止千百倍..

針對一般網站初期的使用規模及性質,考量階段安全訴求及優先順序如下:
1. 資料庫及結構、系統技術文件、程式碼的永久毀損風險。
2. 建立防毒體系、維持最新的防毒軟體,確保內部或客戶、合作夥伴間的信件安全。
3. 避免、預防或降低作業疏失所造成的損害。
4. 網站系統及資料庫的穩定性。
5. 網路合法管道的安全,監控非常態瀏覽行為。
6. 系統、資料庫及結構、技術文件、程式碼的安全防護及版本管理。
7. 網站效能的提升。

PS: 防範駭客內部監控只能算是上列訴求的其中因應措施而已,不要一開始就當成主要訴求點, 更不會是設立的目標。

可行的各項方案:
針對上列訴求,以下方案評估其功能目標、成本效益、重要性及階段性依優先順序提列:

1. 資料庫的備份機制(訴求點1、3、6):
規範三種不同週期各別製作備份:
(1) 資料庫及程式碼,每日備份保留一個月。
優缺點:資料發生問題最小損失1天,發現問題的最大期限1個月

圖例:
8月            9月   10月     

—I—x———I—x———I—————I——
    8/7     9/6

假設資料庫於8月7日發生毀損,則最後有效備份為8月6日,該備份將於9月6日遭毀損資料覆蓋,因此如未能在9月6日前發現問題,之前的資料將永遠消失..

(2) 每週備份保留一個月(每月第1份保留一年)。
優缺點:最小損失1週,最大期限1年。

(3) 每月備份保留一年(每年第1份永久儲存)。
優缺點:最小損失1個月,沒有最大期限(仍需定期更新儲存媒體)。

PS:圖檔及系統組態建議列為每月或每週備份範圍。

重點在於如何以最少成本降低最小損失同時延長最大期限。 整合上列備存優缺點則:資料最小損失1天,沒有最大期限。

2. 防毒體系(訴求點2、6):
1. 不時都有新的或變種病毒產生,不即時更新的防毒軟體形同虛設,專人統合管理並隨時更新,才能確保整體安全。
2. 建置或購買Email管理系統,避免將客戶或合作夥伴Email存進個人郵件軟體,防止病毒透過電子郵件或通訊錄對外散播,損害網站專業形象

3. 系統使用者等級(訴求點3、6):
ps. 等級細分基於技術經驗及權責劃分,避免作業疏失,主要是機制不是人品及信任度。

4. DBA機制(訴求點3、4、6、7):
1. 專人負責結構建置、資料維護、效能監督設定、安全管控及備份儲存。
2. 資料或結構變更應文件作業並整合評估,知會相關程式或資料處理人員擬定整體作業程序。
3. 重大異動之前可先作(月)備份(記錄事由),之後隨即作(週)備份。
4. 資料關聯及互動以資料庫機制完成,避免由程式個別處理,減少錯誤發生機率,同時提升程式效能,降低程式開發、維護、文件製作及訓練成本。
5. 落實技術文件及操作手冊,降低系統維護門檻及訓練成本。
6. 妥善分工,避免關鍵事項、資源或管道過度集中,減少作業瓶頸、部門屏障並降低人事異動風險。

PS:安全監控愈嚴密,第6點的顧慮往往就愈趨明顯。只求不犯錯的企業自然要損失競爭力,考慮監控或督導之前也該考量其它因素

5. 目錄使用權限(訴求點3、6):

6. 資料查詢權限(訴求點5、6):
1. 區分資料庫工具使用權限。
2. 區分查詢權限及可查詢範圍。
3. 系統必須自動查覺、記錄並限制非常態瀏覽行為,並對監控人員提出警告,必要時拒絕往來。

7. 資料編輯權限(訴求點3、6):
1. 區分資料庫工具使用權限。
2. 管理系統界面均必須透過公司內部IP及密碼認證方能使用。
3. 界面僅當日有效,每日須登錄帳號密碼,無法直接利用瀏覽器頁籤功能執行。
4. 區分資料編輯權限。

8. 改善硬體環境建置(訴求點4、6、7):

邱天仙
2001.8.12