A dynamic power user throttling method for managing SLA guarantees

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. Non-Provisional 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 (Attorney Docket No. NSKO1003-2), entitled "Systems and Methods of Enforcing Multi-Part Policies on Data-Deficient Transactions of Cloud Computing Services," filed December 2, 2016 (now U.S. Patent No. 10,826,940, issued November 3, 2020), and U.S. Provisional Patent Application No. 62 / 307,305 (Attorney Docket No. NSKO1003-1), entitled "Systems and Methods of Enforcing Multi-Part Policies on Data-Deficient Transactions of Cloud Computing Services," filed March 11, 2016; “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 group for security and regulatory compliance purposes. 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. Likewise, it should not be assumed that the problems mentioned in this section, or problems 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, which may themselves correspond to implementations of the claimed technology.

[0006] The use of cloud services for corporate functions is common; studies suggest that 80% of enterprise workloads will reside in the cloud by 2025. According to 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, enterprises often use 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 their corporate networks to deliver services. SaaS solution providers offer service level agreements (SLAs) between the service and their customers that set expectations for guaranteed availability, performance, security, and privacy of customer data. Customers, in turn, expect to be able to securely collaborate and create, edit, and store their data across multiple customer branches and data centers.

[0008] As one example of the need for adequate security services, in 2020, the global pandemic caused a sudden shift to remote work 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, the techniques used in more sophisticated cyberattacks also continued to evolve. Applicant reports that attackers have changed their initial delivery techniques, 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 enterprise victims, with over 50% of these files 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 identified notifications 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 the number of operations performed for a user is a factor in the number of API calls allowed for the user per unit of time. API calls are a scarce resource that must be used efficiently, which motivates the utility of limiting the operations created in workers to the amount of work a user can perform. Creating and scheduling operations in workers blindly to users and notifications can lead 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, 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 explanation 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. [Figure 2]1 illustrates a high-level block diagram of the flow of user data representing SaaS application events for internal inspection. [Figure 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] 10 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] 10 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] 10 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 the 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 a throughput penalty 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 within the user group, according to one implementation of the disclosed technology. DETAILED DESCRIPTION OF THE INVENTION

[0013] The following detailed description is made with reference to the drawings. Example 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, which are received from the SaaS app as notifications.

[0015] SaaS apps impose rate limits on API events and can impose rate limits based on several factors. One common factor for rate limiting is user-based. A limit can be placed on the number of API events per user for a user. Because 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 in the number of API events a user is allowed per unit of time. That is, API events are a scarce resource that must be used efficiently, which promotes the usefulness of limiting the operations created in worker processes to the amount of work that can be performed for a user. Creating and scheduling operations to worker processes blindly for users and notifications can lead to head-of-line blocking, a performance-limiting phenomenon that occurs when a line of packets becomes clogged with the leading packet, delaying the processing of other user 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 typically imposed by SaaS vendors on user groups due to excessive API events from users within an organization's user group. The approach disclosed by the applicant monitors API event rates for requests from the user group and from individual users within the user group to the SaaS vendor, recognizes power users as those submitting API events that exceed limits, and takes action to reduce the power user's impact on the user group's API event rate. When a user is recognized as a power user, the information is fed back to a scheduler, which can take action to not allow the user to continue their intended operation based on the rate at which the power user performs operations. In one example, the action is to throttle a particular user's notification workload to ensure that resources are effectively utilized for processing notifications for other users. This approach benefits system throughput and the organization, also referred to as a customer, because power users are identified and their usage is throttled to SLA guarantees based on the API quota available per user, allowing SLA guarantees for other users to be maintained. Configurable actions can be set up by an administrator as a policy to isolate a user from further processing, or 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 group due to excessive API events from users within the user group will be described.

[0019] system FIG. 1 illustrates an architectural-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 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 device 132, the cloud service 118 includes cloud service A 128 through cloud service Z 138, and the client device 142 includes a mobile device 152 and a computer 162. Active analyzer 165 uses monitor 184 to enforce policies on sensitive content in real time as it traverses network 145. 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, user identity may be linked to a specific user and a specific device; thus, the same individual may have different user identities for their mobile phone and computer. User identity may be linked to, but distinct from, an entry or user ID corporate identity directory. In one implementation, a cryptographic certificate signed by network security is used as the user identity. In other implementations, user identity may be unique only to the user and be the same across devices.

[0020] Continuing with the description of system 100, in some implementations, 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 system 100, network 145 communicatively couples management client tablet 122 and mobile 132, client device mobile 152 and computer 162, cloud service A 128-cloud service Z 138, and network security system 155. Communication paths can be point-to-point over public and / or private networks. Communication can occur over various 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 generally occurs over networks such as local area networks (LANs), wide area networks (WANs), telephone networks (public switched telephone networks (PSTNs)), session initiation protocol (SIP), wireless networks, point-to-point networks, star networks, token ring networks, hub networks, and 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, and digital certificates.

[0023] Continuing the description of the system architecture of FIG. 1 , the network security system 155 includes a monitor 184 and 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 physical computers or traditional virtual machines, other computing-as-a-service platforms, such as Salesforce's Rackspace, Heroku, or Force.com, may be used. Furthermore, one or more engines may be used to implement security functions, 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. For 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 FIG. 1 , system 100 includes network security system 155 with customer data privacy protection 156, which accesses various functions via management plane 174 and data plane 180. According to one implementation, data plane 180 includes extraction engine 171, classification engine 172, and security engine 173. Other functions, such as a control plane, may also be provided. These functions collectively provide a secure interface between cloud services 118 and client devices 142. While the term "network security system" is used to describe 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 across the servers in use by client devices 142.

[0025] According to one implementation, the administration client 112 is a computing device with a web browser that has a secure web-delivered interface provided by the network security system 155 for defining and managing content policies 187. The network security system 155 is a multi-tenant system; therefore, according to some implementations, users of the administration client can only modify content policies 187 associated with their organization. In some implementations, an API may be provided for programmatically defining and / or updating policies. In such implementations, the administration client 112 may include one or more servers, such as 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 content policies 187. Both systems may coexist; for example, some companies may use a corporate identity directory to automate the identification of users within the company while using a web interface to tailor policies to user needs. Administration clients are assigned roles, and access to network security system 155 data is controlled based on the role, such as 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 a premises or virtual private network, and the network security system's management plane is located in a cloud service or with the corporate network. In other secure network implementations, the POPs may be distributed differently.

[0027] While 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 physically separate components are used, connections between 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, including as a process, method, apparatus, system, device, 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 with 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. Furthermore, 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 using which cloud apps, to represent events such as logins, file uploads, and logouts. Live network traffic corresponding to cloud app interactions triggers the creation of events containing user information, including which apps are in use and from which IP addresses log entries arrive. Cloud service discovery and content-based function or activity identification uses algorithm-based traffic analysis to discover cloud services interfacing with an organization's network by deeply examining service transactions, including calls made to services, in real time. The disclosed technology uses connectors or standardized integrations to interpret transactions between client devices 142 and cloud services 118. 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 the monitor 184 to interpret what actions a user is performing 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 functional target-specific data structures provided by the cloud service 118. Unstructured data, such as free text, can also be provided by and targeted to the cloud service 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, 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, such as Apache Cassandra™ 158, Google BigTable™, HBase™, Voldemort™, CouchDB™, MongoDB™, Redis™, Riak™, or Neo4j™, which stores the parsed JSON objects using keyspaces similar to SQL databases. Each keyspace is divided into column families, each consisting 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 acts 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 a monitor 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 managed client 112 devices, such as a tablet 122 and a mobile device 132, or from a client device 142, such as a mobile device 152 and a 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 the user's behalf 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. Notification metadata for sample events is illustrated in FIGS. 5A and 5B and 6A, 6B, and 6C, and example events are described later in this specification.

[0033] Continuing with block diagram 200, internal inspection engine 175 receives notifications of user events from SaaS application 242 at receiver 235 on behalf of users or administrators of the instance or account. SaaS application 242 also integrates with bots or scripts that generate updates to objects within 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 a single sequence, which can generate a series of operations for a single user within an organization. A single queue can result in delays for low-demand users due to a single high-demand user. Internal inspection engine 175 also receives these updates as notifications. Internal inspection engine 175 identifies the updates and acts on them. Receiver 235 receives and evaluates pushed notifications, which trigger user compliance checks and power user identification. Receiver 235 sends notifications to scheduler 255, which schedules processing to worker 275, which processes the data stream associated with 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 a user is allowed per unit of time, as discussed above, as one aspect of managing SLA agreements. The disclosed technology identifies users who generate more notifications than can be processed. This alleviates problems that arise from creating operations and scheduling work in workers 275 without information about the number of operations the workers 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 of time according to the user's SLA agreement. The network security system 155 uses a power user identifier 352 to uniquely identify power users using the login and ID in the notification metadata and monitor API event rates for requests to the SaaS vendor from the user group collectively and from individual users within the user group. In some cases, the SaaS application 242 sends notifications about API events from users within the user group to the power user identifier 352 and scheduler 255. The power user identifier 352 recognizes power users as submitting API events in excess of limits and can determine when an identified user is consuming more than the allocated number of operations per unit of 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 information from the power user identifier 352 and the results of tracking users' data usage when scheduling notification processing by the workers 275. In another case, one or more active analyzers 165 monitor the rate or amount of API events over time based on counts 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 periodic time increments.

[0035] FIG. 4 shows an example table of API event counts over time windows for multiple users to track users' impact on API event rates. The table shows seven consecutive time windows for four users to track users' 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 ​​from 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 period x, the user can be reset from a power user to a normal user. A user can be marked as a power user whenever the sum of the values ​​for a configured number of consecutive time windows, i.e., their data usage, is greater than the threshold over the 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 seven time windows w1, w2, w3, w4, w5, w6, and w7 is listed in a row 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 trigger imposed by the SaaS for a throughput penalty for the user group. In this example, the power user identifier 352 generates alert 372 because the sum of the number of notifications u3 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 at 100 in this example.When a user is identified as a power user, their API event submissions to the SaaS are allocated to avoid triggering throughput penalties by the SaaS. In some cases, power users are bots programmed to generate API events.

[0036] The overall effect of this disclosed method is to decrease latency for users in the user group other than power users and increase latency for power users. In one embodiment, the policies describing power users are configurable for an organization by a human administrator and represent requirements of SLA agreements 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 grant 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 occasionally 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 the sliding table entry for the 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. The user's unique identifier 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 power users.

[0040] Actions can be configured in response to the API event rate exceeding or approaching a SaaS-imposed trigger for a throughput penalty for a user group. A user can be quarantined from further processing if an administrator configures a policy to select that option. One action option is to slow a particular user's notification workload, ensuring that resources are better utilized for processing notifications for other users. That is, allocation of API event submissions from power users to the SaaS can be achieved 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 no longer exceed the SaaS-imposed trigger. Another action option can be achieved by temporarily suspending the power user from making API event submissions to the SaaS. The temporary suspension can be for a predetermined time or until the overall submissions by the user group no longer exceed the SaaS-imposed trigger. In some cases, a user's actions may violate a policy. In this case, a configured policy can suspend the user until a human administrator determines that different action is warranted. In one example, a user can add a shared link, such as a link to a box, to a file. Anyone with the shared link can access the file, meaning the file is considered public. The following 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 administrator-initiated API event can successfully set the link to null, resulting in the original link being invalid and the file no longer being 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 might be to alert an administrator and send a notification to a human user to track the blocking or temporary suspension. A security policy might 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 begins downloading them, after the first 100 notifications, a few seconds or a minute later, the administrator might receive an alert that triggers that something is wrong and therefore the user needs to be suspended. In this case, the human administrator can take one of several options: quarantine or block the user and / or require further certification 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 five 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] Figure 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 allocating API event submissions from power users to the SaaS via the disclosed method. The total number of API event notifications received 816, approaching 1,500 notifications, is shown by the curve closest to the top of the graph. The graph shows the number of notifications from the offending user (power user) 866 at approximately 500 events, and the curve for 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 they reach their combined threshold, and the total number of notifications processed without user quarantine 856 is slightly higher than the curve for the number of notifications from power users alone 866. In the second scenario, users are monitored, and power users are identified as submitting a higher volume of API events per hour, exceeding the limit. The power users' API event submissions are rationed to avoid triggering a throughput penalty for the user group. In this second scenario, the number of notifications 836 processed with user quarantine for the power users is much higher: approximately 1,000 API event notifications. This means that users in the non-power user user group experience lower latency and power users experience higher latency. It is only when the total demand for processing API event notifications exceeds the limit triggered by the SaaS that it becomes necessary to throttle the API event rate for the power users.

[0045] In a different action, once a power user is recognized, the active analyzer 165 can set up a separate queue to process the power user's event notifications to protect resources for the remaining users in the organization's user group. In an embodiment, the disclosed process includes monitoring the rate or volume of API events over time based on counts by one or more active analyzers of API event requests being submitted to the SaaS vendor. The allocation can be performed by assigning the power user to an auxiliary API event queue managed by a proxy, which slows the power user's rate of submissions to the SaaS vendor. The auxiliary API event queue allocation can be released when the power user's updated rate or volume of API event submissions falls below a recovery limit or when the updated rate or volume of API event submissions by the user group, collectively, no longer exceeds a SaaS-imposed trigger. Alternatively, the auxiliary API event queue allocation can be released when the auxiliary API event queue is empty or remains below a queue depth limit for a predetermined time. In another case, the allocation may be by the proxy assigning a power user to an overflow API event channel that separates the processing of submissions for that power user 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 user falls below a restoration limit. In other cases, when the updated rate or volume of API event submissions by the user group, collectively, no longer exceeds a SaaS-imposed trigger, or Overflow API Event Channel The overflow API event channel can be configured to be deallocated when it becomes empty or when it stays below the queue depth limit for a predetermined period of time. In some cases, the SaaS can separately meter the usage of the overflow API event channel.

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

[0047] Workflow 9 illustrates an exemplary method for avoiding a throughput penalty imposed by a SaaS vendor on a user group due to excessive API events from users within the user group. Flowchart 900 may be implemented, at least in part, using a computer or other data processing system, e.g., by one or more processors configured to receive or retrieve information, process the information, store the results, and transmit the results. Other implementations may perform actions in a different order than illustrated in FIG. 9 and / or with different, fewer, or additional actions. In some implementations, multiple actions may be combined. For convenience, this 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 collectively monitoring the rate or volume of API events over time for requests from a user group 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 for 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 the sending 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 on a user group by a SaaS vendor due to excessive API events from users within 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 touchscreen integrated into a display, audio input devices such as a voice recognition system and a microphone, and 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 producing a visible image. The display subsystem may also provide a non-visual display 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 the 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 schematically 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 to illustrate 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 for 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 for requests from individual users in the user group to the SaaS vendor. The method includes recognizing power users who submit API events beyond a limit and taking action to reduce the power users' 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 for a throughput penalty for the user group. The disclosed method further includes allocating the 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 brevity, combinations of features disclosed in this application are not individually listed or 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 using 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 predetermined 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 can include assigning a 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 can be released when the 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 can be released when the updated rate or volume of API event submissions by a group of users, collectively, no longer exceeds a SaaS-imposed trigger. An allocation to an auxiliary API event queue can be released when the auxiliary API event queue is empty or remains below a queue depth limit for a predetermined time. The SaaS, in some implementations, can separately meter usage of the overflow API event channel.

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

[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, cause 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 can 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, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.

[0071] The preceding 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. A method for preventing a throughput penalty imposed on a group of users by a Software as a Service (SaaS) vendor due to excessive application programming interface (API) events from said group by executing computer program instructions on a processor, comprising: Monitoring the rate or volume over time of API events in response to requests from users of a user group, both as individuals and as registered members of said user group to a SaaS vendor; Based on the monitoring, identifying a power user who is registered as a regular member of the user group and who submits API events beyond a limit; throttling, for the user group, a rate or volume in time of API event submissions by the registered power users based on a configurable policy managed by a proxy, the policy being specific to the SaaS vendor and setting the limits for individual users within the user group, whereby the throttling of API event submissions reduces the impact of the registered 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 entire user group exceeds or approaches a trigger imposed by a SaaS vendor for imposing the throughput penalty on the entire user group, thereby reducing the imposition of the throughput penalty by the SaaS vendor to the user group.

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 to the user group generated by the SaaS vendor.

3. 10. The method of claim 1, further comprising monitoring a rate or quantity over time of the API events based on counting 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 API consumption 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 policy is 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 suspending 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 time or until submissions by the entire user group no longer exceed a trigger imposed by the SaaS.

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 separates 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. 9. 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 user 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 entire user group no longer exceeds a trigger imposed by the SaaS.

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 independently meters usage of the overflow API event channel.

13. A tangible, non-transitory computer-readable storage medium comprising program instructions loaded onto a memory that, when executed on a hardware processor, cause 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 volume over time of API events to requests from users of a user group as registered members of said user group for individuals and SaaS vendors; Based on the monitoring, identifying a power user who is registered as a regular member of the user group and who submits API events beyond a limit; throttling, for the user group, a rate or volume in time of API event submissions by the registered power users based on a configurable policy managed by a proxy, the policy being specific to the SaaS vendor and setting the limits for individual users within the user group, whereby the throttling of API event submissions reduces the impact of the registered 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 entire user group exceeds or approaches a trigger for the SaaS vendor to impose the throughput penalty on the entire user group, thereby avoiding the SaaS vendor from triggering the throughput penalty on the user group.

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 sending a notification to a human user to follow up on the shutdown or temporary suspension.

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

17. 14. The tangible, non-transitory computer-readable storage medium of claim 13, wherein the steps further comprise 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 hardware processor, a memory coupled to the processor, and computer instructions loaded into the memory, the computer instructions, when executed, monitoring a rate or volume over time of API events to requests from users of a user group as registered members of said user group for individuals and SaaS vendors; Based on the monitoring, identifying a power user who is registered as a regular member of the user group and who submits API events beyond a limit; throttling, for the user group, the rate or volume in time of API event submissions by the registered power users based on a configurable policy managed by a proxy, the policy being specific to the SaaS vendor and setting the limits for individual users, whereby the throttling of API event submissions reduces the impact of the registered 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 entire user group exceeds or approaches a trigger for the SaaS vendor to impose the throughput penalty on the entire user group, thereby preventing the throughput penalty on the user group by the SaaS vendor from triggering.

19. 20. The system of claim 18, wherein the step further comprises 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, which separates 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 a throughput penalty imposed on a group by a Software as a Service (SaaS) vendor due to excessive application programming interface (API) events from the group, comprising: a hardware processor; one or more active analyzers coupled to memory having executable instructions loaded thereon and configured to monitor a rate or quantity over time of API events for requests submitted to the SaaS vendor from users of a user group, both individually 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 registered as a regular member of the user group who submits API events excessively; a scheduler configured to receive API event submissions from the user group and to collectively schedule the API event submissions of the user group for processing by workers; The scheduler is coupled to the power user identifier to receive identification information of the registered power users, and is configured to throttle the rate or amount in time of API event submissions by the registered power users based on a configurable policy managed by a proxy, the policy being specific to the SaaS vendor and setting the limits for individual users, whereby throttling of API event submissions reduces the impact of the registered 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 from the user group as a whole 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 user 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 counting 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 users' API event submissions by assigning them to the auxiliary queue managed by a proxy that throttles the rate and amount in time of API event submissions by the power users.

24. 21. The network security system of claim 20, wherein the scheduler is further configured to allocate the transmission 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