Systems, methods, and computer program products for dynamically controlling access based on unique access criteria
By receiving access requests and system log data, using the processor to provide temporary credentials, and dynamically controlling access permissions based on multi-factor authentication and secure shell protocols, the problems of misuse and resource waste in privileged user access management are solved, thereby improving the security and management efficiency of the production system.
Patent Information
- Application Number
- CN202480036997.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-06-06
- Filing Date
- 2024-06-06
- Publication Date
- 2026-01-23
AI Technical Summary
Existing software systems are unable to effectively monitor and manage privileged user access permissions, leading to potential misuse and waste of resources, especially in production-grade software systems where it is difficult to determine whether users are performing appropriate actions.
By receiving access requests and data associated with system records, the processor provides temporary credentials, dynamically controls access permissions based on multi-factor authentication and secure shell protocols, and terminates access upon expiration of the authorization period or completion of the action.
It enables dynamic control over privileged user access, reduces misuse and resource waste, and improves the security and management efficiency of the production system.
Smart Images

Figure CN121399604A_ABST
Abstract
Description
Cross Reference to Related Applications
[0001] This application claims priority to U.S. Provisional Patent Application 63 / 471,296, filed June 6, 2023, the disclosure of which is hereby incorporated by reference in its entirety. TECHNICAL FIELD
[0002] The present disclosure relates generally to authorized access to production systems, and in some non-limiting embodiments or aspects, to systems, methods, and computer program products for dynamically controlling access based on unique access criteria. BACKGROUND
[0003] Some software systems (e.g., production-level software systems) can require maintenance and / or updates to be performed by privileged users (e.g., users with a range of access permissions and responsible for development and / or maintenance of the software system). In some cases, a privileged user (e.g., a privileged user using a client device) can require authorization to a software system that executes (e.g., runs) a software application (e.g., a software application used by customers) at a production level via one or more devices (e.g., servers) of the software system. For example, a privileged user can receive authorization to access the software system from an administrative user (e.g., a user with a range of access to the software system that exceeds the range of access of the privileged user), granting the privileged user an authorized session on the software system (e.g., on a server of the software system). Alternatively, a privileged user can initially exist as a non-privileged user (e.g., a user without access to the software system), and the non-privileged user can receive login credentials (e.g., a username and password) to use in order to authenticate as a privileged user for authorized access to the software system. As long as the privileged user does not terminate the authorized session (e.g., a login session), the privileged user can maintain access to the software system.
[0004] However, software systems that allow privileged users to maintain access to the software system (e.g., unlimited access, temporary access, etc.) can not monitor whether the privileged user is performing actions that can be appropriate and / or acceptable for the software system while the privileged user is accessing the software system through the authorized session. At times, a privileged user can misuse the authorized access by performing actions that are outside of a range of actions that can be defined prior to the privileged user being granted the authorized access. Alternatively, a privileged user can obtain authorized access to the software system in order to perform maintenance and / or updates without intending to misuse the authorized access. The privileged user can perform unintended actions during the course of performing the maintenance and / or updates. It can become difficult and / or can require a large amount of resources to maintain and monitor the range of authorized access (e.g., permissions) for each privileged user (e.g., among a plurality of privileged users).
[0005] As an example, when a user initiates an interactive session on a Linux server using a service account from a Bastion jump-server, a network security team cannot efficiently and effectively determine the user initiating the session. SUMMARY
[0006] Accordingly, improved systems, methods, and computer program products are provided for dynamically controlling access based on unique access criteria.
[0007] According to non-limiting embodiments or aspects, a computer-implemented method is provided that includes receiving, with at least one processor, an access request associated with a username of a user and data associated with a system record, the data associated with the system record including a change reason and a change identifier; providing, with the at least one processor, a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorizing, with the at least one processor, the user to access at least one target system associated with the access request based on the temporary credential; determining, with the at least one processor, that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminating, with the at least one processor, access to the at least one target system based on determining that the user is no longer authorized to access a production server.
[0008] In non-limiting embodiments or aspects, the method further includes authenticating, with the at least one processor, the user using multi-factor authentication based on the username of the user. In non-limiting embodiments or aspects, the temporary credential is based on a Secure Shell protocol. In non-limiting embodiments or aspects, the method further includes prompting, with the at least one processor, the user to provide the data associated with the system record. In non-limiting embodiments or aspects, the method further includes verifying, with the at least one processor, the data associated with the system record using an initial system record stored in a data repository, wherein verifying the data associated with the system record includes determining that the data associated with the system record matches primary data associated with the initial system record stored in the data repository; and correlating the data associated with the system record with the username of the user based on the primary data associated with the initial system record.
[0009] In non-limiting embodiments or aspects, wherein providing the temporary credential to the user comprises determining a duration associated with the system record based on the change reason; and generating the temporary credential comprising the duration associated with the system record, the duration associated with the system record representing a time for which the temporary credential is valid. In non-limiting embodiments or aspects, wherein determining that the user is no longer authorized to access the at least one target system comprises determining that the duration associated with the system record has expired. In non-limiting embodiments or aspects, wherein determining that the user is no longer authorized to access the at least one target system comprises detecting that the user has completed an action associated with the change reason and the change identifier. In non-limiting embodiments or aspects, the temporary credential comprises one or more user role accounts. In non-limiting embodiments or aspects, wherein authorizing the user to access the at least one target system comprises receiving a request for a connection from the user, the request comprising the temporary credential; determining that the one or more user role accounts of the temporary credential are authorized to access the production server; and initiating a communication session based on the one or more user role accounts, the communication session configured to transmit one or more messages between a user device of the user and the production server. In non-limiting embodiments or aspects, the method further comprises recording the communication session to produce a recorded communication session; associating the recorded communication session with the username of the user that transmitted the request for the connection; and storing the recorded communication session and the username of the user in a data repository. In non-limiting embodiments or aspects, the communication session is based on a Secure Shell protocol.
[0010] In non-limiting embodiments or aspects, the temporary credential includes a key identifier, the key identifier including the username of the user and the change identifier. In non-limiting embodiments or aspects, the method further includes: recording, with the at least one processor, the key identifier, an authorized time of the user, and a username of at least one of the one or more user role accounts to a log record; storing, with the at least one processor, the key identifier in a cache memory of the at least one target system; and retrieving, with the at least one processor, the username of the user of the key identifier from the cache memory of the production server based on a process identifier associated with the at least one target system. In non-limiting embodiments or aspects, wherein authorizing the user to access the at least one target system includes: receiving a request to connect, the request including the temporary credential; retrieving master data associated with an initial system record based on the change identifier of the key identifier matching a record identifier of the initial system record stored in a data store; and correlating the at least one target system to a change reason based on an identifier associated with the at least one target system and the change reason of the master data associated with the initial system record. In non-limiting embodiments or aspects, the data store receives the master data in real-time from a configuration management database. In non-limiting embodiments or aspects, the method further includes generating the temporary credential by digitally signing a user key with a root private key. In non-limiting embodiments or aspects, the method further includes: generating the root private key and a corresponding root public key in response to receiving a change request; and distributing the root public key to a subset of production servers including the production server.
[0011] According to non-limiting embodiments or aspects, a system is provided, the system including: at least one processor configured to: receive an access request associated with a username of a user and data associated with a system record, the data associated with the system record including a change reason and a change identifier; provide a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorize the user to access at least one target system associated with the access request based on the temporary credential; determine that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminate access to the at least one target system based on determining that the user is no longer authorized to access a production server.
[0012] In non-limiting embodiments or aspects, the at least one processor is further configured to authenticate the user based on the username of the user using multi-factor authentication. In non-limiting embodiments or aspects, the temporary credential is based on a Secure Shell protocol. In non-limiting embodiments or aspects, the at least one processor is further configured to prompt the user to provide the data associated with the system record. In non-limiting embodiments or aspects, the at least one processor is further configured to verify the data associated with the system record against an initial system record stored in a data repository, wherein verifying the data associated with the system record includes determining that the data associated with the system record matches primary data associated with the initial system record stored in the data repository, and correlating the data associated with the system record with the username of the user based on the primary data associated with the initial system record. In non-limiting embodiments or aspects, wherein providing the temporary credential to the user includes determining a duration associated with the system record based on the change reason, and generating the temporary credential including the duration associated with the system record, the duration associated with the system record representing a time for which the temporary credential is valid.
[0013] In non-limiting embodiments or aspects, wherein determining that the user is no longer authorized to access the at least one target system includes determining that the duration associated with the system record has expired. In non-limiting embodiments or aspects, wherein determining that the user is no longer authorized to access the at least one target system includes detecting that the user has completed an action associated with the change reason and the change identifier. In non-limiting embodiments or aspects, the temporary credential includes one or more user role accounts. In non-limiting embodiments or aspects, wherein authorizing the user to access the at least one target system includes receiving a request for a connection from the user, the request including the temporary credential, determining that the one or more user role accounts of the temporary credential are authorized to access the production server, and initiating a communication session based on the one or more user role accounts, the communication session configured to transmit one or more messages between a user device of the user and the production server. In non-limiting embodiments or aspects, the at least one processor is further configured to record the communication session to produce a recorded communication session, associate the recorded communication session with the username of the user that transmitted the request for the connection, and store the recorded communication session and the username of the user in a data repository. In non-limiting embodiments or aspects, the communication session is based on a Secure Shell protocol.
[0014] In non-limiting embodiments or aspects, the temporary credential includes a key identifier, the key identifier including the username of the user and the change identifier. In non-limiting embodiments or aspects, the at least one processor is further configured to: record the key identifier, an authorized time of the user, and a username of at least one of the one or more user role accounts to a log record; store the key identifier in a cache memory of the at least one target system; and retrieve the username of the user of the key identifier from the cache memory of the production server based on a process identifier associated with the at least one target system. In non-limiting embodiments or aspects, wherein authorizing the user to access the at least one target system includes: receiving a request to connect, the request including the temporary credential; retrieving master data associated with an initial system record based on the change identifier of the key identifier matching a record identifier of the initial system record stored in a data store; and correlating the at least one target system to a change reason based on an identifier associated with the at least one target system and the master data associated with the initial system record. In non-limiting embodiments or aspects, the data store receives the master data in real-time from a configuration management database. In non-limiting embodiments or aspects, the at least one processor is further configured to generate the temporary credential by digitally signing a user key with a root private key. In non-limiting embodiments or aspects, the at least one processor is further configured to: generate the root private key and a corresponding root public key in response to receiving a change request; and distribute the root public key to a subset of production servers including the production server.
[0015] According to non-limiting embodiments or aspects, a computer program product is provided that includes at least one non-transitory computer-readable medium that contains program instructions, the program instructions, when executed by at least one processor, cause the at least one processor to: receive an access request and data associated with a system record, the access request associated with a username of a user, the data associated with the system record including a change reason and a change identifier; provide a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorize the user to access at least one target system associated with the access request based on the temporary credential; determine that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminate access to the at least one target system based on determining that the user is no longer authorized to access a production server.
[0016] Other non-limiting embodiments or aspects will be set forth in the following numbered clauses: Clause 1 : A computer-implemented method comprising: receiving, with at least one processor, an access request and data associated with a system record, the access request associated with a username of a user, the data associated with the system record including a change reason and a change identifier; providing, with the at least one processor, a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorizing, with the at least one processor, the user to access at least one target system based on the temporary credential; determining, with the at least one processor, that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminating, with the at least one processor, access to the at least one target system for which the user is authorized based on determining that the user is no longer authorized to access the at least one target system.
[0017] Clause 2: The computer-implemented method of clause 1, further comprising authenticating, with the at least one processor, the user using multi-factor authentication based on the username of the user.
[0018] Clause 3: The computer-implemented method of clause 1 or 2, wherein the temporary credential is based on a Secure Shell protocol.
[0019] Clause 4: The computer-implemented method of any of clauses 1 to 3, further comprising prompting, with the at least one processor, the user to provide the data associated with the system record.
[0020] Clause 5: The computer-implemented method of any of clauses 1 to 4, further comprising verifying, with the at least one processor, the data associated with the system record using an initial system record stored in a data store, wherein verifying the data associated with the system record comprises: determining that the data associated with the system record matches primary data associated with the initial system record stored in the data store; and correlating the data associated with the system record with the username of the user based on the primary data associated with the initial system record.
[0021] Clause 6: The computer-implemented method of any of clauses 1 to 5, wherein providing the temporary credential to the user comprises: determining a duration associated with the system record based on the change reason; and generating the temporary credential including the duration associated with the system record, wherein the duration associated with the system record represents a time for which the temporary credential is valid.
[0022] Clause 7: The computer-implemented method of any of clauses 1-6, wherein determining that the user is no longer authorized to access the at least one target system comprises determining that the duration of time associated with the system record has expired.
[0023] Clause 8: The computer-implemented method of any of clauses 1-7, wherein determining that the user is no longer authorized to access the at least one target system comprises detecting that the user has completed an action associated with the change reason and the change identifier.
[0024] Clause 9: The computer-implemented method of any of clauses 1-8, wherein the temporary credential comprises one or more user role accounts.
[0025] Clause 10: The computer-implemented method of any of clauses 1-9, wherein authorizing the user to access the at least one target system comprises receiving a request for a connection from the user, the request comprising the temporary credential, determining that the one or more user role accounts of the temporary credential are authorized to access the at least one target system, and initiating a communication session based on the one or more user role accounts, wherein the communication session is configured to transmit one or more messages between a user device of the user and the production server.
[0026] Clause 11: The computer-implemented method of any of clauses 1-10, further comprising recording the communication session to generate a recorded communication session, associating the recorded communication session with the username of the user that transmitted the request for the connection, and storing the recorded communication session and the username of the user in a data store.
[0027] Clause 12: The computer-implemented method of any of clauses 1-11, wherein the communication session is based on a Secure Shell protocol.
[0028] Clause 13: The computer-implemented method of any of clauses 1-12, wherein the temporary credential comprises a key identifier, the key identifier comprising the username of the user and the change identifier.
[0029] Clause 14: The computer-implemented method of any of clauses 1-13, further comprising: recording, with the at least one processor, the key identifier, an authorized time of the user, and a username of at least one of the one or more user role accounts to a log record; storing, with the at least one processor, the key identifier in a cache memory of the production server; and retrieving, with the at least one processor, the username of the user of the key identifier from the cache memory of the production server based on a process identifier associated with the production server.
[0030] Clause 15: The computer-implemented method of any of clauses 1-14, wherein authorizing the user to access the production server comprises: receiving a request to connect, the request including the temporary credential; matching, based on the change identifier of the key identifier, a record identifier of an initial system record stored in a data store, retrieving primary data associated with the initial system record; and correlating the production server with a change reason based on an identifier associated with the at least one target system and the primary data associated with the initial system record.
[0031] Clause 16: The computer-implemented method of any of clauses 1-15, wherein the data store receives the primary data in real-time from a configuration management database.
[0032] Clause 17: The computer-implemented method of any of clauses 1-16, further comprising generating the temporary credential by digitally signing a user key with a root private key.
[0033] Clause 18: The computer-implemented method of any of clauses 1-17, further comprising: generating the root private key and a corresponding root public key in response to receiving a change request; and distributing the root public key to a subset of production servers including the production server.
[0034] Clause 19: A system comprising: at least one processor configured to: receive an access request and data associated with a system record, the access request associated with a username of a user, the data associated with the system record including a change reason and a change identifier; provide a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorize the user to access at least one target system associated with the access request based on the temporary credential; determine that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminate access to the at least one target system based on determining that the user is no longer authorized to access a production server.
[0035] Clause 20: The system of clause 19, wherein the at least one processor is further configured to authenticate the user using multi-factor authentication based on the username of the user.
[0036] Clause 21 : The system of clause 19 or 20, wherein the temporary credential is based on a Secure Shell protocol.
[0037] Clause 22: The system of any of clauses 19-21, wherein the at least one processor is further configured to prompt the user to provide the data associated with the system record.
[0038] Clause 23: The system of any of clauses 19-22, wherein the at least one processor is further configured to verify the data associated with the system record using an initial system record stored in a data store, wherein verifying the data associated with the system record comprises determining that the data associated with the system record matches primary data associated with the initial system record stored in the data store, and correlating the data associated with the system record with the username of the user based on the primary data associated with the initial system record.
[0039] Clause 24: The system of any of clauses 19-23, wherein providing the temporary credential to the user comprises determining a duration associated with the system record based on the change reason, and generating the temporary credential including the duration associated with the system record, wherein the duration associated with the system record represents a time for which the temporary credential is valid.
[0040] Clause 25: The system of any of clauses 19-24, wherein determining that the user is no longer authorized to access the at least one target system comprises determining that the duration associated with the system record has expired.
[0041] Clause 26: The system of any of clauses 19-25, wherein determining that the user is no longer authorized to access the at least one target system comprises detecting that the user has completed an action associated with the change reason and the change identifier.
[0042] Clause 27: The system of any of clauses 19-26, wherein the temporary credential comprises one or more user role accounts.
[0043] Clause 28: The system of any of clauses 19-27, wherein authorizing the user to access the at least one target system comprises: receiving a request for a connection from the user, the request including the temporary credential; determining that the one or more user role accounts of the temporary credential are authorized to access the production server; and initiating a communication session based on the one or more user role accounts, wherein the communication session is configured to transmit one or more messages between a user device of the user and the production server.
[0044] Clause 29: The system of any of clauses 19-28, wherein the at least one processor is further configured to: record the communication session to generate a recorded communication session; associate the recorded communication session with the username of the user that transmitted the request for the connection; and store the recorded communication session and the username of the user in a data store.
[0045] Clause 30: The system of any of clauses 19-29, wherein the communication session is based on a Secure Shell protocol.
[0046] Clause 31 : The system of any of clauses 19-30, wherein the temporary credential includes a key identifier, the key identifier including the username of the user and the change identifier.
[0047] Clause 32: The system of any of clauses 19-31, wherein the at least one processor is further configured to: record the key identifier, an authorized time of the user, and a username of at least one user role account of the one or more user role accounts to a log record; store the key identifier in a cache of the at least one target system; and retrieve the username of the user of the key identifier from the cache of the production server based on a process identifier associated with the at least one target system.
[0048] Clause 33: The system of any of clauses 19-32, wherein authorizing the user to access the at least one target system comprises: receiving a request for a connection, the request including the temporary credential; retrieving primary data associated with an initial system record based on the change identifier of the key identifier matching a record identifier of the initial system record stored in a data store; and correlating the at least one target system with a change reason based on an identifier associated with the at least one target system and the primary data associated with the initial system record.
[0049] Clause 34: The system of any of clauses 19-33, wherein the data repository receives the master data from a configuration management database in real-time.
[0050] Clause 35: The system of any of clauses 19-34, wherein the at least one processor is further configured to generate the temporary credential by digitally signing a user key with a root private key.
[0051] Clause 36: The system of any of clauses 19-35, wherein the at least one processor is further configured to: generate the root private key and a corresponding root public key in response to receiving a change request; and distribute the root public key to a subset of production servers including the production server.
[0052] Clause 37: A computer program product comprising at least one non-transitory computer- readable medium including program instructions, the program instructions, when executed by at least one processor, cause the at least one processor to: receive an access request and data associated with a system record, the access request associated with a username of a user, the data associated with the system record including a change reason and a change identifier; provide a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorize the user to access at least one target system associated with the access request based on the temporary credential; determine that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminate access to the at least one target system based on determining that the user is no longer authorized to access a production server.
[0053] These and other features and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a definition of the limits of the disclosed subject matter. BRIEF DESCRIPTION OF DRAWINGS
[0054] Additional advantages and details of implementation will now be explained with reference to the non-limiting exemplary embodiments illustrated in the drawings, in which: Figure 1 is a schematic illustration of a system for dynamically controlling access based on unique access criteria in accordance with some non-limiting embodiments or aspects; Figure 2 is a flowchart of a process for dynamically controlling access based on unique access criteria in accordance with some non-limiting embodiments or aspects; Figure 3 is a diagram of an example environment in which methods, systems, and / or computer program products described herein can be implemented in accordance with some non-limiting embodiments or aspects; and Figure 4 is a diagram of example components of one or more devices of Figure 1 and / or Figure 3 in accordance with some non-limiting embodiments or aspects. DETAILED DESCRIPTION
[0055] For the following description, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and derivatives thereof shall relate to the orientation of the embodiments in the drawings. However, it is to be understood that the disclosure can assume various alternative variations and sequence of steps. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary and non-limiting embodiments or aspects of the disclosed subject matter. As such, the specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.
[0056] Some non-limiting embodiments or aspects can be described herein in connection with a threshold. As used herein, satisfying a threshold can refer to a value that is greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.
[0057] No aspect, component, element, structure, act, step, function, instruction, etc. described herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the article "a" is intended to include one or more items, and can be used interchangeably with "one or more" and "at least one." Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, the terms "has," "have," "having," or the like are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "based, at least in part, on" unless explicitly stated otherwise. Additionally, references to "based on" actions taken in response to conditions can refer to actions taken "in response to" or "in reaction to" the conditions. For example, in some non-limiting embodiments or aspects, the phrases "based on" and "in response to" can refer to actions taken "in response to" or "in reaction to" an electronic device, such as a computing device, processor, or the like, automatically triggering a particular operation.
[0058] As used herein, the term "communication" can refer to receipt, receipt of, transmission, transfer, provision, and / or the like of data (e.g., information, signals, messages, instructions, commands, and / or the like). That one unit (e.g., a device, a system, a component of a device or system, a combination thereof, and / or the like) is in communication with another unit means that the one unit is capable of directly or indirectly receiving a signal from and / or transmitting a signal to the other unit. This can include a direct or indirect connection (e.g., direct communication connection, indirect communication connection, and / or the like) that is wired and / or wireless in nature. Additionally, two units can be in communication with each other even though the information transmitted can be modified, processed, relayed, and / or routed between the first and second unit. For example, a first unit can be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit can be in communication with a second unit if at least one intermediary unit processes information received from the first unit and communicates processed information to the second unit. In some non-limiting embodiments or aspects, a message can refer to a network packet (e.g., data packet, and / or the like) that includes data. It will be appreciated that there can be many other arrangements.
[0059] As used herein, the term "computing device" can refer to one or more electronic devices configured to process data. In some examples, a computing device can include the necessary components, such as a processor, a display, memory, an input device, a network interface, and / or the like, to receive, process, and output data. A computing device can be a mobile device. For example, a mobile device can include a cellular phone (e.g., a smart phone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, and / or the like), a personal digital assistant (PDA), and / or other similar devices. A computing device can also be a desktop computer or other form of non-mobile computer.
[0060] As used herein, the term "server" can refer to or include one or more computing devices operated by or facilitating communication and processing of a plurality of parties in a network environment, such as the Internet, although it will be appreciated that communication can be facilitated through one or more public or private network environments and that there can be various other arrangements. Moreover, a plurality of computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, and / or the like) in direct or indirect communication in a network environment can constitute a "system."
[0061] As used herein, the term“system” can refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of these computing devices, etc.). As used herein, references to“devices,”“servers,”“processors,” and the like can refer to the same device, server, or processor that was recited as performing a previous step or function, a different device, server, or processor, and / or a combination of devices, servers, and / or processors. For example, as used in the specification and claims, a first device, first server, or first processor recited as performing a first step or a first function can refer to the same or different device, server, or processor recited as performing a second step or a second function.
[0062] As used herein, the term“acquirer institution” can refer to an entity licensed and / or approved by a transaction service provider to initiate transactions (e.g., payment transactions) using payment devices associated with the transaction service provider. Transactions that an acquirer institution can initiate can include payment transactions (e.g., purchases, original credit transaction (OCT), account funding transactions (AFT), etc.). In some non-limiting embodiments or aspects, an acquirer institution can be a financial institution, such as a bank. As used herein, the term“acquirer system” can refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer executing one or more software applications.
[0063] As used herein, the term“issuer institution” can refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution can provide a customer with an account identifier, such as a PAN, that uniquely identifies one or more accounts associated with the customer. The account identifier can be embodied on a portable financial device, such as a physical financial instrument (e.g., a payment card), and / or can be electronic and used for electronic payments. The term“issuer system” refers to one or more computer devices operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system can include one or more authorization servers for authorizing transactions.
[0064] As used herein, the term“merchant” can refer to a person or entity that provides goods and / or services or access to goods and / or services to a customer based on a transaction, such as a payment transaction. The term“merchant” or“merchant system” can also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications.
[0065] As used herein, the term "payment device" can refer to an electronic payment device, a portable financial device (e.g., a payment card such as a credit or debit card), a gift card, a smart card, a smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or fob, a radio frequency identification (RFID) transponder, a retailer discount or loyalty card, a cellular phone, a mobile wallet application, a PDA, a pager, a security card, a computing device, a door access card, a wireless terminal, a transponder, and / or the like. In some non-limiting embodiments or aspects, a payment device can include volatile or non-volatile memory for storing information (e.g., an account identifier, an account holder name, and / or the like).
[0066] As used herein, the terms "client" and "client device" can refer to one or more client-side devices or systems (e.g., one or more computing devices remote from a transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). For example, a "client device" can refer to one or more POS devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, and / or the like. In some non-limiting embodiments or aspects, a client device can be an electronic device configured to communicate with one or more networks and initiate or facilitate a transaction. For example, a client device can include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, and / or the like), PDAs, and / or the like. Further, a "client" can also refer to an entity (e.g., a merchant, an acquirer, and / or the like) that owns, utilizes, and / or operates a client device to initiate a transaction (e.g., to initiate a transaction with a transaction service provider).
[0067] As used herein, the term "transaction service provider" can refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment guarantees through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider can include a payment network such as Visa®, MasterCard®, American Express®, Discover®, and / or the like, or any other entity that processes transactions. The term "transaction processing system" can refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing server can include one or more processors and, in some non-limiting embodiments or aspects, can be operated by or on behalf of a transaction service provider.
[0068] Non-limiting embodiments or aspects of the disclosed subject matter relate to systems, methods, and computer program products for authorizing access to computing systems, including but not limited to dynamically controlling access based on unique access criteria. Non-limiting embodiments or aspects of the disclosed subject matter can authorize a user (e.g., a privileged user) to access one or more target systems (e.g., production systems, production servers, and / or other systems within the scope of a change request, including but not limited to accessing a protected software application executing on a production system and / or production server) associated with a change request. Non-limiting embodiments or aspects of the disclosed subject matter can control (e.g., customize, dynamically change, etc.) the user's authorization based on a plurality of factors. For example, non-limiting embodiments or aspects of the disclosed subject matter can authorize a user to access a target system, such as a production server, for a predetermined duration (e.g., a time window). Non-limiting embodiments or aspects of the disclosed subject matter can terminate the access authorized to the user based on detecting that the user has completed an action (e.g., an expected action, a documented action, a logged action, etc.) on the production server (e.g., an application executing on the production server). Additionally, non-limiting embodiments or aspects of the disclosed subject matter can determine (e.g., track, log, etc.) a user's username (e.g., corresponding to the user) that the user uses (e.g., the user logs in) when the user is authorized to access the production server. Non-limiting embodiments or aspects of the disclosed subject matter can validate the user's authorization to access the production server against data (e.g., change control data, data associated with a change request (CRQ), etc.) associated with a change control management system.
[0069] Non-limiting embodiments or aspects of the disclosed subject matter can grant users real-time access to a target system without requiring the user to have specific login information associated with a privileged account and / or administrative account. Additionally, once a user is granted access to a target system, non-limiting embodiments or aspects of the disclosed subject matter can detect when the user performs authorized and / or unauthorized actions, and non-limiting embodiments or aspects can terminate the user's authorization to access the target system in real-time (e.g., within seconds or milliseconds, such that the user is substantially unaware) when the user performs an unauthorized action. Non-limiting embodiments or aspects of the disclosed subject matter can automatically approve and provide a user's authorization to access a target system by utilizing a data store that stores a plurality of data associated with a change control management system (e.g., a plurality of data associated with change requests, etc.). In this way, non-limiting embodiments or aspects of the disclosed subject matter can reconcile the provision of a user's authorization to access a target system with the requirements to change and / or remediate an event associated with the target system (e.g., control the provision of a user's authorization to access a target system), such that the user is only authorized to access the system (e.g., portions of a production system, software applications of a production system, etc.) within the scope of the requirements to change and / or remediate an event. Thus, non-limiting embodiments or aspects of the disclosed subject matter can prevent unauthorized changes and / or tampering with a target system, even for users that can be authorized to access the system for legitimate purposes. Accordingly, non-limiting embodiments or aspects of the disclosed subject matter can dynamically control a user's authorization and / or access to a target system based on unique criteria that outline the amount of access a user can need to perform a particular action and / or task. Non-limiting embodiments or aspects also provide traceability by mapping the activities of an authorization subject to a user in real-time (e.g., as the user is making changes), even when multiple users are concurrently active with the same authorization subject (e.g., a shared subject entity) on the same server. Non-limiting embodiments or aspects described herein can be used to provide privileged access to UNIX-based systems, but it should be appreciated that non-limiting embodiments can be used to provide access to various types of systems.
[0070] Referring now to Figure 1 , a system 100 for dynamically controlling access based on unique access criteria in accordance with some non-limiting embodiments or aspects is shown. The system 100 can include an access authorization system 102, a server 104, a user device 106, and a data store 108.
[0071] The access authorization system 102 can include a computing device, such as a server (e.g., a single server), a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the access authorization system 102 can include a processor and / or a memory, as described herein. In some non-limiting embodiments or aspects, the access authorization system 102 can include one or more software instructions (e.g., one or more software applications) executed on a server (e.g., a single server), a group of servers, a computing device (e.g., a single computing device), a group of computing devices, and / or other similar devices. In some non-limiting embodiments or aspects, the access authorization system 102 can be configured to communicate with the server 104, the user device 106, and / or the data repository 108. In some non-limiting embodiments or aspects, the access authorization system 102 can communicate with the server 104, the user device 106, and / or the data repository 108 such that the access authorization system 102 is separate from the server 104, the user device 106, and / or the data repository 108. In some non-limiting embodiments or aspects, the server 104, the user device 106, and / or the data repository 108 can be implemented by the access authorization system 102 (e.g., can be part of the access authorization system).
[0072] The server 104 can include at least one server, computing device, and / or at least one processor (e.g., a multi-core processor), such as a central processing unit (CPU), an accelerated processing unit (APU), a graphics processing unit (GPU), a microprocessor, and / or the like. In some non-limiting embodiments or aspects, the server 104 can be programmed to perform one or more steps of the methods described herein. In some non-limiting embodiments or aspects, the server 104 can communicate with one or more user devices 106. In some non-limiting embodiments or aspects, the server 104 can be configured to receive information from and / or communicate (e.g., transmit) information to the access authorization system 102, one or more user devices 106, one or more other servers 104, and / or the data repository 108. In some non-limiting embodiments or aspects, the server 104 can execute an instance of the access authorization system 102 (e.g., an instance of a software application). In some non-limiting embodiments or aspects, the server 104 can be implemented by the access authorization system 102 (e.g., can be part of the access authorization system). In other examples, the server 104 can communicate with the access authorization system 102 such that the server 104 is separate from the access authorization system 102.
[0073] In non-limiting embodiments or aspects, the user device 106 can include a computing device configured to communicate with the access authorization system 102 and / or the server 104 via a communication network. For example, the user device 106 can comprise a computing device such as a desktop computer, a portable computer (e.g., a tablet computer, a laptop computer, etc.), a mobile device (e.g., a cellular phone, a smart phone, a personal digital assistant, a wearable device, etc.), and / or other similar devices. In some non-limiting embodiments or aspects, the user device 106 can be associated with a user (e.g., an individual operating the user device 106). In some non-limiting embodiments or aspects, the user device 106 can be implemented by the access authorization system 102 (e.g., can be part of the access authorization system). In some examples, the user device 106 can be in communication with the access authorization system 102 and / or the server 104 such that the user device 106 is separate from the access authorization system 102 and / or the server 104.
[0074] In non-limiting embodiments or aspects, the data repository 108 can include a computing device (e.g., a database device) configured to communicate with the access authorization system 102 and / or the server 104 via a communication network. For example, the data repository 108 can include a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the data repository 108 can be associated with one or more computing devices that provide an interface such that a user (e.g., an administrative user) can interact with the data repository 108 via the one or more computing devices. The data repository 108 can be in communication with the access authorization system 102 and / or the server 104 such that the data repository 108 is separate from the access authorization system 102 and / or the server 104. In other examples, the data repository 108 can be implemented by the access authorization system 102, the server 104, and / or the user device 106 (e.g., can be part of the access authorization system, the server, and / or the user device).
[0075] Figure 1 The number and arrangement of systems and devices shown in FIG. 1 are provided as an example. There can be additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, and / or differently arranged systems and / or devices than those shown in FIG. 1. Additionally or alternatively, each of the Figure 1 There can be additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, and / or differently arranged systems and / or devices than those shown in FIG. 1. Additionally or alternatively, each of the Figure 1 two or more systems or devices shown in FIG. 1 can be implemented within a single system and / or device, or Figure 1A single system or device shown in the figures can be implemented as multiple, distributed systems or devices. Additionally or alternatively, a group of systems (e.g., one or more systems) or a group of devices (e.g., one or more devices) of system 100 can perform one or more functions described as being performed by another group of systems or another group of devices of system 100.
[0076] Referring now to Figure 2 , a process 200 for dynamically controlling access based on unique access criteria is shown in accordance with some non-limiting embodiments or aspects. Figure 2 The steps shown in the figures are for exemplary purposes only. It should be appreciated that additional, fewer, different, and / or different order steps can be used in non-limiting embodiments or aspects.
[0077] As Figure 2 shown in , at step 202, process 200 can include receiving an access request from a user. For example, access authorization system 102 can receive an access request and data associated with a system record from a user. In non-limiting embodiments, the request is for credentials to any servers and / or systems within the scope of an event or change request (e.g., as indicated by a change identifier and / or an event identifier). For example, the event or change request can map to one or more systems that host and / or manage one or more applications, development environments, tools, operating systems, etc. In some non-limiting embodiments or aspects, the access request can be for Secure Shell (SSH) certificates (e.g., for authentication based on SSH certificates) and / or another type of public / private key pair authentication mode. In some non-limiting embodiments or aspects, the access request can be associated with a username of the user that transmitted the access request to access authorization system 102. In some non-limiting embodiments or aspects, the data associated with the system record can include a change reason and a change identifier. In some non-limiting embodiments or aspects, access authorization system 102 can prompt the user to provide the data associated with the system record, and access authorization can receive the data associated with the system record from user device 106 associated with the user.
[0078] In some non-limiting embodiments or aspects, access authorization system 102 may use initial system records to verify data associated with system records. In some non-limiting embodiments or aspects, multiple initial system records may be stored in data repository 108. Multiple initial system records may comprise initial system records. In some non-limiting embodiments or aspects, access authorization system 102 may verify data associated with system records by determining that data associated with a system record matches master data associated with an initial system record stored in data repository 108. In some non-limiting embodiments or aspects, access authorization system 102 may verify data associated with system records by associating data associated with system records with a user's username based on master data associated with the initial system record.
[0079] like Figure 2 As shown, at step 204, process 200 may include providing credentials to the user. For example, access authorization system 102 may provide temporary credentials (e.g., credentials valid for a limited time and / or for limited purposes) to the user (e.g., the user transmitting the access request) based on authenticated user and data associated with system records. In some non-limiting embodiments or aspects, temporary credentials may be based on the Secure Shell protocol. For example, access authorization system 102 may use temporary credentials to authorize a session (e.g., a communication session) between a server and a client device based on the Secure Shell protocol. In some non-limiting embodiments or aspects, temporary credentials may contain one or more user role accounts (e.g., a list of one or more user role accounts associated with the temporary credentials).
[0080] In non-limiting embodiments or aspects, the credentials are generated by a credential service (e.g., associated with a Certificate Authority (CA)). As an example, this credential service generates an SSH certificate by digitally signing the user's public key using the CA's private key. The public key corresponding to the CA's private key can be distributed to the target production system. In a non-limiting embodiment, the credential service may include a front-end client and a back-end service, wherein the front-end client is on the user's device and prompts the user for valid changes and / or events and forwards the credential request to the back-end service, and wherein the back-end service receives the request and verifies whether the changes and / or events are valid. The SSH certificate used as a temporary credential may be associated with and / or contain a list of authorized entities (e.g., authorized management entities), such that a user with the SSH certificate can only impersonate or act as those listed authorized entities.
[0081] In some non-limiting embodiments or aspects, the access authorization system 102 can authenticate a user using multi-factor authentication. In some non-limiting embodiments or aspects, the access authorization system 102 can authenticate a user based on a username of the user. In some non-limiting embodiments or aspects, the temporary credential can include a key identifier (e.g., a key identifier associated with the temporary credential). In some non-limiting embodiments or aspects, the key identifier can include a username of the user and a change identifier (e.g., the username of the user concatenated with the change identifier). However, it should be appreciated that the key identifier can include any unique identifier, such as a string, etc.
[0082] In non-limiting embodiments, the temporary credential is used to open a session, and the temporary credential can no longer be involved as the session progresses. The session can be terminated at the same time the credential is set to expire.
[0083] In some non-limiting embodiments or aspects, the access authorization system 102 can record (e.g., record and / or track in log records stored on a recording medium, such as a data storage device) at least one of a key identifier, an authorized time of a user, and a username of at least one user role account of one or more user role accounts. In some non-limiting embodiments or aspects, the access authorization system 102 can store the key identifier in a cache memory of a production server and / or other system. In some non-limiting embodiments or aspects, the access authorization system 102 can retrieve a username of a user of a key identifier (e.g., included in the key identifier) from the cache memory of a production server and / or other system based on a process identifier associated with the production server and / or other system.
[0084] In some non-limiting embodiments or aspects, the access authorization system 102 can provide a temporary credential to a user, the temporary credential including a duration associated with a system record. For example, the access authorization system 102 can determine the duration associated with the system record based on a change reason. In some non-limiting embodiments or aspects, the access authorization system 102 can assign the duration to the temporary credential. In some non-limiting embodiments or aspects, the access authorization system 102 can generate the temporary credential including the duration associated with the system record. In some non-limiting embodiments or aspects, the duration associated with the system record can represent a time for which the temporary credential is valid. In non-limiting embodiments, the access authorization system 102 can provide a temporary credential that is unique to the user and to a jump-server and / or bastion host used to secure a port in a public network.
[0085] As Figure 2As shown in the middle, at step 206, process 200 can include granting the user access to the target system (e.g., the production system and / or other system). For example, in some non-limiting embodiments or aspects, access authorization system 102 can grant the user access to the production server and / or other system based on the temporary credential (e.g., based on access authorization system 102 accepting the temporary credential as a valid credential). In some non-limiting embodiments or aspects, access authorization system 102 can grant the user access to the production server and / or other system by receiving a request to connect from the user. In some non-limiting embodiments or aspects, the request can include the temporary credential. In some non-limiting embodiments or aspects, access authorization system 102 can grant the user access to the production server and / or other system by determining that one or more user role accounts of the temporary credential (e.g., a list of one or more user role accounts associated with the temporary credential) are authorized to access the production server and / or other system.
[0086] In some non-limiting embodiments or aspects, access authorization system 102 can grant the user access to the production server and / or other system by receiving a request to connect. In some non-limiting embodiments or aspects, the request can include the temporary credential. In some non-limiting embodiments or aspects, access authorization system 102 can grant the user access to the production server and / or other system by retrieving master data associated with the initial system record stored in data store 108. Access authorization system 102 can retrieve the master data based on a change identifier (e.g., included in the key identifier) of the key identifier matching a record identifier (e.g., an initial system record identifier, such as an integer) of the initial system record. In some non-limiting embodiments or aspects, access authorization system 102 can grant the user access to the production server and / or other system by correlating the production server and / or other system with a change reason based on an identifier associated with the production server and / or other system and the change reason of the master data associated with the initial system record. In some non-limiting embodiments or aspects, data store 108 can receive the master data (e.g., master data associated with a plurality of initial system records) from a configuration management database (e.g., ServiceNow®) in real-time.
[0087] In some non-limiting embodiments or aspects, access authorization system 102 can initiate a communication session based on the one or more user role accounts (e.g., during and / or after access authorization system 102 grants the user access to the production server and / or other system). In some non-limiting embodiments or aspects, the communication session can be configured to transmit one or more messages between a user device of the user and the production server and / or other system. In some non-limiting embodiments or aspects, the communication session can be based on a secure shell protocol.
[0088] In non-limiting embodiments, an authorized principal command on each target host is configured to resolve whether a given authorized principal is allowed to access the target host. Each login using a temporary credential automatically triggers the authorized principal command such that a list of authorized principals is returned and can be checked against the authorized principal in the temporary credential. If there is no match, the authentication is denied. The authorized principal command can access the incoming credential details, e.g., key identifier, and can use the key identifier to query, in real-time (e.g., within seconds or milliseconds, such that the user is substantially unaware), a data structure containing the scope of change and / or event requests to determine whether the scope contains the current server / host. In response to determining that the scope contains the current server / host, a list of authorized principals can be returned by the authorized principal command. Otherwise, the command can return an empty authorized principal, thereby denying authorization.
[0089] In some non-limiting embodiments or aspects, the access authorization system 102 can record the communication session to generate a recorded communication session. In some non-limiting embodiments or aspects, the access authorization system 102 can associate the recorded communication session with a username of the user that transmitted the request to connect. In some non-limiting embodiments or aspects, the access authorization system 102 can store the recorded communication session and the username of the user in the data store 108. For example, the access authorization system 102 can store the recorded communication session and the username of the user associated with the recorded communication session such that the recorded communication session and the username of the user are associated in the data store 108.
[0090] As shown in Figure 2 At step 208, the process 200 can include determining that the user is not authorized to access the target system and / or other systems, as shown in
[0091] As shown in Figure 2As shown in the middle, at step 210, process 200 can include terminating access to the target systems (e.g., terminating user access to the target systems, terminating access previously granted to the user, etc.). For example, in some non-limiting embodiments or aspects, access authorization system 102 can terminate access to the production servers and / or other systems that the user is authorized for (e.g., the user’s access) based on determining that the user is not authorized to access the production servers and / or other systems.
[0092] In non-limiting embodiments or aspects, in addition to the temporary credentials issued to the user (e.g., SSH certificates), the CA public keys (e.g., CA public keys that can be distributed to the target systems as an initial setup step) can also be temporary. For example, the credential service can generate a temporary public / private key pair (e.g., a “CA root key”) in response to a change request and distribute the temporary CA root public key to only the target systems (e.g., hosts, production servers, and / or other systems) that are within the scope of the change request. For example, the list of servers that can apply the change (e.g., production systems or hosts) is typically a small subset of all servers within the final change scope (e.g., only servers in one data center can be within the scope of a particular change request, such that if an error occurs, the service can be provided by servers in other data centers). In some examples, changes can be made to one data center at a time to roll out the final change across the system.
[0093] In such examples, the temporary credentials generated for the user can be signed with a CA root private key that corresponds to the CA root public key. With such an arrangement, the temporary credentials (e.g., SSH certificates, etc.) provided to the user will only be valid for accessing production systems or hosts that are within the scope of the change request. This provides a mechanism to ensure that any user performing the change does not extend the scope of the change to production systems or hosts that are not approved for the change. This eliminates a potential security vector and avoids accidental disruptions.
[0094] In non-limiting embodiments, unauthorized lateral access can be prevented and detected. For example, each successful SSH connection (e.g., port 22, etc.) from any production system (production host) can be monitored by a script configured to extract information such as source user, source port, destination host, destination port, etc. The information can be logged (e.g., in a sales status hybrid drive (SSHD), etc.). In this way, SSH client data (e.g., timestamp, target host / server, source host, port, user identifier, etc.) can be correlated with logged data using, as an example, timestamp, source column, port, and target server / host to identify when a user logged into which monitored service identifier and from which source server to which target server. Both data sources can then be input into a monitoring and alerting system. Alerts can be input into a data lake (e.g., via Hadoop, etc.) and processed by one or more anomaly detection algorithms (e.g., machine learning algorithms, etc.). Monitoring and alerting can prevent and detect lateral access even without microsegmentation.
[0095] The non-limiting embodiments described herein can be used to seamlessly control user access to production systems with approved changes or effective event windows by leveraging an enterprise change management system in substantially real-time (e.g., within seconds or milliseconds such that users are substantially unaware). This improves security by seamlessly automating integration of complex systems, improves user productivity, and provides frictionless production access when needed.
[0096] Reference is now made to Figure 3 FIG. 1 shows a non-limiting embodiment or aspect of an example environment 100 in which systems, products, and / or methods as described herein can be implemented. As Figure 3As shown, environment 300 can include transaction service provider system 302, issuer system 304, customer device 306, merchant system 308, acquirer system 310, and communication network 312. In some non-limiting embodiments or aspects, each of access authorization system 102, server 104, user device 106, and / or data store 108 can be implemented by (e.g., can be part of) transaction service provider system 302. In some non-limiting embodiments or aspects, at least one of each of access authorization system 102, server 104, user device 106, and / or data store 108 can be implemented by (e.g., can be part of) another system, another device, another set of systems, or another set of devices that is separate from or includes transaction service provider system 302 (e.g., issuer system 304, merchant system 308, acquirer system 310, etc.).
[0097] Transaction service provider system 302 can include one or more devices capable of receiving information from and / or transmitting information to issuer system 304, customer device 306, merchant system 308, and / or acquirer system 310 via communication network 312. For example, transaction service provider system 302 can include a computing device, such as a server (e.g., a transaction processing server, etc.), a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, transaction service provider system 302 can be associated with a transaction service provider as described herein. In some non-limiting embodiments or aspects, transaction service provider system 302 can be in communication with a data storage device (e.g., data store 108), which can be local or remote to transaction service provider system 302. In some non-limiting embodiments or aspects, transaction service provider system 302 can be capable of receiving information from, storing information in, transmitting information to, or searching information stored in the data storage device.
[0098] The issuer system 304 can include one or more devices capable of receiving information from and / or transmitting information to the transaction service provider system 302, the customer device 306, the merchant system 308, and / or the acquirer system 310 via the communication network 312. For example, the issuer system 304 can include a computing device, such as a server, a group of servers, and / or other similar devices. In some non-limiting embodiments or aspects, the issuer system 304 can be associated with an issuer institution described herein. For example, the issuer system 304 can be associated with an issuer institution that issues a credit account, a debit account, a credit card, a debit card, and / or the like to a user associated with the customer device 306.
[0099] The customer device 306 can include one or more devices capable of receiving information from and / or transmitting information to the transaction service provider system 302, the issuer system 304, the merchant system 308, and / or the acquirer system 310 via the communication network 312. Additionally or alternatively, each customer device 306 can include a device capable of receiving information from and / or transmitting information to other customer devices 306 via the communication network 312, another network (e.g., an ad hoc network, a local network, a private network, a virtual private network, and / or the like), and / or any other suitable communication technique. For example, the customer device 306 can include a client device, and / or the like. In some non-limiting embodiments or aspects, the customer device 306 can or can not be capable of receiving information via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like) (e.g., from the merchant system 308 or from another customer device 306) and / or transmitting information via a short-range wireless communication connection (e.g., to the merchant system 308).
[0100] Merchant system 308 can include one or more devices capable of receiving information from and / or transmitting information to transaction service provider system 302, issuer system 304, customer device 306, and / or acquirer system 310 via communication network 312. Merchant system 308 can also include devices capable of receiving information from customer device 306 via communication network 312, a communication connection with customer device 306 (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, etc.), and / or the like, and / or transmitting information to customer device 306 via communication network 312, a communication connection, and / or the like. In some non-limiting embodiments or aspects, merchant system 308 can include a computing device, e.g., a server, a group of servers, a client device, a group of client devices, and / or other similar devices. In some non-limiting embodiments or aspects, merchant system 308 can be associated with a merchant as described herein. In some non-limiting embodiments or aspects, merchant system 308 can include one or more client devices. For example, merchant system 308 can include a client device that allows a merchant to transmit information to transaction service provider system 302. In some non-limiting embodiments or aspects, merchant system 308 can include one or more devices, e.g., a computer, a computer system, and / or a peripheral device, that can be used by a merchant to conduct transactions with a user.
[0101] Acquirer system 310 can include one or more devices capable of receiving information from and / or transmitting information to transaction service provider system 302, issuer system 304, customer device 306, and / or merchant system 308 via communication network 312. For example, acquirer system 310 can include a computing device, a server, a group of servers, and / or the like. In some non-limiting embodiments or aspects, acquirer system 310 can be associated with an acquirer as described herein.
[0102] Communication network 312 can include one or more wired and / or wireless networks. For example, communication network 312 can include a cellular network (e.g., a long-term evolution (LTE®) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a
[0103] The number and arrangement of systems, devices, and / or networks shown Figure 3 There can be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown. For example, a single system, device, and / or network can implement one or more of the systems, devices, and / or networks shown. Similarly, a single system, device, and / or network can implement one or more of the components shown in the systems, devices, and / or networks. Figure 3 There can be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown. For example, a single system, device, and / or network can implement one or more of the systems, devices, and / or networks shown. Similarly, a single system, device, and / or network can implement one or more of the components shown in the systems, devices, and / or networks. Figure 3 There can be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown. For example, a single system, device, and / or network can implement one or more of the systems, devices, and / or networks shown. Similarly, a single system, device, and / or network can implement one or more of the components shown in the systems, devices, and / or networks. Figure 3 There can be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown. For example, a single system, device, and / or network can implement one or more of the systems, devices, and / or networks shown. Similarly, a single system, device, and / or network can implement one or more of the components shown in the systems, devices, and / or networks.
[0104] Referring now to the drawings, and more particularly to FIG. 9, a diagram showing example components of a device 900, in accordance with non-limiting embodiments or aspects, is shown. By way of example, the device 900 can correspond to at least one of the access authorization system 102, the server 104, the user device 106, and / or the data repository 108 in the environment 100, and / or at least one of the transaction service provider system 302, the issuer system 304, the customer device 306, the merchant system 308, and / or the acquirer system 310 in the environment 300. In some non-limiting embodiments or aspects, such a system or device in the environment 100 or 300 can include at least one device 900 and / or at least one component of the device 900. The number and arrangement of components shown in the device 900 are provided as an example. In some non-limiting embodiments or aspects, the device 900 can include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, a group of components (e.g., one or more components) of the device 900 can perform one or more functions described as being performed by another group of components of the device 900. Figure 4 Figure 1 Figure 3 Figure 1 or Figure 3 Figure 4 The number and arrangement of components shown in the device 900 are provided as an example. In some non-limiting embodiments or aspects, the device 900 can include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, a group of components (e.g., one or more components) of the device 900 can perform one or more functions described as being performed by another group of components of the device 900. Figure 4 The number and arrangement of components shown in the device 900 are provided as an example. In some non-limiting embodiments or aspects, the device 900 can include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, a group of components (e.g., one or more components) of the device 900 can perform one or more functions described as being performed by another group of components of the device 900.
[0105] As Figure 4 As shown in the example of FIG. 9, the device 900 can include a bus 902, a processor 904, a memory 906, a storage component 908, an input component 910, an output component 912, and a communication interface 914. The bus 902 can include a component that permits communication among the components of the device 900. In some non-limiting embodiments or aspects, the processor 904 can be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 904 can include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.). The memory 906 can include a random access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage (e.g., a flash memory, a magnetic storage, an optical storage, etc.) that stores information and / or instructions for use by the processor 904. In some non-limiting embodiments or aspects, the memory 906 can be the same as or similar to the data store 108.
[0106] With continued reference to Figure 4 , the storage component 908 can store information and / or software related to the operation and use of the device 900. For example, the storage component 908 can include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.) and / or another type of computer readable medium. In some non-limiting embodiments or aspects, the storage component 908 can be the same as or similar to the data store 108. The input component 910 can include a component that permits the device 900 to receive information, such as through a user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally, or alternatively, the input component 910 can include a sensor (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.) for sensing information. The output component 912 can include a component that provides output information from the device 900 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). The communication interface 914 can include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the device 900 to communicate with other devices, such as through a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 914 can permit the device 900 to receive information from another device and / or provide information to another device. For example, the communication interface 914 can include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, etc.
[0107] The device 900 can perform one or more processes described herein. The device 900 can perform these processes based on processor 904 executing software instructions stored by a computer-readable medium, such as memory 906 and / or storage component 908. A computer-readable medium can include any non-transitory memory. A memory includes a memory space located within a single physical storage device or a memory space that extends across multiple physical storage devices. The software instructions can be read into the memory 906 and / or storage component 908 from another computer-readable medium or from another device via communications interface 914. When executed, the software instructions stored in the memory 906 and / or storage component 908 can cause the processor 904 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry can be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software. As used herein, the term “configured to” can refer to an arrangement of software, devices, and / or hardware used to perform and / or implement one or more functions (e.g., acts, processes, process steps, etc.). For example, a “processor configured to” can refer to a processor executing software instructions (e.g., program code) that cause the processor to perform one or more functions.
[0108] While embodiments have been described in detail, it should be understood that the description is for illustrative purposes only and that modifications and alterations are possible within the scope of the present disclosure. For example, it is understood that one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect, as much as is possible.
Claims
1. A computer-implemented method comprising: receiving, with at least one processor, an access request associated with a username of a user and data associated with a system record, the data associated with the system record including a change reason and a change identifier; providing, with the at least one processor, a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorizing, with the at least one processor, the user to access at least one target system associated with the access request based on the temporary credential; determining, with the at least one processor, that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminating, with the at least one processor, access to the at least one target system based on determining that the user is no longer authorized to access a production server.
2. The computer-implemented method of claim 1, further comprising: authenticating, with the at least one processor, the user using multi-factor authentication based on the username of the user.
3. The computer-implemented method of claim 1, wherein the temporary credential is based on a Secure Shell protocol.
4. The computer-implemented method of claim 1, further comprising: prompting, with the at least one processor, the user to provide the data associated with the system record.
5. The computer-implemented method of claim 1, further comprising: verifying, with the at least one processor, the data associated with the system record using an initial system record stored in a data store, wherein verifying the data associated with the system record comprises: determining that the data associated with the system record matches primary data associated with the initial system record stored in the data store; and relating the data associated with the system record to the username of the user based on the primary data associated with the initial system record.
6. The computer-implemented method of claim 1, wherein providing the temporary credential to the user comprises: determining a duration associated with the system record based on the change reason; and generating the temporary credential including the duration associated with the system record, wherein the duration associated with the system record represents a time for which the temporary credential is valid.
7. The computer-implemented method of claim 6, wherein determining that the user is no longer authorized to access the at least one target system comprises: determining that the duration associated with the system record has expired.
8. The computer-implemented method of claim 1, wherein determining that the user is no longer authorized to access the at least one target system comprises: detecting that the user has completed an action associated with the change reason and the change identifier.
9. The computer-implemented method of claim 1, wherein the temporary credential includes one or more user role accounts.
10. The computer-implemented method of claim 9, wherein authorizing the user to access the at least one target system comprises: receiving a request for a connection from the user, the request including the temporary credential; determining that the one or more user role accounts of the temporary credential are authorized to access the production server; and initiating a communication session based on the one or more user role accounts, wherein the communication session is configured to transmit one or more messages between a user device of the user and the production server.
11. The computer-implemented method of claim 10, further comprising: recording the communication session to generate a recorded communication session; associating the recorded communication session with the username of the user that transmitted the request for the connection; and storing the recorded communication session and the username of the user in a data store.
12. The computer-implemented method of claim 10, wherein the communication session is based on a Secure Shell protocol.
13. The computer-implemented method of claim 1, wherein the temporary credential includes a key identifier, the key identifier including the username of the user and the change identifier.
14. The computer-implemented method of claim 13, further comprising: recording, with the at least one processor, the key identifier, an authorized time of the user, and a username of at least one user role account of the one or more user role accounts to a log record; storing, with the at least one processor, the key identifier in a cache memory of the at least one target system; and retrieving, with the at least one processor, the username of the user of the key identifier from the cache memory of the production server based on a process identifier associated with the at least one target system.
15. The computer-implemented method of claim 13, wherein authorizing the user to access the at least one target system comprises: receiving a request for a connection, the request including the temporary credential; retrieving primary data associated with an initial system record stored in a data store based on the change identifier of the key identifier matching a record identifier of the initial system record; and relating the at least one target system to a change reason based on an identifier associated with the at least one target system and the primary data associated with the initial system record.
16. The computer-implemented method of claim 15, wherein the data store receives the primary data from a configuration management database in real-time.
17. The computer-implemented method of claim 1, further comprising generating the temporary credential by digitally signing a user key with a root private key.
18. The computer-implemented method of claim 17, further comprising: generating the root private key and a corresponding root public key in response to receiving a change request; and distributing the root public key to a subset of production servers including the production server.
19. A system comprising: at least one processor configured to: receive an access request associated with a username of a user and data associated with a system record, the data associated with the system record including a change reason and a change identifier; authenticate the user based on the data associated with the system record and provide a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorize the user to access at least one target system associated with the access request based on the temporary credential; determine that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminate access to the at least one target system based on determining that the user is no longer authorized to access a production server.
20. The system of claim 19, wherein the at least one processor is further configured to: authenticate the user using multi-factor authentication based on the username of the user.
21. The system of claim 19, wherein the temporary credential is based on a Secure Shell protocol.
22. The system of claim 19, wherein the at least one processor is further configured to: prompt the user to provide the data associated with the system record.
23. The system of claim 19, wherein the at least one processor is further configured to: verify the data associated with the system record using an initial system record stored in a data store, wherein verifying the data associated with the system record includes: determining that the data associated with the system record matches primary data associated with the initial system record stored in the data store; and relating the data associated with the system record to the username of the user based on the primary data associated with the initial system record.
24. The system of claim 19, wherein providing the temporary credential to the user includes: determining a duration associated with the system record based on the change reason; and generating the temporary credential including the duration associated with the system record, wherein the duration associated with the system record represents a time for which the temporary credential is valid.
25. The system of claim 24, wherein determining that the user is no longer authorized to access the at least one target system includes: determining that the duration associated with the system record has expired.
26. The system of claim 19, wherein determining that the user is no longer authorized to access the at least one target system includes: detecting that the user has completed an action associated with the change reason and the change identifier.
27. The system of claim 19, wherein the temporary credential includes one or more user role accounts.
28. The system of claim 27, wherein authorizing the user to access the at least one target system includes: receiving a request from the user to connect, the request including the temporary credential; determine that the one or more user role accounts of the temporary credential are authorized to access the production server; and initiate a communication session based on the one or more user role accounts, wherein the communication session is configured to transmit one or more messages between a user device of the user and the production server.
29. The system of claim 28, wherein the at least one processor is further configured to: record the communication session to generate a recorded communication session; associate the recorded communication session with the username of the user that transmitted the request for the connection; and store the recorded communication session and the username of the user in a data store.
30. The system of claim 28, wherein the communication session is based on a Secure Shell protocol.
31. The system of claim 19, wherein the temporary credential comprises a key identifier, the key identifier comprising the username of the user and the change identifier.
32. The system of claim 31, wherein the at least one processor is further configured to: record the key identifier, an authorized time of the user, and a username of at least one user role account of the one or more user role accounts to a log record; store the key identifier in a cache of the at least one target system; and retrieve the username of the user of the key identifier from the cache of the production server based on a process identifier associated with the at least one target system.
33. The system of claim 31, wherein authorizing the user to access the at least one target system comprises: receiving a request for a connection, the request comprising the temporary credential; retrieving primary data associated with an initial system record based on the change identifier of the key identifier matching a record identifier of the initial system record stored in a data store; and associating the at least one target system with a change reason based on an identifier associated with the at least one target system and the primary data associated with the initial system record.
34. The system of claim 33, wherein the data store receives the primary data from a configuration management database in real-time.
35. The system of claim 19, wherein the at least one processor is further configured to generate the temporary credential by digitally signing a user key with a root private key.
36. The system of claim 35, wherein the at least one processor is further configured to: generate the root private key and a corresponding root public key in response to receiving a change request; and distribute the root public key to a subset of production servers including the production server.
37. A computer program product comprising at least one non-transitory computer- readable medium including program instructions, the program instructions, when executed by at least one processor, cause the at least one processor to: receiving an access request associated with a username of a user and data associated with a system record, the data associated with the system record including a change reason and a change identifier; providing a temporary credential to the user based on authenticating the user and based on the data associated with the system record; authorizing the user to access at least one target system associated with the access request based on the temporary credential; determining that the user is no longer authorized to access the at least one target system based on the temporary credential; and terminating access to the at least one target system based on determining that the user is no longer authorized to access a production server.