Technique for controlling execution of query

Abstract

According to one embodiment of the present disclosure, a method for controlling the execution of a query with a record-commit as a precondition, performed by a computing device, is disclosed. The above method comprises: receiving a query from a client; calculating a decision result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log containing the decision result; transmitting a storage request to record the audit log containing the decision result in non-volatile storage, regardless of the value of the decision result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; receiving a commit acknowledgment in response to the storage request, indicating that a commit package containing at least the fingerprint value and the audit log has been recorded in non-volatile storage; verifying the validity of the commit acknowledgment by comparing a verification value reconstructed from the commit acknowledgment with the fingerprint value included in the commit acknowledgment; and, in response to the case where the verification of the validity of the commit acknowledgment is successful and the decision result is allowed, allowing the execution gate to move from a closed state that blocks the execution of the query to a closed state that allows the execution of the query. It may include a step of transitioning to an open state.

Description

Technology Field

[0001] The present disclosure relates to a query processing technique, and more specifically, to a technique for controlling the execution of a query with a record commit as a precondition. Background Technology

[0002] In general computing environments and Database Management Systems (DBMS), when a query or data access request is received from a client, the computing system parses the request to establish an execution plan and executes the query according to the plan. To ensure security compliance, system monitoring, and traceability, these computing systems include a logging mechanism that generates and records user query request and execution history in the form of audit logs in a repository.

[0003] In these conventional systems, the query execution process and the audit log recording process are typically handled as separate workflows or performed asynchronously. For example, a computing system makes a logical judgment on a client's query request, immediately executes the query to provide a response to the client, and then flushes the audit log to disk or external storage via a background process in parallel or after the query execution is completed. The recorded audit logs are subsequently utilized by system administrators or auditors as reference data for forensic analysis of security incidents, diagnosis of system errors, or verification of regulatory compliance.

[0004] Korean Patent Registration No. 10-1619482 presents a technology for securely loading audit logs into a database. The problem to be solved

[0005] The present disclosure aims to fundamentally block any unauthorized system operations or data access that are not recorded by ensuring that an audit log containing the judgment result of a query execution is recorded in a non-volatile storage prior to the execution of a client's query.

[0006] The purpose of this disclosure is not limited to the description above and will be understood to encompass the objectives achieved according to the specific descriptions below. means of solving the problem

[0007] According to one embodiment of the present disclosure, a method for controlling the execution of a query with a record-commit as a precondition, performed by a computing device, is disclosed. The above method comprises: receiving a query from a client; calculating a decision result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log containing the decision result; transmitting a storage request to record the audit log containing the decision result in non-volatile storage, regardless of the value of the decision result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; receiving a commit acknowledgment in response to the storage request, indicating that a commit package containing at least the fingerprint value and the audit log has been recorded in non-volatile storage; verifying the validity of the commit acknowledgment by comparing a verification value reconstructed from the commit acknowledgment with the fingerprint value included in the commit acknowledgment; and, in response to the case where the verification of the validity of the commit acknowledgment is successful and the decision result is allowed, allowing the execution gate to move from a closed state that blocks the execution of the query to a closed state that allows the execution of the query. It may include a step of transitioning to an open state.

[0008] In one embodiment, the step of transitioning the execution gate may include the step of transitioning the execution gate from the closed state to the open state in response to a successful verification event of the validity of the commit response, such that the successful verification event and the transition operation of the execution gate are processed as atomic operations within a single atomic control window (ACW).

[0009] In one embodiment, the method may further include the step of maintaining the execution gate in the closed state to block or suspend the execution of the query in response to a failure event of validating the commit response.

[0010] In one embodiment, the method may further include the step of transitioning the execution gate from the open state to the closed state in response to an execution end event of the query after the execution gate has transitioned to the open state, such that the execution end event and the transition operation of the execution gate are processed as atomic operations within a single atomic control window.

[0011] In one embodiment, the commit package can be generated by binding the audit log and the fingerprint value.

[0012] In one embodiment, the fingerprint value may be generated by applying the cryptographic transformation to the audit log, a record identifier identifying the audit log, and a record time of the audit log.

[0013] In one embodiment, the commit package is generated in response to a save request to write the audit log to the non-volatile storage or a confirmation request to verify whether the commit package containing the audit log has been permanently written to the non-volatile storage, and the commit package may be generated by combining the determination result in the audit log, a record identifier identifying the audit log, the recording time of the audit log, a restoration rule for restoring the determination result in the audit log, and the fingerprint value.

[0014] In one embodiment, after a preset commit validity period has elapsed from the time of the request to save the audit log, the commit response may not be received or the commit response may be determined to be invalid.

[0015] In one embodiment, the step of generating the audit log may include: generating a judgment basis including a judgment result including allow, deny, and hold for the execution of the query based on at least one of the query and the execution plan and the policy data, and an evidence reference used to generate the judgment result; and configuring a structured control schema including the judgment result and the judgment basis; and generating the audit log for which storage to be requested in the non-volatile storage by concatenating a plurality of field values ​​extracted from the structured control schema.

[0016] In one embodiment, the method comprises: (a) transmitting a save request to save a commit package including at least the judgment result and the fingerprint value in a non-volatile storage, regardless of whether the judgment result includes one of allow, reject, or pending; (b) committing the save by receiving a commit response in response to the save request; and (c) verifying the validity of the commit response by comparing the fingerprint value included in the commit response with a fingerprint value reconstructed based on the commit package, wherein (i) when the judgment result includes allow and a successful event of verification of the validity of the commit response occurs, it is determined to transition the execution gate to an open state and allow the execution of the query; (ii) when the judgment result includes reject, it is determined to keep the execution gate in a closed state and reject the execution of the query, regardless of whether a successful event of verification of the validity of the commit response occurs; and (iii) when the judgment result includes pending, it is determined to keep the execution gate in a closed state and reject the execution of the query, regardless of whether a successful event of verification of the validity of the commit response occurs. It is suspended, and the determination for the above query may be re-executed in response to the reception of an additional approval event or an external trigger signal thereafter.

[0017] In one embodiment, the structured control schema may include a policy identifier that identifies policy data used to generate the basis for judgment; and a policy snapshot identifier that indicates a specific version of the policy data.

[0018] In one embodiment, the method may further include the step of verifying the consistency of the determination result included in the audit log based on the policy identifier and the policy snapshot identifier.

[0019] In one embodiment, the step of verifying consistency may include: a step of restoring the policy snapshot identifier and the policy data corresponding to the policy identifier; and a step of re-performing the determination for the query using the restored policy data.

[0020] In one embodiment, the step of verifying the validity of the commit response may include: extracting from the commit response the record metadata generated according to the storage of the audit log and the fingerprint value, and obtaining the generated audit log from the local storage of the computing device; combining the obtained audit log and the extracted record metadata and applying the cryptographic transformation to the combined result to generate the reconstructed verification value; and comparing the reconstructed verification value with the extracted fingerprint value.

[0021] In one embodiment, the step of verifying the validity of the commit response may further include at least one of: comparing the time difference between the time of receiving the query or the time of transmitting a save request for writing the audit log to the non-volatile storage and the time of writing the record metadata with a preset validity time window; and determining whether the commit response includes integrity information or authentication information based on cryptographic transformation.

[0022] In one embodiment, the fingerprint value is generated by applying the cryptographic transformation to the audit log and a preceding fingerprint value corresponding to a preceding audit log that was generated prior to the audit log and whose validity has been verified, and the step of verifying the validity of the commit response includes: extracting the fingerprint value from the commit response and obtaining the preceding fingerprint value included in the preceding commit response corresponding to the preceding audit log and the generated audit log from the local storage of the computing device; combining the obtained preceding fingerprint value and the obtained audit log and applying the cryptographic transformation to the combined result to generate the reconstructed verification value; and comparing the reconstructed verification value with the extracted fingerprint value, and if the preceding audit log does not exist, a predefined initial value may be used.

[0023] In one embodiment, the step of transferring the execution gate can block duplicate transfers of the execution gate according to the same commit response by performing a process to prevent the reuse of the commit response or the fingerprint value used in the step of verifying the validity of the commit response.

[0024] In one embodiment, the execution gate functions as an external execution boundary, which is a boundary through which a control signal for the execution of the query is transmitted to an external entity physically or logically separated from the computing device; the open state is a state in which the control signal passes through the external execution boundary and can reach the external entity, and the closed state may be a state in which the control signal is blocked at the external execution boundary. The method may further include: detecting a gate state change event comprising at least one of a time when the execution gate transitions to the open state and a time when it transitions to the closed state; and generating a subsequent audit log comprising information corresponding to the audit log or the commit package and the gate state change event, and transmitting the subsequent audit log to the non-volatile storage.

[0025] In one embodiment, the step of generating the audit log may include: a step of obtaining an execution plan for processing the query in response to the receipt of the query; and a step of generating the audit log including a determination result related to the execution of the execution plan based on policy data collected based on the execution plan. And the step of obtaining the execution plan may include: a step of parsing the received query to identify a target object accessed or modified by the query and an operation type for the target object; and a step of generating an execution context in which the target object and the operation type are sorted or formatted according to predefined rules - the policy data is collected based on the execution context -.

[0026] In one embodiment, the policy data can be updated without changing or restarting the execution code of the computing device, and the updated policy data can be applied to a query received after the update.

[0027] In one embodiment, a computer program stored on a computer-readable storage medium is disclosed. The computer program, when executed by a computing device, causes the computing device to perform a method for controlling the execution of a query with a write commit as a precondition, wherein the method comprises: receiving a query from a client; calculating a decision result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log including the decision result; transmitting a storage request to cause the audit log including the decision result to be written to a non-volatile storage, regardless of the value of the decision result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; and receiving a commit acknowledgment in response to the storage request, indicating that a commit package including at least the fingerprint value and the audit log has been written to a non-volatile storage. The method may include a step of verifying the validity of the commit response by comparing a verification value reconstructed from the commit response with the fingerprint value included in the commit response; and a step of transitioning the execution gate from a closed state that blocks the execution of the query to an open state that allows the execution of the query in response to the case where the validity verification of the commit response is successful and the judgment result is allowed.

[0028] In one embodiment, a computing device comprising at least one processor for controlling the execution of a query with a record commit as a precondition is disclosed. The at least one processor comprises: receiving a query from a client; calculating a decision result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log including the decision result; transmitting a storage request to record the audit log including the decision result in a non-volatile storage, regardless of the value of the decision result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; receiving a commit acknowledgment in response to the storage request, indicating that a commit package including at least the fingerprint value and the audit log has been recorded in the non-volatile storage; and verifying the validity of the commit acknowledgment by comparing a verification value reconstructed from the commit acknowledgment with the fingerprint value included in the commit acknowledgment. And in response to the validation of the above commit response being successful and the above judgment result being allowed, a step of transitioning the execution gate from a closed state that blocks the execution of the above query to an open state that allows the execution of the above query can be performed. Effects of the invention

[0029] A technique according to one embodiment of the present disclosure allows the execution of a query on the condition that it is a durable record of an audit log (e.g., a non-volatile storage record), thereby structurally blocking security gaps for undocumented execution even if a failure of the computing system or a malicious attack occurs.

[0030] The effects of the present disclosure are not limited to the description above and will be understood to encompass technical effects achieved according to the specific descriptions below. Brief explanation of the drawing

[0031] FIG. 1 schematically illustrates a block diagram of a computing device according to one embodiment of the present disclosure. FIG. 2 illustrates an exemplary method for controlling the execution of a query according to one embodiment of the present disclosure. FIG. 3 illustrates data structures according to one embodiment of the present disclosure. FIG. 4 is a sequence diagram showing the flow of data to control the execution of a query according to one embodiment of the present disclosure. FIG. 5 illustrates an exemplary method for verifying the consistency of a judgment result according to one embodiment of the present disclosure. FIG. 6 illustrates an exemplary methodology for processing a gate state change event according to one embodiment of the present disclosure. FIG. 7 illustrates an exemplary method for verifying the validity of a commit response and controlling an execution gate according to one embodiment of the present disclosure. FIG. 8 is a brief and general schematic diagram of an exemplary computing environment of a computing device (100) in which some embodiments of the present disclosure may be implemented. Specific details for implementing the invention

[0032] Various embodiments are now described with reference to the drawings. In this specification, various descriptions are provided to provide an understanding of the present disclosure. However, it is evident that these embodiments can be practiced without such specific descriptions.

[0033] In this specification, a component refers to a computer-related entity, hardware, firmware, software, a combination of software and hardware, or an execution of software. For example, a component may be, but is not limited to, a procedure executed on a processor, a processor, an object, an execution thread, a program, and / or a computer. A component may reside within a processor and / or an execution thread. A component may be localized within a single computer. A component may be distributed among two or more computers. Additionally, these components may be executed from various computer-readable media having various data structures stored therein. Components may communicate through local and / or remote processes, for example, according to signals having one or more data packets (e.g., data from one component interacting with another component in a local system or distributed system, and / or data transmitted through signals to other systems and networks such as the Internet).

[0034] Furthermore, the term "or" is intended to mean an implicit "or" rather than an exclusive "or." That is, unless otherwise specified or evident from the context, "X uses A or B" is intended to mean one of the natural implicit substitutions. In other words, if X uses A; if X uses B; or if X uses both A and B, "X uses A or B" may apply to any of these cases. Additionally, the terms "or" and "and / or" as used herein should be understood to refer to and include all possible combinations of one or more of the enumerated related items.

[0035] Additionally, the terms “comprising” and / or “comprising” should be understood to mean that such features and / or components are present. However, the terms “comprising” and / or “comprising” should be understood not to exclude the presence or addition of one or more other features, components and / or groups thereof. Furthermore, unless otherwise specified or clearly evident from the context to indicate a singular form, the singular in this specification and claims should generally be interpreted to mean “one or more.”

[0036] And, the term "at least one of A or B" should be interpreted to mean "a case including only A," "a case including only B," or "a combination of A and B."

[0037] Terms expressed as N, such as the first, second, or third in the present disclosure, are used to distinguish at least one entity. For example, the entities expressed as the first and second may be identical or different from each other.

[0038] The expression in the present disclosure that a record commit is a prerequisite may mean that an audit log for a query must be recorded (e.g., persistently recorded) prior to executing a specific external action based on the query. The expression that a record commit is a prerequisite may mean that an acknowledgment certifying that an audit log for a query has been persistently stored must be received prior to executing a specific external action based on the query.

[0039] FIG. 1 schematically illustrates a block diagram of a computing device according to one embodiment of the present disclosure.

[0040] The computing device (100) may include a processor (110), memory (130), and a network unit (150).

[0041] The configuration of the computing device (100) illustrated in FIG. 1 is merely a simplified example. In one embodiment of the present disclosure, the computing device (100) may include other configurations for performing the computing environment of the computing device (100), and only some of the disclosed configurations may constitute the computing device (100).

[0042] A computing device (100) may represent a device for performing a method according to one embodiment of the present disclosure. The computing device (100) may be used in a sense that encompasses a server and a user terminal.

[0043] A server may include any type of computer system or computer device, such as, for example, a microprocessor, a mainframe computer, a digital processor, a portable device, a device controller, a web server, an application server, or a database server.

[0044] User terminals may include, for example, a personal computer (PC), notebook, mobile terminal, smartphone, tablet PC, etc. owned by the user.

[0045] The computing device (100) can be located at the external execution boundary and function as an execution gate.

[0046] An execution gate refers to a security control point that determines whether to pass a control signal before a client's query causes a physical or logical state change in an actual target object. The execution gate has either a closed state that blocks query execution or an open state that allows query execution. A computing device (100) according to the present disclosure can provide a technical effect of preventing unauthorized external access or distributed denial of service (DDoS) attacks by operating as a proxy layer that physically blocks direct data access by a client.

[0047] The external execution boundary may refer to a physical or logical traffic control dividing line between a separate external entity responsible for executing queries and the computing device (100). Depending on the implementation mode, the external execution boundary may exist inside the computing device (100) or outside the computing device (100). For example, the external execution boundary may function as a network interface separating the internal security zone of the system from the external intranet. For example, the external execution boundary may refer to an ingress / egress gateway of a service mesh that controls communication between microservices, or a physical layer of a SQL proxy located in front of a backend database. For example, the external execution boundary can be implemented in various ways, such as a virtual network interface (vNIC) of a reverse proxy device that routes client HTTP requests to a target API server, a localhost port occupied by an ambassador container within a Kubernetes Pod, or a digital output pin of a Programmable Logic Controller (PLC) that directly sends control signals to physical actuators, such as valves or motors, in an industrial control system (ICS).

[0048] The processor (110) of the computing device (100) can manipulate the external execution boundary by controlling the packet forwarding logic of the network unit (150). The processor (110) can maintain the execution gate in a closed state until the validity of the commit response is verified. In the closed state, the processor (110) can immediately drop the control signal for executing the query at the external execution boundary or block the passage of the control signal hardware-wise by processing null routing at the kernel level. On the other hand, when the validity verification is successful and the execution gate transitions to an open state, the processor (110) can update the routing table of the network unit (150) or temporarily modify firewall rules. In the open state, the processor (110) allows the control signal to safely pass through the external execution boundary and reach the receiving buffer of the external entity performing the actual processing.

[0049] This external execution boundary can provide a technical effect of fundamentally blocking excessive disk I / O bottlenecks caused by malicious queries that are unverified or have not been audited reaching external entities of the backend (e.g., mainframe storage engine). In addition, by controlling traffic at the front of the system solely through the computation of the computing device (100)'s own processor (110) and port control of the network unit (150), a hardware infrastructure optimization effect can be achieved, which minimizes the waste of network bandwidth in the internal network and drastically reduces the CPU computation load of backend computing devices (e.g., backend servers).

[0050] The processor (110) may be composed of one or more cores and may include a central processing unit (CPU), a general purpose graphics processing unit (GPGPU), a digital signal processor (DSP), a tensor processing unit (TPU), and a neural processing unit (NPU) of the computing device (100). The processor (110) may read a computer program stored in memory (130) and perform data processing according to embodiments of the present disclosure. That is, a computer program stored in a computer-readable storage medium (e.g., memory (130)) may cause one or more processors (e.g., processor (110)) to perform operations according to embodiments of the present disclosure. Additionally, the processor (110) may implement any component for performing data processing according to embodiments of the present disclosure. The component of the present disclosure may be used to refer to the computing device (100) and / or its components.

[0051] According to one embodiment of the present disclosure, the processor (110) may perform operations for training a neural network. For example, the processor (110) may perform operations for training a neural network, such as processing input data for training in deep learning (DL), extracting features from input data, calculating errors, and updating the weights of the neural network using backpropagation. At least one of the CPU, GPGPU, DSP, TPU, and NPU of the processor (110) may process the training of the network function. For example, the CPU and GPGPU may together process the training of the network function and data processing using the network function. In addition, in one embodiment of the present disclosure, processors of a plurality of computing devices may be used together to process the training of the network function and data processing using the network function.

[0052] The processor (110) can typically control the overall operation of the computing device (100). For example, the processor (110) can perform steps included in the flowcharts described below. The processor (110) can provide or process appropriate information or functions to the user by processing signals, data, information, etc. that are input or output through components included in the computing device (100) or by running an application stored in memory (130).

[0053] In one embodiment, the computing device (100) may include a System on Chip (SoC). For example, the computing device (100) may include a single chip in which the processor (110), memory (130), and network unit (150) shown in FIG. 1 are all mounted. In this case, the SoC may further include any modules for implementing the operation of the computing device (100), such as an I / O interface, a Power Management IC (PMIC), and a security module. Meanwhile, it will be obvious to a person skilled in the art that the SoC may be referred to as a processor. Therefore, in this embodiment, operations performed by the processor (110) in the present disclosure should be interpreted as being able to be performed on the SoC.

[0054] The processor (110) can parse a client query received through the network unit (150). A query refers to any form of command or request information for requesting the retrieval, creation, modification, or deletion of data, or for controlling the operation of a target object. As a non-limiting example, a query may include an SQL query, an HTTP REST API request, a Remote Procedure Call (RPC) call, or a GraphQL query. Based on the parsing result, the processor (110) can identify the target object and the type of operation of the query and convert them into a normalized form of an execution context and / or execution plan. Subsequently, the processor (110) applies policy data loaded in memory (130) to produce a decision result related to the execution of the query. The decision result includes, for example, a value of allow, deny, or pending. The processor (110) combines the calculated judgment result, judgment basis, policy snapshot identifier, etc. to form a structured control schema, and uses the field values ​​extracted therefrom to create an audit log in memory (130).

[0055] Additionally, the processor (110) generates a fingerprint value by applying a cryptographic transformation to the audit log. The cryptographic transformation may include, for example, a one-way hash function algorithm such as SHA-256 or SHA-3, a symmetric key-based authentication algorithm such as HMAC (Hash-based Message Authentication Code), and / or an RSA asymmetric key signature algorithm. The processor (110) may receive a commit package generated by combining the fingerprint value with the audit log through the network unit (150). As an additional example, the commit package may be generated by the processor (110). The processor (110) may verify the validity of a commit acknowledgment by comparing the fingerprint value included in the commit acknowledgment received from the non-volatile storage with a verification value directly reconstructed based on data stored in memory (130) (e.g., temporary storage data) bit by bit. In an additional embodiment, the processor (110) may further verify whether the validity time window has been exceeded and the continuity (chain connectivity) with the previous preceding fingerprint value. Only if the validity verification is successful, the processor (110) may transition the execution gate from a closed state to an open state within a single atomic control window (ACW) by utilizing an atomic instruction (e.g., Compare-And-Swap, Fetch-And-Add) or a mutex lock within the processor (110). Conversely, if the result of the judgment is a rejection or the verification fails, the processor (110) may keep the gate in a closed state.

[0056] Since the processor (110) allows the actual execution of a query (e.g., I / O interrupt or context switching) only after verifying whether data has been written, it produces a technical effect of preventing unnecessary computation cycle waste of the processor (110) caused by invalid transactions that are not authorized or written. In addition, by atomically combining cryptographic transformation and verification logic with gate transition operations, a performance improvement effect can be achieved that maximizes concurrency throughput in a multi-thread environment and prevents deadlocks.

[0057] In one embodiment of the present disclosure, the memory (130) may store any form of information generated or determined by the processor (110) and / or any form of information received by the network unit (150).

[0058] In one embodiment of the present disclosure, the memory (130) may include at least one type of storage medium among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory), RAM (Random Access Memory), SRAM (Static Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), PROM (Programmable Read-Only Memory), magnetic memory, a magnetic disk, and / or an optical disk. The computing device (100) may operate in conjunction with web storage that performs the storage function of the memory (130) on the internet. The memory (130) may include an embedded memory mounted inside the processor (110) and / or a memory mounted outside the processor (110) within the computing device (100). The description of the memory described above is merely an example, and the present disclosure is not limited thereto. The memory (130) may be operated by the processor (110).

[0059] Memory (130) is a hardware component that stores data and computer program instructions within a computing device (100). Memory (130) is a computer-readable medium capable of storing information temporarily or permanently. Memory (130) may include volatile memory that functions as a working space for the processor (110), or internal non-volatile memory that maintains local state. Memory (130) includes main memory such as SRAM and DRAM, L1 / L2 / L3 cache memory provided within the processor (110), registers, or a local SSD (Solid State Drive).

[0060] The memory (130) serves to temporarily buffer the execution plan, structured control schema, and generated audit log generated by the processor (110) parsing the query before transmitting them to an external non-volatile storage. While the non-volatile storage mentioned in the present invention is an external permanent storage medium (e.g., remote DB, S3 storage, etc.) connected via a network, the memory (130) can function as a local buffer for communicating with it. Additionally, the memory (130) can serve as a local storage to cache and store a prior fingerprint value that has been generated and validated by previous query processing. When generating a new fingerprint value, the processor (110) can perform cryptographic chaining operations by fetching the prior fingerprint value cached in the memory (130) at high speed.

[0061] The structural utilization of such memory (130) has the effect of drastically reducing memory latency by eliminating disk I / O lookups for every query to external non-volatile storage. In addition, by allocating a structured control schema to memory (130) as a fixed-length field structure, hardware optimization effects can be provided to prevent memory fragmentation and dramatically increase the cache hit ratio.

[0062] A network unit (150) according to one embodiment of the present disclosure may implement any wired or wireless communication network capable of transmitting and receiving any type of data and signals, etc. The technologies described in this specification may be implemented not only by the networks mentioned above but also by other networks.

[0063] The network unit (150) is a hardware communication interface for the computing device (100) to transmit and receive data with an external system (e.g., client, non-volatile storage, target object, etc.). The network unit (150) may represent a transmitting and receiving device that exchanges signals through a wired or wireless communication network. The network unit (150) may include a network interface card (NIC), a fiber channel adapter, or a wireless transceiver. The network unit (150) may include a TCP / IP-based Ethernet port, a Remote Direct Memory Access (RDMA) supported interface for high-speed data transmission, a PCIe network adapter, or a 5G / 6G wireless communication modem.

[0064] The network unit (150) receives a query from a client and allocates it to a receiving buffer of memory (130). Subsequently, when an audit log is generated by the processor (110), the network unit (150) encapsulates it in the form of a commit package and transmits it to a non-volatile storage (save request) via a secure channel such as TLS (Transport Layer Security). The network unit (150) can receive a commit response from the non-volatile storage indicating that the fingerprint value generated through cryptographic transformation and / or physical writing has been completed. When the execution gate is transitioned to an open state by the processor (110), the network unit (150) can forward the buffered query control signal to an external target object. Additionally, the network unit (150) asynchronously transmits a subsequent audit log containing a gate state change event to the non-volatile storage.

[0065] The operation of the network unit (150) can prevent the processor (110) from falling into a network packet waiting state (idle state) by processing the logging process and the commit response waiting process at the network hardware level using I / O multiplexing or non-blocking I / O methods. Furthermore, the network unit (150) can achieve an effect of improving hardware communication performance by applying an asynchronous transmission method for subsequent audit logs, thereby resolving network packet bottlenecks and maximizing the utilization efficiency of network bandwidth.

[0066] FIG. 2 illustrates an exemplary method for controlling the execution of a query according to one embodiment of the present disclosure.

[0067] For example, the method in Fig. 2 can be performed by a computing device (100).

[0068] The processor (110) can receive a query from a client through the network unit (150) (210).

[0069] A query defines a request message that requires the retrieval, modification, or execution of specific functions regarding data, and can be generated, for example, by a client. A query can represent a database query statement (SQL) or a remote procedure call (RPC). A query can represent HTTP GET / POST-based REST API requests, GraphQL queries, and / or payload data fed into a message queue.

[0070] A client may represent an entity that generates a query. A client may correspond to an entity that generates a request to a computing device (100). A client may include a user terminal or another server. A client may represent another microservice container within a web browser and / or mobile application.

[0071] The processor (110) can obtain an execution plan for the execution of a received query. To do this, the processor (110) can identify target objects accessed or modified by the query and / or types of actions on said target objects by parsing the received query. The processor (110) can then create an execution context by sorting or formatting the target objects and types of actions according to predefined rules.

[0072] An execution context can define information that standardizes the intrinsic intent of a query. An execution context can correspond to a set of request attributes. For example, an execution context can represent parsed Abstract Syntax Tree (AST) derived information. For example, an execution context can include resource identifiers (URIs) and / or CRUD action mapping tables normalized in JSON format.

[0073] In one embodiment, the query may be expressed in various forms, such as a remittance request, email transmission, data storage and / or API call. The processor (110) may determine a plurality of candidate plans for executing the query. For example, for each of the candidate plans, a decision result related to execution may be generated using policy data stored in memory (130). For example, an execution plan for the query may be determined by a combination of the plurality of candidate plans. The computing device (100) may parse the received query to identify a scope of influence including a target resource accessed or modified by the query and a type of operation on the target resource, and to eliminate grammatical representation differences of the query, generate a canonicalized execution context in which the identified scope of influence and the parameters of the query are aligned or formatted according to predefined rules. Policy data may be collected based on this execution context.

[0074] The processor (110) can use policy data loaded in memory (130) to calculate a judgment result related to the execution of a query and generate an audit log containing the judgment result (220).

[0075] The decision result may indicate whether the query is executed. The decision result may indicate whether the execution plan corresponding to the query is allowed. The decision result may indicate whether each of the candidate plans corresponding to the query is allowed.

[0076] Policy data may define a set of rules that determine whether a query is allowed. Policy data may include predefined access control rules. Policy data may include RBAC (Role-based access control) and / or ABAC (Attribute-based access control) rule sets. For example, policy data may consist of a Rego language file of OPA (Open Policy Agent) or an IAM (Identity and Access Management) JSON policy document. Policy data is dynamically updated without changing the execution code of the computing device (100) or restarting the process, and the processor (110) may apply the updated policy data to queries received after the update. For example, policy data may be collected based on at least one of an execution plan and a query.

[0077] The processor (110) can produce a decision result including one of allow, deny, or hold based on the query, execution plan, and policy data. Additionally, the processor (110) can generate an evidence reference used to produce the decision result. The processor (110) can generate a structured control schema configured to include the decision result, the evidence for the decision, a policy identifier (e.g., policy_id) identifying the policy used for the decision, and / or a policy snapshot identifier (e.g., policy_snapshot_id) indicating the policy version at that time. For example, the structured control schema may refer to a data structure that organizes the decision result, the evidence for the decision, and / or the applied policy determined by the computing device (100) to control the external execution of the query in a structured format. This can be used as base data for generating audit logs and may include information for determining whether to allow the external execution of the query. As an example rather than a limitation, a structured control schema may include: a decision result including allow, deny, and reserve; a code indicating the reason for the decision; a subsequent action flag indicating the action to be taken at the execution boundary, such as execute, block, delay, and substitute; a grounds reference indicating the location of the data or document used for the decision; an identifier of the applied policy rule; a policy scope; a threshold identifier; and / or an identifier of the cryptographic algorithm.

[0078] The computing device (100) can provide a non-disruptive policy update function that dynamically updates policy data without modifying software execution code or restarting system processes, and applies it to newly incoming queries. Non-disruptive updating of policy data is an independent configuration information management technique separated from fixed static execution binaries. This may refer to a dynamic configuration management mechanism that changes the way the system operates by injecting only logical control rules from the outside without interrupting the application in the system's runtime environment. Non-disruptive updating of policy data may be a process of dynamically reloading security policies or access control rule sets into the memory of the computing device (100). The computing device (100) can detect updates by periodically checking the status of an external version control repository where policy data is stored or by receiving a policy change trigger signal from the outside. Subsequently, the computing device (100) can load new policy data into a waiting space in memory through a background operation without blocking the existing query processing process. For example, non-disruptive updating of policy data may be implemented through atomic memory pointer replacement or read-copy-update operations. Specifically, the computing device (100) parses the updated policy data, assigns a new policy snapshot identifier, and loads it into memory. Once loading is complete, the computing device (100) immediately switches the memory pointer used to generate the judgment result of the query to the address of the new policy data using a single atomic instruction. At this time, ongoing queries received prior to the pointer switch and already being processed depend on the previously assigned policy snapshot identifier and are processed according to existing rules. On the other hand, starting with new queries received immediately after the pointer switch, the updated policy data and the new policy snapshot identifier are immediately combined and applied to the calculation of the judgment result.

[0079] The computing device (100) can verify the consistency of the judgment results included in the audit log based on the policy identifier and the policy snapshot identifier. The verification of consistency may include restoring policy data corresponding to the policy snapshot identifier and the policy identifier, and re-performing the judgment on the query using the restored policy data.

[0080] The processor (110) may extract field values ​​from a structured control schema and generate an audit log using the extracted field values. For example, the processor may generate an audit log by concatenating the extracted field values ​​into a sequence of bytes in memory (130). The audit log may include a determination result related to the execution of a query. The audit log in this disclosure may function as a record written to a non-volatile storage, which is data containing structured control schema information or information that can subsequently reconstruct the schema. The audit log may perform the function of proving that an external execution was lawfully performed and may include metadata for preventing tampering. By example, not by limitation, the audit log may include: a record identifier representing a unique ID issued or deterministically derived from the non-volatile storage, storage time information representing the time of storage and / or the order of storage, and / or a data set for restoring the schema. Additionally, the audit log may include information about the structured control schema, a storage identifier, a storage epoch and / or a commit order.

[0081] Depending on the implementation mode, the structured control schema may be implemented to be included in the concept of the audit log.

[0082] By serializing the logical data produced by the processor (110) into a contiguous address space of memory (130) according to a fixed schema structure, memory fragmentation during the audit log generation process is prevented, and a performance improvement effect is achieved that maximizes the cache hit rate during future cryptographic hash operations.

[0083] In one embodiment, the structured control schema may further include a retention policy and a residency-region-id that include a retention period, a destruction method, and privacy information. When disposing of sensitive data, the processor (110) destroys the decryption key and the destruction proof therefor, instead of simply deleting the data. It can be committed, and the decryption of the relevant audit artifact can be blocked unless this destruction evidence is committed. In addition, the processor (110) can physically control the transfer of audit logs or original data outside of a specified country or region based on a regional identifier.

[0084] The processor (110) can transmit a storage request through the network unit (150) to have the audit log written to an external non-volatile storage (230).

[0085] For example, the processor (110) can transmit a storage request through the network unit (150) to have the audit log written to an external non-volatile storage regardless of whether the judgment result is accepted, rejected, or pending.

[0086] A non-volatile storage can define a system that permanently preserves data. For example, a non-volatile storage can permanently store data as a storage outside of a computing device (100). A non-volatile storage is a durable storage medium. A non-volatile storage is a relational database management system (RDBMS) or a NoSQL system. A non-volatile storage is a ledger system in a distributed environment, object storage such as AWS S3, or a blockchain node with Write-Once-Read-Many (WORLD) characteristics. A non-volatile storage can represent a disk in a DBMS.

[0087] By pushing a storage request packet (e.g., unconditionally) to the transmission queue (Tx queue) of the network unit (150) before the processor (110) executes a branching command based on the judgment result, integrity can be ensured that even rejected or suspended threat attempt history is recorded on the disk.

[0088] In one embodiment, a save request may include an audit log and / or a structured control schema. For example, a log, etc., may be saved in response to a save request, an identifier and a save time may be obtained in response to the save, and a commit package may be created using the identifier and time and the log. In another example, a save identifier (record identifier) ​​and / or a save time (record time) may be determined together with a save request, and a commit package may be created using this and the log. In this specification, save and record may be used interchangeably.

[0089] For example, a commit package can be generated by combining an audit log and a fingerprint value. The commit package can be generated in response to a save request to store the audit log in non-volatile storage, a confirmation request to verify whether a commit package containing the audit log has been permanently written to non-volatile storage, or a request for a commit response. The commit package can be generated by combining a judgment result within the audit log, a record identifier identifying the audit log, the time of recording the audit log, a restoration rule for restoring the judgment result within the audit log, and a fingerprint value. The fingerprint value can be generated by applying the cryptographic transformation to the audit log, the record identifier identifying the audit log stored in non-volatile storage, and the time of recording the audit log in non-volatile storage.

[0090] In an additional embodiment, in the case of a tool call or a dangerous command, the processor (110) may perform hierarchical control that executes it primarily in a sandbox and requires a secondary commit based on the result and log.

[0091] In an additional embodiment, in one embodiment, the computing device (100) may utilize multimodal evidence, such as images or audio, in addition to text when collecting judgment evidence, and may include coordinate or timecode information regarding this in the evidence reference field. Additionally, the processor (110) may generate and export a signed external integration bundle (export bundle) that packages a structured control schema and audit logs for mapping with an external system (e.g., SIEM, OpenTelemetry, etc.).

[0092] The processor (110) can receive a commit response generated in response to a save request (240).

[0093] A commit response may indicate that a commit package containing fingerprint values ​​and audit logs has been written (e.g., permanently written) to non-volatile storage. Thus, the processor (110) may receive a commit response indicating that the commit package has been written to non-volatile storage by responding to a storage request through the network unit (150). The commit response may indicate a commit confirmation signal guaranteeing a durable commit of the audit log. The commit response may encompass a durability-guaranteed storage confirmation, a non-volatile storage completion notice, a permanent record confirmation signal, a cryptographically bound commit confirmation notice, an audit-traceable record confirmation message and / or an identifier-linked storage confirmation proof, and an integrity-verified record commit response.

[0094] The expression that data has been stored permanently or persistently in non-volatile storage indicates that the corresponding data (e.g., a combination of timestamps, identifiers, and fingerprint values) has been written to the commit journal, immutable ledger, or Write-Ahead Log (WAL) and that the corresponding data has been stored on the actual disk, or in a distributed storage environment, that replication to a promised majority of nodes has been completed. For example, a commit response can guarantee that a commit package containing the body of the audit log (data such as judgments, reasoning references, etc.) and integrity data such as the log identifier, timestamp, and fingerprint values ​​has been written permanently or persistently.

[0095] In one embodiment, a log identifier (e.g., an audit log identifier) ​​corresponding to an audit log may be generated. The computing device (100) may generate a log identifier that identifies the audit log and / or structured control schema when the audit log is generated.

[0096] A record identifier corresponding to a log identifier may be generated. The record identifier may be determined during the process of storing the audit log in a non-volatile storage. For example, the record identifier may be generated by the non-volatile storage in response to a storage request. As another example, the record identifier may be generated based on a method of generating identifiers deterministically by the computing device (100), and the record identifier generated accordingly may be transmitted to the non-volatile storage.

[0097] After the log identifier is finalized, the computing device (100) and the non-volatile storage can generate and transmit / receive a commit response by performing cryptographic binding operations and durable finalization operations. For example, the computing device (100) can transmit a storage request containing an audit log to the non-volatile storage. The computing device (100) can transmit a storage request containing a structured control schema and an audit log. The non-volatile storage (or computing device (100)) can generate a standard byte sequence by aligning and encoding the record identifier and storage time information corresponding to the log identifier (e.g., control schema identifier and / or audit log identifier) ​​according to a predetermined rule (e.g., canonicalization rule). As an additional embodiment, an implementation method in which the log identifier corresponding to the record identifier and storage time information (record time information) are generated as a standard byte sequence may also be possible. A non-volatile storage (or computing device (100)) can generate a fingerprint value by applying cryptographic operations (e.g., a hash or a Message Authentication Code (MAC) to a standard byte sequence). This fingerprint value can be used to prove that an audit log has not been tampered with and is bound to a specific identifier. A commit response indicating that a commit package containing the fingerprint value and the audit log has been permanently stored in the non-volatile storage can be transmitted from the non-volatile storage to the computing device (100). The computing device (100) can generate a verification value using the aforementioned predetermined rule and determine the validity of the commit response by comparing the received fingerprint value with the verification value.

[0098] According to one embodiment of the present disclosure, a fingerprint value may be included in a commit response. The fingerprint value may be generated after a non-volatile storage (or delegated signing entity) that has received an audit log completes the recording, and the generated fingerprint value may be returned to a computing device (100) and used to represent cryptographic evidence. Depending on the implementation mode, the fingerprint value may be generated as cryptographic operations are performed by the computing device (100) that has received data from the non-volatile storage. The fingerprint value may represent integrity verification data. For example, the fingerprint value may represent a Message Authentication Code (MAC) or a digital signature value. The fingerprint value may represent a SHA-256 hash digest, an RSA asymmetric key-based signature, and / or an HMAC-SHA512 value. For example, the fingerprint value may be generated by applying cryptographic operations to the result of concatenating a log identifier (e.g., schema identifier and / or audit log identifier), save time information, and metadata. For example, a fingerprint value may be generated by applying a hash function to the result of concatenating a loss identifier (e.g., schema identifier and / or audit log identifier), save time information, and metadata, and then applying a MAC to the result of applying the hash function.

[0099] A commit package can be created by combining a log identifier (e.g., a unique key that allows records to be found within the repository), a save time (e.g., a value that identifies when a record was saved in the repository and / or represents the saved sequence), and a fingerprint value.

[0100] In one embodiment, upon receiving a save request, the nonvolatile storage may generate a fingerprint value by applying cryptographic transformations to the received audit log, a record identifier assigned by the nonvolatile storage (e.g., record_id), and a timestamp. The fingerprint value may represent a value indicating that the identifier and content recorded in the nonvolatile storage are cryptographically linked. Subsequently, the nonvolatile storage may complete a commit package that is permanently recorded by combining a rule for restoring a determination result (e.g., a restoration rule) and the fingerprint value. To prove the completion of the commit package, the nonvolatile storage generates and transmits a commit response containing the fingerprint value. The commit response may guarantee that the data is written to a disk journal or immutable ledger, rather than to memory or a temporary buffer, and that it is physically finalized.

[0101] The processor (110) may determine that the commit response, save request, and / or query are invalid if the commit response does not arrive within a preset validity period (e.g., commit timeout) from the time of the save request. The commit response may mean a response message indicating that it has been permanently written to a non-volatile storage, such as a permanent storage medium. The commit response may mean a message indicating a permanent write to a non-volatile storage, rather than simply indicating that it has arrived at the server.

[0102] In one embodiment, after a preset commit validity period has elapsed from the time of the request to save the audit log, the commit response may not be received or the commit response may be determined to be invalid.

[0103] In one embodiment, the technique according to one embodiment of the present disclosure can provide a hardware synchronization effect that fundamentally prevents a write-free execution state caused by I / O delay or queue loss by causing the controller of the non-volatile storage to calculate and return a cryptographic fingerprint value to the network only after generating a disk write success interrupt.

[0104] In an additional embodiment, in the event of a network disconnection, the processor (110) may temporarily designate the local security store as the primary gate store and perform temporary control by obtaining a local commit response. Upon network recovery, the processor (110) synchronizes the locally stored audit logs by performing an offline batch commit to the remote non-volatile store, and may forcibly switch the execution gate to a closed state if synchronization fails within a specified period.

[0105] The processor (110) can verify the validity of a commit response by comparing a verification value reconstructed from a commit response with a fingerprint value included in the commit response (250).

[0106] The processor (110) can validate the validity of a commit response by checking whether the received commit response includes a schema identifier and / or an audit log identifier.

[0107] The processor (110) can determine whether there is a match between the fingerprint value from the non-volatile storage and the fingerprint value calculated by the processor (110). The processor (110) can extract metadata and a fingerprint value from the received commit response and combine them with the original audit log stored in memory (130) to generate a reconstructed verification value. For example, the processor (110) can calculate a local fingerprint value using the audit log sent by itself (log identifier and time information generated by the sent or non-volatile storage) and verify the validity of the commit response by comparing it with the received fingerprint value bit by bit.

[0108] The processor (110) can verify the validity of a commit response by comparing the reconstructed verification value with the fingerprint value of the commit response bit by bit. For example, a non-volatile storage can generate a MAC using a message and a secret key and include the MAC in the commit response. The computing device (100) can verify the validity of the commit response by calculating the MAC using the message it sent and the secret key it knows, and by comparing the result of this calculation with the result of the reception. This validation may refer to a process of determining whether the received commit response is cryptographically bound with the data stored internally.

[0109] The following exemplifies methodologies for verifying the validity of various forms of commit responses. Depending on the implementation mode, the validity of a commit response can be verified through a combination of the verification methods described above and those to be described below.

[0110] In one embodiment, the processor (110) may perform a time verification when verifying the validity of a commit response. The time verification may represent a process of determining whether the commit response satisfies a wait condition. For example, the processor (110) may determine whether the difference between the times is within a valid time window by comparing the time of receipt of the query or the time of the save request with the time of recording within the commit response. For example, the processor (110) may determine that the commit response is invalid if it is determined that the commit response pertains to an epoch that has already passed or if a past commit response is received.

[0111] In one embodiment, the processor (110) may perform signature verification when verifying the validity of a commit response. For example, the processor (110) may verify whether the signature information is forged by determining whether the commit response contains authentication information based on cryptographic transformations, such as a private key in a non-volatile storage.

[0112] In one embodiment, the processor (110) may verify the determinism that the same result must be obtained for the same input when verifying the validity of the commit response. For example, the processor (110) may determine whether both entities used the same consensus rule to determine whether the rules for organizing data (e.g., normalization rules, encoding rules and / or separator rules) match between the computing device (100) and the non-volatile storage.

[0113] In one embodiment, the processor (110) may perform chain verification when verifying the validity of the commit response. For example, when reconstructing the fingerprint value, the processor (110) may verify whether the continuity of the current audit log with the previous audit log has not been compromised by performing a cryptographic operation (e.g., hash operation) including the preceding fingerprint value of the preceding audit log stored in memory (130). In this example, if the preceding audit log does not exist, a predetermined initial value may be used. For example, a non-volatile storage or computing device (100) may generate a fingerprint value by applying a cryptographic transformation to the result of combining the preceding fingerprint value of the preceding audit log that was created and verified prior to the current audit log, the current audit log, the record identifier within the non-volatile storage, and the storage time. When verifying the validity of a commit response, the computing device (100) may obtain a prior fingerprint value of a prior commit response corresponding to a prior audit log that was previously received and validated from the local storage of the computing device, combine a record identifier and storage time extracted from the commit response, the prior fingerprint value, and the audit log, and reconstruct the verification value by applying a cryptographic transformation to the combined result. The computing device (100) may determine whether the current audit log has cryptographic continuity with the prior audit log by comparing the reconstructed verification value with the fingerprint value included in the commit response. The local storage may represent a local memory area under the management of the computing device (100).

[0114] Such verification operations can be implemented through a combination of the embodiments described above.

[0115] This verification operation can be implemented by utilizing a cryptographic accelerator within the processor (110).

[0116] The processor (110) can recalculate the fingerprint value of the received commit response using information stored in the local storage, thereby implementing a zero-trust architecture that does not blindly trust the response from the external storage and providing a security effect that neutralizes man-in-the-middle attacks.

[0117] In an additional embodiment, in one embodiment, the computing device (100) may support cryptographic agility that allows for the replacement or parallel application of cryptographic suites. When validating a commit response, the computing device (100) may verify integrity through a hybrid signature with quantum-resistant cryptography (PQC). Additionally, if the determination or commit verification operation is performed in a trusted execution environment, the computing device (100) may include the attestation_quote_hash or measured_boot_hash in a structured control schema. If such attestation fails, the processor (110) may fail the validation and close the execution gate.

[0118] The processor (110) can determine whether to transition the execution gate based on the result of validating the commit response (260).

[0119] The processor (110) may transition the execution gate from a closed state to an open state if the validation of the commit response is successful and the judgment result is allowed. The execution gate in this disclosure may represent a security barrier that controls externalities. The execution gate may refer to an access control point within the computing device (100) or within the target object. The execution gate may refer to a firewall that functions as an external execution boundary. The execution gate may be exemplified by an API forwarding rule, relay switch control logic, or an egress filter module in a Microservice Architecture (MSA) environment. Accordingly, the reception of the commit response may precede the external execution of the query.

[0120] This transition process can be processed within a single Atomic Control Window (ACW). For example, the processor (110) may use a lock or Compare-and-Swap (CAS) instruction to prevent other threads or interrupts from intervening between the successful verification and the transition operation. The processor (110) may prevent the gate from opening redundantly with the same response by setting the fingerprint value used for verification to a consumed state.

[0121] In the present disclosure, an atomic control interval may refer to an interval indicating that the confirmation of successful verification and the opening of the gate are performed as indivisible atomic operations (e.g., a single operation). Within such an atomic control interval, no other operation may intervene between the start and end of the atomic operation. Accordingly, a TOCTOU (Time-of-Check to Time-of-Use) attack may be blocked. The computing device (100) may atomically bind the verification result of the commit response with the state transition of the execution gate. An atomic control interval may refer to an interval in which specific operations are atomically bound and performed.

[0122] On the other hand, if verification fails or the judgment result is deny or hold, the processor (110) may keep the execution gate in a closed state. As the execution gate is kept in a closed state, the execution of the corresponding query (e.g., external effect) may be blocked.

[0123] When the execution of the query is successfully completed, the processor (110) can re-transition the gate back to a closed state within the ACW. This re-transition process can take place within an atomic control window (ACW). For example, the transition process and the re-transition process may take place together within a single atomic control window (ACW). In this example, the confirmation of successful verification, the opening of the gate, and the closing of the gate may be performed as atomic operations. For example, the opening of the gate and the issuance and consumption of the gate opening token may be performed atomically.

[0124] Whenever a state transition occurs, the processor (110) can detect a gate state change event and transmit a subsequent audit log to a non-volatile storage. For example, the processor (110) can detect a gate state change event including at least one of the time when the execution gate transitioned to an open state and the time when it transitioned to a closed state, and can generate a subsequent audit log including said gate state change event. The computing device (100) can bind that said gate state change event is due to the validation of said commit package by including a record identifier or fingerprint value corresponding to the commit package in said subsequent audit log as a reference identifier. The computing device (100) can record said subsequent audit log by transmitting it asynchronously to a non-volatile storage.

[0125] The computing device (100) can prevent the atomic control window from being opened redundantly based on the same commit response by setting the committed response or fingerprint value used for validating the commit response to a consumed state or by expiring a one-time token (e.g., nonce).

[0126] By having the processor (110) control the gate state using atomic CPU instructions, the technique according to one embodiment of the present disclosure can physically eliminate vulnerabilities of a Time-of-Check to Time-of-Use (TOCTOU) race condition that may occur in a multi-core environment and maximize transaction safety in a distributed processing environment. Additionally, in the event of a post-audit or dispute, the computing device (100) can provide deterministic reproducibility that can verify the consistency of the judgment result without error by using a policy snapshot identifier (e.g., policy_snapshot_id) recorded in the audit log to completely restore the policy data at that time to memory (130) and re-perform the judgment.

[0127] In an additional embodiment, if the operation of the target object requested by the query is a nested structure (e.g., a call tree) containing lower calls, the processor (110) may recursively apply the generation of a determination result, the configuration of a structured control schema, the generation of an audit log, and the verification of a commit response down to the lowest call unit that directly causes an external effect. This structurally prevents the upper wrapper call from bypassing the lower control and verification processes to cause an external effect.

[0128] Additionally, when multi-stage chain delegation occurs between multiple entities connected via a network, the processor (110) can process sub-requests by receiving and verifying delegation proof. In this process, the processor (110) can check the path summary within the delegation chain and, if cyclic delegation is detected or if it is confirmed that the revocation list and expiration time have expired, block the execution of the query and record this in the audit log.

[0129] In an additional embodiment, the computing device (100) may apply a hard or soft deadline to the waiting time for a commit response in an environment where real-time processing is required. If a specified timeout is exceeded, the processor (110) may record a deadline miss event (deadline_miss_event) in the audit log, and at the same time block external execution and transition or maintain the execution gate to a pre-specified alternative action or safe state or closed state according to a policy.

[0130] In an additional embodiment, for operational resource optimization, the processor (110) generates a metering record and / or usage receipt within an atomic control window only when an execution gate is opened and an external effect is successfully established. This can structurally prevent cost omissions and duplicate counting due to network delays or retransmissions. Furthermore, in an environment where systems are interlinked between multiple organizations, this can establish a federated audit structure that can mutually verify the integrity of the delegation chain.

[0131] FIG. 3 illustrates data structures according to one embodiment of the present disclosure.

[0132] The structured control schema (310) may represent a logical control and audit data structure that the computing device (100) generates immediately after determining whether to execute a query.

[0133] A structured control schema (310) may include a decision result indicating a value of one of allow, deny, and defer; a decision basis indicating the basis (or code thereof) from which the decision was derived; a pointer to the basis data used for the decision; a basis reference indicating a document hash and / or time code; a follow-up action flag indicating a value (e.g., allow, block, substitute, and approval request, etc.) indicating a follow-up action to be applied to an external output or external action; and / or a policy identifier identifying a policy rule (e.g., a bundle of policy rules) applied to the decision. For example, the data listed above may be used as required fields of the structured control schema (310).

[0134] Additionally, the structured control schema (310) may further include a policy snapshot identifier that fixes the policy version at the time of determination, a policy scope indicating the scope of the authority and / or resources to which the policy applies, and identifier and rule parameters. For example, these data may be used as extension fields. The identifier and rule parameters may include, for example, a threshold identifier (threshold_id), a verification rule identifier (ack_verification_rule_id), a canonicalization rule identifier (canonicalization_rule_id), and / or a reconstruction rule identifier (reconstruction_rule_id).

[0135] Additionally, the structured control schema (310) may further include an atomic control interval identifier (ACW_id) and / or a retransmission prevention identifier (nonce, sequence, etc.).

[0136] In one embodiment, the audit log (320) may be defined as a log record that includes information of the structured control schema (310) or information that can deterministically reconstruct the structured control schema (310). The audit log (320) may represent an actual log record that is serialized into a sequence of bytes in memory or written to storage based on the information of the structured control schema.

[0137] For reconfigurability requirements, the audit log (320) may include the required fields of the structured control schema or have mapping relationships thereto. Additionally, the audit log (320) may include log identifiers (or record identifiers depending on the implementation mode) as log-specific data, including a schema record identifier (schema_record_id) identifying the structured control schema and a log record identifier (log_record_id) identifying the audit log, an event identifier indicating an event code (event_code) and an event timestamp (event_timestamp_wall / mono), and execution principal information indicating a caller ID (caller_id), an actor role (actor_role), and a tenant ID (tenant_id). Additionally, the audit log (320) may include hash chain links indicating a previous packet hash (prev_packet_hash) and a current packet hash (packet_hash).

[0138] The audit log may include a pre-configured set of audit fields or be configured in a form reconstructable to the minimum set of audit fields according to pre-defined mapping rules so that the judgment result can be deterministically reproduced during a post-audit.

[0139] To ensure that the audit log (320) can be reconstructed from the structured control schema (310), the computing device (100) may pre-specify a set of audit fields to be stored or associated in the audit log (320). To reconstruct the structured control schema (310), it is required that for the same audit log (e.g., a single record identified by the same schema_record_id and log_record_id), each field value must always be restored to a single and unique value.

[0140] The required fields within the audit log (320) may include at least a decision result, a reason for the decision, a subsequent action flag, a reason reference, and a policy identifier. Depending on the implementation mode, the required fields may optionally further include a policy scope. As the set of required fields of the structured control schema (310) and the set of required fields of the audit field set are aligned identically, a single restoration for the same record may be possible. The description in this disclosure that the audit log contains information of the structured control schema indicates that at least the required fields within the structured control schema (310) must be included in the audit log (310), and does not require that all optional extended fields within the structured control schema (310) also be included in the audit log (320).

[0141] Additionally, the set of audit fields (essential fields of the structured schema in FIG. 3) to be included in the audit log (320) may further include at least one of the following as optional extension fields: a log identifier including a schema record identifier (schema_record_id) and a log record identifier (log_record_id), a save point, a commit sequence (commit_sequence), a canonicalization rule identifier (canonicalization_rule_id), and an acknowledgment verification rule identifier (ack_verification_rule_id). In particular, when the set of audit fields includes a log identifier (schema_record_id and log_record_id), the log identifier is configured to be deterministically pre-calculated on the side of the computing device (100) before being transmitted to the storage, or a corresponding value (e.g., deterministic digest, request-record binding value, etc.) that is deterministically mapped to an identifier issued by an external storage is included in the audit log so that the identifier can be deterministically reconstructed thereafter. In other words, the original identifier text does not necessarily need to be included in the log at the time of storage; it is sufficient to guarantee only the possibility of post-recovery.

[0142] In one embodiment, the audit log (320) may be divided and stored into multiple log packets depending on the size of the data or the characteristics of the storage. In this case, each log packet is composed of a hash chain link structure that includes the hash value of the previous packet (prev_packet_hash) and the hash value of the current packet (packet_hash). These hash chain links may also be included in the audit log (320). The computing device (100) generates an integrity compromise event when a link mismatch between adjacent packets or a hash verification failure is detected. In this case, the external execution of the query corresponding to the audit log is treated as not satisfying the requirements for a valid commit response or gate opening, so the execution gate remains closed or the execution of the query is processed as deferred and rejected.

[0143] The fact that the audit log is reconstructible may mean that it directly includes a set of audit fields corresponding to the required codes of the structured control schema as described above, or includes deterministically fixed mapping rules (e.g., one-to-one mapping rules) that can restore said fields. The mapping rules include field name mapping rules, encoding and serialization rules, combining rules, etc., and may be designated as a specific set of rules by a reconstruction rule identifier (reconstruction_rule_id) included in the structured control schema (310) and policy snapshot.

[0144] As non-limiting examples of the above mapping rules, a fixed array order of a set of fields, a length-prefix encoding specifying the byte length of each field, Unicode character normalization rules (e.g., NFC), and rules for handling null values ​​or whitespace characters may be applied. Additionally, if the determination basis or subsequent action flag includes multiple elements (arrays), each element may be serialized after being deterministically normalized according to a predefined alignment rule (e.g., ascending order of code value or identifier) ​​and duplicate removal rule. These normalization and alignment rules for same-value comparison may be fixed by a canonicalization_rule_id that can be specified independently of the reconstruction rule identifier or by a basic set of determinism rules of the computing device (100).

[0145] The reconstruction rule identifier (reconstruction_rule_id) must mathematically guarantee that the same single sequence of bytes (canonical_bytes) is always reproduced from the same record for the fields and validation input data that are directly or indirectly involved in the decision to open the execution gate. If rule violations are detected, such as when different reconstruction rule identifiers are randomly mixed and applied, when ambiguous reconstruction occurs where different restoration results are derived even under the same rule, or when the restoration of a set of audit fields fails, the computing device (100) may record this as a determinism violation event. An audit log (320) in which a violation or inconsistency of a 1:1 mapping rule is detected, and the corresponding commit response (340), are considered not to satisfy the validity requirements for opening the execution gate. Therefore, even if the initial decision result for the query was allowed, the computing device (100) blocks the actual execution of the query and keeps the execution gate in a closed state.

[0146] A commit package (330) may refer to a bundle of data that is permanently written to non-volatile storage. As an example, not a limitation, the commit package (330) may include an audit log source (or a determination result within the audit log) and a fingerprint value. The fingerprint value may represent an audit log, a record identifier, and data for integrity verification that has applied cryptographic transformation at the time of recording. The commit package (330) may further include a record identifier identifying the audit log written within non-volatile storage, a record time identifying the time when the recording was physically completed (or when completion was requested), and a restoration rule identifying a mapping rule for a single restoration of the determination result.

[0147] The commit response (340) may represent a cryptographic receipt that the non-volatile storage (or delegated signing entity) returns to the computing device (100) after confirming physical storage. The commit response (340) may include, for example, a fingerprint value and authentication information. Here, the authentication information may include the signature or Message Authentication Code (MAC) of the non-volatile storage (or delegated signing entity). The commit response (340) may further include a record identifier of the schema / log confirmed by the non-volatile storage, and a record time indicating the commit generation and commit sequence. The commit response (340) may further include anchoring information such as a signer ID (signer_id), a signature key identifier (key_id), a certificate reference (certificate_reference), an ACW_id derivative value for ACW context matching verification, and (when integrated with a blockchain) a ledger transaction hash and a Merkle proof.

[0148] FIG. 4 is a sequence diagram showing the flow of data to control the execution of a query according to one embodiment of the present disclosure.

[0149] The external execution boundary (401) can serve as a traffic control partition boundary between the computing device (100) and a separate external entity responsible for executing the query. The external execution boundary (401) can function as a network contact point or a security control point. The external execution boundary (401) can be implemented as a virtual network interface of an application programming interface routing device, a local port occupied by a container, or a digital output pin that transmits a control signal to a physical actuator. The computing device (100) can control an execution gate at this external execution boundary (401) to physically or logically block or allow the occurrence of external effects corresponding to the query.

[0150] The computing device (100) can perform record commit prior verification and gate control methods. The computing device (100) is an electronic device equipped with data processing and communication capabilities, and may represent, for example, a server or access control device that mediates traffic between a client and a non-volatile storage (402). For example, the computing device (100) may encompass a cloud virtual machine, a security proxy module, or an edge computing device.

[0151] The non-volatile storage (402) is a storage system that permanently preserves audit logs and related metadata. The non-volatile storage (402) is a durable storage medium. For example, the non-volatile storage (402) may include a disk in a relational database, a non-relational database, or object storage. The non-volatile storage (402) may encompass an immutable ledger system in a distributed environment, a blockchain node with write-only characteristics, or a secure dedicated audit artifact storage. The non-volatile storage (402) performs the role of generating a cryptographic fingerprint value upon completion of physical writing and returning a commit response to the computing device (100).

[0152] The computing device (100) can receive a query from a client that can cause an external effect (410).

[0153] A query is a control signal or request message transmitted to a computing device (100). The term query may be used to encompass database queries, remote procedure calls, or application interface requests, and, for example, a query may include hypertext transfer protocol-based payload data containing identifiers of specific resources and operation actions. The computing device (100) may parse the query to identify target objects and types of operations, and normalize them to obtain an execution plan and / or execution context. For example, the query may include requests for account transfers on a mobile banking app, deletion of data from a DB server, and requests for insurance payouts.

[0154] An execution plan may refer to information defining the actual processing procedure of a query, obtained by parsing a received query to identify target objects accessed or whose state is changed by the query, as well as the types of actions performed on them. An execution plan serves as a logical or physical specification of operations for processing a query; for example, an execution plan may represent a data access path generated by a query optimizer in a database management system, or a structured call tree for invoking specific tools or functions within an application. For instance, an execution plan may represent a database operation plan defining the index scan method and join order for a specific database table, or a set of parameters and specific API call sequences identified to sequentially modify multiple backend resources in a microservices environment.

[0155] An execution context refers to information that standardizes the essential intent of a query by sorting or formatting target objects and action types according to predefined rules, and is utilized as basic data for collecting policy data and producing judgment results in subsequent steps. An execution context is a single set of request attributes configured by a computing device (100) to clearly identify the intent of a request; for example, the execution context may include parsed abstract syntax tree derivation information that extracts only the essential semantic structure by removing grammatical expression differences or meaningless whitespace that may occur when writing a query. For example, the execution context may be a resource identifier and data manipulation (creation, reading, updating and / or deletion) action mapping table normalized in JSON form according to a set rule, or represent a single-byte sequence-based execution intent object configured by deterministically rearranging multiple query arguments in a predefined alphabetical order or identifier ascending order.

[0156] The computing device (100) can apply pre-set policy data to the received query and execution plan to produce a judgment result, and based on this, can configure or create a structured control schema (420).

[0157] A structured control schema may include logical decision and control records. A structured control schema is a set of required fields that includes a decision result, a decision reason code, a subsequent action flag, and / or a reason reference. A structured control schema may represent a fixed-length standardized data format that includes a policy identifier used for the decision, a policy snapshot identifier that fixes the policy environment at the time, a reconstruction rule identifier for data restoration, and a normalization rule identifier.

[0158] In one embodiment, the computing device (100) may generate a determination result including an allow, deny, and hold for the execution of the query based on at least one of a query and an execution plan and policy data, and an evidence reference used to generate the determination result, and may construct a structured control schema including the determination result and the evidence. The structured control schema may include a policy identifier identifying the policy data used to generate the evidence and a policy snapshot identifier representing a specific version of the policy data.

[0159] For example, if the query includes an account transfer request on a mobile banking app, the computing device (100) can generate a determination result to be included in a structured control schema by performing a process of retrieving grounds such as identity authentication logs, account balance DB, and abnormal transaction detection. If the determination result is allowed, grounds information on the grounds on which the allowed transfer was permitted may also be included in the control schema. Accordingly, after a commit response is received and its validity is verified according to subsequent operations, a gate on the outer execution boundary (401) within the atomic control interval is opened and an interbank transfer operation (outer execution effect) can be performed.

[0160] In another example, if a query involves deleting data from a DB server, the computing device (100) may generate a determination result to be included in a structured control schema by performing a grounds retrieval process that includes the requester's authorization information, operational policies (e.g., requiring approval from two or more people), translation history, etc. In this example, the determination result will be determined as a rejection because the query does not satisfy the operational policy conditions. In this example, the computing device (100) may generate an audit log by including information about who, when, and why the rejection was made together in the structured control schema, and allow said audit log to be recorded and committed. In this example, the gate state on the outer execution boundary (401) will remain closed.

[0161] In another example, if the query includes a request for insurance payment, the computing device (100) may perform a process of retrieving evidence such as accident report records, hospital diagnosis records, and police accident investigation records, and as a result of this process, the judgment result may be determined as pending. The history of the judgment result may also be recorded and / or committed to an external storage (402). In this example, the gate state on the external execution boundary (401) may remain closed until an event regarding the final police investigation result is received. In response to the receipt of the event regarding the final investigation result, actions according to the flowchart in FIG. 4 may be performed again.

[0162] In another embodiment of the present disclosure, if the decision result includes acceptance, the step of generating an audit log from a structured control schema may be performed. If the decision result includes rejection, the step of generating an audit log from a structured control schema may not be performed, and it may be determined to keep the execution gate in a closed state. If the decision result includes suspension: the execution of the query is temporarily suspended, and in response to the receipt of an additional acceptance event or an external trigger signal, the decision for said query is re-executed, and the step of generating an audit log from a structured control schema based on said re-executed decision result may be performed.

[0163] The computing device (100) can generate an audit log by extracting information from the generated structured control schema (430).

[0164] An audit log is serialized data intended to be written to a storage medium. For example, an audit log is a log record containing information that can deterministically restore essential fields of a structured control schema. An audit log is a column of data aligned by bytes according to mapping rules, and when partitioned and stored based on data size, it may refer to a cryptographic data block containing hash chain links between adjacent packets.

[0165] A computing device (100) can generate an audit log to be written to a non-volatile storage by extracting multiple field values ​​from a structured control schema configured to include a calculated judgment result and a judgment basis, and by concatenating the extracted field values. The generation of the audit log can be described as a serialization process that converts a structured control schema in the form of a multidimensional object into a single data column for permanent writing to an external storage medium. The generation of the audit log can represent a process of processing data such that a pre-specified set of audit fields from the entire information contained in the structured control schema can be directly included in the audit log or restored as a single unit by a deterministically fixed one-to-one mapping rule. As an example, not a limitation, the required fields of the set of audit fields may include at least a judgment result, a judgment reason code, a subsequent action flag, a judgment basis reference, and a policy identifier. The audit log is generated to ensure reconstructibility, which allows the required fields of the control schema to be reconstructed in reverse for the same record identifier. For example, the computing device (100) can generate an audit log by sorting and encoding the extracted field values ​​in byte units according to a one-to-one mapping rule specified by a reconstruction rule identifier or a normalization rule identifier. Specifically, the computing device (100) serializes the field values ​​by applying a fixed array order of the set of fields, length-prefix encoding specifying the byte length of each field, Unicode character normalization, and null value or whitespace character processing rules. In particular, if the judgment basis (e.g., judgment reason code) or subsequent action flag is in the form of an array containing multiple elements, the computing device (100) normalizes the elements according to a sorting rule (e.g., ascending order) and duplicate removal rule of a predefined code value or identifier.The computing device (100) produces a serialized byte sequence according to a predefined rule and allocates it as an audit log to a contiguous address space in the memory of the computing device (100).

[0166] The generation of such audit logs provides a technical effect that fundamentally prevents the contents of the structured control schema from being modified differently or interpreted ambiguously due to differences in the systemic characteristics of the non-volatile storage or the network environment. Furthermore, this method of generating audit logs can guarantee determinism, which enables the computing device (100) to recalculate the cryptographic fingerprint value within the commit response received from the non-volatile storage without bit-level error in the local environment and perform a comparison of identical values.

[0167] The computing device (100) can transmit a storage request (440) including an audit log to a non-volatile storage (402) (440).

[0168] For example, the computing device (100) transmits an unconditional save request so that the generated audit log is permanently written to the non-volatile storage (402), regardless of whether the calculated judgment result corresponds to acceptance, rejection, or pending. The transmission of the save request is a communication act that pushes data out. The transmission of the save request may include the action of pushing packets into a transmission queue prior to the branching processing of the judgment result. For example, the transmission of the save request may represent a procedure for transmitting the audit log source and basic parameters for cryptographic transformation to the non-volatile storage (402) through a secure communication channel in order to fix the starting point for calculating the subsequent waiting time (e.g., valid time window).

[0169] The non-volatile storage (420) can create a commit package using the information included in the save request and record the created commit package (450).

[0170] For example, the non-volatile storage (402) may configure a commit package containing an audit log in response to a received storage request and permanently record it on a physical medium such as a disk. Recording the commit package is a process of permanently recording a data set containing the audit log to a permanent storage medium. Recording the commit package may include the process of the non-volatile storage (402) assigning a record identifier corresponding to the audit log and determining the physical record time. Recording the commit package may refer to a series of atomic input / output operations in which the non-volatile storage (402) applies deterministic cryptographic transformations to the audit log, the assigned record identifier, and the record time data to produce a fingerprint value, and combines these elements to permanently preserve them.

[0171] A non-volatile storage (402) or computing device (100) can produce a single result value (i.e., a fingerprint value) by applying a cryptographic transformation, such as a one-way hash function or a symmetric key-based authentication algorithm, to an audit log, a record identifier identifying the audit log, and a physical record time. The non-volatile storage (402) or computing device (100) can generate a commit package by combining an audit log (e.g., a judgment result), a record identifier identifying the audit log, a record time of the audit log, a restoration rule for restoring a judgment result within the audit log, and a fingerprint value.

[0172] For example, the nonvolatile storage (402) can flush the generated commit package to disk in a single atomic write by first generating and combining a record identifier and a fingerprint value corresponding to the audit log in the internal memory (e.g., buffer) of the nonvolatile storage (402). When the nonvolatile storage (402) receives a storage request containing an audit log from the computing device (100), the nonvolatile storage (402) can calculate the location or order in which the data will be stored on its memory (RAM) buffer before writing it to a permanent storage medium. At this time, the nonvolatile storage (402) can determine the next record identifier (e.g., sequence number) and generate a record time (e.g., timestamp) at the current time in memory. The nonvolatile storage (402) can calculate a fingerprint value in memory by performing a cryptographic hash operation using the record identifier allocated in memory, the record time, and the received audit log as materials. The non-volatile storage (402) can generate a commit package corresponding to a single block by concatenating an audit log + record identifier + record time + fingerprint value within a buffer. The non-volatile storage (402) can make a durable commit package by writing (e.g., fsync / flush) the generated block to a permanent storage medium (e.g., disk).

[0173] In one embodiment, the commit package may be configured to include a record to a non-volatile storage (402) for the audit log and metadata related to the record (e.g., a record identifier, a record time and a fingerprint value).

[0174] The non-volatile storage (402) can send a commit response to the computing device (100) to ensure that the recording of the commit package is complete (460).

[0175] A commit response is a reply message indicating the completion of a task. A commit response can function as a cryptographic receipt containing a record identifier and a generated fingerprint value. The commit response may function not as a simple success return code, but as durable commit confirmation notification data that proves origin and integrity by including authentication information or a signature generated based on the encryption key of the non-volatile storage (402).

[0176] In one embodiment, after the physical writing of the audit log is completed, the non-volatile storage (402) can generate a fingerprint value by combining a record identifier and a record time based on the record, and then transmit it by including it in a commit response corresponding to a commit package based on the fingerprint value.

[0177] The computing device (100) can verify the validity of the commit response using the received commit response (470).

[0178] The computing device (100) can actively reconfirm the contents of the received commit response without external trust. Validation is a process of determining whether the data is true or false. Validation may include extracting historical metadata (e.g., a record identifier and / or a record time, etc.) within the received commit response, combining it with the original audit log stored in the local storage of the computing device (100) to reconstruct a validation value, and then comparing the validation value with the fingerprint value included in the commit response bit by bit. For example, validation may refer to a multidimensional security review process that includes not only a comparison of whether the reconstructed validation value and the received fingerprint value match, but also a time verification of whether the response arrived within a preset validity time window, a verification of chain connectivity with the preceding fingerprint value of the preceding audit log, and / or a verification of the integrity of the authentication information in the non-volatile storage (402).

[0179] More specifically, the computing device (100) can perform data extraction, reconstruction, comparison, time verification and / or authentication procedures.

[0180] The computing device (100) extracts the record metadata and cryptographic fingerprint value assigned by the non-volatile storage (402) from the received commit response. Here, the record metadata may include at least one of a schema record identifier, a log record identifier, a physical record time, a commit generation, and a commit order. The computing device (100) may obtain the original audit log and control schema data that were temporarily stored in the local storage of the computing device (100). Based on the extracted record metadata and the locally obtained audit log, the computing device (100) may re-perform the same operations used by the non-volatile storage (402) when generating the fingerprint value. Specifically, the computing device (100) normalizes the obtained data into a single deterministic serialized byte sequence according to a predetermined field order, a length prefix encoding specifying the byte length of the data, special character and space processing rules, etc., based on a predetermined normalization rule identifier. Subsequently, a reconstructed verification value unique to the computing device can be produced by applying a cryptographic transformation, such as a one-way hash function or a symmetric key authentication algorithm, to the corresponding byte sequence. The computing device (100) compares the reconstructed verification value produced locally with the fingerprint value extracted from the commit response bit by bit. If even a single bit does not match, or if multiple interpretations are found due to a mismatch in the application rule during the normalization rule application process, the computing device (100) may treat this as a determinism violation event and process the validity verification as a failure.

[0181] Additionally, the computing device (100) can perform a time window and order integrity verification process. The computing device (100) calculates the time difference between the time of receiving the query or the time of sending the request to store the audit log and the time when the commit response arrives, and compares this with a preset valid time window. A commit response that arrives after the valid time window has expired is treated as expired and discarded. Furthermore, if a one-time identifier or a monotonically increasing commit order value included in the commit response is checked and a reversal of order or duplication is detected, the computing device (100) may determine this as a sign of a retransmission attack or response contamination and deny its validity.

[0182] Additionally, the computing device (100) can perform source authentication and signature verification processes. The computing device (100) can verify whether the integrity information or authentication information included in the commit response is legitimately signed based on a specified encryption key in a pre-authorized non-volatile storage (402). If the certificate chain or verification key is not available or the legitimacy of the delegation is not proven, the commit response may be classified as uncertain and treated as having failed verification.

[0183] The validity verification of a commit response is determined to be successful only when the combination of the mutually independent technical verification conditions listed above is satisfied. This converged verification method can neutralize system failures, data falsification in network segments, time delay attacks, and man-in-the-middle attacks. When multiple verification processes are adopted, if any of the verification processes fail, a structural security effect can be achieved by keeping the execution gate closed regardless of policy approval, thereby fundamentally blocking the occurrence of external effects.

[0184] The computing device (100) can determine the state of an execution gate located at an external execution boundary (401) based on the result of validation and the initial result of judgment, and generate a gate control signal (480).

[0185] Gate control can refer to a switching operation that manipulates whether a signal passes. Gate control is a conditional opening operation that transitions an execution gate from a closed state to an open state only upon a verification success or acceptance judgment. For example, gate control is a physical state control process that enforces the verification of a success event and the state transition operation to be processed collectively by mutual exclusion operations or atomic instructions within a single atomic control window without interruption, in order to fundamentally prevent concurrency issues in a multi-threaded environment. In the event of a verification failure, a timeout, or a rejection judgment result, gate control maintains the closed state.

[0186] The external execution boundary (401) can perform gate operations according to the control signal of the computing device (100) (490).

[0187] When the gate control result transitions to an open state, actual query execution is performed. The gate operation is the process in which a control signal flows to a destination (e.g., a target object). The gate operation is the process in which a control signal according to the query safely passes through the external execution boundary (401) and reaches the target object, thereby causing an external effect. For example, the gate operation can neutralize duplicate reuse attacks by immediately returning the external execution boundary (401) back to a closed state (e.g., atomic retransition) immediately after the execution of the query is successfully completed, and setting the consumed state of the used fingerprint value. The gate operation may represent a series of cyclic security enforcement processes that detect these open and closed state change events and trigger them to be written back to the non-volatile storage (402) as a subsequent audit log.

[0188] In one embodiment, the external execution boundary (401) can transition the execution gate from the open state to the closed state in response to a query execution end event after the execution gate has transitioned to the open state, under the control of the computing device (100), so that the execution end event and the transition operation of the execution gate are processed as atomic operations within a single atomic control window.

[0189] FIG. 5 illustrates an exemplary method for verifying the consistency of a judgment result according to one embodiment of the present disclosure.

[0190] The computing device (100) may perform a step of verifying the consistency of the judgment result within the audit log based on the policy identifier and policy snapshot identifier included in the audit log when a post-audit or security dispute occurs after the query execution is completed. Verifying the consistency of the judgment result is a process of objectively re-proving that the execution of a query processed in the past (e.g., a transaction) was performed under legitimate authority and rules. Verifying the consistency of the judgment result is a process of ensuring deterministic reproducibility by reconstructing the environment at the time the audit log was generated to exclude the influence of security policies updated or changed at the current time, and re-evaluating whether the query is allowed based on the standards of the past time.

[0191] In one embodiment, the computing device (100) can extract an audit log from a non-volatile storage in response to a post-audit request, etc. (510).

[0192] The computing device (100) can identify a commit package (or audit log) corresponding to a post-audit request and extract the audit log contained in the identified commit package. The computing device (100) can extract from the audit log a policy identifier used to generate a basis for judgment in a structured control schema area and a policy snapshot identifier that represents a specific version of the corresponding policy data by fixing it with an immutable hash value, etc. The computing device (100) can extract an execution context and / or execution plan representing the intrinsic intent of a past query from the extracted audit log.

[0193] For example, an execution context is a standardized execution context that removes noise—such as spacing, capitalization differences, and unnecessary metadata—from the source query sent by the client, specifying only the purpose of the query (e.g., "User A intends to delete Document B"). This can serve as input data to determine "exactly what was requested at the time" during a post-audit.

[0194] For example, a policy identifier can identify which of the security policies (or policy bundles) needs to be retrieved to perform an evaluation for a post-audit request. This can guide the version control repository to locate, for instance, a category called "Financial Data Access Rules."

[0195] For example, a policy snapshot identifier may refer to a value that uniquely identifies a specific, deterministic version of policy data (e.g., access control rules, thresholds, validation rules, etc.) actually applied at the time of determination for a query, or the state at that moment (snapshot). Combined with a policy identifier indicating the type of policy, this can be used as a factor to restore the past determination environment during post-audits. As a history identifier or version control indicator that immutably fixes and identifies the past state (configuration) of specific data or rules within the system, the policy snapshot identifier can function as trace information to accurately locate data at a specific point in time, even if the data changes over time. For example, a policy snapshot identifier may include a policy revision number or configuration management snapshot ID that distinguishes the update phase of a policy bundle, which groups multiple policy rules, or an authorization rule set. For example, a policy snapshot identifier may include a policy bundle hash generated by passing the entire source text of the policy data applied at the time of determination through a one-way cryptographic hash function (e.g., SHA-256).

[0196] The computing device (100) can restore the original policy data using the extracted identifiers (520).

[0197] The computing device (100) may request data retrieval by transmitting the extracted identifiers to a separate version control repository (e.g., a policy version control repository). This repository is a system that preserves information and / or change history related to policies, and depending on the implementation mode, it may be included in the computing device (100), included in a non-volatile repository, or be a separate repository logically or physically separated from both. The version control repository may store the policy state at a specific point in time in an immutable, fixed form as a snapshot. As an example, not a limitation, the version control repository may be implemented as a Git repository, AWS S3, or a version control server.

[0198] The computing device (100) can use the extracted identifiers to obtain the rules and thresholds of the original policy data that were actually applied at the time of query determination from a separate version control system or immutable policy repository.

[0199] The version control repository can return a policy bundle at a point in time that matches the corresponding snapshot identifier (e.g., access control documents in JSON format and RBAC / ABAC rule sets, etc.). The computing device (100) can perform a hash operation on the returned policy bundle and compare the result with the policy snapshot identifier to determine whether the restored policy data is the original policy data that has not been tampered with.

[0200] The computing device (100) can recalculate the judgment result using the execution plan or execution context of the query and the restored original policy data (530).

[0201] The computing device (100) can re-execute a decision engine logic that determines whether to allow, reject, or hold a query by using only the execution plan or execution context of the query (i.e., the past query corresponding to the post-audit request) recorded together in the audit log and the restored original policy data as input values. For example, the computing device (100) can evaluate the target object and action type specified in the execution context (or execution plan) by sequentially substituting them into the rules and thresholds of the restored policy data. This process may represent a process of replaying the same logical operations performed in the past. Based on the replay results, the computing device (100) can generate a new decision state (e.g., allow, reject, hold), a decision reason code, and a subsequent action flag. The set of results derived by recalculating post-incidentally in this way can be expressed as a recalculated decision result.

[0202] The computing device (100) can verify consistency by comparing the recalculated judgment result with the judgment result of the audit log (540).

[0203] The computing device (100) can obtain the original determination result from the audit log extracted from the non-volatile storage (i.e., the audit log corresponding to the post-audit request).

[0204] The computing device (100) can compare the result value newly calculated through judgment re-execution with the original judgment result (and judgment reason code) permanently recorded in the past audit log. This comparison may mean, for example, comparing the original judgment result and the recalculated judgment result in bit units or in normalized string units. This comparison may mean, for example, comparing each field of the original judgment result and the recalculated judgment result (e.g., fields such as judgment result and judgment basis) in bit units or in normalized string units. If the two results match, the computing device (100) determines that the integrity and consistency at the time of judgment were not compromised, and if they do not match, it determines that there was tampering in the past logging process or that the policy snapshot was arbitrarily compromised, resulting in a state of consistency violation.

[0205] This policy snapshot-based deterministic consistency verification method provides the technical effect of fundamentally blocking attempts by system administrators or hackers to justify the execution of illegal externalities by arbitrarily changing security policies after the fact or rolling back to a previous version. Furthermore, this method eliminates ambiguity in audit records caused by time discrepancies that may occur in distributed computing environments, and enhances the transparency and execution integrity of computing systems by guaranteeing external cross-reference and perfect post-hoc recall to regulatory bodies or external auditors.

[0206] FIG. 6 illustrates an exemplary methodology for processing a gate state change event according to one embodiment of the present disclosure.

[0207] The computing device (100) can perform the process of generating a subsequent audit log based on a gate state change event and transmitting the generated subsequent audit log to a non-volatile storage. The computing device (100) can perform the steps of FIG. 6 to perform subsequent processing operations to verify the physical trajectory of a query execution retrospectively.

[0208] The computing device (100) can perform state transitions of execution gates (610).

[0209] For example, the computing device (100) may control the state transition of an execution gate (e.g., a state transition from closed to open) within a single atomic control window in response to a successful validation event of a commit response. The control or execution of the state transition includes the action of transitioning the execution gate from the closed state to the open state to allow the actual execution of the query, or the action of returning the execution gate from the open state to the closed state in response to a query execution termination event. The computing device (100) may force such transition operations to be safely processed by mutual exclusion operations without interference from other threads.

[0210] The computing device (100) can detect state change events of the execution gate (620).

[0211] For example, in conjunction with the transition operation of step 610, the computing device (100) can detect and detect a gate state change event including the point in time when the execution gate transitions to an open state or a closed state. When the computing device (100) transitions the execution gate according to the success of validating the commit response, it can detect the gate state change event through a hardware interrupt or an event hook of the operating system when a state change occurs within a single atomic control window.

[0212] In the present disclosure, a state change event may refer to a traffic control signal indicating a point in time when a control barrier within the system changes its open or closed state physically or logically. A state change event may function as a system trigger that records the point in time and / or direction in which the passage of traffic is switched at an external execution boundary between the computing device (100) and an external entity. For example, a state change event may function as execution receipt data that is detected in response to a state change occurring within a single atomic control window, including the direction of the transition (e.g., whether to switch from closed to open, or from open to closed), an applied atomic control window identifier, and a timestamp (e.g., in milliseconds).

[0213] The computing device (100) can generate a subsequent audit log by combining information and state change events from the original audit log (630).

[0214] The computing device (100) can generate a subsequent audit log by cryptographically binding information corresponding to the original audit log or commit package stored in local memory with the gate state change event detected in step 620.

[0215] The information in the source audit log is information that can uniquely identify specific transactions that were processed and approved in the past. The information in the source audit log may represent relational database keys or reference values ​​that link the source commit package, which is persistently written to non-volatile storage, with the execution event that occurred today. For example, the information in the source audit log may include a log record identifier, a schema record identifier, and / or a unique cryptographic fingerprint value that was used during the validation phase of the commit response, all of which were assigned from non-volatile storage when the source audit log was stored.

[0216] Subsequent audit logs are state history data added to track the start and end of a single transaction. Subsequent audit logs can function as execution receipt records issued to retrospectively verify whether a pre-approved query actually passed through the outer execution boundary and reached the target object. The subsequent audit log may be a packet that combines the information of the original audit log (e.g., fingerprint value) with currently detected gate transition time and transition direction data (e.g., concatenation), serializes it according to a predefined normalization rule, and appends it as a hash chain link structure containing the hash value of the previous audit log.

[0217] For example, the generation of a subsequent audit log may be a process of issuing execution receipts that record the actual opening and closing actions of external execution boundaries. The generation of a subsequent audit log may be a procedure that stores records of the time when the gate was opened after successful verification and the time when the gate was closed again after the external effect was triggered, concatenated with the original commit package.

[0218] The computing device (100) can mathematically determine which query judgment result caused the gate opening by retrieving information from the original audit log representing the original identification information and performing a binding operation that combines it with the current state change event.

[0219] The computing device (100) can send a storage request for a subsequent audit log to a non-volatile storage (640).

[0220] The computing device (100) transmits a storage request through the network section so that the generated subsequent audit log is written to the non-volatile storage. In this step, the transmission operation can be processed in a background non-blocking manner using an asynchronous transmission queue, for example, so as not to delay the actual query execution process in which the original control signal of the query flows to the target object. The non-volatile storage can sequentially write the received subsequent audit log to the next order of the same table or hash chain associated with the original commit package.

[0221] The binding and transmission mechanism of subsequent audit logs according to the embodiment of FIG. 6 provides the effect of chronologically verifying not only the fact that a query was approved but also when and until when the gate was actually open for query execution. This mechanism can clearly identify cases where "approval was completed but the query control signal was not actually transmitted" during post-audit, which may occur in the event of a system failure or network disconnection. This mechanism can achieve a performance improvement effect by visualizing the physical operation history of the execution gate and providing a security audit trajectory.

[0222] A technique according to one embodiment of the present disclosure provides the effect of blocking ghost writes at the source. The actual execution of a query (e.g., opening of an execution gate) is performed with the durable recording of an audit log (e.g., recording in a non-volatile storage) as a prerequisite. Accordingly, even if a server goes down or a system failure occurs, security gaps in the form where "execution such as a transfer is completed even though no record remains" can be physically or structurally blocked.

[0223] A technique according to one embodiment of the present disclosure provides zero trust and atomic control (ACW)-based hacking and bypass prevention effects. By comparing a cryptographic fingerprint value generated by the computing device (100) itself with a commit response returned by a non-volatile storage locally, fake success signals or man-in-the-middle attacks on the network can be efficiently detected. In particular, since the validation success event and the transition operation of the gate are processed atomically within a single atomic control window (ACW) and the reuse of the fingerprint value is controlled, duplicate execution by replay attacks that intercept and repeatedly transmit a valid response can be efficiently blocked.

[0224] A technique according to one embodiment of the present disclosure allows the access attempt and context to be securely recorded in a non-volatile storage not only when the judgment result is allowed, but also when it is denied or pending. This can preserve the history of unauthorized hacking attempts and provide a dynamic response environment that can securely resume control over pending queries through additional approval or external triggers.

[0225] A technique according to one embodiment of the present disclosure significantly improves the integrity of post-audits through the guarantee of deterministic reproducibility. A computing device (100) includes a policy snapshot identifier and basis reference data at the time of determination within a structured control schema and constructs and records a cryptographic hash chain with the previous audit log. This allows for the identification of whether the order of the audit log has been tampered with during a post-audit, and enables the construction of a highly reliable audit trail that can mathematically re-prove that the query execution was carried out by legitimate rules by completely restoring the policy environment at the time of determination.

[0226] A technique according to one embodiment of the present disclosure provides the effect of preventing catastrophic accidents when applied to various industrial sectors requiring high risk or high reliability (e.g., finance, defense and safety systems, generative AI, etc.) based on the guarantee of execution integrity. For example, a technique according to one embodiment of the present disclosure can prevent financial accidents by not approving the transaction itself if the commit of the record is not reliably verified during fund transfers or payments. For example, a technique according to one embodiment of the present disclosure can prevent catastrophic malfunctions during drone operation or weapon system control by allowing physical commands to be executed only after it is confirmed that the relevant command has been recorded through lawful procedures and policies. For example, a technique according to one embodiment of the present disclosure can prevent the external exposure of inappropriate responses at the source by verifying whether the judgment basis and record have been finalized before a Large Language Model (LLM) generates hallucinations or dangerous responses that output false information.

[0227] FIG. 7 illustrates an exemplary method for verifying the validity of a commit response and controlling an execution gate according to one embodiment of the present disclosure.

[0228] A computing device (100) according to one embodiment can verify the validity of a commit response through a hash chaining technique using a preceding fingerprint value in order to physically block tampering and omission of the order of the audit log.

[0229] The verification process using such hash chaining techniques can operate based on cryptographic integrity guarantee principles designed so that if even a single historical record is altered or deleted, the current verification fails in a chain reaction.

[0230] In order to actively verify the continuity of the chain, the computing device (100) can obtain audit logs and historical information generated from the local storage of the computing device (100) without relying on external storage. Depending on the implementation mode, the computing device (100) may also obtain audit logs and historical information from non-volatile storage or other external storage (e.g., a blockchain system).

[0231] The computing device (100) can configure a verification input value in response to a commit response (710).

[0232] The computing device (100) can extract from the received commit response the record metadata generated according to the storage of the audit log and the fingerprint value generated by the non-volatile storage. The computing device (100) combines the preceding fingerprint value obtained from the local storage and the obtained audit log (including the extracted record metadata if necessary) according to a predefined normalization rule to derive a combined result. As an example rather than a limitation, this can be expressed by the following mathematical formula. This combined result can be used as a verification input value.

[0233] Validation input = Canonical(Audit Log_n)||Record ID_n||Timestamp_n||H_{n-1}

[0234] The record ID and Timestamp_n are included in the record metadata, and H_{n-1} may represent a preceding fingerprint value. The preceding fingerprint value indicates a value included in the preceding commit response corresponding to a preceding audit log that was generated and validated prior to the audit log.

[0235] The computing device (100) can generate a reconstructed verification value using the verification input value (720).

[0236] The computing device (100) can recalculate a reference value that should be calculated when the non-volatile storage chain is properly connected, using the prepared combination result. The computing device (100) can generate a reconstructed verification value by applying a cryptographic transformation to the derived combination result.

[0237] The computing device (100) can perform multidimensional validation and cross-comparison using the reconstructed validation value and data from the commit response (730).

[0238] The computing device (100) can perform (multidimensional) verification of time, source, and / or data continuity based on locally calculated reconstructed verification values ​​and received data.

[0239] The computing device (100) can calculate the time difference between the time of receiving a query or the time of transmitting a storage request to record an audit log in a non-volatile storage and the time of recording the record metadata (or the time of receiving a commit response), and perform time information verification to block retransmission attacks caused by delayed responses by comparing this with a preset valid time window.

[0240] In one embodiment, time information verification may be a process of determining whether conditions regarding temporal validity are satisfied. Even if a commit response is received, if the commit response does not arrive within a threshold time after the request, the commit response may be determined to be invalid. For example, the computing device (100) may start a timer from the time it sends a save request or a request for a commit response, and may process a commit response received within the expiration period of the timer as a valid commit.

[0241] The computing device (100) can perform authentication information verification to verify the legitimacy of the source by determining whether the commit response includes integrity information or authentication information based on cryptographic transformations such as a specified encryption key.

[0242] The computing device (100) can compare a locally generated reconstructed validation value with a fingerprint value extracted from a commit response, for example, bit by bit. If the two values ​​match as a result of the comparison, it can be proven that the last physical record of the non-volatile storage matches the local state of the computing device (100) and that the hash chain has not been broken. On the other hand, if even a single bit does not match, the computing device (100) immediately detects that the chain has been destroyed because someone deleted or falsified past logs in the middle, and processes the validation as a failure.

[0243] A technique according to one embodiment of the present disclosure can determine the validity of a query response when physical durable storage conditions are satisfied, and thereby control the execution of the query. Physical durable storage conditions may mean a condition in which a physical write (e.g., fsync or flush) must be completed on a non-volatile medium (e.g., disk or SSD) where data is not lost even when the power is cut off, rather than a state where data is written only to memory (RAM). The non-volatile storage may withhold the transmission of a commit response after writing the log to an internal buffer until a disk synchronization command is successfully returned.

[0244] Additionally, the technique of the present disclosure may suspend the execution of a query until the condition is met that the audit log is propagated to a predetermined number of replica nodes, rather than a single node. For example, the computing device (100) may remain in a waiting state "until storage is confirmed in two or more nodes, which is a quorum of three replicas."

[0245] The computing device (100) can perform state update and execution gate control based on the validation result (740).

[0246] When validation is successfully completed, the computing device (100) updates the local state and permits physical execution for the smooth validation processing of subsequent queries. The computing device (100) can update the state by overwriting the fingerprint value that was successfully extracted and validated with a new preceding fingerprint value in the local storage. The computing device (100) can transition the execution gate to an open state and execute the actual external effect of the query.

[0247] FIG. 8 is a brief and general schematic diagram of an exemplary computing environment of a computing device (100) in which some embodiments of the present disclosure may be implemented.

[0248] Although the present disclosure has been described as generally being implementable by a computing device, those skilled in the art will understand that the present disclosure may be implemented in combination with computer-executable instructions and / or other program modules that can be executed on one or more computers, and / or as a combination of hardware and software.

[0249] Generally, a program module includes routines, programs, components, data structures, etc., that perform a specific task or implement a specific abstract data type. Furthermore, those skilled in the art will be well aware that the method of the present disclosure may be implemented in other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, as well as personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc. (each of which may be connected to and operated with one or more associated devices).

[0250] The embodiments described in this disclosure may also be implemented in a distributed computing environment in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0251] Computers typically include various computer-readable media. Any medium accessible by a computer may be a computer-readable medium, and such computer-readable media include volatile and non-volatile media, transitory and non-transitory media, and removable and non-removable media. By example, but not limiting, computer-readable media may include computer-readable storage media and computer-readable transmission media. Computer-readable storage media include volatile and non-volatile media, transitory and non-transitory media, and removable and non-removable media implemented by any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media include, but are not limited to, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD (digital video disk) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other medium that can be accessed by a computer and used to store desired information.

[0252] Computer-readable transmission media typically include all information transmission media that implement computer-readable instructions, data structures, program modules, or other data, etc., on a modulated data signal, such as a carrier wave or other transport mechanism. The term modulated data signal means a signal in which one or more of the characteristics of the signal are set or modified to encode information within the signal. By example, not limiting, computer-readable transmission media include wired media, such as wired networks or direct-wired connections, and wireless media, such as acoustic, RF, infrared, and other wireless media. Any combination of the media described above is also considered to be within the scope of computer-readable transmission media.

[0253] An exemplary environment (4100) for implementing various aspects of the present disclosure, including a computer (4102), is shown, wherein the computer (4102) includes a processing unit (4104), system memory (4106), and a system bus (4108). The system bus (4108) connects system components, including system memory (4106) (but not limited thereto), to the processing unit (4104). The processing unit (4104) may be any processor among various commercial processors. Dual processor and other multiprocessor architectures may also be used as the processing unit (4104).

[0254] The system bus (4108) may be any of several types of bus structures that can be additionally interconnected to a local bus using any of the memory bus, peripheral bus, and various commercial bus architectures. System memory (4106) includes read-only memory (ROM) (4110) and random access memory (RAM) (4112). The Basic Input / Output System (BIOS) is stored in non-volatile memory (4110), such as ROM, EPROM, EEPROM, etc., and this BIOS includes basic routines that help transfer information between components within the computer (4102) at times such as during startup. The RAM (4112) may also include high-speed RAM, such as static RAM, for caching data.

[0255] The computer (4102) also includes an internal and external hard disk drive (HDD) (4114) (e.g., EIDE, SATA)—hard disk drives (4114 and 4115) may also be configured for external use within a suitable chassis (not shown)—and a magnetic floppy disk drive (FDD) (4116) (e.g., for reading from or writing to a removable diskette (4118)), and an optical disk drive (4120) (e.g., for reading from a CD-ROM disk (4122) or reading from or writing to other high-capacity optical media such as a DVD). The hard disk drive (4114), the magnetic disk drive (4116), and the optical disk drive (4120) may each be connected to the system bus (4108) by a hard disk drive interface (4124), a magnetic disk drive interface (4126), and an optical drive interface (4128). The interface (4124) for implementing an external drive includes at least one or both of USB (Universal Serial Bus) and IEEE 1394 interface technologies.

[0256] These drives and associated computer-readable media provide non-volatile storage of data, data structures, computer-executable instructions, etc. In the case of a computer (4102), the drives and media correspond to storing any data in a suitable digital format. Although the description of computer-readable media above refers to HDDs, removable magnetic disks, and removable optical media such as CDs or DVDs, those skilled in the art will know that other types of computer-readable media, such as zip drives, magnetic cassettes, flash memory cards, cartridges, etc., may also be used in exemplary operating environments and that any of these media may contain computer-executable instructions for performing the methods of the present disclosure.

[0257] A number of program modules, including an operating system (4130), one or more application programs (4132), other program modules (4134), and program data (4136), may be stored in the drive and RAM (4112). All or part of the operating system, application, module, and / or data may also be cached in RAM (4112). It will be well known that the present disclosure may be implemented in various commercially available operating systems or combinations of operating systems.

[0258] The user can input commands and information into the computer (4102) through one or more wired / wireless input devices, such as a pointing device like a keyboard (4138) and a mouse (4140). Other input devices (not shown) may include a microphone, an IR remote control, a joystick, a game pad, a stylus pen, a touch screen, etc. These and other input devices are often connected to the processing unit (4104) via an input device interface (4142) connected to the system bus (4108), but may also be connected via other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0259] A monitor (4144) or other type of display device is also connected to the system bus (4108) via an interface such as a video adapter (4146). In addition to the monitor (4144), the computer generally includes other peripheral output devices (not shown), such as speakers, a printer, and so on.

[0260] The computer (4102) may operate in a networked environment using a logical connection to one or more remote computers, such as remote computer(s) (4148), via wired and / or wireless communication. The remote computer(s) (4148) may be a workstation, a computing device computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other conventional network node, and generally include many or all of the components described for the computer (4102), but for brevity, only the memory storage device (4150) is illustrated. The illustrated logical connection includes a wired / wireless connection to a local area network (LAN) (4152) and / or a larger network, e.g., a wide area network (WAN) (4154). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global computer network, e.g., the Internet.

[0261] When used in a LAN networking environment, the computer (4102) is connected to a local network (4152) via a wired and / or wireless communication network interface or adapter (4156). The adapter (4156) may facilitate wired or wireless communication to the LAN (4152), and the LAN (4152) may also include a wireless access point installed therein to communicate with the wireless adapter (4156). When used in a WAN networking environment, the computer (4102) may include a modem (4158), be connected to a communication computing device on the WAN (4154), or have other means of establishing communication through the WAN (4154), such as through the Internet. The modem (4158), which may be an internal or external and a wired or wireless device, is connected to the system bus (4108) via a serial port interface (4142). In a networked environment, the program modules described for the computer (4102) or parts thereof may be stored in a remote memory / storage device (4150). It will be well known that the illustrated network connection is exemplary and that other means of establishing a communication link between computers may be used.

[0262] The computer (4102) operates to communicate with any wireless device or object that is deployed and operated by wireless communication, for example, a printer, scanner, desktop and / or portable computer, PDA (portable data assistant), communication satellite, any equipment or place associated with a wireless detectable tag, and a telephone. This includes at least Wi-Fi and Bluetooth wireless technologies. Accordingly, the communication may be a predefined structure as in a conventional network, or simply ad hoc communication between at least two devices.

[0263] Wi-Fi (Wireless Fidelity) enables connectivity to the Internet and other sources without wires. Wi-Fi is a wireless technology, similar to a cell phone, that allows devices, such as computers, to transmit and receive data indoors and outdoors—that is, anywhere within the coverage area of ​​a base station. Wi-Fi networks use a wireless technology called IEEE 802.11 (a, b, g, etc.) to provide secure, reliable, and high-speed wireless connections. Wi-Fi can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 or Ethernet). Wi-Fi networks can operate in unlicensed 2.4 and 5 GHz wireless bands, for example, at data rates of 11 Mbps (802.11a) or 54 Mbps (802.11b), or in products that include both bands (dual band).

[0264] Those skilled in the art of the present disclosure will understand that information and signals may be represented using any various different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced in the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Claims

Claim 1 A method for controlling the execution of a query with a record-commit as a precondition, performed by a computing device, comprising: receiving a query from a client; calculating a judgment result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log including the judgment result; transmitting a storage request to record the audit log including the judgment result in a non-volatile storage, regardless of the value of the judgment result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; receiving a commit acknowledgment in response to the storage request, indicating that a commit package including at least the fingerprint value and the audit log has been recorded in a non-volatile storage; and verifying the validity of the commit acknowledgment by comparing a verification value reconstructed from the commit acknowledgment with the fingerprint value included in the commit acknowledgment. A method comprising the step of transitioning an execution gate from a closed state that blocks the execution of the query to an open state that allows the execution of the query in response to the case where the validation of the commit response is successful and the judgment result is allowed. Claim 2 A method according to claim 1, wherein the step of transitioning the execution gate comprises: transitioning the execution gate from the closed state to the open state in response to a successful verification event of the validity of the commit response, such that the successful verification event and the transition operation of the execution gate are processed as atomic operations within a single atomic control window (ACW). Claim 3 A method according to claim 1, further comprising the step of maintaining the execution gate in the closed state to block or suspend the execution of the query in response to a failure event of validating the commit response. Claim 4 A method according to claim 1, further comprising the step of transitioning the execution gate from the open state to the closed state in response to an execution termination event of the query after the execution gate has transitioned to the open state, such that the execution termination event and the transition operation of the execution gate are processed as atomic operations within a single atomic control window. Claim 5 In claim 1, the method wherein the commit package is generated by binding the audit log and the fingerprint value. Claim 6 A method according to claim 1, wherein the fingerprint value is generated by applying the cryptographic transformation to the audit log, the record identifier identifying the audit log, and the record time (time) of the audit log. Claim 7 A method according to claim 1, wherein the commit package is generated in response to a save request for writing the audit log to the non-volatile storage or a confirmation request for verifying whether the commit package containing the audit log has been permanently written to the non-volatile storage, and the commit package is generated by combining the determination result in the audit log, a record identifier identifying the audit log, the recording time of the audit log, a restoration rule for restoring the determination result in the audit log, and the fingerprint value. Claim 8 A method according to claim 1, wherein after a preset commit validity period has elapsed from the time of the request to save the audit log, the commit response is not received or the commit response is determined to be invalid. Claim 9 The method according to claim 1, wherein the step of generating the audit log comprises: generating a judgment basis including a judgment result including allow, deny, and hold for the execution of the query based on at least one of the query and the execution plan and the policy data, and an evidence reference used to generate the judgment result; and configuring a structured control schema including the judgment result and the judgment basis; and generating the audit log for which storage to be requested in the non-volatile storage is requested by concatenating a plurality of field values ​​extracted from the structured control schema. Claim 10 In claim 9, regardless of whether the judgment result includes any one of allow, reject, or pending, the steps of: (a) transmitting a save request to save a commit package including at least the judgment result and the fingerprint value to a non-volatile storage; (b) committing the save by receiving a commit response in response to the save request; and (c) verifying the validity of the commit response by comparing the fingerprint value included in the commit response with a fingerprint value reconstructed based on the commit package, wherein (i) when the judgment result includes allow and a successful verification event of the validity of the commit response occurs, it is determined to transition the execution gate to an open state and allow the execution of the query; (ii) when the judgment result includes reject, regardless of whether a successful verification event of the validity of the commit response occurs, it is determined to keep the execution gate in a closed state and reject the execution of the query; and (iii) when the judgment result includes pending, regardless of whether a successful verification event of the validity of the commit response occurs, it is determined to keep the execution gate in a closed state and allow the execution of the query A method in which a decision on the above query is re-executed in response to the reception of an additional approval event or an external trigger signal thereafter. Claim 11 In claim 9, the structured control schema comprises: a policy identifier identifying policy data used to generate the basis for determination; and a policy snapshot identifier indicating a specific version of the policy data. Claim 12 A method comprising, in addition to the step of verifying the consistency of the judgment result included in the audit log based on the policy identifier and the policy snapshot identifier in claim 11. Claim 13 In claim 12, the step of verifying consistency comprises: a step of restoring policy data corresponding to the policy snapshot identifier and the policy identifier; and a step of re-performing a determination for the query using the restored policy data. Claim 14 The method of claim 1, wherein the step of verifying the validity of the commit response comprises: extracting from the commit response, record metadata generated according to the storage of the audit log and the fingerprint value, and obtaining the generated audit log from the local storage of the computing device; combining the obtained audit log and the extracted record metadata and applying the cryptographic transformation to the combined result to generate the reconstructed verification value; and comparing the reconstructed verification value with the extracted fingerprint value. Claim 15 The method according to claim 14, wherein the step of verifying the validity of the commit response further comprises at least one of: a step of comparing the time difference between the time of receiving the query or the time of transmitting a storage request for writing the audit log to the non-volatile storage and the time of recording the record metadata with a preset validity time window; and a step of determining whether the commit response includes integrity information or authentication information based on cryptographic transformation. Claim 16 The method according to claim 1, wherein the fingerprint value is generated by applying the cryptographic transformation to the audit log and the preceding fingerprint value corresponding to the preceding audit log that was generated prior to the audit log and whose validity has been verified, and the step of verifying the validity of the commit response comprises: extracting the fingerprint value from the commit response and obtaining the preceding fingerprint value included in the preceding commit response corresponding to the preceding audit log and the generated audit log from the local storage of the computing device; combining the obtained preceding fingerprint value and the obtained audit log and generating the reconstructed verification value by applying the cryptographic transformation to the combined result; and comparing the reconstructed verification value with the extracted fingerprint value; and, if the preceding audit log does not exist, a predefined initial value is used. Claim 17 A method according to claim 1, wherein the step of transferring the execution gate is to prevent duplicate transfer of the execution gate according to the same commit response by performing a process to prevent the reuse of the commit response or the fingerprint value used in the step of verifying the validity of the commit response. Claim 18 A method according to claim 1, wherein the execution gate functions as an external execution boundary, which is a boundary through which a control signal for the execution of the query is transmitted to an external entity physically or logically separated from the computing device, wherein the open state is a state in which the control signal can pass through the external execution boundary and reach the external entity, and the closed state is a state in which the control signal is blocked at the external execution boundary. Claim 19 The method of claim 1 further comprises: detecting a gate state change event including at least one of the time when the execution gate transitions to the open state and the time when it transitions to the closed state; and generating a subsequent audit log including information corresponding to the audit log or the commit package and the gate state change event, and transmitting the subsequent audit log to the non-volatile storage. Claim 20 The method of claim 1, wherein the step of generating the audit log comprises: a step of obtaining an execution plan for processing the query in response to the receipt of the query; and a step of generating the audit log including a determination result related to the execution of the execution plan based on policy data collected based on the execution plan; and the step of obtaining the execution plan comprises: a step of parsing the received query to identify a target object accessed or modified by the query and an operation type for the target object; and a step of generating an execution context in which the target object and the operation type are sorted or formatted according to predefined rules - the policy data is collected based on the execution context -. Claim 21 A method according to claim 1, wherein the policy data can be updated without changing or restarting the execution code of the computing device, and the updated policy data is applied to a query received after the update. Claim 22 A computer program stored on a computer-readable storage medium, wherein the computer program, when executed by a computing device, causes the computing device to perform a method for controlling the execution of a query with a record commit as a precondition, the method comprising: receiving a query from a client; calculating a judgment result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log including the judgment result; transmitting a storage request to cause the audit log including the judgment result to be written to a non-volatile storage, regardless of the value of the judgment result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; receiving a commit acknowledgment in response to the storage request, indicating that a commit package including at least the fingerprint value and the audit log has been written to a non-volatile storage; and determining the validity of the commit acknowledgment by comparing a verification value reconstructed from the commit acknowledgment with the fingerprint value included in the commit acknowledgment. A computer program stored on a computer-readable storage medium, comprising: a step of verifying; and a step of transitioning an execution gate from a closed state that blocks the execution of the query to an open state that allows the execution of the query in response to the case where the validation of the commit response is successful and the judgment result is allowed. Claim 23 A computing device comprising at least one processor for controlling the execution of a query with a record commit as a precondition, wherein the at least one processor comprises: receiving a query from a client; calculating a judgment result related to the execution of the query using policy data collected based on at least one of the query and an execution plan for executing the query, and generating an audit log including the judgment result; transmitting a storage request to record the audit log including the judgment result in a non-volatile storage, regardless of the value of the judgment result, and including a fingerprint value generated based on applying a cryptographic transformation to the audit log in conjunction with the storage request; receiving a commit acknowledgment in response to the storage request, indicating that a commit package including at least the fingerprint value and the audit log has been recorded in a non-volatile storage; and verifying the validity of the commit acknowledgment by comparing a verification value reconstructed from the commit acknowledgment with the fingerprint value included in the commit acknowledgment. A computing device that performs the step of transitioning an execution gate from a closed state that blocks the execution of the query to an open state that allows the execution of the query in response to the case where the validation of the commit response is successful and the judgment result is allowed.

Images