充換電基礎設施綜合監(jiān)管服務平臺接入規(guī)范

充換電基礎設施綜合監(jiān)管服務平臺接入規(guī)范1范圍本標準規(guī)定了充換電基礎設施綜合監(jiān)管服務平臺接入要求、功能要求、資源共享和數(shù)據(jù)交換要求、部署要求、安全性要求。本標準適用于省、市、縣（區(qū)域）監(jiān)管單位及各級充換電基礎設施運營商開展省充換電基礎設施綜合監(jiān)管服務平臺的接入工作。2規(guī)范性引用文件下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅所注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。GB/T15629.3信息技術系統(tǒng)間遠程通信和信息交換局域網和城域網GB15629.11信息技術系統(tǒng)間遠程通信和信息交換局域網和城域網特定要求第11部分:無線局域網媒體訪問控制和物理層規(guī)范GB/T44130.1-2024電動汽車充換電服務信息交換ISO/IEC11801-2010信息技術用戶基礎設施結構化布線GB17859-1999計算機信息系統(tǒng)安全保護等級劃分準則GB/T22240-2020信息安全技術網絡安全等級保護定級指南GB/T22239-2019信息安全技術網絡安全等級保護基本要求GB/T21062.3政務信息資源交換體系第3部分:數(shù)據(jù)接口規(guī)范GB/T21063.3政務信息資源目錄體系第3部分:核心元數(shù)據(jù)GB/T21063.4政務信息資源目錄體系第4部分:政務信息資源分類GB/T28827.1信息技術服務運行維護第1部分:通用要求GB/T28827.2信息技術服務運行維護第2部分:交付規(guī)范GB/T28827.3信息技術服務運行維護第3部分:應急響應規(guī)范GB/T32960.3電動汽車遠程服務與管理系統(tǒng)技術規(guī)范第3部分：通信協(xié)議及數(shù)據(jù)格式GB/T19596電動汽車術語GB/T29317—2021電動汽車充換電設施術語3術語和定義GB/T19596、GB/T29317中確立的以及下列術語和定義適用于本文件。3.1電動汽車使用者EVdriver通過電動汽車充換電基礎設施進行能量補充服務的用戶。3.2電動汽車充換電服務EVchargingservice運營商提供電動汽車使用者的，包括通過身份識別認證，站點導航，充換電，支付結算的整個過程。3.3電動汽車充換電服務運營商EVchargingandbatteryswapserviceoperator為電動汽車用戶提供充換電服務的提供者。簡稱充換電服務運營商。3.4充換電基礎設施綜合服務平臺由政府行業(yè)主管單位授權的運營組織或由新能源汽車充換電設施運營商建設的，應用智慧監(jiān)管、物聯(lián)網、車聯(lián)網等技術的新能源汽車充換電基礎設施綜合監(jiān)管服務信息系統(tǒng)，在信息化相關技術的支撐下，對新能源汽車充換電基礎設施進行監(jiān)測管理、數(shù)據(jù)采集，向運營商和新能源汽車用戶提供便捷服務，對新能源汽車充換電基礎設施領域內相關信息進行收集、整合、分析并加以有效利用，及時對新能源汽車產業(yè)領域出現(xiàn)的問題或趨向作出反應，有效實施信息化監(jiān)管服務。3.5電動汽車充換電服務平臺運營商EVchargingandbatteryswapserviceplatformoperator為電動汽車充換電服務運營商提供的電動汽車充換電服務平臺服務的專業(yè)平臺運營商，簡稱平臺運營商。4基本要求4.1軟件界面設計開發(fā)應遵循HTML5標準，適應國產瀏覽器。4.2開發(fā)架構應采用B/S架構，前后端分離，模塊化構建方式。4.3應通過統(tǒng)一資源文件實現(xiàn)各項業(yè)務的集成。4.4應保持7*24小時不間斷穩(wěn)定運行。4.5系統(tǒng)訪問及數(shù)據(jù)傳輸過程應加密。5數(shù)據(jù)傳輸與安全5.1數(shù)據(jù)傳輸體系5.1.1數(shù)據(jù)傳輸流程電動汽車充換電服務信息交換應符合GB/T9387.1中關于會話連接的要求，一般需要經過平臺認證、請求和應答3個步驟。5.1.2數(shù)據(jù)傳輸接口所有數(shù)據(jù)傳輸接口均應采用HTTP(S)接口，每個接口的URL均采用如下格式定義：http(s)://[域名]/evcs/v[版本號]/[接口名稱]1.域名：接口提供方平臺域名。2. 版本號：代表接口版本號，不同的版本地址對應相應版本代碼。系統(tǒng)升級期間，新舊版本可同時存在，待所有接入方都切換到新接口，舊版本接口即可下線。從而達到平滑升級的目的。3.接口名稱：所請求/調用接口的名稱，具體接口名稱見T/CEC102.2和T/CEC102.3。為保證各接口的功能明確清晰，每個URL只允許對應一種功能。5.1.3接口調用方式接口均應使用HTTP(S)/POST方式傳輸參數(shù)，采用JSON的方式，傳輸過程中應包含消息頭和消息主體兩部分。數(shù)據(jù)應采用UTF-8編碼，JSON格式。5.2平臺認證要求5.2.1基本要求平臺信息交換應具備平臺認證服務，提供平臺之間的鑒權認證功能。平臺之間在信息交換前，應完成平臺認證，獲得平臺交換能力。省級監(jiān)管平臺、運營商平臺應提供嚴格的系統(tǒng)安全保密機制，保障信息交換接口安全、穩(wěn)定、可靠地運行，包括信息的存取控制、應用系統(tǒng)操作的安全等?；疽螅?.采用身份認證、訪問控制、數(shù)據(jù)加密、數(shù)字簽名等安全措施；2.采用安全可靠并且普遍使用的加密算法；3.密鑰的存貯和交易信息的加密／解密需要在安全的環(huán)境中；4.數(shù)據(jù)安全保密應遵循國家和行業(yè)標準；5.應能定期或應對突發(fā)進行密鑰更新和啟用；6.具備對報文進行來源正確性鑒別的機制（HMAC）。5.2.2認證方式身份認證宜采取用戶名/口令認證、密鑰認證或數(shù)字證書認證等方式；訪問控制可采取IP訪問控制、時間訪問控制等多種結合手段。用戶身份認證成功后授予Token，每次向服務端請求資源時應帶著服務端簽發(fā)的Token，服務端驗證Token成功后，才返回請求的數(shù)據(jù)。Token的有效期由服務方確定，最長不應超過7天，Token丟失或失效后應再次發(fā)起認證服務。6密鑰的管理和使用6.1基本要求各平臺應符合GB/T25070、GB/T20271、GB/T22239中關于數(shù)據(jù)安全傳輸控制要求。各平臺應提供嚴格的系統(tǒng)安全保密機制，保障信息交換接口安全、穩(wěn)定、可靠地運行，包括信息的存取控制、應用系統(tǒng)操作的安全等。密碼算法用于密鑰的產生、分發(fā)、HMAC以及加密等安全功能，相關的算法模塊在其生命周期內不應被修改、導出至安全環(huán)境外部。指定功能的密鑰僅能做指定功能使用，不應被其他任何功能使用。6.2密鑰的分類交互前應分配標識、對接方密鑰、消息密鑰、消息密鑰初始化向量和簽名密鑰。并應符合下列要求：1.唯一標識（PlatformID）:固定9位，對接方的組織機構代碼九位，作為唯一標識。2.密鑰（PlatformSecret）:可采用16H、32H、48H和64H，由0-F字符組成，為申請認證使用。3.消息密鑰（DataSecret）:可采用16H、32H、48H和64H，由0-F字符組成，用于對所有接口中Data信息進行加密。4.消息密鑰初始化向量（DataSecretIV）：固定16位，用戶AES加密過程的混合加密。5.簽名密鑰（SigSecret）:可采用16H、32H、48H和64H，由0-F字符組成，為簽名的加密密鑰。6.3密鑰的管理1.密鑰的產生數(shù)據(jù)密鑰應具備隨機產生特性，密鑰產生后應檢查密鑰的有效性，弱密鑰和半弱密鑰應被剔除。加入信息交換時，必須申請獨立的密鑰文件，密鑰可雙方協(xié)商產生。2.密鑰的分發(fā)密鑰的分發(fā)應由安全方式進行，可通過線下分發(fā)、聯(lián)機報文或數(shù)字信封的方式加密傳輸。3.密鑰的存儲密鑰宜保存在硬件加密機內。如果出現(xiàn)在硬件加密機外，則密鑰應以密文方式出現(xiàn)。密鑰注入、密鑰管理和密鑰檔案的保管應由專人負責。使用密鑰和銷毀密鑰要在監(jiān)督下進行并應有使用、銷毀記錄。4.密鑰的銷毀當新密鑰產生后，生命期結束的舊密鑰應從數(shù)據(jù)庫和內存中清除，防止被替換使用；同時所有可能重新構造此密鑰的信息也應清除。新密鑰成功啟用和舊密鑰自動銷毀的記錄將被更新。6.4密鑰的使用數(shù)據(jù)的加解密處理：消息發(fā)送方應對Data字段中涉及交易及隱私等數(shù)據(jù)利用消息密鑰（DataSecret）進行加密。消息接收方收到消息之后，根據(jù)消息密鑰（DataSecret）對消息體中的Data數(shù)據(jù)進行解密，校驗參數(shù)合法性等后續(xù)業(yè)務處理。參數(shù)簽名規(guī)范：參數(shù)簽名采用HMAC-MD5算法，采用MD5作為散列函數(shù)，通過簽名密鑰（SigSecret）對整個消息主體進行加密，然后采用MD5信息摘要的方式形成新的密文，參數(shù)簽名應大寫。參數(shù)簽名順序按照消息體順序拼接后執(zhí)行，入?yún)⑵唇禹樞驗槲ㄒ粯俗R標