移动边缘计算、雾计算等:安全威胁与挑战的综 述与分析
1. 亮点
- 确定了所有边缘范式共有的特性和问题。
- 分析了影响边缘范式的安全威胁和挑战。
- 展示了在安全机制开发中的潜在协同效应。
- 讨论了近期需要研究和评估的问题。
1. 引言
云计算已席卷全球。在这种效用计算类别中,通过多租户模型汇集了大量的计算资源(例如网络、服务器、存储),以服务于多个消费者。这些资源可通过网络获得,并通过标准机制[1]进行访问。云计算范式提供了多种部署模型和服务模型,从公共云(组织向任何客户提供云计算服务)到私有云(组织部署自己的私有云计算平台),以及从基础设施即服务模型(IaaS,将基本计算资源作为能力提供)到软件即服务模型(SaaS,将应用程序作为能力提供)等。云计算的优势——最小化管理开销、便捷性、快速弹性、按使用付费、普遍性——催生了一个在全球范围内不断增长的数十亿美元的产业[2]。
尽管云计算具有诸多优势,但它并非万能。通常,公共云供应商已在世界各个地区建立了少数大型数据中心。这些大规模的通用计算机数据中心拥有足够的计算资源,可为数量庞大的用户提供服务。然而,这种资源集中化意味着终端用户设备与其云之间存在较大的平均距离,从而导致平均网络延迟和抖动增加[3]。由于这种物理距离,云服务无法直接访问本地上下文信息,例如精确的用户位置、本地网络状况,甚至用户移动行为的信息。对于各种延迟敏感型应用,如车载网络和增强现实,这些需求(低延迟和抖动、上下文感知、移动性支持)是必不可少的。
由于这些原因,近年来出现了各种新型范式,例如雾计算[4],、移动边缘计算[5],和移动云计算[6],等(参见[7, 8])。这些边缘范式的共同点是在网络边缘部署类云计算能力。大多数边缘范式遵循图1所示的结构。
由基础设施提供商拥有和部署的边缘数据中心实现了多租户虚拟化基础设施。任何客户——从第三方服务提供商到终端用户以及基础设施提供商自身——都可以使用这些数据中心的服务。此外,尽管边缘数据中心可以自主运行并相互协作,但它们并未与传统云断开连接。因此,可以通过网络基础设施将它们互联,形成分层多层架构。另外,我们还必须考虑底层基础设施或核心基础设施(例如移动核心网络、集中式云服务)可能存在的事实,这些设施提供各种支持机制,例如管理平台和用户注册服务。最后,一个信任域(即由基础设施提供商拥有的边缘基础设施)可以与其他信任域合作,形成一个开放生态系统,为大量客户提供服务。
不同的边缘范式之间存在多种差异,例如移动边缘计算侧重于将移动网络运营商作为基础设施提供商,移动云计算中存在用户拥有的边缘数据中心(即个人云点),以及使用不同的底层协议和接口等。然而,这些范式之间仍存在大量相似性。尽管如此,目前这些领域的研究很少考虑这些相似性。大多数架构、协议、服务和机制的设计仅针对一种边缘范式,未考虑其他边缘范式的现有技术。在当前初期阶段,研究人员应意识到某一边缘范式相关的研究成果也可能适用于或可被调整以适应其他边缘范式。
这种孤岛思维在安全领域尤为明显。尽管边缘范式中的安全问题研究仍处于初期阶段,但鉴于该领域的特殊重要性,众多研究人员已经识别出各种潜在威胁。在此过程中,他们开发了多种安全与隐私机制。然而,正如前所述,大多数研究没有采用跨学科的方法:研究往往只关注某一种特定的边缘范式及其现有技术。此外,很少有研究人员考虑到,有可能分析并调整最初为使能技术(例如无线网络、分布式和对等系统、虚拟化平台[4])和其他相关范式(例如云计算、网格计算)设计的安全机制。
因此,本研究旨在从整体视角出发,对边缘范式的安全进行详细分析。该分析将按以下方式组织:第2节介绍最重要的边缘范式,包括其历史、用例和标准化工作;第3节分析所有边缘范式的共同特性及差异,并强调其挑战和潜在的协同效应;第4节介绍影响所有边缘范式的安全问题;该节分析针对边缘范式的各种威胁模型,并简要概述在此背景下应采用的安全机制的需求与挑战;第5节对边缘范式安全领域的现有技术进行分析,该分析不仅列举现有的安全机制,还指出了最初为边缘范式及其他相关领域设计的安全机制之间的协同效应;最后,第6节给出结论。
| 特性、协同效应 | 雾 ‐ 威胁 | 雾计算 ‐ 安全 | 移动边缘计算 ‐ 威胁 | 移动边缘计算 ‐ 安全 | 移动云计算 ‐ 威胁 | 移动云计算 ‐ 安全 | 我们的工作 |
|---|---|---|---|---|---|---|---|
| No | No | No | No | No | Partial | 2013 | |
| No | No | No | No | No | Partial | 2013 | |
| No | No | No | No | No | Partial | 2015 | |
| No | No | Partial | No | No | No | No | |
| No | Partial | No | No | No | No | No | |
| Partial | No | No | No | No | No | No | |
| Yes | Yes | Q3 2016 | Yes | Q3 2016 | Yes | Q3 2016 |
表1:关于边缘安全的现有调查的贡献
相关工作
近年来,众多作者对各种边缘范式的安全现状进行了调查和综述,例如移动云计算[9, 10, 11]和雾计算[12, 13, 14]。这些研究旨在初步分析影响这些范式完整性的威胁,并概述用于保护所有参与方和基础设施的安全机制。其他研究则聚焦于特定领域,例如雾计算中的网络安全[16]和取证[17]。此外,一些作者[15]还简要概述了所有边缘范式的基本特性。然而,如表1所示,这是首次从整体视角对多个主题进行全面且最新的分析,包括:i) 边缘范式的共同特性、差异和协同效应;ii) 针对所有边缘范式完整性的各种威胁模型的详细分析;iii) 对所有边缘范式中安全现有技术的深入分析,包括安全机制之间的潜在协同效应。
2. 边缘范式概述
2.1. 雾计算
雾计算的概念由思科系统于2012年提出,在其最初的定义中被视为“云计算范式的一种延伸,可在终端设备与传统云服务器之间提供计算、存储和网络服务”[18]。因此,雾计算并不会取代云计算,而是对其形成补充:雾架构有助于构建一种分层基础设施,其中本地信息的分析在“地面”进行,而协调与全局分析则在“云”端完成。在此架构中,云服务主要部署在网络边缘,但也可能部署在其他位置,例如IP/多协议标签交换(MPLS)骨干网。实际上,雾网络基础设施是异构的,高速链路与无线接入技术将共存[19]。
雾计算的最初定义后来被多位研究人员扩展和修订(参见[4, 20])。尽管这一扩展定义存在争议,但它揭示了雾计算可能带来的所有进步。根据这一新定义,雾计算不再仅仅是云计算的延伸,而是成为一种独立的范式。实现云服务的元素——雾节点,现在可以涵盖从资源受限设备(例如终端设备、本地服务器)到功能更强大的云服务器(例如互联网路由器、5G基站)的各种设备。此外,所有这些元素还能够在分布式方式下相互交互与协作。这形成了一个三层架构(客户端 ⇔ 雾节点 ⇔ 中央服务器),其中集中式云服务器与雾节点共存,但对于雾服务的执行并非必需[21]。此外,雾计算还支持联邦基础设施的构建,使得拥有各自雾部署的多个组织能够相互协作。
最初,雾计算被定义为一个能够在物联网(IoT)环境中实现新应用程序和服务创建的平台。此类服务的示例包括分层的大数据分析系统和智能基础设施管理系统(如风电场、交通信号灯)[18, 4]。然而,目前已有若干研究探讨了如何利用这一范式实现其他类型的服务:面向资源受限(移动)设备的低延迟增强接口(例如使用无线脑电图耳机的脑机接口[22],、增强现实和实时视频分析[23])、信息物理系统[24],、在雾计算环境下的新型内容分发与缓存方法[25],,以及各种车对车(V2V)和车对基础设施(V2I)服务,如共享停车系统[26]。
截至2016年,创建一组标准化的开放雾计算框架和架构的工作已经启动(参见开放雾计算联盟[27])。这些工作无需从零开始,因为已有众多研究人员分析了雾计算架构可能的形式。其中一个例子是Sang Chin 等人[28]定义的架构。该上下文感知基础设施支持多种边缘技术(例如Wi‐Fi、LTE、ZigBee、蓝牙智能),并通过网络功能虚拟化(NFV)和软件定义网络(SDN)机制支持网络虚拟化和流量工程。其他研究人员还研究了如何将雾计算与现有物联网框架(如OpenM2M[29])集成。在这个特定示例中,雾节点部署在车载网络中的路侧单元等边缘设备上,并实现各种机器对机器服务,例如轻量级M2M设备管理系统和M2M传感器测量框架。
也有许多研究人员已经识别出不仅潜在的挑战,还有利用雾计算范式以创新方式的前瞻性部署。一个例子是需要提供一组应用程序编程接口(APIs),使虚拟机(VM)能够访问由雾节点提供的服务。通过这些应用程序编程接口,虚拟机可以访问本地信息,如网络统计、传感器数据等[30]。另一个例子是空中雾计算系统的部署——其中像无人机这样的飞行设备充当雾节点,并与其他服务器协作,为移动用户提供各种服务[31]。
2.2. 移动边缘计算
术语移动边缘计算(MEC)最初于2013年被用来描述在网络边缘执行服务的技术,当时IBM和诺基亚西门子网络推出了一种可在移动基站内运行应用程序的平台[32]。这一初始概念仅限于本地范围,未考虑应用程序迁移、互操作性等其他方面。2014年,欧洲电信标准协会(ETSI)成立了移动边缘计算行业规范小组(ISG)[33],此后MEC获得了当前的含义。根据该规范,MEC旨在“在移动网络边缘提供一个IT服务环境和云计算能力”。该小组还致力于创建一个开放生态系统,使服务提供商能够在多厂商MEC平台上部署其应用程序。一旦标准完成,电信公司将在其基础设施中负责部署该服务环境。
将云服务部署在5G等移动网络边缘的优势包括低延迟、高带宽以及对无线网络信息和位置感知的访问。得益于这些优势,不仅可以优化现有的移动基础设施服务,甚至还能实现全新的服务。例如,移动边缘调度器[34],可最小化LTE下行链路中通用流量流的平均延迟。此外,服务的部署将不仅限于移动网络运营商,还将向 3rd方服务提供商开放。预期的应用程序包括增强现实、智能视频加速、联网汽车和物联网网关等[35]。
为了实现MEC环境,需要在移动网络边缘的多个位置部署虚拟化服务器(即MEC服务器)。MEC ISG考虑的一些部署位置包括LTE/5G基站(eNodeB)、3G无线网络控制器(RNC)或多无线接入技术( 3G/LTE/WLAN)小区汇聚站点——这些站点可以位于室内或室外。此外,MEC ISG建议该虚拟化基础设施不仅应承载移动边缘计算服务,还应承载其他相关服务,如网络功能虚拟化(NFV)和软件定义网络(SDN)[35]。此类部署将降低部署成本,并为所有虚拟化服务提供统一的管理和编排基础设施。
截至2016年,欧洲电信标准协会移动边缘计算ISG[33]已制定出多接入边缘计算框架和参考架构,其功能单元为应用执行、无线网络信息等服务提供支持。以及位置感知。此外,还有各种研究正在探讨如何利用现有和新兴技术部署该服务环境。例如,斯塔林等[36] 评估了三大开源云计算平台( OpenStack、Eucalyptus 和 OpenNebula),并确定了为在移动网络中部署这些平台需要改进的模块。普恩特等[37] 分析了小小区云(互连的 eNodeB 集群)如何在不修改任何现有标准和接口的情况下无缝集成到现有的 LTE‐A 基础设施中。此外,迈尔和里马尔[38] 研究了如何利用光纤通信技术连接多接入边缘计算环境中的所有元素。
2.3. 移动云计算
移动云计算(MCC)主要关注“移动委托”的概念:由于移动设备可用资源有限,它们应将大量数据的存储和计算密集型任务的执行委托给远程实体。在2009年提出的原始MCC概念中,仅考虑了集中式云计算平台作为实现任务远程执行的最可行解决方案[39]。随后,其他研究人员扩展了MCC的范围。在这种新愿景中,任务也可以委托给位于网络边缘的设备[40]。目前,这两种MCC愿景并存[41]。在本研究中,我们将主要关注后者。
最初,移动云计算(MCC)旨在为移动学习、移动医疗、搜索服务及其他服务提供新颖的解决方案[42]。如今,这些服务中的许多都可以在集中式云中实现(例如基于语音的搜索),或直接在移动设备本身实现(例如文本转语音引擎)。然而,移动云计算的概念仍然具有重要意义,因为其潜力尚未被充分挖掘。对于某些应用程序,如增强现实和增强界面应用,若在移动设备附近的区域部署执行平台,则可带来诸多优势,例如更低的延迟和对上下文信息的访问。此外,随着移动设备配备了传感器和高分辨率摄像头等功能单元,开发新型的众包和群体感知应用成为可能,这些应用可以利用位置信息[6]。
移动云计算领域的最活跃的研究领域之一是将任务委托给外部服务[41]。存在各种解决方案允许应用程序将部分代码从移动设备迁移到位于边缘的基于云的计算资源。应用程序通常使用 .NET 和 JVM 等框架实现,这使得代码迁移过程更加容易。一些研究成果允许移动设备仅迁移部分代码,因此有必要静态或动态识别需要卸载的代码。其他研究人员持更激进的观点:创建代表移动设备的整个执行环境(即克隆)。然后,将移动应用程序的部分内容(包括内存镜像、CPU状态及其他)加载到该克隆中。最后,一些方法利用移动代理基础设施,其中移动设备创建一个移动代理,由其代为获取/处理信息。甚至还有一些方法,例如 Aqua计算 的概念,融合了移动代理和克隆的概念[43]。
另一个重要的研究领域是在边缘实现基于云的计算资源。主要有两种策略:邻近的固定计算实体(固定虚拟化服务器)和邻近的移动计算实体(移动设备的临时聚合)[44]。本文将主要关注第一种策略,但也会考虑第二种策略的各个方面。
第一种策略的核心元素是云子。这一概念最初由Satyanarayanan等人在 2009[45],中提出,指的是位于移动用户附近的微型云基础设施。这种小型基础设施可部署在商业场所(例如咖啡店、公司建筑)中,采用数据和代码的持久缓存而非硬状态,并允许设备在预先存在的完整虚拟机镜像上加载小型的虚拟机叠加[3]。目前已有面向研究社区免费提供的概念验证,包括以用户为中心的个人云朵[46],。此外,多项测试表明,与集中式云相比,云子可将移动设备的响应时间缩短51%,能耗降低高达42%[47]。
第二种策略有多种实例。它们都指定在由邻近设备组成的集群上构建一个分布式计算平台,这些设备基于云计算原则充当服务器。集群中的元素可以是移动设备(参见Hyrax[48], FemtoClouds[49])、物联网设备和实体(参见Aura[50]),或多种类型设备的组合。由于构成分布式集群的设备可用资源有限,该策略不使用虚拟化技术。相反,一些实现采用了特定的并行算法如MapReduce,而其他方法则采用更通用的方式,允许各种计算密集型任务。在几乎所有情况下,控制器负责接收任务并发现哪些设备可以最优地执行这些任务。
2.4. 其他方法
正如我们在前面几节中所看到的,有许多范式旨在将云服务和资源带到用户附近。尽管我们已经总结了其中最重要的几个范式(参见图2),但仍有一些与这些主要范式相关的次要的初期架构。一个例子是 Manco 等人[7]提出的 超流体云 概念。在超流体云架构的构想中,一组具备异构能力的虚拟化平台(从树莓派等微型服务器到更大的 x86 部署)被部署在网络的各个位置:接入网络层(例如 5G eNodeB)、汇聚网络层(例如本地数据中心、网络路由器)以及核心基础设施层(例如云数据中心)。除了异构服务器的部署之外,该架构的另一个主要区别特征是大规模整合的概念:即能够执行在单个通用服务器中部署大量(约10,000个)极简化的虚拟机。这些虚拟机可以快速部署并迁移到网络中的各个位置。这种大规模分布式分层架构支持即时创建服务,必要时这些服务可表现为移动代理。
另一种架构被称为以边缘为中心的计算,由加西亚·洛佩兹等人[8]提出。在他们的构想中,部署在数据中心和纳米数据中心上的以边缘为中心的分布式服务联盟,以点对点方式相互协作。此外,云可起到辅助作用,在需要时提供稳定的资源。这一构想支持创建以人为本的应用程序,例如在边缘创建个人空间(如用户自主管理访问控制和信任机制的个人信息)、边缘的社交空间(如基于用户可控社交活动的众包应用)以及边缘的公共空间(如多方参与方——人类与城市服务——互动的协作信息流)。
3. 特征与协同效应分析
3.1. 特性:相似性与差异性
| 特性 | MEC | Fog Computing | MCC | Cloud |
|---|---|---|---|---|
| 所有权 | 电信公司 | 私营实体,个人 | 私营实体,个人 | 私营实体 |
| 部署 | 网络边缘 | 近边缘,边缘网络边缘,设备 | 近边缘,边缘网络边缘,设备 | 网络核心 |
| 硬件 | 异构服务器 | 异构服务器 | 服务器,用户设备 | 服务器 |
| 服务 | 虚拟化 | 虚拟化 | 虚拟化 ,其他 | 虚拟化 |
| 网络架构 | 多层 ,去中心化 ,分布式 | 多层 ,去中心化 ,分布式 | 多层 ,去中心化 ,分布式 | 集中式 |
| 移动性 | Yes | Yes | Yes | N/A |
| 延迟, 抖动 | Low | Low | Low | 平均 |
| 本地感知 | Yes | Yes | Yes | N/A |
| 可用性 | High | High | High | High |
| 可扩展性 | High | High | High | 平均 |
表2:边缘范式特性的比较
表2总结了每种主要边缘范式的主要特性。其中一些特性在上一节中已介绍过,其他特性则来自现有的报告和研究文献(参见 [35, 37, 27, 21, 41, 42]及其他文献)。请注意,为了便于比较,该表还包含了现有集中式云计算范式的一些特性。
相似性
在分析不同范式的特性时,一个明显的结论是:这些范式可能源自不同的背景,但它们都具有相同的基本目标:将类云计算能力带到网络边缘。它们均提供对某种多租户虚拟化基础设施(例如雾节点、MEC服务器、云朵)的支持,用户可通过各种宽带网络(例如光纤、无线通信、高速移动网络)轻松访问这些设施。这些基础设施能够根据用户的位置和需求动态调整能力供给,并在需要时访问附近的计算资源(例如邻近的虚拟化资源池、分布式移动设备)。此外,所有范式都考虑到了监控各类资源使用情况的需求,尽管负责监控的实体以及这些实体的分布方式因范式而异。
各种范式之间也存在诸多相似性。一个明显的例子是移动性:由于大多数服务都是在本地提供的,因此必须考虑移动设备的存在。每种范式都采用多种策略来支持用户移动性:从位于网络层次结构较高层级的移动性管理实体,到支持虚拟机迁移的机制。另一个例子是网络架构。所有范式都可以作为云的延伸,补充其服务,从而能够构建分层的多层级架构。另一方面,这些范式的元素也可以以去中心化和分布式的方式运行;边缘数据中心能够自主提供服务并做出决策,同时在不完全依赖中心化基础设施的情况下相互协作。此外,所有范式都致力于构建联邦基础设施,使多个边缘基础设施能够共存,并交换信息和服务。
这些范式还提供了类似的一组优势,这些优势主要源于边缘数据中心的临近性。例如,当用户访问其周围环境的计算能力时,网络延迟和数据包延迟变化(抖动)都较低且可预测。另一个优势是能够访问本地信息(如网络状况、环境的物理特征、地理位置),这使得所有用户和服务都能够感知其本地上下文。进一步的优势在于整个生态系统的可扩展性。这有多种原因:首先,节点可以广泛分布并在地理上大量可用;其次,假设位于特定位置的节点站点将主要为本地设备提供服务。需要注意的是,如果情况需要,也可以利用相邻节点,甚至使用位于更远地理位置或层级结构中更高层的节点。最后,另一个重要优势是服务的高可用性。这有两个原因:i)本地层面的节点冗余;ii)在某些范式(例如多接入边缘计算)中,边缘数据中心实际上由通信基础设施(例如移动网络基础设施)承载。
差异
显然,即使所有这些范式都具有相同的目标,它们在实现该目标的方式上仍存在一些根本性差异。例如,MEC 将边缘计算平台的部署限制在移动网络基础设施(如 5G)中。而雾节点还可以部署在其他位置,例如用户管理的服务器、接入点、路由器、网关等。至于 MCC,其分布范围更为广泛,在某些情况下,设备本身也可以参与服务提供过程。这种在边缘数据中心部署和管理上的差异影响了谁可以成为服务提供商。例如,在 MEC 中,只有电信运营商才能成为 MEC 提供商,因为他们拥有部署边缘数据中心的移动网络基础设施。相比之下,任何用户(从企业到技术娴熟的终端用户)都可以部署自己的雾节点和 MCC 节点,从而有效成为服务提供生态系统的一部分——甚至创建自己的类私有云环境。
另一个与前述观点相关的差异是精选应用程序的部署。由于MEC服务器由电信运营商控制并托管在其基础设施中,第三方服务提供商可以与运营商紧密合作,开发针对MEC的特定服务。这些服务随后可以经过充分测试,并可能以定制化方式集成。这一点在雾计算中同样适用,因为某些雾节点可以部署在互联网服务提供商基础设施中(例如路由器和网关)。最后,一些范式(如MCC)提供了一些其他范式未考虑的特定服务。例如,MCC支持与虚拟化无关的分布式执行机制,例如在资源受限设备上执行MapReduce并行算法。另一个例子是以边缘为中心的计算愿景,其重点在于个人空间(例如用户控制的个人网络)和点对点交互。
3.2. 挑战与协同效应
| 挑战 | 描述 |
|---|---|
| 基础设施 | 互操作性;监控;问责制 |
| 虚拟化 | 虚拟机生命周期;容器和上下文感知 |
| 资源与任务 | 资源定位;任务调度;卸载 |
| 分布式 | 协作;多层管理;软状态 |
| 移动性 | 连接性;无缝切换 |
| 可编程性 | 可用性;会话管理 |
表3:边缘范式中的常见挑战
由于所有边缘范式之间存在相似性,它们面临一些共同的主要挑战,这些挑战总结于表3中(参见[20, 6, 35]及其他)。这些挑战的共同点在于这些范式的去中心化和分布式特性,这与云计算范式的集中式特性形成对比。服务基础设施向边缘的去中心化和临近性带来了各种优势(例如低延迟、可扩展性),但也引入了必须认真考虑的新问题。此类问题的例子包括各类实体的移动性(包括服务基础设施本身[31])以及在多层架构中同步“软”状态和“硬”状态的需求。服务基础设施的分布式特性——其中可能由不同基础设施提供商拥有的多个边缘数据中心需要能够相互协作——也带来了其他挑战。有必要制定标准,规定架构中不同元素如何相互协作,以及虚拟机如何无论其部署位置如何都能访问某些信息(例如上下文和主机信息)。具体到虚拟化,至关重要的是为优化的虚拟机生命周期提供支持——即虚拟机的创建、部署和迁移应尽可能轻量级。此外,由于资源分布在不同的实体和位置上,必须存在一组机制以实现这些资源的发现和编排,包括对其进行监控。
尽管所有范式都面临这些共同的挑战,但在研究和开发新解决方案时,仍然有必要考虑每种范式的细微差别(例如,其底层协议的特性、特定的用例)。事实上,由于技术、经济和政治原因,多种标准和规范将共存,与其针对现有问题的自身解决方案。然而,即使这些范式之间存在若干结构性差异,也不意味着它们应当孤立存在,而忽视其他相关领域的进展。由于这些范式之间存在相似性(参见第3节),可以合理假设将出现能够为共性问题提供通用解决方案的机制和平台。此类解决方案随后可被适配到其他边缘范式中。事实上,这一假设得到了现有技术的支持,在当前已有许多机制最初是针对某一特定范式而设计的,但同样可应用于其他范式。我们将在接下来的段落中提供多个此类协同效应的实例。
在范式之间可以找到明显协同效应的一个领域是虚拟机的管理。在雾计算[51]和多接入边缘计算[52],领域,已经存在各种研究工作,定义并解决了优化问题,旨在通过一组本地集群优化虚拟机的分布式部署,以最小化资源的使用。这些机制还定义了虚拟机何时需要复制、迁移和合并。由于这些算法所依赖的基本假设主要要求一种能够访问本地信息的去中心化基础设施,因此它们可以适应任何边缘范式。另一个重要方面是创建和部署新虚拟机的成本。特别是,在超流体云[7],等领域的进展中,可以在通用服务器上以极低延迟部署数千个轻量级虚拟机,这些进展也可以被适配并应用于其他范式。
另一个其解决方案可应用于其他范式的领域是资源卸载,这是移动云计算(MCC)领域中研究最广泛的领域之一。如第2节所述,存在多种策略允许用户设备将其任务委托给外部服务器(远程过程调用框架、代码迁移、克隆部署、移动代理)。然而,也存在并非用户设备而是虚拟机(VM)希望将其部分任务进行委托的情况。此类情况的实例包括用户移动性(例如,特定任务——而非整个虚拟机——被迁移到距离用户最近的节点)、任务优化(例如,网络密集型任务保留在本地级别,而计算密集型任务则发送到功能更强的云系统[53])、用户赋能(例如,在Aqua计算中通过克隆在网络中创建用户空间[43]),以及其他情况。许多委托策略仅需存在一个虚拟化平台以供任务被委托[6],,因此该特定领域的大量研究可以被调整以满足在其他边缘范式中部署的应用程序的需求。
其他示例包括用户移动性、上下文感知和资源位置。该领域存在多种算法,例如[54, 55],,试图预测(潜在)用户的位置,以便提前部署预期资源。实现迁移计划的核心算法仅需要一种分布式架构的计算平台,这些平台能够以尽可能低的延迟相互通信。关于上下文感知,该领域的若干研究分析了本地硬件感知如何帮助虚拟机理解其自身容器的限制[30],,或虚拟机如何利用图形计算单元等硬件加速技术[56]。在虚拟化服务器异构且虚拟机可能需要动态调整其行为的场景中,这些研究至关重要。关于资源位置,普适计算领域(参见[57])已有大量研究成果,可应用于雾、多接入边缘计算及其他范式。许多此类搜索引擎采用N层层次结构,其中层次结构的最底层存储有关本地上下文的信息。随后使用布隆过滤器等算法来表示一组关键词,以减少通信开销。
还有一些应用场景仅针对一种范式定义,但由于其需求(例如支持去中心化和分布式执行平台),它们也可以在其他相关范式中实现。主要为雾计算定义的场景,如物联网节点配对服务[58],上下文感知数据分析平台[59],以及紧急通知机制[60],也可以部署在多接入边缘计算和云朵基础设施中。最后,存在各种支持服务,即使它们最初是基于单一范式开发的,也可以适应其他范式。尼卡因等人[61]提出的网络商店概念就是此类支持服务之一。这项研究工作引入了一个面向多接入边缘计算的数字分发平台,该平台提供虚拟化网络功能(VNF)或切片,以支持5G应用用例。尽管由于底层协议的差异,这些切片无法直接部署在其他相关范式中,但数字分发平台的概念及其架构元素(服务与业务层、切片编排与管理层)可以被适配并部署到其他虚拟化平台中。确切地说,由于边缘范式的分布式和协作特性,网络商店的实现可作为边缘应用快速部署的催化剂,因为它可以充当功能与知识库。
最后需要强调的是,即使每种范式都完导致它们创建各自的标准和各自的服务基础设施,并不意味着它们之间无法相互协作,甚至无法相互集成。例如,云子传统上与移动云计算相关联,但它们可以成为雾计算和多接入边缘计算的技术推动者。此外,由于雾计算和多接入边缘计算都旨在通过一组开放的应用程序编程接口支持联邦服务以及与不同提供商的交互,因此有可能创建同时利用两种边缘范式的应用,甚至部署在基础设施层面连接各种边缘范式的中间件平台。
4. 安全威胁
为了构建一个所有参与方(终端用户、服务提供商、基础设施提供商)都能从边缘范式所提供的服务中受益的生态系统,必须克服诸多挑战。不出所料,其中最大的挑战之一是安全。在第4节中,我们将:a)回顾安全在此特定背景下为何是一个非常重要的因素(第4.1节),b)分析可能针对边缘范式的具体威胁(第4.2节),c)介绍适用于此特定背景的安全机制的需求与挑战(第4.3节)。
4.1. 安全在边缘范式中的重要性
如前所述,构建边缘范式生态系统面临的最大挑战之一是安全。原因有多个方面。首先,大多数边缘范式的 核心 都包含多种使能技术,例如无线网络、分布式和对等系统以及虚拟化平台[4]。因此,不仅需要保护所有这些构建模块,还需要协调各种安全机制。这本身就是一个复杂的问题,因为我们必须创建一个统一且跨领域的视图,以实现所有安全机制的集成和互操作性。
其次,整体大于部分之和:即使保障了所有使能技术的安全,也不意味着整个系统的安全就能得到保障。一旦将类云计算能力带到网络边缘,就会出现新的情况(例如异构边缘数据中心之间的协作、在局部和全局范围迁移服务),而这些情况的安全性尚未得到广泛研究。此外,我们还需要考虑这一特定场景下的具体需求(参见第3节),这些需求可能会影响可部署的安全机制类型。
例如,安全机制应尽可能自主,而不依赖于集中式基础设施的持续存在。原因主要有两点:一是某些情况下(如恶意攻击、间歇性连接、分布式应用)可能无法提供集中式控制系统;二是还需考虑安全机制本身的延迟问题。另一个例子是基础设施组件的技术限制。例如,某些边缘数据中心可能由微型服务器(如树莓派)组成,这些服务器缺乏商用服务器的硬件防护机制,或包含具有有限连接性的传统边缘设备——这限制了可部署的认证协议[12]。此外,安全机制还需考虑移动设备的存在,这些设备可以随时随地使用边缘数据中心。
第三,我们需要牢记,除了由于边缘范式特性而出现的安全威胁外,整个系统还继承了其构建模块和应用场景中存在的安全威胁。这并非微不足道的问题,因为这些威胁实际上非常严重。一个明显的例子是物联网,它是雾计算[18]存在的理由raison d’etre,也是所有边缘范式中的主要用例。物联网在安全性方面也被认为是“集所有世界之最坏情况的组合”:我们不仅需要整合并保护多层技术(从网络到移动再到云[62]),还需要在异构生态系统[63]中提供全局连接性和可访问性。这种情况产生了一个相当大的攻击面,进而也影响了所有使用物联网的范式。
最后,一次成功的攻击可能对我们的社会造成的冲击是相当巨大的。边缘范式可以应用的应用场景数量巨大。事实上,我们日常生活的几乎所有方面都可能受到部署在这些基础设施中的应用程序的影响:我们的私人信息(例如照片、医疗报告)、我们的日常活动(例如交通、购物)、我们的企业生态系统(例如工业、供应链)、我们的关键基础设施(例如能源、应急系统)等。如果没有适当的安全与隐私机制,边缘范式的种种优势将很快被恶意攻击者造成的损害所掩盖。
4.2. 威胁格局
在我们理解了边缘范式背景下安全的重要性之后,现在是时候分析可能针对这些范式的具体威胁以及它们可能造成的损害程度了。在不久的将来,这一分析将有助于我们开发出能够充分保护整个生态系统免受此类威胁的安全机制。此外,它还将使我们了解每种边缘范式的特殊性,因为它们之间存在细微差异,这些差异会影响安全机制的实现和部署。
然而,在分析威胁之前,有必要研究全局边界缺失如何影响边缘范式的安全。正如我们在前面章节中所看到的,在最封闭的范式——移动边缘计算中,整个生态系统也不会由单一所有者控制。更重要的是,边缘数据中心能够在不持续依赖中心化基础设施的情况下提供服务。因此,所有相关资产,包括网络基础设施、服务基础设施(例如边缘数据中心、核心基础设施)、虚拟化基础设施以及用户设备,并不由单一实体控制,而是由多个参与方(在某些情况下包括终端用户)共同掌控,这些参与方需要彼此协作。这种情况带来的后果是,基础设施的每个元素都可能在任何时候成为攻击目标或被破坏。事实上,这种“任何时间、任何事物”的原则也继承自一些底层构建模块和应用场景,例如物联网[63]。
话虽如此,“任何地点”原则(攻击可以从任何地方发起)在此特定情境下并不完全适用。其原因在于边缘数据中心的地理位置。这些范式的基本原则之一是,云计算能力基本上是在靠近终端用户的位置提供。因此,一个边缘数据中心(例如雾节点、MEC服务器)主要为本地实体(例如位于附近区域的移动用户、建筑物内的实体)提供服务。这一规则也有一些例外情况,例如充当代理并迁移到与其物理对应体相分离的其他基础设施的虚拟机,或由远程实体请求的特定本地服务。边缘范式的这一特性是一把双刃剑:一方面,它限制了攻击对本地环境的影响;另一方面,如果一个攻击者能够控制一个边缘数据中心,则其可能能够控制该地理位置所提供的几乎全部服务。
缺乏全局边界还有另一个后果:即针对边缘范式的不同攻击者画像的性质。即使传统的“外部”攻击者仍然存在(即不控制整个基础设施中任何元素的对抗者),也会有许多攻击者能够控制基础设施中的一个或多个元素:用户设备、虚拟机、服务器、网络部分,甚至整个边缘数据中心。这种情况类似于当前的互联网,恶意攻击者可以控制现有元素或部署自己的设备。这些对抗者既是“内部”的,也是“外部”的,因为他们只控制基础设施的一部分,而非全部。需要注意的是,这些攻击者仍可能试图影响基础设施中其他健康的部分。例如在协作过程中注入虚假信息,或部署恶意虚拟机,这些虚拟机会像病毒一样尝试利用其宿主机中的漏洞。不用说,传统的“内部”攻击者(即潜伏对抗者,如心怀不满的员工,他们被正式授权访问基础设施的某些部分)也将在该生态系统中存在。
4.2.1. 威胁模型
| 资产 | 威胁 |
|---|---|
| 网络基础设施 | 拒绝服务、中间人攻击、恶意网关 |
| 边缘数据中心 | 物理损坏、隐私泄露、权限提升,服务操纵、恶意数据中心 |
| 核心基础设施 | 隐私泄露、服务操纵、恶意基础设施 |
| 虚拟化 基础设施 | 拒绝服务、资源滥用、隐私泄露 权限提升,虚拟机操纵 |
| 用户设备 | 信息注入,服务操纵 |
表4:边缘范式中威胁的分类
在审查了潜在攻击者的性质和范围后,我们最终可以对威胁进行分析。在此分析中,我们将列举边缘范式最重要的资产,然后总结可能针对这些资产发起的攻击。需要注意的是,影响边缘范式的某些威胁与影响传统数据中心的威胁相同,因为两者共享多种资产(例如服务器集群、网络基础设施)。然而,在我们的分析中,仍需考虑边缘范式特有的去中心化和分布式特性,以及互操作性、移动性支持、位置等附加服务的存在。
网络基础设施。如前所述,边缘范式利用各种通信网络来互连其元素:从无线网络到移动核心网络和互联网。攻击者可能会试图针对这些通信基础设施中的任何一个。
- 拒绝服务(DoS) 。所有通信网络都容易受到多种拒绝服务攻击,例如分布式拒绝服务(DDoS)攻击和无线干扰。然而,这些攻击的影响范围有限。针对边缘网络的攻击只会扰乱受影响网络附近区域的通信。此外,对核心基础设施的攻击可能不会完全破坏边缘数据中心的功能,因为其协议和服务可以设计为以自主或半自主方式运行。
- 中间人 。恶意攻击者可能能够控制网络的某个部分,然后发起窃听和/或流量注入等攻击。斯托伊梅诺维奇等人[12]已证明了这种特定威胁的可行性。在这种情况下,连接两个 3G 和无线局域网的网关遭到破坏,攻击者获得了对网络接口的访问权限。这种攻击不仅非常隐蔽,而且非常危险,因为它可能影响通过该特定节点的所有元素(例如信息、虚拟机)。
- 恶意网关 。多种边缘范式的开放性使得用户拥有的设备也能成为完全的参与者(例如个人云子、参与附近设备集群的移动设备),从而导致恶意攻击者可以部署他们自己的网关设备。这种特定威胁所产生的结果与中间人攻击相同(例如具备窃听的能力)和/或注入流量),即使方式不同(入侵与部署)。
服务基础设施:边缘数据中心 。边缘数据中心承载了虚拟化服务器和多个管理服务等。然而,对于外部攻击者而言,边缘数据中心的攻击面相当广泛:从为所有参与者(例如用户、虚拟机、其他数据中心)提供服务的多个公共API,到Web应用程序等其他接入点。请注意,与虚拟化基础设施相关的具体威胁将在后文描述。
- 物理损坏 。在某些范式中,服务基础设施的组件可能未受到保护,容易遭受物理损坏。明显的例子包括由小型企业和用户设备组成的集群所管理的雾节点。对于这种特定威胁,攻击者必须位于设备附近才能将其破坏。因此,此类攻击极有可能被多个观察者目击。此外,此类攻击的影响仅限于本地范围:只有与特定地理位置相关的服务会受到影响。
- 隐私泄露 。内部攻击者和诚实但好奇的对抗者都可能试图访问流经边缘数据中心的信息。然而,这些攻击的范围是有限的:边缘数据中心主要存储和处理位于其附近区域的实体的信息,尽管在某些情况下(例如分布式存储服务、迁移的虚拟机)它也可能处理来自其他位置的数据。但请注意,由于边缘数据中心了解上下文[14],它们可能能够提取出关于用户的更敏感信息。
- 权限提升 。这些边缘数据中心巨大的攻击面使得外部攻击者可以尝试控制其各种服务。这种情况的产生是因为边缘数据中心可能由安全培训有限的专业人员甚至业余爱好者来管理。这些基础设施可能存在配置错误,甚至缺乏适当的维护。需要注意的是,内部攻击者也可能通过滥用其权限并利用其内部知识来实施此类攻击。
- 服务操纵 。一旦攻击者通过权限提升或滥用其作为合法管理员的权限,获得了对边缘数据中心某些部分的控制权,便可操纵数据中心的服务。由此,攻击者可发起多种类型的攻击,例如选择性拒绝服务攻击和选择性信息篡改等其他攻击。
- 恶意数据中心 。在此威胁中,攻击者能够通过多种手段(例如权限提升或部署自己的恶意基础设施)控制整个边缘数据中心。这将造成非常危险的情况,因为攻击者:i)完全控制在某一地理位置提供的所有服务;ii)可访问所有流向该恶意数据中心的信息流;iii)能够操纵与外部系统的所有交互(例如迁移的虚拟机、来自远程实体的服务请求)。
服务基础设施:核心基础设施 。所有边缘范式都可以由多个核心基础设施支持,例如移动核心管理系统和集中式云服务。因此,有必要分析在此特定背景下针对这些上层的具体威胁。需要注意的是,在某些范式(例如多接入边缘计算)中,核心基础设施将由部署边缘数据中心的同一公司(例如移动网络运营商)管理。此外,由于网络犯罪[64]和其他原因(例如政府入侵[65]),我们不应假设与云服务提供商的所有交互都完全可信。关于针对云服务提供商的一般威胁的完整分类法,可参见其他文献[66]。
- 隐私泄露 。我们无法保证在边缘基础设施的上层处理和存储的所有信息流都不会被未经授权的实体或诚实但好奇的攻击者访问。然而需要注意的是,这些内部攻击者可能无法访问完整的信息集,包括原始测量数据。原因很简单:由于底层的边缘数据中心会处理本地信息,因此上层很可能只接收到该信息的一个子集。此外,边缘范式允许边缘数据中心之间直接交换信息,从而绕过中央系统。
- 服务操纵 。拥有足够权限的内部攻击者不仅可能试图操纵信息流,还可能实例化提供虚假信息(例如虚假的管理信息、历史数据)给合作伙伴的恶意服务。但这种特定威胁遵循与隐私泄露威胁相同的原则:由于边缘范式的去中心化和分布式特性,这些内部攻击者将无法影响整个生态系统。
- 恶意基础设施 。该威胁假设核心基础设施的某些元素可能会受到专业对手的攻击。此类攻击可能控制基础设施上层的部分服务,从而对整个生态系统造成严重破坏。尽管攻击者成功发起此类攻击的可能性极低,但在特别敏感的情况下,仍需考虑此种情形,并部署专业的安全和容错机制。
虚拟化基础设施 。在所有边缘数据中心的核心部分,我们都能找到一种虚拟化基础设施,它能够在网络边缘部署云服务。与其他所有资产一样,该基础设施也可能以多种方式被利用。此外,我们还需要考虑到,虚拟机本身可能已被恶意攻击者控制,他们试图滥用或利用其所能访问的资源。
- 拒绝服务(DoS) 。恶意虚拟机可能会试图耗尽其运行所在的宿主机的资源(包括计算、网络和存储资源)。这一威胁在此特定情境下尤为严重,因为大多数边缘数据中心不具备其他云基础设施所拥有的丰富资源。
- 资源滥用 。恶意虚拟机可以执行各种恶意程序,这些程序的目标并非其所在的边缘数据中心,而是其他本地或远程实体。例如,恶意虚拟机可以在本地环境中搜索易受攻击的物联网设备。它还可以执行密码破解程序,或托管僵尸网络服务器。
- 隐私泄露 。由于设计上的需求,位于边缘数据中心的大多数虚拟化基础设施并不完全透明的:它们实际上可以实现各种提供物理和逻辑环境信息的应用程序编程接口,例如本地网络的状态。然而,如果这些应用程序编程接口未受到保护,恶意虚拟机可能会获取有关执行环境及边缘数据中心周边的敏感信息。
- 权限提升 。恶意虚拟机还可能试图利用其宿主机中的漏洞。此类攻击可能导致多种后果:从隔离失效(恶意虚拟机成功操纵其他虚拟机)到权限升级(恶意虚拟机控制宿主机的某些部分)。由于虚拟机可能因各种原因在不同数据中心之间迁移(例如用户从一个位置移动到另一个位置,或虚拟机作为代理运行),这一问题变得更加严重。
- 虚拟机操纵 。当主机系统被攻击者控制时(例如拥有足够权限的恶意内部人员,或已实现权限提升的虚拟机),可以对其内部运行的虚拟机发起多种攻击。这些攻击可能包括从提取信息到操纵虚拟机中正在执行的计算任务。此外,攻击者还可以在虚拟机中植入逻辑炸弹、恶意软件或其他恶意元素,一旦该虚拟机迁移到其他物理位置,就会威胁其他数据中心的安全。
用户设备 。由用户控制的设备也是整个生态系统的重要组成部分。它们不仅消费服务,还可以成为积极参与者,在不同层次上提供数据并参与分布式基础设施。然而,也会存在恶意用户,可能会以某种方式试图破坏服务。但需要注意的是,这些威胁的范围相当有限:在此背景下,用户只能影响其直接环境。
- 信息注入 。任何被攻击者控制的设备都可能被重新编程,在被查询时分发虚假信息(例如,车辆报告错误值,用户向众包服务提供虚假数据)。需要注意的是,由于传感器或内部系统的异常,设备也可能提供虚假值。
- 服务操纵 。在某些情况下,设备可能会参与服务提供。例如,由位于边缘数据中心的虚拟机控制的设备集群可以充当分布式计算平台。然而,如果攻击者获得对其中一台设备的控制权,则可能能够操纵服务的结果。
4.2.2. 范式之间的差异
在本节中,我们将利用第3节中定义的特性来分析前一节所述的威胁如何影响所有范式。其中一个对先前威胁的影响较为显著的特性是基础设施的所有权。在某些范式中,例如移动边缘计算,单个公司(移动网络运营商)不仅控制着位于不同地理位置的多个边缘数据中心,还控制着连接这些数据中心的部分核心网络(即移动网络基础设施)。原则上,该基础设施得到了良好的维护,具备一致的安全策略,并且能够防范物理和虚拟入侵者。正因为如此,攻击面应该更小,从而降低了攻击者破坏或控制部分服务基础设施的可能性。而其他范式,例如雾计算和移动云计算,则允许小型企业(如商店)部署自己的边缘数据中心,甚至允许用户成为服务提供的积极参与者。这形成了一个更加异构的生态系统,由于各种原因(如维护不足、有限的物理保护),其受到的保护可能不如大型公司部署的基础设施。
然而,由单个公司管理大部分服务基础设施也存在弊端。一个明显的例子就是成功攻击造成的影响。一旦攻击者控制了基础设施的某个部分,他就会成为该基础设施内部的内部攻击者。如果缺乏必要的应急机制,他可能会试图获取更多权限和/或利用其他漏洞,以获得更大的影响力。此外,如果内部攻击者控制了该公司核心网络的某些部分,则可能操纵整个生态系统中的大部分区域。另一方面,如果攻击者控制了一个由小型公司或技术娴熟的个人管理的边缘数据中心,其影响范围将仅限于该特定边缘数据中心的范围。
另一个对安全威胁有一定影响的特征是用于在边缘数据中心实现云服务的hardware。诸如移动云计算和Super- f luid Cloud等范式可以利用微型服务器(树莓派)和用户设备(手机)来提供其服务。目前,仍需分析某些微控制器的硬件扩展如何被用来保障安全虚拟化环境[67]。关于雾计算等范式中所使用的硬件,小规模部署中使用的商用服务器可以采用与云部署中使用的商用服务器相同的安全机制[68]。但需要注意的是,一些小规模部署可能缺乏经验丰富的技术人员,因此某些流程(例如安全策略的制定、角色分离、日志存储于独立的物理存储中)可能无法得到正确实施或维护。
关于部署基础设施的元素,我们已经提到,某些移动云计算范式允许在网络边缘创建设备集群,并且这些集群通过并行化等机制提供服务。因此,MCC范式具有一组额外的安全挑战[10],,例如恶意软件对用户设备的影响、不同对等节点的身份识别与认证,以及针对诚实参与者的拒绝服务攻击。此外,我们需要提及一个与网络架构密切相关的方面。所有范式都支持构建分层多层架构,其中不同的元素(用户设备、边缘数据中心、核心基础设施)具有不同的角色。因此,某些安全服务(例如认证、监控)可以以更集中或更分布的方式进行部署。每种方法都有其自身的优缺点。例如,如果一个集中式服务变得不可用或被攻击者控制,则除非有应急机制存在,否则整个基础设施将崩溃。最后,我们还需要考虑到,某些范式会使用其自身的协议和服务,例如在MEC环境中多接入边缘计算的小基站即服务(SCaaS)元素,它们将具有自身特有的安全需求(参见[69])。
4.3. 安全机制
为了针对不同威胁建立有效的防御层,部署各种类型的安全服务和机制至关重要。在本节中,我们将介绍应集成到所有边缘范式中的安全服务和机制,同时简要概述在此特定背景下的需求与挑战。请注意,所有安全机制都需要考虑各种常见的需求和限制,例如尽可能降低其操作的延迟,支持移动设备和其他移动实体(如虚拟机),实现技术、功能和语义上的互操作性,管理现有技术的局限性,并提供对离线操作的支持。
身份与认证 。在所有边缘范式中,存在多个参与者(终端用户、服务提供商、基础设施提供商)、服务(虚拟机、容器)以及基础设施(用户设备、边缘数据中心、核心基础设施),它们在一个存在多个信任域的生态系统中进行交互。这种情况带来了诸多挑战,因为我们不仅需要为每个实体分配一个身份,还需要允许所有实体相互进行认证。如果没有这些安全机制,外部攻击者将很容易肆无忌惮地针对服务基础设施的资源发起攻击。此外,内部攻击者在实施恶意行为后也不会留下任何证据痕迹。
在此背景下,有必要研究身份联合机制和跨域认证系统,这些机制和系统应能相互兼容。此外,由于存在各种需求(如延迟、中央服务器的可用性),理想情况下,实体能够在不与中央服务器通信的情况下提供其身份证明(例如,出示有效且可信的属性)。然而需要注意的是,在某些情况下,部分基础设施可由终端用户管理(例如个人云点),甚至以点对点方式交互。因此,我们应研究分布式认证机制的适用性。
Access Control Systems 。授权基础设施的存在对于边缘范式同样重要,因为必须验证各个实体的凭证,以授权其执行某些操作的请求(例如,服务提供商部署虚拟机、虚拟机访问边缘数据中心的应用程序编程接口、边缘数据中心之间相互交互)。如果没有适当的授权机制,任何没有正确凭证的人都可能滥用虚拟化基础设施的资源。用户将能够冒充管理员并进行控制基础设施的服务。恶意攻击者将能够访问任何资源,包括专有和/或个人信息。其可能性将无限。
由于边缘范式的固有特性,必须在每个信任域中部署授权基础设施,以便这些域的所有者能够传播、存储和执行其自身的安全策略。原则上,此类基础设施应能够处理任何实体的凭证,前提是它们之间存在信任关系。此外,在定义认证策略时,还应能够考虑各种因素,例如地理位置和资源所有权。例如,如果迁移的虚拟机拥有特定权限(例如由本地执法机构拥有),则可能被允许使用虚拟化基础设施中的额外资源。
协议与网络安全 。如果网络基础设施未受到保护,整个服务生态系统将面临来自内部和外部恶意对抗者的威胁。因此,有必要保护边缘范式所使用的各种通信技术与协议。例如,存在多种无线通信技术(如Wi‐Fi、 802.15.4、5G、Sigfox、LoRa),这些技术可能被用于服务本地客户。因此,边缘数据中心及其管理员需要理解并利用这些技术所实现的安全协议与扩展。此外,边缘范式还需要配置并集成核心基础设施所使用的安全协议(如公共互联网、移动网络基础设施)。同时,我们还需要在虚拟化基础设施中为租户提供网络隔离,以及其他防护机制。
这里存在各种需要解决的挑战。首先,必须对网络基础设施的不同元素进行适当配置。然而,所有这些元素将部署在不同的地理位置,并由不同的管理员进行管理。此外,还可能出现属于不同信任域(例如来自不同基础设施所有者的边缘数据中心)的实体相互交互的情况。在这种高度异构的场景中,我们需要在可能使用不同通信技术的实体之间建立安全连接。还有其他同样重要的方面,例如在安全机制的强度与网络整体服务质量之间实现动态平衡。
信任管理 。对于边缘范式而言,另一个非常重要的安全机制是信任。在此背景下,信任的概念超越了“不知道我正在与谁交互”的范畴,后者通常通过实施认证机制并在信任域之间建立信任关系来解决。原因很简单:我们还必须应对不确定性的概念,即“不知道我的合作方将如何行为”。所有实体都有多种可用的协作对等体:用户在其附近区域可以有多个可用的服务提供商,服务提供商可以选择多个基础设施提供商,等等。然而,这些对等节点可能无法满足我们的期望:服务延迟可能较高,异常检测率可能较低,或者数据可能不准确。更糟糕的情况是,对等节点可能会表现出自私或恶意的行为。
因此,有必要认真考虑在此背景下部署信任管理基础设施。其优势众多:从改善所有实体的决策过程(例如,将高优先级虚拟机迁移至声誉较高的较近边缘数据中心),到加强个人数据管理(例如,降低向低声誉实体传输的信息粒度)等。然而也存在诸多挑战。所有信任管理基础设施应能够相互交换兼容的信任信息,即使它们位于不同的信任域中。另一个问题在于信任信息的存储与传播,因为这些信息应能够随时随地以尽可能低的延迟被访问。此外,由于基础设施的动态性,非恶意实体可能因临时原因而面临低声誉的情况,因此必须在惩罚与恢复之间找到平衡。
入侵检测系统 。谈到恶意实体,我们已经在第4.2.1节中了解到,外部和内部对手可以在任何时间攻击任意实体。如果没有适当的入侵检测和防御机制,任何成功的攻击都将无法被发现,从而逐渐破坏整个基础设施的功能。因此,必须确保整个基础设施都被此类防御机制所覆盖。幸运的是,我们也已经看到,“无处不在”的原则在这些范式中并不完全适用:大多数攻击的影响通常局限于本地环境。因此,本地基础设施(如边缘数据中心)可以负责监控其所有元素——网络连接,虚拟机等——及其周围环境。此外,这些本地基础设施还可以相互协作,或与位于网络层次结构更高级别的核心基础设施协作。通过这种方式,可以检测针对服务基础设施大范围的攻击。
然而,在异构、去中心化和分布式基础设施中运行由检测与防御机制互连而成的网络面临着诸多挑战。需要充分理解针对边缘范式的具体攻击方式。如果使用攻击数据库(例如用于基于特征的入侵检测系统),则必须始终对其进行更新和保护。需要在本地与全局防御机制之间实现平衡,并构建涵盖多个层次和/或信任域的全局监控基础设施。此外,所有防御机制无论其位置如何,都必须能够以互操作格式相互交换信息。此类信息应持续可用,以便检测更具持续性的威胁。最后,防御机制必须尽可能自主地运行,以降低维护开销并提升安全基础设施的可用性。
隐私 。除了恶意攻击者之外,还可能存在诚实但好奇的攻击者。这些攻击者通常是被授权的实体(例如边缘数据中心、基础设施提供商),其次要目标是了解更多关于使用其服务的实体的信息。这些信息随后可能以多种方式被利用:使用行为分析、位置追踪、敏感信息泄露等。所有这些攻击者都对用户的隐私构成威胁。不幸的是,所有边缘范式都是开放生态系统,其中多个信任域由不同的基础设施所有者控制。在这种情况下,无法提前确定某个服务提供商是否值得信赖到足以尊重用户隐私的程度。因此,这是一个必须认真考虑的严重威胁。
该领域存在各种挑战。首先,个人数据将由用户无法控制的实体进行存储和处理。因此,必须为用户提供各种高效机制,这些机制不仅要保护其信息,还要允许用户对其信息进行查询和处理(例如可审计数据、受控披露)。其次,需要在匿名性与责任性之间实现平衡。在这种动态环境中,用户有权保护其身份和个人数据,但同时也有责任诚实守信地行事。如果一个用户出现异常行为,应能够使用某些机制来识别恶意方。最后,我们需要考虑到人类的移动性实际上具有相当高的可预测性(参见[70]):我们通常前往相同的地点,每天遵循相同的日常规律。因此,用户很可能会反复使用相同的边缘数据中心。这对旨在保护用户位置和使用服务隐私的隐私保护机制的开发提出了挑战。
虚拟化 。虚拟化基础设施是边缘范式的核心要素之一,因此必须通过在所有边缘数据中心设计和部署安全机制来保护它。如果没有这些安全机制,不仅恶意内部人员可能控制用户部署的虚拟机,而且恶意虚拟机也可能操纵边缘数据中心的服务。可以在所有商用服务器上实施多种对策,例如隔离策略、虚拟机监控程序加固、角色和虚拟机的分离、网络抽象以及许多其他措施[68]。但需要注意的是,任何依赖于限制物理访问的机制在此环境下可能难以实施。
容错与弹性 。没有任何范式能够做到百分之百安全并免受威胁,边缘范式也不例外。配置错误、漏洞、过时软件以及其他弱点将使恶意攻击者得以禁用或控制整个基础设施的某些部分。因此,有必要集成多种机制和策略(例如冗余操作、故障转移能力、灾难恢复机制),以确保服务基础设施能够持续执行其预期功能。然而,在网络边缘部署边缘数据中心是一把双刃剑:一方面,保护机制可以利用同一位置可能存在多个基础设施提供商的优势;另一方面,由于服务是在本地层面提供的,可能会出现无替代资源可用的情况。
取证 。正如我们已经提到的,无论采取何种保护机制,边缘范式都可能遭受成功的攻击。这些攻击会留下某些证据,可用于揭示攻击者及其方法的相关信息。取证的目标是识别、恢复和保存这些证据,以便能够在法庭上呈示。在边缘范式中对证据的管理是一个非常复杂的问题,主要由于存在多个参与者、基础设施、技术和场景。然而,有可能利用相关领域的现有研究(例如云取证(参见[71, 72, 73]))来解决某些问题,例如移动取证、虚拟化取证和存储取证。
此外,王等人[17]和扎沃德等人[74]分别对雾计算取证和移动云计算取证的主要需求进行了详细分析。这两项研究都认为该领域存在多种共同挑战,例如:i)在具有多个信任域的分布式生态系统中存储可信证据;ii)在获取和管理证据时尊重其他租户的隐私;iii)维护证据的证据链。此外,两项研究均认为边缘数据中心在管理潜在证据时所需的计算资源较少:由于其地理位置和本地范围,它们所管理的资源(如网络流量、虚拟机)少于集中式云基础设施。
5. 安全挑战与机遇
在前面的章节中,我们回顾了所有边缘范式之间的相似性与差异性,并对可能针对这些范式的威胁以及应采用的安全机制进行了详细分析。在本节中,我们将对所有边缘范式中的安全现有技术进行分析(第5.1节),并通过对现有不足之处和潜在研究领域的讨论来总结该分析(第5.2节)。
与第3.2节类似,我们将在分析中指出所有边缘范式之间可能存在的协同效应。但需要注意的是,我们的分析还将考虑其他相关范式(例如云计算、网格计算、点对点计算)以及边缘范式所使用的一些使能技术(例如无线网络、分布式和对等系统、虚拟化平台[4])。这其中有多个原因。为相关范式设计的安全机制所依据的某些基本假设,并不与边缘范式的需求相冲突。例如,某些对等节点安全机制仅需要一个能够相互通信的对等节点去中心化基础设施。其他安全协议则独立于实现它们的底层技术,因此可以轻松地适应其他环境。此外,一些安全机制这些机制在设计时考虑了特定场景,但其功能单元可轻松映射到边缘范式场景中。例如,某些面向网格计算的信任管理系统的安全组件仅假设位于不同管理域的宿主机能够安全地交换信任信息。这些构建模块可映射到一种边缘范式场景中,即属于不同信任域的多个边缘数据中心以安全的方式交换信息。显然,在将所有这些安全机制应用于边缘范式时,必须进行充分分析而不能直接套用,但它们表明研究人员在为边缘范式设计安全机制时无需从零开始。
5.1. 具体挑战与有前景的解决方案
5.1.1. 身份与认证
目前,尚无研究工作分析如何识别和认证由不同公司和个人拥有的、相互连接的全球边缘数据中心基础设施中的成员。然而,可以尝试在其他相关领域(如联邦云计算和点对点计算)中寻找该问题的解决方案。事实上,已有多种方法致力于构建跨云身份管理系统[75]。这些方法利用多种标准(如安全断言标记语言(SAML)和开放身份验证(OpenID)),以实现云之间的单点登录(SSO)认证。至于点对点计算,也存在多种机制可在无需连接中央认证服务器的情况下实现相互认证[76]。由于这些方法的设计与边缘范式的底层基础设施相兼容,因此它们均可能被调整用于处理属于不同信任域的边缘数据中心的认证。
另一方面,存在一些认证基础设施,专注于同一信任域内的用户认证,明确针对边缘范式设计。例如,唐纳德等人[77]定义了一种用于移动云计算的集中式基础设施,其中单一可信第三方充当认证服务器。然而,这种方法要求认证服务器始终可访问,因此其适用性受限。在另一项工作中,易卜拉欣[78]开发了一种用户认证系统,允许雾用户与雾节点相互进行认证,但该方法迫使所有雾节点存储信任域内所有用户的某些凭证信息。在移动云计算领域还有其他研究工作[79]以及雾计算[12],即使认证服务器无法访问,也能以较低的开销对用户进行认证。这是通过使用配对密码系统和安全硬件[79], ,或采用混合加密(公钥和对称密钥加密)[12]实现的。尽管这些机制主要关注用户认证,但它们也可能适用于对属于同一信任域的边缘数据中心联盟进行认证。
具体而言,关于用户认证,由于边缘数据中心位于终端用户的附近区域,研究人员提出了多种利用位置特定信息的认证方案。例如,在联邦移动云计算的背景下,邵怀等[80]提出了情境认证的概念,该概念基于“你与谁在一起”、“你在哪里”以及“现在是什么时间”等要素。其他作者,如布泽弗兰[81],,则使用近场通信(NFC)来验证移动设备是否正在向授权的本地云粒进行任务卸载。需要注意的是,基于位置的认证概念已在多个其他领域(例如无线传感器网络[82], 物联网[83])中得到研究,提供了多种可适配于边缘范式的机制。
关于用户移动性,已有一些协议尝试在移动云计算(MCC)场景中实现安全高效的切换认证。例如,杨等[84]提出了一种高效的设计,允许移动客户端从一个区域迁移到另一个区域。需要注意的是,这些协议通常需要访问集中式云基础设施中的认证服务器,因此仍有改进空间。最后,某些边缘范式允许用户部署自己的个人数据中心。因此,一些研究工作(如 OPENi框架[85],)探讨了如何在这样的个人云粒平台中授予外部用户访问权限。在OPENi中,认证组件使用了OpenID Connect认证层以及其他机制。因此,云粒所有者可以决定信任哪些认证服务器,并确定哪些用户被允许访问云粒资源。
5.1.2. 访问控制系统
在边缘范式背景下,研究细粒度访问控制机制开发的文献非常少。其中一个例子是前一节提到的OPENi框架[85], ,该框架中的授权基于 OAuth。2.0,云粒所有者通过在NoSQL数据库中创建和存储访问控制列表( ACL)来定义每个资源的访问权限。这种方法更适合个人云点,在这种情况下,所有者可以定义特定用户对资源执行的操作。其他方法,例如黄等人[86]提出并由斯托伊梅诺维奇等人[12],使用的方法,则采用基于属性的加密(ABE)等密码学原语来实现基于属性的访问控制策略。在这种方法中,用户被赋予某些属性,而访问控制规则将这些属性与可在资源上执行的操作关联起来。该机制适用于单一信任域,服务提供商可利用这些属性(连同其凭证)获得在边缘数据中心部署虚拟机的权限。
其他作者已探讨了策略实施组件的部署以及安全策略的管理。一个简单的例子是瓦西拉基斯等人[87],所定义的架构,该架构利用形式化方法在移动边缘计算小型基站中部署安全组件。这些组件为各种移动边缘计算服务(如无线资源和虚拟化服务)提供保护和访问控制。然而,最突出的例子之一是德索萨等人[88]设计的用于雾计算的策略管理框架。在此框架中,雾架构的编排层由一个策略管理模块支持,该模块定义了多个组件——包括规则库、属性数据库和会话管理员。此外,策略可以在多个层级上实施,例如边缘数据中心、虚拟机实例和物联网设备。该策略管理框架除了需要存在核心基础设施外,并无特殊的架构要求,因此可应用于移动边缘计算等其他范式。
关于其他相关范式中联邦式和分布式访问控制架构的存在,实际上已有大量文献对此进行了研究[89, 90]。其中一些机制或许可被调整以适用于我们的场景,从而解决当前存在的开放性问题。例如,阿尔穆泰里等人[91]提出了一种面向多云环境的分布式访问控制架构,该架构基于基于角色的访问控制(RBAC)政策,并提供了跨域角色映射和约束验证功能。该方法可用于连接属于不同信任域的多个实体。此外,还有一些安全机制虽然并非为边缘范式设计,但在某些场景下可能同样适用。例如,带属性的直接匿名证明(DAA‐A)协议 cols 允许匿名用户证明其拥有某一组可信属性。这些协议可以使用可信平台模块2.0 (TPM 2.0) 规范[92], 中定义的原语来实现,因此可应用于两个边缘数据中心需要证明其具有某些属性(例如位置、能力)而不披露其所有者身份的场景。
5.1.3. 协议与网络安全
边缘范式所使用的所有通信技术要么是成熟的标准(例如TCP/IP协议栈、Wi‐Fi),要么正在由工业界和学术界广泛研究(例如5G、Sigfox)。这些技术定义了各自的安全协议和机制,能够在两个经过认证的实体之间提供隐私性和数据完整性。该领域的一个挑战是如何分发用于协商会话密钥的凭证。尽管已有可用的解决方案,但仍需进一步研究。例如,由一个基础设施提供商控制的指定认证机构可以向其信任域内的所有元素分发凭证。密码学属性(如[86],中使用的属性)也可用作凭证以交换会话密钥[93]。此外,在多个不同领域已有若干研究工作,例如联邦内容网络[94],,
13万+

被折叠的 条评论
为什么被折叠?



