Trust-based dynamic access control method and system

Abstract

Systems and methods are provided for creating and running instances of a dynamic access control system (DACS). Trust providers can be defined in a trust broker of the DACS such that custom data structures can be created using trust information associated with the trust providers. Resources and resource groups can be defined in the DACS. Policies can be configured or coded in the DACS to map the custom data structures to resources or resource groups. Additionally, policies can be configured or coded in the DACS to route the data structures and requests to network segments or shared with other parties.

Description

[0001] By incorporating references

[0002] This application is a continuation of and claims priority to U.S. Patent Application No. 18 / 058,168, filed November 22, 2022, entitled “TRUST-BASED DYNAMIC ACCESS CONTROL SYSTEM”, and is a continuation of and claims priority to U.S. Patent Application No. 18 / 058,198, filed November 22, 2022, entitled “CUSTOMIZABLE TRUST-BASED DYNAMIC ACCESS CONTROL SYSTEM”, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0003] Computing devices can use communication networks to exchange data. Companies and organizations operate computer networks that interconnect multiple computing devices to support operations or provide services to third parties. Computing devices may be located in a single geographic location or in multiple different geographic locations (e.g., interconnected via private or public communication networks). Specifically, a data center or data processing center (generally referred to herein as a "data center") may include several interconnected computing systems for providing computing resources to users of the data center. A data center may be a private data center operating on behalf of an organization or a public data center operating on behalf of or for the benefit of the general public.

[0004] The emergence of virtualization technology for commodity hardware has offered benefits in managing large-scale computing resources for numerous clients with diverse needs, thereby allowing multiple clients to share various computing resources efficiently and securely. For example, virtualization technology can allow a single physical virtualization host to be shared among multiple users by providing each user with one or more "guest" virtual machines hosted by a single virtualization host. Attached Figure Description

[0005] Embodiments of various inventive features will now be described with reference to the following accompanying drawings. Throughout the drawings, reference numerals may be used repeatedly to indicate correspondences between reference elements. The drawings are provided to illustrate exemplary embodiments described herein and are not intended to limit the scope of this disclosure.

[0006] Figure 1 It is a block diagram depicting the high-level technical architecture of a network environment that enables a dynamic access control system according to some implementation schemes.

[0007] Figure 2 This is a block diagram depicting an example configurable user interface and a decoding user interface for connecting to a trust provider, according to some implementation schemes.

[0008] Figure 3 This is a block diagram depicting an example configurable user interface and a decoded user interface for creating resource access and routing policies according to some implementation schemes.

[0009] Figure 4 It is a block diagram depicting an example trust information data structure for generating Hypertext Transfer Protocol (HTTP) requests according to some implementation schemes.

[0010] Figure 5 It is a block diagram depicting an example resource request routed to a network segment according to some implementation schemes.

[0011] Figure 6 It is a block diagram depicting an example resource request that is routed to a specific resource according to some implementation scheme.

[0012] Figure 7 This is a block diagram depicting an example resource request associated with the conversion of a first role to a second role according to some implementation schemes.

[0013] Figure 8 It is a flowchart that can be executed to create an instance of a dynamic access control system and set up an exemplary routine of the dynamic access control system.

[0014] Figure 9 It is a flowchart of an exemplary routine that can be executed to enable a dynamic access control system to evaluate and decide on resource requests.

[0015] Figure 10 This is a block diagram of an exemplary dynamic access control system configured to implement features of some implementation schemes. Detailed Implementation

[0016] In general, this disclosure relates to a dynamic access control system (“DACS”) that provides and manages a “zero-trust” security framework in a network environment. A DACS ensures that user access to network segments, network slices, resources on the network (e.g., virtual machine instances, containers, data stores), attachments, applications, and data is authenticated, authorized, and continuously verified, regardless of whether the user attempts to make such access from inside or outside the protected network. For example, a DACS can grant access to resources (generally referred to as “resources”) on the network to a remote computing device on a per-request basis without separate network authentication and authorization (e.g., without the use of a Virtual Private Network or “VPN”). This resource access for each request can be determined by the DACS client (public or private) according to a custom written policy and can be based on information accompanying the request (e.g., identification and device information), information obtained separately by the DACS from the request (e.g., asynchronously obtained security and historical information), or a combination thereof. Advantageously, this allows the client to create (and the DACS can manage) fine-grained network access to specific resources on a per-request basis, based on a combination of custom written policies and trust information, without having to grant access to all applications on the network.

[0017] Some conventional networks manage user access to network resources (e.g., applications) via VPNs, which provide broad access to many applications on the network (e.g., a corporate or university network). However, as access to applications from multiple locations becomes increasingly common and popular, this broadly permissive access method, providing access to the entire network via VPN, introduces greater risks. To address these risks, network administrators typically employ multiple layers of protection that require configuration and coordination across multiple third-party systems (such as identity, device management, and networking). Any changes to access policies (e.g., new devices or users, new updates to security posture) require network administrators to spend significant time and effort (e.g., sometimes several weeks or months) updating and verifying security configurations. Furthermore, this type of network management becomes increasingly complex as user groups (e.g., enterprise employees) become larger and more dispersed. Additionally, traditional VPNs are not designed for large, distributed, remote user groups, resulting in poor user experiences in these scenarios (e.g., intermittent connectivity). To address these issues, some solutions offer zero-trust access to resources. These solutions determine a risk score for resource requesters. The score is then evaluated to determine whether to grant the requester access to the resource. However, the methods used to determine risk scores and the information upon which those scores are based are typically not shared with the client, nor is there an option to share such determination. Therefore, risk scores are effectively generated by a "black box." Additionally, clients typically lack the ability to inject their own security data into the authentication and authorization process, nor can they modify how the black box determines a requester's risk score. Consequently, clients lack complete control over managing authorization (e.g., grouping requesters into different access groups) based on client-specific custom access policies.

[0018] Some aspects of this disclosure address some or all of the aforementioned problems, as well as others, by providing various types of trust information from multiple sources and by implementing client-defined access policies based on combinations of client-defined trust information. DACS can be configured to receive trust information from multiple trust providers within a DACS trust broker. The trust broker can format the trust information into custom data structures usable by clients. Clients can define which trust providers they want to subscribe to and from which they receive trust information via the data structures. Within the DACS policy engine, clients can define what resources they want requesters to access (in some cases, including the level of access) and the conditions for granting access. For example, by referencing data structures and defined resources, clients can use the policy engine to write custom access policies (often referred to as "policies") that define fine-grained access rules for resources. Additionally, clients can define routing rules that route requests (or in some cases, data structures or their byproducts) to different destinations, such as firewalls (e.g., web application firewalls or "WAFs"), routers, or even network segments. Data structures and policies can also be used to transform one form of request or security role into another.

[0019] As described above, DACS can receive trust information from various trust providers. Trust providers can connect directly to DACS, provide trust information via browser extensions, or even act as out-of-band trust providers, offering trust information to DACS through other methods. When a trust provider connects directly to DACS, they can use connections such as OpenID Connections (OIDC) to provide trust information directly to DACS. Additionally, DACS can receive trust information via custom web browser extensions used by the trust provider to provide trust information (e.g., decorating HTTP requests with trust information). Instead of using web browser extensions or other methods, trust providers can also provide out-of-band trust information. As used herein, the phrase "out-of-band" means that the trust provider can send trust information to DACS asynchronously, independently of any network requests received by DACS. In some implementations, the trust provider can provide trust information to DACS according to a predetermined or dynamically determined schedule, in response to a request from DACS, or in a self-organizing manner. During the processing of real-time requests for access to resources, DACS can match the out-of-band trust information with the requesting party and then use the out-of-band trust information to generate a trust information data structure. An example of an out-of-band trust provider can be achieved by leveraging the OpenID Continuous Access Evaluation Profile (CAEP).

[0020] Additional aspects of this disclosure relate to utilizing trust information to construct a custom trust information data structure, which can be evaluated using customer policies or provided to downstream recipients. The trust information can identify a specific requester attempting to obtain access to a resource via an Identity Provider (IdP) in real-time or near real-time. In some embodiments, the trust information may identify or include information about the device used by the requester to obtain access to the resource (e.g., device information obtained via an Electronic Device Management (EDM) provider). The trust information can also be information stored in a data storage device, retrieved when an access request for the resource is made. A data structure can be constructed for each resource request using the trust information at the time of the request. Therefore, the data structure can provide trust information in real-time or near real-time.

[0021] Another aspect of this disclosure relates to allowing clients to write custom policies based on trust information within a data structure. These custom policies can be configured via a user interface (UI) page or via programmatic decoding. Custom policies allow DACS to analyze the trust information and then map the trust information to resources or resource groups. DACS can also utilize the trust information and route requesters to one or more network segments. Furthermore, DACS can utilize the trust information and transfer requesters from one security role to another.

[0022] Various aspects of this disclosure will now be described with respect to certain examples and implementations, which are intended to be illustrative and not limiting. While some aspects of the implementations described herein will focus on specific examples of defining trust providers, resources and resource groups, and policies in a DAS for illustrative purposes, these examples are for illustrative purposes only and are not intended to be limiting. Any feature used in any implementation described herein may be used in any combination with any other feature without limitation.

[0023] Overview of the example computer environment

[0024] Refer to the example implementation plan, Figure 1 An example network environment is shown that can implement the features of this disclosure.

[0025] In some implementations, the network environment may be or include a Virtual Private Cloud-based Wide Area Network (also referred to as "VPC-WAN" for brevity) configured within a cloud-based network provider's shared network infrastructure (also referred to as a "cloud provider network"). A VPC-WAN can be considered "private" because it is isolated from any other traffic and / or clients (including, but not limited to, other VPC-WANs) sharing the same cloud provider network. Therefore, a VPC-WAN can also be more commonly referred to as a "private WAN," or as an example of a "private network." A VPC-WAN can be considered both "virtual" and "cloud-based" because it is implemented on top of a cloud-based network provider's shared network infrastructure, rather than on a separate infrastructure for the client.

[0026] In some implementations, the network environment may be or include other types of private networks, such as local area networks (“LANs”) or wide area networks (“WANs”) operated by or for a specific entity outside the cloud provider’s network infrastructure. For example, the LAN or WAN infrastructure may operate as a single-client private network, where DAS enables trust-based access policies for a single client.

[0027] In some implementations, the network environment may be or include a global network. More specifically, DACS may be attached to a global network or a portion thereof. In some implementations, the global network may be (or include) a telecommunications network, such as a public or private cellular network (e.g., 4G / LTE, 5G / NR, 6G, etc.) that operates at least partially using the infrastructure of a cloud provider. In some implementations, the global network may be a single private network that acts as a high-level container for network objects. Such a global network may be referred to as a VPC-WAN or “cloud WAN.” The global network may contain transit gateways and other core networks. These can be managed in the Network Manager console. The core network may be a global network managed by a web service provider. This includes regional connection points and attachments, such as VPNs, VPCs, and transit gateway connections. The core network may operate within the regions defined in the core network policy document.

[0028] The core network edge can be associated with regional connection points managed by web service providers in multiple regions, as defined in the core network policy. Each annex can connect to the core network edge. Example, this could be a transit gateway for a web service provider, inheriting many of the same attributes. The regions a user wants to connect to can be defined in the core network policy document. Regions can be added, deleted, or modified at any time using the policy document. For each region defined in the policy document, Cloud WAN can create a core network edge router in the specified region. All core network edges in the core network can create full mesh peering with each other to form a highly resilient network. Traffic on the web service provider's global network uses redundant connections and multiple paths.

[0029] Segment behavior defines how routing works between segments. After creating a segment, users can choose to map resources to segments explicitly (e.g., "VpcId: "vpc-2f09a348") or by creating and using attachment policies. Instead of manually associating segments with each attachment, attachments are tagged. These tags can then be associated with the applicable segments. When attachments are mapped to segments, users can choose how routes are shared between segments. For example, a user might want to share access to a VPN across multiple segments or allow access between two types of branch offices. Users can also choose to configure centralized internet routing for segments or route traffic between segments via a firewall. The techniques disclosed in this paper in the context of network segments can also be applied to network slicing on cellular networks.

[0030] When creating a core network within the global network, users can automatically create the core network and become its owner. The core network owner has full control and view of all parts of the cloud WAN network. The core network owner can then use Resource Access Manager to share the core network across accounts or organizations. Accounts sharing the core network may become attachment owners. Attachment owners may only have permissions to create connections, attachments, or tags, but may not have permissions for any core network tasks. A core network owner can also be an attachment owner.

[0031] Attachment owners can create, update, or delete VPC attachments. They can also add, update, or remove attachment tags. Peering allows interconnection between the core network edge and transit gateway within the same region using peering connections. Users can create one or more routing table attachments via peering connections to route through the cloud WAN network segment peering transit gateway routing table, allowing users to deploy end-to-end network segments across transit gateways and cloud WAN-based networks.

[0032] A home zone can be a region for aggregating and storing data related to the use of the cloud WAN core network. The cloud WAN can aggregate and store this information within the home zone to provide users with a central dashboard offering visualized insights into the global network. Web service providers can aggregate and store usage data for that region from different physical locations. This data may include, but is not limited to: Topology data of registered transit gateways Event data of transit gateways and VPNs Transit Gateway ID used to register the transit gateway with the global network Location data related to device and site registration Provider and link data related to link registration IP addresses and CIDR ranges used in cloud WAN and relay gateway connections to peers Furthermore, all mobile and data aggregation can be conducted through secure and encrypted channels and stored encrypted at rest. This can be accomplished by a third party to create a mapping of the global network. Resource identifiers collected during device and site registration to generate these mappings can be sent to the respective parties.

[0033] As relevant to the concepts herein, cloud provider networks typically provide access to computing resources via a set of defined regions, availability zones, and / or other defined physical locations of data centers aggregated by the cloud provider network. In many cases, each region represents a geographically separated region from other regions (e.g., Eastern United States Region, Western United States Region, Asia Pacific Region, etc.), where each region may include two or more availability zones interconnected via a private high-speed network (e.g., fiber optic communication connection). An availability zone (also known as an availability domain or simply a "zone") is an isolated fault domain comprising one or more data center facilities that have separate power, separate networking, and separate cooling from data center facilities in another availability zone. Preferably, availability zones within a zone are positioned far enough apart that the same natural disaster does not cause more than one availability zone to go offline simultaneously.

[0034] Furthermore, and relevant to the concepts herein, the regions of the cloud provider network are connected to a global "backbone" network, which includes a private networking infrastructure (e.g., fiber optic connections controlled by the cloud provider) connecting each region to at least one other region. This infrastructure design enables users of the cloud provider network to design their applications to run in multiple physical availability zones and / or multiple regions for greater fault tolerance and availability. For example, because the various regions and physical availability zones of the cloud provider network are interconnected via fast, low-latency networking, users can build applications that automatically failover between regions and physical availability zones in the event of an outage or failure in any particular region, with minimal or no disruption to users of the application.

[0035] Furthermore, and in connection with the concepts herein, a cloud provider network may also include multiple edge locations located close to customer workloads, for example, close enough to meet workload latency requirements or data sovereignty requirements. Edge locations may be extensions of the cloud provider network outside of traditional regional / AZ environments. For example, an edge location may be a data center positioned to provide capacity to a group of customers within specific latency requirements, a group (e.g., one or more) of servers provided to a customer site, or a group of servers provided within (or forming part of) a cellular communication network, each of which may be at least partially controlled by the control plane of a nearby AZ or region.

[0036] A network environment (whether implemented as a VPC-WAN, a single-client private network, or otherwise) may include various network resources that a user can request access to or that a user can otherwise interact with from inside or outside the network. For example, a network environment may include applications, network segments, network slices, network attachments, etc. DACS can be implemented as a trust-based access policy that enables and manages any network resources (or only a subset thereof) associated with the network.

[0037] like Figure 1 As shown, the computing environment may include access request 102, computing device 103, trust provider 104, verification 106, DACS 112 (which includes at least trust broker 114 and policy engine 116), sample segment 108 and resource 110.

[0038] As indicated by access request 102, a user of computing device 103 may seek access to a resource, such as resource 110, via a computer network. The computing device 103 may be equipped with hardware and / or software that can communicate trust information directly to the DAS via a trust provider 104. For example, computing device 103 may have an agent installed thereon that may be associated with a trust provider (such as an Enterprise Device Management (EDM) solution 104a or an Identity Provider (IdP) solution 104b), which may assess trust information about the computing device and the user of computing device 103 (e.g., the requester), respectively. For example, the EDM solution may provide device information such as the current operating system, type of antivirus software installed, type of malware protection installed, type of disk encryption installed, device manufacturer, device model, current location of the device, type and model of hardware associated with the device, whether the device complies with National Institute of Standards and Technology (NIST) standards, firmware updates, installed applications or the device's EDM risk score, and other device information. As another example, an IdP solution communicating with DACS can provide information about the user of the device, such as the user's name, username, assigned role, email address associated with the user, verified user location (e.g., video evidence, government court appearance records (e.g., court cases), government documents (e.g., police reports), public and social media content confirming the location, etc.), and an IdP risk score associated with the user, as well as other user information. DACS can connect directly to a trust provider and provide trust information via authentication protocols such as, but not limited to, Secure Access Markup Language (SAML) and OpenID Connectivity (OIDC).

[0039] As described above, when a requester seeks access to a web application, trust information can also be conveyed to DACS via a web browser extension. The web browser extension can use trust information (such as the trust information described above) to decorate a request (such as an HTTP request) so that DACS can receive such trust information. In some implementations, to decorate an HTTP request with trust information, the web browser extension can include the trust information, such as encrypted trust information included in the HTTP request header, in the form of a JavaScript Object Notation (JSON) Web Token (JWT). For example, the HTTP request can be decorated with trust information that gives the current geographic location of the requester and the requester's device. DACS can then receive the HTTP request and know to look for the trust information in the HTTP request header.

[0040] In addition, trust information can be provided to DACS via out-of-band providers. Out-of-band trust providers are trust information providers that do not convey trust information via HTTP request web extensions or provide trust information specific to a particular request. Out-of-band trust providers can communicate with DACS via various methods not covered by HTTP request modifications (e.g., via the Continuous Access Evaluation Protocol (CAEP) or even via a self-organizing file request that securely transmits trust information files). As another example, a vulnerability may be discovered in an application running on the requester's device, and neither the directly connected trust provider nor the HTTP web extension trust provider is notified. However, the out-of-band trust provider can be notified of the vulnerability in the application running on the requester's device and also notify DACS. Therefore, the out-of-band trust provider may be able to provide DACS with supplemental trust information not provided by the HTTP web extension trust provider or the directly connected trust provider. Out-of-band trust providers may also be able to provide historical information about the requester's device (e.g., location history, IP address history, etc.) or historical information about the requester, as well as other types of trust information.

[0041] Therefore, DAS can obtain trust provider information from directly connected trust providers, HTTP web extension trust providers, out-of-band trust providers, and any other trust providers, and use this trust information at least during the initial resource request to create custom data structures specific to individual clients. In other words, DAS can receive and process arbitrary and uniform trust information from multiple sources. This provides DAS clients with the ability to obtain the trust information they want from any source they desire. Trust information from any trust source allows clients to write fine-grained access and / or routing policies in the specific way they want, which will be discussed in detail below.

[0042] Verification section 106 illustrates an example DACS 112 that can utilize a trust broker 114 and a policy engine 116 to determine access and / or routing based on trust information from trust providers. The trust broker 114 can receive trust information from any of the trust providers 104 (but not limited to any of them) and then construct a custom data structure for the client based on the trust providers subscribed to by the client. As described in more detail below, the client will have the ability to decode and / or configure a trust provider with the trust information the client is looking for via DACS 112 to construct access and / or routing policies. DACS 112 can at least analyze the trust information provided by the trust providers subscribed to by the client and at least determine how the trust information can be used to construct data structures. For example, the data structures may take into account previously written access / routing policies by the client and selectively include some trust information or exclude others.

[0043] The client can then configure, decode, or write custom access and / or routing policies using the policy engine 116, based at least on the trust information within the data structure constructed by the trust broker 114. As described in more detail below, the client can define the resources and resource groups to which the trust provider information is mapped. Therefore, when writing custom access and / or routing policies via code or configuration, the client can evaluate each resource request from a requester and make decisions by examining the trust information. These decisions can be allowing the requester access to a resource or resource group, or the level of access. For example, a policy might determine, based on the trust information, that the requester is an accountant in an accounting department and only allow read access to legitimate filing software (the resource). Furthermore, policies can be written to analyze the trust information and determine that the requester is making a resource request via a mobile computing device, and therefore require routing of the request via additional web application firewall settings.

[0044] Example paragraph 108 illustrates network segments for HR, finance and accounting, information technology, and legal and blocked networks (these network segments should not be considered as restrictive). As used herein, the term "network segment" (or simply "segment" for brevity) refers to a network structure used to divide network traffic into different logical network parts of a shared physical network infrastructure. For example, VPC-WAN can be configured using network policy data that defines various aspects, such as the regions covered by the VPC-WAN, network segments that may span multiple regions within the VPC-WAN but remain isolated or substantially isolated from each other, and how isolated networks (Virtual Private Cloud or "VPC", VPN, Software-Defined Wide Area Network or "SD-WAN", direct connection to a resident client network, etc.) are attached to network segments. Thus, a VPC-WAN may span multiple regions of a cloud provider network and may include any number of isolated networks that may be hosted within the cloud provider network's physical data center (e.g., a VPC) or physically located outside the cloud provider's data center (e.g., a resident client network or a third-party network communicating with the cloud provider network via VPN, SD-WAN, direct connection, etc.). This allows client traffic originating from one endpoint to be routed to another endpoint in the VPC-WAN, regardless of whether one or both endpoints are within or outside the cloud provider's physical data center network. Furthermore, clients can segment VPC-WAN traffic within network policy data by defining the network segments using one or more rules attached to isolate network segments.

[0045] To determine the appropriate segment for network traffic and enforce segmentation policies, segmentation data can be included in the network packet header metadata. At Layer 3 of the Open Systems Interconnection (“OSI”) model, some networks use packet headers to perform routing operations. These packet headers include 5-tuple metadata: a source address, such as the Internet Protocol (“IP”) address of the packet's sender; a destination address, such as the IP address of the packet's intended destination; a source port, such as the Transmission Control Protocol (“TCP”) or User Datagram Protocol (“UDP”) port from which the packet originated; a destination port, such as the TCP or UDP port of the packet's intended destination; and the protocol to be used. In some implementations, to facilitate routing traffic across a network or its region within a given segment while maintaining isolation between different segments, additional metadata can be added to the packet header to indicate the segment from which the packet originated. For example, a Layer 3 packet header can be expanded to 6-tuple metadata for routing, where the additional metadata item is a segment identifier. Additional metadata items can be added to the header by the gateway or the packet sender (e.g., the host device from which the packet originated, a virtual machine instance or hypervisor running on the host device, etc.). Policies can be implemented at the gateway so that when a packet is received, the gateway can evaluate the segment identifier and determine which routing data (e.g., a segment-specific routing table) to use to route the packet. In this way, a single gateway or a system of gateways within a given network or area can resolve the segment to which a packet belongs and route traffic across multiple segments, while maintaining isolation between segments using segment-specific routing information.

[0046] Clients can write access policies to route requests for resources to a specific network segment among multiple network segments implemented in a network environment. This specific network segment may be different from the network segment to which the request was initially associated, or the request may not initially be associated with any segment. For example, policies can be written to analyze trust information and determine that the requester is using Bring Your Own Device (BYOD) and route the request to a network segment isolated from the network segment containing sensitive information. As another example, policies can be written to analyze trust information and determine that the requester has an HR role and should therefore be routed to the HR segment of the network. Blocked network segments illustrate policies that can be written to analyze trust information and determine, for example, that the requester is using a device from a manufacturer on a blacklist or using a device from a country where the requester is not allowed to access resources, that the requester should not be allowed access to any network segment and resource.

[0047] Resource 110 illustrates example resources to which a requester may attempt to obtain access. Resource 110 is positioned after example segment 108 because in some embodiments, a requester may be routed to a network segment before being granted access to the resource. However, this may not always be the case, and in some embodiments, a requester may be directly routed to the resource without requesting any assignment to a particular segment. As shown in Resource 110, example resources to which a requester may attempt to obtain access could be accounting systems, payroll systems, benefits systems, legal systems, billing systems, networking tool systems, and screen sharing tool systems. Policies can be written to analyze trust information and determine that the requester has an accounting role and route them directly to the accounting system resource. Furthermore, policies can be written to analyze trust information and determine that the requester has a lawyer role and route them directly to the legal system. Moreover, policies can be written to analyze trust information and determine that the requester has an information technology professional role and thus route them to both networking tool resources and screen sharing tool resources. As mentioned above, the resources shown in the segments of Resource 110 are merely examples and are not intended to be limiting.

[0048] Trust brokers and strategy engines

[0049] Figure 2 The illustration depicts a block diagram of an example configurable user interface and a decoding user interface for connecting to a trust provider. For example... Figure 2 As shown, the trust broker 114 may be located within the DAS 112 and may be configured via UI 202 or decoded via UI 204.

[0050] like Figure 2As shown, UI 202 allows clients to configure the trust providers they wish to subscribe to in order to receive custom data structures from DAS 112 and write custom policies. Field 206 indicates that DAS 112 allows clients to select a type of trust provider, here an identity provider, such as an IdP. As mentioned above, an IdP trust provider provides trust information related to the requester, while an EDM trust provider provides trust information related to the computing device associated with the requester. However, as mentioned above, DAS 112 is not limited to EDM and IdP trust providers; any trust provider with access to DAS 112's web extensions can be selected, or even an out-of-band trust provider can be selected. Field 208 allows clients to select from predefined directly connected trust providers, trust providers enabled by the HTTP request web extension, or any other trust provider that DAS 112 already has access to. In the example shown, a Single Sign-On (SSO) trust provider has been selected; however, another type of trust provider, such as a geolocation trust provider that provides real-time location services for the requester's device, may also have been selected.

[0051] The "Download Metadata File" button 210 allows the client to download metadata associated with the currently selected trust provider. The "Upload Metadata File" button 212 allows the client to upload metadata associated with the trust provider. For example, the client can upload metadata describing how DAS 112 connects to an out-of-band trust provider so that DAS 112 can receive trust information from the out-of-band trust provider. Furthermore, once the client has completed the configuration of the trust provider's properties, the "Add New Trust Provider" button 214 allows the client to add a new trust provider.

[0052] As an alternative to configuring new trust providers to be added, UI 204 allows clients to write code via detailed decoding to explain how to add specific trust providers, resulting in the trust providers being added to a custom data structure of DAS 112. As shown in UI 204, clients can write code to define the type of provider they are adding to their data structure feed, such as a user-identified trust provider (e.g., IdP), a computing device-identified trust provider (e.g., EDM), or an out-of-band trust provider (e.g., a provider that identifies a computing application with a recently identified vulnerability).

[0053] Beyond fields, dropdown menus, and other buttons, clients in UI 204 can perform complex functions when defining trust providers to include in data structure feeds. For example, clients can write code to instruct DAS 112 which specific trust information to obtain from the trust provider and which information to exclude. Some clients might want the location history of the computing device, while others might want the history of applications installed on the computing device, as well as other information requests. As another example, clients can instruct DAS 112 how to communicate with and obtain information from out-of-band trust providers. For instance, clients can write code to instruct DAS 112 that out-of-band trust providers can communicate via the CAEP protocol and that trust information will be transmitted in a specific trust information format.

[0054] Figure 3 The diagram illustrates an example configurable user interface and a decoded user interface used to create resource access and routing policies. (Example:) Figure 3 As shown, the policy engine 116 may reside within DAS 112 and may be configured via UI 220 or decoded via UI 222. As will be described in detail below, clients may map trust information from data structures to resources, resource groups, or routing details.

[0055] like Figure 3 As shown, UI 220 allows clients to configure resource or routing policies based on data structures provided by trust broker 114. Policies can be defined based on one or more evaluations to be applied to trust information associated with a request, and the corresponding actions to be taken regarding the request based on the results of these evaluations.

[0056] As described above but shown now, the client can first define which resources access is permitted under the routing policy. Additionally, resource groups can be defined to group resources, for example, grouping all IT resources into a resource group named IT Group. Radio button 224 allows the client to select whether to define an access or routing policy for a resource or a group of resources. If a group access policy is selected, field 226 allows selection of the resource group shown in the figure (here, the HR group is selected); otherwise, field 226 allows selection of a single resource (e.g., a single word processing application). The user can then define one or more evaluations for the policy and take action based on the evaluation results. In some implementations, the evaluations and corresponding actions can be implemented as rules. For example, in the rules section of UI 220, field 230 allows the client to select the action to take based on provided trust information, such as an allow or deny value. In this case, allow means the requester will be granted access to the resource, while deny means access to the resource is not permitted.

[0057] Other options selectable in field 230 may include read or write access to the resource, permission to access all or some sections of the resource, and other options. Field 228 allows the client to select which trust provider the action in field 230 applies to. For example, the client may choose to apply the action in field 230 (e.g., allow access) to an IdP trust provider. Field 232 shows the values ​​that the client can place for conditional evaluation, such as the requester's email address being evaluated against fields 234 and 236 to determine whether the requested access to the resource is allowed. Under field 234, operators can be selected to evaluate the values ​​in field 232. Example operators may include "ends with," "begins with," "contains," "equals," and other operators. Field 236 allows the client to place the values ​​that fields 232 and 234 evaluate against. For example, the @company value here means that requesters with email addresses ending in @company (e.g., jwright@company) are allowed, as determined by the values ​​in fields 228, 230, 232, 234, and 236. Field 238 allows clients to add more rules, and to add the added rules via "and" or "or". "And" can mean that additional rules must be satisfied before access to the resource can be granted, while "or" can mean that only one of the rules (including the rule currently being configured) must be satisfied before access can be granted.

[0058] As an alternative to configuring custom access or routing policies, UI 222 allows clients to write policies based on the data structures provided by DAS 112 via detailed decoding. As shown in UI 222, clients can write code to precisely define how the provided data structures determine access or routing. For example, if the data structure contains trust information from three trust providers—one from IdP, one from EDM, and one from an out-of-band provider—the client can choose to use only the IdP trust provider to determine whether a requester can obtain access to a resource. In this example, the client can write code to write a policy to evaluate only whether a requester has an email address from a company before allowing access to a company's intranet website. As a second example, the client can write code to evaluate the IdP and EDM trust providers to see if a requester can again access the company's legal system. In this second example, the client can write code to check the IdP trust information to see if the user has the role of a lawyer and whether a third-party verification service has not flagged the lawyer as a security risk. Furthermore, in the second example, the client can write code to check the EDM trust information to ensure that the requester's computing device is not in a restricted country, has all updated firmware, was not manufactured by a restricted manufacturer, and other relevant matters. Therefore, in this second example, the requester is only granted access to the legal system after the IdP and EDM trust information have been verified.

[0059] Referring again to UI 222, clients can write code to examine the risk profile associated with a requester within a data structure and can send the requester to additional security checks (e.g., additional firewalls) based on the risk profile. For example, an IdP trust provider or a client-managed trust provider can provide a risk score of the requester that can be found within the data structure. Furthermore, an EDM trust provider can provide information about the mobile computing device the requester is using that can be found within the data structure. Therefore, clients can write policy code to determine whether a requester has a certain risk score (e.g., medium risk) and is using a mobile computing device, and then route the requester to a network segment with additional security settings, or even perform additional security checks (firewalls, authentication, etc.) before allowing the requester access to the resource.

[0060] It should be noted that both the trust broker 114 and the strategy engine 116 can be implemented via one or more computing devices, computer servers, computer software, or a combination thereof. For example... Figure 10 As defined in, but not limited to.

[0061] Custom data structures

[0062] Figure 4This is a block diagram depicting an example of a data structure for generating trust information in a request. For example... Figure 4 As shown, at step (1), the requester may generate a resource request (such as request 404) via device 402 to access or use a resource (such as one of resources 110). As described above, the requester may be associated with the client as an employee (e.g., as an accountant or lawyer working for the client). As shown in request 404, the request for the resource may include header data that is not human-readable, such as JavaScript Object Notation (JSON) encoded data. This may be due to the encoding mechanism or due to some type of encryption. The content of request 404 may contain trust information provided by a trust provider (such as an IdP, EDM, or out-of-band trust provider) associated with device 402.

[0063] In some implementations, trust information may be determined dynamically in response to a request 404 initiated by user device 402 (or substantially simultaneously). For example, user device 402 may be operated by a user. The user may use a web browser application to generate an HTTP request to access a specific resource on the client. The web browser application or its executable extension may generate trust information, such as user account identification information, information about the user device's attributes, etc. For example, the user may need to perform an authentication procedure to provide user account identification information to the web browser application or extension. As another example, the web browser application or extension may obtain data about the attributes of user device 402, such as device manufacturer, software version, malware protection, etc. The trust information may then be included in the HTTP request. For example, the trust information may be encoded using JSON and included as a JWT in the header of the HTTP request.

[0064] At step (2), DAS 112 may receive request 404 and process it through trust broker 114. Trust broker 114 may refer to client configurations or decodings that define the trust provider subscribed to by the client, such as... Figure 2As shown. When referencing such a trust provider subscription, at step (3), trust broker 114 may construct data structure 406 (also referred to as a trust information data structure) in real-time or near real-time, the data structure referencing at least the client's trust provider subscription details and the content of request 404. In other words, trust broker 114 may construct a custom data structure for the client each time a requester makes a resource request. Trust broker 114 may also add additional trust data stored in a data storage device to the custom data structure, which may be associated with at least request 404, the requester, the client, or the trust provider, but is not limited thereto. This additional trust data may have been obtained by DAS 112 before request 404 or otherwise asynchronously relative to the request, such as from a previous resource request, provided by the trust provider, provided by the client, or provided by any other party that can provide information that can be used to construct the custom data structure. For example, request 404 may contain data about a user account associated with the name "John Wayne". Trust broker 114 can search data storage devices and discover a history of resource requests made by individuals with the same name to legal and accounting-related resources, even if the current request 404 does not contain a request for legal or accounting resources. This additional trust data can also be added to the data structure to be analyzed by policy engine 116.

[0065] Data structure 406 may include any number or combination of trust information items, depending on the trust provider configuration specified by the client. In some implementations, data structure 406 may organize certain trust information items into groups, subgroups, etc. Groups / subgroups / etc. may be organized based on the type of trust information (e.g., user identifier, device attribute, etc.), the source of the trust information (e.g., IdP, EDM, out-of-band provider, etc.), or based on specific client configurations. Figure 4 As shown, data structure 406 can be constructed by trust broker 114 to include segments containing user identifier, device identifier, and behavior, network, or resource requests.

[0066] As described above, the trust broker 114 can construct the data structure 406 in real-time or near real-time during or after receiving request 404. Therefore, if the client changes its subscribed trust providers or the information the client wants to obtain from each trust provider before receiving request 404, the content or underlying structure of data structure 406 can be altered. For example, if the client modifies the definition of the EDM trust provider before request 404, now adding geolocation information (which was not previously subscribed to), the trust broker 114 can now add the geolocation of device 402 to data structure 406, where previous iterations of data structure 406 did not include the geolocation of device 402.

[0067] Still discussing data structure 406, the trust information used to populate segments for user identification, device identification and behavior, network, and resources can come from multiple trust providers. For example, user identification segment trust information can come from at least one IdP. Device identification and behavior segment trust information can come from at least one EDM. Network segment trust information may come from a trust provider that provides Internet Protocol (IP) location information of the device, separate from the IdP and EDM that provide trust information for the other segments described, and resource request segment trust information can come from an IdP. Therefore, at least because Figure 2 The client configuration or decoding details the trust providers the client subscribes to, and data structure 406 may contain trust information from multiple trust providers.

[0068] As shown in data structure 406, the user identifier field may contain trust information such as user_id, user_email, user_role, and status. As mentioned above, this trust information may already be provided by the IdP. The user_id may be an identifier in which the client's resources identify the requester as a known user using said resources, and this identifier may be associated with the requester's legal name (e.g., Jake Smiles in this case). The value of user_email may be an email address associated with the requester, such as JSmiles@example.com, referring to the email address of Jake Smiles at a company-named entity. This email address can be referenced against emails stored by the trust broker 114 to ensure it is not fraudulent or tampered with. User_role may refer to the employment role assigned to the requester. As shown in this example, the requester has roles in legal, accounting, and NYUsers. Therefore, the requester may have employment roles associated with legal work and accounting work within the client's company, and the requester may also work in the client's New York City office. These roles may therefore specify which resources the requester is allowed to access based on the client's written policy, as described in more detail above and below. The status may refer to the IdP's risk score or the requester's rating. For example, an IdP may assign a green risk score or risk category to a trustworthy requester, a yellow risk score or risk category to a less trustworthy requester, and a red risk score or risk category to a requester who should not be granted access to any resources.

[0069] As shown in data structure 406, the device identification and behavior section may contain trust information such as source, agent_status, last_update_time, secure_boot, OS, user, MFG, and current_location. As mentioned above, this trust information may have been provided by the EDM. Source may identify the EDM trust provider, which could be Sentinel One. Agent_status may identify the risk score assigned to device 402. For example, the EDM may assign a green risk score or risk category to a trustworthy computing device, a yellow risk score or risk category to a less trustworthy computing device, and a red risk score or risk category to a computing device that should not be granted access to any resources. Last_update_time may indicate when device 402 last performed an operating system or firmware update. Secure_boot may indicate when device 402 last booted securely. User may indicate the username of the requester associated with device 402, or how 402 identifies the requester. MFG may identify the manufacturer of device 402. Finally, the current location can identify the location of device 402 when a 404 request is made. Therefore, the trust information described in this section can also be evaluated by a policy written by the client to determine access or routing.

[0070] EDM may provide Trust Broker 114 with additional trust information for constructing its data structures, including location history, device-level signature history, NIST standards, disk encryption, hardware, and software. Location history may be associated with the history of the location of device 402. Device-level signature history may be associated with the history of signatures made by device 402 at the device level. Disk encryption may be associated with information describing which disks of device 402 are encrypted and the type of encryption. NIST standards may be associated with information describing whether device 402 complies with any NIST standards (such as the NIST 800 standard, developed to address and support the security and privacy needs of U.S. federal government information and information systems). Hardware may be associated with the computer hardware (such as various types of processors, memory, buses, drives, I / O devices, etc.) internal to or part of device 402. Software may be associated with information describing all software installed on or already installed on device 402.

[0071] As additionally shown in data structure 406, a network segment may contain trust information such as src_ip, src_port, dst_ip, dst_port, and protocol. As described above, this trust information may come from a trust provider that provides IP-based location information for the device. This type of trust provider may be separate from the IdP and EDM that provide trust information for the other segments described. Src_ip may identify the IP address of device 402. Src_port may identify the number assigned to device 402 by the Transmission Control Protocol (TCP). Dst_ip may identify the IP address of the resource the requester is attempting to access. Protocol may identify the IP protocol used by device 402 for communication, which is TCP in this case. This trust information can also be evaluated by a policy written by the client to determine access or routing.

[0072] Furthermore, as shown in data structure 406, the resource request segment may contain trust information such as protocol, host, header, URI, method, and body. As mentioned above, this trust information may come from a trust provider that provides resource request information from a device (such as device 402), which may be an EDM, or even a trust provider that specializes in providing trust information related to the request information but is not an EDM. The protocol may identify the protocol associated with the current resource request, here HTTP. The host may identify the IP address of the host associated with the resource the requester wants to access, here www.example.com. The header may identify header information associated with the resource request. As mentioned above, the trust information may be embedded in the request header, rather than in a segment containing the trust information from a trust provider. For example, the user identification segment and the device identification and behavior segment may not identify trust information related to whether any application running on device 402 is vulnerable. Therefore, the client may choose to obtain trust information about application vulnerabilities from a separate trust provider, where the separate trust provider may at least provide a list of computing device applications with vulnerabilities. Additionally, the trust provider may have the ability to provide trust information in the request header rather than in a separate section of data structure 406. The Uri may identify a Uniform Resource Locator (URL) that identifies a specific segment of the host IP address where the resource requested by the requester resides. The method may identify the type of request 404, such as whether it is a POST or GET method. Here, using the POST method, request 404 may instruct the contents of the storage body segment (as shown in data structure 406 below) and the header segment (as shown in data structure 406 above) for future processing (such as during analysis performed by policy engine 116 when evaluating policies based on data structures (such as data structure 406).

[0073] Policy access and routing examples

[0074] Figures 5 to 7 This is a diagram depicting the application of client-defined access policies to trust information to process a requester's example resource request.

[0075] Figure 5 This is a diagram depicting a sample resource request routed to a network segment. For example... Figure 5 As shown, in step (1), request 404 can be received at DACS 112 by first being processed by trusted agent 114. As above... Figure 4 As described, the trust broker 114 can generate a data structure 406 of trust information for request 404. In step (2) and... Figure 5 In the example shown, this data structure may at least contain a user identification segment with trust information. In this example implementation, the trust information may indicate the requester's roles as Legal, ProdSupport, and NYUsers via User_Role. Furthermore, the trust information via Status may indicate that the requester's risk rating as an individual is green.

[0076] At step (3), data structure 406 can be passed to policy engine 116 for analysis of data structure 406 according to the client configuration or decoding policy, such as Figure 3 As shown above, custom access policies can include one or more evaluations applied to trust information and corresponding actions taken based on the evaluation results of the trust information. For example, a policy can map trust information and resource requests to resources, or even route resource requests to network segments and other actions.

[0077] In the illustrated example, the client may have written a policy to route resource requests (and possibly other trust information or information derived therefrom) to the network segment based on trust information in data structure 406. For example, policy engine 116 could use a written policy to determine that if the requester has the ProdSupport role and a green status, the requester should be routed to production segment 512 because production support users should be allowed access to the production database. In the provided case, the written policy might route the requester to the network segment instead of directly to the requested resource because the requesting application may store and process confidential information. Therefore, the client could have a policy that routes any request for a resource storing or processing confidential information to the network segment instead of directly to the application because the network segment may have added security procedures.

[0078] Figure 6 It is a diagram depicting a sample resource request that is routed to a specific resource. For example... Figure 6As shown, in step (1), request 404 can be received at DACS 112 by first being processed by trusted agent 114. As above... Figure 4 As described, the trust broker 114 can generate data structure 406 for request 404. In step (2) and... Figure 6 In the example shown, this data structure may at least include a user identification segment with trust information. In this example implementation, the trust information may indicate the requester's roles as HR Executive and NYUser via user_role. Furthermore, trust information via status may indicate that the requester's risk rating as an individual is green. Although not shown, this example may also indicate via trust information from EDM that the requester is making a resource request from a desktop computer located at the client's location.

[0079] At step (3), data structure 406 can be passed to policy engine 116 for analysis of data structure 406 according to the client configuration or decoding policy, such as Figure 3 As illustrated above, custom access policies can include one or more assessments applied to trust information and corresponding actions taken based on the assessment results of the trust information. In the illustrated example, the client may have written a policy to directly route resource requests to the welfare system named in the resource based on the trust information in data structure 406. For example, policy engine 116 can use a written policy to determine that the requester should be routed to the resource if the requester has the role of an HR executive, is in a green status, is making a request from a home office desktop computer, and requests access to the welfare system resource. The client can determine that this combination of trust information is sufficient to grant direct access to the welfare system resource without any additional security measures or routing.

[0080] Figure 7 This is a diagram illustrating the application of an access policy based on trust information associated with the request, transforming a sample resource request into a modified request. In the illustrated example, the request associated with the first role is transformed into a modified request associated with the second role.

[0081] like Figure 7 As shown, in step (1), request 404 can be received at DACS 112 by first being processed by trusted agent 114. As above... Figure 4 As described, the trust broker 114 can generate data structure 406 for request 404. In step (2) and... Figure 7In the example shown, this data structure may include at least a user identifier segment and a device identifier and behavior segment, both of which contain trust information. In this example implementation, the trust information may indicate that the requester has the roles of a contractor and an NYUser via the user_role segment. Furthermore, the trust information via status may indicate that the requester's risk rating as an individual is yellow. This example may also indicate via the device identifier and behavior segment that the requester is making a resource request from a mobile computing device.

[0082] At step (3), data structure 406 can be passed to policy engine 116 for analysis of data structure 406 according to the client configuration or decoding policy, such as Figure 3 As illustrated above, custom access policies can include one or more assessments applied to trust information and corresponding actions taken based on the assessment results of the trust information. In the illustrated example, a client may have written a policy to require any requester who is a contracting party, has a status below green, and is using a mobile computing device to be mapped to a multi-factor authentication (MFA) role within a specific resource because the client needs additional assurance that a high-risk requester, acting as a contracting party, is taking precautions to at least not create vulnerabilities in the client's computer network and systems. For example, policy engine 116 can use a written policy to determine that when a requester has a contracting party role, is in a yellow status, and is making a request from a mobile computing device, the requester should be required to perform MFA authentication, regardless of the requested resource. The client may decide that this combination of trust information requires additional precautions because the requester is not an employee of the client, has a status below green, and is making a request on a mobile computing device.

[0083] Although Figures 5 to 7 This means providing examples of access and routing policies, but does not mean they are restrictive examples. As mentioned above, in some implementations, clients are free to configure or decode policies they deem appropriate for their organization via policy engine 116. For example, clients can use policy engine 116 to write policies to analyze trust information and send requests and trust information to the web application firewall (WAF), allowing the WAF to evaluate the trust information and resource requests. Clients can also update WAF rules to take into account the results of analysis performed on resource requests and trust information.

[0084] Additionally, access levels to resources can be controlled via custom written policies. For example, a client can configure or decode written policies via Policy Engine 116 to allow only HR administrators access to payroll resources when trust information or other information indicates that the client is currently under a Distributed Denial-of-Service (DDoS) attack. Similarly, policies can be written to grant read-only and read / write access to resources primarily based on the requester's role. For example, an auditor role might only have read access to accounting resources, while a Chief Financial Officer (CFO) role might be granted both read and write access to accounting resources.

[0085] Example routines

[0086] Figure 8 and Figure 9 These are example, non-restricted routines related to the configuration and operation of DACS 112. Figure 8 It is a flowchart of an executable routine 800 for creating an instance of a dynamic access control system and setting up the dynamic access control system.

[0087] At box 802, a DAS 112 client can create an instance of the Dynamic Access Control System. When creating an instance, the client can choose to attach the instance directly to a network partition (e.g., a VPC or segment) where its resources can be deployed. For example, the client may not need to route resource requests to a network segment before allowing a requester access to the resource, and therefore the DAS 112 can be attached to a VPC. Alternatively, the client can attach the instance to a network gateway so that resource requests can be routed to different VPCs and local area networks accessible via the gateway. As another example, the instance can be attached to an ingress point in a private network or VPC-WAN, allowing policies to be written based on resources deployed across multiple regions and local area networks. Ingress point attachment enables policies to be written for resources on different network segments, where traffic from one network segment is isolated from traffic from other network segments. By attaching the instance to an ingress point, additional protection can be provided by keeping traffic to the resource to its own segment.

[0088] At box 804, the client can define the trust provider used by the trust broker 114 via configuration or decoding. As mentioned above, the trust provider can be directly connected, web-extended enabled, or even out-of-band. DACS 112 not only allows selection of trust providers but also allows control over the exact trust information from these trust providers.

[0089] At box 806, the client can define the resources used by policy engine 116 via configuration or decoding. As described above, when the trust information associated with a resource request meets the policy requirements written by the client, the resource can be directly mapped to the resource request.

[0090] At box 808, the client can define resource groups to group individual resources together. This allows the client to broadly access resources that are logically grouped together (such as grouping all valid resources under a valid resource group).

[0091] although Figure 8 The definition of resources is shown to occur before the definition of resource groups; however, this order is presented for illustrative purposes only and does not imply limitation or requirement. In some embodiments, resource groups may be defined before or simultaneously with the resources within them.

[0092] At box 810, the client can configure or decode written policies to effectively map trust information and requests to specific resources or routers. As described above, the client is free to obtain trust information from the trust provider and choose to perform at least any action related to resource access. For example, based on the provided trust information, a resource request can be routed to a network segment. Alternatively, it can be routed directly to a resource. As another example, trust information and resource requests can be shared with other parties and systems, such as a WAF.

[0093] Figure 9 This is a flowchart of an exemplary routine 900 that can be executed to enable the dynamic access control system to evaluate and determine resource requests. At block 902, DAS 112 can receive requests to access resources. As mentioned above, resource requests can be received in the form of HTTP requests.

[0094] At box 904, DAS 112 may reference the decoding or configuration settings used by the client to define the trust provider. By referencing such decoding or configuration, DAS 112 can determine, via trust broker 114, which trust providers the client has subscribed to and which trust information it accesses from those providers. After retrieving or otherwise accessing that trust provider information (e.g., from a request header, a data storage device, or directly from the trust provider), trust broker 114 can use that trust information to create a custom data structure. This data structure will be evaluated by policy engine 116 specifically according to the access policy defined by the client. As mentioned above, each data structure can be created in response to receiving a request for a resource. Therefore, each created data structure may differ in structure and content. The structural differences are because the client's decoding and configuration may have been altered because the client may have subscribed to different trust providers or even chosen to receive more or less trust information from existing trust providers.

[0095] At box 906, when trust information and requests trigger a custom access policy, DAS 112 can map the trust information and resource requests to the custom access policy in policy engine 116. At box 908, DAS 112 can evaluate the trust information and requests according to the matching policy via policy engine 116 to make routing or access decisions.

[0096] As a result of evaluating trust information based on access policies, DAS 112 can determine one or more actions to be taken regarding the request. For example, at box 910, policy engine 116 can directly allow access to a resource based on trust information and the request, according to a written policy. As another example, at box 912, policy engine 116 can route trust information and the request to a network segment based on the content of the trust information and the request. As yet another example, at box 914, a client can write policies via policy engine 116 based on the content of the trust information and the request to share trust information and the request with other parties (such as a WAF). Thus, trust information and the request can be shared. As yet another example, at box 916, a client can write policies via policy engine 116 based on trust information to modify the request or aspects thereof (e.g., role, security scenario, destination IP address).

[0097] although Figure 9 The actions shown are determined individually, but in some implementations, multiple actions may be determined and / or performed in parallel.

[0098] Example Dynamic Access Control System

[0099] Figure 10 Examples of various components of the sample DAS are configured to implement the various functionalities described in this article.

[0100] In some implementations, as shown in the figure, the DAS 1000 may include: one or more computer processors 1002, such as a physical central processing unit (“CPU”); one or more network interfaces 1004, such as a network interface card (“NIC”); one or more computer-readable storage devices 1006; and one or more input and output device interfaces 1008.

[0101] Main memory 1010 may include computer program instructions executed by one or more computer processors 1002 and / or data used by one or more computer processors 1002 to implement one or more embodiments. For example, main memory 1010 may store operating system 1012 to provide general management of DAS 112. As another example, main memory 1010 may store trust broker 1014 for storing decoding and configuration for defining trust providers. As yet another example, main memory 1010 may store policy engine 1016, wherein policy engine 106 can execute policies based on data structures created by trust broker.

[0102] Terminology and Additional Notes

[0103] Some inventive aspects of this disclosure are set forth in the following clauses: Clause 1. A system comprising: A computer-readable storage medium storing executable instructions; and At least one computing device, the at least one computing device communicating with the computer-readable storage medium and programmed by the executable instructions to: Receive requests to access web applications from the user's device; In association with the request, trust information generated by one or more trust providers is received, wherein the trust information at least indicates: The first identification information of the user; and Second identification information regarding the device; A trust information data structure is created using the first identification information and the second identification information; Access network application policies, wherein the network application policies map the trust information data structure to one or more of the following: (i) the access level of the network application, (ii) the access level of a network segment of the cloud provider network, (iii) routing instructions to a network firewall, or (iv) routing instructions to a network router. Access or routing information is determined at least in part based on the network application policy and the trust information; and Access or routing actions are performed based at least in part on the access or routing information.

[0104] Clause 2. The system as described in Clause 1, wherein the trust information generated by the one or more trust providers is requested to be provided via Hypertext Transfer Protocol by a browser extension executed on the user's device.

[0105] Clause 3. A system as described in Clause 1, wherein the access or routing information includes at least one of the following: The access level of the network application; Access levels for network segments; Route the command to the network firewall; Route the command to the network router; or Denied access to the web application.

[0106] Clause 4. A system as described in Clause 1, wherein the access or routing action includes at least one of the following: Provide the user with access levels to the network application; Provide the user with access to the network segment; The trust information is routed to the network firewall; The trust information is routed to a network router; or Access to the web application is denied.

[0107] Clause 5. A computer-implemented method, said method comprising: Under the control of a computing system associated with a cloud provider network, the computing system includes one or more computer processors configured to execute specific instructions: Receive a request for network resources on the cloud provider's network, the request including first trust information representing one or more attributes of the source of the request; The second trust information is generated at least in part based on the first trust information and additional trust information obtained separately from the request, wherein the additional trust information is associated with the source of the request; The request is augmented using the second trust information to generate an augmented request; and The action to be taken regarding the request for expansion is determined based on the assessment of the second trust information.

[0108] Clause 6. The computer-implemented method as described in Clause 5, the method further comprising: determining from the first trust information an attribute among one or more attributes of the source of the request, wherein the attribute includes: an identifier of a user account, an attribute of the user account, an identifier of a device, or an attribute of the device.

[0109] Clause 7. The computer-implemented method as described in Clause 5, the method further comprising: accessing the additional trust information based at least in part on the association between the additional trust information and the source of the request, wherein the additional trust information includes: the history of the source of the request, a security risk score associated with the source of the request, or the location of the source of the request.

[0110] Clause 8. A computer-implemented method as described in Clause 5, the method further comprising: receiving the additional trust information prior to receiving the request.

[0111] Clause 9. The computer-implemented method as described in Clause 5, wherein generating the second trust information includes generating a trust information data structure using a plurality of trust information items selected by the client and associated with the network resource.

[0112] Clause 10. A computer-implemented method as described in Clause 5, wherein augmenting the request with the second trust information to generate the augmented request includes adding the second trust information to one or more headers of the request.

[0113] Clause 11. A computer-implemented method as described in Clause 5, wherein augmenting the request with the second trust information to generate the augmented request comprises adding the second trust information to one or more encapsulation headers, wherein packets of the request are encapsulated for transmission.

[0114] Clause 12. The computer-implemented method as described in Clause 5, the method further comprising: removing a header comprising at least a portion of the first trust information from the request.

[0115] Clause 13. The computer-implemented method as described in Clause 5, wherein determining the action to be taken regarding the request for the extension based on an evaluation of the second trust information includes determining, based on the second trust information satisfying an access policy, to transmit the request for the extension to the network resource.

[0116] Clause 14. The computer-implemented method as described in Clause 5, wherein determining the action to be taken regarding the request for the extension based on an assessment of the second trust information includes determining to transmit the request for the extension to a firewall, the firewall being configured to apply an access policy to determine whether to transmit the request for the extension to the network resource.

[0117] Clause 15. The computer-implemented method as described in Clause 5, wherein determining the action to be taken regarding the request for the extension based on an evaluation of the second trust information includes transmitting the request for the extension through a segment of a plurality of segments of the cloud provider network, the segments being selected based on the second trust information satisfying an access policy.

[0118] Clause 16. A system comprising: A computer-readable storage medium storing executable instructions; and One or more processors, the one or more processors communicating with the computer-readable storage and programmed by the executable instructions to: Receive a request for a network resource on a network, the request including first trust information representing one or more attributes of the source of the request; The second trust information is generated at least in part based on the first trust information and additional trust information obtained separately from the request, wherein the additional trust information is associated with the source of the request; The request is augmented using the second trust information to generate an augmented request; and The action to be taken regarding the request for expansion is determined based on the assessment of the second trust information.

[0119] Clause 17. The system as described in Clause 16, wherein the one or more processors are further programmed by the executable instructions to determine, from the first trust information, an attribute among the one or more attributes of the source of the request, wherein the attribute includes: an identifier of a user account, an attribute of the user account, an identifier of a device, or an attribute of the device.

[0120] Clause 18. The system as described in Clause 16, wherein the one or more processors are further programmed by the executable instructions to access the additional trust information at least in part based on the association between the additional trust information and the source of the request, wherein the additional trust information includes: the history of the source of the request, a security risk score associated with the source of the request, or the location of the source of the request.

[0121] Clause 19. The system as described in Clause 16, wherein, in order to utilize the second trust information to augment the request to generate the augmented request, the one or more processors are further configured to add the second trust information to one of: the header or encapsulation header of the request.

[0122] Clause 20. The system as described in Clause 16, wherein the action to be taken includes one of the following: transmitting the extended request to the network resource based on the second trust information satisfying an access policy; transmitting the extended request to a firewall configured to apply an access policy to determine whether to transmit the extended request to the network resource; or transmitting the extended request through a segment of a plurality of segments of the network, the segments being selected based on the second trust information satisfying an access policy.

[0123] Clause 21. A system comprising: A computer-readable storage medium storing executable instructions; and At least one computing device, the at least one computing device communicating with the computer-readable storage medium and programmed by the executable instructions to: Receive a first set of information defining one or more trust providers, wherein the one or more trust providers provide information about at least the following: The first identification information of the user requesting access to a web application available on the cloud provider's network; and Second identification information about the user's device; Receive a second set of information defining one or more application groups, wherein each of the one or more application groups includes one or more network applications available on the cloud provider's network; The one or more application groups are created based at least in part on the second set of information; Receive a third set of information defining a network application policy, wherein the network application policy includes instructions for the following: Based at least in part on the first set of information, determine to map the first identification information and the second identification information to at least: Access level of at least one of the one or more application groups; The access level of the network segment of the cloud provider's network; A sharing option for sharing the first identification information and the second identification information with a network firewall on the cloud provider's network; or Denial of mapping to the network segment or the application group; and Configure a dynamic access control system to implement the network application strategy.

[0124] Clause 22. The system as described in Clause 21, wherein the access level of the at least one group of applications is based at least in part on the first identification information, including the employment role associated with the user.

[0125] Clause 23. The system as described in Clause 21, wherein the access level of the network segment of the cloud provider network is based at least in part on the second identification information indicating whether the user's device is a mobile device or a desktop computing device.

[0126] Clause 24. The system as described in Clause 21, wherein the sharing option is based at least in part on the second identification information, which consists at least of the geographic location of the user's device.

[0127] Clause 25. A computer-implemented method, the method comprising: Under the control of a computing system associated with a cloud provider network, the computing system includes one or more computer processors configured to execute specific instructions: Receive trust provider data, which specifies one or more trust information items that can be used to control access to network resources available on the cloud provider network, wherein the network resources are associated with clients on the cloud provider network; Receive policy data associated with an access policy from a client computing system associated with the client, wherein the policy data specifies one or more assessments to be applied to the trust information, and wherein access to the network resource is determined based on the one or more assessments; and Configure the access control system on the cloud provider network based on the access policy to control access to the network resources.

[0128] Clause 26. A computer-implemented method as described in Clause 25, wherein configuring the access control system to control access to the network resource based on the access policy includes configuring the access control system to determine whether trust information associated with a request for the network resource satisfies one or more criteria, and wherein the request is sent to the network resource in response to determining that the request satisfies the one or more criteria.

[0129] Clause 27. The computer-implemented method as described in Clause 25, wherein configuring the access control system based on the access policy to control access to the network resource further comprises configuring the access control system to obtain trust information from the header of a request for the network resource, wherein the trust information includes one of: device information about one or more characteristics of the device initiating the request, or identification information about one or more characteristics of a user account associated with the request.

[0130] Clause 28. A computer-implemented method as described in Clause 25, wherein receiving the policy data includes receiving a definition of a transformation to be applied to the request for the network resource based on an evaluation result of trust information associated with the request.

[0131] Clause 29. A computer-implemented method as described in Clause 25, wherein configuring the access control system based on the access policy includes configuring the access control system to modify one of the following: a network endpoint to which a request for the network resource is to be sent, a routing path through which the request is to be sent, a routing table to which the router to which the request is to be sent, or a network segment to which the request is to be sent.

[0132] Clause 30. A computer-implemented method as described in Clause 25, wherein configuring the access control system based on the access policy includes configuring the access control system to modify one of the following: the role of the user account that initiated the request for the network resource, or the security group to which the user account is assigned.

[0133] Clause 31. The computer-implemented method as described in Clause 25, wherein configuring the access control system based on the access policy includes configuring the access control system to apply an evaluation to a combination of different types of trust information, the combination including two or more of the following: device characteristic information, user identification information, location information, or risk scoring information.

[0134] Clause 32. The computer-implemented method as described in Clause 25, the method further comprising: causing the presentation of a graphical user interface, wherein the graphical user interface includes one or more user interface controls configured to receive input regarding a trust provider and trust information items, wherein receiving the trust provider data includes receiving the input via the one or more user interface controls.

[0135] Clause 33. The computer-implemented method as described in Clause 25, the method further comprising: causing the presentation of a graphical user interface, wherein the graphical user interface includes one or more user interface controls configured to receive input regarding an evaluation associated with the access policy, wherein receiving the policy data includes receiving the input via the one or more user interface controls.

[0136] Clause 34. A system comprising: A computer-readable storage medium storing executable instructions; and One or more processors, the one or more processors communicating with the computer-readable storage and programmed by the executable instructions to: Receive trust provider data, which specifies one or more trust information items that can be used to control access to network resources available on the network; Receive policy data associated with an access policy, wherein the policy data specifies one or more assessments to be applied to the trust information, and wherein access to the network resource is determined based on the one or more assessments; and Configure the access control system on the network based on the access policy to control access to the network resources.

[0137] Clause 35. The system as described in Clause 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to determine whether trust information associated with a request for the network resource satisfies one or more criteria, and wherein the request is sent to the network resource in response to determining that the request satisfies the one or more criteria.

[0138] Clause 36. The system as described in Clause 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to obtain trust information from the header of a request for the network resource, wherein the trust information includes one of: device information about one or more characteristics of the device initiating the request, or identification information about one or more characteristics of a user account associated with the request.

[0139] Clause 37. The system as described in Clause 34, wherein the policy data includes a definition of a transformation to be applied to a request for the network resource based on an evaluation of trust information associated with the request.

[0140] Clause 38. The system as described in Clause 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to modify one of the following: the network endpoint to which a request for the network resource is sent, the routing path through which the request is sent, the routing table to which the router to which the request is sent, or the network segment to which the request is sent.

[0141] Clause 39. The system as described in Clause 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to modify one of the following: the role of the user account that initiated the request for the network resource, or the security group to which the user account is assigned.

[0142] Clause 40. The system as described in Clause 34, wherein, in order to configure the access control system to control access to the network resources based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to apply an evaluation to a combination of different types of trust information, the combination including two or more of the following: device characteristic information, user identification information, location information, or risk scoring information.

[0143] All methods and tasks described herein can be performed and fully automated by a computer system. In some cases, the computer system may include multiple different computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate via a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in memory or other non-transitory computer-readable storage media or devices (e.g., solid-state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions or implemented in the computer system's dedicated circuitry (e.g., ASICs or FPGAs). In cases where the computer system includes multiple computing devices, these devices may, but need not, be located in the same location. The results of the disclosed methods and tasks can be persistently stored by transforming physical storage devices such as solid-state memory chips or disks into different states. In some embodiments, the computer system may be a cloud-based computing system whose processing resources are shared by multiple different business entities or other users.

[0144] Depending on the implementation, certain actions, events, or functions of any process or algorithm described herein may be performed in a different order, or may be added, combined, or omitted entirely (e.g., not all described operations or events are necessary for the practical algorithm). Furthermore, in some implementations, operations or events may be performed simultaneously rather than sequentially, for example, through multithreading, interrupt handling, or on multiple processors or processor cores or other parallel architectures.

[0145] The various exemplary logic blocks, modules, routines, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware or a combination of electronic hardware and computer software. To clearly illustrate this interchangeability, the various exemplary components, blocks, modules, and steps have been generally described above in accordance with their functionality. Whether such functionality is implemented as hardware or as software running on hardware depends on the specific application and design constraints imposed on the system as a whole. For each specific application, the described functionality may be implemented in different ways, but such implementation decisions should not be interpreted as departing from the scope of this disclosure.

[0146] Furthermore, the various exemplary logic blocks and modules described in conjunction with the embodiments disclosed herein can be implemented or executed by machines designed to perform the functions described herein, such as processor devices, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof. The processor device may be a microprocessor, but alternatively, it may be a controller, microcontroller, or state machine, a combination thereof, etc. The processor device may include electronic circuitry configured to process computer-executable instructions. In another embodiment, the processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. The processor device may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors along with a DSP core, or any other such configuration. Although this document primarily describes digital technologies, the processor device may also primarily include analog components. For example, some or all of the algorithms described herein may be implemented in analog circuitry or mixed analog and digital circuitry. Computing environments can include any type of computer system, including, but not limited to, microprocessor-based computer systems, mainframe computers, digital signal processors, portable computing devices, device controllers, or computing engines within appliances.

[0147] Elements of the methods, processes, routines, or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in software modules executed by a processor device, or a combination of both. Software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of non-transitory computer-readable storage medium. Exemplary storage media may be coupled to a processor device such that the processor device can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor device. The processor device and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. Alternatively, the processor device and storage medium may reside as discrete components in the user terminal.

[0148] Unless otherwise specifically stated, or otherwise understood as used in the context herein, the conditional language used herein (such as, in addition to, “can,” “may,” “may,” “may,” “may,” “for example,” etc.) is generally intended to convey that certain embodiments include certain features, elements, or steps that are not included in other embodiments. Therefore, such conditional language is generally not intended to imply that one or more embodiments require features, elements, and / or steps in any way, or that one or more embodiments must include a means for determining, with or without further input or prompting, whether such features, elements, and / or steps are included or performed in any particular embodiment. The terms “comprising,” “including,” “having,” etc., are synonymous and used inclusively in an open-ended manner, without excluding additional elements, features, actions, operations, etc. Furthermore, the term “or” is used in its inclusive sense (and not exclusively) such that, when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.

[0149] Unless otherwise specifically stated, disjunctive language such as the phrase “at least one of X, Y or Z” is understood in context to generally represent that items, terms, etc., can be X, Y or Z or any combination thereof (e.g., X, Y and / or Z). Therefore, such disjunctive language is generally not intended and should not imply that certain embodiments require the presence of at least one of X, at least one of Y or at least one of Z.

[0150] Unless otherwise expressly stated, articles such as “a” or “an” should generally be understood to include one or more of the described items. Thus, phrases such as “a device configured to…” are intended to include one or more of the described devices. Such one or more of these devices may also be collectively configured to perform the stated description. For example, “a processor configured to perform descriptions A, B, and C” may include a first processor configured to perform description A, which operates in conjunction with a second processor configured to perform descriptions B and C.

[0151] While the above detailed description has shown, described, and pointed out novel features applicable to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the illustrated apparatus or algorithm may be made without departing from the scope of this disclosure. It will be appreciated that certain embodiments described herein may be embodied in forms that do not provide all the features and benefits set forth herein, as some features may be used or practiced separately from other features. The scope of certain embodiments disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes falling within the meaning and scope of the equivalents of the claims will be included within the scope of the claims.

Claims

1. A trust-based dynamic access control system, the system comprising: A computer-readable storage medium storing executable instructions; as well as At least one computing device, the at least one computing device communicating with the computer-readable storage medium and programmed by the executable instructions to: Receive requests to access web applications from the user's device; In association with the request, trust information generated by one or more trust providers is received, wherein the trust information at least indicates: Regarding the user's first identification information; as well as Second identification information about the user's device; A trust information data structure is created using the first identification information and the second identification information; Access network application policies, wherein the network application policies map the trust information data structure to one or more of the following: (i) the access level of the network application, (ii) the access level of a network segment of the cloud provider network, (iii) instruction routing to a network firewall, or (iv) instruction routing to a network router. The request or aspects thereof are transformed based on the trust information data structure, wherein the aspects thereof include at least one of role, security context and target Internet Protocol address; Access or routing information is determined at least in part based on the network application policy and the trust information; as well as Access or routing actions are performed based at least in part on the access or routing information.

2. The system of claim 1, wherein the trust information generated by the one or more trust providers is requested and provided by a browser extension executed on the user's device via Hypertext Transfer Protocol.

3. The system of claim 1, wherein the access or routing information includes at least one of the following: The access level of the network application; Access levels for network segments; Command routing to the network firewall; Command routing to the network router; or Denied access to the web application.

4. The system of claim 1, wherein the access or routing action includes at least one of the following: Provide the user with access levels to the network application; Provide the user with access to the network segment; The trust information is routed to the network firewall; The trust information is routed to the network router; or Access to the web application is denied.

5. A computer-implemented method, the method comprising: Under the control of a computing system associated with a cloud provider network, the computing system includes one or more computer processors configured to execute specific instructions: Receive a request for network resources on the cloud provider's network, the request including first trust information representing one or more attributes of the source of the request; The second trust information is generated at least in part based on the first trust information and additional trust information obtained separately from the request, wherein the additional trust information is associated with the source of the request; The request or aspects thereof are transformed based on the second trust information, wherein the aspects thereof include at least one of role, security context and target Internet Protocol address; as well as The action to be taken regarding the transformed request is determined based on the assessment of the second trust information.

6. The computer-implemented method according to claim 5, further comprising: The first trust information is used to determine one or more attributes of the source of the request, wherein the attributes include: an identifier of a user account, attributes of the user account, an identifier of a device, or attributes of the device.

7. The computer-implemented method according to claim 5, further comprising: The additional trust information is accessed at least in part based on the association between the additional trust information and the source of the request, wherein the additional trust information includes: the history of the source of the request, a security risk score associated with the source of the request, or the location of the source of the request.

8. The computer-implemented method according to claim 5, further comprising: The additional trust information is received before the request is received.

9. The computer-implemented method of claim 5, wherein generating the second trust information includes generating a trust information data structure using a plurality of trust information items selected by the client and associated with the network resource.

10. The computer-implemented method of claim 5, wherein using the second trust information to transform the request to generate a transformed request comprises adding the second trust information to one or more headers of the request.

11. The computer-implemented method of claim 5, wherein using the second trust information to transform the request to generate a transformed request comprises adding the second trust information to one or more encapsulation headers, wherein the request packets are encapsulated for transmission.

12. The computer-implemented method according to claim 5, further comprising: Remove at least a portion of the header containing the first trust information from the request.

13. The computer-implemented method of claim 5, wherein determining the action to be taken regarding the transformed request based on an assessment of the second trust information comprises: Based on the second trust information, the access policy is satisfied to determine whether the transformed request will be transmitted to the network resource.

14. The computer-implemented method of claim 5, wherein determining the action to be taken regarding the transformed request based on an assessment of the second trust information comprises: The system determines whether to transmit the transformed request to the firewall, which is configured to enforce access policies to determine whether to transmit the transformed request to the network resource.

15. The computer-implemented method of claim 5, wherein determining the action to be taken regarding the transformed request based on an assessment of the second trust information comprises: The transformed request is transmitted through a segment of a plurality of segments in the cloud provider network, the segments being selected based on the second trust information satisfying the access policy.

16. A trust-based dynamic access control system, the system comprising: A computer-readable storage medium storing executable instructions; as well as One or more processors, the one or more processors communicating with the computer-readable storage and programmed by the executable instructions to: Receive a request for a network resource on a network, the request including first trust information representing one or more attributes of the source of the request; The second trust information is generated at least in part based on the first trust information and additional trust information obtained separately from the request, wherein the additional trust information is associated with the source of the request; The request or aspects thereof are transformed based on the second trust information, wherein the aspects thereof include at least one of role, security context and target Internet Protocol address; as well as The action to be taken regarding the transformed request is determined based on the assessment of the second trust information.

17. The system of claim 16, wherein the one or more processors are further programmed by the executable instructions to determine, from the first trust information, an attribute among the one or more attributes of the source of the request, wherein the attribute includes: The identifier of the user account, the attributes of the user account, the identifier of the device, or the attributes of the device.

18. The system of claim 16, wherein the one or more processors are further programmed by the executable instructions to access the additional trust information at least in part based on the association between the additional trust information and the source of the request, wherein the additional trust information includes: The history of the source of the request, the security risk score associated with the source of the request, or the location of the source of the request.

19. The system of claim 16, wherein, in order to use the second trust information to transform the request to generate a transformed request, the one or more processors are further configured to add the second trust information to one of the following: a header or encapsulation header of the request.

20. The system of claim 16, wherein the action to be taken includes one of the following: transmitting the translated request to the network resource based on the second trust information satisfying an access policy; transmitting the translated request to a firewall configured to enforce an access policy to determine whether to transmit the translated request to the network resource; or transmitting the translated request through a segment of a plurality of segments of the network, the segments being selected based on the second trust information satisfying an access policy.

21. A trust-based dynamic access control system, the system comprising: A computer-readable storage medium storing executable instructions; as well as At least one computing device, the at least one computing device communicating with the computer-readable storage medium and programmed by the executable instructions to: Receive a first set of information defining one or more trust providers, wherein the one or more trust providers provide information about at least the following: First identification information about the user requesting access to a network application available on the cloud provider's network; as well as Second identification information about the user's device; Receive a second set of information defining one or more application groups, wherein each of the one or more application groups includes one or more network applications available on the cloud provider's network; The one or more application groups are created based at least in part on the second set of information; Receive a third set of information defining a network application policy, wherein the network application policy includes instructions for the following: Based at least in part on the first set of information, determine to map the first identification information and the second identification information to at least: Access level of at least one of the one or more application groups; The access level of the network segment of the cloud provider's network; A sharing option for sharing the first identification information and the second identification information with a network firewall on the cloud provider's network; or Rejection of mappings to the network segment or the application group; as well as Configure a dynamic access control system to implement the network application policy.

22. The system of claim 21, wherein the access level of the at least one group of applications is based at least in part on the first identification information including the employment role associated with the user.

23. The system of claim 21, wherein the access level of the network segment of the cloud provider network is based at least in part on the second identification information indicating whether the user's device is a mobile device or a desktop computing device.

24. The system of claim 21, wherein the sharing option is at least partially based on the second identification information, the second identification information including at least the geographical location of the user's device.

25. A computer-implemented method, the method comprising: Under the control of a computing system associated with a cloud provider network, the computing system includes one or more computer processors configured to execute specific instructions: Receive trust provider data, which specifies one or more trust information items that can be used to control access to network resources available on the cloud provider network, wherein the network resources are associated with clients on the cloud provider network; Receive policy data associated with an access policy from a client computing system associated with the client, wherein the policy data specifies one or more assessments to be applied to the trust information, and wherein access to the network resource is determined based on the one or more assessments; as well as Configure the access control system on the cloud provider network based on the access policy to control access to the network resources.

26. The computer-implemented method of claim 25, wherein configuring the access control system based on the access policy to control access to the network resource comprises: The access control system is configured to determine whether trust information associated with a request for the network resource meets one or more criteria, wherein the request is sent to the network resource in response to the determination that the request meets the one or more criteria.

27. The computer-implemented method of claim 25, wherein configuring the access control system based on the access policy to control access to the network resource further comprises: The access control system is configured to obtain trust information from the header of a request for the network resource, wherein the trust information includes one of the following: device information about one or more characteristics of the device initiating the request, or identification information about one or more characteristics of the user account associated with the request.

28. The computer-implemented method of claim 25, wherein receiving the policy data comprises: The definition of the transformation to be applied to the request for the network resource is received based on the evaluation results of the trust information associated with the request.

29. The computer-implemented method of claim 25, wherein configuring the access control system based on the access policy includes configuring the access control system to modify one of the following: the network endpoint to which a request for the network resource is to be sent, the routing path through which the request is to be sent, the routing table to which the router to send the request is to be used, or the network segment to which the request is to be sent.

30. The computer-implemented method of claim 25, wherein configuring the access control system based on the access policy includes configuring the access control system to modify one of the following: the role of the user account that initiated the request for the network resource, or the security group to which the user account is assigned.

31. The computer-implemented method of claim 25, wherein configuring the access control system based on the access policy comprises: The access control system is configured to evaluate the application of different types of trust information, including two or more of the following: device characteristic information, user identification information, location information, or risk scoring information.

32. The computer-implemented method according to claim 25, further comprising: This results in the presentation of a graphical user interface, wherein the graphical user interface includes one or more user interface controls configured to receive input about a trust provider and trust information items, wherein receiving the trust provider data includes receiving input via the one or more user interface controls.

33. The computer-implemented method according to claim 25, further comprising: This results in the presentation of a graphical user interface, wherein the graphical user interface includes one or more user interface controls configured to receive input regarding an evaluation associated with the access policy, wherein receiving the policy data includes receiving input via the one or more user interface controls.

34. A trust-based dynamic access control system, the system comprising: A computer-readable storage medium storing executable instructions; as well as One or more processors, the one or more processors communicating with the computer-readable storage and programmed by the executable instructions to: Receive trust provider data, which specifies one or more trust information items that can be used to control access to network resources available on the network; Receive policy data associated with an access policy, wherein the policy data specifies one or more assessments to be applied to the trust information, and wherein access to the network resource is determined based on the one or more assessments; as well as Configure the access control system on the network based on the access policy to control access to the network resources.

35. The system of claim 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to determine whether trust information associated with a request for the network resource satisfies one or more criteria, and wherein the request is sent to the network resource in response to determining that the request satisfies the one or more criteria.

36. The system of claim 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to obtain trust information from the header of a request for the network resource, wherein the trust information includes one of: device information about one or more characteristics of the device initiating the request, or identification information about one or more characteristics of a user account associated with the request.

37. The system of claim 34, wherein the strategy data includes: The definition of the transformation to be applied to the request for the network resource is based on the evaluation results of the trust information associated with the request.

38. The system of claim 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to modify one of the following: the network endpoint to which a request for the network resource is to be sent, the routing path through which the request is to be sent, the routing table to which the router to which the request is to be sent, or the network segment to which the request is to be sent.

39. The system of claim 34, wherein, in order to configure the access control system to control access to the network resource based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to modify one of the following: the role of the user account that initiated the request for the network resource, or the security group to which the user account is assigned.

40. The system of claim 34, wherein, in order to configure the access control system to control access to the network resources based on the access policy, the one or more processors are further programmed by the executable instructions to configure the access control system to apply an evaluation to a combination of different types of trust information, the combination including two or more of the following: device characteristic information, user identification information, location information, or risk scoring information.

Images