Controlling access entitlement for networking device data

Techniques are provided for controlling access entitlement for networking device data. In one example, a geographic location of a networking device is determined. A request to access data associated with the networking device is obtained from a user device. A user parameter of a user associated with the user device is determined. An access policy that controls access to the data based on the geographic location of the networking device and the user parameter is identified. The request to access the data is permitted or denied based on the geographic location of the networking device, the user parameter, and the access policy.

TECHNICAL FIELD

The present disclosure relates to computer networking.

BACKGROUND

Data sovereignty requirements—which govern where and/or how data can be stored—are quickly being adopted by various entities (e.g., governments and private companies). These data sovereignty requirements often vary with geographic region (e.g., country, province, etc.). Furthermore, many of the entities that must adhere to these requirements use networking devices located throughout the world. These entities will continue to have increasingly complex security and access requirements.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Techniques are provided herein for controlling access entitlement for networking device data. In one example embodiment, a geographic location of a networking device is determined. A request to access data associated with the networking device is obtained from a user device. A user parameter of a user associated with the user device is determined. An access policy that controls access to the data based on the geographic location of the networking device and the user parameter is identified. The request to access the data is permitted or denied based on the geographic location of the networking device, the user parameter, and the access policy.

Example Embodiments

FIG.1illustrates an example system100configured to control access entitlement for networking device data. System100includes user device105, Multi-Factor Authentication (MFA) server110, Internet115, and Software as a Service (SaaS) cloud120. SaaS cloud120includes access entitlement server140. System100further includes remote network125, device manager/controller130(e.g., hosted on one or more servers), and networking devices135(1)-135(3). Networking devices135(1)-135(3) may include any suitable networking devices (e.g., switches, routers, etc.), and may be geographically dispersed. While three networking devices135(1)-135(3) are shown in the example ofFIG.1, it will be appreciated that techniques described herein may be compatible with any suitable number of networking devices.

Conventional approaches struggle to provide access control for geographically dispersed networking devices, particularly in view of increasingly complex data sovereignty requirements. For example, given various country-specific laws related to data and service access based on complex entitlement needs, conventional approaches cannot adequately handle entities with offices around the world. Such entities have networking devices physically located in different countries, requiring adherence to the various corresponding national data sovereignty policies. Conventional techniques are ill-equipped to align network management with data sovereignty policies by permitting users in certain countries to work on networking devices only where allowed by data sovereignty rules.

This problem is complicated even further by Virtual Private Networks (VPNs). VPNs can be used to access parts of a network by giving the appearance that a user is in one location (e.g., country), when in reality the user is in another location. For example, many video streaming services offer content unique to a given geographic region based on where the video streaming services are licensed to stream that content. However, a user can easily bypass location requirements with a VPN to give the appearance that the user is in a location where the desired content is offered.

Accordingly, access entitlement server140is provided that is configured with access entitlement logic145. Access entitlement logic145causes access entitlement server140to control access entitlement for data associated with networking devices135(1)-135(3) in accordance with operations described herein. Access entitlement logic145, or portions of access entitlement logic145, may be located on any suitable networking entity(ies), such MFA server110, SaaS cloud120, device manager130, and/or access entitlement server140.

In one example, device manager130may identify the respective geographic locations of networking devices135(1)-135(3). For instance, device manager130may maintain the respective geographic locations of networking devices135(1)-135(3) and various services during deployment. Device manager130may assign location labels to networking devices135(1)-135(3) and provide the location labels to access entitlement server140via remote network125. The location labels may indicate the respective geographic locations of networking devices135(1)-135(3). Access entitlement server140may determine the respective geographic locations of networking devices135(1)-135(3) based on the location labels. It will be appreciated that access entitlement server140or any other suitable network entity may determine the respective geographic locations of networking devices135(1)-135(3) using any suitable techniques, such as by obtaining indications of the respective geographic locations directly from networking devices135(1)-135(3).

Device manager130and/or access entitlement server140may group/classify networking devices135(1)-135(3) based on geographic region. The geographic region may be an access entitlement region that has a unique set of networking device/data access policies. The geographic region may be government-mandated or entity-specific. The specific entity may include any suitable organization, enterprise, corporation, government, company, etc.

Device manager130may further dynamically auto-generate respective Location-Based Access Criticality (LBAC) labels for networking devices135(1)-135(3). The LBAC labels may be unique labels that indicate respective target access control levels for networking devices135(1)-135(3). For example, a first target access control level may permit many users to access networking device135(1), a second target access control level may permit relatively few users to access networking device135(2), and a third target access control level may permit a moderate number of users to access networking device135(3).

In one example, device manager130may dynamically auto-generate the respective LBAC labels based on the respective topological locations of networking devices135(1)-135(3) in one or more networks. A topological location refers to where in the network topology as networking devices resides (such as in terms of neighboring, next hop devices, etc.). Device manager130may auto-label networking devices135(1)-135(3) for criticality of operations performed by networking devices135(1)-135(3). The auto-labeling may be based on the roles/types of networking devices135(1)-135(3) in the one or more networks/topologies. For instance, core switches may have higher criticality than access switches within a network because core switches may handle highly-sensitive, global network traffic. As a result, device manager130may assign LBAC labels indicating a higher target access control level for core switches than for access switches. Thus, LBAC labels may represent a level of security to be associated with a given networking device based on the topological location of the networking device in a network. In one example, the LBAC labels may include an indication of device sensitivity on a scale from one to ten.

Device manager130may share the LBAC labels with access entitlement server140directly or via integration with SaaS cloud120. As a result, access entitlement server140may obtain the LBAC labels from device manager130. However, access entitlement server140may obtain the LBAC labels using any suitable techniques; for example, access entitlement server140may bypass device manager130to classify networking devices135(1)-135(3) by auto-generating the LBAC labels and assigning the LBAC labels to networking devices135(1)-135(3).

Access entitlement server140may store access policy150. Access policy150may include custom, entity-defined rules that control when/which users can access data associated with networking devices135(1)-135(3). Access policy150may be a target management location policy based on a target location (e.g., a location of networking device135(1)) and current user location. Access policy150may be based on any suitable parameter, and the number/types of parameters may be customizable by the entity. Access policy150may pertain to one or more specific countries/regions/entities/etc.

In one example, access policy150may be based on one or more access entitlement characteristics of networking devices135(1)-135(3), such as configurations of networking devices135(1)-135(3), location labels of networking devices135(1)-135(3), the LBAC labels of networking devices135(1)-135(3), the location of data associated with networking devices135(1)-135(3), etc. For example, access entitlement server140may map the location of each networking device135(1)-135(3) to access policy150. In another example, access policy150may be based on user parameters/characteristics defining which users are permitted access. Examples of user parameters include the physical location or citizenship of the user requesting access, user identity, user credential strength, etc. In still another example, access policy150may be based on a third-party rule(s) database (e.g., a third-party regulatory policy engine) that provides policies defined by third-parties (e.g., regional data sovereignty laws).

SaaS cloud120may provide a user interface tool/portal that permits a network administrator of the entity to create/define access policy150. For example, an entity may define access policy150to control access to data associated with networking devices135(1)-135(3) (e.g., networking device configuration). Any suitable mechanism may be used to enable entities to consume LBAC labels to define general or intent-based policies. For example, the user interface may display various options for defining access policy150in a drop-down menu or any other suitable format. Or, network administrator may manually mark/select/tag one or more of networking devices135(1)-135(3) with access entitlement characteristics.

SaaS cloud120and/or access entitlement server140may parse entity selections of access policy150and convert the entity selections into a format suitable for consumption by access entitlement server140. Access entitlement server140may process inputs from the entity, device manager130, and/or a third-party rule database to generate access policy150. Access policy150may include any suitable rules such as government laws, local company policies, rules for subcontracted companies, etc. Specific examples of access policy150are:Access to sensitive networking devices in a network must be provided to specific engineers from a specific third-party company based on local and company policies.Citizenship from a specific country is required for a user to design and manage a particular network or set of networking devices within a network.Access to networking device configuration and other critical documents can be accessed only by trusted users based on user location and citizenship.An engineer must be physically located in the United States of America (USA) to access internal networking devices for the USA federal government.Any device in a Toronto-based data center can be accessed only by a user in North America.For a defense organization where network access and configuration rules are created for an entire region, any networking device in Germany can only be accessed by German citizens located in Germany.A core router in Germany can only be accessed by German citizens located in Germany, whereas an access switch in the USA can be accessed by USA or Canadian citizens located anywhere in the world.Core switches require both user location and citizenship verification.A core device and its configuration can be accessed by employees of a partner company who have American citizenship and a local presence.A network fabric in Canada that serves the Canadian armed forces may only be managed by authorized individuals who are physically present at a known military base.To access an access switch, the user must be a USA citizen, but to access a core switch, the user must be a USA citizen, physically located in the USA during access, and an employee of a specific contractor.

User155may cause user device105to send a request to access data associated with one or more of networking devices135(1)-135(3) (e.g., networking device135(1)). The request may include a request to access (e.g., manage) networking devices135(1)-135(3), configurations of networking devices135(1)-135(3), one or more services, etc. Access entitlement server140(and/or any other suitable network entity such as MFA server110or an Authentication, Authorization, and Accounting (AAA) server) may obtain the request and authenticate user155against a directory store for identification/validation and/or additional information (e.g., user parameters). Access entitlement server140may determine a user parameter of user155, such as a citizenship of user155. One or more user parameters applied and used by access entitlement server140may be integrated into active directories that may be referenced by the AAA server and/or access entitlement server140for use in authorization. Thus, access entitlement server140may interface with one or more identity servers (e.g., AAA server) for user validation and enable the addition of customized parameters in the authorization.

In one example, an MFA-based authentication system may obtain input from user device105to help authenticate user device105. MFA server110may help authenticate user155by requesting/fetching user parameters such as the geographic location of user155. For instance, access entitlement server140may obtain an indication of the geographic location of user155from an MFA process (e.g., MFA server110). More specifically, in response to the request from user device105, MFA server110may send a push notification to user device105with a request for geographic location information. An MFA agent (e.g., a plugin) on user device105may access the geographic location information of user device105and relay the geographic location information to MFA server110as part of the push notification response. The push notification response may also/alternatively include information input by user155into user device105.

The geographic location information of user device105may include Global Positioning System (GPS) data, cellular location data (e.g., cellular triangulation, the cellular global identity of the cellular tower to which user device105is connected, cell/antenna identifier, etc.), footprint location database information/services (e.g., crowd-sourced location evaluation data), dead-reckoning inertial sensors, Access Points (APs) identifiers (e.g., AP Media Access Control (MAC) addresses), Long-Term Evolution (LTE) Positioning Protocol (LPP) values, Fine Time Measurement (FTM) values, etc. The geographic location information may include any suitable data.

Because individual location values can be attacked (e.g., GPA poisoning or spoofing), the MFA agent may collect geographic location information from a plurality of sources and provide, to access entitlement server140, a corresponding plurality of candidate geographic locations of user155. Access entitlement server140may obtain the plurality of candidate geographic locations of user155, compare each of the plurality of candidate geographic locations against each other candidate geographic location, and derive the geographic location of user155.

Any suitable network entity, such as the MFA agent and/or MFA server110, may also/alternatively perform these operations. For example, the MFA agent may parse through the candidate geographic location values returned, and adopt the values that are most commonly returned by the various sources. The MFA agent may also return a failure notice if no common values are observed. MFA server110may contact access entitlement server140, share the location of user155, and/or reference access policy150based on the location of user155. As shown inFIG.1, access entitlement server140may be a standalone server in SaaS cloud120that is integrated with an MFA process; alternatively, access entitlement server140may be integrated directly with MFA server110. Other embodiments may be envisioned.

A specific example for deriving the geographic location of user155from multiple candidate geographic locations is provided as follows. In this example, the candidate geographic locations include a series of GPS values, a series of LTE LPP values, a series of values through FTM, and one or more crowd-sourced evaluations. Each location value may be a set of latitude and longitude coordinates. The values may be retained for a given interval (e.g., a time window of five seconds).

A first candidate geographic location, provided by a first source, may be a=(3,5); a second candidate geographic location, provided by the first source (within the given interval), may be b=(5,5); a third candidate geographic location, provided by a second source, may be c=(3,2); and a fourth candidate geographic location, provided by a third source, may be d=(3,4). Each candidate geographic location is compared against every other candidate geographic location. Taking d=(3,4), for example, a=(3,5), b=(5,5), and c=(3,2) are subtracted from d=(3,4) to arrive at a set of differences between d and a, b, and c. The resulting set of differences is d-a=(0,−1), d−c=(−2,−1), and d−c=(0,2). Although this example uses coordinate differences, the distance to the point may be computed, e.g., using a Pythagorean transformation.

Table 1 below illustrates the results of the differences comparison in the form of a matrix. A value of 1 indicates that the corresponding candidate geographic location in the left-most column is closer to d than the corresponding candidate geographic location in the top row. As shown, a is closer to d than both b and c; b is further from d than both a and c; and c is further from d than a but closer than b. As a result, a is the closest to d, followed by c, and then b. The ranked list of differences for candidate geographic location d may be a in first, c in second, and b in third. The absolute values of the differences may be used to arrive at Table 1.

This process may be repeated for each of candidate geographic locations a, b, and c by ranking all the other candidate geographic locations based on their respective distances to the chosen candidate geographic location. A ranked list may be compiled for each candidate geographic location a, b, c, and d. A Condorcet table may be built by adding votes from each of the ranked lists together to provide a sum of votes, where each vote represents the proximity of the other candidate locations to the current location being examined. At each iteration of adding the votes to the Condorcet table, the entry for the candidate geographic location that is being compared to the other candidate geographic locations may be missing. In that case, the vote for that candidate geographic location may be counted as zero. Candidate geographic locations that are close to many other candidate geographic locations may receive high scores, and candidate geographic locations that are far from many other candidate geographic locations may receive low scores.

The geographic location of user155may be derived/estimated/selected from the Condorcet table by selecting the location with the highest corresponding vote count. The Condorcet table may rank the locations that are closest to one another, and the winner may be the location that has the highest count of votes (e.g., the location that is closest (or equal) to the largest number of other location values returned by the different location sources. Thus, the Condorcet table may provide the winner, and the location provided by the winner may be considered the geographic location of user155.

This process may reveal nodules/groups of candidate geographic locations that have high scores relative to each other, but have low scores relative to the other candidate geographic locations. This may signify that the candidate geographic locations form geographic clusters where user device105might be located. For example, all GPS and LPP values might be accurate, but the LPP values might be systematically biased in one direction (e.g., because a cell tower has an inaccurate configuration). This process may enable checking whether sets of candidate geographic locations that are coherent with each other are also coherent with the other candidate geographic locations. Thus, static error may be distinguished from dynamic error. In one example, a reverse bias may be applied and the Condorcet table may be recomputed to compensate for the error.

In a real-world deployment, {latitude, longitude} coordinate values may have nine digits after the period. As a result, the difference computation may occur at that scale (e.g., having nine digits after the period) rather than at the integer scale. Also, some inaccuracies in the measurements may be considered acceptable. If a {latitude, longitude} coordinate value has nine possible digits (xx.xxxxxxxxx), seven or eight digit values may be acceptable. Therefore, it may be possible to obtain two different measurements for the same location from the same technique. It may also be possible to obtain the same measurements for the same location from different techniques (at the accepted accuracy scale). In that case, both measurements may win against each other. For example, if F and G have the same location, F wins against G and G wins against F.

Access entitlement server140may obtain the derived geographic location of user155with the request (from user device105) to access the data associated with networking device135(1). Access entitlement server140may identify access policy150, which may control access to data associated with networking device135(1) based on the geographic location of networking device135(1), one or more user parameters (e.g., the geographic location of user155, the citizenship of user155, etc.), and/or the LBAC label of networking device135(1).

Based on the geographic location of networking device135(1), one or more user parameters, access policy150, and/or the LBAC label of networking device135(1), access entitlement server140may permit or deny the request to access the data. For example, access entitlement server140may generate an entitlement value (e.g., deny, limited access—read/write, etc.) based on information received from device manager130(e.g., hosted device and services) as well as local and customer-specific rules. The entitlement value may be converted to a specific access type or Terminal Access Controller Access-Control System plus (TACACS+) based authorization.

Access entitlement server140may process access policy150to generate the access entitlement authorization based on different inputs/components from SaaS cloud120, device manager130, third-party rule databases, MFA server110, etc. Access entitlement server140may be integrated in, and interact with, the authentication MFA workflow to consume the entitlement value. As a result, access entitlement server140may process the request from MFA server110based on both user and service location, and return the authorization (if appropriate) back to MFA server110. If authenticated and authorized based on the access policy150, location information, etc., user155may be allowed to access networking device135(1) and/or configuration data associated with networking device135(1) based on the entitlement value provided by access entitlement server140. Access entitlement server140may grant access to only select portions of a network in adherence with access policy150.

In one example, user155may be a computer networking engineer who is trying to access networking device135(1) (e.g., a customer networking device). The engineer may be validated and authorized using a location-aware MFA process that validates the physical location of the engineer. Access entitlement server140may check the LBAC label of networking device135(1), access policy150(e.g., a customer-defined policy), and other regulations. Access entitlement server140may further generate the entitlement value and pass the entitlement value to MFA server110for proper authorization. If access policy150allows a person from the engineer's country or region to manage networking device135(1), and the engineer is validated with the correct credentials, permission may be granted.

Access entitlement server140may audit which users (e.g., user155) accessed which networking devices (e.g., networking devices135(1)-135(3)), what actions were performed by the users, etc., to ensure compliance with access policy150. This may help assure the entity associated with access policy150that access policy150is being met for managed networks/services.

Access entitlement server140may also control how network traffic is routed based on access policy150using additional parameters. Access entitlement server140may, for example, use Border Gateway Protocol (BGP) peering and routing techniques to route the network traffic.

With continuing reference toFIG.1,FIG.2illustrates an example workflow200for controlling access entitlement for networking device135(1). Workflow200illustrates operations210-250performed by access entitlement server140. Inputs260to access entitlement server140may include SaaS cloud120, device manager130, and third-party rule database270. In this example, user155has sent a request (via user device105) to access networking device135(1).

At operation210, access entitlement server140processes the locations of networking device135(1) and user155. Access entitlement server140may obtain the location of networking device135(1) from device manager130, as represented by arrow275. Access entitlement server140may process the location of user155based on the location of user device105. Access entitlement server140may obtain the location of user device105from MFA server110, as represented by arrow280.

At operation220, access entitlement server140processes the LBAC label of networking device135(1). Access entitlement server140may obtain the LBAC label of networking device135(1) from SaaS cloud120and/or device manager130, as represented by arrow275. At operation230, access entitlement server140processes the citizenship of user155. At operation240, access entitlement server140applies access policy150. Access entitlement server140may apply access policy150based on the location of networking device135(1), the location of user device105/user155, the LBAC label of networking device135(1), and the citizenship of user155.

At operation250, access entitlement server140sends the authorization decision and level to MFA server110, as represented by arrow285. The authorization decision may indicate whether user155is permitted to access networking device135(1). MFA server110may, in turn, perform an enforcement action on user device105. For example, if user device105is permitted access, the enforcement action may include moving user device105onto a specific Virtual Local Area Network (VLAN). If user device105is denied access, the enforcement action may include quarantining user device105from networking device135(1) and/or other components of the network. MFA server110may perform any suitable enforcement action.

With continuing reference toFIG.1,FIG.3illustrates an example workflow300for controlling access entitlement for data previously downloaded from networking device135(1). Workflow300may include operations performed by SaaS cloud120, MFA plugin310, MFA server110, and access entitlement server140. MFA plugin310may run on user device105and communicate with MFA server110on behalf of user device105.

SaaS cloud120includes document320, which may be encrypted. Document320may include data that was previously downloaded from networking device135(1) and is now stored in SaaS cloud120. Document320may include any suitable data that is downloadable from networking device135(1), such as configuration information of networking device135(1).

Access entitlement server140(and/or device manager130) may assign an LBAC label to document320. The LBAC label assigned to document320may be the same LBAC label assigned to networking device135(1). For instance, when the configuration data is downloaded from networking device135(1) and document320is created, the LBAC label assigned to networking device135(1) may automatically attach to document320. Document320may also be marked with a corresponding policy (e.g., access policy150).

In this example, user155sends a request (via user device105) to access document320. MFA server110receives the request and invokes MFA plugin310to request user155for authentication information and obtain the physical/geographic location of user155. The physical location of user155may be obtained/derived as described above. MFA server110may fetch the details about the geographic location of user155and other user parameters, which may be stored in an active directory.

MFA server110may provide the user parameter(s) to access entitlement server140. Access entitlement server140identifies access policy150, which controls access to the data based on the geographic location of networking device135(1), the user parameter(s), and/or the LBAC label of document320. Based on the geographic location of networking device135(1), the user parameter(s), the LBAC label of document320, and/or access policy150, access entitlement server140may permit or deny the request to access the data. For example, access entitlement server140may share the entitlement value with MFA server110for access processing (e.g., decrypting document320for access by user155). Thus, access entitlement/validation may be triggered for existing data/configuration files such as document320before user155is permitted to open document320.

Different policies may apply to configuration file documents and corresponding networking devices. For example, access entitlement server140may define one access policy (or set of access policies) for configuration file documents, and another access policy (or set of access policies) for the networking devices from which the configuration file documents are obtained.

Described herein are techniques to provide data access entitlement for a network or service. Data access entitlement may be used for data sovereignty applications and ensuring compliance to local and regulatory laws pertaining to data access. Authorized access may be provided to devices/services based on a unique combination of user/service location, identity, other policy-related functions such as citizenship, etc. Dynamic policy-based access may be provided for networking devices and services by using a unique access entitlement-based method that applies user and device location, requester reputation, criticality of device, and service with a policy framework included as part of a MFA system.

Techniques described herein may apply to other document-based use cases, such as legal documents that are subject to access control. Similar techniques may also apply to non-document-based use cases, such as other file types, such as photos, videos, streaming video, etc. For instance, similar techniques may be invoked when a user requests to stream video content.

Referring toFIG.4,FIG.4illustrates a hardware block diagram of a computing device400that may perform functions associated with operations discussed herein in connection with the techniques depicted inFIGS.1-3. In various embodiments, a computing device, such as computing device400or any combination of computing devices400, may be configured as any entity/entities as discussed for the techniques depicted in connection withFIGS.1-3in order to perform operations of the various techniques discussed herein.

In at least one embodiment, computing device400may include one or more processor(s)402, one or more memory element(s)404, storage406, a bus408, one or more network processor unit(s)410interconnected with one or more network input/output (I/O) interface(s)412, one or more I/O interface(s)414, and control logic420. In various embodiments, instructions associated with logic for computing device400can overlap in any manner and are not limited to the specific allocation of instructions and/or operations described herein.

In at least one embodiment, processor(s)402is/are at least one hardware processor configured to execute various tasks, operations and/or functions for computing device400as described herein according to software and/or instructions configured for computing device400. Processor(s)402(e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, processor(s)402can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. Any of potential processing elements, microprocessors, digital signal processor, baseband signal processor, modem, PHY, controllers, systems, managers, logic, and/or machines described herein can be construed as being encompassed within the broad term ‘processor.’

In at least one embodiment, memory element(s)404and/or storage406is/are configured to store data, information, software, and/or instructions associated with computing device400, and/or logic configured for memory element(s)404and/or storage406. For example, any logic described herein (e.g., control logic420) can, in various embodiments, be stored for computing device400using any combination of memory element(s)404and/or storage406. Note that in some embodiments, storage406can be consolidated with memory elements404(or vice versa), or can overlap/exist in any other suitable manner.

In at least one embodiment, bus408can be configured as an interface that enables one or more elements of computing device400to communicate in order to exchange information and/or data. Bus408can be implemented with any architecture designed for passing control, data and/or information between processors, memory elements/storage, peripheral devices, and/or any other hardware and/or software components that may be configured for computing device400. In at least one embodiment, bus408may be implemented as a fast kernel-hosted interconnect, potentially using shared memory between processes (e.g., logic), which can enable efficient communication paths between the processes.

In various embodiments, network processor unit(s)410may enable communication between computing device400and other systems, entities, etc., via network I/O interface(s)412to facilitate operations discussed for various embodiments described herein. In various embodiments, network processor unit(s)410can be configured as a combination of hardware and/or software, such as one or more Ethernet driver(s) and/or controller(s) or interface cards, Fibre Channel (e.g., optical) driver(s) and/or controller(s), and/or other similar network interface driver(s) and/or controller(s) now known or hereafter developed to enable communications between computing device400and other systems, entities, etc. to facilitate operations for various embodiments described herein. In various embodiments, network I/O interface(s)412can be configured as one or more Ethernet port(s), Fibre Channel ports, and/or any other I/O port(s) now known or hereafter developed. Thus, the network processor unit(s)410and/or network I/O interfaces412may include suitable interfaces for receiving, transmitting, and/or otherwise communicating data and/or information in a network environment.

FIG.5is a flowchart of an example method500for performing functions associated with operations discussed herein. Method500may be performed by any suitable entity, such as access entitlement server140, MFA server110, device manager130, computing device400, etc. At operation510, a geographic location of a networking device is determined. At operation520, a request to access data associated with the networking device is obtained from a user device. At operation530, a user parameter of a user associated with the user device is determined. At operation540, an access policy that controls access to the data based on the geographic location of the networking device and the user parameter is identified. At operation550, the request to access the data is permitted or denied based on the geographic location of the networking device, the user parameter, and the access policy.

In one form, a method is provided. The method comprises: determining a geographic location of a networking device; obtaining, from a user device, a request to access data associated with the networking device; determining a user parameter of a user associated with the user device; identifying an access policy that controls access to the data based on the geographic location of the networking device and the user parameter; and based on the geographic location of the networking device, the user parameter, and the access policy, permitting or denying the request to access the data.

In one example, the method further comprises: obtaining a label indicating a target access control level for the networking device, wherein: identifying the access policy that controls access to the data is based further on the label; and permitting or denying the request to access the data is based further on the label. In a further example, obtaining the label includes: obtaining a label assigned based on a topological location of the networking device in a network.

In one example, determining the user parameter of the user includes: determining a geographic location of the user. In a further example, determining the geographic location of the user includes: obtaining, from a plurality of sources, a plurality of candidate geographic locations of the user; comparing each of the plurality of candidate geographic locations against each other candidate geographic location of the plurality of candidate geographic locations; and in response to comparing each of the plurality of candidate geographic locations against each other candidate geographic location of the plurality of candidate geographic locations, deriving the geographic location of the user. In another further example, determining the geographic location of the user includes: obtaining an indication of the geographic location of the user from a multi-factor authentication process.

In one example, determining the user parameter of the user includes: determining a citizenship of the user.

In one example, obtaining the request to access the data associated with the networking device includes: obtaining a request to access the networking device.

In one example, obtaining the request to access the data associated with the networking device includes: obtaining a request to access data that was previously downloaded from the networking device. In a further example, the method further comprises: assigning, to the data, a label indicating a target access control level for the data, wherein: identifying the access policy that controls access to the data is based further on the label; and permitting or denying the request to access the data is based further on the label.

In another form, an apparatus is provided. The apparatus comprises: a network interface configured to obtain or provide network communications; and one or more processors coupled to the network interface, wherein the one or more processors are configured to: determine a geographic location of a networking device; obtain, from a user device, a request to access data associated with the networking device; determine a user parameter of a user associated with the user device; identify an access policy that controls access to the data based on the geographic location of the networking device and the user parameter; and based on the geographic location of the networking device, the user parameter, and the access policy, permit or deny the request to access the data.

In another form, one or more non-transitory computer readable storage media are provided. The non-transitory computer readable storage media are encoded with instructions that, when executed by a processor, cause the processor to: determine a geographic location of a networking device; obtain, from a user device, a request to access data associated with the networking device; determine a user parameter of a user associated with the user device; identify an access policy that controls access to the data based on the geographic location of the networking device and the user parameter; and based on the geographic location of the networking device, the user parameter, and the access policy, permit or deny the request to access the data.