Dynamic power user suppressing method for managing sla guarantee

Abstract

To provide a method for collectively monitoring the amount of API event rates or time within the request from a group and the request from individual users in the user group to an SaaS vendor, avoiding the throughput penalty imposed on the user group by the SaaS vendor.SOLUTION: When a group's API rate, overall, exceeds or approaches a trigger imposed by an SaaS for a throughput penalty against a group, power users are identified as submitting API events in excess of a limit, and an action is taken to reduce a user's impact on a group's API event rate. Furthermore, transmission is assigned for API event submission from power users to the SaaS. Triggering is avoided for the throughput penalty by the SaaS. A latency of users in a group other than the power users is reduced and the latency of power users is increased.SELECTED DRAWING: Figure 1

Description

cross reference

[0001] This application claims priority to and the benefit of U.S. patent application Ser. No. 17 / 163,285, filed Jan. 29, 2021, entitled "Dynamic Power User Identification and Isolation For Managing SLA Guarantees." INCORPORATION BY REFERENCE

[0002] The following materials are incorporated by reference in this application:

[0003] U.S. Nonprovisional Patent Application No. 14 / 198,508 (Attorney Docket No. NSKO1000-3), entitled “Security for Network Delivered Services,” filed March 5, 2014 (now U.S. Patent No. 9,270,765, issued February 23, 2016); U.S. Non-provisional Patent Application No. 15 / 368,240, entitled “Systems and Methods of Enforcing Multi-Part Policies on Data-Deficient Transactions of Cloud Computing Services,” filed on December 2, 2016 (Attorney Docket No. NSKO1003-2) (now U.S. Patent No. 10,826,940, issued on November 3, 2020), and U.S. Provisional Patent Application No. 62 / 307,305, entitled “Systems and Methods of Enforcing Multi-Part Policies on Data-Deficient Transactions of Cloud Computing Services,” filed on March 11, 2016 (Attorney Docket No. NSKO1003-1); “Cloud Security for Dummies,Netskope Special Edition”by Cheng,Ithal,Narayanaswamy,and Malmskog,John Wiley & Sons,Inc.2015; “Netskope Introspection” by Netskope,Inc.; “Data Loss Prevention and Monitoring in the Cloud” by Netskope,Inc.; “The 5 Steps to Cloud Confidence” by Netskope, Inc.; “Netskope Active Cloud DLP” by Netskope,Inc.; “Repave the Cloud-Data Breach Collision Course” by Netskope, Inc.; and “Netskope Cloud Confidence Index(TM)” by Netskope,Inc. [Technical field]

[0004] The disclosed technology relates generally to avoiding throughput penalties imposed by Software as a Service (SaaS) vendors on user groups of an organization due to excessive Application Programming Interface (API) events from users within the user groups for security and regulatory compliance. More specifically, the disclosed technology relates to dynamic power user identification and isolation for managing Service Level Agreement (SLA) guarantees. [Background technology]

[0005] The subject matter discussed in this section should not be assumed to be prior art merely as a result of its mention in this section. Similarly, it should not be assumed that the problems mentioned in this section, or related to the subject matter provided as background, have been previously recognized in the prior art. The subject matter in this section merely represents different approaches, and as such, may correspond to implementations of the claimed technology.

[0006] The use of cloud services for corporate functions is common. Research suggests that 80% of enterprise workloads will reside in the cloud by 2025. According to the International Data Corporation, "spending on public cloud information technology (IT) infrastructure surpassed spending on traditional IT infrastructure for the first time in the second quarter of 2020." For example, enterprise companies often utilize software-as-a-service (SaaS) solutions instead of installing servers within the corporate network to deliver services.

[0007] Enterprises typically use SaaS solutions instead of installing servers within the enterprise network to deliver services. SaaS solution providers offer service level agreements (SLAs) between the service and the customer that set expectations of guaranteed availability, performance, security and privacy of the customer's data. In turn, customers expect to be able to securely collaboratively create, edit and store their data across multiple customer branches and data centers.

[0008] In one example of the need for adequate security services, in 2020, the global pandemic caused a sudden shift to remote working among enterprise knowledge workers, which in turn led to an increase in risky behavior. Attackers sought to exploit the outbreak with COVID-19 themed phishing emails, scams, and Trojans. During this period, techniques used in more sophisticated cyber attacks also continued to evolve. Applicant reports that attackers have changed techniques for initial delivery, with malicious Microsoft Office document files increasing in popularity by more than six-fold, rivaling or surpassing portable executable files. Attackers continue to exploit popular cloud apps and services to deliver malicious files to victims within enterprises, with over 50% of these being delivered through the cloud.

[0009] In addition to human users using SaaS apps, SaaS apps are also integrated with bots or scripts that generate updates to objects within the SaaS app. These updates are received as notifications that are identified and inspected to ensure secure service. Meanwhile, SaaS apps can impose rate limits on factors such as the number of API calls made for a user per unit of time, so that the number of operations performed for a user is a factor of the number of API calls allowed for the user per unit of time. API calls are a scarce resource that is used efficiently, which motivates the usefulness of limiting the operations created in workers to the amount of work the user can perform. Creating operations and scheduling in workers blindly to users and notifications leads to head-of-line blocking, delaying the processing of other users' notifications.

[0010] In response to a service level agreement (SLA) for an organization, an opportunity arises to avoid throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users within the user group.

[0011] In the drawings, like reference characters generally refer to like parts throughout the different views. Also, the drawings are not necessarily to scale, with emphasis instead generally being placed upon illustrating the principles of the disclosed technology. In the following description, various implementations of the disclosed technology are described with reference to the following drawings: [Brief description of the drawings]

[0012] [Figure 1] 1 illustrates an architecture level schematic diagram of a system for avoiding throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users within the user group, according to one implementation of the disclosed technology. [Diagram 2]1 illustrates a high-level block diagram of the flow of user data representing SaaS application events for introspection. [Diagram 3] 1 illustrates a block diagram for identifying power users who generate more notifications per unit time than can be processed according to the users' SLA agreements. [Figure 4] 1 shows an example table of API event counts over a time window for multiple users to track user impact on API event rate. [Figure 5A] 13 lists exemplary push notifications received from a third-party SaaS vendor for a network event, along with notification metadata in a JSON-style representation. [Figure 5B] 13 lists exemplary push notifications received from a third-party SaaS vendor for a network event, along with notification metadata in a JSON-style representation. [Figure 6A] Exemplary metadata for an item created 604 network event is listed in a JSON style representation. [Figure 6B] Exemplary metadata for an item created 604 network event is listed in a JSON style representation. [Figure 6C] Exemplary metadata for an item created 604 network event is listed in a JSON style representation. [Figure 7A] 4 shows an exemplary alert, message for an administrator. [Figure 7B] Here is an example of the email an administrator receives when a power user violates a configured policy: [Figure 8] A graph of API events received over a 5 minute period and API event submissions from power users allocated via the disclosed method to a SaaS is used to illustrate the reduced latency for 9 out of 10 users. [Figure 9]1 illustrates a representative workflow of a method for avoiding throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users within the user group, according to one implementation of the disclosed technology. [Figure 10] FIG. 1 is a simplified block diagram of a computer system that may be used to avoid throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users in the user group, according to one implementation of the disclosed technology. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] The following detailed description is provided with reference to the drawings. Exemplary implementations are described to illustrate the disclosed technology, but not to limit its scope, which is defined by the claims. Those skilled in the art will recognize various equivalent variations based on the following description.

[0014] The SaaS app is used by real users and is also integrated with bots or scripts that generate updates to objects within the SaaS app. Updates are received from the SaaS app as notifications.

[0015] SaaS apps impose rate limits on API events and can impose rate limits based on some factors. One common factor for rate limiting is based on users. The number of API events per user for a user can be limited. Since SaaS apps impose rate limits on API events for a user per unit of time, the number of operations performed for a user is a factor of the number of API events allowed for the user per unit of time. That is, API events are a scarce resource that must be used efficiently, which drives the usefulness of limiting the operations created in worker processes to the amount of work that can be performed for a user. Creating operations and scheduling for worker processes blindly to users and notifications can lead to head-of-line blocking, a performance-limiting phenomenon that occurs when a line of packets gets clogged with the leading packet, delaying the processing of other users' notifications.

[0016] In the past, the approach to managing SLA guarantees has been to react to rate limits imposed by external applications. While important, this approach does not have enough impact to improve resource usage enough to guarantee the service level agreements (SLAs) of other users that should not be affected by another user's usage.

[0017] The disclosed technology solves the technical problem of avoiding throughput penalties imposed by SaaS vendors on user groups, typically due to excessive API events from users in the user group of an organization. The approach disclosed by the applicant monitors API event rates for requests from the user group and from individual users in the user group to the SaaS vendor, recognizes power users as submitting API events that exceed the limit, and takes action to reduce the power user's impact on the API event rate of the user group. Once a user is recognized as a power user, the information is fed back to the scheduler, which can take action to not allow the user to continue with the intended operation based on the rate at which the power user performs the operation. In one example, the action is to throttle the notification workload of a particular user, ensuring that resources are usefully utilized for notification processing of other users. This approach benefits the system throughput and the organization, also referred to as the customer, since the power users are identified and their usage is throttled to SLA guarantees based on the API quota available per user, and then SLA guarantees for other users can be maintained. Configurable actions can be set up by an administrator as a policy to quarantine a user from further processing, and can alert an administrator if a policy for alerting is set up. In some embodiments, another configurable policy action can be to create a separate queue for power users to process their notifications in order to protect resources needed by other users in the organization.

[0018] Next, an exemplary system for avoiding throughput penalties imposed by a SaaS vendor on an organization's user groups due to excessive API events from users within the user groups is described.

[0019] system FIG. 1 shows an architecture-level schematic diagram of a system 100 for improving near real-time access to SaaS APIs on behalf of an organization. The system 100 includes a network security system 155, an administration client 112, a cloud service 118, a client device 142, and a public network 145. The network security system 155 includes a customer data privacy protection 156, an active analyzer 165, an internal inspection engine 175, a monitor 184, and a storage 186. The monitor 184 of the network security system 155 includes an extraction engine 171, a classification engine 172, a security engine 173, a management plane 174, and a data plane 180. The administration client 112 includes a tablet 122 and a mobile 132, the cloud service 118 includes cloud service A 128 to cloud service Z 138, and the client device 142 includes a mobile 152 and a computer 162. The active analyzer 165 uses monitors 184 to enforce policies on sensitive content in real time as it traverses the network 145. The storage 186 includes content policies 187, content profiles 188, content inspection rules 189, enterprise data 197, client information 198, and user identity 199. User identity refers to an indicator provided to a client device by the network security system in the form of a token, a unique identifier such as a UUID, a public key certificate, etc. In some implementations, the user identity may be linked to a specific user and a specific device, so the same individual may have different user identities for their mobile phone and computer. The user identity may be linked to, but is distinct from, an entry or user id corporate identity directory. In one implementation, a cryptographic certificate signed by the network security is used as the user identity. In other implementations, the user identity may be unique only to the user and may be the same across devices.

[0020] Continuing with the description of the system 100, in some implementations, the storage 186 can store information from one or more tenants in tables of a common database image to form an on-demand database service (ODDS), which can be implemented in many ways, such as a multi-tenant database system (MTDS). The database image can include one or more database objects. In other implementations, the database can be a relational database management system (RDBMS), an object-oriented database management system (OODBMS), a distributed file system (DFS), a no-schema database, or any other data storage system or computing device.

[0021] Enterprise data 197 may include organizational data, including, but not limited to, intellectual property, private financials, strategic plans, customer lists, personally identifiable information (PII) belonging to customers or employees, patient health data, source code, trade secrets, reservation information, partner agreements, corporate plans, merger and acquisition documents, and other confidential data. In particular, the term "enterprise data" refers to documents, files, folders, web pages, collections of web pages, images, or other text-based documents.

[0022] In interconnecting the elements of the system 100, the network 145 communicatively couples the management client tablet 122 and mobile 132, the client device mobile 152 and computer 162, the cloud service A 128-cloud service Z 138, and the network security system 155. The communication paths can be point-to-point over public and / or private networks. The communication can occur over a variety of networks, such as private networks, VPNs, MPLS circuits, or the Internet, and can use appropriate application program interfaces (APIs) and data exchange formats, such as REST, JSON, XML, SOAP, and / or JMS. All communication can be encrypted. This communication is generally over networks such as local area networks (LANs), wide area networks (WANs), telephone networks (public switched telephone network (PSTN)), session initiation protocol (SIP), wireless networks, point-to-point networks, star networks, token ring networks, hub networks, the Internet, including the mobile Internet, via protocols such as EDGE, 3G, 4G LTE, Wi-Fi, and WiMAX. Additionally, communications can be secured using a variety of authentication and authorization technologies, including username / password, OAuth, Kerberos, SecureID, digital certificates, and more.

[0023] Continuing with the description of the system architecture of FIG. 1, the network security system 155 includes a monitor 184 and a storage 186, which may include one or more computers and computer systems communicatively coupled to each other. They may also be one or more virtual computing and / or storage resources. For example, the monitor 184 may be one or more Amazon EC2 instances, and the storage 186 may be Amazon S3™ storage. Rather than implementing the network security system 155 directly on a physical computer or a traditional virtual machine, other computing-as-a-service platforms such as Rackspace, Heroku, or Force.com from Salesforce may be used. Moreover, to implement the security functions, one or more engines may be used and one or more points of presence (POPs) may be established. The engines may be of various types, including workstations, servers, computing clusters, blade servers, server farms, or any other data processing systems or computing devices. The engines may be communicatively coupled to a database via different network connections. For example, extraction engine 171 may be coupled via network 145 (e.g., the Internet), classification engine 172 may be coupled via a direct network link, and security engine 173 may be coupled by a further different network connection. With respect to the disclosed technology, the POPs of data plane 180 are hosted on the premises of the client or are located within a virtual private network controlled by the client.

[0024] Continuing with the description of FIG. 1, the system 100 includes a network security system 155 with customer data privacy protection 156 that accesses various functions via a management plane 174 and a data plane 180. According to one implementation, the data plane 180 includes an extraction engine 171, a classification engine 172, and a security engine 173. Other functions such as a control plane may also be provided. These functions collectively provide a secure interface between the cloud services 118 and the client devices 142. Although the term "network security system" is used to describe the network security system 155, more generally the system provides application visibility and control as well as security. In one example, 35,000 cloud applications reside in a library that intersects with the servers in use by the client devices 142.

[0025] The administration client 112, according to one implementation, is a computing device with a web browser with a secure web-delivered interface provided by the network security system 155 to define and manage the content policies 187. The network security system 155 is a multi-tenant system, and therefore, according to some implementations, users of the administration client can only modify the content policies 187 associated with their organization. In some implementations, an API may be provided to programmatically define and / or update the policies. In such implementations, the administration client 112 may include one or more servers, for example, a corporate identity directory such as Microsoft Active Directory, a Google Drive file storage and synchronization service, or a Slack business communication platform that pushes updates and / or responds to pull requests for updates to the content policies 187. Both systems may also coexist, for example, some enterprises may use a corporate identity directory to automate the identification of users within the enterprise, while using a web interface to tailor policies to the needs of the users. Administration clients are assigned roles, and access to the network security system 155 data is controlled based on the role, for example, read-only / read-write.

[0026] The control plane may be used in conjunction with or instead of the management plane 174 and data plane 180. The particular division of functionality between these groups is an implementation choice. Similarly, functionality may be highly distributed across several points of presence (POPs) to improve locality, performance, and / or security. In one embodiment of the disclosed technology, the data plane is on-premise or on a virtual private network, and the management plane of the network security system is located in a cloud service or with the corporate network. In other secure network implementations, the POPs may be distributed differently.

[0027] Although system 100 is described herein with reference to particular blocks, it should be understood that the blocks are defined for convenience of description and are not intended to require a particular physical arrangement of components. Furthermore, the blocks need not correspond to physically separate components. To the extent that physically separate components are used, connections between the components can be wired and / or wireless as appropriate. Different elements or components can be combined into a single software module and multiple software modules can be executed on the same hardware.

[0028] Furthermore, the technology can be implemented using two or more separate and distinct computer-implemented systems that cooperate and communicate with each other. The technology can be implemented in numerous ways, such as as a process, a method, an apparatus, a system, a device, a computer-readable medium such as a computer-readable storage medium storing computer-readable instructions or computer program code, or as a computer program product that comprises a computer usable medium having computer-readable program code embodied therein. The disclosed technology can be implemented in the context of any computer-implemented system, including a database system or relational database implementation, such as an Oracle™-compatible database implementation, an IBM DB2 Enterprise Server™-compatible relational database implementation, a MySQL™- or PostgreSQL™-compatible relational database implementation, or a Microsoft SQL Server™-compatible relational database implementation, or a NoSQL non-relational database implementation such as a Vampire™-compatible non-relational database implementation, an Apache Cassandra™-compatible non-relational database implementation, a BigTable™-compatible non-relational database implementation, or an HBase™- or DynamoDB™-compatible non-relational database implementation. Additionally, the disclosed techniques can be implemented using different programming models, such as MapReduce™, bulk synchronous programming, MPI primitives, or different scalable batch and streaming management systems, such as Amazon Elasticsearch Service™, Amazon Web Services (AWS)™ including Amazon Kinesis™, Apache Storm™, Apache Spark™, ​​Apache Kafka™, Apache Flink™, Truviso™, IBM Info-Sphere™, Borealis™, and Yahoo! S4™.

[0029] The network security system 155 monitors user interactions with tens of thousands of cloud-based applications and generates metadata from raw event data as information collected from cloud application transactions passes through the system. Customer data privacy protection 156 within the network security system 155 accepts live network traffic from client devices 142 and generates event metadata on the fly, including metadata identifying which users are utilizing which cloud apps, to represent events such as logins, file uploads, and logouts. The live network traffic corresponding to cloud app interactions stimulates the creation of events that include user information, including which apps are in use and from which IP addresses the log entries arrive. Cloud service discovery and content-based functionality or activity identification uses algorithm-based traffic analysis to discover cloud services that interface with an organization's network by deeply inspecting service transactions, including calls made to the services, in real time. The disclosed technology uses connectors or standardized integrations to interpret transactions between client devices 142 and cloud services 118. The transactions are decomposed to identify the activities being performed and their associated parameters. Transactions are represented as JSON files, which contain a structure and format that allows monitor 184 to interpret what actions a user is taking in the cloud service as it occurs.

[0030] In some implementations, the collected metadata is processed and / or normalized. In some examples, the metadata includes structured data and feature target specific data structures provided by the cloud services 118. Unstructured data such as free text can also be provided by and targeted to the cloud services 118. The internal inspection engine 175 can aggregate both structured and unstructured data. For example, the assembled metadata is stored in a semi-structured data format such as JSON (JavaScript Option Notation), BSON (binary JSON), XML, Protobuf, Avro, or Thrift objects, which consist of string fields (or columns) and corresponding values ​​of potentially different types such as numbers, strings, arrays, objects, etc. In other implementations, the JSON objects can be nested and fields can be multi-valued, e.g., arrays, nested arrays, etc. These JSON objects are stored in a schemaless or NoSQL key-value metadata store 148 that stores the parsed JSON objects using keyspaces similar to SQL databases, such as Apache Cassandra™ 158, Google's BigTable™, HBase™, Voldemort™, CouchDB™, MongoDB™, Redis™, Riak™, Neo4j™, etc. Each keyspace is divided into column families, which consist of a set of rows and columns, similar to a table.

[0031] In one implementation, the internal inspection engine 175 includes a metadata parser (omitted for clarity) that analyzes incoming metadata and identifies keywords, events, user IDs, locations, demographics, file types, timestamps, etc. in the received data. Parsing is the process of breaking down and analyzing a stream of text into keywords or other meaningful elements called "targetable parameters." In one implementation, a list of target parameters is input for further processing, such as parsing by a matching engine (not shown) or text mining. Parsing extracts meaning from the available metadata. In one implementation, tokenization operates as the first step of parsing to identify granular elements (e.g., tokens) in the stream of metadata, but parsing then proceeds to use the context in which the tokens are found to determine the meaning and / or type of information being referenced. Because the metadata analyzed by the internal inspection engine 175 is not homogenous (e.g., there are many different sources in many different formats), certain implementations employ at least one metadata parser per cloud service, and possibly more than one. In other implementations, the internal inspection engine 175 uses monitors 184 to inspect cloud services and assemble content metadata.

[0032] FIG. 2 illustrates a high-level block diagram 200 of the flow of user data representing SaaS application events for internal inspection. A SaaS user 202 utilizes a SaaS application 242 over a network 145. The SaaS user 202 can operate any of a variety of devices of managed clients 112, such as tablet 122 and mobile 132, and can operate from client devices 142, such as mobile 152 and computer 162. Exemplary third-party managed cloud SaaS apps include Office 365, Box cloud content management, Salesforce, Google Workplace, and Amazon Web Services (AWS). The SaaS app can impose rate limits on API calls based on an identified user's service level agreement (SLA) and the number of API calls made on behalf of the user per unit of time, or based on an organization's SLA and the number of API calls made by a group of users within the organization. The SaaS application 242 pushes notifications representing events. Sample event notification metadata is illustrated in FIGS. 5A and 5B, and 6A, 6B, and 6C, and example events are described later in this specification.

[0033] Continuing with the description of block diagram 200, the internal inspection engine 175 receives notifications of user events from the SaaS application 242 at the receiver 235 on behalf of users or administrators of the instance or account. The SaaS application 242 is also integrated with bots or scripts that generate updates to objects in the SaaS app via API calls. In one embodiment, a sync application or download bot generates many potential API call events, such as 10,000 operations in one sequence, which can generate a series of operations for a single user in an organization. A single queue can result in delays for low demand users due to a single high demand user. The internal inspection engine 175 also receives these updates as notifications. The internal inspection engine 175 identifies the updates and acts on them. The receiver 235 receives and evaluates pushed notifications that trigger user compliance checks and power user identification. The receiver 235 sends notifications to the scheduler 255, which schedules processing to the worker 275 that processes the data stream in association with the SaaS application 242. The number of operations performed by a third-party SaaS vendor on behalf of a user is related to the number of API calls allowed to a user per unit of time, as one aspect of managing SLA agreements, as discussed above. The disclosed technique identifies users who generate more notifications than can be processed. This mitigates problems that arise due to creating operations and scheduling work in workers 275 without information about the number of operations the worker can perform for a user per unit of time, as an overwhelming number of notifications would clog the head of the line and delay the processing of other users' notifications.

[0034] FIG. 3 illustrates a block diagram 300 for identifying power users who generate more notifications than can be processed per unit time according to the user's SLA agreement. The network security system 155 uses the power user identifier 352 to uniquely identify the power user using the login and ID in the notification metadata and monitors the API event rate for requests to the SaaS vendor from the user group collectively and from individual users in the user group. In some cases, the SaaS application 242 sends notifications about API events from users in the user group to the power user identifier 352 and scheduler 255. The power user identifier 352 can recognize power users as submitting API events beyond the limit and determine when the identified user is consuming more than the allocated number of operations per unit time specified in the organization's SLA. The power user identifier 352 provides the power user's identification information to the scheduler 255, which can take action based on the feedback and generate an alert 372 for the identified power user. Action options are described later in this specification. The scheduler 255 takes into account the information from the power user identifier 352 and the results of tracking the user's data usage when scheduling notification processing by the workers 275. In another case, one or more active analyzers 165 monitor the rate or amount in time of API events based on a count of API event requests being submitted to the SaaS vendor via the primary and auxiliary queues 377. The power user identifier 352 maintains a sliding window for tracking each user's data usage and stores each user's data usage value as an entry in a table in the data usage store 342 at regular time increments.

[0035] FIG. 4 shows an example table of API event counts in time windows for multiple users to track the user's impact on API event rates. The table shows seven consecutive time windows for four users to track the user's API event rates over time. Each time the SaaS application 242 sends a notification to the power user identifier 352, the API event rate and volume are updated in the data usage store 342. To recognize power users, for each user represented in a separate row of the table shown in FIG. 4, a running sum of the values ​​of the previous n windows and the value added to the current window is calculated. If the sum is greater than a configurable threshold, the user is identified as a power user for the next specified amount of time x. At the end of the period x, the user may be reset from a power user to a normal user. A user may be marked as a power user whenever the sum of the values ​​of a configured number of consecutive time windows, i.e., their data usage, is greater than the threshold over a sliding window of interest. In FIG. 4, four users u1, u2, u3, and u4 are actively generating events. For each of the four users, the number of notifications received in each of the seven time windows w1, w2, w3, w4, w5, w6, and w7 are listed in the rows of the table. In this example, the configured policy specifies that a power user is defined as a user who uses more than a threshold of 100 in the last five consecutive slots. The value of the limit is configured to a particular value based on exceeding or approaching a SaaS-imposed trigger for a throughput penalty for the user group. In this example, the power user identifier 352 generates an alert 372 because the sum of u3 of the number of notifications in five consecutive time windows 455 (shaded) is 4+20+40+5+40=109. User u3 is designated a power user by submitting an API event that exceeds the limit set to 100 in this example.When a user is identified as a power user, the sending of API event submissions from the power user to the SaaS is allocated to avoid triggering a throughput penalty by the SaaS. In some cases, the power user is a bot programmed to generate API events.

[0036] The overall effect of the disclosed method is to decrease the latency for users in the user group other than power users and increase the latency for power users. In one embodiment, the policies describing power users are configurable for an organization by a human administrator and represent the requirements of an SLA agreement for the organization.

[0037] The internal inspection engine 175 monitors a range of operations that cause the SaaS application 242 to generate API event notifications including file creation, file editing, and file sharing. Files can be shared through the use of collaboration, with options to add users, create links, remove users, delete links, and give users permission to edit, view, share, or unshare. Additional operations include copy, move, download, and lock via create lock and delete lock. Further operations include delete, undelete, open, preview, and update metadata, which are sometimes used. Typically, one API call is used for one operation, and one API call corresponds to a single API event.

[0038] 5A and 5B list an example pushed API notification received from a third-party SaaS vendor for a network event, along with notification metadata in a JSON style representation. A user can be uniquely identified as requesting an event type "item upload" 514 using login 534 and id 544. The push notification metadata file shown in FIGS. 5A and 5B is not exhaustive of event-related fields that may be captured in a metadata file, but rather highlights key fields. The power user identifier 352 utilizes "time created" 548 when calculating a slide table entry for a user identified by login 534 and id 544.

[0039] 6A, 6B, and 6C list example metadata in a JSON style representation for the network API event "item created" 604. A unique identifier for the user is captured by login 674 and ID 684, and the power user identifier 352 utilizes the time content created 664 to calculate a count of notifications per unit time to identify the power user.

[0040] Actions can be configured in response to the API event rate exceeding or approaching a SaaS-imposed trigger of a throughput penalty for a user group. A user can be quarantined from further processing if an administrator sets a policy to select that option. One action option is to slow down the notification workload of a particular user, ensuring that resources are usefully utilized for notification processing of other users. That is, allocation of sending API event submissions from a power user to the SaaS can be done by blocking the power user from making API event submissions to the SaaS. Blocking an identified power user can be for a predetermined time or until the overall submissions by the user group do not exceed the SaaS-imposed trigger. Another action option can be allocation by temporarily stopping the power user from making API event submissions to the SaaS. The temporary stopping can be for a predetermined time or until the overall submissions by the user group do not exceed the SaaS-imposed trigger. In some cases, an action by a user may violate a policy. In this case, the configured policy may suspend the user until a human administrator determines that a different action is warranted. In one example, a user may add a shared link, such as a link to a box, to a file. Anyone with the shared link can access the file, meaning that the file is considered public. Below is an example of adding a shared link to a file: curl --location --request PUT 'https: / / api.box.com / 2.0 / files / 12345?fields=shared_link' \ --header 'Content-Type: application / json' \ --header 'Authorization:Bearer {{access_token_redacted}}' \ --data-raw '{ "shared_link": { “access”: “open”, “password”: “very-strong-password”, “vanity_name”: “my-shared-link”, “unshared_at”:“2021-12-12T10:53:43-8:00”, "permissions": { "can_download": true } } }'

[0041] Security policy enforcement or an API event initiated by an administrator can successfully set the link to null, so that the original link is no longer valid and the file is no longer publicly accessible, thereby enforcing enterprise policy. Typically, this type of policy is set to match any file with sensitive content that is not expected to be posted publicly. The code for removing a shared link on a file is listed below. curl --location --request PUT 'https: / / api.box.com / 2.0 / files / 12345?fields=shared_link' \ --header 'Content-Type: application / json' \ --header 'Authorization:Bearer {{access_token_redacted}}' \ --data-raw '{ "shared_link": null }'

[0042] Another action option may be to alert an administrator and send a notification to a human user to track the blocking or temporary suspension. A security policy may include monitoring the rate of notifications for a user per x amount of time to identify that the user may be taking some action defined by the policy as anomalous. For example, is the user downloading an excessive amount of content as defined by a configured policy? If the user has 100K files and starts downloading them, a few seconds or a minute after the first 100 notifications, the administrator may receive an alert that triggers that something is wrong and therefore the user needs to be suspended. In this case, the human administrator may have one of several options: to quarantine or block the user and / or to request further credentials for permission to continue the action.

[0043] One example action is Figure 7A shows an example alert 372 and message 724 informing an administrator that user Chandra downloaded 1028 files in less than 5 minutes. Figure 7B shows an example email that an administrator receives when a power user violates a configured policy in one embodiment of the disclosed technology. In this example, the power user has been disabled 774 for the violation.

[0044] FIG. 8 illustrates a graph showing reduced latency for 9 of 10 users showing API events received over a 5 minute period. The graph shows the effect of allocation of API event submissions from power users to the SaaS allocated via the disclosed method. The total number of API event notifications received 816, close to 1500 notifications, is shown by the curve closest to the top of the graph. The graph shows the curves for the number of notifications from the offending user (power user) 866 as about 500 events, and notifications from 9 other users 846. Two scenarios are shown by the remaining curves. In one scenario, the user is not quarantined; that is, the SaaS limits (throttles) the API events of all active users after reaching their combined threshold, and the total number of notifications processed without user quarantine 856 is a slightly higher curve than the number of notifications for power users only 866. In the second scenario, the users are monitored and the power users are recognized as submitting a higher volume of API events per hour, exceeding the limit. The sending of API event submissions for power users is allocated to avoid triggering throughput penalties for user groups. In this second scenario, the number of notifications 836 processed with user quarantine for power users is much higher, about 1000 API event notifications, i.e., less latency for users in the non-power user user group and more latency for power users. Only when the total demand for processing API event notifications exceeds the SaaS-triggered limit does it become necessary to throttle the API event rate for power users.

[0045] In a different action, once a power user is recognized, the active analyzer 165 can set up a separate queue to handle the power user's event notifications to protect resources for the remaining users of the organization's user group. The disclosed process, in its embodiment, includes monitoring the rate or volume of API events in time based on a count by one or more active analyzers of API event requests being submitted to the SaaS vendor. The allocation can be done by assigning the power user to an auxiliary API event queue managed by the proxy that slows the rate of submissions by the power user to the SaaS vendor. The auxiliary API event queue allocation can be released when the updated rate or volume of API event submissions by the power user falls below a recovery limit or when the updated rate or volume of API event submissions by the user group, as a whole, does not exceed a SaaS-imposed trigger. In another case, the allocation to the auxiliary API event queue can be released when the auxiliary API event queue is empty or continues to fall below a queue depth limit for a predetermined time. In another case, the allocation may be by the proxy assigning power users to overflow API event channels that separate the processing of submissions for the power users from submissions for other users in the user group, and de-allocating the overflow API event channel when the updated rate or volume of API event submissions by the power users falls below a restoration limit. In other cases, the overflow API event channel may be configured to be de-allocated when the updated rate or volume of API event submissions by the user group, taken as a whole, no longer exceeds a SaaS-imposed trigger, or when the auxiliary API event queue is empty or remains below a queue depth limit for a predefined time. In some cases, the SaaS may separately meter the usage of the overflow API event channel.

[0046] Next, a workflow is described for avoiding throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users in the user group.

[0047] Workflow FIG. 9 illustrates an exemplary method for avoiding throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users in the user group. Flowchart 900 may be implemented, at least in part, with a computer or other data processing system, such as by one or more processors configured to receive or obtain information, process the information, store the results, and transmit the results. Other implementations may perform actions in a different order and / or with different, fewer, or additional actions than those illustrated in FIG. 9. In some implementations, multiple actions may be combined. For convenience, the flowchart is described with reference to a system that performs the method. A system is not necessarily part of the method.

[0048] The methods described in this and other sections of the disclosed technology may include one or more of the following features and / or features described in connection with the additional methods disclosed. For brevity, combinations of features disclosed in this application are not individually recited and are not repeated with each base set of features.

[0049] FIG. 9 begins with action 910 which involves monitoring the rate or amount over time of API events for requests from a user group, collectively, and from individual users within the user group to a SaaS vendor.

[0050] Process 900 proceeds to action 920, where when the rate or volume of API events for the user group as a whole exceeds or approaches a SaaS-imposed trigger of a throughput penalty for the user group, the power user is recognized as submitting API events beyond the limit, and action is taken to reduce the power user's impact on the rate or volume of API events for the user group.

[0051] Action 930 includes allocating transmission of API event submissions from power users to the SaaS to avoid triggering a throughput penalty by the SaaS, thereby reducing latency for users in a user group other than power users and increasing latency for power users.

[0052] Other implementations of the methods described in this section may include a non-transitory computer-readable storage medium storing instructions executable by a processor to perform any of the methods described above. Still other implementations of the methods described in this section may include a system including a memory and one or more processors operable to execute instructions stored in the memory to perform any of the methods described above.

[0053] Computer Systems 10 is a simplified block diagram of a computer system 1000 that may be used to avoid throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users in the user group. The computer system 1000 includes at least one central processing unit (CPU) 1072 that communicates with several peripheral devices via a bus subsystem 1055, and a network security system 155 for providing the network security services described herein. These peripheral devices may include, for example, a storage subsystem 1010 including memory devices and a file storage subsystem 1036, a user interface input device 1038, a user interface output device 1076, and a network interface subsystem 1074. The input and output devices enable user interaction with the computer system 1000. The network interface subsystem 1074 provides an interface to external networks, including interfaces to corresponding interface devices in other computer systems.

[0054] In one implementation, the network security system 155 of FIG. 1 is communicatively linked to the storage subsystem 1010 and the user interface input device 1038 .

[0055] The user interface input devices 1038 can include pointing devices such as a keyboard, a mouse, a trackball, a touchpad, or a graphics tablet, a scanner, a touch screen integrated into a display, audio input devices such as a voice recognition system and a microphone, as well as other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and methods for inputting information into the computer system 1000.

[0056] The user interface output devices 1076 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a flat panel device such as an LED display, a cathode ray tube (CRT), a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visible image. The display subsystem may also provide non-visual displays such as an audio output device. In general, use of the term "output device" is intended to include all possible types of devices and methods for outputting information from computer system 1000 to a user or to another machine or computer system.

[0057] Storage subsystem 1010 stores programming and data structures that provide the functionality of some or all of the modules and methods described herein. Subsystem 1078 can be a graphics processing unit (GPU) or a field programmable gate array (FPGA).

[0058] The memory subsystem 1022 used within the storage subsystem 1010 may include several memories, including a main random access memory (RAM) 1032 for storing instructions and data during program execution, and a read only memory (ROM) 1034 in which fixed instructions are stored. The file storage subsystem 1036 may provide persistent storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules that implement the functionality of a particular implementation may be stored by the file storage subsystem 1036, within the storage subsystem 1010, or within another machine accessible by the processor.

[0059] Bus subsystem 1055 provides a mechanism for allowing the various components and subsystems of computer system 1000 to communicate with each other as intended. Although bus subsystem 1055 is shown generally as a single bus, alternative implementations of the bus subsystem may use multiple buses.

[0060] The computer system 1000 itself can be of a variety of types, including a personal computer, a portable computer, a workstation, a computer terminal, a network computer, a television, a mainframe, a server farm, a widely distributed set of loosely networked computers, or any other data processing system or user device. Due to the ever-changing nature of computers and networks, the description of the computer system 1000 shown in Figure 10 is intended only as a specific example for illustrating a preferred embodiment of the present invention. Many other configurations of computer system 1000 are possible, having more or fewer components than the computer system shown in Figure 10.

[0061] Specific Implementations Some specific implementations and features for avoiding throughput penalties imposed by a SaaS vendor on a user group due to excessive API events from users within the user group are described in the following discussion.

[0062] In one disclosed implementation, a disclosed method of avoiding a throughput penalty imposed by a SaaS vendor on a user group due to excessive API events from users in the user group includes collectively monitoring the rate or volume of API events over time for requests from the user group and requests from individual users in the user group to the SaaS vendor. The method includes recognizing power users who submit API events over a limit and taking action to reduce the power user's impact on the rate or volume of API events for the user group. Taking action may be limited to situations when the rate or volume of API events for the user group as a whole exceeds or approaches a SaaS-imposed trigger of a throughput penalty for the user group. The disclosed method further includes allocating transmission of API event submissions from the power users to the SaaS to avoid triggering a throughput penalty by the SaaS, thereby reducing latency for users in the user group other than the power users and increasing latency for the power users.

[0063] The methods described in this and other sections of the disclosed technology may include one or more of the following features and / or features described in connection with the additional methods disclosed. For the sake of brevity, combinations of features disclosed in this application are not individually recited and are not repeated with each basic set of features. The reader will understand how features identified in this method can be readily combined with the set of basic features identified as an implementation.

[0064] In one implementation, the disclosed method of monitoring the rate or volume of API events can be handled with a SaaS implementation notifying a collector based on notification from a SaaS vendor of API events for a user group. In an alternative implementation, monitoring the rate or volume of API events can be handled based on counting by one or more active analyzers of API event requests being submitted to a SaaS vendor, with the subscriber notifying a collector.

[0065] Allocation may include blocking power users from making API event submissions to the SaaS, which may apply to bots programmed to generate API events, which may include sending notifications to human users to track the blocking.

[0066] Allocation may include temporarily suspending power users from making API event submissions to the SaaS. This may apply to bots programmed to generate API events. It may be for a predefined amount of time or until the overall submissions by a group of users do not exceed a trigger imposed by the SaaS. It may include sending a notification to a human user to follow up on the temporary suspension.

[0067] The allocation may include assigning the power user to an auxiliary API event queue managed by the proxy, which slows and possibly throttles the rate of submissions on behalf of the power user. An allocation to an auxiliary API event queue may be released when an updated rate or volume of API event submissions by the power user falls below a recovery limit. An allocation to an auxiliary API event queue may be released when an updated rate or volume of API event submissions by a group of users, taken as a whole, no longer exceeds a SaaS-imposed trigger. An allocation to an auxiliary API event queue may be released when the auxiliary API event queue is empty or remains below a queue depth limit for a predefined time. The SaaS may separately meter usage of the overflow API event channel in some implementations.

[0068] Allocation may include assigning power users to overflow API event channels managed by a proxy that separates the meeting of submissions for the power users from submissions for other users in the user group. Use of overflow API event channels may be billed separately by the SaaS. Allocations to overflow API event channels may be released when an updated rate or volume of API event submissions by a power user falls below a restoration limit. Allocations to overflow API event channels may be released when an updated rate or volume of API event submissions by a user group, collectively, no longer exceeds a SaaS-imposed trigger. In some implementations, the SaaS separately meters usage of overflow API event channels.

[0069] Other implementations of the methods described in this section may include a tangible, non-transitory computer-readable storage medium storing program instructions loaded into a memory that, when executed on a processor, causes the processor to perform any of the methods described above. Yet another implementation of the methods described in this section may include a device including a memory and one or more processors operable to execute computer instructions stored in the memory to perform any of the methods described above.

[0070] Any data structures and code described or referenced above are, according to many implementations, stored on a computer readable storage medium, which may be any device or medium capable of storing code and / or data for use by a computer system, including, but not limited to, volatile memory, non-volatile memory, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), magnetic and optical storage devices such as disk drives, magnetic tape, compact discs (CDs), digital versatile discs or digital video discs (DVDs), or other media capable of storing computer readable media now known or hereafter developed.

[0071] The foregoing description is presented to enable making and using the disclosed technology. Various modifications to the disclosed implementations will become apparent, and the general principles defined herein may be applied to other implementations and applications without departing from the spirit and scope of the disclosed technology. Thus, the disclosed technology is not intended to be limited to the implementations shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. The scope of the disclosed technology is defined by the appended claims.

Claims

1. 1. A method for preventing throughput penalties imposed by a Software as a Service (SaaS) vendor on a group of users due to excessive Application Programming Interface (API) events from the group, comprising: Monitoring a rate or amount in time of API events relative to requests from users of a user group, both as individuals and as registered members of said user group to a SaaS vendor; identifying power users who are registered as members of the user group that submit API events beyond a limit based on the monitoring; throttling, for the user group, a rate or volume in time of API event submissions by the power users to the SaaS vendor based on a configurable policy specific to the SaaS vendor managed by a proxy, thereby reducing the impact of the power users on the rate or volume in time of the API events for the user group, at least when the rate or volume in time of the API events for the user group, collectively, exceeds or approaches a trigger for imposing the throughput penalty on the user group by a SaaS vendor, thereby reducing the imposition of the throughput penalty by the SaaS vendor.

2. The method of claim 1 , further comprising monitoring a rate or amount over time of the API events based on notifications of processing of API events for the user group generated by the SaaS vendor.

3. 10. The method of claim 1, further comprising monitoring a rate or amount over time of the API events based on a count by one or more active analyzers of API event requests being submitted to the SaaS vendor.

4. 2. The method of claim 1, further comprising identifying the power users by monitoring the rate or amount over time of APIs of the users of the user group that consume a number of operations per unit time that exceeds a threshold specified in the configurable policy specific to the SaaS vendor.

5. The method of claim 1 , wherein the SaaS vendor-specific configurable policies are configured by the proxy to guarantee a third-party service level agreement (SLA) for the user group.

6. 2. The method of claim 1, further comprising throttling the rate or amount over time of the power user by one of blocking and temporarily ceasing the power user from making API event submissions to the SaaS vendor.

7. The method of claim 6 , wherein the temporary suspension is for a predetermined amount of time or until the overall submissions by the user group do not exceed a SaaS-imposed trigger.

8. 2. The method of claim 1, further comprising allocating transmission of API event submissions from the power users by assigning the registered power users to an overflow API event channel managed by the proxy that isolates processing of submissions for the registered power users from processing of submissions for other users of the user group, and throttling the rate or amount in time of the power users' API event submissions.

9. 10. The method of claim 8, further comprising deallocating the overflow API event channel when an updated rate or amount in time of API event submissions by the power users falls below a recovery limit.

10. 10. The method of claim 8, further comprising deallocating the overflow API event channel when an updated rate or amount in time of API event submissions by the user group, collectively, no longer exceeds a SaaS-imposed trigger.

11. 9. The method of claim 8, further comprising deallocating the overflow API event channel when the overflow API event channel is empty or remains below a queue depth limit for a predetermined period of time.

12. The method of claim 8 , wherein the SaaS vendor separately meters usage of the overflow API event channel.

13. 1. A tangible, non-transitory computer-readable storage medium comprising program instructions loaded onto a memory that, when executed on a hardware processor, causes the hardware processor to perform steps for preventing a throughput penalty imposed by a Software as a Service (SaaS) vendor on a group of users due to excessive Application Programming Interface (API) events from the group, the steps comprising: monitoring a rate or amount in time of API events to requests from users of a user group as registered members of said user group to individuals and SaaS vendors; identifying power users who are registered members of the user group that submit API events beyond a limit based on the monitoring; and throttling, for the user group, a rate or amount in time of API event submissions by the power users to the SaaS vendor based on a configurable policy specific to the SaaS vendor managed by a proxy, such that, collectively, at least when the rate or amount in time of the API events for the user group exceeds or approaches a SaaS vendor-imposed trigger for the throughput penalty to the user group, reducing the impact of the power users on the rate or amount in time of the API events for the user group, thereby avoiding the throughput penalty by the SaaS vendor from triggering.

14. 14. The tangible, non-transitory computer-readable storage medium of claim 13, further comprising throttling the rate or amount in time of API event submissions by one of blocking and temporarily ceasing the power user from making API event submissions to the SaaS.

15. 14. The tangible, non-transitory computer readable storage medium of claim 13, further comprising the step of sending a notification to a human user to follow up on the interruption or temporary suspension.

16. 15. The tangible, non-transitory computer-readable storage medium of claim 14, wherein the temporary suspension is for a predetermined amount of time or until overall submissions by the user group do not exceed a SaaS-imposed trigger.

17. 14. The tangible, non-transitory computer-readable storage medium of claim 13, further comprising the step of allocating transmission of API event submissions from the power user by assigning the power user to an overflow API event channel managed by the proxy that isolates processing of submissions for the power user from processing of submissions for other users of the user group, and throttling the rate or amount in time of the power user's API event submissions.

18. 1. A system for preventing throughput penalties imposed on a group by a Software as a Service (SaaS) vendor due to excessive application programming interface (API) events from the group, the system including a processor, a memory coupled to the processor, and computer instructions loaded into the memory, the computer instructions, when executed, perform: monitoring a rate or amount in time of API events to requests from users of a user group as registered members of said user group to individuals and SaaS vendors; identifying power users who are registered members of the user group that submit API events beyond a limit based on the monitoring; throttling, for the user group, a rate or amount in time of API event submissions by the power users to the SaaS vendor based on a configurable policy specific to the SaaS vendor managed by a proxy, thereby reducing the impact of the power users on the rate or amount in time of the API events for the user group, at least when the rate or amount in time of the API events for the user group, collectively, exceeds or approaches a trigger for imposing the throughput penalty on the user group by the SaaS vendor, thereby avoiding the throughput penalty by the SaaS vendor from triggering.

19. 20. The system of claim 18, wherein the steps further include allocating transmission of API event submissions from the power user by assigning the power user to an overflow API event channel managed by the proxy that isolates processing of submissions for the power user from processing of submissions for other users of the user group, and throttling the rate or amount in time of the power user's API event submissions.

20. 1. A network security system for preventing throughput penalties imposed on a group by a Software as a Service (SaaS) vendor due to excessive application programming interface (API) events from the group, comprising: one or more active analyzers coupled to memory having executable instructions loaded therein and configured to monitor a rate or amount over time of API events for requests submitted to a SaaS vendor from users of a user group, both as individuals and as registered members of the user group; a power user identifier coupled to the active analyzer and configured to identify, based on the monitoring, a power user that excessively submits API events; a scheduler configured to receive API event submissions from the user group and to schedule the API event submissions of the user group, collectively, for processing by a worker; The scheduler is coupled to the power user identifier to receive identification information of the power user, and is configured to throttle a rate or amount in time of API event submissions by the power user based on a configurable policy specific to the SaaS vendor and managed by a proxy, thereby reducing the impact of the power user on the rate or amount in time of the API events of the user group, at least when the rate or amount in time of the API events from the user group collectively exceeds a policy limit or approaches a trigger for the imposition of the throughput penalty on the user group imposed by the SaaS vendor.

21. 21. The network security system of claim 20, wherein the scheduler that receives notifications of the processing of the API event submissions for the user group sent from the SaaS vendor is further configured to throttle a rate of notification processing for the power users and increase a rate of notification processing for other users in the user group.

22. 21. The network security system of claim 20, wherein the one or more active analyzers monitor a rate or amount over time of API events based on a count of API event requests being submitted to the SaaS vendor via a primary queue and an auxiliary queue.

23. 23. The network security system of claim 22, wherein the scheduler is further configured to throttle the power user's submission of API event submissions by assigning the power user to an auxiliary queue managed by a proxy that throttles the rate and amount in time of API event submissions by the power user.

24. 21. The network security system of claim 20, wherein the scheduler is further configured to allocate transmissions of the power user's API event submissions by assigning the power user to an overflow API event channel managed by a proxy that isolates processing of submissions for the power user from processing of submissions for other users in the user group.

Images