WO2024010662A1 - Extraction d'état de configuration de locataire et détection de variance - Google Patents

Extraction d'état de configuration de locataire et détection de variance Download PDF

Info

Publication number
WO2024010662A1
WO2024010662A1 PCT/US2023/024630 US2023024630W WO2024010662A1 WO 2024010662 A1 WO2024010662 A1 WO 2024010662A1 US 2023024630 W US2023024630 W US 2023024630W WO 2024010662 A1 WO2024010662 A1 WO 2024010662A1
Authority
WO
WIPO (PCT)
Prior art keywords
configuration
processing unit
configuration settings
tenant organization
storage device
Prior art date
Application number
PCT/US2023/024630
Other languages
English (en)
Inventor
Marcio Costa, Jr.
Neil Evan LYDICK
Hua Wang
Artur PEREZ
Adrian Kyle WIRPEL
Original Assignee
Microsoft Technology Licensing, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US18/072,586 external-priority patent/US20240015163A1/en
Application filed by Microsoft Technology Licensing, Llc filed Critical Microsoft Technology Licensing, Llc
Publication of WO2024010662A1 publication Critical patent/WO2024010662A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/024—Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis

Definitions

  • Enterprises may create endpoint policies to ensure data is accessed only by authorized users, to prevent certain applications from being installed on devices, deploying software updates, etc.
  • Software tools may be used to manage the policies and be stored in a database.
  • FIG. 1 is an illustration of components of a client device and an application server, according to various examples.
  • FIG. 2 illustrates a tenant state extractor framework, according to various examples.
  • FIG. 3 is a tree creation flow diagram, according to various examples.
  • FIG. 4 is a generated JSON response according to various examples.
  • FIG. 5 is a generated tree structure, according to various examples.
  • FIG. 6 is a data model, according to various examples.
  • FIG. 7 is a user interface screenshot, according to various examples.
  • FIG. 8 is data structure model, according to various examples.
  • FIG. 9 is a configuration setting user interface, according to various examples.
  • FIG. 10 illustrates a result of an API call, according to various examples.
  • FIG. 11 is a user interface that renders API data, according to various examples
  • FIG. 12 illustrates evaluating conditional access policies, according to various examples.
  • FIG. 13 are tables of a reverse mapping process, according to various examples.
  • FIGS. 14 and 15 are tables of a variance detection process, according to various examples.
  • FIG. 16 is a flowchart illustrating operations of a method, according to various examples.
  • FIG. 17 is a block diagram illustrating a machine in the example form of computer system, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to various examples.
  • variable values e.g., thresholds, user preferences, etc.
  • this disclosure does not always detail where the variables are stored or how they are retrieved.
  • the variables may be assumed that the variables are stored on a storage device (e.g., Random Access Memory (RAM), cache, hard drive) accessible by the component via an Application Programming Interface (API) or other program communication method.
  • RAM Random Access Memory
  • API Application Programming Interface
  • the variables may be assumed to have default values should a specific value not be described.
  • User interfaces may be provided for an end-user or administrator to edit the variable values in some instances.
  • Presentation may include data transmitted (e.g., a hypertext markup language file) from a first device (such as a Web Server) to the computing device for rendering on a display device of the computing device via a web browser.
  • Presenting may separately (or in addition to the previous data transmission) include an application (e.g., a stand-alone application) on the computing device generating and rendering the user interface on a display device of the computing device without receiving data from a server.
  • the user interfaces are often described as having different portions or elements. Although in some examples these portions may be displayed on a screen at the same time, in other examples the portions/elements may be displayed on separate screens such that not all of the portions/elements are displayed simultaneously. Unless explicitly indicated as such, the use of “presenting a user interface” does not infer either one of these options.
  • an input element may be described as being configured to receive an input string.
  • “configured to” may mean presentation of a user interface element that is capable of receiving user input.
  • the input element may be an empty text box or a drop-down menu, among others.
  • “Configured to” may additionally mean computer executable code processes interactions with the element/portion based on an event handler.
  • a “search” button element may be configured to pass text received in the input element to a search routine that formats and executes a structured query language (SQL) query with respect to a database.
  • SQL structured query language
  • a managed service provider helps organizations such as small and medium-sized businesses (collectively SMB) customers manage, migrate, and extend their systems and applications to a cloud-based environment (e.g., such as MICROSFOT AZURE®).
  • An administration portal e.g., MICROSOFT 365 LIGHTHOUSE®
  • an MSP may manage multiple tenants.
  • An MSP may help secure and manage devices, data, and users at scale for SMBs.
  • the administrative portal described herein simplifies onboarding of customer tenants by recommending security configuration baselines tailored to SMB customers and providing multi-tenant views across all customer environments.
  • MSPs can scale the management of their customers and focus on what's most important — quickly finding and investigate risks, and take action to get their customers to a healthy and secure state.
  • MSPs define different security configuration baselines depending on the security and licensing requirements of their customers. Those baselines may have been developed using other admin portals such as Azure Active Directory (AAD) and Microsoft Endpoint Manager. Once the baselines are defined in a source environment or tenant, the MSP often needs to make the same configurations using the same admin portals on their customer’s tenants. Such procedure can lead to human errors and generate unexpected behavior in the target environments.
  • Azure Active Directory AAD
  • Azure Endpoint Manager Microsoft Endpoint Manager
  • the described Tenant State Extractor facilitates the distribution and maintenance of baselines across multiple tenants.
  • the TSE extracts a selected baseline from a source tenant.
  • the TSE converts the baseline’s metadata (e.g., the settings) to a reusable format in order to make the extracted data easily maintainable without the necessity of visiting the source administrator portal again.
  • metadata e.g., the settings
  • MSPs can extract policies and configurations from multiple sources and build unique deployment plans for their customers. Those plans can be customized and re-deployed efficiently over time, reducing chances of unexpected behavior and investigation costs.
  • a variance detection feature of the admin portal allows a user to measure the degree to which a tenant’s current configuration aligns with a desired — or reference — configuration state.
  • the reference configuration state may already have been deployed to the tenant being examined.
  • the purpose of the comparison may be to evaluate whether the tenant’ s current configuration has drifted from previously applied values.
  • the reference configuration serves as a desired configuration state against which the tenant’s current adherence is being validated.
  • the goal of the variance detection feature may be to determine how current configurations (if any) deviate from the desired state.
  • a user e.g., technician looking at variance detection results may then decide whether normative interventions are required on the tenant being analyzed.
  • FIG. 1 is an illustration of components of a client device and an application server, according to various examples.
  • the illustration comprises an application server 102, a web server 110, a client device 104, a web client 106, a data 108, a processing system 114, a configuration extraction 120, a settings tree construction component 122, a deployment plan component 124, an application logic 112, an API 116, a variance detection algorithm 126, a data store 118, a configuration state comparator 128, and a conditional access permutator 130.
  • application server 102 may be used to implement the tenant state extractor and variance detection features described herein.
  • Application server 102 is illustrated as set of separate elements (e.g., component, logic, etc.). However, the functionality of individual elements may be performed by a single element.
  • An element may represent computer program code that is executable by processing system 114.
  • the program code may be stored on a storage device (e.g., data store 118) and loaded into a memory of the processing system 114 for execution. Portions of the program code may be executed in a parallel across multiple processing units (e.g., a core of a general-purpose computer processor, a graphical processing unit, an application specific integrated circuit, etc.) of processing system 114. Execution of the code may be performed on a single device or distributed across multiple devices.
  • the program code may be executed on a cloud platform (e.g., MICROSOFT AZURE® and AMAZON EC2®) using shared computing infrastructure.
  • Client device 104 may be a computing device which may be, but is not limited to, a smartphone, tablet, laptop, multi-processor system, microprocessor-based or programmable consumer electronics, game console, set-top box, or another device that a user utilizes to communicate over a network.
  • a computing device includes a display module (not shown) to display information (e.g., in the form of specially configured user interfaces).
  • computing devices may comprise one or more of a touch screen, camera, keyboard, microphone, or Global Positioning System (GPS) device.
  • Client device 104 may be used by an MSP to extract baselines from tenants and deploy them to other tenants, as well as perform other user-facing functionality as described herein.
  • Client device 104 and application server 102 may communicate via a network (not shown).
  • the network may include local-area networks (LAN), wide-area networks (WAN), wireless networks (e.g., 802.11 or cellular network), the Public Switched Telephone Network (PSTN) Network, ad hoc networks, cellular, personal area networks or peer-to-peer (e.g., Bluetooth®, Wi-Fi Direct), or other combinations or permutations of network protocols and network types.
  • the network may include a single Local Area Network (LAN) or Wide-Area Network (WAN), or combinations of LAN’s or WAN’s, such as the Internet.
  • Client device 104 and application server 102 may communicate data 108 over the network. Data 108 may include data payloads, configuration settings for a tenant, etc.
  • the communication may occur using an application programming interface (API) such as API 116.
  • API application programming interface
  • An API provides a method for computing processes to exchange data.
  • a web-based API e.g., API 116
  • the API may define a set of HTTP calls according to Representational State Transfer (RESTful) practices.
  • RESTful API may define various GET, PUT, POST, DELETE methods to create, replace, update, and delete data stored in a database (e.g., data store 118).
  • One set of APIs may be a common set of calls to access data across a variety of connected services.
  • a single end point may be used to retrieve or edit settings for multiple applications common to an organization.
  • Microsoft Graph APIs are interfaces to a number of network-based services under the Microsoft365 suite of services.
  • Application server 102 may include web server 110 to enable data exchanges with client device 104 via web client 106.
  • web server 110 may be utilized by web server 110 (e.g., File Transfer Protocol, Telnet, Secure Shell, etc.).
  • a user may enter in a uniform resource identifier (URI) into web client 106 (e.g., the INTERNET EXPLORER® web browser by Microsoft Corporation or SAFARI® web browser by Apple Inc.) that corresponds to the logical location (e.g., an Internet Protocol address) of web server 110.
  • URI uniform resource identifier
  • web server 110 may transmit a web page that is rendered on a display device of a client device (e.g., a mobile phone, desktop computer, etc.).
  • web server 110 may enable a user to interact with one or more web applications provided in a transmitted web page.
  • a web application may provide user interface (UI) components that are rendered on a display device of client device 104.
  • the user may interact (e.g., select, move, enter text into) with the UI components, and based on the interaction, the web application may update one or more portions of the web page.
  • a web application may be executed in whole, or in part, locally on client device 104.
  • the web application may populate the UI components with data from external sources or internal sources (e.g., data store 118) in various examples.
  • the web application may be executed according to application logic 112.
  • Application logic 112 may use the various elements of application server 102 to implement the web application. For example, application logic 112 may issue API calls to retrieve or store data from data store 118 and transmit it for display on client device 104. Similarly, data entered by a user into a UI component may be transmitted using API 116 back to the web server.
  • Application logic 112 may use other elements (e.g., configuration extraction 120, settings tree construction component 122, deployment plan component 124, variance detection algorithm 126, etc.) of application server 102 to perform functionality associated with the web application as described further herein.
  • Data store 118 may store data that is used by application server 102.
  • Data store 118 is depicted as singular element but may in actuality be multiple data stores.
  • the specific storage layout and model used in by data store 118 may take a number of forms — indeed, a data store 118 may utilize multiple models.
  • Data store 118 may be, but is not limited to, a relational database (e.g., SQL), non-relational database (NoSQL) a flat file database, object model, document details model, graph database, shared ledger (e.g., blockchain), or a file system hierarchy.
  • Data store 118 may store data on one or more storage devices (e.g., a hard disk, random access memory (RAM), etc.). The storage devices may be in standalone arrays, part of one or more servers, and may be located in one or more geographic areas.
  • the TSE uses a protocol such as the OData protocol (e.g., a REST API best practices standards protocol) to invoke APIs responsible for representing metadata of a security configuration baseline using an Entity Data Model (EDM) standard.
  • OData e.g., a REST API best practices standards protocol
  • EDM Entity Data Model
  • the EDM standard is a set of concepts that describe the structure of data, regardless of its stored form (e.g., it is tenant-agnostic).
  • the EDM addresses the challenges that arise from having data stored in many forms. For example, consider a business that stores data in relational databases, text files, XML files, spreadsheets, and reports. This presents significant challenges in data modeling, application design, and data access. When designing a data- oriented application, the challenge is to write efficient and maintainable code without sacrificing efficient data access, storage, and scalability.
  • the EMD uses three concepts to describe the structure of data: entity type, association type, and property.
  • entity type describes the structure of data with the EDM.
  • entity types are constructed from properties and describe the structure of top-level concepts, such as a customers and orders in a business application.
  • a class definition in a computer program is a template for instances of the class
  • an entity type is a template for entities.
  • An entity represents a specific object (such as a specific customer or order).
  • An association type (also called an association) describes relationships in the EDM.
  • an association represents a relationship between two entity types (such as Customer and Order). Every association has two association ends that specify the entity types involved in the association. Each association end also specifies an association end multiplicity that indicates the number of entities that can be at that end of the association.
  • Entity types contain properties that define their structure and characteristics. For example, a Customer entity type may have properties such as Customerld, Name, and Address.
  • FIG. 2 illustrates a tenant state extractor framework, according to various examples.
  • FIG. 2 includes three operations indicated by block 202, block 204, and block 206.
  • the extraction API execution may occur.
  • the extraction API may include triggering a GET request using an EDM based API.
  • the response may be a Javascript Object Notion (JSON) object or any other key-value pair collection structure that could be converted into a JSON format.
  • Block 202 may be performed using configuration extraction 120, in various examples.
  • the TSE may be exposed via a REST API by application server 102 (e.g., API 116).
  • the API contract may be established as described below:
  • the “windowsInformationProtectionPolicies” are requested along with any of the $expand parameter values.
  • the request reaches the desired endpoint, its payload is validated in order to confirm that the API provided in the extractionAPI parameter is supported and the tenant provided in the tenantld parameter is accessible by the caller.
  • an HTTP GET request may be issued based on the provided extraction API targeting the tenant provided in the input parameters.
  • the framework may ensure the authorization for such requests by swapping the necessary tokens to retrieve the data from the tenant.
  • the response is parsed, and it is sent to the next stage (e.g., block 204) where it will be converted into a settings tree for easier customizations.
  • the framework may only move forward to the next stage if the response is in a JSON format. Generating a setting tree is discussed further with respect to FIG. 3, FIG. 4, FIG. 5, and FIG. 6.
  • the deployment plan may be generated as discussed in more detail below.
  • FIG. 3 is a tree creation flow diagram, according to various examples. The operations illustrated in FIG. 3 may be performed by settings tree construction component 122 in various examples.
  • the second stage of the TSE framework may include building a tree based on the JSON object (JObject) extracted from the source tenant as illustrated in this figure.
  • JObject JSON object
  • the algorithm starts at operation 302 by processing each JProperty of the JObject extracted from the source tenant (operation 304). If the JProperty consists of a simple key-value pair item, the same is added to a dictionary of type ⁇ string, object> (operation 306). If the JProperty consists of a key with the @odata. context suffix and value of type JObject, then a new branch of the tree should be created (e.g., operation 308) and a new instance of the ⁇ string, object> dictionary is initialized. Then, the framework recursively processes each JProperty of the inner JObject until there are no more properties to process. After all properties are visited, each dictionary instance is connected accordingly, and a tree is formed as a result (operation 310).
  • Each branch of the tree can be determined by nested $expand calls present in the provided extraction API, given that such calls generate JProperties with the @data.context suffix.
  • FIG. 6 is a data model, according to various examples.
  • the property (e.g., settings) tree generated in block 204 may be stored according to the data model depicted in FIG. 6.
  • the populated data model is stored in data store 118.
  • each ManagementTemplateStep Version record holds a collection of ManagementTemplateStepSetting which represents the key-value pairs processed from the extraction response.
  • another ManagementTemplateStepVersion instance is created and connected to the parent record, resulting in a tree of settings available for customization.
  • the extraction API is stored in a ManagedTenantOperationDefinition instance, in the value property, in order to calculate the deployment plan in the last stage of the TSE framework.
  • the tree data model facilitates further customizations on the extracted properties, due to the fact that a single PATCH request may be executed on a node of the tree to change the value of a property.
  • Such a data model may also be used to determine the deployment plan for the extracted actions — given that each branch of the tree indicates a dependency — and the customizer may enhance it further to add or remove dependencies from their plan.
  • a deployment plan calculation may be made.
  • block 206 is performed by deployment plan component 124.
  • the settings tree is used to calculate the deployment order of each action represented by each node.
  • a GET, PATCH, and POST requests are pre-calculated, where their payload is parametrized based on the latest value of each setting.
  • the first GET request is designed to verify the existence of an instance according to a given identifier.
  • the instance’s display name is selected as the primary identifier, however such metadata can be customized by changing the isldentifier property of the corresponding ManagementTemplateStepSetting. If the GET request returns no response, then it indicates that the target instance does not exist — hence a create or POST request needs to be issue — otherwise an update or PATCH request is sent.
  • the response from the second POST or PATCH request may return the full payload of the persisted entityA record including its identifier (id). That id is used to trigger the next POST request for the creation of entityB, in association to the just written entityA record.
  • id identifier
  • two operations are executed on the second POST record: the creation of a new entityB record and its association with the recently created entityA record.
  • MSPs may extract multiple security policies and configurations from different tenants and generate one or more deployment plans to secure their customers according to their needs.
  • the multiple extraction APIs are provided that target several security related customizations (but is applicable to non-security settings as well).
  • MSPs can use them as guidelines for building their own standards.
  • FIG. 7 is a user interface screenshot, according to various examples.
  • the screenshot illustrates the authoring experience for a baseline with some of the extraction options available.
  • FIG. 8 is data structure model, according to various examples.
  • the data model to store those actions was designed to be extensible, given that the TSE supports any EDM based solution.
  • the extraction APIs may be stored in a ManagementTemplateExtractionAction entity, and users can add, remove, or edit actions from the list by executing POST, DELETE, or PATCH requests for that entity, respectively.
  • the model in FIG. 8 describes an example data structure of this entity
  • FIG. 9 is a configuration setting user interface, according to various examples.
  • the customizer can edit the settings processed by the TSE framework.
  • FIG. 9 is a screenshot illustrating an example of such an experience.
  • the Display Name setting 902 has the Lighthouse - Require MFA for Admins default value 904.
  • the customizer may change the default value of that setting which was extracted from a source tenant. Additionally, they may determine if the setting should require input from the user executing the deployment of that artifact by checking the Required checkbox 906. Moreover, the customizer can determine if the setting should not be editable by the user executing the deployment by checking the Read only checkbox 908.
  • APIs may not follow the EDM standard entirely; however those APIS may still be used to ensure tenant security. For such cases, special handling may be used, and custom code is embedded into application server 102 to support those APIs. Some examples consist of merging POST calls targeting multiple entities into a single POST call targeting a single entity or providing a different contract for creating and updating records for a target entity.
  • MSPs can detect variances from the policy or configuration they want to deploy to a target tenant, then identify the consequences of applying the new security standards to that environment. They may also identify the group of users that are not following those standards and address them immediately in order to avoid potential vulnerabilities.
  • a generic comparison algorithm may be applied on the extraction API to identify possible variances.
  • MSPs In addition to creating and updating artifacts deployed to target tenants, MSPs also have the option to remove those artifacts when needed.
  • a DELETE API call may be automatically generated by the TSE and available for invocation on-demand.
  • TSE Another use for the TSE is to retrieve artifacts from different source tenants, maintain them in a central location, then replicate them to multiple other environments. However, there can be cases that require a direct data migration from one environment to another —especially for non-configuration related artifacts.
  • the TSE may be leveraged to execute such procedure.
  • the TSE provides a flexible and extensible infrastructure for consumers to retrieve the state from a source environment and replicate it across multiple environments at scale. Additionally, it allows easier maintenance of the extracted data, in union with ordered deployment actions according to dependent entities. Even though one use may be for extracting and customizing security related policies and configurations from certain tenants, the TSE is designed to support any service that follows EDM standards, making it a valuable tool for multi-tenant management in general, not only security related solutions.
  • the described variance detection algorithm classifies configuration state into discrete configuration object types (e.g.: policy, rule), and value comparisons are performed on instances of matching object types (e.g., using configuration state comparator 128).
  • Configuration object instances that are already defined within the tenant are compared to a reference instance configured within the product.
  • tenant configurations may be stored within data store 118 and reference configuration instances are stored within a feature specific to a product (e.g., baselines as discussed above).
  • Code within application server 102 includes configuration object type metadata that specifies how to transform each configuration object type instance into n- dimensional function that fully represents that instance.
  • each property of a configuration object maps to a one-dimensional function argument (“property”) whose domain includes valid property names of properties within that configuration object and whose range includes the possible values for those properties.
  • Valid values to which this single argument can be mapped include “Allow user to access with Multi-Factor Authentication (MFA)” or “Deny User Access without MFA”. Only one value will be present for any configuration object instance, and the variation detection algorithm can compare the value of policies currently active in the tenant with any user-specified, desired state.
  • the algorithm may add function arguments/dimensions for every condition on which a configuration object property is dependent. For example, configuration policies generally are targeted to specific users, groups, or user roles.
  • this user targeting aspect of Conditional Access Policies is resolved into a “user” dimension, and all possible user values for a tenant with the single grant control property are permuted (e.g., using conditional access permutator 130) to arrive at the configuration function’s domain. Other conditions (e.g., application used to log in, user’s client type) are similarly added as dimensions and permuted.
  • conditional access permutator 130 e.g., application used to log in, user’s client type
  • the setting value in the tenant object is undefined while the setting value in the reference object has a value.
  • the setting value in the reference object is undefined while the setting value in the tenant object has a value.
  • This setting is defined on at least two tenant objects and contains different values on each.
  • an aggregate comparison is computed between the reference configuration object and all tenant configuration objects.
  • This aggregate comparison relies on the pointwise settings comparisons and uses the following priority rule to define an overall settings value comparison, which can be customized per configuration object type: conflicting > equal > missing > extra
  • each supported type of configuration is associated with a list of “dimension builders”.
  • Some “dimension builders” are shared among several types of configurations.
  • the “user” dimension may be shared among Conditional Access Policies, Device Compliance Policies (e.g., Intune Device Compliance Policies) and Configuration Profiles (e.g., Intune Configuration Profiles).
  • Each “dimension builder” may have logic to retrieve dimension specific information from their management portals as APIs (e.g., API 116). They also provide information for user experience to display the values correctly.
  • developers may implement derived classes of DimensionBuilderBase and define how they retrieve the dimension values from the input configurations. If the developers need additional information that is not in the input configurations, they may make calls to retrieve the information with the given credentials.
  • Variance detection may be defined as an expression of an API.
  • the baselines feature may allow several “actions,” to be executed on behalf of the user to bring a tenant to a desired configuration.
  • Variance detection may a scriptable action.
  • a user may invoke it through an API by calling /API/managementTemplateStepVersion/ ⁇ id ⁇ /validate, and in the payload, specifying a target tenant id and a set of configuration settings which define the configuration object used as a reference. If the required app permissions are available, variance detection may also be invoked online without the user providing their credentials (explicitly through an action or implicitly by loading a page).
  • conditional access policy conditionalAccessPolicy presented in JSON format as reference configuration and a list of policies retrieved with a call: “vl .O/identity/conditionalAccess/policies”, as existing configuration, to a Variance Detection function “sys.validateConditionalAccessPolicy”.
  • FIG. 10 illustrates a result of an API call, according to various examples.
  • the validation result entity is persisted in a data store so that the user may retrieve these results at any time.
  • FIG. 11 is a user interface that renders API data, according to various examples.
  • the user interface picks up the result (e.g., FIG. 10) stored in a typed entity and displays them in a structured format. Note that all but the final settings dimension is grouped into headers for user readability.
  • the user interface renders using the dimension metadata provided by the API and can accommodate any number of dimensions for analysis.
  • the UI displays the setting and user statistics for each detected configuration, including whether the configuration has equal, missing, or conflicting settings/users.
  • the UI may support device level statistics and filters on the setting types so that users can view which settings are equal, conflicting, missing or extra.
  • the described variance framework provides a variety of statistics. This includes a user summary, which categorizes users into the following disjointed sets, in various examples:
  • Each category may have the following definition:
  • Not Targeted Users who are not targeted as an included user or as a member of a users role or group and not part of the exclusion group
  • the framework internally maintains settings classifications that exceed the (equal/conflicting/missing/extra) designations described earlier. These classifications vary based on the type of configuration. For example, conditional access has different levels of “Access controls”. In all cases, the system may define “Block Access” as stricter than “Grant Access” in general. Furthermore, the system may differentiate between levels of “Grant Access” (MFA vs. MFA + Managed Device) to reflect that a certain threshold has been met. That is, the settings comparison exceeds (i.e.: is not just equal to) the standard defined by some reference configuration. Qualitative and quantitative comparisons are possible to achieve and return to the user in this model (e.g.: windows versions).
  • Variance detection data may be archived in a database (e.g., data store 118) store to analyze the change in configuration drift over time.
  • application server 102 may be able to alert on first and second derivatives of the comparison numbers captured from variance detection APIs.
  • prioritized user alerts may be surfaced that target the following conditions: (1) The number of users not covered by deployed baseline has increased by Y; and (2) The number of users without adequate licensing has increased by X
  • variance detection algorithm 126 processes each unique configuration object — both the reference object used as the standard of comparison as well as objects that already exist within the tenant — dimension-by-dimension. For each dimension, these three steps may be run: input preprocessing, reverse-mapping, and grouping.
  • FIG. 12 illustrates evaluating conditional access policies, according to various examples.
  • the figures show an example of evaluating three conditional access policies - pl, p2, p3, over three dimensions: user assignment, device platform and client type.
  • a policy assignment can have groups, roles, and users. As discussed above, flatten these values may be flattened into “user” and use “user” as dimension values in the further process.
  • the input may be a list of values mapping to their dimensions.
  • a list of dimension values mapping to the values that associate with those dimensions is obtained so that the values being compared are under the same conditions.
  • FIG. 13 are tables of a reverse mapping process, according to various examples.
  • table 1302 four setting values are set to different conditions, so they should not be compared directly.
  • table 1304 After reverse-mapping (table 1304), all the values under the same condi -ti on are put side by side. Therefore, the system can compare the values under the same condition and determine if there is variance. In the bottom table it can be observed there are some conflicts under some conditions.
  • FIGS. 14 and 15 illustrates tables of a variance detection process, according to various examples.
  • the number of comparison results are reduced by grouping some dimension values.
  • table 1304, user2 and user3, user4 and user6, user7-userl0 share the same comparison result. Therefore, those comparison results can be grouped together as shown in table 1402 of FIG. 14.
  • Table 1404 of FIG. 14 shows the variance detection result over two dimensions — user and device platform.
  • the table in FIG. 15 illustrates the result over three dimensions — user, device platform and client types.
  • FIG. 16 is a flowchart illustrating operations of a method.
  • the method is represented as a set of blocks that describe operations 1602-1622 of the method.
  • the method may be embodied in a set of instructions stored in at least one computer-readable storage device of a computing device(s).
  • a computer-readable storage device excludes transitory signals.
  • a signal-bearing medium may include such transitory signals.
  • a machine-readable medium may be a computer-readable storage device or a signal-bearing medium.
  • the computing device(s) may have one or more processors that execute the set of instructions to configure the one or more processors to perform the operations illustrated in FIG. 16.
  • the one or more processors may instruct other component of the computing device(s) to carry out the set of instructions.
  • the computing device may instruct a network device to transmit data to another computing device or the computing device may provide data over a display interface to present a user interface.
  • performance of the method may be split across multiple computing devices using a shared computing infrastructure.
  • the method is performed on a server device such as described as application server 102.
  • the request may originate from a client device such as client device 104.
  • the method includes at operation 1602, receiving, at a server device, a request to extract configuration settings of a source tenant organization from a data store.
  • the request may include an identifier of the source organization.
  • the request may originate from a client device such as client device 104.
  • the configuration settings may be stored as a tenant-agnostic security baseline configuration.
  • the method includes at operation 1604, in response to the request at the server device, recursively accessing the configuration settings of the source tenant organization.
  • recursively accessing the configuration settings of the source tenant organization may include accessing multiple dimensions of a setting, such as a user dimension.
  • the method includes at operation 1606, generating, at the server device, a configuration tree data structure based on the accessed configuration settings, the configuration tree data structure organized as a plurality of key -value pairs.
  • the method includes at operation 1608 selecting, at the server device, a target tenant organization.
  • the selecting may be based on receiving an identifier of the target tenant organization via a web application.
  • the method includes at operation 1610 based on the configuration tree data structure, generating, at the server device, a deployment order including chained API calls directed towards the target tenant organization. In various examples, the method includes at operation 1612, executing, at the server device, the chained API calls.
  • additional operations may include, at operation 1618 executing variance detection between the agnostic security baseline configuration and configuration settings of a second tenant organization.
  • the method includes at operation 1620, as a result of the variance detection, receiving a conflict between the agnostic security baseline configuration and the configuration settings of a second tenant organization.
  • the method includes, at operation 1622, resolving the conflict according to an ordered priority list of conflict types.
  • FIG. 17 is a block diagram illustrating a machine in the example form of computer system 1700, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to an example embodiment.
  • the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
  • the machine may operate in the capacity of either a server or a client machine in server-client Network environments, or it may act as a peer machine in peer-to-peer (or distributed) Network environments.
  • the machine may be an onboard vehicle system, wearable device, personal computer (PC), a tablet PC, a hybrid tablet, a personal digital assistant (PDA), a mobile telephone, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • machine shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • processor-based system shall be taken to include any set of one or more machines that are controlled by or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.
  • Example computer system 1700 includes at least one processor 1704 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.), a main memory 1710 and a static memory 1722, which communicate with each other via a bus 1702.
  • the computer system 1700 may further include a video display 1708, an input device 1712 (e.g., a keyboard), and a user interface (UI) navigation device 1716 (e.g., a mouse).
  • the video display 1708, input device 1712, and UI navigation device 1716 are incorporated into a single device housing such as a touch screen display.
  • the computer system 1700 may additionally include a storage device 1718 (e.g., a drive unit), a signal generation device 1720 (e.g., a speaker), a network interface device 1726, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensors.
  • a storage device 1718 e.g., a drive unit
  • a signal generation device 1720 e.g., a speaker
  • a network interface device 1726 e.g., a network interface device 1726
  • sensors not shown
  • GPS global positioning system
  • the storage device 1718 includes a machine-readable medium 1724 on which is stored one or more sets of data structures and instructions 1714 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein.
  • the instructions 1714 may also reside, completely or at least partially, within the main memory 1710, static memory 1722, and/or within the processor 1704 during execution thereof by the computer system 100, with the main memory 1710, static memory 1722, and the processor 1704 also constituting machine-readable media.
  • machine-readable medium 1724 is illustrated in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed Database, and/or associated caches and servers) that store the one or more instructions 1714.
  • the term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions.
  • the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.
  • machine- readable media include non-volatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magnetooptical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)
  • flash memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)
  • flash memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)
  • flash memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable
  • the instructions 1714 may further be transmitted or received over a communications Network 1726 using a transmission medium via the network interface device 1726 utilizing any one of a number of well-known transfer protocols (e.g., HTTP).
  • Examples of communication networks include a local area Network (LAN), a wide area Network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi, 3G, and 4G LTE/LTE-A or WiMAX networks).
  • POTS plain old telephone
  • wireless data networks e.g., Wi-Fi, 3G, and 4G LTE/LTE-A or WiMAX networks.
  • transmission medium shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé qui peut consister à : recevoir, au niveau d'un dispositif serveur, une demande d'extraction de réglages de configuration d'une organisation locataire source à partir d'un magasin de données ; en réponse à la demande au niveau du dispositif serveur, accéder de manière récursive aux réglages de configuration de l'organisation locataire source ; générer, au niveau du dispositif serveur, une structure de données d'arbre de configuration sur la base des réglages de configuration accédés, la structure de données d'arbre de configuration étant organisée sous la forme d'une pluralité de paires clé-valeur ; sélectionner, au niveau du dispositif serveur, une organisation locataire cible ; sur la base de la structure de données d'arbre de configuration, générer, au niveau du dispositif serveur, un ordre de déploiement comprenant des appels d'API chaînés dirigés vers l'organisation locataire cible ; exécuter, au niveau du dispositif serveur, les appels d'API chaînés.
PCT/US2023/024630 2022-07-06 2023-06-06 Extraction d'état de configuration de locataire et détection de variance WO2024010662A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202263358800P 2022-07-06 2022-07-06
US63/358,800 2022-07-06
US18/072,586 US20240015163A1 (en) 2022-07-06 2022-11-30 Tenant configuration state extraction and variance detection
US18/072,586 2022-11-30

Publications (1)

Publication Number Publication Date
WO2024010662A1 true WO2024010662A1 (fr) 2024-01-11

Family

ID=87071033

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/024630 WO2024010662A1 (fr) 2022-07-06 2023-06-06 Extraction d'état de configuration de locataire et détection de variance

Country Status (1)

Country Link
WO (1) WO2024010662A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220086190A1 (en) * 2020-09-16 2022-03-17 Salesforce.Com, Inc. Correlation of security policy input and output changes
US20220150133A1 (en) * 2020-11-06 2022-05-12 Salesforce.Com, Inc. Modifying a data center based on cloud computing platform using declarative language and compiler

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220086190A1 (en) * 2020-09-16 2022-03-17 Salesforce.Com, Inc. Correlation of security policy input and output changes
US20220150133A1 (en) * 2020-11-06 2022-05-12 Salesforce.Com, Inc. Modifying a data center based on cloud computing platform using declarative language and compiler

Similar Documents

Publication Publication Date Title
US10839011B2 (en) Application programing interface document generator
US11429677B2 (en) Sharing common metadata in multi-tenant environment
US11537552B2 (en) Rule generation in a data governance framework
US11843664B1 (en) Managing access control of data pipelines configured on a cloud platform
US9898497B2 (en) Validating coherency between multiple data sets between database transfers
US10361944B2 (en) Automated test for uniform web service interfaces
US10628237B2 (en) Cloud service integration flow
US9600342B2 (en) Managing parallel processes for application-level partitions
US10169417B2 (en) Detecting logical relationships based on structured query statements
US10915662B2 (en) Data de-identification based on detection of allowable configurations for data de-identification processes
US11106820B2 (en) Data anonymization
CN108427550B (zh) 一种Web服务生成方法、装置及设备
US10261808B2 (en) Access operation with dynamic linking and access of data within plural data sources
US11134085B2 (en) Cloud least identity privilege and data access framework
US11334472B2 (en) Automated testing for metadata-driven custom applications
US20190102477A1 (en) Novel metadata relationships in a configuration management database
US10558624B2 (en) System and method for datastore management framework
US20240015163A1 (en) Tenant configuration state extraction and variance detection
EP4030280A1 (fr) Stabilité continue du cycle de vie pour des fonctions logicielles extensibles
WO2024010662A1 (fr) Extraction d'état de configuration de locataire et détection de variance
US20220222225A1 (en) Model generation service for data retrieval
US10484483B1 (en) Method and system for providing software functionalities to users of multi-tenant applications via inheritance
CN113342775B (zh) 基于云的计算环境中的集中式多租户即服务
US20220342802A1 (en) Automated testing for metadata-driven custom applications
CN115495781A (zh) 示范用功能页面的生成方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23736529

Country of ref document: EP

Kind code of ref document: A1