1、基礎(chǔ)架構(gòu)配置與變更管理規(guī)定第一節(jié) 總則第一條 為合理配置系統(tǒng)參數(shù)， 實施硬件資源的有序調(diào)配， 保證硬件設(shè)施與 系統(tǒng)軟件配置能在最大程度上滿足信息系統(tǒng)運行與安全需要， 特制 定本規(guī)定。第二條本規(guī)定所指基礎(chǔ)架構(gòu)，請參見 IT 基礎(chǔ)架構(gòu)規(guī)中的定義。第三條本規(guī)定所涉及配置與變更管理圍包括： 硬件設(shè)施與平臺軟件的配置與變更、基礎(chǔ)架構(gòu)布局的配置與變更。第四條規(guī)定中所指配置管理單位：省公司信息技術(shù)處。第五條本規(guī)定中所指配置管理員包括系統(tǒng)管理員、 數(shù)據(jù)庫管理員、 網(wǎng)絡(luò)管理員、安全管理員等。第二節(jié) 平臺軟件的基準配置第六條 平臺軟件的基準配置包括操作系統(tǒng)軟件、 數(shù)據(jù)庫軟件、 網(wǎng)絡(luò)設(shè)備系 統(tǒng)軟件、 安全設(shè)備系統(tǒng)軟

2、件的基準配置等。 維護單位應(yīng)為平臺軟件 建立合適的配置基準。 配置基準應(yīng)確保系統(tǒng)安全與整體安全要求的 一致性。第七條 經(jīng)授權(quán)的配置管理員應(yīng)根據(jù)系統(tǒng)安裝手冊與配置基準對初裝系統(tǒng) 或設(shè)備進行基準配置， 詳細記錄安裝過程與設(shè)置， 確保配置的正確 性。配置管理員應(yīng)建立該配置對象的配置清單并在配置清單中 清楚體現(xiàn)基準配置。第八條 完成基準配置的系統(tǒng)或設(shè)備需進行運行測試和安全性檢查。 運行測 試與安全檢查通過后， 配置管理員需在配置記錄上寫明運行測試與 安全檢查結(jié)果， 由配置監(jiān)管人簽字確認。 只有在測試與安全檢查沒 有問題的情況下該系統(tǒng)或設(shè)備才能在生產(chǎn)環(huán)境下運行。第三節(jié) 平臺軟件的配置變更第九條 平臺軟件

3、的配置變更包括但不限于：操作系統(tǒng)軟件、數(shù)據(jù)庫軟件、 網(wǎng)絡(luò)設(shè)備系統(tǒng)軟件、 安全設(shè)備系統(tǒng)軟件、 系統(tǒng)安全策略的配置變更； 供應(yīng)商發(fā)布的補丁、升級包的使用等。第十條 配置管理員負責對平臺軟件進行配置管理和維護， 配置監(jiān)管人負責 平臺軟件配置正確性的確認。 可通過操作系統(tǒng)層面對系統(tǒng)配置文件 的訪問權(quán)限的設(shè)置、 明確的職責分工來確保配置和變更只能由被授 權(quán)的人進行操作。第十一條 配置變更應(yīng)有統(tǒng)一的配置變更申請、審批流程。 配置變更申請、 審批表中應(yīng)寫明該配置變更所屬設(shè)備的名稱、配置的類別（操作 系統(tǒng)、數(shù)據(jù)庫、路由策略、安全策略、補丁包 / 升級包的使用等） 和配置變更的原因及容。 若配置變更源于第三方服

4、務(wù)商的建議則應(yīng) 同時提交第三方服務(wù)商建議文檔。第十二條 配置管理員應(yīng)根據(jù)變更申請制定配置變更計劃， 變更計劃中應(yīng)詳細 說明該配置變更可能對系統(tǒng)本身以及其他系統(tǒng)產(chǎn)生的影響、 配置變 更發(fā)生的時間、地點等。第十三條 配置單位管理層應(yīng)根據(jù)配置變更計劃及該配置變更所能產(chǎn)生的影 響進行分析評估，對包括獲取的補丁 / 升級包的安全性、準確性及 真實性的核查， 確定配置變更的原因是否充分， 決定是否需要進行 配置變更測試、 是否同意該變更。為確保生產(chǎn)系統(tǒng)的安全性， 補丁 / 升級包在安裝之前必需經(jīng)過測試。配置單位管理層應(yīng)在配置變 更申請、審批表中記錄審批結(jié)果并簽字。第十四條 經(jīng)授權(quán)的配置管理員應(yīng)根據(jù)審批后的

5、配置變更計劃進行配置變更， 若需進行配置變更測試時， 應(yīng)首先完成測試并出具測試報告。 配置 管理員在完成配置變更后應(yīng)及時填寫配置變更記錄表 ，該表要 求變更申請人對配置變更結(jié)果進行確認并簽字。 同時配置管理員應(yīng) 更新配置清單。第十五條 配置管理員還應(yīng)將配置變更申請、審批表 、配置清單、測試 報告做為配置變更記錄表的附件提交給配置監(jiān)管人，由其進行配置變更的確認，并在配置變更記錄表的“監(jiān)管人”一欄中 簽字。第四節(jié) 硬件設(shè)施的配置變更第十六條 硬件設(shè)施的基準配置參見總公司下發(fā)的 IT 基礎(chǔ)架構(gòu)規(guī)。第十七條 硬件設(shè)施配置變更包括但不限于： 主機處理器、 主機存、主機硬盤、 主機HBA卡、網(wǎng)卡、光驅(qū)、磁

6、帶機、網(wǎng)絡(luò)設(shè)備接口模塊、備份電源 等硬件設(shè)施配置變更。第十八條 硬件設(shè)施使用方在硬件資源使用過程中時發(fā)生硬件資源不足或壞 損時可申請硬件設(shè)施配置的變更， 并填寫配置變更申請、審批表。第十九條 配置管理員負責對硬件設(shè)施進行配置管理和維護， 配置監(jiān)管人負責 確認硬件設(shè)施配置的正確性。第二十條 配置變更應(yīng)有統(tǒng)一的配置變更申請、審批流程。 配置變更申請、 審批表 中應(yīng)寫明該配置變更所屬設(shè)備的名稱、配置的類別（ CPU、 存、硬盤、備份電源、HBA卡、網(wǎng)卡、光驅(qū)、磁帶機、網(wǎng)絡(luò)設(shè)備接 口模塊）和配置變更的原因及容。第二十一條 配置管理員應(yīng)根據(jù)變更申請制定配置變更計劃， 變更計劃中應(yīng)詳細 說明該配置變更可能

7、對系統(tǒng)本身以及其他系統(tǒng)產(chǎn)生的影響、 配置變 更發(fā)生的時間、地點等。第二十二條 配置單位管理層應(yīng)根據(jù)配置變更計劃及該配置變更所能產(chǎn)生的影 響進行分析評估， 確定配置變更的原因是否充分， 決定是否需要進 行配置變更測試、 是否同意該變更。配置單位管理層應(yīng)在配置變 更申請、審批表中記錄審批結(jié)果并簽字。第二十三條 經(jīng)授權(quán)的配置管理員應(yīng)根據(jù)審批后的配置變更計劃進行配置變更， 若需進行配置變更測試時， 應(yīng)首先完成測試并出具測試報告。 配置 管理員在完成配置變更后應(yīng)及時填寫配置變更記錄表 ，該表要 求變更申請人對配置變更結(jié)果進行確認并簽字。 同時配置管理員應(yīng) 更新硬件設(shè)備維護檔案中的硬件設(shè)備基本配置 （ 見

8、硬件設(shè)備 維護規(guī)定 ） 。第二十四條第二十五條第二十六條第二十七條 第二十八條第二十九條第三十條 第三十一條配置管理員還應(yīng)將配置變更申請、審批表、硬件設(shè)備維護檔案、 測試報告作為配置變更記錄表的附件提交給配置監(jiān)管人， 由其進行配置變更的確認，并在配置變更記錄表的“監(jiān)管人” 一欄中簽字。第五節(jié) 基礎(chǔ)架構(gòu)布局的變更基礎(chǔ)架構(gòu)布局的變更包括但不限于：設(shè)備增減、設(shè)備遷移、線路調(diào) 整、拓撲變化、定期停機檢修等。維護單位應(yīng)為基礎(chǔ)架構(gòu)布局建立相關(guān)文檔， 如機房布線圖、 網(wǎng)絡(luò)拓 撲圖、設(shè)備分布圖、機架分布圖、跳線表、地址表等。當基礎(chǔ)架構(gòu) 布局發(fā)生變更時此類基礎(chǔ)架構(gòu)布局文檔應(yīng)得到及時的更新。 基礎(chǔ)架構(gòu)布局變更時，

9、 變更提出方應(yīng)填寫 布局變更申請、審批表， 申請表中應(yīng)具體描述變更的原因、容、時間、 涉及到的部門等相關(guān) 容，經(jīng)需求方管理層審批后提交配置管理單位。經(jīng)授權(quán)的配置管理員應(yīng)根據(jù)審批后的布局變更計劃進行布局變更 并填寫布局變更記錄表 ，該表要求變更申請人對布局變更結(jié)果 進行確認。配置管理員應(yīng)同時更新相關(guān)的基礎(chǔ)架構(gòu)布局文檔。 配置管理員還應(yīng)將 布局變更申請、 審批表、基礎(chǔ)架構(gòu)布局文檔 一并作為布局變更記錄表的附件提交給配置監(jiān)管人，由其進行 布局變更的確認，并在布局變更記錄表的“監(jiān)管人”一欄中簽 字。第六節(jié) 變更事件的處理根據(jù)變更事件可能造成的影響， 其圍可以分為處室圍、部門圍、省 公司本部圍、 省公司

10、本部及下級地市公司圍四類。 配置管理單位應(yīng) 將可能產(chǎn)生的變更行為依據(jù)上述四種影響圍進行歸類劃分， 并每半 年對分類規(guī)則進行評估更新。根據(jù)上述分類規(guī)則， 維護單位應(yīng)詳細制定變更事件的通知細則， 其 容應(yīng)包括各種影響圍的最遲提前申請時間、 最遲提前通知時間、 變 更審批領(lǐng)導(dǎo)等，并根據(jù)變更事件影響圍的更新而重新評估通知細 則。第三十二條 經(jīng)過審批的配置變更或布局變更， 配置管理維護單位管理層應(yīng)根據(jù) 影響圍及通知細則提前發(fā)布變更通知， 以便受影響管理方能夠及時 與可能影響到的有關(guān)各方聯(lián)系確認， 并提前通知有關(guān)各方預(yù)先做好 準備。第三十三條 為減少配置變更與布局變更對正常業(yè)務(wù)和工作的影響， 變更實施應(yīng)

11、盡量安排在業(yè)務(wù)、工作的空閑時段進行。第七節(jié) 定期審閱第三十四條 技術(shù)的進步或系統(tǒng)、 設(shè)備的升級可能引起配置基準的改變。 信息技 術(shù)處應(yīng)根據(jù)設(shè)備或系統(tǒng)的升級情況決定是否更新配置基準。 維護單 位應(yīng)定期對各類配置對象的配置基準進行評估 （ 每年一次 ） ，形成 配置基準評估表并提交管理層審閱。第三十五條 若需發(fā)生配置基準的變更行為則應(yīng)按照配置變更申請、 審批流程執(zhí) 行。配置管理員在填寫配置變更申請時， 應(yīng)詳細說明該配置變更屬 配置基準的變更。配置基準的變更必需經(jīng)過測試成功后方可實施。第三十六條 為了防止配置管理人員有意或無意的對軟、 硬件的配置、 基礎(chǔ)架構(gòu) 布局的非法更改， 應(yīng)建立對配置清單、基礎(chǔ)

12、架構(gòu)布局文檔、配置變 更記錄、 布局變更記錄的年審機制， 該年審工作應(yīng)由配置監(jiān)管人員 執(zhí)行。配置監(jiān)管人應(yīng)根據(jù)相關(guān)文檔對真實情況進行檢查， 確保實際 情況與相關(guān)文檔的記錄一致。第三十七條 配置監(jiān)管人員進行年審工作后應(yīng)填寫基礎(chǔ)架構(gòu)變更年審表 ，該 年審表應(yīng)說明相關(guān)文檔與實際情況是否相符。 若實際情況與相關(guān)文 檔不一致則應(yīng)說明發(fā)生的原因與處理結(jié)果。第八節(jié) 文檔保存第三十八條 在基礎(chǔ)架構(gòu)配置與變更管理過程中產(chǎn)生的所有文檔， 包括配置基 準、配置清單、基礎(chǔ)架構(gòu)布局相關(guān)文檔 、配置變更申請、審 批表、布局變更申請、審批表 、配置變更記錄表 、布局變更記錄表、基礎(chǔ)架構(gòu)變更年審表 、配置基準評估表等均應(yīng)該由

13、配置管理單位指定專人進行統(tǒng)一管理，保留工作痕跡。第九節(jié) 附則第三十九條 本制度由省公司信息技術(shù)處負責解釋和修訂。第四十條 本制度自發(fā)布之日起開始執(zhí)行。附件一配置變更申請、審批流程變更管理流程變更管理員需求申請人監(jiān)管人變更記錄表否否*需求方申請 人簽字確認在變更記錄中簽字確認是是配置變更 申請、審 批流程否部門處室設(shè)備名稱設(shè)備編號有效期至變更需求欄*申請方填葺寫*變更類型平臺軟件數(shù)據(jù)庫操作系統(tǒng)路由策略安全策略補丁 /升級其它硬件設(shè)施CPU存硬盤備份電源HBA卡網(wǎng)卡光驅(qū)磁帶機網(wǎng)絡(luò)設(shè)備接口模塊其它變更原因：變更容：申請單位審批人：結(jié)論：審批時間：變更分析欄*變更方填與*配置計劃：管理員：時間：影響圍

14、：管理員：時間：變更實施時間：通知發(fā)布時間：通知發(fā)布對象：配置單位審批人：結(jié)論：審批時間：部門處室截止日期變更需求欄*申請方填寫*變更類別：設(shè)備增減設(shè)備遷移線路調(diào)整拓撲變化停電檢修其它變更原因：變更容：申請單位審批人：結(jié)論：時間：變更分析欄*變更方:填寫*布局變更計劃：管理員：時間：影響圍：管理員：時間：變更實施時間：通知發(fā)布時間：通知發(fā)布對象：變更單位審批人：結(jié)論：時間：附件五配置變更記錄表編號.設(shè)備編號.變更時間：管理員：變更類型數(shù)據(jù)庫操作系統(tǒng)路由策略安全策略補丁 /升級硬件資源其它變更結(jié)論結(jié)論：申請人：時間：配置變更審閱變更審批審批表的（或附件）測試情況若存在測試，提供測試報告的（或附件

15、），否則無。變更后文檔配置清單或設(shè)備維護檔案的（或附件）審核結(jié)論：監(jiān)管人：審核時間：附件六布局變更記錄表編號.結(jié)構(gòu)文檔號：變更時間：管理員：變更類型設(shè)備增減設(shè)備遷移線路調(diào)整拓撲變化停電檢修其它變更結(jié)論結(jié)論：申請人：時間：配置變更審閱變更審批審批表的（或附件）測試情況若存在測試，提供測試報告的（或附件），否則無。變更后文檔布局文檔的（或附件）審核結(jié)論：監(jiān)管人：審核時間：附件七基礎(chǔ)架構(gòu)變更年審表變更對象變更類型審閱結(jié)論審閱時間監(jiān)管人附件八 配置基準、路由器配置基準：1、關(guān)閉不必要的服務(wù)fingerbootptcp-small-serversudp-small-serversno ip proxy-

16、arpno ip http server2、遠程訪問的安全使用SSH方式提供遠程訪問。在vty線路上不提供tel net協(xié)議的傳輸，路 由器允許終端閑置的時間設(shè)置為 5 分鐘。3、口令加密使用 service password-encryption 啟用口令加密。使用 enable secret 設(shè)置特權(quán)模式的訪問口令。4、snmp的安全刪除 public 訪問串。用訪問控制列表限制使用sn mp的圍。5、端口的安全在不可靠接口上輸入 no ip unreachables 停止發(fā)送 icmp 不可達信息，避 免路由器被DOS攻擊。在不可靠接口上應(yīng)關(guān)閉CDP協(xié)議，關(guān)閉IP反向路由設(shè)置。6、訪問控

17、制列表使用訪問控制列表技術(shù)進行訪問控制，只允許指定的 IP 地址圍訪問。7、日志設(shè)置外部的 syslog 日志服務(wù)器。在網(wǎng)絡(luò)設(shè)備上將日志發(fā)往該服務(wù)器，日志級別不低于 notification8、AAA設(shè)置外在的AAA!務(wù)器。通過該服務(wù)提供以下功能：認證authentication ,即確定訪問者的身份。路由器的控制臺登錄和遠 程登錄都要使用AAA提供的認證服務(wù)。在AAA服務(wù)器上為系統(tǒng)管理員和 系統(tǒng)操作員分別設(shè)置用戶賬號。授權(quán)authorization ，對不同的訪問者授予不同的訪問權(quán)限。系統(tǒng)管理 員賬號可以執(zhí)行修改設(shè)備配置的命令，而系統(tǒng)操作員只能執(zhí)行查看設(shè)備 狀態(tài)的命令。記帳accountin

18、g，記錄訪問者對網(wǎng)絡(luò)設(shè)備進行的操作。9、路由協(xié)議網(wǎng)絡(luò)設(shè)備上配置動態(tài)路由協(xié)議時要使用該路由協(xié)議所支持的最高級報文認證。見下表：路由協(xié)議認證方式RIPMD5OSPFMD5EIGRPMD5IS-ISMD5BGPMD51、防火墻配置基準：1、防火墻的缺省包過濾規(guī)則為允許， 在調(diào)試過程完成，測試結(jié)束后，一定要 將防火墻的默認允許，改為禁止。2、若防火墻的默認規(guī)則為全通的規(guī)則， 請刪除默認的安全規(guī)則，然后按照網(wǎng) 絡(luò)實際環(huán)境配置相應(yīng)的安全規(guī)則，并且盡量不要設(shè)置地址和服務(wù)有 ANY 勺 規(guī)則，3、為了有效保護網(wǎng)與防火墻自身的抗攻擊能力， 可以打開防火墻的抗攻擊功能,（建議在網(wǎng)絡(luò)流量大的情況下不會開此功能，會影

19、響網(wǎng)絡(luò)的處理速度）4、為了有效的保護部的網(wǎng)絡(luò)地址，并解決網(wǎng)絡(luò)地址不足的問題，請盡量使用 防火墻的NAT功能，把網(wǎng)的ip地址轉(zhuǎn)換成防火墻的公網(wǎng)地址后再訪問外部網(wǎng)絡(luò)5、為了保證防火墻本身的主機安全，不要隨意開啟防火墻的遠程SSH管理 功能，建議使用WEB+HTTP密鑰等有效的管理方法。6、為了分析防火墻的數(shù)據(jù)包記錄日志， 應(yīng)將防火墻的包過濾日志信息記錄下 來，用于對事件分析。三、數(shù)據(jù)庫配置基準：1、對于特權(quán)用戶組的管理：由于特權(quán)用戶組的賬戶， 如 GID=0, 可以進入超級用戶所建立的用戶組可寫 文件。未經(jīng)許可的用戶持有 GID=0 ，會增加敏感系統(tǒng)配置文件被更改或刪 除的風險。 在 Inform

20、ix 數(shù)據(jù)庫的管理中， Informix 用戶組里的用戶能夠?qū)?數(shù)據(jù)庫服務(wù)器空間進行管理，因此我們建議對 Informix 用戶組的授權(quán)進行 限制，只有被合理授權(quán)過的用戶才能屬于此用戶組；2、對于 dba 權(quán)限的限制由于 informix 數(shù)據(jù)庫沒有專門的用戶賬號管理的容，所以是通過數(shù)據(jù)庫授 權(quán)賦予操作系統(tǒng)賬號對數(shù)據(jù)庫的存取權(quán)限的方法來對 Informix 數(shù)據(jù)庫進行 訪問，存在三個存取級別， dba， resource ， connect 。擁有 dba 權(quán)限的用 戶能夠?qū)?shù)據(jù)庫進行操作，因此不能合理賦予數(shù)據(jù)庫用戶的權(quán)限必將帶來 較大的風險。因此我們建議對數(shù)據(jù)庫用戶的權(quán)限進行限制，只有被合理

21、授 權(quán)過的用戶才能擁有dba權(quán)限。系統(tǒng)中沒有創(chuàng)建通用的用戶/功能ID。同一 個用戶不能同時登陸多次。供應(yīng)商使用的用戶 ID 已被刪除或禁用。3、對于 Informix 的重要文件的保護Informix 的重要文件包括系統(tǒng)文件、安裝文件以及數(shù)據(jù)庫文件等，此類文 件的未經(jīng)許可訪問會對數(shù)據(jù)真實性、有效性以及保密性帶來風險。因此我 們建議限制應(yīng)用程序文件的訪問， 只有 informix 用戶組的用戶才應(yīng)該有讀、 寫、執(zhí)行權(quán)限，其他用戶有只讀權(quán)限；4、明確的職責分工建議將 Informix 中操作與審計責任進行職責劃分，即由不同的用戶擔任， 實施明確的職責分工，例如制定用戶組將DBSSO (databa

22、se securityofficer) 和 DBAO (database audit officer) 進行執(zhí)行職責劃分； (如：$INFORMAIXDIR/dbssodir/seccfg 文件中 ixuser=* 表示沒有制定用戶組） 安全管理員應(yīng)該安排各種不同的角色對數(shù)據(jù)庫進行管理。應(yīng)該為不同類別 的管理員分派不同的角色?？梢酝ㄟ^以下命令分派角色：create rolerolename ;通過以下命令為對象進行特權(quán)授權(quán)： grant privilege name on tablename to rolename; 通過以下命令為賬號分配角色： grant rolename to usern

23、ame;安全管理員應(yīng)該為“ Process ”賬號分配角色。每一種“ Process ”賬號應(yīng) 該分配特定的角色?？梢酝ㄟ^以下命令創(chuàng)建角色：create rolerolename ;可以通過以下命令為系統(tǒng)和對象建立特權(quán)： grant privilege name on tablename to rolename; 可以通過以下命令為賬號分配角色： grant rolename to username; 安全管理員應(yīng)該為用戶分配角色。每一種不同類別的用戶應(yīng)該分配不同的 角色?？梢酝ㄟ^以下命令分配角色：CREATE ROLE rolename; 通過以下命令為系統(tǒng)和對象分配特權(quán)：GRANT pri

24、vilegename ON tablename TO rolename; 可以通過以下命令為用戶分配角色：GRANT rolename TO username;5、權(quán)限訪問控制 建議妥善賦予數(shù)據(jù)庫對象的訪問權(quán)限，不然會帶來較大的風險，因此需要 確認客戶已經(jīng)限制了數(shù)據(jù)庫對象的訪問權(quán)限， 即將 systabauth 系統(tǒng)表中的 tabauth 列設(shè)為小寫字母，表示不具備數(shù)據(jù)庫對象的訪問權(quán)限；建議將系統(tǒng)表sysprocauth中的procauth列設(shè)置為小寫字母“ e”，即限 制被授權(quán)人持有對存儲過程和觸發(fā)器的執(zhí)行權(quán)，以借此來授予他人該權(quán)限； 建議為數(shù)據(jù)庫的應(yīng)用程序文件進行合理的用戶權(quán)限設(shè)置，確認只

25、有組用戶 才擁有對數(shù)據(jù)庫的應(yīng)用程序文件進行讀和運行的權(quán)限。6、系統(tǒng)安全設(shè)置在 Informix 中沒有關(guān)于如下方面的固有控制，因此必須在操作系統(tǒng)層面對 以下方面進行控制：a. 最小密碼長度；b. 保證用戶使用非空的密碼，且密碼具備一定的復(fù)雜程度；c. 強迫用戶在特定時間后更改密碼；d. 如果連續(xù)幾次失敗登陸后， 自動將賬號鎖死。 關(guān)于失敗登陸的記 錄應(yīng)該在操作系統(tǒng)層面被記錄，并有系統(tǒng)管理員定期進行審閱這些 記錄，查看是否存在異常；e. 安全管理員應(yīng)該與系統(tǒng)管理員和數(shù)據(jù)庫管理員一起決定， 在對系 統(tǒng)進行管理過程中應(yīng)該使用哪些服務(wù) / 設(shè)施 ( 例如 isql,) ，不需要的 服務(wù)/ 設(shè)施應(yīng)該及時

26、刪除。且應(yīng)該對這些需要的服務(wù) / 設(shè)施進行安全 方面的考慮，確認只有授權(quán)的人員可以使用這些服務(wù) / 設(shè)施。安全管 理員應(yīng)該定期審閱誰曾經(jīng)訪問過功能比較大的服務(wù) / 設(shè)施，確定是否 該訪問是必需的。一般的，如下文件不應(yīng)該是所有用戶都可執(zhí)行的：? onstat - 顯示共享的存儲和服務(wù)空間的統(tǒng)計數(shù)據(jù)；? on check -檢查并修訂磁盤空間；? on mode -變更一個IDS服務(wù)空間的操作模式；? onlog -邏輯日志調(diào)試工具；? oninit -初始化并啟動數(shù)據(jù)庫空間；? on spaces 酉己置數(shù)據(jù)庫 space 禾口 chunk；? onparms - 設(shè)置日志。7、安全監(jiān)控方面 系

27、統(tǒng)管理員應(yīng)該建立警報策略，以確保在出現(xiàn)以下事件時能夠及時通知操 作人員或數(shù)據(jù)庫管理員：? 創(chuàng)建表失敗( Table failure )；? 創(chuàng)建索引失敗( Index failure )；? 二進制大對象失敗( Blob failure )；Chunk 離線， mirror 處于激活狀態(tài)： %ld (Chunk is off-line, mirror is active: %ld (chunk number)； 數(shù)據(jù)庫空間離線( DBSpace is off-line )；部子系統(tǒng)失敗( Internal Subsystem failure )； 數(shù)據(jù)庫服務(wù)空間初始化失敗( Database

28、server initialization failure)；)；)；)； %s (pathname) ；)物理修復(fù)失敗( Physical Restore failed 物理恢復(fù)失敗( Physical Recovery failed 物理恢復(fù)失敗( Logical Recovery failed 不能打開 Chunk ( Cannot open Chunk:不能打開數(shù)據(jù)庫空間(Cannot open Dbspace: %s (dbspace name；) )性能提升( Performance Improvement possible )； 數(shù)據(jù)庫失敗( Database failure.

29、)； 可用很高的數(shù)據(jù)復(fù)制失敗 ( High-availabilitydata-replication failure. )；檔案文件異常( Archive aborted )； 日志備份異常( Log Backup aborted )； 邏輯日志滿了需要備份( Logical Logs are full - Backup is needed)；數(shù)據(jù)庫服務(wù)空間資源溢出( Database server resource overflow)；? 長期交易檢查( Long Transaction detected )；? 邏輯日志完成( Logical Log Complete )；? 不能分配存儲

30、空間( Unable to Allocate Memory )。b.c.啟動事件日志 (例如對于關(guān)鍵數(shù)據(jù)庫表的訪問的審計痕跡) 。每天對事件日志進行審 閱。數(shù)據(jù)庫管理員應(yīng)該定期監(jiān)控數(shù)據(jù)庫。 (可以通過使用 onstat ，或者 oncheck 、onlog 等命令)? 檢查消息日志： 一些至關(guān)重要的信息可能來自消息日志，如防火墻的安裝，邏 輯日志的備份，或者服務(wù)器崩潰。? 檢察系統(tǒng)狀況 ( 存，硬盤和輸入輸出利用率 ): 系統(tǒng)狀況體現(xiàn)了系統(tǒng)活動狀態(tài)， 例如顯示資源缺乏或一般的性能統(tǒng)計。通過檢查系統(tǒng)狀況，可以幫助確定引起 系統(tǒng)問題的性能因素。? 檢查輸入輸出隊列活動： 如果系統(tǒng)中產(chǎn)生了輸入輸出隊

31、列，就會有傳輸?shù)钠款i。 當數(shù)據(jù)從物理磁盤之間傳輸過程中不能達到預(yù)期的傳輸速度就會產(chǎn)生傳輸隊列?？梢酝ㄟ^使用 on stat -g ioq命令為每一個虛擬處理器(VP)監(jiān)控這些隊列。該命令的輸出結(jié)果顯示了每一個能夠進行異步傳輸?shù)腣P的傳輸請求隊列的統(tǒng)計結(jié)果。 該結(jié)果中有兩個重要的列： len 和 maxlen。 Len 是指當前隊列的長度，maxle n是指在服務(wù)器開啟后或上一次on stat - z操作后的最大隊列長度。如果maxlen 是兩位數(shù)，傳輸請求就需要排隊，這樣就會引起性能的降低。?檢查CPU隊列活動：如果用戶線程需要排隊通過 CPU的虛擬處理器處理，就會出現(xiàn)CPU的瓶頸。當準備運行

32、一個線程時，所有的CUP虛擬處理器都在執(zhí)行其他的線程，就會產(chǎn)生CPU隊列,。這種隊列可以通過以下命令來監(jiān)控on stat -g rea。該命令的運行結(jié)果顯示所有準 備啟動的， 但是需要排隊等候執(zhí)行的用戶的線程。四、操作系統(tǒng)配置基準：UNIX系統(tǒng)：1、系統(tǒng)閑置時間設(shè)置：建議針對IBM AIX、HPUX小型機操作系統(tǒng)的和服務(wù)器SCOUNIX系統(tǒng)中設(shè)定統(tǒng)一的系統(tǒng)進程最大閑置時間，并對最大閑置時間的大小做出規(guī)定： TIMEOUT / TMOUT100，用戶GID100,小于100的保留給系統(tǒng)使用； 通用賬號應(yīng)被禁用；不使用的默認系統(tǒng)賬號應(yīng)禁用；無需授權(quán)的賬號不允許被使用； 已離職的員工賬號及時刪除或禁

33、用； 第三方服務(wù)商技術(shù)支持賬號應(yīng)禁用，僅在需要時臨時開啟； 控制 shadow password 文件的訪問權(quán)限； 新賬號應(yīng)有唯一的初始密碼，第一次使用新賬號時應(yīng)立即修改該密碼， 密碼以安全方式發(fā)布；?密碼應(yīng)不易猜測，具有一定復(fù)雜度?密碼組成：a. 4 = maxage = 1c. Minalpha = 1d. Minother = 1e. mindiff = 1f. maxrepeats = 23、超級用戶賬號管理：?只有 root UID =0；?root 的路徑不能包括當前的工作目錄；?應(yīng)該限制 root 用戶的遠程登錄；telnet = false ; rlogin = false 。

34、只允許前臺( console )進行 root 登錄， root 用戶的登錄 應(yīng)包含以下命令行：4、Unix操作系統(tǒng)配置管理：? 對于Umask的控制，建議設(shè)置為027;? 限制SUID和SGID程序的使用;文件中列出;? 所有的 shell 都必須在 /etc/shells ? 建議操作系統(tǒng)為所有 world-writeable 的目錄都設(shè)置粘貼位 ( “T”) ;? 建議只有 root 用戶才有權(quán)使用 at 或 batch 命令;crontab 命令的權(quán)限只授權(quán)給必須使用該命令的用戶;? 在/etc/ftpusers文件中加入允許使用ftp得用戶列表;? 不要通過 hosts.equiv

35、文件來建立信任;? 建立定期對重要文件權(quán)限進行檢查的機制;? 建議檢查所有的網(wǎng)絡(luò)服務(wù)配置，所有不必要的網(wǎng)絡(luò)服務(wù)配置從/etc/inetd.conf 文件中刪除;? 除非必須， 否則建議移除所有以 r 開頭的命令和以 .rhosts 結(jié)尾的文件;? 只在需要的情況下開啟telnet daemon ;? 禁止后臺程序 finger的使用;? 檢查本機是否真的需要ftp 服務(wù)，如果不需要，應(yīng)禁止使用這個服務(wù)? 禁止后臺程序 tftp 、rexec 的使用;? 禁止UUCP協(xié)議的使用;? 系統(tǒng)中同磁盤、存儲、磁帶和網(wǎng)絡(luò)文件要設(shè)置為644;，以保護下列系統(tǒng)程序：列文件的權(quán)限位將為 555(r-x r-x r-x:)/usr/sbin/mount /usr/sbin/acct/a