Fog Computing. Группа авторов
Читать онлайн книгу.
1.5.5.3 Security Monitoring and Management
The system must be capable of observing security state in the network and reacting to new threats via monitoring and management mechanisms. Security management should allow definition and updating of security policies and propagation of the policies over the network in real-time.
In addition to policy management, identity and credential management is a requirement. In addition to the necessary registration and credential storage functions, an MFC system must handle the challenge of authentication and access control in situations with intermittent connectivity, e.g. negotiating session keys when crossing different trust domains while ensuring data integrity and privacy [67]. Security monitoring, on the other hand, should collect log traces while ensuring their integrity.
The OpenFog security requirements define at least two logically separate security domains: (1) policies concerning the collection of Fog entities within the system that can interact with one another and (2) for policies regarding the individual services and applications being executed and provided on the platform.
1.5.5.4 Trust Management and Multitenancy Security
Managing trust. The information flows in MFC raise the issue of how to determine which nodes in the network are trustworthy for a particular client and request? Trust management frameworks need to manage trust assessment of both devices and applications and be able to adjust to the real-time updates of trust-related data, such as social relationships and execution results [68]. Some scenarios may also require decentralized trust management achievable with the help of blockchain technology; however, this aspect has issues with latency [69].
Multitenancy. As the fog architecture dictates that fog platforms can host services for multiple parties, this poses the issue of how to ensure isolation in the runtime environment and ensure that only data that was intended to be shared is available across the instances [61, 70]. Secure isolation of tenant and user space continues to be a challenging requirement, as vulnerabilities allowing adversaries to access memory of other tenants VMs without permission [71] have surfaced, even in mass-produced CPUs.
1.6 Open Challenges
Fog computing has been introduced to overcome many challenges that cloud computing was incapable of handling, such as latency-sensitivity, connectivity between the large set of cloud-based applications, etc. Therefore, many researchers investigated and proposed different architectures for introducing fog computing into the traditional cloud computing to create an extension of the existing design. This action resolved into solving some of the old obstacles and generate new perspectives and ambitions that led to new challenges.
1.6.1 Challenges in Land Vehicular Fog Computing
Introducing the cloud computing into VANET was redemption since it provided a solution to most challenges that traditional design of VANET faced, such as decreased flexibility, scalability, poor connectivity, and inadequate intelligence [72]. However, the new generation of VANET has introduced new requirement with respect to the high mobility, low latency, real-time applications, and reliable connectivity. For all these reasons, adding fog computing to the equation has emerged as a potential solution. Based on the existing research it seems that there are still some obstacles to be dealt with, for example, the management of fog server in geographically distributed fog nodes. The difficulty relies on the positioning of each edge server in a given area, which is important for fog approach and it considers many parameters, such as vehicles density, traffic status data, and processing load on the servers. Another challenge is related to management of neighboring fog servers with respect to communication and access, which can be affected by the environment. Finally, the assessment and handling dissemination of real-time critical message can be problematic, since design should be capable of distinguishing between a true or false event [73].
1.6.2 Challenges in Marine Fog Computing
Existing works [4, 28] have proposed the frameworks for improving the efficiency of the communication and for application management in the hybrid MFC environment that consist of both iFog and mFog nodes. Essentially, comparing to the UAV-Fog nodes and the UE-fog nodes, the Marine Fog nodes do not have the resource-constraint issue in terms of computation and data storage. However, because the operating marine environment lacks infrastructure, the communication between the Marine Fog nodes and the distant central cloud faces the latency issue derived from the limitation of the underline network topology and technology. For example, the bandwidth of the common VHF radio used in maritime communication can reach only 28.8 kbps and the range of the infrastructure-less 4G/5G LTE device-to-device communication is unable to fulfill the need of a marine environment. In order to overcome the fundamental communication issue, developers may consider integrating UAV-fog nodes [31] in which the system can deploy the UAV-fog nodes between vessels to form a mesh network toward dynamically supporting better bandwidth and more stable connection. However, UAVs have a limited available operation time slot because they are battery-powered. The system needs to introduce an adaptive scheduling scheme, physical location placement scheme. Further, the system needs to dynamically adjust the movement of the UAV-fog nodes based on the interconnected vessels in order to seamlessly maintain the mesh network.
1.6.3 Challenges in Unmanned Aerial Vehicular Fog Computing
Current works in UAV mFog [32, 52] were focusing on the underlying system design and communication mechanisms. Although UAV-Fog nodes have many potential applications due to the features in terms of fast deployment, scalability, flexibility, and cost-efficiency [31], integrating UAV-Fog nodes to pervasive computing systems or IoT systems raises many new challenges besides the underlying communication mechanisms. Specifically, existing works have not fully addressed the requirements for both tenant and provider. For example, although an existing work [63] has proposed schemes that enable UAV-Fog nodes to perform data-driven service handover, which transfers the client data from one UAV-Fog node to another, this scheme was designed for a domain-specific application in which the author assumes the system has preinstalled the application to all the UAV-Fog nodes and hence, at runtime, the UAV-Fog nodes need only to transfer the client data in order to support the mobility. On the other hand, considering the multitenancy fog service model, preinstalling applications to the UAV-Fog nodes for all the tenants will cause a high burden to the storage size, especially when the application involves large size files. Therefore, UAV-fog nodes require the mechanism that supports rapid and dynamic application management in terms of task allocation/placement and task migration.
1.6.4 Challenges in User Equipment-based Fog Computing
There exist a large number of frameworks designed for supporting mobile UE from iFog. However, existing works rarely address the challenges in UE-fog nodes. The use cases described in the previous section indicate that systems which integrate UE-fog nodes require a dynamic program deployment mechanism. For example, in the advanced crowd sensing use case, which utilize UE-fog nodes to provide the interpreted context information derived from the collected sensory data, the UE-fog nodes need to provide the corresponding service that allows the clients to deploy the program code of the context reasoning algorithm on the UE-fog nodes. Explicitly, considering the UE-fog nodes have constraint resources, they are unable to support the common VM or containers engine-based service for the dynamic program deployment. Instead, developers generally would develop the standalone solutions which leave the interoperability as an unsolved problem in UE-fog. In order to address such an issue, developers may consider integrating an open standard–based service interface or to develop a specific mobile fog node description language based on the extension of existing cloud service-based standard, such as OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA).
1.6.5 General Challenges
1.6.5.1 Testbed Tool
The