文檔信息

 

修訂記錄

 

審批發布

 

一 總則

目的。爲規範自有軟件研發以及外包軟件的管理工作，依據《世界杯官网信息安全管理辦法》制定本管理制度。

對象。本制度中軟件開發指新系統開發和現有系統重大改造。

範圍。本制度適用于世界杯官网軟件研發與管理。

要求。世界杯官网信息系統的軟件開發安全管理要求統一遵循《GB/T 22239-2019信息安全技术 信息系统安全等级保护基本要求》。

二 軟件開發管理制度

1 通用規範

1. 系統開發總體原則：

（1）系統開發應從業務需求的角度出發，不得盲目追求系統先進性而忽略了系統的實用性。

（2）開發的方法和管理必須規範化、合理化、制度化。只有采用了規範化、合理化、制度化的開發管理方法，才能確保開發的質量和進度。

（3）確保系統開發環境與業務環境相隔離，內部測試由開發人員自行搭建環境，模擬測試必須在專用的測試環境中進行測試。

（4）確保開發進度和開發質量。

（5）系統開發必須具有一定的前瞻性，符合主流系統的發展方向。

（6）開發人員安全意識的提高和加強，確保機密信息和關鍵技術不泄漏。

（7）充分利用現有的資源。

2. 系統開發人員職責分配管理規範：

在系統開發的過程中，應明確不同人員的角色和職責。通常在系統開發過程中具體劃分以下四種角色：

（1）項目負責人員：確保在整個系統開發的各個階段都實施了相關的安全措施，同時在整個系統開發的過程中負責整個項目的開發安全管理。

（2）系統開發人員：根據業務需求確保開發的系統能夠滿足業務上的需求和相應的安全上的需求，同時滿足系統質量上和進度上的要求。

（3）系統審計人員：對整個開發的過程進行審核和監督，確保開發的質量和開發的安全，建議由單位相關人員承擔。

（4）文檔管理員：負責對整個開發過程産生的系統軟件設計類相關文檔、系統培訓和操作等用戶手冊進行管理和使用控制。

3. 開發人員授權管理規範：

（1）開發人員授權由單位安全管理員協調相關管理員進行授權。

（2）根據該員工在整個開發項目中所負責的開發內容授予其相應的權限和承擔的責任。

（3）開發人員必須負責其開發內容的保密性，不得私自將開發的相關信息泄漏出去。

（4）根據員工權限和責任的大小確認是否需要簽署相關的保密協議。

（5）在日常工作中記錄員工的開發相關的日志信息。

（6）員工一旦離職或調動崗位應立即收回或調整其相應的權限。

4. 系統開發變更管理：

（1）開發人員必須確認所有需要更改的應用系統、信息、數據庫和相關的硬件設備。

（2）確認更改的原因(業務上的具體流程和具體的需求或開發上的需求)。

（3）在正式的實施之前，更改的方案必須經過評審並通過正式的批准。

（4）確保授權的用戶在實施之前確認並接受更改的內容。

（5）確保在實施的過程中，盡量減少對現行系統的影響。

（6）確保建立的文件系統在完成各項更改時得到修改，舊文件被很好的歸檔或處置。

（7）保證對所有系統升級的版本的控制。

（8）確保用戶使用手冊作相應的必要的更改。

（9）確保更改的實施選擇了適當的時機以確保更改的實施不會幹擾正常的系統運行。

2 系统需求分析阶段規範

1. 技術可行性分析：

（1）根據業務上提出的需求，從技術開發的角度分析現有的技術手段和技術能力是否可以達到業務上要求的系統功能，通常可以從三個方面進行分析：

技術能力分析：指學校內的系統開發隊伍是否有足夠的軟件開發技術能力來完成系統開發的任務，或第三方外包的開發單位是否具有開發應用系統的技術能力。

計算機軟件和硬件分析：指學校現有的軟件和硬件的性能或配置是否足夠滿足系統開發的要求。

管理能力分析：指現有的技術開發管理制度和管理流程是否成熟且標准化，是否足夠系統開發的要求。

（2）需求可行性分析：系統的開發來源于業務上的需求，因此需要對該需求進行可行性分析，以判斷需求是否明確，是否符合實際，是否在一定的時間範圍內可實現。

（3）投資可行性分析：根據業務需求和技術手段的分析，確認根據業務需求和技術手段需要多少投資才可以實現，確認投資的數額是不是在可控制和可承受的範圍內。

（4）影響可行性分析：新系統開和投入運營會不會造成社會影響，以及造成的社會影響有多少等；新系統開發和投入運營是否會對現有的系統造成不良影響。

2. 在技術可行性分析階段，同樣必須從身份鑒別、訪問控制、軟件容錯、數據加密和安全審計等方面進行系統安全需求分析，並且提供相關安全需求分析報告，報告應包括以下內容：

（1）安全需求計劃應能夠達到期望的安全水平。其中包括了成本的預估，完成各個安全相關流程所需的時間。

（2）所有有關應用系統的更新或改進都必須是基于業務需求的，並且是有業務事件支持的。這裏的業務需求不僅僅包括了系統的功能、性能、開發費用、開發周期等內容，還要明確系統的安全要求。

（3）安全開發需求分析計劃應由開發項目負責人和學校內部安全管理員共同商議決定。

（4）系統的更新或改進都必須進行詳細的需求定義、需求分析以及測試評估以保證不會對業務造成任何的影響。

（5）業務需求是系統更新和改動的基礎，因此必須清晰明確的定義業務的需求，絕對不允許在業務需求未經過業務部門領導和主要負責人員的認可的情況下進行開發。

3. 在技術可行性分析階段，同樣建議考慮系統的容量規劃，容量規劃是指確定系統的總體規模，性能和系統彈性。容量規劃的具體內容可能有所不同，但一般需要考慮以下方面：

（1）系統的預期存儲容量和在給定的周期內獲取生成和存儲的數據量。

（2）在線進程的數量和估計可能的占用資源。

（3）對于系統和網絡的相應時間和性能的要求。

（4）系統彈性要求和設計使用率、峰值、槽值和平均值等。

（5）安全措施（如加密解密數據）對系統的影響。

（6）24x7運作要求和可接受的系統宕機次數。

3 系统开发阶段安全規範

1. 開發人員技術要求：

（1）開發人員應有能力防止開發過程中的緩沖器溢出錯誤。

（2）在整個開發過程中必須完整持續的進行代碼錯誤處理所規定的流程。

（3）錯誤問題報告應越通俗越好，不應在其中包含任何系統細節問題。

（4）應對重要的敏感信息進行加密的保護。

（5）應使用一些相對複雜的加密和密鑰生成機制。

（6）應單獨編寫安全性設計說明概要。

2.程序库管理規範：

（1）程序庫的修改、更新由開發人員提出申請，由學校信息系統項目管理人員進行審批，並由開發人員進行彙總登記。

（2）管理開發工具：

n 嚴格管理在開發設備上的存放開發工具的目錄。

n 只有指定的人員經過適當的管理授權後才可以訪問開發工具服務器。

（3）訪問控制：

n 嚴格管理開發環境的安全管理，防止未經授權的人進入開發環境。

n 嚴格管理開發用途的計算機，只有指定的人員才可以訪問開發用的計算機設備。

n 嚴格管理開發系統的認證管理，建立嚴格的基于人員職責的授權等級制度，用口令或其他身份識別技術確認訪問者身份。

（4）源代碼管理：

n 必須嚴格管理在開發系統上的存放源代碼的目錄。

n 只有指定的人員如程序庫管理員經過適當的管理授權後才可以訪問源代碼庫，對源代碼庫的訪問必須結合嚴格的訪問控制技術手段和雙重訪問控制機制。

n 各項應用應指定相應的管理員。

n 非開發人員不應自由的訪問源代碼庫。

n 源代碼庫和開發工具服務器盡量分開存放並且分開管理。

n 源代碼庫和運行的應用系統盡量分開存放且分開管理。

n 源代碼庫的更新和向開發人員發布的源代碼應由指定的管理員根據一定的授權進行，不得私自自行更新或發放。

n 應保存所有對源代碼庫進行訪問讀取或修改的日志紀錄，以便于日後審計。

3. 开发版本管理規範：

（1）版本程序管理：

n 對于程序清單必須進行嚴格的控制並及時地進行更新。

n 對應用系統開發源代碼的打印資料、電子版本或者是相關的報告都必須進行控制，紙質的文件應保存在一個安全的環境下，如保險櫃等。電子文檔則應有一定的加密措施。

（2）版本升級管理：

n 當軟件的版本由于更新，修改等操作需要升級時必須先向單位相關負責人員提交申請。

n 應用系統軟件版本升級測試，對升級的應用系統進行測試，確認系統的各種安全特性。

n 需確認當前的版本爲最新的版本，舊的版本需進行歸檔，不得隨意丟棄或刪除。

n 制定相關的升級計劃，確保將系統升級對業務的影響降至最低。

（3）版本控制管理：

n 開發人員必須對版本變更進行管理，符合相關變更管理規定。

n 防止不同版本的覆蓋的情況。

n 版本變更時需要在更新的版本中記錄變更的詳細描述。

n 版本的更改只允許指定的人員進行操作。

n 開發人員記錄所有版本變更的日志並由單位信息系統項目管理人員進行審核，記錄應包括更改日期、更改前版本號、更改後版本號、更改人等信息。

4. 开发检查管理規範：

（1）開發日志定期檢查，系統開發中的相關日志文件根據開發周期定期審核。

（2）開發人員權限應定期檢查。

（3）應有防禦後門代碼或隱藏通道控制措施，如對源代碼進行檢查，安裝相關檢查工具等。

5. 按照第三方管理規定對開發外包安全進行管理。

4 系统测试阶段安全規範

1. 应用系统的安全性测试規範：

（1）必須有詳細的測試計劃，包括測試範圍、測試方法和測試工具。

（2）在測試的過程中詳細描述與測試方案相關的測試步驟和測試數據，將所有的測試數據進行整理歸檔，將出錯的紀錄進行分析，確認問題産生的原因並編寫問題報告。

（3）應用系統上線前必須經過安全性測試。

2. 測試數據通用要求：

（1）任何測試數據必須妥善保管理和處理，不得隨意丟棄和泄露。

（2）爲了防止數據泄漏和敏感系統的濫用，一般情況下要求使用虛構數據進行測試。

（3）當處于測試目的而使用真實的敏感的數據時，可以采用以下措施保護測試數據的安全：

n 對測試的系統進行嚴格的訪問控制。只允許小部分的測試人員進行測試。且對于測試的人員按需要簽訂保密協議。

n 將真實的運行信息複制到測試系統時間應有單獨授權過程。

n 測試完成後，應立即將相關數據從測試的應用系統中刪除。

n 記錄下測試數據的複制、使用和刪除的情況，以便于審查追蹤。

3. 質量認證：目前國際上公認的開發質量驗證標准主要有兩種，可以根據這兩種標准確認系統是否已經達到一定的質量要求，如ISO9000認證體系，軟件開發能力成熟度模型(CMM)。

5 培训与文档管理規範

1. 新系統的培訓要求：

（1）對所有的用戶和技術人員提供關于新系統功能和操作方面的培訓。必須保證所有的技術和業務用戶接受足夠的關于新系統或者系統改進的培訓。

（2）培訓同樣應包括安全性方面的培訓。

2. 撰寫新系統和系統改進的文檔：

（1）新系統和系統改進都必須有充分的最新的文檔支持。

（2）必須保證新系統和系統改進有詳實的文檔。

3. 項目組應將整理後的文檔交由單位存檔。

6 系统交付管理規範

1. 服務質量要求：

（1）開發方必須依據合同或獨立的服務協議中的關鍵指標提供服務；

（2）在服務提供期間，單位信息系統項目管理部門或人員應經常對開發方的人員資質進行確認，保證服務期間服務人員的穩定性；

（3）制定對開發方服務的評價指標和測量體系，以確保開發方服務提供的質量。

2. 服務的改進：

（1）開發方在服務提供過程中，發現與服務的需求有較大差距時，雙方必須對服務進行評估，如果是未達到服務合同或服務協議的要求，則責成開發方對服務進行改進；

（2）如果開發方服務達到合同或服務協議的要求，但是還不能滿足服務的實際需求，則雙方可以協商對合同或服務協議進行變更，提高關鍵指標以適應服務的實際需求。

7 系统验收与试运行安全規範

1. 安全性測試：

應制定研發、試運行與驗收等過程中的安全測試與驗收大綱，在項目實施完成後，由單位及開發人員共同組織測試小組進行測試。在測試大綱中應至少包括以下安全性測試和評估要求：

（1）配置管理：建議使用配置管理系統，並提供配置管理文檔；

（2）交付程序：應將把系統及其部分交付給用戶的程序文檔化；

（3）安全功能測試：對系統的安全功能進行測試，以保證其符合詳細設計並對詳細設計進行檢查，保證其符合概要設計以及總體安全方案；

（4）系統管理員指南：應提供如何安全地管理系統和如何高效地利用系統安全功能的優點和保護功能等詳細准確的信息；

（5）系統用戶指南：必須包含兩方面的內容：首先，必須解釋那些用戶可見的安全功能的用途以及如何使用它們，這樣用戶可以持續有效地保護他們的信息；其次，必須解釋在維護系統的安全時用戶所能起的作用；

（6）安全功能強度評估：功能強度分析應說明安全機制（如口令字或哈希函數）實現的系統安全功能強度。

（7）脆弱性分析：應對新系統進行脆弱性測試，包括工具或人工測試。

測試完成後，測試小組應提交測試報告，其中應包括安全性測試和評估的結果。

2.安全試運行：

試運行階段應有安全措施來維護系統安全，包括但不限于：

（1）監測系統的安全性能，包括事故報告；

（2）進行用戶安全培訓，並對培訓進行總結；

（3）監測新發現的對系統安全的攻擊、系統所受威脅的變化以及其它與安全風險有關的因素；

（4）監測系統的備份支持，支持與系統安全有關的維護培訓；

（5）評估系統改動對安全造成的影響；

（6）監測系統物理和功能配置。

在試運行情況報告中應對上述工作做總結性描述。

3. 系統驗收：

系統試運行過程結束後，可以由單位與開發單位相關人員對項目進行驗收，驗收應包括以下內容：

（1）項目是否已達到項目任務書中制定的總體安全目標和安全指標，實現全部安全功能；

（2）采用技术是否符合国家、行业有关安全技术标准及規範。

（3）是否實現驗收測評的安全性測試。

（4）项目实施过程中的各种文档资料是否規範、齐全。

（5）應由安全管理員對驗收在安全性方面進行評價。

4. 投入運行後的監控與跟蹤，項目投入運行後還應進行一段時間的監控和跟蹤，系統的管理人員負責監控和跟蹤工作，具體應包括以下要求：

（1）應對系統關鍵安全性能的變化情況進行監控，了解其變化的原因；

（2）對系統安全事故的發生、應急、處理、恢複、總結進行全程跟蹤，並有詳細的記錄；

（3）對新發現的對系統安全的攻擊進行監控，記錄其發生的頻率以及對系統的影響；

（4）監控系統所受威脅的變化，評估其發生的可能性以及可能造成的影響；

（5）監控並跟蹤系統相關的備份情況；

（6）監控運行程序的變化，並記錄其對系統安全的影響；

（7）監控系統物理環境的變化情況，並記錄這些變化對系統安全的影響；

（8）監控安全配置的變化，並記錄其對系統安全的影響。

三 自行軟件開發

1 申报

本階段主要是項目審批單位對項目申報內容進行審批，對項目進行安全性論證，必要時可以聘請外單位的專家參與論證工作。

2 安全性论证和审批

安全性論證應著重對項目的安全需求分析、安全對策以及總體安全方案進行成本-效益、合理性、可行性和有效性分析，並在《信息化項目立項審批表》上給出明確的結論：

（1）適當

（2）不合適（否決）

（3）需作複議

3 複議

對論證結論爲“需作複議”的项目，通知申报单位对有关内容进行必要的补充或者修改后，再次提交复审。

4 项目安全立项

審批後，項目審批單位將對項目進行立項，在《信息系統項目任務書》的以下條目中應增加相應的計算機安全方面的內容：

（1）項目的管理模式、組織結構和責任：增加項目建設中的安全管理模式、安全組織結構以及五、人員的安全職責；

（2）項目實施的基本程序和相應的管理要求：增加項目建設實施中的安全操作程序和相應安全管理要求；

（3）項目設計目標、主要內容和關鍵技術：增加總體安全目標、安全對策以及用于實現安全對策的總體安全方案；

（4）項目實現功能和性能指標：增加描述系統擁有的具體安全功能以及安全功能的強度；

（5）項目驗收考核指標：增加安全性測試和考核指標。

立項的項目，如采用引進、合作開發或者外包開發等形式，則需與第三方簽訂安全保密協議

5 项目管理

5.1 概要 

5.1.1 目的

为了規範项目的文档管理工作，特制定本規範。  

5.1.2 范围

本規範仅适用与项目的文档管理工作。  

5.1.3 编制及修订

本規範由项目实施小组负责编制及修订。  

5.1.4 发布

本規範由保密科负责发布，发布后项目组成员可通过OA系統查閱。

5.2 正文

5.2.1 文档架构的构成

項目的文檔（下簡稱文檔）將由電子版本和紙介質共同組成，二者必須一致（應用系統源代碼只以電子文檔形式提交）。  

文檔按項目啓動、項目計劃、項目執行與控制、項目收尾四個階段進行管理，對于這四個階段的文檔分類簡寫分別爲：項目啓動（PS）、項目計劃（PP）、項目執行與控制（PE）、項目收尾（PC）。

5.2.2 文档编码规则

 

5.2.3 文檔管理職責

項目文檔由項目實施小組負責管理，信息資料科派出一位同事兼任項目文檔管理員。

項目小組的成員應按要求及時將審定過的文檔交付給項目文檔管理員，項目文檔管理員應該及時對文檔編碼並歸檔。

項目文檔管理員負責項目文檔的管理，及時更新項目文檔目錄。

項目文檔管理員每周對歸檔或變更的文檔出一份簡報呈交實施組組長和保密科科長。

5.2.4 文檔架構的變更

文檔體系的結構需要變更時，需經以下的程序才能執行：

項目組成員提出申請、實施組組長批准、保密科科長批准、項目文檔管理員變更。

5.2.5 文檔的授權  

經項目文檔管理員發布的文檔默認爲全體項目組成員有讀取權限，需要特殊指定權限的文檔由項目組成員交付文檔時特別說明。

四 外包軟件管理制度

1 组织职责

甲方職責

世界杯官网(以下稱“甲方”)一般爲外包項目管理部門，其主要職責是：

（1）負責爲外包項目指派甲方項目負責人作爲甲方的代表參與外包項目的管理、技術審核和協調工作，必要時成立甲方工作組；

（2）负责对乙方的管理体系进行审定，并确定乙方项目组使用的管理标准。如乙方已通过ISO9000、CMM或CMMI等标准，经审核同意后，项目可以按照乙方的管理規範实施；如果审核未通过，则需要按照甲方的管理規範、流程执行，并对相关文档模版进行裁剪后，提供乙方项目组使用，必要时为乙方项目组提供管理相关的培训。

乙方職責

（1）負責對外包開發進行管理，成立項目組，並指派乙方項目負責人代表乙方與甲方溝通，負責乙方的項目管理工作。

（2）乙方项目组使用的技术規範、文档标准、管理过程应符合合同规定的要求，或符合甲乙双方达成的一致要求。

（3）乙方應履行合同中規定的其它條款要求，如知識産權、保密、技術支持和産品售後維護等，這些要求應在合同中明確。

（4）按計劃向甲方交付相關工作産品和文檔，並按合同要求提供後期的服務和維護工作。

2 外包开发人员管理

（1）人員登記：外包開發人員進入學校進行項目實施的，乙方項目負責人應填寫《外包軟件開發人員登記表》,並提交甲方項目負責人，同時乙方應遵守甲方相關規章制度和管理條例。

（2）資源申請：乙方項目負責人對于乙方在甲方開發工作期間需要使用的資源須填寫《資源使用申請表》並提交甲方項目負責人,其中資源包括設備、網絡、開發環境等。

（3）資源分配：甲方項目負責人對于乙方的資源申請進行審核確認,並負責協調解決。乙方在獲取資源後專人專用並不得隨意借用于他人。

（4）實行考勤制度，乙方人員在學校項目開發期間必須遵守學校的作息制度。

（5）外包開發人員應遵守學校開發環境管理相關規定，不能隨意更改網絡配置，一台設備不能同時連接外網和內網。如果由于乙方外包開發人員不遵守學校規定造成的損失,甲方有權要求乙方賠償。

3 进度管理

（1）甲方項目負責人應要求乙方項目負責人按季度提供外包開發實施計劃

（2）甲方項目負責人應要求乙方項目負責人每周編制工作周報,總結本周工作情況和計劃下周工作,並反饋工作中遇到的問題。

（3）對于開發中遇到的問題,甲方項目負責人和乙方項目負責人應根據各自職責協調解決。

（4）甲方項目負責人應對乙方開發工作進行檢查和監督。

4 文档管理

如果外包開發在甲方現場實施,則乙方必須遵守學校的文档管理規範，使用學校統一的版本管理工具，並及時更新。甲方項目負責人負責監督，且驗收時以文檔管理工具上的內容爲准。

5 知識轉移

（1）在外包開發結束之後或開發過程中,乙方負責將開發相關文檔和産品提交給甲方項目負責人,甲方項目負責人填寫《開發成果交接登記表》。

（2）乙方有義務制定培訓計劃，並提交培訓計劃至甲方項目負責人,甲方項目負責人在培訓實施過程中填寫《項目培訓記錄表》。

6 代码检查

甲方項目負責人依據相關開發代碼檢查規則對外包軟件關鍵代碼進行惡意代碼和後門檢查。

五 附則

對違反本制度的人員，將按照世界杯官网有關規定進行處罰。

本制度由信息安全工作小組負責制定、解釋和修改。

本制度自發布之日起執行。

世界杯官网信息安全工作小組

2020年10月18日