基礎(chǔ)架構(gòu)配置與變更管理制度

1、 中國人壽信息技術(shù)管理制度基礎(chǔ)架構(gòu)配置與變更管理制度第一節(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)絡管理員、安全管理員等。第二節(jié) 平臺軟件的基準配置第六條 平臺軟件的基準配置包括操作系統(tǒng)軟件、數(shù)據(jù)庫軟件、網(wǎng)絡設(shè)備系統(tǒng)軟件、安全

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

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

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

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

6、壞損時可申請硬件設(shè)施配置的變更，并填寫配置變更申請、審批表。第十九條 配置管理員負責對硬件設(shè)施進行配置管理和維護，配置監(jiān)管人負責確認硬件設(shè)施配置的正確性。第二十條 配置變更應有統(tǒng)一的配置變更申請、審批流程。配置變更申請、審批表中應寫明該配置變更所屬設(shè)備的名稱、配置的類別（CPU、內(nèi)存、硬盤、備份電源、HBA卡、網(wǎng)卡、光驅(qū)、磁帶機、網(wǎng)絡設(shè)備接口模塊）和配置變更的原因及內(nèi)容。第二十一條 配置管理員應根據(jù)變更申請制定配置變更計劃，變更計劃中應詳細說明該配置變更可能對系統(tǒng)本身以及其他系統(tǒng)產(chǎn)生的影響、配置變更發(fā)生的時間、地點等。第二十二條 配置單位管理層應根據(jù)配置變更計劃及該配置變更所能產(chǎn)生的影響進行分

7、析評估，確定配置變更的原因是否充分，決定是否需要進行配置變更測試、是否同意該變更。配置單位管理層應在配置變更申請、審批表中記錄審批結(jié)果并簽字。第二十三條 經(jīng)授權(quán)的配置管理員應根據(jù)審批后的配置變更計劃進行配置變更，若需進行配置變更測試時，應首先完成測試并出具測試報告。配置管理員在完成配置變更后應及時填寫配置變更記錄表，該表要求變更申請人對配置變更結(jié)果進行確認并簽字。同時配置管理員應更新硬件設(shè)備維護檔案中的硬件設(shè)備基本配置(見硬件設(shè)備維護規(guī)定)。第二十四條 配置管理員還應將配置變更申請、審批表、硬件設(shè)備維護檔案、測試報告作為配置變更記錄表的附件提交給配置監(jiān)管人，由其進行配置變更的確認，并在配置變更

8、記錄表的“監(jiān)管人”一欄中簽字。第五節(jié) 基礎(chǔ)架構(gòu)布局的變更第二十五條 基礎(chǔ)架構(gòu)布局的變更包括但不限于：設(shè)備增減、設(shè)備遷移、線路調(diào)整、拓撲變化、定期停機檢修等。第二十六條 維護單位應為基礎(chǔ)架構(gòu)布局建立相關(guān)文檔，如機房布線圖、網(wǎng)絡拓撲圖、設(shè)備分布圖、機架分布圖、跳線表、地址表等。當基礎(chǔ)架構(gòu)布局發(fā)生變更時此類基礎(chǔ)架構(gòu)布局文檔應得到及時的更新。第二十七條 基礎(chǔ)架構(gòu)布局變更時，變更提出方應填寫布局變更申請、審批表，申請表中應具體描述變更的原因、內(nèi)容、時間、涉及到的部門等相關(guān)內(nèi)容，經(jīng)需求方管理層審批后提交配置管理單位。第二十八條 經(jīng)授權(quán)的配置管理員應根據(jù)審批后的布局變更計劃進行布局變更并填寫布局變更記錄表，

9、該表要求變更申請人對布局變更結(jié)果進行確認。配置管理員應同時更新相關(guān)的基礎(chǔ)架構(gòu)布局文檔。第二十九條 配置管理員還應將布局變更申請、審批表、基礎(chǔ)架構(gòu)布局文檔一并作為布局變更記錄表的附件提交給配置監(jiān)管人，由其進行布局變更的確認，并在布局變更記錄表的“監(jiān)管人”一欄中簽字。第六節(jié) 變更事件的處理第三十條 根據(jù)變更事件可能造成的影響，其范圍可以分為處室范圍、部門范圍、省公司本部范圍、省公司本部及下級地市公司范圍四類。配置管理單位應將可能產(chǎn)生的變更行為依據(jù)上述四種影響范圍進行歸類劃分，并每半年對分類規(guī)則進行評估更新。第三十一條 根據(jù)上述分類規(guī)則，維護單位應詳細制定變更事件的通知細則，其內(nèi)容應包括各種影響范圍

10、的最遲提前申請時間、最遲提前通知時間、變更審批領(lǐng)導等，并根據(jù)變更事件影響范圍的更新而重新評估通知細則。第三十二條 經(jīng)過審批的配置變更或布局變更，配置管理維護單位管理層應根據(jù)影響范圍及通知細則提前發(fā)布變更通知，以便受影響管理方能夠及時與可能影響到的有關(guān)各方聯(lián)系確認，并提前通知有關(guān)各方預先做好準備。第三十三條 為減少配置變更與布局變更對正常業(yè)務和工作的影響，變更實施應盡量安排在業(yè)務、工作的空閑時段進行。第七節(jié) 定期審閱第三十四條 技術(shù)的進步或系統(tǒng)、設(shè)備的升級可能引起配置基準的改變。信息技術(shù)處應根據(jù)設(shè)備或系統(tǒng)的升級情況決定是否更新配置基準。維護單位應定期對各類配置對象的配置基準進行評估(每年一次)，

11、形成配置基準評估表并提交管理層審閱。第三十五條 若需發(fā)生配置基準的變更行為則應按照配置變更申請、審批流程執(zhí)行。配置管理員在填寫配置變更申請時，應詳細說明該配置變更屬配置基準的變更。配置基準的變更必需經(jīng)過測試成功后方可實施。第三十六條 為了防止配置管理人員有意或無意的對軟、硬件的配置、基礎(chǔ)架構(gòu)布局的非法更改，應建立對配置清單、基礎(chǔ)架構(gòu)布局文檔、配置變更記錄、布局變更記錄的年審機制，該年審工作應由配置監(jiān)管人員執(zhí)行。配置監(jiān)管人應根據(jù)相關(guān)文檔對真實情況進行檢查，確保實際情況與相關(guān)文檔的記錄一致。第三十七條 配置監(jiān)管人員進行年審工作后應填寫基礎(chǔ)架構(gòu)變更年審表，該年審表應說明相關(guān)文檔與實際情況是否相符。若

12、實際情況與相關(guān)文檔不一致則應說明發(fā)生的原因與處理結(jié)果。第八節(jié) 文檔保存第三十八條 在基礎(chǔ)架構(gòu)配置與變更管理過程中產(chǎn)生的所有文檔，包括配置基準、配置清單、基礎(chǔ)架構(gòu)布局相關(guān)文檔、配置變更申請、審批表、布局變更申請、審批表、配置變更記錄表、布局變更記錄表、基礎(chǔ)架構(gòu)變更年審表、配置基準評估表等均應該由配置管理單位指定專人進行統(tǒng)一管理，保留工作痕跡。第九節(jié) 附則第三十九條 本制度由省公司信息技術(shù)處負責解釋和修訂。第四十條 本制度自發(fā)布之日起開始執(zhí)行。附件一 配置變更申請、審批流程附件二 配置變更管理流程附件三 配置變更申請、審批表姓名部門處室設(shè)備名稱設(shè)備編號有效期至變 更 需 求 欄 *申請方填寫*變更

13、類型平臺軟件數(shù)據(jù)庫¨ 操作系統(tǒng)¨ 路由策略¨ 安全策略¨補丁/升級¨其它¨硬件設(shè)施CPU ¨內(nèi)存¨硬盤¨備份電源¨ HBA卡¨網(wǎng)卡¨光驅(qū)¨磁帶機¨網(wǎng)絡設(shè)備接口模塊¨其它¨變更原因：變更內(nèi)容：申請單位審批人：結(jié)論：審批時間：變 更 分 析 欄 *變更方填寫*配置計劃： 管理員： 時間： 影響范圍： 管理員： 時間： 變更實施時間：通知發(fā)布時間：通知發(fā)布對象：配置單位審批人： 結(jié)論：審批時間：附件四 布局變更申請、審批表姓名部門處室截止日期

14、變 更 需 求 欄 *申請方填寫*變更類別：設(shè)備增減¨ 設(shè)備遷移¨ 線路調(diào)整¨ 拓撲變化¨ 停電檢修¨ 其它¨變更原因：變更內(nèi)容：申請單位審批人：結(jié)論：時間：變 更 分 析 欄 *變更方填寫*布局變更計劃： 管理員： 時間： 影響范圍： 管理員： 時間： 變更實施時間：通知發(fā)布時間：通知發(fā)布對象：變更單位審批人： 結(jié)論：時間：附件五 配置變更記錄表編號：設(shè)備編號：變更時間：管理員：變更類型數(shù)據(jù)庫¨ 操作系統(tǒng)¨ 路由策略¨ 安全策略¨補丁/升級¨硬件資源¨ 其它¨ 變

15、更結(jié)論結(jié)論：申請人：時間：配置變更審閱變更審批審批表的鏈接（或附件）測試情況若存在測試，提供測試報告的鏈接（或附件），否則無。變更后文檔配置清單或設(shè)備維護檔案的鏈接（或附件）審核結(jié)論： 監(jiān)管人：審核時間：附件六 布局變更記錄表編號：結(jié)構(gòu)文檔號：變更時間：管理員：變更類型設(shè)備增減¨ 設(shè)備遷移¨ 線路調(diào)整¨ 拓撲變化¨ 停電檢修¨ 其它¨ 變更結(jié)論結(jié)論：申請人：時間：配置變更審閱變更審批審批表的鏈接（或附件）測試情況若存在測試，提供測試報告的鏈接（或附件），否則無。變更后文檔布局文檔的鏈接（或附件）審核結(jié)論： 監(jiān)管人：審核時間：附件七 基

16、礎(chǔ)架構(gòu)變更年審表變更對象變更類型審閱結(jié)論審閱時間監(jiān)管人附件八 配置基準一、路由器配置基準：1、關(guān)閉不必要的服務fingerbootptcp-small-serversudp-small-serversno ip proxy-arpno ip http server2、遠程訪問的安全使用SSH方式提供遠程訪問。在vty線路上不提供telnet協(xié)議的傳輸，路由器允許終端閑置的時間設(shè)置為5分鐘。3、口令加密使用service password-encryption啟用口令加密。使用enable secret設(shè)置特權(quán)模式的訪問口令。4、snmp的安全刪除public訪問串。用訪問控制列表限制使用snm

17、p的范圍。5、端口的安全在不可靠接口上輸入no ip unreachables停止發(fā)送icmp不可達信息，避免路由器被DOS攻擊。在不可靠接口上應關(guān)閉CDP協(xié)議，關(guān)閉反向路由設(shè)置。6、訪問控制列表使用訪問控制列表技術(shù)進行訪問控制，只允許指定的IP地址范圍訪問。7、日志設(shè)置外部的syslog日志服務器。在網(wǎng)絡設(shè)備上將日志發(fā)往該服務器，日志級別不低于notification。8、AAA設(shè)置外在的AAA服務器。通過該服務提供以下功能：l 認證authentication，即確定訪問者的身份。路由器的控制臺登錄和遠程登錄都要使用AAA提供的認證服務。在AAA服務器上為系統(tǒng)管理員和系統(tǒng)操作員分別設(shè)置用戶

18、賬號。l 授權(quán)authorization，對不同的訪問者授予不同的訪問權(quán)限。系統(tǒng)管理員賬號可以執(zhí)行修改設(shè)備配置的命令，而系統(tǒng)操作員只能執(zhí)行查看設(shè)備狀態(tài)的命令。l 記帳accounting，記錄訪問者對網(wǎng)絡設(shè)備進行的操作。9、路由協(xié)議網(wǎng)絡設(shè)備上配置動態(tài)路由協(xié)議時要使用該路由協(xié)議所支持的最高級報文認證。見下表：路由協(xié)議認證方式RIPMD5OSPFMD5EIGRPMD5IS-ISMD5BGPMD5二、防火墻配置基準：1、 防火墻的缺省包過濾規(guī)則為允許，在調(diào)試過程完成，測試結(jié)束后，一定要將防火墻的默認允許，改為禁止。2、 若防火墻的默認規(guī)則為全通的規(guī)則，請刪除默認的安全規(guī)則，然后按照網(wǎng)絡實際環(huán)境配置相

19、應的安全規(guī)則，并且盡量不要設(shè)置地址和服務有ANY的規(guī)則，3、 為了有效保護內(nèi)網(wǎng)與防火墻自身的抗攻擊能力，可以打開防火墻的抗攻擊功能，（建議在網(wǎng)絡流量大的情況下不會開此功能，會影響網(wǎng)絡的處理速度）4、 為了有效的保護內(nèi)部的網(wǎng)絡地址，并解決網(wǎng)絡地址不足的問題，請盡量使用防火墻的功能，把內(nèi)網(wǎng)的ip地址轉(zhuǎn)換成防火墻的公網(wǎng)地址后再訪問外部網(wǎng)絡。5、 為了保證防火墻本身的主機安全，不要隨意開啟防火墻的遠程管理功能，建議使用WEB+HTTPS+密鑰等有效的管理方法。6、 為了分析防火墻的數(shù)據(jù)包記錄日志，應將防火墻的包過濾日志信息記錄下來，用于對事件分析。三、數(shù)據(jù)庫配置基準：1、對于特權(quán)用戶組的管理：由于特權(quán)

20、用戶組的賬戶，如GID=0, 可以進入超級用戶所建立的用戶組可寫文件。未經(jīng)許可的用戶持有GID=0 ，會增加敏感系統(tǒng)配置文件被更改或刪除的風險。在Informix數(shù)據(jù)庫的管理中，Informix用戶組里的用戶能夠?qū)?shù)據(jù)庫服務器空間進行管理，因此我們建議對Informix用戶組的授權(quán)進行限制，只有被合理授權(quán)過的用戶才能屬于此用戶組；2、對于dba權(quán)限的限制 由于informix數(shù)據(jù)庫沒有專門的用戶賬號管理的內(nèi)容，所以是通過數(shù)據(jù)庫授權(quán)賦予操作系統(tǒng)賬號對數(shù)據(jù)庫的存取權(quán)限的方法來對Informix數(shù)據(jù)庫進行訪問，存在三個存取級別，dba，resource，connect。擁有dba權(quán)限的用戶能夠?qū)?shù)據(jù)

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

22、即由不同的用戶擔任，實施明確的職責分工，例如制定用戶組將DBSSO (database security officer) 和DBAO (database audit officer)進行執(zhí)行職責劃分；（如：$INFORMAIXDIR/dbssodir/seccfg 文件中ixuser=* 表示沒有制定用戶組）安全管理員應該安排各種不同的角色對數(shù)據(jù)庫進行管理。應該為不同類別的管理員分派不同的角色?？梢酝ㄟ^以下命令分派角色：create role rolename;通過以下命令為對象進行特權(quán)授權(quán)：grant privilege name on tablename to rolename;通過以下

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

24、以下命令為系統(tǒng)和對象分配特權(quán)：GRANT privilegename 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ù)庫的應用程序文件

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

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

27、日志。7、安全監(jiān)控方面系統(tǒng)管理員應該建立警報策略，以確保在出現(xiàn)以下事件時能夠及時通知操作人員或數(shù)據(jù)庫管理員：· 創(chuàng)建表失?。═able failure）；· 創(chuàng)建索引失?。↖ndex failure）；· 二進制大對象失敗（Blob failure）；· Chunk 離線，mirror處于激活狀態(tài)：%ld (Chunk is off-line, mirror is active: %ld (chunk number)；· 數(shù)據(jù)庫空間離線（DBSpace is off-line）；· 內(nèi)部子系統(tǒng)失?。↖nternal Subsystem

28、 failure）；· 數(shù)據(jù)庫服務空間初始化失敗（Database server initialization failure）；· 物理修復失敗（Physical Restore failed）；· 物理恢復失?。≒hysical Recovery failed）；· 物理恢復失?。↙ogical Recovery failed）；· 不能打開Chunk （Cannot open Chunk: %s (pathname)）；· 不能打開數(shù)據(jù)庫空間（Cannot open Dbspace: %s (dbspace name)）；

29、83; 性能提升（Performance Improvement possible）；· 數(shù)據(jù)庫失?。―atabase failure.）；· 可用很高的數(shù)據(jù)復制失?。℉igh-availability data-replication failure.）；· 檔案文件異常（Archive aborted）； · 日志備份異常（Log Backup aborted）；· 邏輯日志滿了需要備份（Logical Logs are full - Backup is needed）；· 數(shù)據(jù)庫服務空間資源溢出（Database server

30、resource overflow）；· 長期交易檢查（Long Transaction detected）；· 邏輯日志完成（Logical Log Complete）；· 不能分配存儲空間（Unable to Allocate Memory）。b. 啟動事件日志（例如對于關(guān)鍵數(shù)據(jù)庫表的訪問的審計痕跡）。每天對事件日志進行審閱。c. 數(shù)據(jù)庫管理員應該定期監(jiān)控數(shù)據(jù)庫。（可以通過使用 onstat，或者 oncheck 、 onlog等命令）· 檢查消息日志：一些至關(guān)重要的信息可能來自消息日志，如防火墻的安裝，邏輯日志的備份，或者服務器崩潰。·

31、檢察系統(tǒng)狀況(內(nèi)存，硬盤和輸入輸出利用率): 系統(tǒng)狀況體現(xiàn)了系統(tǒng)活動狀態(tài)，例如顯示資源缺乏或一般的性能統(tǒng)計。通過檢查系統(tǒng)狀況，可以幫助確定引起系統(tǒng)問題的性能因素。· 檢查輸入輸出隊列活動：如果系統(tǒng)中產(chǎn)生了輸入輸出隊列，就會有傳輸?shù)钠款i。當數(shù)據(jù)從物理磁盤之間傳輸過程中不能達到預期的傳輸速度就會產(chǎn)生傳輸隊列?？梢酝ㄟ^使用onstat -g ioq 命令為每一個虛擬處理器（VP）監(jiān)控這些隊列。該命令的輸出結(jié)果顯示了每一個能夠進行異步傳輸?shù)腣P的傳輸請求隊列的統(tǒng)計結(jié)果。該結(jié)果中有兩個重要的列：len和maxlen。Len是指當前隊列的長度，maxlen是指在服務器開啟后或上一次onstat

32、z操作后的最大隊列長度。如果maxlen 是兩位數(shù)，傳輸請求就需要排隊，這樣就會引起性能的降低。· 檢查CPU隊列活動：如果用戶線程需要排隊通過CPU的虛擬處理器處理，就會出現(xiàn)CPU的瓶頸。當準備運行一個線程時，所有的CUP虛擬處理器都在執(zhí)行其他的線程，就會產(chǎn)生CPU隊列,。這種隊列可以通過以下命令來監(jiān)控onstat -g rea。該命令的運行結(jié)果顯示所有準備啟動的，但是需要排隊等候執(zhí)行的用戶的線程。四、操作系統(tǒng)配置基準：UNIX系統(tǒng)：1、 系統(tǒng)閑置時間設(shè)置: 建議針對IBM AIX、HPUX小型機操作系統(tǒng)的和服務器SCO UNIX系統(tǒng)中設(shè)定統(tǒng)一的系統(tǒng)進程最大閑置時間，并對最大閑置時

33、間的大小做出規(guī)定：TIMEOUT / TMOUT <= 300。2、 用戶賬號管理和密碼策略：· 每個用戶有唯一的用戶名（username）和用戶ID（UID）；· 用戶UID>100，用戶GID>100，小于100的保留給系統(tǒng)使用；· 通用賬號應被禁用；· 不使用的默認系統(tǒng)賬號應禁用；· 無需授權(quán)的賬號不允許被使用；· 已離職的員工賬號及時刪除或禁用；· 第三方服務商技術(shù)支持賬號應禁用，僅在需要時臨時開啟；· 控制shadow password文件的訪問權(quán)限；· 新賬號應有唯一的初始密

34、碼，第一次使用新賬號時應立即修改該密碼，密碼以安全方式發(fā)布；· 密碼應不易猜測，具有一定復雜度· 密碼組成：a. 4 <= maxage <= 13b. minage >= 1c. Minalpha >= 1d. Minother >= 1e. mindiff >= 1f. maxrepeats <= 23、 超級用戶賬號管理：· 只有root UID =0；· root 的路徑不能包括當前的工作目錄；· 應該限制root用戶的遠程登錄；· 組內(nèi)的特權(quán)用戶（GID=0）應被適當查看；·

35、; 只允許前臺（console）進行root登錄，root用戶的登錄應包含以下命令行：telnet = false；rlogin = false。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)給必須使用該命令的用戶；· 在/e

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