智慧城市公共交通领域的网络安全架构模型介绍

信息安全与通信保密杂志社
编译石建兵
欧洲网络与信息安全局(ENISA)在 2016 年 1 月发布了智慧城市中智能交通的网络安全架构模型,该架构模型分析了网联城市和智慧城市的异同,列举智慧城市面临的网络安全风险和威胁,提供了不少优秀实践,并根据调研情况...

欧洲网络与信息安全局(ENISA)在 2016 年 1 月发布了智慧城市中智能交通的网络安全架构模型,该架构模型分析了网联城市和智慧城市的异同,列举智慧城市面临的网络安全风险和威胁,提供了不少优秀实践,并根据调研情况总结了七项重要发现情况,最后向智慧城市利益干系各方提出八点建议。中国部分地区目前也在大力推动智慧城市项目,但由于各自发展模式和发展路径不同,对于网络安全缺乏总体统括,也缺少经验支撑,本报告提出的网络安全架构模型可以为此提供借鉴。

智慧城市网络安全报告综述

智慧城市是指通过运用信息通信技术(ICT),以动态的方式优化城市功能,为市民提供更好的生活。智慧城市内涵更广,是在“网联城市”概念基础上更普遍化、更广泛的数据交换演化。智能公共交通系统(Intelligent public transport,IPT)是智慧城市的关键要素之一,智能公交运营商应用 ICT 技术来管理本地公共交通,从而提高运输系统的服务水平和效能,运营商之间彼此互相交换数据,以期提供更佳的整合服务。

数据交换整合服务和资产,促进了城市的自动化程度。在这些关键服务互联后,为保护数据交换、隐私以及市民的健康和安全,网络安全的需求激增。当前暂无统一的准则或标准来管控数据交换,导致智能公交运营商、市政部门、政策制定者、生产制造商、供应商及解决方案提供商等无法应对各类不同的需求提供具有高可用性的特定解决方案。目前 IPT 运营商可遵循的网络安全政策或关键资产的制度化和规范屈指可数,此外 IPT 领域的网络安全方面的知识储备和投入也极少。虽然 IPT 运营商也已施用一些网络安全措施,但这类措施种类繁多,但由于网络安全标准并不通用,故与 IPT 的需求并不完全相符,能被普遍接受的最佳实践那就更少了。

这份报告定义了一个高级架构模型可用来理解关键领域所面临的网络威胁,为后续完善网络安全指南奠定基础,但由于城市成熟度水平各异,该架构主要基于 IPT 运营商视角,侧重于智慧城市中利益相干各方的相互作用及集成各自的功能流程和数据交换。IPT 运营商与其他相关方之间的数据交换不可避免地带来网络安全威胁以及潜在的风险。由于城市的成熟度不同,威胁来源多样,不仅只是信息 / 数据、应用和技术等层面,还包括源自组织机构及 IPT 相关的基础设施等因素。在本报告中将特定威胁初步分为两类:故意攻击和意外威胁。

本报告不仅为 IPT 运营商预防故意攻击和意外威胁整理了部分优秀实践,根据调研情况总结出七项重要发现,因此向利益干系各方提出八点建议:

市政部门应支持开发协调一致的网络安全框架;

欧盟委员会及成员国应促成产业、成员国和市政部门之间的网络安全知识交流和合作;

IPT 运营商应清晰定义其安全需求;

IPT 运营商和政府应在网络安全事务方面增加投入;

产品制造商和解决方案供应商应在产品中集成安全性;

IPT 运营商和政府应明确中高层管理人员在网络安全事务中的职责;

欧盟委员会和成员国应明确参与各方职责;

智慧城市和标准化组织应将网络安全需求整合进智慧城市成熟度模型;

智慧城市的网络安全

该研究分别在网联城市(Connected Cities,CCs)和智慧城市(Smart Cities,SCs)的不同概念下分析智能公交(IPT)的网络安全,网联城市和智慧城市均系在多利益相干方的情况下充分利用信通技术,满足公众需求并促进城市发展。网联城市的特点是运营商独立,由自己的控制中心管理一个或多个系统,运营商之间基本独立。而智慧城市则突破网联城市的相关约束,在数据集成方面通过全局决策过程实现任务自动化的管理,目标是以动态方式优化城市功能从而为市民提供更佳的生活质量。城市首先通过信息技术变得“更智能”,同时信息技术应用延伸范围极广,渗透进金融、公共安全、能源、公共交通等各个领域的管理。

网络安全不仅指数据的安全性,还存在于用于存储、处理和传输数据的应用程序和基础设施等方面,通常认为网络安全是预防、检测和响应网络安全事件来保护数据和信息的过程。

范围和目标

研究目标为构建智慧城市中运输领域的架构模型,并向 IPT 运营商介绍优秀的网络安全优秀实践,但这类优秀实践与城市成熟度水平有关,这就使得运营商和市政部门可迅速评估他们是否在网络安全方面落后于其他城市,如果确有差距,本研究提供了一些实用的、可操作的指南,可让这些城市选择采取恰当的行动。

本研究网络安全的研究重点为数据交换方面,因此就特别关注参与各方的相互干系,这些参与方不仅包括 IPT 运营商,还有银行、安全部门和能源供应商等。除此之外,还研究了潜在网络安全事件产生的原因影响、如何控管恢复措施及优秀实践。

目标受众

主要面向四类人群:

公共交通运营商:设计了一个网络安全框架,协助运营商明了其即将面临的网络安全威胁,并为他们控制事态和恢复服务提供指南;

市政部门:了解在智慧城市中公交运营商和其他利益相关者之间如何进行数据交换及互动,可参照城市成熟度的国际基准评估本地网络安全状况并采取对策。

政策制定者:除了解各利益方在数据交换领域如何共同互动,还可让他们更清晰地了解政策如何影响公交运营商的网络安全实践。

网络安全产业:本研究中开发的网络安全框架,可帮助公交运营商的供应商、解决方案提供商以此为基础充分交换意见,从而更好的协同。

智慧城市环境介绍

智慧城市近年来概念较多,尚未有明确定义,本研究经过多方调研认为其概念主要包含两个关键要素:

智 慧 城 市 的 基 本 流 程: 如 广 泛 使 用ICT,或为满足公众需求而应用大数据分析等;

与这些流程相关或赋能的特定领域:如提高移动性或弹性,或克服环境带来的挑战。

不同的人对智慧城市这一概念的认知在两项要素中有明显的侧重点,如厂商或生产制造商通常不太关心网络安全状况;而市政部门则容易陷入畅想未来,而非真切定义。当然 “网联城市”和“智慧城市”这两个概念并无明显界限,两者也常被混用,在改报告中一般使用智慧城市,因为智慧城市是比网联城市外延更广泛,而且关注与数据集成及通盘决策流程的任务自动化。

智能交通一般指的是智能交通系统(ITSs),但和智慧城市一样,它的概念也是定义众多 , 通常与欧盟2010/40/EU 指令中 ITS 定义相似,这类定义都源于 ITS 的技术本质及在技术基础之上的相关活动,在本报告中将此定义做了简化,仅指在运输体系中为提高服务水平和效能而应用 ICT 技术,而且限定于城区范围的载客公共交通。

网络安全的定义一般指网络空间中对计算机系统和信息的保护、事件发生后如何管理恢复过程,但在如下三个方面使得定义略有不同:

保护的要素;

保护所采取的措施;

威胁的本质;

智慧城市中的网络安全是指向支撑城市运营及让生活其中的人们安居乐业产生关键影响的各类基础设施、各种系统及数据的提供防护。

利益相干方

智慧城市中利益相干方主要分为如下四类,如图 1 所示:

(1)本地公交运营商:在城区内提供乘客公共运输服务,如出租车、公交车、有轨 /无轨电车、地铁、轻轨等;

(2)非本地公交运营商:主要是包含提供国际或国内长途等公共运输服务商、货运以及为私人提供服务的运营商三个小类;

(3)非运输运营商:主要指银行、通讯等;

(4)非营运类:主要包括政府、产业联盟、监管部门等。

全部四类利益干系方均面临与日俱增的网络安全威胁,其中一个突出的问题是越来越密集的互联传感器网络,包括各式各样的资源受限设备和它们之间连绵不断的数据流,就给攻击者搜寻脆弱点带来机会。与此同时,被智慧城市运营商大量存储和交换的数据及对系统的访问控制权对攻击者变得更有价值,加上依赖数据和系统的,被敲诈的风险就越大。如智慧城市需要使用云服务来存储地理分布广泛、不同来源的大量数据,一旦不能确保其云环境有足够的安全规范,那它容易遭致敏感数据泄露风险,当前基础设施往往使用内部专网,但在上云后就使维持系统固若金汤变得格外艰难。还有一个问题是攻击智慧城市会有现实风险,譬如操纵交通信号灯所依赖的交通数据将会引发严重事故。除了公交运营商外,其他非运营商实际也与智能交通相关,如政府、监管机构等。在网络安全方面最关键的是计算机安全事件响应小组(CSIRTS)。最后是市民,无论是否是乘客,都是智能交通特别是智慧城市的主要利益相关方,市民也是与智能公交运营商直接互动最多的参与者之一。

数据交换的交互作用

该报告的研究切入点是智慧城市参与方之间的数据交换的形式,认为交互的特点是协同,但目前这些利益相干者之间数据交换及相关的协同并不多见,即便有数据交换,但也只是因为强制而非由于协调所需,因此数据交换需要夯实一个广泛、规范的共同基础,而非流于应付。

在智慧城市的智能公交领域内产生数据交互主要有两种情况:

与市民相关的数据交换:市民与运营商之间一般没有直接交换的渠道,而是通过网站、App应用、站牌等媒介进行数据交互;

与其他干系方的数据交换:运营商之间实现各自系统级的数据交换;

智慧城市环境实际的数据传输主要是通过有线或无线的机器对机器(Machine to Machine,M2M)技术,实现 M2M 数据交换的途径之一是使用 Webservice,在智慧城市中常用的规范或 协 议 主 要 有 SIRI、GTFS、CoAP 等。SIRI 协议是指实时信息服务接口(Service Interface for Real Time Information),该协议最早由伦敦交通局所使用,目前已成为国际标准的一部分。GTFS 是指通用数据传输格式(General Transit Feed Specification), 这是一种开源公共交通调度数据格式。而 CoAP 是指受限制的应用协议 (ConstrainedApplication Protocol), 由 IETF 所开发,主要用于类似传感器这类仅有简单设备的软件接口标准。在智能交通领域常常用到的技术或协议还包括6LoWPAN(IPv6 over Low power Wireless Personal Area Networks)、IEEE802.15.4、HC-06蓝牙模块及 MRHOF(Minimum Rank Objective Function with Hysteresis) 等, 当然 3GPP 及 5GPPP 也在欧盟及欧洲物联网产业协同规划下一代通讯网络和服务。

该架构主要从利益相关者互动的角度来介绍,因此细分为两个模型:

干系交互模型:主要关注利益相关者(如能源运营商)、功能流程(如能源管理)和利益相关者之间的数据交换(如能源消耗数据的交换);

交互层模型:主要关注利益相关者需要从业务(如交通协调业务)、信息 / 数据(如乘客信息)、应用(如 GTFS)、技术(如 IEEE802.15.4)和物理链路(如无线射频)之间交互的元素。

从网联城市向智慧城市演进

由于公交部门的表现不一,主要取决于城市成熟度水平,因此在描述智慧城市的交通部门的架构时,需要考虑城市成熟度。当前为了评估智慧城市的发展水平,已有多种评级方法,这类评级有助于遴选领先者,同时领先者的优秀实践可成为其他城市的标杆,智慧城市的简化 ICT 架构如图 2 所示。

下面三层实际描述的是网联城市(CC)中智能交通的 ICT 体系结构,其中独立运营商(不一定就是 IPT 运营商)管理他们的系统,彼此之间较少进行交互。现场组件是与真实世界进行交互的传感器和执行器,数据传输网络用于现场组件和数据处理之间传输数据,在数据处理则将来自现场组件的数据在集成后通过可视化系统进行呈现。

智慧城市则利用增加数据聚合和全局决策的能力来拓展网联城市的范畴,因此在架构中需增加两个额外的层:数据聚合与链接层和智能化处理层,前者使得公交运营商与智能组件之间的数据交换成为可能,因为后者需聚合和关联来自多个来源的数据,为全局通盘决策奠定基础。但与市民或其他利益相关者的数据交换在智慧城市或网联城市均有可能发生,但两者的交互方式略有不同。

干系交互模型

IPT 运营商和其他利益相关者之间交换数据的能力和范围取决于城市的禀赋和成熟度,但智慧城市中智能交通相较于网联城市更复杂,智慧城市中的 IPT 运营商可单独或联合交互数据,除在网联城市已涉及到的能源、基础设施、安全、交通和网络安全等方面采取协调行动外,智慧城市还要处理应急信息。智慧城市中 IPT运营商与利益相干者的数据交互关系如图 3所示。

调研表明 IPT 运营商非常不愿意公开网络安全方面的问题,但愿意与 CSIRTS 和警察部门合作和交换信息,同时他们也期待实现主动、双向的信息共享。表 1 说明了智慧城市中 IPT 运营商与其他利益相关者的安全要求和交互关系。

交互层模型

交互层模型主要从 IPT 运营商的视角来描述数据交换,即前一节中描述的互动关系。智慧城市中的数据交换主要从业务和信息 / 数据的角度来确定,同时兼顾应用和技术等方面因素,如图 4 展示了交互层模型。

业务层:该层主要使用信息和数据的过程和活动,这些过程和活动依赖于参与各方的数据交换。与 IPT 有关的过程及活动包括购票支付、乘客信息、交通协调以及能源协调、基础设施协调、提高紧急警报、安全协调和网络安全安全协调。由于流程与活动必须受保护且需具备相当的可靠性,因此业务层与网络安全息息相关。

信息 / 数据层:该层处理存储、处理和传输的信息或数据。在 IPT 的运行环境中,除需要处理如支付数据、行程数据和乘客信息外,还应包括定位信息、交通和基础设施状况数据、能源消耗数据、应急和监测数据以及与网络安全相关的威胁和事件数据。信息 / 数据层与网络安全高度相关,应注意对实际的网络安全需求和恰当的控制进行评估。

应用层:指在技术层基础上运行的应用程序及其存储、处理和传输的信息或数据。本模型不关注于特定应用,而是更重视与应用相关所采用的协议和标准,如 SIRI、GTFS 和CoAP 等。

技术层:承载应用程序运行所需的技术,同样不关注技术的细节。目前数据交换大多基于如 Web 服务等的互联网技术。在实际生产运营中,如6LoWPAN、IEEE 802.15.4 和 HC-06蓝牙等技术在 IPT 环境应用较为普遍,但主要存在于现场组件之间、及现场组件与各个运营商的数据中心之间的数据交换。分出应用层和技术层对详细评估网络安全需求和未来控制很有必要。

物理链路层:网络节点实际连接所采用的传输介质,此类介质可以是如双绞线、光纤等有线媒介或其他无线方式。物理链路层同样也与网络安全相关,但在目前与之相关的安全定义细节较少。

威胁模型

该报告采用安全评估矩阵作为威胁模型,见表 2 智慧城市威胁评估矩阵。威胁分类主要参照 ETSI 所定义的 ITS 威胁,再根据智慧城市中 ICT 体系架构调整,最终定义了五类威胁:①可用性威胁;②完整性威胁;③真实性威胁;④机密性威胁 ;⑤不可否认性威胁/ 责任威胁。

常见的可用性和持续的威胁如拒绝服务(DoS)攻击。完整性威胁主要包括使用伪装或恶意软件未经授权而访问受限信息以及信息的丢失、被操纵或被破坏。由于 ITS 中各节点都有发送、接收和转发消息的能力,保证数据的真实性是长期挑战。威胁信息的机密性常见的手段有通过窃听或对消息流量的分析非法收集数据。信息的不可否认 / 责任极为重要,应确保没人可以否认发送或接收特定消息或对特定的服务 / 数据进行了修改。

在前一节智慧城市的ICT 体系架构描述了五层模型:①现场组件;②数据传输网络;③数据处理;④数据汇聚与链接;⑤智能化处理。

合成这两种指标形成矩阵,就易于将其评估结果将威胁类别在各层中进行定义和描述。

特定威胁

特定威胁分为两类:故意攻击和意外事件。在智慧城市中威胁来源多样,既有针对信息 / 数据层、应用层和技术层的威胁,也有来自组织结构和 IPT 相关的基础设施等威胁,如图 5 智慧城市威胁图景所示。

优秀实践

面临故意攻击和事故威胁的威胁就有必要进行风险评估,以作出合理的决定并采取正确的措施。优秀实践可为 IPT 运营商和市政部门提供评估措施进行控制或从事件中恢复提供指导,并为后续管理这类事件落实新举措。

当前 IPT 运营商很少制度化网络安全政策或配置关键资产,调查发现 IPT 运营商对于网络安全的知识储备不足、相关支出偏低。虽然部分 IPT 运营商也已实施一些网络安全措施和应对方案,但这些仍处于摸索当中,再加上攻击的应对手段往往是多样化的,因此最合用的措施还是改变政策和程序或应用新技术。通常除员工培训、物理访问控制和防护及安全性设计外,惯常使用的还是对数据和网络进行访问控制、组织架构和操作程序的实施指南、灾难恢复和维护备份及实时监控硬件 / 软件故障。难免设备使用年限过长且拥有大量的老旧系统,整体安全性难以保证。

左右网络安全与否的要素在于网络安全意识、数据隐私和机密性需求、保持服务 / 数据完整性能力以及安全标准和法规。总结出了部分优秀实践供参考,需要留意的是防护和响应措施也是多元化,即便优秀实践也并非完全拿来就用,或者施用就完全符合标准或规范。

适用于故意攻击威胁的优秀实践有:尽量使用 VPN、数据加密、部署网络入侵检测系统、实施物理防护、严格访问控制、实施警报与监测、配置应用信息安全策略、记录活动日志、定期备份与维护、定期审计、停机检测(检查系统依存度)等;

适用于意外事件威胁的优秀实践有:监控关键绩效指标(KPI)、硬件冗余、规范设计、完善维保流程、建立应急响应和支持小组、质量控制、报告流程、事件管理、排错流程、操作和用户培训、培育安全意识、制定准操作过程、响应流程、错误日志、软硬件故障检测、持续安全监测、定义支持条件、定期升级基础设施、增强系统弹性、设备远程关闭能力、早期预警系统、灾难恢复流程、基础设施的威胁评估等。

重要发现与建议

七项重要发现

(1)智慧城市中协同周界定义不清晰

智慧城市的首当其冲的是实现组件相互关联,要点在于连通性和数字网络,核心是网络安全,还要有明确的愿景和远期目标。智慧城市因此需要跨部门、多个城市甚至跨国的协作,但当前各方缺乏协同意识,何况一城之内合作领域已非常宽泛、但尚未形成协同,再加上相应的法规也不健全。

(2)缺乏智慧城市数据交换的参考架构模型

智慧城市利益干系人众多,数据交换来源广,集成难度大,数据集成后易于导致在事件发生时产生雪崩效应,因此需要一个合适的参考架构模型,但目前尚为空白。

(3)智慧城市的网络安全意识很重要但被忽视

在调研中发现在理解网络安全政策和配置关键资产方面表现较差,大多数受访者对网络安全政策了解甚少,也从不制度化相关政策或编制关键资产配置表。调研发现这个行业注重的是车辆运行安全性及相应的安全系统和训练有素的员工,其次是车辆和物理基础设施,网络安全不是主要目标就不甚关心。

(4)缺乏威胁和事件的横向信息共享渠道

现实中安全威胁来源广泛,应急事件响应时缺乏信息共享渠道因此难以多方协同。

(5)IPT 领域的网络安全知识贫乏、投入极低

运营商们即不希望泄露受网络攻击的事实,又不知道如何应对此类事件的协同处置和信息共享,大部分受访者经说明后才知晓有 CSIRT或 LEA 等部门可主动双向共享威胁情报。

(6)施用网络安全措施进度迟缓

智慧城市中 IPT 运营商虽已经采取部分措施来保障网络安全,但进展缓慢,同时大多数受访的组织也没有评估其措施是否有效的手段。

(7)提高安全意识可增强网络安全性

IPT 中对网络安全的认知障碍主要在于缺乏对 IPT 方面的网络安全威胁的充分理解及缺乏应对网络安全的明确策略。在调查中不同类别的受访者确认存在如下差距:组织差距(如安全、培训、内部威胁的治理)、政策和标准化差距(如欧盟标准和可识别的欧盟网络安全战略)。但受访者也认为不能把安全与网络安全混淆,因为这两者并不相同,需要不同的方法来处理。另一个值得注意的是关于网络安全是否重要的问题,这个问题的答案大相径庭, IPT 及智慧城市运营商持积极态度,但安全专家和决策者却相反,他们反而认为不甚重要。但总体而言秉持网络安全重要的观点在组织内逐渐占主导地位,但路还很长。

八点建议

(1)市政部门应支持开发协调一致的网络安全框架

建议目标:解决第(1)、( 2)和(4)关键发现中所包含的问题。

建议多方参与开发协同一致的网络安全框架,让框架成为智慧城市参与各方共同实施的基本准则,而且低成熟度的智慧城市也可参照此类框架进行调整。

该框架可基于现有的安全标准和风险管控措施,但也要考虑诸如社会因素、ICT 体系架构等在内的特殊性,因此理解行业及运营商们采取的方法也很关键,毕竟他们知晓其安全需求和相关标准。

(2)欧盟委员会及成员国应促成产业、成员国和市政部门之间的网络安全知识交流和合作

建议目标:解决第(1)、( 3)、(4)和(7)关键发现中所包含的问题。

其他部门已经开始调研各自的网络安全,建议 IPT 运营商加入此类平台进行跨部门协作,加深对于威胁和风险的理解,共享并借鉴优秀实践。市政部门也应当参与,可获取安全知识及落实优秀实践。

(3)IPT 运营商应清晰定义其安全需求

建议目标:解决第(6)和(7)关键发现中所包含的问题。

IPT 运营商需明确定义规范的安全需求,应遵循“设计即安全和隐私”的理念,在新系统的早期概念阶段就应重视其安全性,在集成新系统或服务时,还应考虑对现有现有系统的影响。

由于 IPT 运营商通常由第三方提供相关产品和服务,因此需要明确安全性要求,运营商可定义技术规范(如安全协议)、安全集成要求(如接口、访问控制等)、维护与支持(如补丁等)、安全功能的测试周期、员工培训等,通过规范的安全需求可引导第三方供应商提供安全产品。

(4)产品制造商和解决方案供应商应在产品中集成安全性

建议目标:解决第(5)和(6)关键发现中所包含的问题。

建议产品制造商和解决方案供应商应遵循“设计即安全”的原则,早做准备,积极提升产品的安全性和弹性,适应 IPT 运营商所提出的安全需求。 制造商或解决方案供应商可从其他领域借鉴优秀安全实践,避免重新开发安全功能,还建议厂商通过测试或认证等方法验证其产品的安全性,另外这些供应商也可提供安全支持或培训等增值服务。

(5)IPT 运营商和政府应明确中高层管理人员在网络安全事务中的职责

建议目标:解决第(3)、( 5)、(6)和(7)关键发现中所包含的问题。

建议 IPT 运营商和政府明确中高级管理人员在网络安全事务方面的职责,职责应涵盖每位管理人员的角色、职责和义务、汇报链以及可采取的行动(如跨部门协同等)。明确职责有助于提高应对网络威胁及其后果的准备程度,也可激发组织提升网络安全水平。

(6)欧盟委员会和成员国应明确参与各方职责

建议目标:解决第( 2)和(6)关键发现所包含的问题,对发现(3)也有正面影响。

随着信息 - 物理类产品的应用更广泛,网络威胁会对市民的安全产生实则影响。因此欧盟委员会和成员国应明确参与方各的职责。

(7)IPT 运营商和政府应在网络安全事务方面增加投入

建议目标:解决第( 5)和(6)关键发现中所包含的问题,对发现(4)、(7)也有正面影响。

网络安全是有成本的,建议IPT运营商和政府增加投入,尤其需要先管理人员和各级员工提供培训、提高网络安全认知、提升专业能力等。

(8)智慧城市和标准化组织应将网络安全需求整合进智慧城市成熟度模型

建议目标:解决关键发现( 2)所包含的问题,对发现(1)和(6)也有正面影响。

当前已有数个评估体系可用来评价智慧城市发展成熟度,“弹性”指标可能已经包含,但用于说明网络安全并不全面。而智慧城市的链接度持续增长、数据交换范围逐渐扩大,建议现行的标准和评估体系将网络安全纳入成熟度的关键指标。

当前中国已有数百个城市或城区正在建设智慧城市或智慧城区,在城市内管理、经济、社会领域内实施信息化和智能化技术,对于提升城市综合治理能力和服务水平收效显着,但在建设过程中,由于各自建设模式或遵循的理念不尽不同,对于网络安全的规划和设计也参差不齐,因此 ENISA 的这份报告提出智慧城市中网络安全体系架构模型,可作为网络安全的顶层设计方案为我国智慧城市的规划与实施提供参考,最终建设更智能、更安全、更宜居的城市。

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论