《樓宇自控系統(tǒng)安全技術(shù)要求》團體標準

編制說明

一、工作簡況

（一）任務(wù)來源

隨著信息技術(shù)的飛速發(fā)展和城市化進程的加快，樓宇自控系統(tǒng)作為

智慧城市建設(shè)的重要組成部分，其重要性與日俱增。樓宇自控系統(tǒng)通過

集成多種智能設(shè)備和技術(shù)，實現(xiàn)了對建筑物內(nèi)部環(huán)境、設(shè)備設(shè)施及能源

使用的全面監(jiān)控與管理，極大地提高了建筑運行效率和居住舒適度。然

而，隨著系統(tǒng)復(fù)雜性的增加，其問題也日益凸顯，首先，不同廠商之間

的設(shè)備通信協(xié)議不統(tǒng)一，系統(tǒng)集成時需要大量的定制開發(fā)工作，增加了

開發(fā)成本和時間。其次，現(xiàn)有系統(tǒng)多側(cè)重于設(shè)備的自動化控制，但在智

能調(diào)節(jié)、預(yù)測性維護等高級功能方面仍有待提升。最后，系統(tǒng)的通信協(xié)

議、設(shè)備接口等存在安全漏洞，容易受到黑客攻擊和病毒侵害；數(shù)據(jù)安

全保護措施不完善，可能導(dǎo)致數(shù)據(jù)泄露和損壞。

因此，制定樓宇自控系統(tǒng)安全技術(shù)要求的團體標準具有重要意義。

一是通過標準化工作，推動設(shè)備通信協(xié)議的統(tǒng)一和互操作性的提升，降

低系統(tǒng)集成難度和成本。二是明確系統(tǒng)智能化功能的要求，推動新技術(shù)

在樓宇自控系統(tǒng)中的應(yīng)用，提升系統(tǒng)的智能化水平。三是對系統(tǒng)的安全

性能進行詳細規(guī)定，包括系統(tǒng)架構(gòu)安全、數(shù)據(jù)安全、設(shè)備安全、應(yīng)用安

全以及安全監(jiān)測與防護等方面，確保系統(tǒng)的安全穩(wěn)定運行。

（二）編制過程

為使本標準在樓宇自控系統(tǒng)安全技術(shù)市場管理工作中起到規(guī)范信息

化管理作用，標準起草工作組力求科學(xué)性、可操作性，以科學(xué)、謹慎的

態(tài)度，在對我國現(xiàn)有樓宇自控系統(tǒng)安全技術(shù)市場相關(guān)管理服務(wù)體系文件、

—1—

模式基礎(chǔ)上，經(jīng)過綜合分析、充分驗證資料、反復(fù)討論研究和修改，最

終確定了本標準的主要內(nèi)容。

標準起草工作組在標準起草期間主要開展工作情況如下：

1、項目立項及理論研究階段

標準起草組成立伊始就對國內(nèi)外樓宇自控系統(tǒng)安全技術(shù)相關(guān)情況進

行了深入的調(diào)查研究，同時廣泛搜集相關(guān)標準和國外技術(shù)資料，進行了

大量的研究分析、資料查證工作，確定了樓宇自控系統(tǒng)安全技術(shù)市場標

準化管理中現(xiàn)存問題，結(jié)合現(xiàn)有產(chǎn)品實際應(yīng)用經(jīng)驗，為標準起草奠定了

基礎(chǔ)。

標準起草組進一步研究了樓宇自控系統(tǒng)安全技術(shù)需要具備的特殊條

件，明確了技術(shù)要求和指標，為標準的具體起草指明了方向。

2、標準起草階段

在理論研究基礎(chǔ)上，起草組在標準編制過程中充分借鑒已有的理論

研究和實踐成果，基于我國市場行情，經(jīng)過數(shù)次修訂，形成了《樓宇自

控系統(tǒng)安全技術(shù)要求》標準草案。

3、標準征求意見階段

形成標準草案之后，起草組召開了多次專家研討會，從標準框架、

標準起草等角度廣泛征求多方意見，從理論完善和實踐應(yīng)用多方面提升

標準的適用性和實用性。經(jīng)過理論研究和方法驗證，起草組形成了《樓

宇自控系統(tǒng)安全技術(shù)要求》（征求意見稿）。

（三）主要起草單位及起草人所做的工作

1、主要起草單位

協(xié)會、企業(yè)等多家單位的專家成立了規(guī)范起草小組，開展標準的編

制工作。

—2—

經(jīng)工作組的不懈努力，在2024年8月，完成了標準征求意見稿的編

寫工作。

2、起草人所做工作

廣泛收集相關(guān)資料。在廣泛調(diào)研、查閱和研究國際標準、國家標準、

行業(yè)標準的基礎(chǔ)之上，形成本標準草案稿。

二、標準編制原則和主要內(nèi)容

（一）標準編制原則

本標準依據(jù)相關(guān)行業(yè)標準，標準編制遵循“前瞻性、實用性、統(tǒng)一性、

規(guī)范性”的原則，注重標準的可操作性，本標準嚴格按照《標準化工作指

南》和GB/T1.1《標準化工作導(dǎo)則第一部分：標準的結(jié)構(gòu)和編寫》的要

求進行編制。標準文本的編排采用中國標準編寫模板TCS2009版進行

排版，確保標準文本的規(guī)范性。

（二）標準主要技術(shù)內(nèi)容

本標準報批稿包括7個部分，主要內(nèi)容如下：

1范圍

本文件規(guī)定了樓宇自控系統(tǒng)安全技術(shù)的術(shù)語和定義、系統(tǒng)總體架構(gòu)、

平臺層安全要求、傳輸層安全要求、感知層安全要求。

本文件適用于樓宇自控系統(tǒng)的設(shè)計、建設(shè)、運維等。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的

條款。其中，注日期的引用文件，僅該日期對應(yīng)的版本適用于本文件；

不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。

GB/T35273信息安全技術(shù)個人信息安全規(guī)范

GB/T37044信息安全技術(shù)物聯(lián)網(wǎng)安全參考模型及通用要求

—3—

GM/T0026安全認證網(wǎng)關(guān)產(chǎn)品規(guī)范

3術(shù)語和定義

下列術(shù)語和定義適用于本文件。

密鑰key

一種用于控制密碼變換操作（例如加密、解密、密碼校驗函數(shù)計算、

簽名生成或簽名驗證）的符號序列。

4系統(tǒng)總體架構(gòu)

系統(tǒng)架構(gòu)

4.1.1樓宇自控系統(tǒng)架構(gòu)如圖1。

圖1樓宇自控系統(tǒng)架構(gòu)

4.1.2樓宇自控系統(tǒng)架構(gòu)應(yīng)包括以下內(nèi)容：

——樓宇自控系統(tǒng)應(yīng)包括平臺層、傳輸層以及感知層三部分；

——平臺層安全面向智能終端設(shè)備提供服務(wù)，如設(shè)備注冊、數(shù)據(jù)采集、

數(shù)據(jù)監(jiān)控、安全服務(wù)等；

—4—

——傳輸層安全提供網(wǎng)絡(luò)連接功能，智能終端設(shè)備通過通信層，實現(xiàn)

發(fā)現(xiàn)、組網(wǎng)、控制等操作，并可連接到平臺層，實現(xiàn)平臺對智能

終端設(shè)備的注冊、管理、控制等；

——感知層安全應(yīng)包括智能終端設(shè)備、網(wǎng)關(guān)設(shè)備、人機交互終端設(shè)備

等。

安全體系架構(gòu)

4.2.1樓宇自控系統(tǒng)安全體系架構(gòu)如圖2。

圖2樓宇自控系統(tǒng)安全體系架構(gòu)

4.2.2樓宇自控系統(tǒng)安全體系架構(gòu)應(yīng)包括以下內(nèi)容：

——應(yīng)由平臺層安全、傳輸層安全以及感知層安全三部分構(gòu)成；

—5—

——平臺安全應(yīng)分為網(wǎng)絡(luò)安全和業(yè)務(wù)安全，網(wǎng)絡(luò)安全以等級三級為基

礎(chǔ)，增加訪問控制和入侵防護兩個方面；

——傳輸安全應(yīng)包括安全認證、加密傳輸、會話管理、網(wǎng)絡(luò)防御等方

面；

——感知安全應(yīng)分為分級安全部分和通用安全部分，安全要求應(yīng)符合

GB/T37044的相關(guān)規(guī)定。

5平臺層安全要求

網(wǎng)絡(luò)安全

5.1.1物理環(huán)境

應(yīng)通過云主機管理器實現(xiàn)同一物理機上不同云主機之間相互隔離，

用戶僅能訪問屬于自己的云主機資源，保證云主機不受周邊云主機的影

響，避免云主機之間發(fā)生惡意攻擊或數(shù)據(jù)竊取等情況。

5.1.2存儲安全

應(yīng)通過虛擬化層實現(xiàn)云主機間存儲訪問隔離，隔離用戶數(shù)據(jù)，

防止惡意云主機用戶盜取其他用戶的數(shù)據(jù)，保證數(shù)據(jù)安全。

數(shù)據(jù)存儲宜采用多重備份機制，每一份數(shù)據(jù)都可有一個或者多

個備份，以防存儲設(shè)備（如硬盤）出現(xiàn)故障引起數(shù)據(jù)丟失或影響系統(tǒng)正

常使用。

5.1.3入侵保護安全

應(yīng)通過網(wǎng)絡(luò)平面隔離和防火墻，控制和審計云主機的網(wǎng)絡(luò)流量，

保證內(nèi)部網(wǎng)絡(luò)傳輸安全。

Web應(yīng)用防火墻宜采用黑、白名單機制相結(jié)合的完整防護體

系，通過精細的配置將多種Web安全檢測方法連結(jié)成一套完整的解決方

案，并整合成熟的DDos攻擊抵御機制，能夠在Web環(huán)境中抵御各類

—6—

Web安全威脅和拒絕服務(wù)攻擊，攔截如Web漏洞攻擊，SQL注入、XSS

跨站、獲取敏感信息等常見的攻擊行為。

5.1.4數(shù)據(jù)安全

數(shù)據(jù)安全應(yīng)包括下列內(nèi)容：

——數(shù)據(jù)傳輸過程中應(yīng)對用戶的數(shù)據(jù)進行加密，保證在數(shù)據(jù)傳輸過程

中數(shù)據(jù)不會泄漏，防止數(shù)據(jù)的交叉泄漏和非法訪問；

——密鑰管理員應(yīng)通過API或控制臺進行主密鑰的產(chǎn)生與管理操作，

還可通過訪問控制為密鑰實現(xiàn)訪問控制功能，直接通過使用API

進行少量數(shù)據(jù)的加解密。還可通過信封加密技術(shù)實現(xiàn)大量數(shù)據(jù)的

本地加解密；

——對所有信息系統(tǒng)的日志和權(quán)限審批記錄均應(yīng)采用碎片化分布式離

散存儲技術(shù)進行長期保存，對用戶的操作行為進行日志監(jiān)控；

——用戶云服務(wù)期滿后，設(shè)備管理平臺應(yīng)自動消除原有服務(wù)器上磁盤

和內(nèi)存數(shù)據(jù)，使得原用戶數(shù)據(jù)無法恢復(fù)，保證對用戶退庫后的設(shè)

備進行完全的數(shù)據(jù)銷毀。

業(yè)務(wù)安全

5.2.1用戶注冊、登錄和注銷

用戶賬號的相關(guān)過程應(yīng)符合下列要求：

——應(yīng)對用戶注冊的過程進行有效保護；

——應(yīng)對用戶注冊或登錄涉及的用戶密碼，進行加密處理后才能傳輸；

——應(yīng)有效防止用戶登錄、密碼重置、忘記密碼等流程進行密碼暴力

破解；

——應(yīng)對所有請求參數(shù)進行有效校驗，保證會話的完整性；

—7—

——應(yīng)保證用戶注銷賬號的權(quán)利，確保用戶數(shù)據(jù)能夠完整和安全地刪

除。

5.2.2設(shè)備入網(wǎng)認證和用戶綁定

設(shè)備入網(wǎng)認證和用戶綁定應(yīng)符合下列要求：

——應(yīng)對設(shè)備的身份進行有效驗證，需要保證平臺內(nèi)設(shè)備的身份信息

唯一，不應(yīng)預(yù)測，并擁有足夠的長度和復(fù)雜度；

——應(yīng)保證用戶綁定設(shè)備的過程安全可靠，確保用戶和設(shè)備身份準確。

5.2.3用戶和設(shè)備身份鑒權(quán)

設(shè)備交互過程，包含了APP與云端交互，以及云端與設(shè)備交互，平

臺的服務(wù)包括設(shè)備的鑒權(quán)，用戶鑒權(quán)，設(shè)備控制和狀態(tài)的上報。交互過

程的身份鑒權(quán)應(yīng)符合下列要求：

——應(yīng)對設(shè)備的身份憑證進行有效驗證，不應(yīng)直接使用設(shè)備ID等身

份索引標識符號直接作為交互的憑證；

——應(yīng)對用戶的身份憑證進行有效驗證，不應(yīng)直接使用用戶ID等身

份索引標識符號直接作為交互的憑證；

——應(yīng)對用戶和設(shè)備的綁定關(guān)系進行嚴格的校驗，防止用戶和非其綁

定關(guān)系的設(shè)備進行交互。

5.2.4固件升級

固件升級應(yīng)符合下列要求：

——應(yīng)保證在固件升級下發(fā)固件信息的完整性和準確性；

——應(yīng)保證固件的完整性和不應(yīng)抵賴性，對固件進行安全有效的算法

驗證；

——應(yīng)能夠在下發(fā)固件的時候，同時下發(fā)固件的校驗值，宜使用SM3

等算法。

—8—

5.2.5日志審計

日志審計應(yīng)符合下列要求：

——應(yīng)審計用戶的所有操作時間，包括事件的日期、時間、類型、設(shè)

備標識和結(jié)果，對不正常的事件，如頻繁大量或不符合的業(yè)務(wù)參

數(shù)進行有效記錄和告警；

——應(yīng)審計設(shè)備的異常狀態(tài)，包括系統(tǒng)資源的使用情況，設(shè)備狀態(tài)的

頻繁變化等，進行有效的記錄和告警；

——應(yīng)保護審計記錄，保證無法刪除、修改或覆蓋等；

——應(yīng)保證日志存儲時間滿足《中華人民共和國網(wǎng)絡(luò)安全法》等相關(guān)

法律法規(guī)的規(guī)定和要求。

5.2.6用戶信息保護

平臺應(yīng)滿足GB/T35273中的個人信息安全的有關(guān)規(guī)定。

6傳輸層安全要求

安全認證要求

6.1.1集成平臺要求

應(yīng)支持標準的認證授權(quán)機制，提供認證授權(quán)網(wǎng)關(guān)的服務(wù)或模塊

供各子系統(tǒng)平臺使用，達到單點登錄和用戶權(quán)限統(tǒng)一維護的效果，各子

系統(tǒng)平臺應(yīng)能將自己的認證和授權(quán)部分接入集成平臺由集成平臺統(tǒng)一管

理，也可脫離集成平臺獨立運行。

集成平臺和子系統(tǒng)平臺在直接進行物聯(lián)網(wǎng)設(shè)備接入時應(yīng)實現(xiàn)

設(shè)備的認證和授權(quán)機制，做到只有已知的設(shè)備才能接入平臺，避免非法

設(shè)備隨意接入平臺對系統(tǒng)的正常運行產(chǎn)生影響。

6.1.2認證機制

—9—

認證機制中應(yīng)避免使用一些終端依賴的機制，對于設(shè)備的接入，應(yīng)

采用基于非對稱秘鑰機制進行身份認證。

6.1.3授權(quán)機制

授權(quán)機制應(yīng)根據(jù)不同的客體采用不同的機制，支持基于角色的細粒

度訪問控制（RBAC）。平臺在集成各子系統(tǒng)平臺時除提供單點登錄的

方案外，還應(yīng)支持標準的授權(quán)機制。

安全接入要求

6.2.1對于保密性一般的數(shù)據(jù)接入，如封閉的內(nèi)網(wǎng)環(huán)境，平臺應(yīng)對內(nèi)網(wǎng)

提供HTTP的API。

6.2.2對于保密性高的數(shù)據(jù)接入，平臺應(yīng)對外僅提供HTTPS的API，

不應(yīng)對外提供HTTP的API；終端應(yīng)用程序?qū)訒r不應(yīng)忽略證書錯誤。

6.2.3對于保密性極高的數(shù)據(jù)接入，平臺應(yīng)對外僅提供HTTPS的API，

不應(yīng)對外提供HTTP的API；TLS版本應(yīng)大于等于1.2，終端應(yīng)用程序?qū)?/p>

接時不應(yīng)忽略證書錯誤，終端應(yīng)用程序應(yīng)實現(xiàn)證書鎖定（SSL/TLS

Pining）。

6.2.4平臺應(yīng)能夠攔截未經(jīng)授權(quán)的訪問，為每個受信的終端應(yīng)用程序頒

發(fā)終端唯一標識、終端秘鑰。終端唯一標識可對外公開，終端秘鑰不應(yīng)

對外公開。

6.2.5終端應(yīng)用程序調(diào)用平臺提供的API時，平臺應(yīng)能夠驗證認證信

息，能夠防止重放攻擊，并能夠驗證請求的內(nèi)容未經(jīng)篡改。

6.2.6平臺應(yīng)實現(xiàn)僅允許受信的終端應(yīng)用程序調(diào)用其有權(quán)訪問的API，

對超出訪問權(quán)限的調(diào)用進行攔截。在平臺中，每個受信的終端應(yīng)用程序

應(yīng)配置有0到多條API訪問規(guī)則，每條訪問規(guī)則應(yīng)確切地描述終端“允

許調(diào)用”系統(tǒng)中的哪一個或那些API，以及允許調(diào)用的頻次等，或者是描

—10—

述終端“不應(yīng)調(diào)用”系統(tǒng)中的哪一個或那些API。

7感知層安全要求

安全分級原則

樓宇設(shè)備依據(jù)自身在身份認證、硬件、操作系統(tǒng)、固件等安全能力，

依次劃分三個安全等級，安全能力從低到高分別為：Leve11、Leve12、

Leve13，以滿足不同應(yīng)用場景的安全需求。本文件依次對不同安全等級

的樓宇設(shè)備提出安全需求，樓宇設(shè)備應(yīng)滿足Leve11中的全部安全要求，

Level2至Leve13為宜滿足的可選安全要求，并應(yīng)符合下列規(guī)定：

——Level1級樓宇設(shè)備應(yīng)在使用密鑰時可以進行軟件級隔離并保障一

定的安全性并可抵抗大規(guī)模軟件攻擊，應(yīng)支持如軟件沙箱、白盒

加密等技術(shù)；

——Leve12級樓宇設(shè)備應(yīng)在使用密鑰時可以進行邏輯級隔離并可以

抵御大規(guī)模軟件攻擊、可在操作系統(tǒng)層被攻破的情況下仍然保障

密鑰的安全性，應(yīng)支持如可信執(zhí)行環(huán)境、安全MCU芯片等技術(shù)；

——Leve13級樓宇設(shè)備應(yīng)支持物理隔離安全性、芯片級防篡改保護機

制并具備可抵御芯片級攻擊能力，可在物理設(shè)備層被攻破的情況

下仍然保障密鑰的安全性，應(yīng)支持安全芯片或同等安全能力的安

全單元。

應(yīng)用程序安全要求

7.2.1應(yīng)用程序內(nèi)部存儲要求

內(nèi)部存儲應(yīng)符合下列要求：

——系統(tǒng)私有目錄本地部分存放的配置文件等信息，通過安全的加密

方式保存，包括嚴格的讀寫執(zhí)行權(quán)限設(shè)置；

——系統(tǒng)數(shù)據(jù)庫不應(yīng)存儲用戶相關(guān)的敏感信息；

—11—

——在設(shè)備本地不存儲所有樓宇設(shè)備的令牌等涉及設(shè)備安全的信息；

——在未授權(quán)拿到令牌之前，應(yīng)用程序不應(yīng)主動獲取樓宇設(shè)備的信息；

——應(yīng)用程序系統(tǒng)配置文件不應(yīng)出現(xiàn)敏感信息。

7.2.2應(yīng)用系統(tǒng)日志要求

系統(tǒng)日志應(yīng)符合下列要求：

——應(yīng)用程序系統(tǒng)不應(yīng)打印和存放任何交互日志文件；

——應(yīng)用程序系統(tǒng)不應(yīng)打印和存放任何從樓宇設(shè)備獲取的信息的日志

文件。

7.2.3應(yīng)用代碼安全要求

代碼安全應(yīng)符合下列要求：

——簽名應(yīng)校驗客戶端完整性；

——對核心業(yè)務(wù)代碼應(yīng)進行混淆；

——應(yīng)具備反調(diào)試功能；

——應(yīng)用程序禁止存在病毒、木馬、惡意腳本/代碼，以及發(fā)送惡意廣

告、吸費、惡意消耗流量的行為；

——軟件安裝包應(yīng)進行完整性保護并確保完整性校驗流程安全可靠；

——應(yīng)用程序執(zhí)行從文件中讀取的命令或調(diào)用外部腳本時要嚴格限制

該文件的腳本的修改權(quán)限，防止注入攻擊；

——應(yīng)用程序應(yīng)設(shè)置對外交互組件的訪問權(quán)限；

——應(yīng)對涉及現(xiàn)實或虛擬貨幣應(yīng)用的口令輸入框?qū)崿F(xiàn)安全輸入機制；

——涉及現(xiàn)實或虛擬貨幣的應(yīng)用應(yīng)實現(xiàn)root檢測及風(fēng)險控制；

——應(yīng)用程序不應(yīng)緩存敏感信息；

——應(yīng)用程序只申請業(yè)務(wù)必要的權(quán)限；

——應(yīng)用程序應(yīng)實現(xiàn)自動檢測更新機制；

—12—

——應(yīng)用的保持登錄選項，應(yīng)能夠讓用戶自主選擇和取消；

——應(yīng)對涉及現(xiàn)實或虛擬貨幣操作的應(yīng)用提供會話保護機制；

——應(yīng)對涉及現(xiàn)實或虛擬貨幣交易操作提供重認證；

——對于每一個需要授權(quán)訪問的Web請求，應(yīng)核實用戶的會話標識是

否合法、用戶是否被授權(quán)執(zhí)行這個操作；

——對Web用戶的最終認證處理過程應(yīng)放到服務(wù)器進行；

——在Web服務(wù)器端對所有來自不可信數(shù)據(jù)源的數(shù)據(jù)進行校驗，拒絕

任何沒有通過校驗的數(shù)據(jù)。若輸出到Web客戶端的數(shù)據(jù)來自不可

信的數(shù)據(jù)源，則應(yīng)對該數(shù)據(jù)進行相應(yīng)的編碼或轉(zhuǎn)義；

——Web應(yīng)用程序的會話標識應(yīng)具備隨機性、唯一性，身份驗證成功

后，應(yīng)更換會話標識；

——通過Web上傳文件時，應(yīng)在服務(wù)器端采用白名單方式對上傳到

Web內(nèi)容目錄下的文件類型進行嚴格的限制。

密鑰安全要求

加解密部件涉及密鑰安全的安全性應(yīng)符合GM/T0026的規(guī)定。

加解密部件的功能要求

7.4.1加解密部件應(yīng)包括對網(wǎng)絡(luò)數(shù)據(jù)信息的加密和解密兩個部分，即將

網(wǎng)絡(luò)數(shù)據(jù)從明文數(shù)據(jù)加密為密文數(shù)據(jù)或從密文數(shù)據(jù)解密為明文數(shù)據(jù)，加

解密部件可根