Patent Description:
<CIT> relates to an end user reviewing search results and following one of the hyperlinks in the search results. In a preferred embodiment, the access request data structure includes the state, search hit, and end user credentials or information. The selected workflow then triggers a request to the document administrator for access to the restricted document. The administrator reviews the request for access, which may include state information and end user credential information, and decides whether or not to grant access to the requested search hit document.

<CIT> discloses systems and/or methods for the implementation and/or enforcement of an email policy for an organization's email system. A Data Loss Prevention (DLP) system may be implemented as part of the email system to affect an e-mail policy enforcement. In one embodiment, the DLP system may comprise modules and/or processing that apply a DLP defined policy. Such DLP policy may define what is considered sensitive information, how should that information be treated during the various stages of the e-mail lifecycle, such as e-mail authoring, email processing, e-mail auditing, and e-mail delivery mechanisms. One such policy directive may be to reject mail messages unless the sender has decided to override the policy. Such override, when evaluated in the delivery context, may result in insisting that the message have a header present indicating a previous action of the sender to override the mail policy before sending the mail. Another policy directive may instruct to educate the users as to the sensitive information detected in the mail. Another policy directive may instruct to reject mail submissions upon the detection of sensitive content. For this policy directive, the delivery system would discard any messages received.

<CIT> discloses an arrangement for safeguarding sensitive information. A user attempt to perform an operation to move data off a computing device is detected as the result of a DLP (data loss prevention) policy violation. Optionally, the data is scanned to ascertain whether the data actually includes sensitive information and/or whether the user is authorized to perform the operation.

It is the object of the present invention to provide data loss prevention in a collaborative service environment.

The object is achieved by the subject matter of the independent claims.

This summary is not intended to exclusively identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.

Embodiments are directed to providing access blocking as part of data loss prevention (DLP) within a collaborative service environment. An action associated with content processed by the collaborative service may be detected and a determination may be made if the action matches access blocking criteria defined by one or more DLP policy rules. In response to the determination that the action matches at least one access blocking criterion defined by the DLP policy rules, a block access tag associated with the content may be activated, previously defined permissions associated with the content may be ignored, and access to the content may be restricted to a number of predefined users.

It is to be understood that both the foregoing general description and the following detailed description are explanatory and do not restrict aspects as claimed.

As briefly described above, data loss prevention (DLP) systems may be implemented in conjunction with collaborative services that may be integrated with or work in coordination with productivity services providing word processing, spreadsheet, presentation, communication, note taking, and comparable functionalities, for example. DLP services may be implemented in data at rest (DAR) or data in transit (DIT) scenarios, and allow administrators to configure DLP policies in the collaborative service to help mitigate their organization's information disclosure risks, along with the detection and remediation of sensitive information. Encryption, content classification, policy management, user notification, incident report generation, and access blocking may be some of the features of a comprehensive DLP system implemented in conjunction with a collaborative service. Provision of access blocking, for example, may include determining if a detected action associated with content processed by the collaborative service matches access blocking criteria defined by one or more DLP policy rules. In response to the determination that the action matches at least one access blocking criterion defined by the one or more DLP policy rules, a block access tag associated with the content may be activated, previously defined permissions associated with the content may be ignored or additional constraints to the permissions may be applied, and access to the content may be restricted to a number of predefined users.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations, specific embodiments, or examples.

While some embodiments will be described in the general context of program modules that execute in conjunction with an application program that runs on an operating system on a personal computer, those skilled in the art will recognize that aspects may also be implemented in combination with other program modules.

Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and comparable computing devices. Embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Some embodiments may be implemented as a computer-implemented process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage medium readable by a computer system and encoding a computer program that comprises instructions for causing a computer or computing system to perform example process(es). The computer-readable storage medium is a computer-readable memory device. The computer-readable storage medium can for example be implemented via one or more of a volatile computer memory, a non-volatile memory, a hard drive, a flash drive, a floppy disk, or a compact disk, and comparable hardware media.

Throughout this specification, the term "platform" may be a combination of software and hardware components for providing access blocking as part of DLP implementation in collaborative service environments. Examples of platforms include, but are not limited to, a hosted service executed over a plurality of servers, an application executed on a single computing device, and comparable systems. The term "server" generally refers to a computing device executing one or more software programs typically in a networked environment. However, a server may also be implemented as a virtual server (software programs) executed on one or more computing devices viewed as a server on the network. More detail on these technologies and example operations is provided below.

<FIG> includes an example network environment where access blocking may be provided server-side as part of DLP within a collaborative service environment.

In one example configuration, as illustrated in diagram <NUM>, one or more servers may provide a collaborative service <NUM> to a plurality of clients or tenants. Each tenant may provide access to a number of applications executed within the infrastructure provided by the collaborative service <NUM> to their users. The applications may include any application such as word processing applications, spreadsheet applications, presentations applications, communication applications, imaging applications, audio / video processing applications, graphic processing applications, and comparable ones.

As illustrated in <FIG>, the collaborative service environment may be a hosted environment. However, the collaborative service environment is not limited to this specific example. Alternatively, the collaborative service environment may include one or more applications or similar environments, through which users may be able to create, edit, review, and/or share content. The collaborative service environment may also be any type of environment where the users can exchange content, among other examples.

On the user side, a user <NUM> may execute a thin (e.g., a web browser) or a thick (e.g., a locally installed client application) application <NUM> within an operating system <NUM> of their computing device <NUM> and access the services provided by the collaborative service <NUM> and its associated applications over one or more networks such as network <NUM>. The computing device <NUM> may include a desktop computer, a laptop computer, a tablet computer, a vehicle mount computer, a smart phone, or a wearable computing device, among other similar devices. User <NUM> may be an example user under a tenant <NUM>. As discussed above, any number of users within the infrastructure of any tenant may access the services of the collaborative service <NUM>. User <NUM> may store content or files associated with the one or more applications provided under the umbrella of the collaborative service <NUM> locally at local storage <NUM> or remotely at data stores managed by the collaborative service <NUM> or by third party services.

The collaborative service <NUM> may include, among other things, a DLP module <NUM> configured to manage and enforce DLP policies. For example, content processed by the collaborative service <NUM> may be evaluated against one or more DLP policy rules created by a tenant administrator in response to the content being opened, saved, deleted, edited, copied, moved, uploaded, downloaded, printed, and/or shared through one of the applications and/or at an expiration of a pre-defined time interval. In some embodiments, an action associated with the content processed by the collaborative service may be detected and a determination may be made if the action matches access blocking criteria defined by the DLP policy rules. The action may include insertion of sensitive information into the content, such as credit card numbers and Social Security numbers, for example. In some embodiments, an entirety of the content may include sensitive information, such as a patent document or a design specification. In other embodiments, a portion of the content may include sensitive data, such as an expenditure report that includes a credit card number.

In response to the determination that the action matches at least one access blocking criterion defined by the DLP policy rules, a block access tag associated with the content may be activated, previously defined permissions associated with the content may be ignored and/or additional constraints to the permissions may be applied, and access to the content may be restricted to a number of predefined users. The predefined users may include an owner (such as the user <NUM>), an administrator, and a last modifier of the content, and the restricted access may include read, edit, and share permissions, for example. The predefined users may also include one or more users that belong to a role defined for managing content with restricted access. In some examples, the predefined users that may have access to restricted content may change as the predefined users' memberships in security groups change. For example, the one or more users may gain or lose status as an administrator, or gain or lose membership in some other role that grants access to restricted content. In other embodiments, access to the content may be restricted to one or more users based on the matched access blocking criteria defined by DLP policy rules. For example, DLP policy rules may define that only internal employees of an organization may view confidential documents. If an internal employee attempts to share a confidential document with other internal employees along with an external employee to the organization, access blocking criteria associated with the confidential document and the attempted share with the external employee may be matched. Accordingly, access to the shared confidential document may be restricted to the other internal employees, while the access to the shared confidential document would be blocked to the external employee.

According to the invention, a notification is provided to the user <NUM> through a user experience of the collaborative service <NUM> to indicate the restricted access to the content. The notification includes a link to a DLP policy document that includes the DLP policy rules, a link to a location of the content, and various control elements associated with one or more actions for the user <NUM> to implement in order to deactivate the block access tag associated with the content, reinstate previously defined permissions associated with the content, and/or revoke the restricted access to the content. The user <NUM> may be enabled to interact with the user experience of the collaborative service <NUM> through one or more of touch input, gesture input, voice command, eye tracking, gyroscopic input, pen input, mouse input, and/or keyboard input. For example, the user <NUM> may be enabled to override the restricted access to the content, report a false positive associated with information corresponding to the at least one access blocking criterion, and/or request a policy check or a reclassification in response to the notification to prompt another evaluation of the content with the DLP policy rules.

Additionally, the user <NUM> may be enabled to remove the information corresponding to the at least one access blocking criterion from the content. For example, the user <NUM> may remove the sensitive information from the content. Furthermore, the user <NUM> may be enabled to remove offending users with access to the content. In one example, if the user <NUM> is sharing restricted content with a multitude of users that include offending users, the user may remove the offending users from a list to share. In another example, if the user <NUM> has saved the restricted content to a location where offending users may have access to the restricted content, the user <NUM> may save the restricted content to a new location such that the offending users no longer have access.

In some embodiments, the match, the restricted access to the content, an override, and a reported false positive may be recorded within a log or report associated with the collaborative service. Furthermore, the block access tag associated with the content may be persisted to an index of the collaborative service such that when external users without access to the content are searching the collaborative service, the access to the content remains restricted. For example, the content may not be displayed in search results for a query issued by one or more of the external users without access to the content. Additionally, an entry may be generated within an audit log to indicate when the content is restricted, when the content is unrestricted, and if the restriction associated with the content is overridden (with additional business justification) or information associated with the at least one access blocking criterion is reported as a false positive by the predefined users, for auditing and reporting purposes. The entry within the audit log may also indicate which DLP policy and corresponding DLP policy rules were violated to invoke the restricted access to the content.

In other embodiments, the content to which access is restricted may include various versions, where the versions may follow a similar pattern to in-place hold. For example, the versions may be temporarily moved to a secure archive location within a site and may be held there for a predefined number of days, where the archive location may only be accessible by the site collection administrator, or another user that belongs to a role defined for the purpose of managing such content. However, the owner, an administrator, such as the site collection administrator, and/or last modifier of the content, among others, may be notified when versions have been archived. Archiving of versions may occur when one or more of the predefined users remove the information corresponding to access blocking criteria from the content and/or remove offending users with access to the content. All other actions, such as a user override of the restricted access to the content and/or report of false positive associated with the information corresponding to access blocking criteria, may not be impacted by versioning since the information corresponding to the at least one access blocking criterion (e.g., sensitive information) remains within the document.

As previously discussed, DLP is a feature set that enables organizations to identify, monitor, and protect sensitive information through deep content analysis, where DLP may be implemented in conjunction with collaborative services. Provision of access blocking as part of DLP may help improve process security by restricting access to content that includes sensitive information, and reduce network bandwidth through creation of automated tasks to detect sensitive content and block access to the content. Additionally, enabling the user <NUM> to interact with the user experience of the collaborative service <NUM> to perform one or more actions associated with the blocked access may improve user efficiency, as well as increase user interaction performance. Furthermore, enabling the user <NUM> to view the links provided with the notification through the user experience of the collaborative service <NUM> may educate the user <NUM> about an organization, such as their place of employment, DLP policies associated with the organization, and how user actions may affect the organization.

<FIG> illustrates another example network environment where access blocking may be provided client-side as part of DLP within a collaborative service environment.

As previously discussed, a tenant may provide access to a number of applications executed within the infrastructure provided by a collaborative service to their users. The applications may include any application such as word processing applications, spreadsheet applications, presentations applications, communication applications, imaging applications, audio / video processing applications, graphic processing applications, and comparable ones.

In an example scenario, as illustrated in diagram <NUM>, a tenant administrator <NUM>, may create one or more DLP policy rules <NUM> through a policy management user interface associated with a compliance console <NUM>. The DLP policy rules <NUM>, for example, may block access to any documents that have been shared externally when the document contains credit card information. A DLP policy may be configured <NUM> from the DLP policy rules <NUM> and stored at a policy store <NUM> for subsequent distribution <NUM> to one or more servers <NUM> associated with the tenant. The server(s) <NUM> associated with the tenant may then further distribute the DLP policy <NUM> to a client <NUM> associated with a user <NUM> under the tenant.

The client <NUM> may include a classification engine <NUM> and a policy engine <NUM> configured to evaluate a document <NUM> against the DLP policy rules <NUM> created by the tenant administrator <NUM> in response to the document <NUM> being opened, saved, deleted, edited, copied, moved, uploaded, downloaded, printed, and/or shared by a user <NUM> through one of the applications and/or upon an expiration of a pre-defined time interval. For example, upon receipt of the DLP policy from the server(s) <NUM> associated with the tenant, the client <NUM> may be configured to transmit the DLP policy rules <NUM> to the policy engine <NUM>. Concurrently, the classification engine <NUM> may be configured to analyze the document <NUM> to detect an action associated with the document <NUM>, such as insertion of sensitive information within the document. The detected action may be transmitted to the policy engine <NUM>, along with contextual data <NUM> associated with the document <NUM>, to determine if the action matches access blocking criteria defined by the DLP policy rules <NUM>. In response to a determination that the action matches <NUM>, a block access tag associated with the document <NUM> may be activated, previously defined permissions associated with the document <NUM> may be ignored or additional constraints to the permissions may be applied, and access to the document <NUM> may be restricted to a number of predefined users. In other embodiments, access to the document <NUM> may be restricted to one or more users based on the matched access blocking criteria defined by DLP policy rules. Furthermore, a user experience comprising a notification may be displayed <NUM> to the user <NUM> through the client <NUM> indicating the restricted access to the document <NUM>. Once the access the document <NUM> has been blocked, only an author/user who uploaded the document <NUM>, a modifier of the document <NUM>, and an administrator, among other predefined users identified, may continue to have access to the document <NUM>.

In some examples, the notification may include a link to a DLP policy document that includes the DLP policy rules <NUM>, a link to a location of the document <NUM>, and various control elements associated with one or more actions for the user <NUM> to implement in order to deactivate the block access tag associated with the document <NUM>, reinstate previously defined permissions associated with the document <NUM>, and revoke the restricted access to the document <NUM>. The user <NUM> may be enabled to interact with the user experience through one or more of touch input, gesture input, voice command, eye tracking, gyroscopic input, pen input, mouse input, and/or keyboard input.

For example, the user <NUM> may work on documents, such as document <NUM>, with credit card information daily. Currently, the user <NUM> may be collaborating on the document <NUM> with one or more members of a team, who also have access to credit card information. The user <NUM> may save the document <NUM> such that it is uploaded to a collaborative service site to share with the team, not realizing external users may also have access to the location. In response to the save, the document <NUM> may be evaluated against the DLP policy rules <NUM> created by the tenant administrator <NUM>. The user <NUM> may receive a notification through a user experience associated with the collaborative service indicating that the upload of the document <NUM> has been blocked because it may contain credit card information that matched an access blocking criterion of the DLP policy rules <NUM>, and furthermore, the location to which the document <NUM> was uploaded is accessible by external users (e.g., offending users of the policy). According to embodiments, the user experience associated with the collaborative service may be synchronous or asynchronous. In one example, the user experience associated with the collaborative service may be synchronous, and thus may display the notification in real-time to the user <NUM> as the upload of the document <NUM> is being blocked. Alternatively, the user experience associated with the collaborative service may be asynchronous, and thus may only be updated periodically or upon demand causing a potential delay in the display of the notification to the user <NUM> indicating that the upload of the document <NUM> has been blocked. For example, to prevent reducing an amount of bandwidth available to the user <NUM>, the user experience may be updated during a quiet period associated with low data transmissions, such as in the middle of the night.

In response, the user <NUM> may be enabled to actuate a link within the notification, which may redirect the user <NUM> to the location of the document <NUM> in the collaborative service. A textual scheme, a graphical scheme, an audio scheme, an animation scheme, a coloring scheme, a highlighting scheme, and a shading scheme may be employed in the collaborative service user experience to indicate the document <NUM> has restricted access. For example, an icon may be displayed adjacent to and/or on the document <NUM> in the collaborative service, to provide a visual indication that the document <NUM> is now blocked. In other examples, the user <NUM> may be enabled to actuate a link within the notification, which may redirect the user <NUM> to a DLP policy document that includes the DLP policy rules <NUM> and one or more actions the user <NUM> may implement to deactivate the block access tag associated with the document <NUM>, reinstate previously defined permissions associated with the document <NUM>, and revoke the restricted access to the document <NUM>. For example, the user <NUM> may remove information corresponding to the at least one access blocking criterion from the document <NUM>, remove offending users with access to the document <NUM>, override the restricted access to the content, report a false positive associated with the information corresponding to the at least one access blocking criterion, and request one of a policy check or a reclassification.

In a first example, the user <NUM> may remove information corresponding to at least one access blocking criterion from the document <NUM>. Accordingly, the user may edit the document <NUM> to remove the credit card numbers by selecting an option to "edit" within the collaborative service user experience. Once the credit card numbers are removed, the document <NUM> no longer violates the DLP policy (e.g., the action no longer matches access blocking criteria defined by the DLP policy rules <NUM>), and on the next policy evaluation the block access tag may be deactivated or removed, previously defined permissions associated with the document <NUM> may be reinstated, and the restricted access to the document <NUM> may be revoked. In some embodiments, the reinstatement of permissions may be based on a current state of permissions. For example, if one or more permissions associated with the document <NUM> changed and/or were updated while the access to the document <NUM> was restricted, upon revocation of the restriction, the changed and/or updated permissions would be effective. The next policy evaluation may occur in response to any of an opening, saving, deleting, editing, copying, moving, publishing, uploading, downloading, printing, and/or sharing of the document <NUM> and/or upon an expiration of a predefined interval. Alternatively, the user <NUM> may request a policy check or a reclassification following the removal of the credit card numbers through the collaborative user experience to prompt the next policy evaluation.

In a second example, the user <NUM> may choose to remove offending users with access to the document <NUM> by removing any guest links to the document <NUM>. The user <NUM> may select to view the properties of the document <NUM> and subsequently disable or remove a link to external users through the collaborative service user experience. Accordingly, external users with a guest link can no longer view or edit the document <NUM>. On the next policy evaluation, the block access tag associated with the document <NUM> may be deactivated or removed, previously defined permissions associated with the document <NUM> may be reinstated, and the restricted access to the document <NUM> may be revoked as the document <NUM> no longer violates the DLP policy (e.g., the action no longer matches access blocking criteria defined by the DLP policy rules <NUM>). As previously discussed in the first example, the user <NUM> may request a policy check or a reclassification following the removal of offending users with access to the document <NUM> through the collaborative user experience to prompt the next policy evaluation.

In a third example, the user <NUM> may choose to override the restricted access to the content. For example, there may be a justification for external vendors to access the document <NUM> because they require the data. The user may select an option to override the restricted access to the document <NUM> through an "override" control element displayed in the collaborative service user experience, and subsequently provide the justification through a user experience implement, such as a pop-up menu or a prompt, displayed through the collaborative service user experience. The user <NUM> may be notified that the override will be audited and the tenant administrator <NUM> will be able to view the justification. In response, the block access tag associated with the document <NUM> may be deactivated, the previously defined permissions associated with the document <NUM> may be reinstated, and the restricted access to the document <NUM> may be revoked. In some examples, an entry may be generated within an audit and/or server log to indicate when access to the document <NUM> is restricted, when restriction of access to the document <NUM> is revoked, and the override of the restriction of access to the content, for auditing and/or reporting purposes. On the next policy evaluation, the policy engine <NUM> may be aware that there is a block access override on the document <NUM> and skip additional policy application. However, if one or more of the DLP policy rules <NUM> are changed, the override and justification would be ignored or discarded, and access to the document <NUM> would be restricted again.

In a fourth example, the user <NUM> may choose to report a false positive associated with the information corresponding to the at least one access blocking criterion. For example, the detected sensitive information in the document <NUM> corresponding to the access blocking criterion may appear to be credit cards numbers due to a structure of the numbers, however, the numbers may simply be a random identification number unattached to any personal information. The user may select an option to report a false positive through a "report" control element displayed through the collaborative service user experience, and the block access tag associated with the document <NUM> may be deactivated or removed, the previously defined permissions associated with the document <NUM> may be reinstated, and the restricted access to the document <NUM> may be revoked. The user <NUM> may be notified that the sensitive information has been reported as a false positive, and will be tracked for auditing and/or reporting purposes. In some examples, an entry may be generated within an audit and/or server log to indicate when access to the document <NUM> is restricted, when the restricted access to the document <NUM> is revoked, and the report of the false positive associated with the sensitive information. On the next policy evaluation, the policy engine <NUM> may be aware that there is a reported false positive on the document <NUM> and skip additional policy application. However, if one or more of the DLP policy rules are changed, the reported false positive would be ignored, and the document <NUM> would be restricted again.

<FIG> illustrates an example access blocking process implemented as part of DLP within a collaborative service environment. A tenant may provide access to a number of applications executed within an infrastructure provided by a collaborative service to one or more users. The applications may include any application such as word processing applications, spreadsheet applications, presentations applications, communication applications, imaging applications, audio / video processing applications, graphic processing applications, and comparable ones. The applications may enable the users to open, create, edit, save, delete, move, upload, download, publish, print, and share content, such as a document <NUM>. Furthermore, a tenant administrator may be enabled to configure DLP policies in the collaborative service to mitigate their organization's information disclosure risks, along with the detection and remediation of sensitive information.

As shown in a diagram <NUM>, the document <NUM> may be saved and uploaded by a user to a location for storage <NUM>. The document <NUM> may then be evaluated <NUM> against a DLP policy created by the tenant administrator, where the DLP policy includes one or more DLP policy rules. For example, in the evaluation, an action associated with the document <NUM> may be detected, and it may be determined if the action matches access blocking criteria defined by the DLP policy rules <NUM>. In response to a determination that the action does not match any access blocking criteria <NUM>, the access blocking process may be terminated. In response to a determination that the action matches at least one of the access blocking criteria <NUM>, a block access tag associated with the document <NUM> may be activated, previously defined permissions associated with the document <NUM> may be ignored or additional constraints to the permissions may be applied, and access to the document <NUM> may be restricted <NUM> to a number of predefined users. The predefined users may include an owner/user who uploaded the document <NUM>, a last modifier of the document <NUM>, and an administrator, for example. The predefined users may also include other users that belong to a role defined for managing restricted content. In other embodiments, access to the content may be restricted to one or more users based on the matched access blocking criteria defined by DLP policy rules.

Furthermore, a notification is provided to the user <NUM> through a collaborative service user experience to indicate the restricted access to the document <NUM>. The notification includes a link to a DLP policy document that includes the DLP policy rules, a link to a location of the document <NUM>, and various control elements associated with one or more actions for user decision <NUM>, which are implemented in order to deactivate the block access tag associated with the document <NUM>, reinstate previously defined permissions associated with the document <NUM>, and/or revoke the restricted access to the document <NUM>. In some embodiments, the reinstatement of permissions may be based on a current state of permissions. For example, if one or more permissions associated with the document <NUM> changed and/or were updated while the access to the document <NUM> was restricted, upon revocation of the restriction, the changed and/or updated permissions would be effective. The actions may include removal of information corresponding to the at least one access blocking criterion, such as sensitive information, <NUM> from the document <NUM>, removal of offending users <NUM> with access to the document <NUM>, and an override of the restricted access to the document <NUM> or a report of a false positive associated with the information corresponding to the at least one access blocking criterion <NUM>. Additionally or alternatively, the user may choose to do nothing to the document <NUM> causing the restricted access to the document <NUM> to persist, delete the document <NUM>, move the document <NUM>, or share the document <NUM>, among other actions.

On the next evaluation <NUM>, it may be determined if the action matches access blocking criteria defined by the DLP policy rules <NUM>. If the action does not match the access blocking criteria <NUM>, the block access tag may be deactivated, previously defined permissions associated with the document <NUM> may be reinstated, and/or the restricted access to the document <NUM> may be revoked. In some examples, to prompt the next evaluation <NUM>, the user may immediately request a policy check or a reclassification following the execution of the user action through the collaborative service user experience.

In some embodiments, the block access tag associated with the document <NUM> may be enabled in the collaborative service, and all previous document permissions may be ignored. Furthermore, the block access tag associated with the content may be persisted to an index of the collaborative service such that when external users without access to the content are searching the collaborative service, the access to the content remains restricted. User reported overrides or false positives may result in all previous document permissions to be applicable again.

<FIG> and <FIG> illustrate example user experiences associated with an access block. As previously discussed, a tenant may provide access to a number of applications executed within the infrastructure provided by a collaborative service to their users, where the application may be a spreadsheet application <NUM>, for example. Furthermore, a tenant administrator may be enabled to configure DLP policies in the collaborative service to mitigate their organization's information disclosure risks, along with the detection and remediation of sensitive information.

As shown in <FIG>, diagram 400A, the spreadsheet application <NUM> may enable a user to enter data into one or more columns and rows through interaction with one or more control elements provided through a toolbar <NUM>, such that the user may organize, analyze, and store data in a tabular form within a spreadsheet document <NUM>. For example, the user may enter data <NUM> associated with health insurance claims into the spreadsheet document <NUM>, where the columns represent a date, a type, and an amount of the claim respectively, and the rows may represent each date and its corresponding type and amount of the claim. The user may also enter personal health information (PHI) of an insurance member associated with the claims, such as a member number, a date of birth, and a Social Security number <NUM>, for example, into the spreadsheet document <NUM>.

In response to an implicit or explicit save of the spreadsheet document <NUM> to a location for storage, the spreadsheet document <NUM> may be evaluated against one or more DLP policy rules created by the tenant administrator. For example, in the evaluation, the insertion of the Social Security number <NUM> within the data <NUM> may be detected, and a determination may be made if the insertion of the Social Security number <NUM> matches access blocking criteria defined by the DLP policy rules. In this scenario, the insertion of the Social Security number <NUM> may be considered insertion of sensitive information, and therefore, a match to at least one access blocking criterion defined by the DLP policy rules may be determined. In response to determining the match, a block access tag associated with the spreadsheet document <NUM> may be activated, previously defined permissions associated with the spreadsheet document <NUM> may be ignored or additional constraints may be applied, and access to the spreadsheet document <NUM> may be restricted to a number of predefined users.

A notification <NUM> may be provided to the user through a user experience of the spreadsheet application <NUM> to indicate the restricted access to the spreadsheet document <NUM>. For example, a policy tip indicating that the spreadsheet document <NUM> appears to contain sensitive information may be provided to the user. The notification may include a "dismiss" control element <NUM> that the user may select if the user wishes to do nothing in regards to the restricted access to the spreadsheet document <NUM>. The notification may also include a link <NUM> that the user may select <NUM> to learn more information about the restricted access or associated DLP policy or DLP policy rules.

In response to the user selection <NUM> of the link <NUM>, another view comprising a policy tips menu <NUM> may be presented to the user through the user experience of the spreadsheet application <NUM>, as shown in <FIG>, diagram 400B, configuration <NUM>. Although not illustrated, the view may include various other menus associated with other capabilities of the spreadsheet application <NUM> in addition to the policy tips menu <NUM>. The policy tips menu <NUM> may include text <NUM> describing the at least one access blocking criterion matched, such as sensitive data, and information within the spreadsheet document <NUM> that corresponds to it, such as the personal health information, and Social Security number. The policy tips menu <NUM> may also include a "policy tips" control element <NUM>, and a link <NUM> that when selected by the user <NUM> may redirect the user to a DLP policy document that includes the DLP policy rules.

The user may also be enabled to hover over and/or select <NUM> the "policy tips" control element <NUM>, as shown in <FIG>, diagram 400B, configuration <NUM>. Upon selection of the "policy tips" control element <NUM>, a drop-down menu <NUM> comprising one or more options for user action may be presented. For example, the user actions may include to dismiss the notification <NUM>, report the sensitive information found as a false positive <NUM>, and manage the notification <NUM> for future instances when sensitive information, such as a Social Security number, is detected.

<FIG> illustrate example user experiences associated with a user override of an access block. A tenant may provide access to a number of applications executed within the infrastructure provided by a collaborative service to their users, where the application may be a presentation application <NUM>, for example. Furthermore, a tenant administrator may be enabled to configure DLP policies in the collaborative service to mitigate their organization's information disclosure risks, along with the detection and remediation of sensitive information.

As shown in <FIG>, diagram 500A, the presentation application <NUM> may enable a user to create, save, edit, and/or share content with one or more other users through interaction with one or more control elements provided through a toolbar <NUM> on a user experience of the presentation application <NUM>. For example, the user may create a document <NUM> comprising multiple slides <NUM>, where each slide is associated with monthly travel expenditures for an annual financial report. Data <NUM> within the document <NUM> may include a date, a type, and an amount of the travel expenditure respectively. The user may also include credit card information associated with the travel expenditures, such as a credit card number <NUM>, a date of expiration, and a security code, for example, within the document <NUM>.

At an expiration of a pre-defined time interval following one or more of the opening, saving, deleting, editing, copying, moving, publishing, uploading, downloading, printing, and/or sharing of the document <NUM>, the document <NUM> may be evaluated against one or more DLP policies created by the tenant administrator. For example, the insertion of the credit card number <NUM> within the data <NUM> may be detected, and a determination may be made if the insertion of the credit card number <NUM> matches access blocking criteria defined by the DLP policy rules. In this scenario, the insertion of the credit card number <NUM> may be considered insertion of sensitive information, and therefore, a match to at least one access blocking criterion defined by the DLP policy rules may be determined. In response to determining the match, a block access tag associated with the document <NUM> may be activated, previously defined permissions associated with the document <NUM> may be ignored, and access to the document <NUM> may be restricted to a number of predefined users. The predefined users may include an owner of the document <NUM> (e.g., the user in this example), a last modifier of the document <NUM>, and/or an administrator, such as the tenant administrator, among others.

A notification <NUM> may be provided to the user through the user experience of the presentation application <NUM> to indicate the restricted access to the document <NUM>. For example, a policy tip indicating that the document <NUM> contains sensitive information may be provided to the user. The notification <NUM> may include an "override" control element <NUM> that the user may select if the user wishes to override the restricted access to the document <NUM>. The notification may also include a link <NUM> that the user may select <NUM> to learn more information about the restricted access.

In response to the user selection <NUM> of the link <NUM>, another view comprising a policy tips menu <NUM> may be presented to the user through the user experience of the presentation application <NUM>, as shown in <FIG>, diagram 500B, configuration <NUM>. Although not illustrated, the view may include multiple other menus associated with other capabilities of the presentation application <NUM> in addition to the policy tips menu <NUM>. The policy tips menu <NUM> may include text <NUM> describing the at least one access blocking criterion matched, such as sensitive data, and what information corresponds to it, such as the credit card number. The policy tips menu <NUM> may also include a "policy tips" control element <NUM>, and a link <NUM> that when selected by the user may redirect the user to a DLP policy document that includes the DLP policy rules. The user may be enabled to hover over and/or select <NUM> the "policy tips" control element <NUM>.

Upon selection of the "policy tips" control element <NUM>, a drop-down menu <NUM> comprising one or more options for user action may be presented, as shown in <FIG>, diagram 500B, configuration <NUM>. For example, the user actions may include overriding <NUM> the restricted access to the document <NUM>, requesting a policy check <NUM> to confirm the sensitive information found, reporting the sensitive information found as a false positive <NUM>, and managing the notification <NUM> for future instances when sensitive information, such as a credit card number, is detected.

In response to user selection <NUM> to override <NUM> the restricted access to the document <NUM>, a dialog <NUM> may be displayed through the user experience of the presentation application <NUM>, as shown in <FIG>, diagram 500C. A similar dialog may be presented to the user, if the user had selected the "override" control element <NUM> within the notification <NUM> described in the previous <FIG>. The dialog <NUM> may include text <NUM> prompting the user to justify why the user wants to override the restriction, and indicating that the justification is subject to review by the tenant administrator, for example. If the user has a justification for overriding, the user may select option <NUM>, enter the justification within a text box provided <NUM>, and select OK <NUM>. The user may then be notified that the override will be audited and reported upon. If the user believes the document <NUM> does not include sensitive information, and thus, would like to report a false positive, the user may select option <NUM> and select OK <NUM>. The user may then be notified that the report will be audited. If the user no longer wishes to override the document <NUM> or report a false positive, the user may select cancel <NUM>.

<FIG> illustrate example user experiences associated with a user reclassification of an access block following removal of content. A tenant may provide access to a number of applications executed within the infrastructure provided by a collaborative service to their users, where the application may be a spreadsheet application <NUM>, for example. Furthermore, a tenant administrator may be enabled to configure DLP policies in the collaborative service to mitigate their organization's information disclosure risks, along with the detection and remediation of sensitive information.

As shown in <FIG>, diagram 600A, the spreadsheet application <NUM> may enable a user to enter data into one or more columns and rows through interaction with one or more control elements provided through a toolbar <NUM>, such that the user may organize, analyze, and store data in a tabular form within a spreadsheet document <NUM>. For example, the user may enter data <NUM> associated with recent employee hires into the spreadsheet document <NUM>, where the columns represent a hire date, an identifier of the hired employee, and a Social Security number <NUM> of the hired employee, and the rows may represent each hire date of the employees and a corresponding identifier and Social Security number of the employee hired on that date.

In response to the user opening the spreadsheet document <NUM> to view and/or edit the document, the spreadsheet document <NUM> may be evaluated against one or more DLP policies created by the tenant administrator. For example, the inclusion of the Social Security numbers <NUM> within the data <NUM> may be detected, and a determination may be made if the inclusion of the Social Security numbers <NUM> matches access blocking criteria defined by the DLP policy rules. In this scenario, the inclusion of the Social Security numbers <NUM> may be considered inclusion of sensitive information, and therefore, a match to at least one access blocking criterion defined by the DLP policy rules may be determined. In response to determining the match, a block access tag associated with the spreadsheet document <NUM> may be activated, previously defined permissions associated with the spreadsheet document <NUM> may be ignored, and access to the spreadsheet document <NUM> may be restricted to a number of predefined users. The predefined users may include an owner of the spreadsheet document <NUM> (e.g., the user in this example), a last modifier of the spreadsheet document <NUM>, and/or an administrator, such as the tenant administrator, among others.

A notification <NUM> may be provided to the user through a user experience of the spreadsheet application <NUM> to indicate the restricted access to the spreadsheet document <NUM>. For example, a policy tip indicating that the spreadsheet document <NUM> contains sensitive information may be provided to the user. The notification may also include a link <NUM> that the user may select to learn more information about the restricted access. After receiving the notification <NUM>, the user may choose to remove the sensitive information from the data <NUM> such that the block access tag associated with the spreadsheet document <NUM> may be deactivated or removed, the previously defined permissions associated with the spreadsheet document <NUM> may be reinstated, and/or the restricted access to the spreadsheet document <NUM> may be revoked. Therefore, the user may select <NUM> the Social Security numbers <NUM> and remove them from the spreadsheet document <NUM>.

Following removal of the Social Security numbers <NUM> from the spreadsheet document <NUM>, the new data <NUM> may represent each hire date and a corresponding identifier of the employee hired on each date, as shown in <FIG>, diagram 600B. The user may now wait until the next policy evaluation on the spreadsheet document <NUM> is performed for the block access tag associated with the spreadsheet document <NUM> to be deactivated or removed, the previously defined permissions associated with the spreadsheet document <NUM> to be reinstated, and/or the restricted access to the spreadsheet document <NUM> to be revoked. The next policy evaluation may be in response to saving the spreadsheet document <NUM>, sharing the spreadsheet document <NUM>, an expiration of a predefined time interval, and/or a variety of other actions altering the content, location or state of the spreadsheet document <NUM>. Alternatively, the user may select <NUM> the link <NUM> to prompt the next policy evaluation.

In response to the user selection <NUM> of the link <NUM>, another view comprising a policy tips menu <NUM> may be presented to the user through the user experience of the spreadsheet application <NUM>, as shown in <FIG>, diagram 600C, configuration <NUM>. Although not illustrated, the view may include multiple other menus associated with other capabilities of the spreadsheet application <NUM> in addition to the policy tips menu <NUM>. The policy tips menu <NUM> may include text <NUM> describing the at least one access blocking criterion matched, such as sensitive data, and what information corresponds to it, such as the Social Security number. The policy tips menu <NUM> may also include a "policy tips" control element <NUM>, and a link <NUM> that when selected by the user may redirect the user to a DLP policy document that includes the DLP policy rules. The user may be enabled to hover over and/or select <NUM> the "policy tips" control element <NUM>.

Upon selection of the "policy tips" control element <NUM>, a drop-down menu <NUM> comprising one or more options for user action may be presented, as shown in configuration <NUM>. For example, the user actions may include to reclassify <NUM> to recheck the document for sensitive information, report the sensitive information found as a false positive <NUM>, and manage the notification <NUM> for future instances when sensitive information, such as a Social Security number, is detected.

In response to user selection <NUM> to reclassify <NUM>, another policy evaluation may be performed to evaluate the spreadsheet document <NUM> against the DLP policies to determine if there are any matches to access blocking criteria defined by the DLP policy rules. Due to the removal of the sensitive information by the user, there may be no matches determined, and upon reclassification, the block access tag associated with the spreadsheet document <NUM> may be deactivated or removed, the previously defined permissions associated with the spreadsheet document <NUM> may be reinstated, and/or the restricted access to the spreadsheet document <NUM> may be revoked.

<FIG> illustrates example user experiences associated with a user sharing content with an access block. A tenant may provide access to a number of applications executed within the infrastructure provided by a collaborative service to their users, where the application may be a word processing application <NUM>, for example. Furthermore, a tenant administrator may be enabled to configure DLP policies in the collaborative service to mitigate their organization's information disclosure risks, along with the detection and remediation of sensitive information.

As shown diagram <NUM>, the word processing application <NUM> may enable a user to invite <NUM> one or more other users <NUM> to view and/or edit a document created within the word processing application <NUM> based on one or more permissions <NUM> set by the user. In response to the user attempting to share <NUM> the document with the other users <NUM> invited to view and/or edit the document, the document may be evaluated against one or more DLP policies created by the tenant administrator. For example, sensitive information within the document may be detected, and a determination may be made if the sensitive information within the document matches access blocking criteria defined by the DLP policy rules. In this scenario, the inclusion of the sensitive information may be a match to at least one access blocking criterion defined by the DLP policy rules. In response to determining the match, a block access tag associated with the document may be activated, previously defined permissions associated with the document may be ignored, and access to the document may be restricted to a number of predefined users. The predefined users may include an owner of the document (e.g., the user in this example), a last modifier of the document, and/or an administrator, among others.

A notification <NUM> may be provided to the user through a user experience of the word processing application <NUM> to indicate the restricted access to the document. For example, a policy tip indicating that the document cannot be shared because it contains sensitive information may be provided to the user. The notification <NUM> may include an "override" control element <NUM> that the user may select if the user wishes to override the restricted access to the document without having to remove the sensitive information from the document. The notification may also include a link <NUM> to learn more information about the restricted access.

The examples in <FIG> have been described using specific network environments, services, applications, and user experiences for provision of access blocking as part of DLP within a collaborative service environment. Embodiments for provision of access blocking as part of DLP within a collaborative service environment are not limited to the specific network environments, services, applications, and user experiences according to these examples.

DLP is a feature set that enables organizations to identify, monitor, and protect sensitive information through deep content analysis, where the DLP may be implemented in conjunction with collaborative services. Provision of access blocking as part of DLP may improve process security by restricting access to content comprising sensitive information to predefined users. Provision of access blocking may also reduce network bandwidth through the creation of automated tasks to evaluate content against one or more DLP policies created by a tenant administrators of the organizations. For example, in response to opening, saving, deleting, editing, copying, moving, publishing, uploading, downloading, printing, and/or sharing of the content, and/or at an expiration of a predefined time interval, the content may be evaluated, sensitive information may be detected within content, and access to the content may be restricted.

Additionally, enabling the predefined users to interact with a user experience of the collaborative service to perform one or more actions associated with the blocked access may advantageously improve user efficiency, as well as increase user interaction performance. Furthermore, enabling the user to actuate and view the links provided with the notification through the user experience of the collaborative service may educate the user about an organization, such as their place of employment, DLP policies associated with the organization, and how user actions may affect the organization.

<FIG> and the associated discussion are intended to provide a brief, general description of a general purpose computing device, which may be used to provide access blocking as part of DLP within a collaborative service environment.

For example, computing device <NUM> may be used as a server, desktop computer, portable computer, smart phone, special purpose computer, or similar device. In an example basic configuration <NUM>, the computing device <NUM> may include one or more processors <NUM> and a system memory <NUM>. A memory bus <NUM> may be used for communicating between the processor <NUM> and the system memory <NUM>. The basic configuration <NUM> is illustrated in <FIG> by those components within the inner dashed line.

Depending on the desired configuration, the processor <NUM> may be of any type, including but not limited to a microprocessor (µP), a microcontroller (µC), a digital signal processor (DSP), or any combination thereof. The processor <NUM> may include one more levels of caching, such as a level cache memory <NUM>, one or more processor cores <NUM>, and registers <NUM>. The example processor cores <NUM> may (each) include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP Core), or any combination thereof. An example memory controller <NUM> may also be used with the processor <NUM>, or in some implementations the memory controller <NUM> may be an internal part of the processor <NUM>.

Depending on the desired configuration, the system memory <NUM> may be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or any combination thereof. The system memory <NUM> may include an operating system <NUM>, a collaborative service <NUM>, and program data <NUM>. The collaborative service <NUM> may include a DLP module <NUM> and a block access module <NUM>, which may be integrated modules of the collaborative service <NUM> or independent modules. The DLP module <NUM> and the block access module <NUM> may perform tasks associated with providing access blocking as part of DLP in a collaborative environment as described herein. The program data <NUM> may include, among other data, process data <NUM> related to restricted content, etc., as described herein.

The computing device <NUM> may have additional features or functionality, and additional interfaces to facilitate communications between the basic configuration <NUM> and any desired devices and interfaces. For example, a bus/interface controller <NUM> may be used to facilitate communications between the basic configuration <NUM> and one or more data storage devices <NUM> via a storage interface bus <NUM>. The data storage devices <NUM> may be one or more removable storage devices <NUM>, one or more non-removable storage devices <NUM>, or a combination thereof. Examples of the removable storage and the non-removable storage devices include magnetic disk devices such as flexible disk drives and hard-disk drives (HDDs), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid state drives (SSD), and tape drives to name a few. Example computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.

The system memory <NUM>, the removable storage devices <NUM> and the non-removable storage devices <NUM> are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs), solid state drives, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which may be used to store the desired information and which may be accessed by the computing device <NUM>.

The computing device <NUM> may also include an interface bus <NUM> for facilitating communication from various interface devices (for example, one or more output devices <NUM>, one or more peripheral interfaces <NUM>, and one or more communication devices <NUM>) to the basic configuration <NUM> via the bus/interface controller <NUM>. Some of the example output devices <NUM> include a graphics processing unit <NUM> and an audio processing unit <NUM>, which may be configured to communicate to various external devices such as a display or speakers via one or more A/V ports <NUM>. One or more example peripheral interfaces <NUM> may include a serial interface controller <NUM> or a parallel interface controller <NUM>, which may be configured to communicate with external devices such as input devices (for example, keyboard, mouse, pen, voice input device, touch input device, etc.) or other peripheral devices (for example, printer, scanner, etc.) via one or more I/O ports <NUM>. An example communication device <NUM> includes a network controller <NUM>, which may be arranged to facilitate communications with one or more other computing devices <NUM> over a network communication link via one or more communication ports <NUM>. The one or more other computing devices <NUM> may include servers, computing devices, and comparable devices.

The network communication link may be one example of a communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. A "modulated data signal" may be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), microwave, infrared (IR) and other wireless media. The term computer readable media as used herein may include both storage media and communication media.

The computing device <NUM> may be implemented as a part of a general purpose or specialized server, mainframe, or similar computer that includes any of the above functions. The computing device <NUM> may also be implemented as a personal computer including both laptop computer and non-laptop computer configurations.

Example embodiments may also include methods to provide access blocking as part of DLP within a collaborative service environment. These methods can be implemented in any number of ways, including the structures described herein. One such way may be by machine operations, of devices of the type described in the present disclosure. Another optional way may be for one or more of the individual operations of the methods to be performed in conjunction with one or more human operators performing some of the operations while other operations may be performed by machines. These human operators need not be collocated with each other, but each can be only with a machine that performs a portion of the program. In other embodiments, the human interaction can be automated such as by pre-selected criteria that may be machine automated.

<FIG> illustrates a logic flow diagram for process <NUM> of a method to provide access blocking as part of DLP within a collaborative service environment, according to embodiments. Process <NUM> may be implemented on a server or other system.

Process <NUM> begins with operation <NUM>, where an action associated with content processed by a collaborative service is detected. The action may include insertion of sensitive information within the content, such as credit card numbers, Social Security numbers, or other forms of sensitive information, for example.

At operation <NUM>, a determination of whether the action matches access blocking criteria defined by one or more DLP policy rules is made. The detection and determination may be made by one of a DLP module associated with the collaboration service in a server-side environment, or by a classification engine and policy engine, respectively, associated with a client in a client-side environment.

At operation <NUM>, in response to determination that the action matches at least one of the access blocking criterion defined by the DLP policy rules, a block access tag associated with the content may be activated, previously defined permissions associated with the content may be ignored or additional constraints to the permissions may be applied, and access to the content may be restricted to a number or predefined users. The predefined users may include an owner, an administrator, and last modifier, and the restricted access to the content may include read, edit, and share permissions. The predefined users may also include one or more users that belong to a role defined for managing content with restricted access, or in other embodiments, access to the content may be restricted to one or more users based on the matched access blocking criteria defined by DLP policy rules. A notification may be provided to one or more of the predefined users to indicate the restricted access to the content, where the notification may include a link to a DLP policy document that includes the one or more DLP policy rules, a link to a location of the content, specific details of the detected sensitive content, and various control elements associated with one or more actions for the predefined user to implement in order to release the content from restriction.

The operations included in process <NUM> are for illustration purposes. Provision of access blocking as part of DLP within a collaborative service environment may be implemented by similar processes with fewer or additional steps, as well as in different order of operations using the principles described herein.

A means for providing access blocking as part of DLP within a collaborative service environment may include a means for detecting an action associated with content processed by the collaborative service, determining if the action matches access blocking criteria defined by one or more DLP policy rules, and in response to a determination that the action matches at least one access blocking criterion defined by the one or more DLP policy rules, activating a block access tag associated with the content, ignore previously defined permissions associated with the content, and restrict access to the content to a number of predefined users.

According to some examples, a computing device to provide access blocking as part of data loss prevention (DLP) within a collaborative service environment may be described. An example computing device may include a memory configured to store instructions, and a processor coupled to the memory. The processor may be configured to perform actions including detect an action associated with content processed by a collaborative service, determine if the action matches access blocking criteria defined by one or more DLP policy rules, and in response to a determination that the action matches at least one access blocking criterion defined by the one or more DLP policy rules, activate a block access tag associated with the content, ignore previously defined permissions associated with the content, and restrict access to the content to a number of predefined users.

In other examples, the predefined users may include an owner, an administrator, and/or a last modifier. The restricted access to the content may include read, edit, and/or share permissions. The detected action may include insertion of sensitive information into the content. The action may be detected as a part of an evaluation of the content in response to an opening of the content, an editing of the content, a sharing of the content, a copying of the content, a moving of the content, a publishing of the content, a saving of the content, a printing of the content, an uploading of the content, a downloading of the content, or an expiration of a predefined time interval.

According to the invention, a notification is provided to the predefined users through a user experience of the collaborative service to indicate the restricted access to the content. The notification includes a link to a DLP policy document that includes the one or more DLP policy rules, a link to a location of the content, and/or various control elements associated with one or more actions for the predefined users to implement in order to deactivate or remove the block access tag associated with the content, reinstate previously defined permissions associated with the content, and revoke the restricted access to the content. The computing device may be associated with a client, and the processor may be configured to execute a classification engine and/or a policy engine to perform the one or more actions.

According to some embodiments, a system to provide access blocking as part of data loss prevention (DLP) within a collaborative service environment may be described. An example system may include a first computing device configured to provide access to one or more applications within the collaborative service, and a second computing device configured to manage the DLP within the collaborative service. The second computing device may be configured to execute an access blocking module configured to detect an action associated with content processed by the collaborative service, determine if the action matches access blocking criteria defined by one or more DLP policy rules, and in response to a determination that the action matches at least one access blocking criterion defined by the one or more DLP policy rules, activate a block access tag associated with the content, ignore previously defined permissions associated with the content, and restrict access to the content to a number of predefined users.

In other embodiments, the second computing device may be further configured to enable the predefined users to remove information corresponding to the at least one access blocking criterion from the content, remove offending users with access to the content, override the restricted access to the content and provide a business justification for the override, report a false positive associated with the information corresponding to the at least one access blocking criterion from the content, and/or request a policy check or a reclassification through a collaborative service user experience. The second computing device may be further configured to deactivate the block access tag associated with the content, reinstate previously defined permissions associated with the content, and revoke the restricted access to the content in response to one or more of detecting the removal of the information corresponding to the at least one access blocking criterion from the content, detecting the removal of the offending users with access to the content, and detecting one of the override and the reported false positive by the predefined users.

According to some examples, a method to provide access blocking as part of DLP within a collaborative service environment may be provided. An example method may include detecting sensitive information within content processed by the collaborative service, determining if the sensitive information matches access blocking criteria defined by one or more DLP policy rules, and in response to a determination that the sensitive information matches at least one access blocking criterion defined by the one or more DLP policy rules, activating a block access tag associated with the content, ignore previously defined permissions associated with the content, and restrict access to the content to a number of predefined users. The example method may also include providing a notification to the predefined users through a collaborative service user experience to indicate the restricted access to the content.

In other examples, the predefined users may be enabled to override the restricted access to the content through the collaborative service user experience. The predefined users may be enabled to report a false positive associated with the sensitive information through the collaborative service user experience. The predefined users may be enabled to share the content through the collaborative service user experience. The method may further include detecting removal of the information, detecting removal of offending users with access to the content, and/or detecting one of an override of the restricted access to the content and a reported false positive associated with the sensitive information by the predefined users; and deactivating the block access tag associated with the content, reinstating the previously defined permissions associated with the content, and/or revoking the restricted access to the content.

In further examples, a textual scheme, a graphical scheme, an audio scheme, an animation scheme, a coloring scheme, a highlighting scheme, and/or a shading scheme may be employed in the collaborative service user experience to indicate the content with restricted access. The block access tag associated with the content may be persisted to an index of the collaborative service.

The match, the restricted access to the content, an override of the restricted access to the content, and/or a reported false positive associated with the sensitive information may be recorded within a log associated with the collaborative service. An entry may be generated within an audit log and/or a server log to indicate when the access to the content is restricted, when the restricted access to the content is revoked, and/or if the restricted access to the content is overridden or the sensitive information is reported as a false positive by the predefined users.

Claim 1:
A computing device to provide access blocking as part of data loss prevention, DLP, within a collaborative service environment (<NUM>), the computing device comprising:
a memory configured to store instructions;
a processor coupled to the memory; wherein the processor is configured to perform actions including:
detect (<NUM>) an action associated with content processed by a collaborative service (<NUM>), wherein the action is detected as a part of an evaluation of the content in response to one of: an opening of the content, an editing of the content, a sharing of the content, a copying of the content, a moving of the content, a publishing of the content, a saving of the content, a printing of the content, an uploading of the content, a downloading of the content, and an expiration of a predefined time interval;
determine (<NUM>; <NUM>; <NUM>) if the action matches access blocking criteria defined by one or more DLP policy rules (<NUM>; <NUM>); and
in response to a determination that the action matches at least one access blocking criterion defined by the one or more DLP policy rules (<NUM>), activate (<NUM>; <NUM>) a block access tag associated with the content, ignore previously defined permissions associated with the content, and restrict access to the content to a number of predefined users,
wherein a notification is provided to the predefined users through a user experience of the collaborative service to indicate the restricted access to the content, the notification comprising a link to a DLP policy document that includes the one or more DLP policy rules, a link to a location of the content, and control elements associated with one or more actions for the predefined users, wherein the one or more actions are implemented in order to deactivate the block access tag associated with the content, reinstate previously defined permissions associated with the content, and revoke the restricted access to the content.