EP2460071A2 - Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité - Google Patents

Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité

Info

Publication number
EP2460071A2
EP2460071A2 EP10752854A EP10752854A EP2460071A2 EP 2460071 A2 EP2460071 A2 EP 2460071A2 EP 10752854 A EP10752854 A EP 10752854A EP 10752854 A EP10752854 A EP 10752854A EP 2460071 A2 EP2460071 A2 EP 2460071A2
Authority
EP
European Patent Office
Prior art keywords
virtual machine
data
virtual machines
software component
security
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP10752854A
Other languages
German (de)
English (en)
Inventor
Severine Vermande
Philippe Biondi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus SAS
Original Assignee
Airbus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Airbus SAS filed Critical Airbus SAS
Publication of EP2460071A2 publication Critical patent/EP2460071A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control

Definitions

  • the present invention relates to data processing systems, including aircraft information system data, and more particularly to a software component and a device for the automated processing of multi-purpose data, implementing functions requiring different levels of security or limits of liability.
  • airlines have the regulatory obligation to implement technical and organizational means to maintain the level of safety of the elements of an aircraft as determined upon delivery of the aircraft. This regulatory obligation covers only physical security and not logical security.
  • the data manipulated by the operational software applications implemented in the STADs can be downloaded, calculated, displayed and / or transmitted. Because of the security constraints mentioned above, there are strong security needs in terms of confidentiality, integrity and / or availability thereof.
  • the invention solves at least one of the problems discussed above.
  • the invention thus relates to a computer software component adapted to the automatic processing of multi-purpose data, the software component implementing functions requiring different levels of security or limits of responsibility and including,
  • each virtual machine being adapted to perform at least one function requiring a predetermined level of security or a predetermined limit of responsibility;
  • a hypervisor adapted to control the execution of said plurality of virtual machines.
  • the software component according to the invention thus makes it possible to implement functions having different levels of safety or limits of responsibility in the same machine, independently of the hardware platform and the information system architecture used on board. aircraft. Publishers of software applications implemented are no longer dependent on the evolution of operating systems and master the life cycle of these applications.
  • the software component can thus be implemented on a mobile STAD market, according to a list of hardware compatibility. Since the limits of responsibility are clearly identified, it can receive software applications from suppliers and the user. Such a STAD can be attached to an aircraft or a user.
  • the use of the software component according to the invention does not increase the need for maintenance compared to a single-use equipment, mobile or not. It ensures a good level of segregation as well as a good level of security including the integrity of operational data. It makes it possible to control the sharing of resources between the various functions while being relatively independent with respect to the lack of reliability of the commercial products implemented.
  • said hypervisor comprises authentication means for authenticating at least one virtual machine of said plurality of virtual machines in order, in particular, to check the validity of transmitted data.
  • said authentication means are preferably adapted to verify the integrity of said at least one authenticated virtual machine.
  • said authentication means are advantageously adapted to verify the isolation level of said at least one authenticated virtual machine with respect to at least one other virtual machine of said plurality of virtual machines in order, in particular, to check the validity of data passed to other virtual machines.
  • the software component further comprises data storage means processed by least one virtual machine of said plurality of virtual machines, said storage means being adapted to store said processed data in a removable memory of said computer.
  • the software component according to the invention thus makes it possible to store data whose level of confidence is not sure without compromising it.
  • Such data storage means are preferably implemented by virtual machines of said plurality of virtual machines whose security level is below a predetermined threshold.
  • the software component further comprises means for controlling a level of confidence of at least one piece of data processed by at least one virtual machine of said plurality of virtual machines, said at least one piece of data processed. can not be stored locally in said computer until it has been checked.
  • the software component according to the invention thus makes it possible to store locally only data whose level of confidence is safe so as not to compromise it.
  • the software component further comprises data transfer means between a first and a second virtual machine of said plurality of virtual machines, said transfer means being adapted to filter data transferred if the level of security of said second virtual machine is greater than the security level of said first virtual machine to validate the data exchanged, in particular according to their type or the need for access to these data.
  • configuration data used to start at least one virtual machine of said plurality of virtual machines are not modified during the execution of said at least one started virtual machine in order to facilitate maintenance of the virtual machine. software component and allow it to restart from a stable and validated state.
  • the invention also relates to a device comprising means adapted to the implementation of each of the elements of the component previously described software whose advantages are similar to those mentioned above.
  • FIG. 1 shows schematically an example of environment in which can be used a multi-purpose automated data processing system implementing the invention
  • FIG. 2 illustrates an exemplary architecture of an automated multi-purpose data processing system according to the invention
  • FIG. 4 schematically illustrates certain steps implemented to analyze the risks associated with the functions that must be performed on the same STAD
  • FIG. 5 schematically illustrates an exemplary algorithm for distributing software applications implemented in a STAD in virtual machines according to the functions they use;
  • FIG. 6 shows an example of a device for implementing at least partially the invention.
  • the invention makes it possible in particular to replace the single-use automated data processing systems (STAD), mobile or fixed, used today for maintenance and mission, by a single secure STAD, preferably mobile.
  • STAD single-use automated data processing systems
  • FIG. 1 schematically represents an example of environment 100 in which a multi-purpose automatic data processing system embodying the invention can be used.
  • a STAD 105 can be used by a crew member in an aircraft 110 for example to run flight management software applications.
  • the same STAD 105, or a similar STAD 115, can be used by a maintenance team to access the maintenance data of the aircraft 110 and / or to update data or software applications of the aircraft.
  • the same STAD 105, or a similar STAD 120 can be used in the airline's offices 125, for example for the preparation of a flight.
  • the same STAD 105, or a similar STAD 130 can be used by its owner to access office applications and e-mail from, for example, a network access of a hotel 135.
  • the operational applications, the office applications and the personal applications of a STAD are thus hosted in several virtual machines implemented in the STAD, according to the needs of security levels and preferably by responsibility.
  • a virtual machine offers a runtime environment with its own configuration characteristics.
  • two virtual machines can be considered as two independent physical machines.
  • Each virtual machine runs with its operating system, its drivers (called drivers in English terminology), its software applications and its configuration management and data exchange.
  • a virtualization mechanism allows the execution of several virtual machines on a real machine using a hypervisor.
  • the hypervisor is responsible for sharing the resources of the real machine and enforcing resource access control rules.
  • the resources shared between the virtual machines are, for example, the computing power CPU (acronym for Central Processing Unit in English terminology), the communication channels, the interrupts hardware and software, input / output ports, memory, clocks, system buses, controllers and / or mass storage.
  • the invention is based on the use of a standard hypervisor, personalized to manage the virtual machines according to predetermined rules.
  • the virtualization implemented here is a hardware virtualization, for example a complete virtualization according to which the hypervisor manages all the requests of the virtual machines or a paravirtualisation according to which certain requests are managed directly by the virtual machines.
  • virtualization software tools adapted to real time are used for their benefits in terms of performance and security level.
  • virtualization makes it possible, for embedded systems, to optimize the weight of the computer hardware implemented including servers, switches and cabling, as well as a reduction in electrical consumption as well as a simplification of deployment and maintenance procedures, which is particularly advantageous in an aeronautical environment.
  • FIG. 2 illustrates an exemplary architecture of a STAD according to the invention, which is sufficiently safe to be used in environments having different levels of security.
  • the STAD 200 here comprises a hardware layer 205.
  • PDA personal digital Assistant
  • the hardware layer to be trusted can consist of an open platform of PC type whose level of confidence is improved by the use of an authentication module called TPM (acronym Trusted
  • the hardware layer 205 allows the execution of a software layer 210 comprising the hypervisor. It allows to run multiple machines separate virtual machines, for example virtual machines MV1, MV2, MV3 and MVx, referenced 215-1, 215-2, 215-3 and 215-x, respectively.
  • a first virtual machine here the virtual machine 215-1, has a particular role and rights. This is the administration machine that serves as access for the maintenance and configuration of the platform. It uses an OS1 operating system here. Still according to this example, the virtual machine 215-1 includes a storage space, or mass memory, and a communication interface, denoted I / O (acronym for Input / Output in English terminology).
  • a second virtual machine here the virtual machine 215-2, allows the STAD to connect to the most sensitive information system, that is to say that of the aircraft.
  • the display associated with this virtual machine may be directed to the STAD screen or aircraft-specific displays according to, for example, a standard graphical user interface of the client / server type.
  • the virtual machine 215-2 here uses the OS2 operating system and an input / output interface for exchanging data with the aircraft information system via a cockpit docking type link.
  • the virtual machine 215-2 makes it possible to execute operational applications.
  • the devices that are available in this environment and the administrative rights must be precisely defined to ensure the required level of security.
  • a third virtual machine allows the STAD to connect to insensitive information systems, here systems separate from the information system of the aircraft.
  • the virtual machine 215-3 allows the STAD to access an internal network of the company operating the STAD or the Internet, for example at a WiFi access point of a hotel.
  • the risks associated with the virtual machine 215-3 are higher than those of the virtual machines 215-1 and 215-2 because it is open to environments likely to be a source of compromise.
  • This virtual machine can therefore be a target for malware, called malware in English terminology.
  • software applications and the drivers implemented in this virtual machine are a priori standard software, they represent potentially known faults.
  • a virtual machine 215-x can be used for the execution of software applications requiring a level of security equivalent to that of the virtual machine 215-2 but whose provider is different from that of the applications running in virtual machine 215-2.
  • a single STAD it is possible to use a single STAD.
  • the execution level is constrained in the user space at the start of the STAD so that the administration rights are not accessible.
  • the login banner is preferably disabled to prevent a user from exiting the virtualization layer. It only accesses virtual machines.
  • the sequence of start keys is deactivated.
  • hardware virtualization features are implemented in the STAD processor, they are configured so as not to degrade the expected level of security.
  • the STAD When the STAD starts or when it is activated, for example after a standby, the user is authenticated. Such authentication is here performed by the hypervisor. Access to virtual machines depends on this authentication. Thus, for example, a pilot and a co-pilot will be able to access all the virtual machines implemented on a STAD, with the exception of the administration virtual machine used to configure the STAD, while a maintenance technician will be able to access this. last.
  • Virtual machines can be launched automatically when the STAD is started or when the user requests it. Each virtual machine can be started and stopped independently, depending on the needs of the user. It can pass from one virtual machine to another according to a standard mechanism, for example via a graphical interface. According to a particular embodiment, the functions implemented in the virtual machines are adapted according to certain parameters such as the level of safety of the virtual machine in which they are executed.
  • FIG. 3 schematically illustrates an example of adaptation of certain functions executed in virtual machines according to these parameters, as a function of the type of function (step 300).
  • the virtual machines go through an authentication phase to connect to certain systems external to the STAD (step 305), for example to an information system of an aircraft.
  • This authentication phase implemented by the hypervisor during the launch of the virtual machine and / or data exchange, comprises the following steps,
  • step 310 authentication of the virtual machine according to a standard authentication mechanism
  • checking the integrity of the virtual machine by checking, for example, several security criteria such as the operating system and the date of last update (step 315); and,
  • step 320 checking the isolation level of the virtual machine with respect to the other virtual machines according to the functions implemented. This step makes it possible to verify that no other virtual machine can interact with the one whose authentication is requested, for example via the user interface or the network, when the virtual machine is connected with a system of an aircraft. Alternatively, this step may consist in checking compliance with predetermined communication rules.
  • the data are effectively transmitted (step 325) only after authentication of the virtual machine so that it can not transmit erroneous data to an external system.
  • the transfer of data between virtual machines is controlled to ensure the required levels of security. Indeed, whether they have been isolated for purposes of limit of liability or levels of different functions, some functions may require a transfer of data between virtual machines and thus the setting of a communication channel.
  • an import function is created to validate the data transiting to a virtual machine having a higher security level than that of the source virtual machine (denoted MV * in FIG. 3).
  • the principle of this function is in particular to filter the data according to their type (step 330) and to ensure that only the expected data (step 335) pass through the open communication channel (step 325).
  • the user remains master of the validation, that is to say the effective transfer of data from one virtual machine to another having a higher level of security.
  • snapshots in English terminology
  • the snapshot feature allows all virtual machine data to be stored at a particular time so that the virtual machine can be relaunched and reconfigured later to return to the state it was in when the data has been stored as a photograph.
  • This function may be activated by a user or may be automatically activated at a predetermined periodicity, for example every week or month, or in response to particular events.
  • step 340 only the necessary operations are allowed to write data to the STAD mass memory, depending on the level of security of the virtual machine. For example, only operational data and user data that has been specifically identified can be stored in the STAD. In addition, if the security level of the virtual machine is high, only data whose confidence level is verified can be stored in the STAD (steps 345 and 350). Such verification consists, for example, in validating the integrity or the origin of the data or in verifying the environment in which they were produced.
  • a particular treatment is performed for the data that the user acquires from a virtual machine whose security level is low, that is to say the security level of which is below a predetermined threshold, for example when a virtual machine can access the Internet and therefore receive messages, applications and cookies (commonly called cookies in English terminology) or when devices such as storage devices can be connected to the STAD.
  • these data can not be stored only on a removable medium such as an SD card or USB type (step 355).
  • each virtual machine corresponds here to a predetermined security level need
  • the applications for example the operational applications, the office applications and the user's personal applications being distributed in several virtual machines by security level needs. according to the functions they use.
  • it is important to fine-tune the hypervisor and the virtual machines, taking into account, in particular, the good uses, the strictly necessary drivers and the means of communication supporting the functions of the STAD in order to reduce as much as possible the attack surface and thus not degrade the level of safety.
  • Figure 4 schematically illustrates some steps implemented to analyze the risks associated with the functions that must be performed on the same STAD. These risks make it possible to define the virtual machines to be implemented in the STAD and the distribution of these functions in the virtual machines used.
  • This analysis includes determining the execution parameters of the functions to determine, in particular, the communication interfaces that can be used, the operating system used and the source of the processed data. These parameters make it possible to characterize the parameters of the virtual machine capable of implementing the function and to define a security level.
  • a security level can also be directly associated with a function, for example if it is imposed.
  • a first step (step 400) is aimed at analyzing the context in order to determine the parameters enabling the risk of each function to be evaluated.
  • the risks being assessed here in the event of a loss of confidentiality, integrity, availability or authenticity, the parameters that may be taken into account to assess the risks may include:
  • step 300 provides context for the analysis of the functions to be implemented in a STAD to meet particular needs.
  • a second step (step 405), the risks are identified. After having defined the list of assets to be protected and identified the responsibilities, the potential threats as well as the vectors of these threats and the means of mitigation already implemented are identified. It should be noted that the lists used must be sufficiently detailed to allow decision-making on the needs of the security levels.
  • a next step (step 410), the risks are estimated by crossing the information obtained previously with the known vulnerabilities as well as the type and the level of consequences in case of exploitation of a vulnerability and the probability of an attack.
  • This step allows in particular to evaluate the possible consequences for a given risk according to the context and to establish a list of risks to which a function may be subject.
  • step 415 the level of risk is evaluated for each function, using the grid established above and the associated treatments.
  • Figure 5 schematically illustrates an example of an algorithm for distributing software applications implemented in a STAD in virtual machines according to the functions they use.
  • a variable / representing the index of the software applications implemented in the STAD
  • a variable y representing the index of the functions called by the application having the index /
  • Functions to which the application having the index / are used are determined (step 505). They are here stored as a table in the database 510.
  • the security level requirement of the application having for index Z 1 is then defined as being the security level requirement of the function having for index y, called BNS (/) (step 515).
  • a test is then performed (step 520) to determine whether the value of the index corresponds to the number of functions used by the function having index /. If so, the index is incremented by one (step 525) and another test is performed (step 530) to determine if the security requirement of the function having index y (BNSO) is greater than the need in security level of the application having for index / (BNS (Z)). If yes, the security level requirement for the Z-indexed application
  • the application with Z index is associated with the virtual machine whose security level corresponds to BNS (Z) (step 540 ). This information is here stored in the database 545.
  • the value of the Z index is then compared to the number of applications implemented by the STAD to determine if all applications have been associated with a virtual machine (step 550). If yes, the process ends. In the opposite case, the index / is incremented by one and the preceding steps (steps 505 to 550) are repeated.
  • an application provider can deliver one or more virtual machines integrating its applications and communicate the installation procedure of the recommended software platform (virtualization-based) to the STAD.
  • the latter can also be provided with the hypervisor and the virtual machine (s) pre-installed.
  • customers may use a USB key or SD card to store the profile and user data such as an email id, cookies and favorites from an Internet browser, and login scripts. .
  • the STADs are interchangeable and can be managed in a fleet.
  • a common software base is installed on a fleet of STADs, for all uses and all types of aircraft to which the STADs are likely to be connected.
  • the virtual machine (s) corresponding to the types of use and / or aircraft are then installed.
  • one or more reference images are created to allow the configuration of the STAD during its use. These reference images can also be restored by the user without the need for a technician.
  • the tool case known as the Electronic Flight Bag is here considered.
  • This is a tool kit to from which a pilot and his second prepare a mission to perform.
  • L 1 EFB is not an application having a high level of safety.
  • Mission data is loaded into a portable STAD from the ground.
  • the STAD is carried on board the aircraft but it is not connected to the on-board information system. Data is exchanged with the ground only after landing;
  • this is a standard portable STAD, attached to a pilot.
  • the STAD exchanges data with the ground, including the airline and the airport, and with the aircraft information system during all phases of flight; and,
  • the STAD is supportive of the cockpit and can access critical systems that require a high level of certification.
  • Class 2 EFBs can therefore be managed by a STAD according to the invention.
  • the EFB provider delivers the operational applications or part of them to the client. It communicates the list of compatible systems and the minimum configuration of the hypervisor or delivers the STAD with the hypervisor and virtual machines pre-installed.
  • the client prepares the virtual machines according to the operational applications and the received configuration data. It also prepares virtual machines to implement enterprise-specific applications, such as messaging applications.
  • an IT technician can install the STAD hypervisor, which then makes it possible to use the company's IT resources, the functionalities of the EFB and, possibly, others.
  • the data of the users is preferably stored on a removable memory card, for example an SD type card and not on the internal hard disk of the STADs.
  • a removable memory card for example an SD type card
  • the user can restart the virtual machine using the most recent associated reference image without recourse to a technician.
  • the technician retrieves the user's memory card and inserts it into another STAD of the fleet. It does not need to customize this STAD or copy user data.
  • FIG. 6 illustrates an exemplary hardware architecture adapted to implement the invention.
  • the device 600 here comprises a communication bus 605 to which are connected:
  • CPU Central Processing Unit
  • ROM Read OnIy Memory in English terminology
  • ROM Read OnIy Memory
  • RAM Random Access Memory
  • cache memory 620 comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs
  • a communication interface 650 adapted to transmit and receive data.
  • the device 600 also preferably has the following elements:
  • a screen 625 making it possible to display data such as representations of the commands and to serve as a graphical interface with the user who can interact with the programs according to the invention, using a keyboard and a mouse 630 or another pointing device such as a touch screen or remote control;
  • a hard disk 635 that may include the aforementioned programs and data processed or to be processed according to the invention; and a memory card reader 640 adapted to receive a memory card 645 and to read or write to it data processed or to be processed according to the invention.
  • the communication bus allows communication and interoperability between the various elements included in the device 600 or connected to it.
  • the representation of the bus is not limiting and, in particular, the central unit is able to communicate instructions to any element of the device 600 directly or via another element of the device 600.
  • the executable code of each program enabling the programmable device to implement the processes according to the invention can be stored, for example, in the hard disk 635 or in the read-only memory 615.
  • the memory card 645 may contain data, in particular a correspondence table between the detected events and the commands that can be requested, as well as the executable code of the aforementioned programs which, once read by the device 600, is stored in the hard disk 635.
  • the executable code of the programs may be received, at least partially, via the interface 650, to be stored in a manner identical to that described above.
  • program or programs may be loaded into one of the storage means of the device 600 before being executed.
  • the central unit 610 will control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored in the hard disk 635 or in the read-only memory 615 or else in the other elements of aforementioned storage.
  • the program or programs that are stored in a non-volatile memory for example the hard disk 635 or the read-only memory 615, are transferred into the random access memory 620 which then contains the executable code of the program or programs according to the invention, as well as registers for memorize the variables and parameters necessary for the implementation of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention a notamment pour objet un composant logiciel pour le traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité. Le composant logiciel selon l'invention comprend une pluralité de machines virtuelles (215), chaque machine virtuelle étant adaptée à exécuter au moins une fonction ayant besoin d'un niveau de sûreté ou d'une limite de responsabilité prédéterminé et un hyperviseur (210) adapté à contrôler l'exécution de ladite pluralité de machines virtuelles.

Description

Composant logiciel et dispositif pour le traitement automatisé de données multi-usages, mettant en œuyre des fonctions avant besoin de différents niveaux de sûreté ou limites de responsabilité
La présente invention concerne les systèmes de traitement de données, notamment de données de systèmes d'information d'aéronefs, et plus particulièrement un composant logiciel et un dispositif pour le traitement automatisé de données multi-usages, mettant en œuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité.
Depuis les événements tragiques du 11 septembre 2001 liés aux crashs d'avions commerciaux, la sûreté représente désormais une problématique essentielle de l'aéronautique. Pour répondre à celle-ci, les constructeurs et les compagnies aériennes ont développé et intégré des fonctions visant à améliorer la sûreté à bord des aéronefs.
Ainsi, à titre d'illustration, des portes de cockpit renforcées et des systèmes de vidéo surveillance interne ont été développés. De même, les systèmes d'information embarqués sont désormais protégés contre des malveillances.
Par ailleurs, les compagnies aériennes ont l'obligation réglementaire de mettre en œuvre des moyens techniques et organisationnels pour maintenir le niveau de sûreté des éléments d'un aéronef tel que déterminé à la livraison de celui-ci. Cette obligation réglementaire ne couvre que la sûreté physique et non la sûreté logique.
Cependant, du fait de cette obligation réglementaire, certaines compagnies aériennes demandent aux constructeurs d'aéronefs de permettre l'intégration de fonctions de sûreté dans les processus opérationnels des compagnies aériennes. En outre, certaines compagnies aériennes demandent aux constructeurs d'aéronefs que les fonctions opérationnelles et les fonctions de sûreté associées soient compatibles avec des matériels et des logiciels du commerce non spécifiques à l'aéronautique. De façon générale, les systèmes de traitement automatisé de données, aussi appelés STADs (acronyme de Système de Traitement Automatisé de Données), peuvent être utilisés, dans un environnement aéronautique, pour héberger des applications logicielles opérationnelles et/ou de communication, c'est-à-dire comme des mallettes à outils, pour permettre au personnel opérationnel, par exemple le pilote et son second, aux techniciens et aux équipes de maintenance, de remplir certaines tâches de leur mission. Ces mallettes à outils peuvent également être ouvertes à d'autres usages. En particulier, une compagnie aérienne peut décider d'y installer ses propres applications métiers ou bureautiques. Les mallettes à outils ne sont pas des fonctions de sûreté, c'est-à-dire que leur rôle n'est pas d'assurer la sûreté, mais de permettre de réaliser des tâches opérationnelles.
Les données manipulées par les applications logicielles opérationnelles mises en œuvre dans les STADs peuvent être téléchargées, calculées, affichées et/ou transmises. En raison des contraintes de sûreté évoquées précédemment, il existe des besoins forts de sûreté en termes de confidentialité, d'intégrité et/ou de disponibilité de celles-ci.
Cependant, il est difficile de faire cohabiter des fonctions et des données sensibles avec des fonctionnalités pouvant communiquer vers l'extérieur et qui reposent sur des logiciels et des matériels du commerce lorsqu'un objectif de sûreté doit être respecté.
L'invention permet de résoudre au moins un des problèmes exposés précédemment.
L'invention a ainsi pour objet un composant logiciel pour ordinateur adapté au traitement automatique de données multi-usages, le composant logiciel mettant en œuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité et comprenant,
- une pluralité de machines virtuelles, chaque machine virtuelle étant adaptée à exécuter au moins une fonction ayant besoin d'un niveau de sûreté ou d'une limite de responsabilité prédéterminé ; et,
- un hyperviseur adapté à contrôler l'exécution de ladite pluralité de machines virtuelles. Le composant logiciel selon l'invention permet ainsi de mettre en œuvre des fonctions ayant des niveaux de sûreté ou des limites de responsabilité différentes dans une même machine, indépendamment de la plateforme matérielle et de l'architecture du système d'information utilisées à bord des aéronefs. Les éditeurs des applications logicielles mises en œuvre ne sont donc plus dépendants de l'évolution des systèmes d'exploitation et maîtrisent le cycle de vie de ces applications.
Le composant logiciel peut ainsi être mis en œuvre sur un STAD mobile du marché, selon une liste de compatibilité matérielle. Les limites de responsabilité étant clairement identifiées, il peut recevoir des applications logicielles de fournisseurs et de l'utilisateur. Un tel STAD peut être attaché à un aéronef ou à un utilisateur.
L'utilisation du composant logiciel selon l'invention n'augmente pas les besoins de maintenance par rapport à un équipement mono-usage, mobile ou non. Il assure un bon niveau de ségrégation ainsi qu'un bon niveau de sûreté dont l'intégrité des données opérationnelles. Il permet de contrôler le partage des ressources entre les différentes fonctions tout en étant relativement indépendant vis-à-vis des manques de fiabilité des produits du commerce mis en œuvre.
De façon avantageuse, ledit hyperviseur comprend des moyens d'authentification pour authentifier au moins une machine virtuelle de ladite pluralité de machine virtuelle afin, notamment, de contrôler la validité de données transmises. De même, lesdits moyens d'authentification sont, de préférence, adaptés à vérifier l'intégrité de ladite au moins une machine virtuelle authentifiée.
En outre, lesdits moyens d'authentification sont avantageusement adaptés à vérifier le niveau d'isolation de ladite au moins une machine virtuelle authentifiée par rapport à au moins une autre machine virtuelle de ladite pluralité de machines virtuelles afin, notamment, de contrôler la validité de données transmises au regard d'autres machines virtuelles.
Selon un mode de réalisation particulier, le composant logiciel comprend en outre des moyens de mémorisation de données traitées par au moins une machine virtuelle de ladite pluralité de machine virtuelle, lesdits moyens de mémorisation étant adaptés à mémoriser lesdites données traitées dans une mémoire amovible dudit ordinateur. Le composant logiciel selon l'invention permet ainsi de mémoriser des données dont le niveau de confiance n'est pas sûr sans le compromettre. De tels moyens de mémorisation de données sont, de préférence, mis en œuvre par des machines virtuelles de ladite pluralité de machines virtuelles dont le niveau de sûreté est inférieur à un seuil prédéterminé.
Toujours selon un mode de réalisation particulier, le composant logiciel comprend en outre des moyens de contrôle d'un niveau de confiance d'au moins une donnée traitée par au moins une machine virtuelle de ladite pluralité de machines virtuelles, ladite au moins une donnée traitée ne pouvant être mémorisée localement dans ledit ordinateur qu'après qu'elle ait été contrôlée. Le composant logiciel selon l'invention permet ainsi de ne mémoriser localement que des données dont le niveau de confiance est sûr afin de ne pas le compromettre.
Toujours selon un mode de réalisation particulier, le composant logiciel comprend en outre des moyens de transfert de données entre une première et une seconde machines virtuelles de ladite pluralité de machines virtuelles, lesdits moyens de transfert étant adaptés à filtrer des données transférées si le niveau de sûreté de ladite seconde machine virtuelle est supérieur au niveau de sûreté de ladite première machine virtuelle afin de valider les données échangées, notamment selon leur type ou le besoin d'accès à ces données.
Toujours selon un mode de réalisation particulier, des données de configuration utilisées pour démarrer au moins une machine virtuelle de ladite pluralité de machine virtuelle ne sont pas modifiées au cours de l'exécution de ladite au moins une machine virtuelle démarrée afin de faciliter la maintenance du composant logiciel et permettre son redémarrage à partir d'un état stable et validé.
L'invention a également pour objet un dispositif comprenant des moyens adaptés à la mise en œuvre de chacun des éléments du composant logiciel décrit précédemment dont les avantages sont similaires à ceux évoqués précédemment.
D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :
- la figure 1 représente schématiquement un exemple d'environnement dans lequel peut être utilisé un système de traitement automatisé de données multi-usages mettant en œuvre l'invention ;
- la figure 2 illustre un exemple d'architecture d'un système de traitement automatisé de données multi-usages selon l'invention ;
- la figure 3 illustre schématiquement un exemple d'adaptation de certaines fonctions exécutées dans des machines ;
- la figure 4 illustre schématiquement certaines étapes mises en oeuvre pour analyser les risques associés aux fonctions qui doivent être exécutées sur un même STAD ;
- la figure 5 illustre schématiquement un exemple d'algorithme pour répartir des applications logicielles mises en œuvre dans un STAD dans des machines virtuelles selon les fonctions auxquelles elles font appel; et,
- la figure 6 montre un exemple de dispositif permettant d'implémenter au moins partiellement l'invention.
L'invention permet notamment de remplacer les systèmes de traitement automatisé de données (STAD) mono-usages, mobiles ou fixes, utilisés aujourd'hui pour la maintenance et la mission, par un STAD unique sécurisé, de préférence mobile.
La figure 1 représente schématiquement un exemple d'environnement 100 dans lequel peut être utilisé un système de traitement de données automatique multi-usages mettant en œuvre l'invention. Selon cet exemple, un STAD 105 peut être utilisé par un membre d'équipage dans un aéronef 110 par exemple pour exécuter des applications logicielles de gestion de vol.
Le même STAD 105, ou un STAD similaire 115, peut être utilisé par une équipe de maintenance pour accéder aux données de maintenance de l'aéronef 110 et/ou pour mettre à jour des données ou des applications logicielles de l'aéronef.
Par ailleurs, le même STAD 105, ou un STAD similaire 120, peut être utilisé dans les bureaux 125 de la compagnie aérienne, par exemple pour la préparation d'un vol. De façon similaire, le même STAD 105, ou un STAD similaire 130, peut être utilisé par son possesseur pour accéder à des applications bureautiques et à sa messagerie électronique à partir, par exemple, d'un accès réseau d'un hôtel 135.
Il convient de remarquer ici que les exemples illustrés sur la figure 1 ne sont donnés qu'à titre illustratif. Ils ne sont pas limitatifs.
Pour permettre la mise en œuvre de fonctions ayant des besoins de niveaux de sûreté différents sur un STAD unique, sans compromettre la sûreté de chacune de ces fonctions, plusieurs techniques sont combinées.
Les applications opérationnelles, les applications bureautiques et les applications personnelles d'un STAD, plus généralement toutes les fonctions mises en œuvre dans un STAD, sont ainsi hébergées dans plusieurs machines virtuelles mises en œuvre dans le STAD, selon les besoins de niveaux de sûreté et, de préférence, par responsabilité.
Il est rappelé ici qu'une machine virtuelle offre un environnement d'exécution ayant ses propres caractéristiques de configuration. En d'autres termes, deux machines virtuelles peuvent être considérées comme deux machines physiques indépendantes. Chaque machine virtuelle s'exécute avec son système d'exploitation, ses pilotes (appelés drivers en terminologie anglo- saxonne), ses applications logicielles et sa configuration de gestion et d'échange de données.
Un mécanisme de virtualisation permet notamment l'exécution de plusieurs machines virtuelles sur une machine réelle à l'aide d'un hyperviseur.
L'hyperviseur est responsable du partage des ressources de la machine réelle et de l'application des règles de contrôle d'accès aux ressources. Les ressources partagées entre les machines virtuelles sont, par exemple, la puissance de calcul CPU (sigle de Central Processing Unit en terminologie anglo-saxonne), les canaux de communication, les interruptions matérielles et logicielles, les ports d'entrées/sorties, la mémoire, les horloges, les bus systèmes, les contrôleurs et/ou la mémoire de masse. L'invention est basée sur l'utilisation d'un hyperviseur standard, personnalisé pour gérer les machines virtuelles selon des règles prédéterminées.
La virtualisation mise en œuvre ici est une virtualisation matérielle, par exemple une virtualisation complète selon laquelle l'hyperviseur gère toutes les requêtes des machines virtuelles ou une paravirtualisation selon laquelle certaines requêtes sont gérées directement par les machines virtuelles.
Selon un mode de réalisation particulier, des outils logiciels de virtualisation adaptés au temps réel sont utilisés pour leurs bénéfices en terme de performances et de niveau de sûreté.
Par ailleurs, il est observé que la virtualisation permet, pour des systèmes embarqués, d'optimiser le poids du matériel informatique mis en œuvre comprenant les serveurs, les commutateurs et le câblage, mais aussi une réduction de consommation électrique ainsi qu'une simplification des procédures de déploiement et de maintenance, ce qui est particulièrement avantageux dans un environnement aéronautique.
La figure 2 illustre un exemple d'architecture d'un STAD selon l'invention, suffisamment sûr pour être utilisé dans des environnements ayant des niveaux de sûreté différents.
Comme représenté, le STAD 200 comprend ici une couche matérielle 205. Celle-ci correspond, par exemple, à celle d'un ordinateur personnel portable, aussi appelé laptop ou notebook en terminologie anglo- saxonne, d'un assistant personnel, aussi appelé PDA (sigle de Personal Digital Assistant en terminologie anglo-saxonne), ou d'un smartphone.
La couche matérielle devant être de confiance, elle peut consister en une plateforme ouverte de type PC dont le niveau de confiance est amélioré par l'utilisation d'un module d'authentification appelé TPM (sigle de Trusted
Platform Module en terminologie anglo-saxonne). Il s'agit d'un composant matériel cryptographique défini par le Trusted Computing Group.
La couche matérielle 205 permet l'exécution d'une couche logicielle 210 comprenant l'hyperviseur. Elle permet d'exécuter plusieurs machines virtuelles distinctes, par exemple les machines virtuelles MV1 , MV2, MV3 et MVx, référencées 215-1 , 215-2, 215-3 et 215-x, respectivement.
Une première machine virtuelle, ici la machine virtuelle 215-1, a un rôle et des droits particuliers. C'est la machine d'administration qui sert d'accès pour la maintenance et la configuration de la plateforme. Elle utilise ici un système d'exploitation OS1. Toujours selon cet exemple, la machine virtuelle 215-1 comprend un espace de stockage, ou mémoire de masse, et une interface de communication, notée I/O (sigle d'Input/Output en terminologie anglo-saxonne).
Une deuxième machine virtuelle, ici la machine virtuelle 215-2, permet au STAD de se connecter au système d'information le plus sensible, c'est-à-dire celui de l'aéronef. L'affichage lié à cette machine virtuelle peut être dirigé vers l'écran du STAD ou des écrans spécifiques de l'aéronef selon, par exemple, une interface utilisateur graphique standard de type client/serveur.
La machine virtuelle 215-2 utilise ici le système d'exploitation OS2 et une interface d'entrée/sortie permettant d'échanger des données avec le système d'information de l'aéronef via un lien de type station d'accueil cockpit. La machine virtuelle 215-2 permet d'exécuter des applications opérationnelles. Il convient de définir précisément les périphériques qui sont disponibles dans cet environnement ainsi que les droits d'administration pour assurer le niveau de sûreté requis.
Une troisième machine virtuelle, ici la machine virtuelle 215-3, permet au STAD de se connecter à des systèmes d'information peu sensibles, ici des systèmes distincts du système d'information de l'aéronef. A titre d'illustration, la machine virtuelle 215-3 permet au STAD d'accéder à un réseau interne de l'entreprise exploitant le STAD ou au réseau Internet, par exemple à une borne d'accès WiFi d'un l'hôtel.
Les risques associés à la machine virtuelle 215-3 sont plus élevés que ceux des machines virtuelles 215-1 et 215-2 car elle est ouverte vers des environnements susceptibles d'être source de compromission. Cette machine virtuelle peut donc être une cible pour des logiciels malveillants, appelés malware en terminologie anglo-saxonne. En outre, les applications logicielles et les pilotes mis en œuvre dans cette machine virtuelle étant a priori des logiciels standard, elles représentent des failles potentiellement connues.
Par ailleurs, le concepteur et/ou la société exploitant le STAD peuvent décider de créer une ou plusieurs autres machines virtuelles 215-x pour répondre à des besoins spécifiques. A titre d'illustration, une machine virtuelle 215-x peut être utilisée pour l'exécution d'applications logicielles ayant besoin d'un niveau de sûreté équivalent à celui de la machine virtuelle 215-2 mais dont le fournisseur est différent de celui des applications exécutées dans la machine virtuelle 215-2. Ainsi, en dissociant les environnements d'exécution des applications selon les niveaux de sûreté requis et les responsabilités, il est possible d'utiliser un STAD unique.
De façon avantageuse, le niveau d'exécution est contraint dans l'espace utilisateur au démarrage du STAD de telle sorte que les droits d'administration ne soient pas accessibles. De plus, la bannière de connexion est, de préférence, désactivée pour empêcher un utilisateur de sortir de la couche de virtualisation. Il n'accède ainsi qu'aux machines virtuelles. Toujours de façon avantageuse, la séquence de touches de démarrage est désactivée. Par ailleurs, si des fonctionnalités de virtualisation matérielle sont implémentées dans le processeur du STAD, elles sont configurées de manière à ne pas dégrader le niveau de sûreté attendue.
Au démarrage du STAD ou lors de son activation, par exemple après une mise en veille, l'utilisateur est authentifié. Une telle authentification est ici réalisée par l'hyperviseur. L'accès aux machines virtuelles dépend de cette authentification. Ainsi, par exemple, un pilote et un copilote pourront accéder à toutes les machines virtuelles implémentées sur un STAD, à l'exception de la machine virtuelle d'administration utilisée pour configurer le STAD, tandis qu'un technicien de maintenance pourra accéder à cette dernière. Les machines virtuelles peuvent être lancées automatiquement à la mise en route du STAD ou à la requête de l'utilisateur. Chaque machine virtuelle peut être démarrée et stoppée indépendamment, en fonction des besoins de l'utilisateur. Celui-ci peut passer d'une machine virtuelle à une autre selon un mécanisme standard, par exemple via une interface graphique. Selon un mode de réalisation particulier, les fonctions mises en œuvre dans les machines virtuelles sont adaptées en fonction de certains paramètres tels que le niveau de sûreté de la machine virtuelle dans laquelle elles sont exécutées.
La figure 3 illustre schématiquement un exemple d'adaptation de certaines fonctions exécutées dans des machines virtuelles selon ces paramètres, en fonction du type de fonction (étape 300).
Ainsi, par exemple, pour une fonction de communication permettant de transmettre des données, les machines virtuelles, ou certaines d'entre elles, passent par une phase d'authentification pour se connecter à certains systèmes externes au STAD (étape 305), par exemple à un système d'information d'un aéronef. Cette phase d'authentification, mise en œuvre par l'hyperviseur lors du lancement de la machine virtuelle et/ou d'échange de données, comprend les étapes suivantes,
- authentification de la machine virtuelle selon un mécanisme standard d'authentification (étape 310) ;
- vérification de l'intégrité de la machine virtuelle en contrôlant, par exemple, plusieurs critères de sûreté tels que le système d'exploitation et la date de dernière mise à jour (étape 315) ; et,
- vérification du niveau d'isolation de la machine virtuelle par rapport aux autres machines virtuelles selon les fonctions mises en œuvre (étape 320). Cette étape permet de vérifier qu'aucune autre machine virtuelle ne peut interagir avec celle dont l'authentification est demandée, par exemple via l'interface utilisateur ou le réseau, lorsque la machine virtuelle est connectée avec un système d'un aéronef. Alternativement, cette étape peut consister à vérifier le respect de règles de communication prédéterminées.
Ainsi, les données ne sont effectivement transmises (étape 325) qu'après authentification de la machine virtuelle afin qu'elle ne puisse transmettre de données erronées vers un système externe.
De même, le transfert de données entre machines virtuelles est contrôlé pour garantir les niveaux de sûreté requis. En effet, qu'elles aient été isolées pour des besoins de limite de responsabilité ou bien de niveaux de sûreté différents, certaines fonctions peuvent nécessiter un transfert de données entre machines virtuelles et donc le paramétrage d'un canal de communication.
Ainsi, une fonction d'import est créée pour permettre de valider les données transitant vers une machine virtuelle ayant un niveau de sûreté plus élevé que celui de la machine virtuelle source (notée MV* sur la figure 3). Le principe de cette fonction est notamment de filtrer les données selon leur type (étape 330) et d'assurer que seules les données attendues (étape 335) transitent par le canal de communication ouvert (étape 325). Cependant, l'utilisateur reste maître de la validation, c'est-à-dire du transfert effectif des données d'une machine virtuelle vers une autre ayant un niveau de sûreté plus élevé.
Pour améliorer les opérations de maintenance des STADs, un mécanisme de photographies instantanées, appelées snapshots en terminologie anglo-saxonne, est, de préférence, mis en œuvre.
La fonction de photographies instantanées permet de mémoriser toutes les données relatives à une machine virtuelle, à un instant donné, de telle sorte que la machine virtuelle puisse être ultérieurement relancée et reconfigurée afin d'être remise dans l'état dans lequel elle se trouvait lorsque les données ont été mémorisées sous forme de photographie. Cette fonction peut être activée par un utilisateur ou l'être automatiquement selon une périodicité prédéterminée, par exemple toutes les semaines ou tous les mois, ou en réponse à des événements particuliers.
En outre, pour garantir un niveau de sûreté des STADs, un mécanisme particulier de gestion d'écriture de données est mis en œuvre dans chaque machine virtuelle. Ce mécanisme est ici basé sur les fonctions de copie d'images lors de l'écriture, appelées copy-on-write en terminologie anglo- saxonne, ainsi que d'interdiction d'écriture de certaines données dans la mémoire de masse du STAD.
Selon la fonction d'images copiées lors de l'écriture, toutes les données utilisées par une machine virtuelle lors de son démarrage sont copiées et seule cette copie est utilisée par la machine virtuelle. Ainsi, à chaque démarrage suivant de la machine virtuelle les mêmes données que celles utilisées pour le démarrage précédent sont utilisées même si ces dernières ont été modifiées par la suite.
La combinaison de ces fonctions permet de garantir les niveaux de sûreté tout en évitant que les STADs aient besoin de davantage de maintenance que des équipements standard. En effet, si une machine virtuelle est compromise, il suffit de la restaurer à partir d'une photographie instantanée réalisée à partir d'un état stable pour retrouver un système fonctionnel.
De façon avantageuse, dans le but de ne pas corrompre la plateforme, seules les opérations nécessaires sont autorisées à écrire des données dans la mémoire de masse du STAD, en fonction du niveau de sûreté de la machine virtuelle (étape 340). Par exemple, seules les données opérationnelles et les données de l'utilisateur expressément identifiées peuvent être stockées dans le STAD. En outre, si le niveau de sûreté de la machine virtuelle est élevé, seules les données dont le niveau de confiance est vérifié peuvent être mémorisées dans le STAD (étapes 345 et 350). Une telle vérification consiste par exemple à valider l'intégrité ou l'origine des données ou à vérifier l'environnement dans lequel elles ont été produites. Néanmoins, même si de telles données peuvent être mémorisées dans le STAD, elles sont de préférence mémorisées dans un support amovible, telle qu'une carte SD (sigle de Digital Secυre en terminologie anglo-saxonne) ou de type clé USB, pour faciliter le remplacement d'un STAD en évitant l'étape de récupération des données. Les données dont le niveau de confiance n'est pas vérifié peuvent être mémorisées dans un tel support amovible (étape 355).
Un traitement particulier est effectué pour les données que l'utilisateur acquiert à partir d'une machine virtuelle dont le niveau de sûreté est faible, c'est-à-dire dont le niveau de sûreté est inférieur à un seuil prédéterminé, par exemple lorsqu'une machine virtuelle peut accéder à Internet et donc recevoir des messages, des applications et des témoins (couramment appelés cookies en terminologie anglo-saxonne) ou lorsque des périphériques tels que des périphériques de stockage peuvent être reliés au STAD. Dans ce cas, pour des raisons opérationnelles et de sûreté, ces données ne peuvent être stockées que sur un support amovible telle qu'une carte SD ou de type clé USB (étape 355).
Comme indiqué précédemment, chaque machine virtuelle correspond ici à un besoin de niveau de sûreté prédéterminé, les applications, par exemple les applications opérationnelles, les applications bureautiques et les applications personnelles de l'utilisateur étant réparties dans plusieurs machines virtuelles par besoins de niveaux de sûreté selon les fonctions auxquelles elles font appel. Ainsi, pour obtenir un niveau de sécurité général satisfaisant, il est important de configurer avec finesse l'hyperviseur et les machines virtuelles en tenant notamment compte des bons usages, des drivers strictement nécessaires et des moyens de communication supportant les fonctions du STAD afin de réduire autant que possible la surface d'attaque et ainsi ne pas dégrader le niveau de sûreté.
La figure 4 illustre schématiquement certaines étapes mises en œuvre pour analyser les risques associés aux fonctions qui doivent être exécutées sur un même STAD. Ces risques permettent de définir les machines virtuelles devant être implémentées dans le STAD et la répartition de ces fonctions dans les machines virtuelles utilisées.
Cette analyse consiste notamment à déterminer les paramètres d'exécution des fonctions afin de déterminer, en particulier, les interfaces de communication pouvant être utilisées, le système d'exploitation utilisé et la provenance des données traitées. Ces paramètres permettent de caractériser les paramètres de la machine virtuelle apte à mettre en œuvre la fonction et de définir un niveau de sûreté.
II convient de remarquer qu'un niveau de sûreté peut également être directement associé à une fonction, par exemple s'il est imposé.
Une première étape (étape 400) a pour objet l'analyse du contexte afin de déterminer les paramètres permettant d'évaluer le risque de chaque fonction.
Les risques étant ici évalués dans le cas d'une perte de confidentialité, d'intégrité, de disponibilité ou d'authenticité, les paramètres pouvant être pris en compte pour évaluer les risques peuvent notamment être les suivants,
- la valeur stratégique des informations par rapport à l'activité commerciale ;
- la criticité des informations par rapport à la sécurité des biens et des personnes ;
- les obligations réglementaires et contractuelles ;
- l'importance opérationnelle de la confidentialité, de l'intégrité, de l'authenticité et de la disponibilité des informations traitées ; et,
- les attentes et perception des parties prenantes ainsi que les conséquences sur l'image de marque.
Ces paramètres sont utilisés pour élaborer une grille d'évaluation qui définit des zones pour chaque risque identifié. A titre d'illustration, cette grille peut comprendre trois zones correspondant à des risques faibles, moyens et élevés. Le traitement associé à chaque zone, permettant notamment d'identifier les risques des fonctions devant être mises en œuvre, est de préférence prédéterminé pour permettre la comparaison et la reproductibilité des résultats. En d'autres termes, l'étape 300 permet d'établir le contexte de l'analyse des fonctions devant être mises en œuvre dans un STAD pour répondre à des besoins particuliers.
Dans une seconde étape (étape 405), les risques sont identifiés. Après avoir ici défini la liste des biens à protéger et identifié les responsabilités, les menaces potentielles ainsi que les vecteurs de ces menaces et les moyens de mitigation déjà implémentés sont identifiés. Il convient de remarquer que les listes utilisées doivent être suffisamment détaillées pour permettre une prise de décision quant aux besoins des niveaux de sûreté.
Dans une étape suivante (étape 410), les risques sont estimés en croisant les informations obtenues précédemment avec les vulnérabilités connues ainsi que le type et le niveau de conséquences en cas d'exploitation d'une vulnérabilité et la probabilité d'une attaque. Cette étape permet en particulier d'évaluer les conséquences possibles pour un risque donné selon le contexte opérationnel et d'établir une liste des risques auxquels peut être soumis une fonction.
Enfin, dans une étape suivante (étape 415), le niveau de risque est évalué pour chaque fonction, en utilisant la grille établie précédemment et les traitements associés. En fonction du résultat obtenu, il peut être décidé de reprendre le processus d'analyse des risques (répétition des étapes 400 à 415) avec une variante d'implémentation afin, par exemple, de réduire le risque associé à une fonction en imposant des contraintes supplémentaires.
Les étapes décrites en référence à la figure 4, appliquées aux fonctions qui doivent être hébergées dans le STAD, permettent de définir les besoins de niveau de sûreté de chaque fonction. Ces résultats, éventuellement combinés avec un critère de responsabilité, permettent de définir les fonctions regroupées dans une même machine virtuelle. Comme indiqué précédemment, l'utilisation d'un critère de responsabilité permet de définir des limites de responsabilité entre les différents intervenants dont les fonctions ou les applications sont implémentées dans le STAD. Par exemple, il est possible de définir une machine virtuelle pour chaque intervenant afin que chacun soit responsable de sa partie.
Ainsi, à titre d'illustration, quatre machines virtuelles peuvent être mises en œuvre selon le schéma suivant,
- machine virtuelle F1 pour l'exécution d'applications ayant un besoin d'un niveau élevé de sûreté. Cette machine virtuelle est isolée des autres pour permettre de suivre la responsabilité du fournisseur 1 ;
- machine virtuelle F2 pour l'exécution d'applications ayant un besoin d'un niveau élevé de sûreté. Cette machine virtuelle est isolée des autres pour permettre de suivre la responsabilité du fournisseur 2 ;
- machine virtuelle F3 pour l'exécution d'applications ayant un besoin d'un niveau moyen de sûreté ; et,
- machine virtuelle F4 pour l'exécution d'applications ayant un besoin d'un faible niveau de sûreté.
Il convient de remarquer que la machine virtuelle d'administration utilisée pour la gestion des autres machines virtuelles, créée par l'hyperviseur lors de l'installation, a un usage purement technique et non opérationnel. A partir de cette machine virtuelle sont en particulier gérés les droits utilisateurs d'accès aux autres machines.
La figure 5 illustre schématiquement un exemple d'algorithme pour répartir des applications logicielles mises en œuvre dans un STAD dans des machines virtuelles selon les fonctions auxquelles elles font appel.
Une variable /, représentant l'index des applications logicielles mises en œuvre dans le STAD, et une variable y, représentant l'index des fonctions appelées par l'application ayant l'index /, sont initialisées à la valeur un (étape 500). Les fonctions auxquelles fait appel l'application ayant l'index / sont déterminées (étape 505). Elles sont ici mémorisées sous forme de table dans la base de données 510.
Le besoin en niveau de sécurité de l'application ayant pour index Z1 appelé BNS(Z), est alors défini comme étant le besoin en niveau de sécurité de la fonction ayant pour index y, appelé BNS(/) (étape 515).
Un test est ensuite effectué (étape 520) pour déterminer si la valeur de l'index y correspond au nombre de fonctions auxquelles fait appel la fonction ayant pour index /. Dans l'affirmative, l'index y est incrémenté de un (étape 525) et un autre test est effectué (étape 530) pour déterminer si le besoin en niveau de sécurité de la fonction ayant pour index y (BNSO)) est supérieur au besoin en niveau de sécurité de l'application ayant pour index / (BNS(Z)). Dans l'affirmative, le besoin en niveau de sécurité de l'application ayant pour index Z
(BNS(Z)) est défini comme étant le besoin en niveau de sécurité de la fonction ayant pour index y (BNS(/)) (étape 535). L'algorithme se poursuit alors à l'étape 520.
Si la valeur de l'index y correspond au nombre de fonctions auxquelles fait appel la fonction ayant pour index /, l'application ayant pour index Z est associé à la machine virtuelle dont le niveau de sécurité correspond à BNS(Z) (étape 540). Cette information est ici mémorisée dans la base de données 545.
La valeur de l'index Z est ensuite comparée au nombre d'applications mises en œuvre par le STAD pour déterminer si toutes les applications ont été associées à une machine virtuelle (étape 550). Dans l'affirmative, le processus prend fin. Dans le cas contraire, l'index / est incrémenté de un et les étapes précédentes (étapes 505 à 550) sont répétées.
Comme décrit précédemment, il est possible de créer des machines virtuelles indépendamment les unes des autres afin de permettre leur intégration au sein d'un hyperviseur selon des besoins spécifiques. En outre, un tel mode de réalisation permet à différents intervenants d'intégrer leurs applications selon leurs besoins. Etant responsable d'une ou de plusieurs machines virtuelles, chaque intervenant peut ainsi offrir une garantie en terme de sûreté de fonctionnement.
Ainsi, en utilisant l'architecture du STAD et les algorithmes décrits précédemment, un fournisseur d'applications peut livrer une ou plusieurs machines virtuelles intégrant ses applications et communiquer le mode opératoire d'installation de la plateforme logicielle recommandée (à base de virtualisation) sur le STAD. Ce dernier peut aussi être fourni avec l'hyperviseur et la ou les machines virtuelles pré-installées.
De plus, comme indiqué précédemment, des clients peuvent utiliser une clé USB ou une carte SD pour stocker le profil et les données utilisateur tels qu'un identifiant de messagerie, des témoins et des favoris d'un navigateur Internet ainsi que des scripts de connexion. De cette façon, les STADs sont interchangeables et peuvent être gérés en flotte.
De façon avantageuse, une base logicielle commune est installée sur une flotte de STADs, pour tous les usages et tous les types d'aéronefs auxquels les STADs sont susceptibles d'être connectés. La ou les machines virtuelles correspondant aux types d'utilisation et/ou d'aéronefs sont ensuite installées. A la fin de la configuration, une ou plusieurs images de références sont créées pour permettre la configuration du STAD lors de son utilisation. Ces images de référence peuvent en outre être restaurées par l'utilisateur sans recourir à un technicien.
A titre d'illustration, la mallette d'outils connue sous le nom d'Electronic Flight Bag (EFB) est ici considérée. Il s'agit d'une mallette d'outils à partir desquels un pilote et son second préparent une mission à effectuer. L1EFB n'est pas une application ayant un niveau de sûreté élevé.
Il existe essentiellement trois classes d'EFB définies de la façon suivante,
- classe 1 : les données de mission sont chargées dans un STAD portable depuis le sol. Le STAD est emporté à bord de l'aéronef mais il n'est pas connecté au système d'information de bord. Les données sont échangées avec le sol uniquement après l'atterrissage ;
- classe 2 : il s'agit d'un STAD portable standard, attaché à un pilote. Le STAD échange des données avec le sol, notamment la compagnie aérienne et l'aéroport, et avec le système d'information de l'aéronef pendant toutes les phases de vol ; et,
- classe 3 : le STAD est solidaire au cockpit et peut accéder aux systèmes critiques qui requièrent un haut niveau de certification.
Les EFBs de classe 2 peuvent donc être gérés par un STAD conforme à l'invention. Dans ce cas, le fournisseur d'EFBs livre les applications opérationnelles ou une partie d'entre elles au client. Il lui communique la liste des systèmes compatibles et la configuration minimale de l'hyperviseur ou livre le STAD avec l'hyperviseur et les machines virtuelles pré-installées.
Durant une phase de préparation initiale, le client prépare les machines virtuelles selon les applications opérationnelles et les données de configuration reçues. Il prépare également les machines virtuelles permettant de mettre en œuvre les applications spécifiques de l'entreprise, par exemple des applications de messagerie.
Ainsi, en utilisant les machines virtuelles créées, un technicien informatique peut installer l'hyperviseur du STAD qui permet alors d'utiliser les moyens informatiques de l'entreprise, les fonctionnalités de l'EFB et, éventuellement, d'autres.
Pour que les STADs soient interchangeables, les données des utilisateurs sont de préférence stockées sur une carte mémoire amovible, par exemple une carte de type SD et non sur le disque dur interne des STADs. En utilisation, lorsqu'une compromission est détectée sur une machine virtuelle, par exemple une machine virtuelle qui s'est connectée à un site Internet, l'utilisateur peut redémarrer la machine virtuelle en utilisant l'image de référence associée la plus récente sans recourir à un technicien.
De même, en cas de panne matérielle d'un STAD, le technicien récupère la carte mémoire de l'utilisateur et l'insère dans un autre STAD de la flotte. Il n'a pas besoin de personnaliser ce STAD ni de copier des données de l'utilisateur.
La figure 6 illustre un exemple d'architecture matérielle adaptée à mettre en œuvre l'invention. Le dispositif 600 comporte ici un bus de communication 605 auquel sont reliés :
- une unité centrale de traitement ou microprocesseur 610 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ;
- une mémoire morte 615 (ROM, acronyme de Read OnIy Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en œuvre de l'invention ;
- une mémoire vive ou mémoire cache 620 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et
- une interface de communication 650 adaptée à transmettre et à recevoir des données.
Le dispositif 600 dispose également, de préférence, des éléments suivants :
- un écran 625 permettant de visualiser des données telles que des représentations des commandes et de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 630 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ;
- d'un disque dur 635 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 640 adapté à recevoir une carte mémoire 645 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600.
Le code exécutable de chaque programme permettant au dispositif programmable de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 635 ou en mémoire morte 615.
Selon une variante, la carte mémoire 645 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 600, est stocké dans le disque dur 635.
Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 650, pour être stocké de façon identique à celle décrite précédemment.
De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 600 avant d'être exécutés.
L'unité centrale 610 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 635 ou dans la mémoire morte 615 ou bien dans les autres éléments de stockage précités.
Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 635 ou la mémoire morte 615, sont transférés dans la mémoire vive 620 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention.
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims

REVENDICATIONS
1. Composant logiciel pour ordinateur adapté au traitement automatique de données multi-usages, le composant logiciel étant caractérisé en ce qu'il met en œuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité et en ce qu'il comprend,
- une pluralité de machines virtuelles (215), chaque machine virtuelle étant adaptée à exécuter au moins une fonction ayant besoin d'un niveau de sûreté ou d'une limite de responsabilité prédéterminé, au moins une desdites fonctions étant adaptée selon des paramètres de la machine virtuelle dans laquelle elle est exécutée ; et,
- un hyperviseur (210) adapté à contrôler l'exécution de ladite pluralité de machines virtuelles.
2. Composant logiciel selon la revendication précédente selon laquelle ledit hyperviseur comprend des moyens d'authentification pour authentifier (310) au moins une machine virtuelle de ladite pluralité de machine virtuelle.
3. Composant logiciel selon la revendication précédente selon lequel lesdits moyens d'authentification sont adaptés à vérifier l'intégrité (315) de ladite au moins une machine virtuelle authentifiée.
4. Composant logiciel selon l'une quelconque des revendications 2 et 3 selon lequel lesdits moyens d'authentification sont adaptés à vérifier le niveau d'isolation (320) de ladite au moins une machine virtuelle authentifiée par rapport à au moins une autre machine virtuelle de ladite pluralité de machines virtuelles.
5. Composant logiciel selon l'une quelconque des revendications précédentes comprenant en outre des moyens de mémorisation de données traitées par au moins une machine virtuelle de ladite pluralité de machine virtuelle, lesdits moyens de mémorisation étant adaptés à mémoriser lesdites données traitées dans une mémoire amovible dudit ordinateur (355).
6. Composant logiciel selon la revendication précédente selon lequel lesdits moyens de mémorisation de données sont mis en œuvre par des machines virtuelles de ladite pluralité de machines virtuelles dont le niveau de sûreté est inférieur à un seuil prédéterminé (340).
7. Composant logiciel selon l'une quelconque des revendications précédentes comprenant en outre des moyens de contrôle d'un niveau de confiance (345) d'au moins une donnée traitée par au moins une machine virtuelle de ladite pluralité de machines virtuelles, ladite au moins une donnée traitée ne pouvant être mémorisée localement (350) dans ledit ordinateur qu'après qu'elle ait été contrôlée.
8. Composant logiciel selon l'une quelconque des revendications précédentes comprenant en outre des moyens de transfert de données entre une première et une seconde machines virtuelles de ladite pluralité de machines virtuelles, lesdits moyens de transfert étant adaptés à filtrer (330, 335) des données transférées si le niveau de sûreté de ladite seconde machine virtuelle est supérieur au niveau de sûreté de ladite première machine virtuelle.
9. Composant logiciel selon l'une quelconque des revendications précédentes selon lequel des données de configuration utilisées pour démarrer au moins une machine virtuelle de ladite pluralité de machine virtuelle ne sont pas modifiées au cours de l'exécution de ladite au moins une machine virtuelle démarrée.
10. Dispositif comprenant des moyens adaptés à la mise en œuvre de chacun des éléments du composant logiciel selon l'une quelconque des revendications précédentes.
EP10752854A 2009-07-28 2010-07-28 Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité Ceased EP2460071A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0955281A FR2948789B1 (fr) 2009-07-28 2009-07-28 Composant logiciel et dispositif pour le traitement automatise de donnees multi-usages, mettant en oeuvre des fonctions ayant besoin de differents niveaux de surete ou limites de responsabilite
PCT/FR2010/000552 WO2011020954A2 (fr) 2009-07-28 2010-07-28 COMPOSANT LOGICIEL ET DISPOSITIF POUR LE TRAITEMENT AUTOMATISÉ DE DONNÉES MULTI-USAGES, METTANT EN œUVRE DES FONCTIONS AVANT BESOIN DE DIFFÉRENTS NIVEAUX DE SÛRETÉ OU LIMITES DE RESPONSABILITÉ

Publications (1)

Publication Number Publication Date
EP2460071A2 true EP2460071A2 (fr) 2012-06-06

Family

ID=41432807

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10752854A Ceased EP2460071A2 (fr) 2009-07-28 2010-07-28 Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité

Country Status (8)

Country Link
US (1) US9804875B2 (fr)
EP (1) EP2460071A2 (fr)
JP (1) JP5646622B2 (fr)
CN (1) CN102656559B (fr)
CA (1) CA2769239C (fr)
FR (1) FR2948789B1 (fr)
RU (1) RU2012107091A (fr)
WO (1) WO2011020954A2 (fr)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR112012020933A2 (pt) * 2010-02-23 2017-03-07 Astronautics Corp pacote de voo eletrônico de classe 3
CN103677983B (zh) * 2012-09-20 2018-05-04 三亚中兴软件有限责任公司 应用的调度方法及装置
FR2997811B1 (fr) * 2012-11-05 2015-01-02 Viaccess Sa Dispositif de traitement de contenus multimedia mettant en oeuvre une pluralite de machines virtuelles.
US9781118B2 (en) 2013-03-14 2017-10-03 Intel Corporation Differentiated containerization and execution of web content based on trust level and other attributes
RU2568282C2 (ru) * 2014-04-18 2015-11-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ обеспечения отказоустойчивости антивирусной защиты, реализуемой в виртуальной среде
US9454497B2 (en) * 2014-08-15 2016-09-27 Intel Corporation Technologies for secure inter-virtual-machine shared memory communication
US20160098259A1 (en) * 2014-10-02 2016-04-07 The Boeing Company Software Aircraft Part Installation System
US9444849B2 (en) * 2014-10-06 2016-09-13 The Boeing Company Enforcing policy compliance on a device
ES2896405T3 (es) 2014-11-19 2022-02-24 Technion Res & Dev Foundation Sistema de generación de plasma frío
FR3038404B1 (fr) * 2015-07-02 2019-04-26 Viaccess Procede et systeme d'execution securisee de machines virtuelles par un ensemble de dispositifs programmables interconnectes
WO2017011006A1 (fr) * 2015-07-15 2017-01-19 Nokia Solutions And Networks Oy Instanciation sensible à la sécurité se rapportant à des services de réseau et/ou des fonctions de réseau virtualisées
DE102015214389A1 (de) * 2015-07-29 2017-02-02 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aktualisieren einer auf einer physischen Maschine unter einem Hypervisor betriebenen virtuellen Maschine
US10225349B2 (en) 2016-10-26 2019-03-05 Honeywell International Inc. Software development kit for aircraft tablet device and airborne application server
US11175937B2 (en) * 2018-03-30 2021-11-16 The Boeing Company Virtualized avionics systems for operational environments
CN116260823B (zh) * 2023-05-15 2023-09-15 南方电网数字电网研究院有限公司 受控数据共享方法、装置、计算机设备和存储介质

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442645A (en) * 1989-06-06 1995-08-15 Bull Cp8 Method for checking the integrity of a program or data, and apparatus for implementing this method
US5809493A (en) * 1995-12-14 1998-09-15 Lucent Technologies Inc. Knowledge processing system employing confidence levels
US5870610A (en) * 1996-06-28 1999-02-09 Siemens Business Communication Systems, Inc. Autoconfigurable method and system having automated downloading
US6941410B1 (en) * 2000-06-02 2005-09-06 Sun Microsystems, Inc. Virtual heap for a virtual machine
US6922774B2 (en) * 2001-05-14 2005-07-26 The United States Of America As Represented By The National Security Agency Device for and method of secure computing using virtual machines
US7730318B2 (en) * 2003-10-24 2010-06-01 Microsoft Corporation Integration of high-assurance features into an application through application factoring
US7401230B2 (en) * 2004-03-31 2008-07-15 Intel Corporation Secure virtual machine monitor to tear down a secure execution environment
US7506170B2 (en) * 2004-05-28 2009-03-17 Microsoft Corporation Method for secure access to multiple secure networks
JP2006201845A (ja) * 2005-01-18 2006-08-03 Hitachi Software Eng Co Ltd ウィルス感染及び機密情報漏洩防止対策コンピュータ
US7881755B1 (en) * 2005-05-26 2011-02-01 Marvell International Ltd. Wireless LAN power savings
CN100547515C (zh) * 2005-07-15 2009-10-07 联想(北京)有限公司 支持可信计算的虚拟机系统及在其上实现可信计算的方法
TW200745951A (en) * 2005-10-21 2007-12-16 Vir2Us Inc Computer security method having operating system virtualization allowing multiple operating system instances to securely share single machine resources
WO2007083300A2 (fr) * 2006-01-17 2007-07-26 Kidaro (Israel) Ltd. Sécurisation de données dans un environnement en réseau
JP4735331B2 (ja) * 2006-03-01 2011-07-27 日本電気株式会社 仮想マシンを利用した情報処理装置および情報処理システム、並びに、アクセス制御方法
JP2008084081A (ja) * 2006-09-28 2008-04-10 Nec Corp 機密情報の漏洩防止システム、機密情報の漏洩防止方法、記録媒体、及びプログラム
US8234641B2 (en) * 2006-10-17 2012-07-31 Managelq, Inc. Compliance-based adaptations in managed virtual systems
US9015703B2 (en) * 2006-10-17 2015-04-21 Manageiq, Inc. Enforcement of compliance policies in managed virtual systems
US8949826B2 (en) * 2006-10-17 2015-02-03 Managelq, Inc. Control and management of virtual systems
JP4907371B2 (ja) * 2007-02-01 2012-03-28 株式会社日立ソリューションズ ウィルス感染及び機密情報漏洩防止対策システム
US8024790B2 (en) * 2007-04-11 2011-09-20 Trend Micro Incorporated Portable secured computing environment for performing online confidential transactions in untrusted computers
JP4987555B2 (ja) * 2007-04-27 2012-07-25 株式会社東芝 情報処理装置、および情報処理システム
JP4782871B2 (ja) * 2007-10-03 2011-09-28 富士通株式会社 デバイスアクセス制御プログラム、デバイスアクセス制御方法および情報処理装置
US8555081B2 (en) * 2007-10-30 2013-10-08 Vmware, Inc. Cryptographic multi-shadowing with integrity verification
US20090133097A1 (en) * 2007-11-15 2009-05-21 Ned Smith Device, system, and method for provisioning trusted platform module policies to a virtual machine monitor
KR101489244B1 (ko) * 2007-12-24 2015-02-04 삼성전자 주식회사 가상 머신 모니터 기반의 프로그램 실행 시스템 및 그 제어방법
JP5029701B2 (ja) * 2008-01-09 2012-09-19 富士通株式会社 仮想マシン実行プログラム、ユーザ認証プログラムおよび情報処理装置
US8443440B2 (en) * 2008-04-05 2013-05-14 Trend Micro Incorporated System and method for intelligent coordination of host and guest intrusion prevention in virtualized environment
US8561137B2 (en) * 2008-07-23 2013-10-15 Oracle International Corporation Techniques for identity authentication of virtualized machines
US8387046B1 (en) * 2009-03-26 2013-02-26 Symantec Corporation Security driver for hypervisors and operating systems of virtualized datacenters

Also Published As

Publication number Publication date
WO2011020954A2 (fr) 2011-02-24
US9804875B2 (en) 2017-10-31
CN102656559A (zh) 2012-09-05
RU2012107091A (ru) 2013-09-10
WO2011020954A3 (fr) 2011-04-14
FR2948789B1 (fr) 2016-12-09
JP2013500531A (ja) 2013-01-07
CN102656559B (zh) 2016-12-07
CA2769239A1 (fr) 2011-02-24
US20120167089A1 (en) 2012-06-28
FR2948789A1 (fr) 2011-02-04
JP5646622B2 (ja) 2014-12-24
CA2769239C (fr) 2018-10-23

Similar Documents

Publication Publication Date Title
WO2011020954A2 (fr) COMPOSANT LOGICIEL ET DISPOSITIF POUR LE TRAITEMENT AUTOMATISÉ DE DONNÉES MULTI-USAGES, METTANT EN œUVRE DES FONCTIONS AVANT BESOIN DE DIFFÉRENTS NIVEAUX DE SÛRETÉ OU LIMITES DE RESPONSABILITÉ
US11704413B2 (en) Assessing latent security risks in Kubernetes cluster
US20230021216A1 (en) Systems and methods for deploying secure edge platforms
US10686809B2 (en) Data protection in a networked computing environment
US9411954B2 (en) Managing software deployment
EP3997602B1 (fr) Sécurité blackbox pour conteneurs
JP7397557B2 (ja) セキュア実行ゲスト所有者環境制御
EP3651099B1 (fr) Traitement de transactions distribuées
FR3067803A1 (fr) Synchronisation d'un systeme dual avionique et non-avionique
US20170322929A1 (en) Script manager for distributed systems
US11176253B2 (en) HSM self-destruction in a hybrid cloud KMS solution
EP4381404B1 (fr) Attestation d'un invité sécurisé
US11588847B2 (en) Automated seamless recovery
US20190251255A1 (en) Malicious code avoidance using transparent containers
EP4381400A1 (fr) Données confidentielles fournies à un invité sécurisé par l'intermédiaire de métadonnées
US11361055B1 (en) Protection of a content repository using dynamic watermarking
WO2022179820A1 (fr) Profil préconfiguré sécurisé pour une configuration de contrôle d'accès à base de rôles
US11194926B2 (en) Intelligent authorization and protection of user data
US20250200156A1 (en) Identification, validation and authentication using biological patterns and numbers
Mishra et al. Features and resolution of SAAS model in cloud computing
Gunasekhar et al. Detection and Mitigation of Insider Attacks in a Cloud Infrastructure: Emerging Research and Opportunities: Emerging Research and Opportunities
Chasens The Discovery, Disclosure, and Investigation of CVE-2024-25825
LeBlanc Windows 8 70-687 Study Guide

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20120209

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130923

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20221006