Villamood 心境網誌

　　一般在擬訂系統安全機制時，受媒體及管理習性的影響，很容易讓人就把焦點集中在防範駭客及內部監控這兩個訴求點上面，所付出的有形或無形成本也最高，偏偏從這樣的考量點上顧問公司卻最容易謀取到最高的利潤，也較能順應管理者基於技術盲點所產生的心理安全需求。
其實安全政策的制定大致上可以由建立軟硬體設備、資料庫、系統技術這三項資源的防護措施作為整體機制的訴求，在安全上區別重要性及機密性則可以從預防設備或資料的毀損及資訊外流兩個方向考量。依照可能發生機率提列如下：

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

先從資訊外流的管道來看：
保護觀點基於道德義務要遠甚於資料本身的機密實質，因為對會員資料或Email蒐集而言，不代表沒有其他管道甚或成本更低的資料蒐集方案。關鍵是..

1. 資料對網站的意義？
(1) 資料內的會員對網站是否存在互信或互動。
(2) 會員彼此間是否透過網站存在互信或互動。
(3) 從資料或互動中能夠整理或分析出甚麼樣的訊息？
(4) 對於資料的群組分類等相關定義及經營管理機制。

2. 考量的重點在哪裡？
(1) 流出的資料是否隱含或透漏出任何市場數據或訊息？
(2) 從資料或結構中是否能夠解析出重要的技術Know-How？
(3) 是否暴露網站的優勢或缺陷或弱點？
(4) 是否透露網站的近程階段重點或管理流程或營運方向？
(5) 以上四點是否不須經由系統或資料庫可以更容易取得？

回頭看設備或資料毀損的原因：
有八成以上的資料毀損都是由於人為的作業疏失導致。無關乎技術的好壞，隨著資料庫結構及作業流程的日益複雜，DBA或系統管理人員犯錯的機會也相對不斷攀升.. 日子要過得安穩？買保險或是買再昂貴的設備及系統都無法防止或彌補資料永久消失所造成的傷害，而真正需要的卻僅僅只是資料的備份、儲存而已..
如果設備或資料發生問題，首先真正要擔心的應該是資料救不救得回來？網站的備份機制從問題發生到發現的最大期限及空窗損失(方案1.例1)？多少預算成本才能夠將風險降低到可以容忍範圍？然後才考慮當機或停機對網站使用者所造成的負面影響..

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

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

PS： 防範駭客及內部監控只能算是上列訴求的其中因應措施而已，初期並不合適成為主要訴求點， 更不可能當作是目標的達成。

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

1. 資料庫備份機制(訴求點1、3、6)：
規範三種不同週期各別製作備份：
例1. 資料庫及程式碼，每日備份保留一個月。
優缺點：資料發生問題最小損失1天，發現問題的最大期限1個月，否則損失所有相關資料。
圖例：　1/8　　　　1/9　　　　1/10　　　　1/11
—I—x———I—x———I—————I——
　　　　　　7/8　　　　6/9
假設資料庫於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. 設立DBA專人負責結構建置、資料維護、效能監督設定、安全管控及備份儲存。
2. 資料庫任何結構建置或資料維護均須透過DBA整合評估，知會相關程式或資料處理人員擬定整體作業程序，之後並應隨即相關系統文件作業。
3. 重大異動之前必須先作(月)備份(記錄事由)，之後並應隨即作(週)備份。
4. 重大資料關聯及資料互動統籌由DBA以資料庫機制完成，不須要經由程式設計人員為個別界面再作個別設計，減少錯誤發生機會以確保資料系統完整，同時提升程式效能，並降低程式開發、維護、文件製作及新人訓練等相關成本。
5. 建立系統作業、維護、設定等相關程序技術文件或操作手冊，降低系統 維護門檻及人員訓練成本；培養儲備DBA及系統人員，分攤相關事務，避免關鍵事項、資源或管道過度集中，減少作業瓶頸、部門屏障並降低 人事異動風險。

PS： 其實第5項目的考量往往是與其它項目相衝突的，一個安全監控愈嚴密的體系，在這方面的顧慮往往就愈趨明顯..以較傳統的思維來看，人品有疑慮的人員就不應該擺在企業關鍵點上，但就未來而言卻是非常不夠。套用中國微軟的管理理念『人品是企業人才的第一優先考量』..癌細胞就是比正常細胞容易生存，破壞遠比建設容易，組織體系不能只靠權謀制衡過日子，真正需要的是一個能夠協調合作創新的有機體，一個只是不犯錯的企業是沒有能力存活的.. 因此，不能信任就不該任用，考慮監控或督導之前應該先考量其它更重要因素。

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

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

PS：經由分類瀏覽資料時，無法對查詢結果加以限制，可延長下載時間、增加下載成本。

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

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

邱天仙
2001.8.12