Patent Application
20240231997
The present disclosure relates to systems and methods to integrate software systems dedicated to the operations, management, administration, and/or financial management of healthcare practices as well as software systems dedicated to the management of electronic health records or electronic medical records.
Tenant: A tenant is a group of users who share a common access with specific privileges to a software system and its component, including data, configurations, infrastructure resources, etc. A tenant generally maps to an entity such as a company or a public sector organization engaging in business with a provider of said software system to use said software system. In this disclosure example tenants may include private or public medical practice, medical facilities, etc.
Data source: Any first, second or third-party software system dedicated to either (i) the operations, management, administration, and/or financial management of healthcare practices, (ii) the management of patient health insurance and processing health insurance claims or (iii) the management of electronic health records or electronic medical records.
Data extractor: A system configured to extract data enclosed within one or more data sources to one or more destination, or mutate data enclosed within said one or more data sources.
Mutation, mutating: Mutation refers to the C, U, D in CRUD—Create, Update, Delete (data).
Infrastructure resource: An infrastructure resource refers to a computer infrastructure resource, such as a data storage, servers, databases, networking, software service, content delivery networks, etc., wherein said resource may be hosted on virtualized or physical machines. It is a generalization of the concept of “cloud resource”, to include computer infrastructure resources on the edge.
Subject infrastructure: Following the definition of subject and object in English grammar, where a subject is the entity performing an action, and the object is having the action performed upon/on/using it, subject infrastructure defines a computer system infrastructure composed of various embodiments of infrastructure resources, said subject infrastructure performing action on an object (in this disclosure at least one object infrastructure). Said subject infrastructure can be in the cloud or on the edge.
Object infrastructure: Following the definition of subject and object in English grammar, where a subject is the entity performing an action, and the object is having the action performed upon/on/using it, object infrastructure defines a computer system infrastructure composed of various embodiments of infrastructure resources, said object infrastructure having an action performed on it by a subject infrastructure. Said object infrastructure can be in the cloud or on the edge.
Isolation (logical, physical): Physical isolation is defined as the physical isolation of a component (device, data, etc.) via lack of connectivity to a network. Logical isolation is defined as presence of isolation via a protocol, device or some sort of software protection.
Long-lived connection: A long-lived connection is a connection that is kept open for much longer than required for a single transaction or operation. A long-lived connection can be kept for minutes, hours, days or longer, as necessary.
Full-duplex connection: A full-duplex connection is a connection that enables both parties engaging in the connection to send message to the other party, whether simultaneously or non-simultaneously.
Real-time: A real-time operation is an operation that is required to be performed within a specified deadline. Deadlines may vary from system to system. In this disclosure, real-time implies a deadline of less than 5 seconds.
Near real-time: A near real-time operation is an operation that are required to be performed within time constraints defined as an interval. Said range is generally more permissive than real-time deadlines. In this disclosure, near real-time implies a time constraint interval of between 5 seconds and 30 minutes.
Storage: In this disclosure, storage refers to persistent or volatile storage, examples of such storage being file system, object storage systems (such as Google Cloud Storage, Amazon Web Services S3, Azure Cloud Storage, etc.), key-value databases, wide-column databases, document databases, relational databases, etc.
Storage object: Generalization of a storage primitive; named after the unit of storage of object storage systems such as Google Cloud Storage, Amazon Web Services S3, and Azure Cloud Storage, but refers to any such storage primitive that can store data—file, table row, document, key+value entry, etc.
Executable asset: An executable asset is any file or object that can be executed by the operating system on which it resides. Examples of executable assets include executable binaries (e.g. .exe files), executable scripts (e.g. .sh, .batch files), etc.
Healthcare practices usually use one or many workflow software to manage their operations, whether medical, financial, administrative, human, inventory, insurance, analytical or otherwise, as well as to manage the electronic records of their patients. As defined herein, a practice is a business through which one or more physicians practice medicine.
Said workflow software are typically associated with a data store or data registry, together named “data source” in this disclosure. Said data sources generally include a wealth of information that can be extracted and processed to offer a variety of valuable services to the medical and non-medical staff of the practice. Moreover, there is high commercial value in being able to mutate information enclosed in said data sources to provide complementary services to patients or users of said workflow software.
The extraction or mutation of the information enclosed in the data sources associated with said workflow software in a reliable, resilient and secure fashion at scale is a complex task. Significant engineering research and development is required for a party that is external to the practices to be able to integrate these data sources across a large number of practices.
This significant engineering research and development is due to four major sources of engineering complexity.
The first major source of engineering complexity is the heterogeneity of the infrastructure on which said workflow software are operated. Indeed, most healthcare practices operate their workflow software on their own computer system hardware, located on the physical premises of their practice. This in turn increases the complexity of the integration by an external party whose infrastructure is external to that of the practice, as they do not have control or reliable physical or virtual access to the computer infrastructure of the practice. Often these on-premise infrastructures are operated by different IT firms from practice to practice and standardization of the software or hardware environment is not feasible. The high variability of these infrastructure configurations and security measures creates a wide range of combinations which can result in failure of the external party to offer a reliable, resilient and secure offering.
The second major source of engineering complexity comes from the heterogeneity of the workflow software across the healthcare practices. Indeed, in order to reach as wide of a market as possible, an external party must integrate a variety of competing and/or complementary workflow software. The data sources of said workflow software may use technologies with interfaces, protocols or drivers that are incompatible with each other. Said data sources range from outdated legacy systems that are no longer supported by its manufacturer to state-of-the-art systems. Furthermore, some data sources may only support a subset of the functionalities required for the extraction or mutation of the information enclosed within, or the parties managing said workflow software may only grant limited permissions or accessibility to said data sources.
The third significant source of engineering complexity is security compliance and tenancy isolation. Indeed, due to the sensitive nature of the data extracted, an external party must provide strong guarantees of security and isolation of the data. In the case of healthcare data, this is even more important as protected health information (PHI) may be part of the data extracted. As such, an ideal extraction or mutation system must observe high levels of compliance to regulatory norms or laws such as The Health Insurance Portability and Accountability Act of 1996 (HIPAA), effective in the United States, and The Personal Information Protection and Electronic Documents Act (PIPEDA), effective in Canada.
The fourth significant source of engineering complexity comes from the necessity of designing a system to facilitate the deployment of new functionalities, updates and corrections in an autonomous way with confidence, without the need for a representative of the external party to interact with the external infrastructure or any software installed therein.
Known prior art discloses tools and methods that partially responds to the needs above, but our research has not been able to demonstrate the existence of prior art that responds to all the criteria elicited above.
Our research compiled prior art in five major classes of software systems which come closest to the use-case and requirements elicited above:
Visual Analytic Platforms are platforms dedicated to providing powerful data visualization tools against various data sources.
VAPs tackle the workflow software heterogeneity issue by offering out of the box integrations with various data sources as part of their offering. While most of them offer a generous number of integrations, they are not guaranteed to have support for all workflow systems, especially legacy ones.
Moreover, VAPs present shortcomings that make them unfit for the use case of this disclosure:
Due to these shortcomings, we have evaluated VAPs not to support the use-case of this disclosure.
Internet of Things (IoT) Platform offerings support the integration of a wide, heterogeneous set of hardware and software infrastructure as their core value propositions.
This being said, IoT Platform offerings also assume that you have control over the hardware on which it is installed and that if your device fails, you have a way to have access to the device and repair it yourself or swap it with another.
IoT Platform researched, such as Microsoft Azure IoT, Google Cloud Platform Cloud IoT Core, and AWS IoT SDK xAWS Greengrass all make such an assumption, and thus come either as embeddable software development toolkit to be embedded in your own deployed code, or as managed solutions that manage the whole code lifecycle for the device. Neither of these solutions are adequate for the reality expressed above as neither tackle the reliability nor resiliency demands expressed above and assume access to the device is possible. Moreover, these platforms are generally not meant for expanding sets of features but instead are meant to establish a control-command pattern and a lightweight communication channel for devices with low-bandwidth requirements.
Database replication tools are interesting solutions in that they address the first and second requirements quite well; they are generally built with reliability in mind since they serve the purpose of replicating or mirroring a database in near-real time to real time. Most are also designed to be installable on a variety of computer systems, which partially answers the problem of infrastructure heterogeneity.
This being said, database replication tools present shortcomings that make them unfit for the use case of this disclosure:
Due to these shortcomings, we have evaluated Database replication tools not to support the use-case of this disclosure.
The value proposition of Data Integration tools is simple: Integrate data sources seamlessly into destinations using managed pipelines. While this is an amazing value proposition, all the candidates we have researched focus mostly on integrating well known end-user, web-facing products, such as HubSpot, Google Sheets, GitHub, Google Analytics, etc. Our research also found support for many SQL and No-SQL databases, but all of these databases have to be hosted in a managed fashion on a known cloud provider platform. Examples of such databases are Amazon Aurora, Amazon RDS, GCP Cloud SQL, etc.
As such, none of the solutions found in this class seem to answer our primary need, which is to integrate disparate data sources dispersed across a wide range of (often self-hosted) heterogeneous infrastructure in a reliable fashion.
Healthcare Interface Engines (HIE) solves the problem of sharing and exchanging data between healthcare systems by providing on-premise extraction-load-transform (ELT) tools that ingest data structured in the proprietary data schema of the workflow system data source, and output a standard-compliant data schema.
Healthcare Interface Engines are effectively on-premise mini ELT/ETL tools that expose APIs on the local network or the public internet to be interfaced with.
HIE interface with a wide range of data sources, and are designed to be secure, resilient and reliable on any infrastructure they support. From what our research has gathered, the results seem to show that the HIE may also be capable of self-diagnosis and diagnosis of their environment.
The HIE solutions, however, have the following drawbacks:
Based on (a), (b) and (c), we have evaluated that HIE are not adequate to answer particular use-cases.
There is therefore a need in the industry for covering the requirements expressed above.
According to the present invention, there is provided method for improving reliability and resiliency of a computer-based software system installed on an object infrastructure managed by an external party, the method comprising:
In embodiments, the method further comprises:
In embodiments, the method comprises:
According to the present invention, there is also provided a method for securely extracting or mutating data associated to a tenant in at least one data source located in an object infrastructure, from a subject infrastructure, the method comprising:
In embodiments, the method further comprises a recurrent and automatic rotation of said authentication credential, said rotation comprising:
According to the present invention, there is also provided a computer-based software system for extracting or mutating data in at least one data source associated to at least one tenant, said at least one data source being located on an object infrastructure, the system comprising:
In embodiments, the system with the main module of the at least one data extractor further comprises:
In embodiments, the system with the watchdog module of the at least one data extractor further comprises:
In embodiments, the system with the plurality of child modules of the main module of the data extractor further comprises:
In embodiments, the system with the plurality of child modules of the watchdog module of the data extractor further comprises:
According to the present invention, there is also provided a computer-based software system for extracting or mutating data in at least one data source associated to at least one tenant, said at least one data source being located on an object infrastructure, the system comprising:
Other objects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of specific embodiments thereof, given by way of example only with reference to the accompanying drawings.
The present invention is illustrated in further details by the following non-limiting examples.
Referring to
Subject infrastructure 12000 may be a private or closed system or may be set up by an entity such as a company or a public sector organization to provide one or more service to a company, a public sector organization, or an embodiment of a legal person. In order to perform said service, the entity providing the service relying on the subject infrastructure 12000, or “integrator entity” may need to integrate data located within the one or more data source 11002 located on one or more object infrastructure 11000. Said integration of data may include extraction of data to the subject infrastructure 12000 or mutation of data within said data source 11003. In some embodiments, the one or more object infrastructure 11000 may belong to different legal entities or be in different private networks or closed systems.
In some embodiments, extraction or mutation of data in the one or more data source 11002 from outside the private or closed system of the one or more object infrastructure may be difficult or impossible due to network or infrastructure configuration. In such embodiments, an installation of a data extraction or mutation agent, “data extractor” 11100 may allow to perform extraction and mutation of data where it would have been otherwise impossible to do. In many embodiments, installation of the data extractor 11100 within the private or closed network on a long-lived machine may be sufficient to gain access to the data source and export the data to the subject infrastructure. In other embodiments, the data extractor 11100 may have to be installed on the same machine as the data source 11002, for example if the data source does not provide an interface that can be accessed over network.
Following the installation of a data extractor 11100, the data extractor may be configured to establish a connection over a secure communication channel 12001 to the subject infrastructure 12000, according to some embodiments. By having the data extractor establish the connection from within the object infrastructure 11000 to the subject infrastructure 12000, the embodiment can circumvent the network limitations preventing incoming connections on the object infrastructure, whereby allowing communication with a remote host located within the subject infrastructure. An embodiment of such communication channel should support full-duplex, real-time or near-real-time messages to allow a human operator of the subject infrastructure or an embodiment of the subject infrastructure or a subsystem thereof to communicate promptly with the data extractor in case of time sensitive operations, such as zero-day vulnerability patching, mirroring changes in data to the data source, etc. Optimal characteristics of an embodiment of such a communication channel would be to support long-lived, full-duplex, real-time or near-real-time connections to allow for two-way communications without the need to resort to asynchronous polling by the data extractor. Example technologies matching these requirements include the WebSocket protocol, gRPC protocol, and HTTP polling.
The data extractor 11100 may be configured to upload data extracted from a data source 11102 to an embodiment of storage 12300 for collection and use by the subject infrastructure 12000.
In some embodiments, extraction or mutation of data in the one or more data source 11002 over a long period of time (weeks, months or years) by a data extractor 11100 installed in the object infrastructure 11000 may be difficult to achieve due to concerns over reliability and resiliency of the data extractor. In effect, given that between various embodiments of the object infrastructure 11000 there may be significant differences in configurations of said infrastructure embodiments, the data extractor should maintain full functionality through changes in configurations of said infrastructures such as operating system upgrades, patch application, changes in available computational resources (CPU, memory, disk), etc. The data extractor should also reestablish full functionality following object infrastructure service interruptions such as shutdown of a machine on which the data extractor is installed.
As such the data extractor may implement techniques to ensure its reliability and resiliency.
For example, the data extractor 11100 may be executed as an operating system service 11102 to maximize its uptime. Operating the data extractor as an operating system service may allow the data extractor process 11102 to be (i) started alongside critical operating system processes on startup of the machine on which it is installed, (ii) executed with administrative privileges (iii) started independently of user logon, and (iv) automatically restarted by the operating system in case of failure, all three capacities being beneficial to reliability and resiliency.
Reliability of said operating system service process may be improved by delegating any non-reliability-essential, non-resiliency-essential, or prone to change functionality to child processes. Delegating said functionalities to child processes allow to minimize the code surface of the executable code of the operating system service process and as such reduce chances of failures in the parent process 11102. Said functionalities can then be packaged as separate executable assets which may follow a different release cycle than the parent process 11102 and thus be updated independently from the parent process.
If the delegation of said non-reliability-essential, non-resiliency-essential, or prone to change functionality to child processes is not implemented, it results that the parent process must be stopped, updated and restarted whenever changes in functionality are required. Such an update procedure comes with increased risks of failure, and thereby reduce the reliability of the data extractor 11100. In some embodiments, this need to change functionality may not arise often; nevertheless, the risk of mass failure of data extractors across a plurality of object infrastructures 11000, each possibly managed by different companies, public sector organizations, or legal person is a risk that may cost significant efforts and money to address would it occur, and as such the present design in this disclosure seeks to minimize the probability of this occurring.
Essential operational functionality of the parent process 11102 may include heartbeat exchange with the subject infrastructure 12000, and logging of operations to the subject infrastructure, according to some embodiments.
Heartbeat exchange may be considered as essential functionality since it provides the subject infrastructure 12000 or any natural person with sufficient access to said subject infrastructure 12000 the information of loss of heartbeat (failure of the parent process) or of an unhealthy heartbeat (failure in an essential operational functionality or child-process-delegated functionality), whereby said information may be used by said subject infrastructure 12000 or natural person to take action and resolve the failure.
Logging of operations may be considered as essential functionality since it provides the subject infrastructure 12000 or any natural person with sufficient access to said subject infrastructure 12000 detailed information about the operations of the data extractor for troubleshooting, data governance or audit purposes.
Delegation of non-reliability-essential, non-resiliency-essential, or prone to change functionality to child modules may need the parent process to extend said essential operational functionality with (i) orchestrating of said child processes, (ii) logging of operations of said child processes to the subject infrastructure 12000, as well as (iii) configuring and updating of executable assets and configuration files used by said child processes.
In some embodiments, essential operational functionality of the parent process 11102 may be organized as a set of components, said components being subsets of the code executed by the parent process. As such, the parent module may include (i) a heartbeat component 11103 to carry out heartbeat exchange with the subject infrastructure 12000, (ii) a logging component to handle logging of the parent process and of the child processes to the subject infrastructure 11106, a configuration and update component 11104 to handle configuring and updating of executable assets 12212 and configuration files of the parent module 11110 and executable assets 12213 and configuration files of the child modules 11113.
Referring now to
According to some other embodiments, said executable assets 12210 may also be stored outside of the subject infrastructure 12000.
As part of its child modules, the main module 11101 must include at least one data source integration module 11108 to perform its primary functionalities: data extraction or mutation from at least one data source 11002.
According to some embodiments, the main module may have more than one data source integration module 11108 in embodiments where the one or more data sources 11002 to integrate by the data extractor 11100 use different methods of connectivity or different drivers for exposing an extraction or mutation API. Example of methods of connectivity or drivers include ODBC connections, JDBC connections, REST APIs, GraphQL APIs, etc. A data source integration module 11108 may be configured to integrate more than one data sources 11002 in embodiments where said more than one data sources 11002 use the same method of connectivity or driver for exposing their extraction or mutation API.
According to some other embodiments, a data source integration module 11108 may integrate one or more data sources 11002 with different methods of connectivity or different drivers. However, separating integration of different methods of connectivity or different drivers across a plurality of data source integration modules 11108 may improve decoupling and compartmentalization, resulting in smaller, more reliable data source integration modules (11108).
In some embodiments, in order to improve resiliency of the data extractor 11100, each child module of the main module may have their respective configuration file 11113, each separate from the respective configuration files of other child modules 11113 and of the parent module of the main module 11110. This fragmentation in multiple configuration files rather than a single configuration file may improve resiliency by minimizing the probability that one or more module corrupts the otherwise single configuration file that all of the modules rely upon.
Resiliency of the data extractor 11100 may be improved by installing a watchdog alongside the operating system service parent module 11102 and its child modules, “main module” 11101, said watchdog being responsible for asserting the health of said main module, and (ii) attempting to repair said main module 11101 in case of failure. To maximize reliability of the watchdog, said watchdog may be installed as a process run by an operating system primitive, such as an operating system service or an operating system scheduled task.
Similarly to the operating system service, the reliability of watchdog process may be improved by delegating any non-reliability-essential, non-resiliency-essential, or prone to change functionality to child processes.
Essential operational functionality of the parent process of the watchdog 11121 may include heartbeat exchange with the subject infrastructure 12000, and logging of operations to the subject infrastructure, according to some embodiments.
Delegation of non-reliability-essential, non-resiliency-essential, or prone to change functionality to child modules may need the parent process of the watchdog 11121 to extend said essential operational functionality with (i) orchestrating of said child processes, (ii) logging of operations of said child processes to the subject infrastructure 12000, as well as (iii) configuring and updating of executable assets and configuration files used by said child processes.
In some embodiments, essential operational functionality of the parent process of the watchdog 11122 may be organized as a set of components, said components being subsets of the code executed by the parent process of the watchdog. As such, the parent module may include (i) a heartbeat component 11123, (ii) a logging component 11124, a configuration and update component 11125 to handle configuring and updating of executable assets 12212 and configuration files of the parent module 11129 and executable assets 12214 and configuration files of the child modules 11131.
As part of its child modules, the watchdog must include a main module health monitoring and recovery child module 11127 responsible for its primary functions: (i) performing a series of health check asserting the health of the main module 11101, and (ii) attempting recovery of detected failures in the main module 11101.
An embodiment of said main module 11101 health checks by the watchdog 11121 may include the following checks:
As part of its child modules, the watchdog module 11121 may include an environment information child module 11128 responsible for collecting information about the execution environment 11003, such as network conditions, CPU, memory or disk utilization, presence of known threats to the resiliency or reliability of the main module 11101 or watchdog module 11121, such as specific programs or procedures, etc.
In some embodiments, the watchdog module 11121 may report the result of its health checks on the main module 11101, the result of its attempts at recovery of failures in the main module 11101, or the information collected by its environment information child module 11128 to the subject infrastructure 12000.
As part of its child modules, the watchdog may include any number of additional child modules as deemed necessary for carrying out its functionalities or extending said functionalities with additional functionalities, according to some embodiments.
In some embodiments, in order to improve resiliency of the watchdog module 11121, each child module of the watchdog module may have their respective configuration file 11132, each separate from the respective configuration files of other child modules 11132 and of the parent module of the watchdog module 11129. This fragmentation in multiple configuration files rather than a single configuration file may improve resiliency by minimizing the probability that one or more module corrupts the otherwise single configuration file that all of the modules rely upon.
In order to improve the reliability and resiliency of the watchdog 11121, the main module 11101 may include a child module dedicated to (i) recurrently performing a series of health check asserting the health of the watchdog module 11121, and (ii) attempting recovery of detected failures in the watchdog module 11121.
An embodiment of said watchdog module 11121 health checks by the main module 11101 may include the following checks:
As part of its child modules, the main module 11101 may include an environment information child module 11109 responsible for collecting information about the execution environment 11003, such as network conditions, CPU, memory or disk utilization, presence of known threats to the resiliency or reliability of the main module 11101 or watchdog module 11121, such as specific programs or procedures, etc.
The presence of an environment information child module in both the watchdog module 11121 and the main module 11101 may allow both modules to act independently in their health monitoring, health checks, and failure recovery of the other module.
In some embodiments, the main module 11101 may report the result of its health checks on the watchdog module 11121 health, the result of its attempts at recovery of failures in the watchdog module 11121, or the information collected by its environment information child module 11109 to the subject infrastructure 12000.
Those skilled in the art will appreciate that the directory structure illustrated in the representation of the tenant isolated storage 12300 in
In order to access the subject infrastructure 12000 and its infrastructure resources securely, each data extractor 11100 may authenticate itself against the subject infrastructure using an identity and access management (IAM) authentication credential 12104. In some embodiments, said authentication credential may enable the data extractor 11100 to assume the identity of an IAM user 12112 specifically associated to said data extractor. By assuming the identity of the IAM user 12112, the data extractor 11100 may gain access related to the IAM access privileges 12102 associated to one of the at least one IAM Roles 12101 associated with said IAM user 12112. Said IAM primitives 12110, 12112, 12101, 12102, 12103 may be “managed” (created, mutated, or removed) by the IAM module 12100.
In some embodiments, said IAM user 1211 associated to said data extractor may also be associated to a tenant 11001, thereby allowing the subject infrastructure 12000 to limit the access and usage of its infrastructure resources only to those provisioned for said tenant 11001.
In some embodiments of alternative structures to the invention disclosed, access to the subject infrastructure 12000 and its infrastructure resources may be shared across a plurality of data extractors 11100 irrespectively of which tenant 11001 is integrated by each of said plurality of data extractors 11100. In such an alternative structure, tenancy determination may be done after data is ingested by the subject infrastructure 12000.
These alternative structures may come with major security shortcomings however—in case of leak of the authentication credential 12104 of one of the plurality of data extractor sharing access to the subject infrastructure 12000, the entirety of shared infrastructure resources may be compromised, and in some embodiments of said alternative structures, may come with major data leaks if access privileges provided to data extractors are too expansive.
In order to mitigate such risk, the structure described in this disclosure ensures that each data extractor has its own set of authentication credential 12104, is only associated to one tenant 11001, and has only access to the infrastructure resources associated with said tenant or to infrastructure resources that can be shared safely without risking compromising tenant data security. Moreover, the structure described in this disclosure may be further hardened by implementing low-level access control lists wherever applicable. For example, the data extractor may have access to a tenant isolated storage 12200, but have only read access to certain objects stored within the storage, or only write access to certain other objects in said storage. Optimally, an embodiment should prioritize a structure of infrastructure resources, objects and more granular elements facilitating the minimization of minimum required access privileges for the data extractor to carry out its functions, within reason. For example, data extractors may only have read access to the configuration objects 12320 in storage, write access to data and log objects, and be denied all other operations against their associated tenant logically isolated storage 12300, including the overwriting of data or log objects where applicable.
According to some embodiments, the concept of “tenant data extraction IAM primitives” 12105 include IAM primitives associated to a tenant 11001 and a data extractor 11100, said primitives including an IAM User 12112, at least one IAM Role 12101, at least one IAM Access Privilege 12102, and at least one IAM Authentication Credential 12103, downloaded to the object infrastructure 11000 as an object 12104 such as a file, registry key or other form of storage on the object infrastructure 11000.
In order to further reduce the size of a security breach in the event of an authentication credential 12104 leak, an embodiment may opt to rotate said authentication credential 12104 frequently. For example, an embodiment may opt to rotate credentials every hour, few hours or every day. Such a measure may reduce the size of the breach by shortening the time window during which the attacker has access to a valid authentication credential 12104.
As such, in some embodiments, the subject infrastructure 12000 may have an automated rotation system designed in such a way such as to invalidate existing valid authentication credentials 12104 and provide data extractors 11100 with a new, valid authentication credential instead.
The sequence described in
An embodiment implementing the above sequence ensures that only an entity with a valid authentication credential 12104 can gain access to a new authentication credential 12104. An embodiment of the above sequence may further ensure the security of the operation by halting the rotation sequence if the authentication credential 12104 bearer does not respond adequately or within a reasonable time frame and may flag the authentication credential 12104 as compromised and trigger an alert for a human person to take appropriate action.
The sequence of steps presented in
Furthermore, the sequence of steps presented in
The sequence of steps presented in
While it may not provide additional significant benefits, given the high level of security of the sequence of steps presented in
An embodiment of the system disclosed herein may additionally implement data governance, auditing, and anomaly detection mechanisms using one or more of the logs described by the invention, including the logs of operations of the data extractor 12310, the event log of the IAM module 12106, and the log produced by the authentication credential activity logging module 12003. In some embodiments, elements of the subject infrastructure 12000 discussed in this disclosure may also produce logs of their own that may be relevant to some of said additional mechanisms.
Those skilled in the art will appreciate that the system described herein is merely illustrative and is not intended to limit the scope of the techniques as described herein.
Various modifications and changes may be made as would be obvious to a person skilled in the art having the benefit of this disclosure. It is intended that the invention embrace all such modifications and changes and, accordingly, the above description to be regarded in an illustrative rather than a restrictive sense.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CA2022/050066 | 1/18/2021 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63199686 | Jan 2021 | US |
