WO2015188247A1 - Système et procédé d'entretien pour systèmes de base de données en nuage - Google Patents

Système et procédé d'entretien pour systèmes de base de données en nuage Download PDF

Info

Publication number
WO2015188247A1
WO2015188247A1 PCT/CA2014/050528 CA2014050528W WO2015188247A1 WO 2015188247 A1 WO2015188247 A1 WO 2015188247A1 CA 2014050528 W CA2014050528 W CA 2014050528W WO 2015188247 A1 WO2015188247 A1 WO 2015188247A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
record
user
cloud
account
Prior art date
Application number
PCT/CA2014/050528
Other languages
English (en)
Inventor
David Everett
Original Assignee
Royal Canadian Mint/Monnaie Royale Canadienne
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 Royal Canadian Mint/Monnaie Royale Canadienne filed Critical Royal Canadian Mint/Monnaie Royale Canadienne
Priority to PCT/CA2014/050528 priority Critical patent/WO2015188247A1/fr
Publication of WO2015188247A1 publication Critical patent/WO2015188247A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/88—Monitoring involving counting

Definitions

  • the present invention relates to secure storage and transfer of information, and in particular to a keep-alive system and method for cloud-based database systems.
  • Cloud-based services typically utilize a host server connected to a data network such as the Internet.
  • the host server normally comprises one or more computer servers or server clusters maintained and operated by a cloud service provider.
  • a client of the cloud service provider can access the host server to utilize various cloud-based computing and storage services available on the host server.
  • An example of cloud-based services includes an on-line cloud-hosted electronic payment system.
  • the host server may be used to store user account records, which may include information related to financial transactions of each user and an account balance.
  • Cloud-based services are attractive for electronic payment systems because the host servers offer very high availability and scalability, with the ability to process and store enormous amounts of information and handle multiple transactions simultaneously.
  • cloud-based services also suffer a limitation in that data stored on a host server is vulnerable to un-authorized access and other forms of misuse. This difficulty arises from the fact that a user must trust a legally unrelated party (in this case the cloud service provider) to ensure the security and integrity of the user ' s data.
  • the user or payment services provider
  • the authentication algorithms are executed on the host server, and the passwords and/or other authentication information wi ll be received by the host server during a user log-on process. Users must therefore trust that the cloud service provider will not manipulate the authentication algorithms or misuse the authentication information provided by the user.
  • account data stored on the host server may be encrypted or otherwise cryptograph ically secured (for example by means of digital signatures and/or checksums), and messaging between users and the payment system may use encrypted messaging (such as Secure Socket Layer - SSL) to convey a user's financial information.
  • encrypted messaging such as Secure Socket Layer - SSL
  • the encryption algorithms are executed on the host server, and the keys will be stored on the host server at least for the duration of a user session. Users must therefore trust that the cloud service provider will not manipulate the encryption algorithms (e.g. to provide a "back-door") or misuse the keys stored on the server during a user session.
  • Applicant's co-pending US patent application entitled “Cloud-based Secure information storage and transfer system” teaches a system that addresses this problem, by providing a secure data center which provides encryption and decryption services using keys that are securely stored in the data center. With this arrangement, user data can be cryptographically secured by the data center prior to be forwarded to the cloud host server for storage. This system is advantageous because data stored on the cloud host server is secured, but the secret keys and algorithms are never present on the cloud host server.
  • an aspect of the present invention provides a keep-alive system and method for cloud-based database systems.
  • a plurality of fields of the database are monitored to track a predetermined pattern of change with respect to time.
  • a departure from the predetermined pattern of change indicates an unexpected action of the database such as, for example, a roll-back of the state of the database.
  • the present technique is able to detect unexpected actions of the database, including roll-backs. This enables administrative and/or security personnel to investigate and take appropriate actions.
  • FIG. 1 schematically illustrates a representative database format usable in embodiments of the present invention
  • FIG. 2 is a block diagram schematically illustrating a cloud-based system in which embodiment of the present invention may be implemented
  • FIGs. 3A and 3B are message flow diagrams schematically illustrating a possible scenario for completing an e-commerce transaction in the cloud-based system of FIG. 2; and
  • FIGs. 4A and 4B are flowcharts schematical ly i llustrating representative steps and process rules implemented in the methods of FIGs. 3A and 3B, and including methods in accordance with the present invention.
  • the present invention provides keep-alive system and method for cloud-based database systems. Embodiments of the invention are described below, by way of example only, with reference to FIGs. 1 -4.
  • the present invention wil l be described by way of an embodiment in which the present invention is used to enable detection of roll-backs of a database storing user account information in a cloud-based payments system.
  • the present invention is not l imited to such embodiments, but rather that the same techniques may be used to detect improper operations in any database having one or more fields which exhibit a detectable pattern of state changes with respect to time during normal operation of the database.
  • each record 4 contains information regarding an account associated with a user.
  • the record includes fields for storing the respective account ID 6, Private and Public Keys 8 and 1 0, and Certificate 12 uniquely assigned to the account, a current content (Cur.Val) 14 and a log 1 6.
  • the Keys 8- 10 and Certificate 12 enable cryptographic security of messaging for transferring monetary value to and from the respective account using, for example, well-known Public Key Infrastructure (PKI) techniques.
  • the log 16 contains information relating to each transaction executed by or on behalf of the respective account.
  • PKI Public Key Infrastructure
  • each record 4 of the database 2 may also include a field identifying a currency 1 8 of the current value 1 4, and a count 20 of transactions that have been completed by (or on behalf of) the account represented by that record 4.
  • the contents of a record 4 provides the context of a respective account assigned to a user.
  • the ID field 6 is unencrypted, so that a payment appl ication can readily use the account ID contained in received messages (as will be described in greater detail below) to retrieve a record 4 from the database 2 using well known techniques.
  • At least the Keys 8- 10 and Certificate 12 are encrypted using one or more secret keys maintained independently of either the cloud-based payments system or the cloud host itself.
  • one or more other fields such as the current value (Cur.Val) 1 4 and the log 16 are also encrypted.
  • un-encrypted fields may protected by means of cryptographic checksums and/or signatures, so as to prevent un-authorized changes in these fields. This arrangement is beneficial, in that it allows any given record 4 to be readily retrieved from the database 2, and updated using known techniques; but at the same time maintains security of the critical content of each record 4 by ensuring that it is computationally infeasible for any unauthorized party to read its secret data or modify its contents.
  • each database record 4 includes a count 20 of transactions that have been completed by or on behalf of the account represented by that record 4. It wi ll be appreciated that the count value stored in this field must necessarily increase over time, as the owner of the account uses it for various transactions.
  • FIG. 2 illustrates a representative cloud-based system in which techniques in accordance with the present invention may be used.
  • a representative cloud- based secure information storage and transfer system 22 comprises a cloud host system 24 and secure data center 26, both of which are connected to a data network 28, such as, for example, the Internet.
  • Merchant systems 30 and individual users 32 may interface with the cloud host system 24 to access and use cloud based applications, such as e-commerce applications, for example.
  • the cloud host system 24 may be managed by a cloud service provider and may comprise one or more servers or server clusters configured to provide computing and storage services to a plurality of subscribers of the cloud service provider.
  • Cloud host systems of a type usable in the present technique are well known, and cloud hosted services are readily available from several cloud service providers (such as, for example, Amazon.com, and Google.com).
  • a merchant may use the merchant system 30 to manage an e-commerce application 34 executing on the cloud host 24, and maintain a product catalogue database 36 stored on the cloud host 24.
  • an individual user 12 may use their communication device 38 to access the e-commerce application 34, which then may permit the user 32 to browse the catalogue 36 and select items the user 12 wishes to purchase.
  • the e-commerce application 34 may access a payment application 40 in order to complete the purchase transaction.
  • the payment application may use the database 2 to obtain information of the user ' s and merchant's respective accounts, and to complete the transfer of monetary value between these accounts.
  • the user's account ID 6s, private and public keys 8s- 10s and certificate 12s may be saved on the user's communication device 38.
  • the merchant ' s account I D 6m, private and public keys 8m- 10m and certificate 12m may be saved on the merchant system 30.
  • a payment services provider manages both the payment application 40 and the data center 26, which generally comprises a manager 42 connected to one or more secure servers 44.
  • the manager 42 controls the flow of messages into and out of the data center 26.
  • the manager 42 distributes messaging across the secure servers 44, for example to provide load balancing or redirection in the event of a failure of one of the secure servers 44.
  • the manager 42 may also provide encryption and decryption services, as w ill be described in greater detail below.
  • the manager 42 is provided as a Hardware Security Module (HSM) of a type known in the art and commercially available, and executing suitable software to implement the appropriate functionality.
  • HSMs Hardware Security Modules
  • Security of the data center 26 is enhanced by configuring the manager 42 to only exchange messages with the Payment Application 40.
  • One way of accomplishing this is to establish and maintain a secure connection 46 or Virtual Private Network (VPN ) between the manager 42 and the Payment Application 40 using a known tunnelling protocol, for example.
  • the manager 42 can be configured to accept and send messages through the secure connection 46, and to discard messages received via the data network 28 from any other source.
  • the security of the data center 26 may also be enhanced by ensuring that the network address of the data center 26 is known only to the Payment Application 40. and is not advertised to the network 28.
  • FIG. 3A is a message flow diagram illustrating an example operation of the Payment application 40 and data center 26 for completing an e-commerce transaction implemented in the system of FIG. 2.
  • a user 32 uses their communications device 38 to access the merchant's e-commerce application 34, browse the merchant's product catalog 36, and select an item to purchase, all in a conventional manner.
  • the e-commerce site 34 Based on the user's purchase selection, the e-commerce site 34 initiates a payment sequence, by formulating a Value Request Message (VRM) containing the merchant ' s account ID 6m as the intended recipient, and the payment amount owing as the content to be transferred, and sends this VRM to the user's communication device 38 (at S4).
  • VRM Value Request Message
  • the subscriber' s communication device 38 redirects the VRM to the Payment Application 40 (at S6).
  • the redirected VRM may also include the users account ID 6s and Certificate 12s.
  • the Payment Application 40 may perform verification process (at S8) to confirm the user's account ID 6s and Certificate 1 2s. In some embodiments, the Payment Application 40 may also attempt to obtain confirmation of the user ' s acceptance of the transaction. In some embodiments, the verification processes may be handled within secure connections (for example Secure Sockets Layer, SSL. connections) set up for this purpose between the Payment Application 40 and either one or both of the e-commerce application 34 and the Cloud Host 24. In some embodiments, the Payment Appl ication 40 may obtain information of the transaction (e.g. user ' s account ID 6s and the transaction amount) from the e-commerce application 34.
  • secure connections for example Secure Sockets Layer, SSL. connections
  • the Payment Application 40 may obtain confirmation of the user ' s authentication status from either the cloud host 24 or the e-commerce application 34.
  • the Payment Appl ication 40 may not be necessary for the Payment Appl ication 40 to request the user 32 to complete further authentication steps in order to complete the transaction. However, if desired, these further additional authentication steps may be performed using known techniques.
  • the Payment Application 40 requests (at S 10) the user's account record 4s from the database 2.
  • the database record 4s representing the users' account is locked (at S I 2) to prevent another process from accessing or revising that record before completion of the current transaction.
  • the record 4s may be locked by the database engine (not shown), in response to the request message from the Payment Appl ication 40.
  • the record may be locked by the Payment Application 40 itself, for example by means of suitable control messages.
  • the Payment Application 40 Upon receipt of the subscriber ' s account record from the database 2 (at S I 4), the Payment Application 40 forwards the VRM and the user ' s account record (at S I 6) to the data center 26 for processing.
  • the manager 42 may decrypt the user's record using locally stored keys, and pass the VRM and the decrypted record to a secure server 44 for processing.
  • the manager 42 may pass the encrypted record 4s and the VRM to a secure server 44, which will then decrypt the record prior to processing the VRM.
  • the secure server 44 processes the VRM and the decrypted context (S I 8) in accordance with a set of processing rules (described in greater detail below), to generate (S20) at least: a value transfer message (VTM) for conveying the payment amount owing to the Merchant and an updated version of the user's account record.
  • VTM value transfer message
  • the secure server 44 performs encryption/decryption functions
  • at least a portion of the updated user's account record may be encrypted and/or secured using cryptographic checksums by the secure server 44 prior to passing them to the manager 42.
  • the manager 42 may encrypt and/or generate checksums securing portions of the updated account record prior to forwarding it to the Payment Application 40.
  • the secure server 44 may also generate one or more checksums, signatures or other validation data, which may be passed to the manager 42 and/or the Payment Application 40 so that the integrity of the VTM and updated user ' s account record can be verified.
  • the Payment Application 40 may forward the VTM to the subscriber ' s communication device 38 (at S22).
  • the updated account record may then be stored (at S24) in the appropriate record 4 of the database 2, and that record unlocked (at S26) to permit other transactions
  • the user' s communication device 38 can forward the VTM to the e-commerce application 34 (at S28) in order to complete the transaction.
  • the e-commerce application 34 A representative process for completing a transaction following receipt of the VTM by the e-commerce application 34 is described below with reference to FIG. 3B.
  • an acknowledgment message may be sent (at S30) to the user's communication device 38.
  • a corresponding acknowledgment message may also be sent by the e-commerce application 34 to the Merchant's system 30.
  • the e-commerce application 34 when the e-commerce application 34 receives a VTM from a user's communication device 38 (at S28). it formulates and sends a load request message (at S32) containing the VTM to the Payment Application 40.
  • the Payment application 40 may perform a verification process (at S34) to confirm the integrity of the VTM.
  • the verification process may use the User ' s Certificate 12s and/or signature/checksums contained in the VTM to verify that the VTM content has not been changed since it was generated.
  • the payment application 40 may discard the VTM and the Load request message. In some embodiments, the payment appl ication may return a failure notification message (not shown) to the e-commerce application 34.
  • the Payment application 40 requests the Merchant ' s account record from the database 2 (at S36). Preferably, the database record 4m representing the Merchant's account is locked (at S38) to prevent another process from accessing or revising that record before completion of the current transaction. In some embodiments, the record may be locked by the database engine (not shown), in response to the request message from the Payment Application 40. In other embodiments, the record may be locked by the Payment application 40 itself for example by means of suitable control messages. Upon receipt of the Merchant ' s account record from the database 2 (at S40), the Payment application 40 forwards the VTM and the Merchant's record 6m to the data center 26 (at S42) for processing.
  • the manager 42 may decrypt the Merchant' s context, and pass the VTM and the decrypted record 4 to a secure server 44 for processing.
  • the manager 42 may pass the encrypted record and the VTM to a secure server 44, which will then decrypt the record 4 prior to processing the VTM.
  • the secure server 44 processes (at S44) the VTM and the decrypted record 4 in accordance with a set of processing rules (described in greater detail below), to generate at least: an acknowledgment message indicating success or failure of the transaction; and an updated version of the Merchant ' s record 4m.
  • At S46 these items are passed back to the manager 42 for forwarding to the Payment application 40 (at S46).
  • the secure server 44 performs encryption/decryption functions
  • at least a portion of the updated Merchant's record 4 may be encrypted by the secure server 44 prior to passing them to the manager 42.
  • the manager 32 may encrypt portions of the updated Merchant's record 4 prior to forwarding them to the Payment Application 20.
  • the secure server 44 may also generate one or more checksums, signatures or other validation data, which may be passed to the manager 42 and/or the Payment application 40 so that the integrity of the updated merchant ' s record 4m can be verified.
  • the Payment application 40 may store the updated Merchant's record 4m in the database 2 (at S50), and unlock that record (at S52) to permit other transactions.
  • corresponding acknowledgment messages may be sent (at S54) to any one or more of the e- commerce application 34, the user ' s communication device 38 and/or the merchant system 30 to indicate that the transaction has been successfully completed.
  • the Payment appl ication 40 may send failure messages to any one or more of the user's communication device 38, the merchant system 30, and the e-commerce application 34 so that the user's purchase may be cancelled or other steps taken to identify and rectify the problem.
  • the secure server 44 processes a VRM and the user's record 4 in accordance with a set of processing rules at step S I 8, to generate at least a VTM, and an updated version of the user's account record 4s.
  • the secure server 44 processes a VTM and the Merchant's record 4m in accordance with a set of processing rules at step S44, to generate at least an Acknowledgment message and an updated version of the Merchant' s record 4m.
  • the secure server 44 is able to examine the respective count value 20 of the record 4 involved in any given transaction.
  • the count value 20 is particularly useful because in the normal course of operation it must necessarily increase monotonically with respect to time. This pattern of behaviour of the count value enables the evolution of the state of the database to be monitored in such a way that unexpected database actions, such as a roll-backs for example, can be detected.
  • FIGs. 4A and 4B illustrate processing of the data center that incorporates one method of accomplishing this monitoring operation.
  • FIG. 4A is a flow chart il lustrating representative processing rules for processing a VRM and a user' s account record 4s. to generate a VTM and an updated version of the user's account record 4s, which is referenced at step S I 8 of FIG. 3A.
  • the process begins with the secure server 44 receiving the VRM and decrypted user ' s account record 4s.
  • the secure server 44 retrieves an old count value of the user's account stored in the data center 26 (step S62), and compares it to the count value 20 in the decrypted user's account record 4s. If the count value 20 is equal to, or greater than the old count value, then the proper behavior of the count value is confirmed, and the process may continue, Otherwise, an error message indicative of an improper database operation is generated and returned to the manager 42.
  • the secure server 44 compares (at S66) the content (Val. ) to be transferred with the current content (Cur.Val) 14 stored in the user's account record 4s. If Cur.Val 14 is less than the content to be transferred (Val.), then the secure server 44 generates and returns an error message (at S68). Otherwise, the secure server 44 decreases the Cur.Val 14 by the content (Val.
  • VTM Value Transfer Message
  • the secure server 44 then applies a Digital Signature (DS) and the user's Certificate 12s to the VTM (at S74).
  • DS Digital Signature
  • the secure server 44 then records information about the transfer in the Log field 16 of the user ' s account record 4s (at S76), and updates the user's old count value stored in the data center 26. Finally, the secure server 44 returns (at S80) the digitally signed VTM and the updated record 4s to the Manager 42.
  • FIG. 4B is a flow-chart illustrating representative processing rules for processing a received VTM message to load value to a subscriber ' s (in the illustrated example, the merchant ' s) account.
  • the process begins with the secure server 44 receiving the VTM and decrypted Merchant's account record 4m from the manager 42.
  • the secure server 44 uses the Certificate 1 2 to verify (at S84) the digital signature of the received VTM. If the verification fails, the VTM is discarded (at S86), and an error message is returned (at S88) to the Manager 42 before the process is terminated.
  • the secure server 44 uses the nonce and both the user' s account ID 6s and the merchant's account ID 6m to compare (at S90) the received VTM with the decrypted Merchant' s log field 16m to determine whether the VTM is a duplicate of a VTM previously received from the user ' s account. If it is a duplicate, the VTM is discarded (at S86), an error message is returned to the Manager 42 (at S88) and the process is terminated. Otherwise, the secure server 44 retrieves an old count value of the merchant ' s account stored in the data center 26 (step S92), and compares it to the count value 20 in the decrypted user ' s account record 4s (at step S94). If the count value 20 is equal to, or greater than the old count value, then the proper behavior of the count value is confirmed, and the process may continue. Otherwise, an error message indicative of an improper database operation is generated and returned to the manager 42 (at step S88).
  • the secure server 44 updates the merchant's log 14 with a transaction record including information about the transaction (at S96), updates the user' s old count value stored in the data center 26 (at S98) and increases the current content (Curr.Val) 14 stored in the Merchant ' s record 4m by the content (Val.) contained in the VTM (at S I 00). Finally, the secure server 44 returns (at S I 02) an acknowledgment message and the updated Merchant ' s account record 4m to the manager 42, indicating that the VTM message has been successfully processed.
  • the count field value of the user ' s account record 4s is used to check for proper operation of the database (at S64). However, this is not essential, i f desired, the merchant's count value may be used for this purpose.
  • a subset of subscriber accounts may be selected and monitored to track the evolving state of the database. For example, it is contemplated that some subscriber accounts (such as the account of an individual user 12. for example) may be involved in transactions only infrequently, while others (such as a merchant, broker, or bank) may experience a large number of transactions within any given period of time. It is expected that subscriber accounts that experience a lot of activity (which may be referred to as "high-activity accounts " ) will provide a more precise indication of the evolving state of the database. For example, the embodiments if FIGs.
  • the data center may compute an aggregate function over a plurality of subscriber accounts. For example, in an embodiment that tracks count field values of high activity accounts, the data center may compute a running total of count field values, or a running average, or any other suitable function across the accounts being tracked. This arrangement can be beneficial in that an aggregate value computed across a plurality of subscriber accounts operates as a filter function to smooth out short period changes due to variations in the traffic loads experienced by any one subscriber account.
  • the count field 20 is used to track the evolving state of the database with respect to time, and thereby detect unexpected actions of the database such as a roll-back.
  • the present technique is not limited to such embodiments. Rather, any suitable field, combination of fields, or characteristic of the database which, under normal operation of the database, exhibits a known pattern of behaviour with respect to time, may be used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

On décrit un système et un procédé d'entretien pour systèmes de base de données en nuage. Une pluralité de champs de la base de données sont surveillés pour suivre une configuration de changements prédéterminée par rapport au temps. Le fait de s'écarter de la configuration de changement prédéterminée indique une action inattendue de la base de données telle que, par exemple, un retour en arrière de l'état de la base de données.
PCT/CA2014/050528 2014-06-09 2014-06-09 Système et procédé d'entretien pour systèmes de base de données en nuage WO2015188247A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CA2014/050528 WO2015188247A1 (fr) 2014-06-09 2014-06-09 Système et procédé d'entretien pour systèmes de base de données en nuage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CA2014/050528 WO2015188247A1 (fr) 2014-06-09 2014-06-09 Système et procédé d'entretien pour systèmes de base de données en nuage

Publications (1)

Publication Number Publication Date
WO2015188247A1 true WO2015188247A1 (fr) 2015-12-17

Family

ID=54832641

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2014/050528 WO2015188247A1 (fr) 2014-06-09 2014-06-09 Système et procédé d'entretien pour systèmes de base de données en nuage

Country Status (1)

Country Link
WO (1) WO2015188247A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013072232A1 (fr) * 2011-11-15 2013-05-23 Telefonica, S.A. Procédé pour gérer des performances dans des applications multi-étages
US8504876B2 (en) * 2010-04-30 2013-08-06 The Mitre Corporation Anomaly detection for database systems
US20130333033A1 (en) * 2012-06-06 2013-12-12 Empire Technology Development Llc Software protection mechanism
US20140143868A1 (en) * 2012-11-19 2014-05-22 Hewlett-Packard Development Company, L.P. Monitoring for anomalies in a computing environment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8504876B2 (en) * 2010-04-30 2013-08-06 The Mitre Corporation Anomaly detection for database systems
WO2013072232A1 (fr) * 2011-11-15 2013-05-23 Telefonica, S.A. Procédé pour gérer des performances dans des applications multi-étages
US20130333033A1 (en) * 2012-06-06 2013-12-12 Empire Technology Development Llc Software protection mechanism
US20140143868A1 (en) * 2012-11-19 2014-05-22 Hewlett-Packard Development Company, L.P. Monitoring for anomalies in a computing environment

Similar Documents

Publication Publication Date Title
US11477032B2 (en) System and method for decentralized-identifier creation
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
US11533164B2 (en) System and method for blockchain-based cross-entity authentication
EP3593482B1 (fr) Système de nom de domaine décentralisé sécurisé
AU2001238056B2 (en) System and method for installing an auditable secure network
US6918038B1 (en) System and method for installing an auditable secure network
CN102077506B (zh) 用于对等存储系统的安全结构
CN110569675A (zh) 一种基于区块链技术的多Agent交易信息保护方法
CN111444273B (zh) 一种基于区块链的数据授权方法以及装置
US11496327B1 (en) Secure and trustworthy bridge for transferring assets across different networks
WO2019170814A1 (fr) Système et procédé de transaction de données
US20150358296A1 (en) Cloud-based secure information storage and transfer system
CN110851837A (zh) 一种基于可信计算的自助设备、其安全管理系统及方法
US11797392B2 (en) Backup and recovery of private information on edge devices onto surrogate edge devices
US20150356295A1 (en) Keep-alive system and method for cloud-based database systems
WO2015188247A1 (fr) Système et procédé d'entretien pour systèmes de base de données en nuage
AU776222B2 (en) System and method for installing an auditable secure network
WO2015188246A1 (fr) Système infonuagique sécurisé de transfert et de mise en mémoire d'informations
CN111626735B (zh) 一种数据交互系统、方法和模块

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14894460

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14894460

Country of ref document: EP

Kind code of ref document: A1