Patent Application
20090300706
Not Applicable.
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, accounting, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic content. Accordingly, the performance of many computing tasks are distributed across a number of different computer systems and/or a number of different computing components.
Nonetheless, although electronic content may be accessible to a number of computer systems, the creator of the electronic content may desire to limit access to the electronic data. In some environments, one or more access mechanisms, such as, for example, password protection, setting file attributes, (e.g., read-only, etc.), firewalls, etc., can be used to limit access to electronic content. These mechanisms provide essentially the same level of electronic content access to anyone who is authorized. However, if a user can access a file, there is typically no limitation on what that can do with the contents of a file. For example, if a user can read a file, the user can copy the file to another location in which others may be able to access the file, the user can print the file and leave a hardcopy somewhere, etc, typically with no limitations.
As a result, in some environments, a creator of electronic content may desire more configurable and/or granular access control to their electronic content. In these other environments, a content creator can use Digital Rights Management (DRM) to control access to their electronic content. DRM generally includes access control technologies used by content creators to limit usage of electronic content (or instances thereof). Thus, various different types of DRM have been developed to protect different types of electronic content, such as, for example, pictures, movies, videos, music, programs, multi-media, games, documents, etc.
One category of DRM, Enterprise Rights Management (ERM) is often used to control access to documents, such as, for example, electronic mail messages, Word processing documents, and Web pages, etc. Rights Management Services (RMS) is an ERM solution. RMS can be used to encrypt documents, and through server-based policies, prevent the documents from being decrypted except by specified people or groups, in certain environments, under certain conditions, and for certain periods of time. Document based operations like printing, copying, editing, forwarding, and deleting can be allowed or disallowed for individual documents. RMS administrators can deploy RMS templates that group these rights together into predefined policies that can be applied en masse to content.
Accordingly, RMS-protected content can be created by RMS-enabled applications. RMS-protected content is encrypted and can contain an embedded Usage Policy, which defines the rights each user or group has to the content. An RMS system works by assigning rights to trusted entities, which are either single users or groups of users. Rights are assigned on a per-entity basis. RMS defines and recognizes several rights by default—such as permission to read, copy, print, save, forward, and edit—and can be extended to recognize additional rights (which each application would have to explicitly implement).
To protect content, a user specifies a usage policy that is to apply to the content. The user then submits the content and usage policy to an RMS-enabled application that applies the usage policy to the content. Although users can (with sufficient technical expertise) create their own usage polices from scratch, users more typically access pre-created usage policy templates that define a usage policy. For example, a user can request a usage policy template from an RMS server. The usage policy is then attached to the document. When a user requests access to the content, the usage policy is evaluated to determine access rights for the user.
Accordingly, the use of RMS (or other DRM mechanisms), has become increasingly popular in the business setting to protect proprietary or confidential information within a business network. For example, a CEO of a large corporation may wish to distribute an e-mail that includes trade-secrets. Because of the confidential nature of this information, however, the CEO may wish to limit the actions recipients may take in regard to this message. For example, the CEO may wish to allow upper-level management to read, copy, print and save the confidential information; however, she may wish to limit other employees to read-only access or to no access at all. Accordingly, through the use of RMS the CEO can specify who is authorized to view the protected message and what actions they may take in regards thereto.
However, within many organizations (e.g., businesses), content usage policies (e.g., included in templates) are distributed and spread out across a number of RMS servers. In this environment, different sub-organizations (e.g., divisions, departments, etc) within an organization typically obtain content usage policies from different RMS servers. This distributed nature of content usage policies results in a number of problems in applying and maintaining content usage policies.
At least one problem is the difficulty in defining the content usage polices. For example, an organization may have organization-wide polices applicable to any content published within the organization. To make organization-wide policies available, the organization-wide policies must be pushed out to any and all RMS servers within the organization. Thus, an administrator is required to individually access each RMS server and update organization-wide polices at the RMS server. Based on the number of RMS servers within an organization, individually accessing and updating RMS servers can place a strain on administrator resources. Further, the frequency of change for organization-wide policy can also increase the strain on administrator resources (independent of the actually number of RMS servers).
Further, different sub-organizations within an organization may have other specific polices configured to alter and/or supplement the organization wide policies. Sub-organization policies can be beneficial since they permit sub-organizations (divisions, departments, etc.) to meet their specific policy requirements without impacting an entire organization. For example, an accounting department may have accounting specific requirements that are not applicable to the rest of an organization. Accordingly, the accounting department can configure accounting policies to meet the accounting specific requirements, without forcing the accounting policies on other portions of the organization.
In some environments, creation and control of sub-organizations is distributed out to the sub-organizations themselves (e.g., different sub-organizations may control their own RMS server). Unfortunately, distributed creation and maintenance of policies can result in the creation of potentially unwanted, unapproved, non-compliant, etc., policies. To verify that sub-organizations use only approved, compliant policies, an administrator may be required to access the a number of RMS servers (e.g, for each sub-organization) and review any organization polices. The administrator can remove any unapproved, non-complaint, etc. usage polices that are identified. Thus, in some environments, an administrator is in part relegated to policing content usage polices. Accordingly, the availability of the administrator to perform other computer and network related duties is reduced.
In some environments an administrator may restrict creation and maintenance of polices to authorized personnel. However, the authorized personnel must still access each RMS server to create and maintain organization policies and any sub-organization specific polices. Thus, in some organizations administration duties can be distributed across sub-organizations. As such, there is always some chance that (e.g., content usage) polices can become inconsistent. For example, if a content usage policy is changed after content has been protected using the content usage policy, users can be afforded or limited to inappropriate access to the document.
The present invention extends to methods, systems, and computer program products for a centrally accessible policy repository. An organization includes a central policy database. The central policy database stores the organization's policies for protecting the organization's resources. The central policy database includes a plurality of centrally accessible policy items. Some of the plurality of centrally accessible policy items contain a protection policy. The protection policy can be applied to a resource to consistently protect the resource when the resource is transferred between and utilized at other computer systems (or used at the same computer system). At least one of the plurality of centrally accessible policy items contains a policy selection policy. The policy selection policy indicates how to identify at least one protection policy that is to be applied to a resource to consistently protect the resource when the resource is transferred between and utilized at other computer systems (or used at the same computer system).
In some embodiments, a computer system accesses an indication that a specified resource of the organization is to be protected. The computer system accesses policy context data for the specified resource. The policy context data indicates the context for protecting the specified resource. The computer system accesses a policy selection policy from the central policy database for the organization. The policy selection policy indicates protection polices within the central policy database that can be applied to a resource based on the policy context data for the resource. Thus, protection polices are consistently applied to resources of the organization when the resources of the organization are utilized.
The computer system identifies one or more appropriate protection policies to apply to the specified resource based on the indications in the policy selection policy and based on the accessed policy context data. The computer system receives a selection of at least one of the one or more appropriate protection polices to apply to the specified resource.
The computer system can then protect the resource in accordance with the specified protection policy to provide consistent protection to the accessed resource across the plurality of computer systems. Alternately, the computer system can send the specified protection policy to another computer system that is to protect the resource. The other computer system can then protect the resource in accordance with the specified protection policy. In either case, a handle to the specific protection policy is attached to the resource such that other receiving computer systems can access the specified protection policy from the central policy repository. Accordingly, other computer systems can also consistently protect the resource in accordance with the specified protection policy during subsequent access to the resource.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
The present invention extends to methods, systems, and computer program products for a centrally accessible policy repository. An organization includes a central policy database. The central policy database stores the organization's policies for protecting the organization's resources. The central policy database includes a plurality of centrally accessible policy items. Some of the plurality of centrally accessible policy items contain a protection policy. The protection policy can be applied to a resource to consistently protect the resource when the resource is transferred between and utilized at other computer systems (or utilized at the same computer system). At least one of the plurality of centrally accessible policy items contains a policy selection policy. The policy selection policy indicates how to identify at least one protection policy that is to be applied to a resource to consistently protect the resource when the resource is transferred between and utilized at other computer systems (or utilized at the same computer system).
In some embodiments, a computer system accesses an indication that a specified resource of the organization is to be protected. The computer system accesses policy context data for the specified resource. The policy context data indicates the context for protecting the specified resource. The computer system accesses a policy selection policy from the central policy database for the organization. The policy selection policy indicates protection polices within the central policy database that can be applied to a resource based on the policy context data for the resource. Thus, protection polices are consistently applied to resources of the organization when the resources of the organization are utilized.
The computer system identifies one or more appropriate protection policies to apply to the specified resource based on the indications in the policy selection policy and based on the accessed policy context data. The computer system receives a selection of at least one of the one or more appropriate protection polices to apply to the specified resource.
The computer system can then protect the resource in accordance with the specified protection policy to provide consistent protection to the accessed resource across the plurality of computer systems. Alternately, the computer system can send the specified protection policy to another computer system that is to protect the resource. The other computer system can then protect the resource in accordance with the specified protection policy. In either case, a handle to the specific protection policy is attached to the resource such that other receiving computer systems can access the specified protection policy from the central policy repository. Accordingly, other computer systems can also consistently protect the resource in accordance with the specified protection policy during subsequent access to the resource.
Embodiments of the present invention may comprise or utilize a special purpose or general-purpose computer including computer hardware, as discussed in greater detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: physical storage media and transmission media.
Physical storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
With this description and following claims, a “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry or desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
Further, it should be understood, that upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to physical storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile physical storage media at a computer system. Thus, it should be understood that physical storage media can be included in computer system components that also (or even primarily) utilize transmission media.
Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Within organization 102, each of the organization units 102A, 102B, 102C, etc., can represent some portion of the resources of organization 102, such as, for example, within a business department, within a business division, a subsidiary, etc. Central policy repository 104 provides a centrally accessible location that stores policies for organization 102. Any computer system (either internal or external to organization 102) that receives instructions to protect content related to organization 102 or that receives instructions to access protected content related to organization 102 can locate relevant policies from central policy repository 104.
As depicted, central repository 104 includes policy database 107. Alternately, database 107 can be located at a physically separate computer system or set of computer systems. Generally, policy database 107 is configured as a centrally accessible location that stores any policies, such as, for example, protection policies and classification policies, for use within organization 102. Policies stored in policy database 107 can be applied to consistently protect resources of organization 102. A resource can be of a variety of different types including an edge resource (e.g., firewalls, ipsec, virtual private networks, etc.), an application or service (e.g., ports and services of composite applications), storage (e.g., file systems, file shares, etc). More particularly, in some embodiments, a resource is a file, an electronic message, multi-media content, a document, a Web page, a directory, or a Web service.
Protection policies can include any of a number of different polices. For example, Digital Rights Management (“DRM”) policies can be stored in policy database 107. Basic file access policies can be stored in policy database 107. Cloud service polices can be stored in policy database 107. Document management polices can be stored in policy database 107.
In some embodiments, policies in policy database 107 are stored and edited in compatible formats used by protection software. For example, it may be that the format of protection policy 109B is compatible with protection software 103. In other embodiments, policies in policy database 107 are stored and edited in other formats. The central policy repository processes the stored format to generate a compatible format to return to a requesting computer system. For example, policy items can include executable code. The executable code can be executed to derive compatibly formatted policies to return to other computer systems.
As depicted, policy database includes policy items 108A, 108B, etc. Each policy item can include a policy handle, a protection policy, policy context data, and optionally one or more friendly names. For example, policy item 108A includes policy handle 129A, protection policy 109A, policy context data 111A, and friendly names 112A. Similarly, policy item 108B includes policy handle 129B, protection policy 109B, policy context data 111B, and friendly names 112B.
A policy handle provides a mechanism for indirectly pointing back to a policy in policy database 107. For example, policy handle 129A points to protection policy 109A. Thus, policy handle 129A can be attached to a resource to cause a computer system to access protection policy 109A as the protection policy for the resource. Accordingly, a policy handle can point a computer system to appropriate protection policy even when the protection policy changes over time. For example, administrator 114 can use administrator tools 113 to modify protection policy 109A. However, since computer systems can use policy handle 129A to access protection policy 109A from policy database 107 (instead of attaching a version of protection policy 109A to a resource) any modifications to protection policy 109A are provided to the computer systems.
Policy context data indicates a context in which it may be appropriate to protect a resource in accordance with a corresponding protection policy. Policy context data can be used to identify the protection policy of a policy item as the protection policy that is to be applied to a resource. For example, under the context indicated in policy context data 111A, protection policy 109A can be identified as the protection policy to apply to a resource. Policy context data can be based on a variety of different data, such as, for example, a resource itself, user and group identities, application type, machine health, roles, document class, etc.
Friendly names can be used to better indicate what a protection policy is to a user. For example, friendly names can include “confidential”, “division source code”, “document retention policy”, etc. When multiple protection policies are appropriate for a resource, a user can refer to the friendly names to determine what protection polices are applicable and select one or more of the protection policies for application to the resource.
Generally, policy identification module 106 is configured to identify an appropriate and/or corresponding protection policy in response to receiving protection policy identification data, such as, for example, policy context data or a policy handle. For example, in some embodiments, policy identification module 106 receives a policy handle from another computer system. In response, policy identification module 106 scans policy items for a matching policy handle. When a match is identified, the corresponding protection policy can be returned.
In other embodiments, policy identification module 106 receives resource context data from another computer system. In response, policy identification module 106 scans policy items for any matching policy context data. When a match is identified, the corresponding protection policy can be returned. Received policy context data can match a plurality of policy items. Thus, in response to receiving policy context data, policy identification module 106 can return a plurality of protection policies (and corresponding friendly names).
Method 200 includes an act of accessing a resource that is to be protected (act 201). For example, protection software 103 can access resource 121. Protection software 103 can be located at a computer system within organizational unit 102B. Method 200 includes an act of formulating content context data corresponding to accessed resources, the content context data indicating the context for protecting accessed resources (act 202). For example, protection software 103 can formulate policy context data 122 corresponding to resource 121. Policy context data 122 indicates the context for protecting resource 121.
Method 200 includes an act of sending the policy context data to a central repository to request a protection policy for protecting the accessed resource (act 203). For example, protection software 103 can send policy context data 122 to central repository 104. Method 200 includes an act of receiving policy context data from the content protection software, the policy context data corresponding to the resources that protection software is to protect (act 204). For example, central policy repository 104 can receive policy context data 122 from protection software 103.
Method 200 includes an act of comparing the received policy context data to policy context data of policy items in the central repository (act 205). For example, policy identification module 106 can compare policy context data 122 to policy context data 111A, policy context data 111B, etc.
Method 200 includes an act of, based on the comparisons, identifying one or more protection policies that are potentially appropriate for protecting the accessed resource (act 206). For example, policy identification module 106 can identify protection policy 109B as potentially appropriate for protecting resource 121. Identifying a protection policy as appropriate can include determining that there is some requisite similarity between received policy context data and policy context data contained in the corresponding policy item. Thus, policy identification module 106 can identify a plurality of protection policies that are potentially appropriate. For example, policy identification module 106 can determine that there is some requisite similarly between policy context data 122 and policy context data 111B. Accordingly, policy identification module 106 can identify protection policy 109B as potentially appropriate for protecting resource 121. Other protection policies can be similarly identified.
Method 200 includes an act of returning the one or more identified protection policies to the protection software (act 207). For example, central repository 104 can return protection policy 109B and policy handle 129 (possibly along with friendly names 112B) to protection software 103. Central policy repository 104 can also return any other identified protection policies (possibly along with their corresponding friendly names) to protection software 103. Method 200 includes an act of receiving one or one more protection polices from the central repository, the one or one more received protection polices identified as potential protection policies for protecting the accessed resource (act 208). For example, protection software 103 can receive protection policy 109B (possible along with friendly names 112B) form central policy repository 104. Protection software 103 can also receive any other identified protection polices (possibly along with their corresponding friendly names) from central policy repository 104.
Method 200 includes an act of selecting a specified protection policy, from among the one or more received protection policies, to protect the accessed content (act 209). For example, protection software 103 can select protection policy 109B to protect resource 121. Alternately, protection software 103 can present a user-interface (e.g., using friendly names) listing any potential protection polices for protecting resource 121. A user can then enter a selection at the user-interface to select protection policy 109B (or some other presented protection policy).
Protection polices are not necessarily mutual exclusive of one another. Thus, in some embodiments protection software 103 or a user can select a plurality of protection policies to apply to resource 121.
Method 200 includes an act of protecting the accessed resource in accordance with the specified protection policy to provide consistent protection to the accessed resource across a plurality of computer systems (act 210). For example, protection software 103 can protect resource 121 in accordance with protection policy 109B (and any other selected protection policies) to provide consistent protection of resource 121 across computer systems of organization 102, as well as external computer systems, such as, for example, computer system 141. The protected version of resource 121 is depicted as protected resource 121P.
Method 200 includes an act of attaching at least a handle to the specific protection policy to the resource such that a receiving computer system can access the specified protection policy from the central repository to consistently protect the resource in accordance with the specified protection policy during subsequent access to the resource (act 211). For example, protection software 103 can attach policy handle 129B to protected resource 121P. Accordingly, a receiving computer system can use policy handle 129B to access protection policy 109B from central policy repository 104. The receiving computer system can then protect resource 121P in accordance with protection policy 109B. Policy handles for any other applied protection policies can also be attached to protected resource 121P.
For example, computer system 141 can subsequently access protected resource 121P. Protection software 143 can submit policy handle 129B (and any other handles) to central policy repository 104. Policy identification module 106 can use policy handle 129B (and any other handles) to identify protection policy 109B (and any other protection policies). Central policy repository 104 can then return protection policy 109B (and any other protection policies) to computer system 141. Protection software 143 can handle protected resource 121P in accordance with protection policy 109B (and any other returned protection policies).
In some embodiments, protection software outside of a central policy repository processes policy context data to identify one or more appropriate protection policies for a resource. For example,
As further depicted, policy database 107 includes policy items 138. Each policy item includes a policy handle, a protection policy, and friendly names. For example, policy item 138A includes policy handle 143A, protection policy 139A, and friendly names 142A. Similarly, policy item 138B includes policy handle 143B, protection policy 139B, and friendly names 142B.
Policy database 107 also includes policy selection policy 161. Each item within policy selection policy 161 maps policy context data to a corresponding policy handle. For example, item 161A maps policy context data 141A to policy handle 143A (the policy handle for protection policy 139A). Similarly, item 161B maps policy context data 141B to policy handle 143B (the policy handle for protection policy 139B). Policy identification module 106 or some other computer system, such as, for example, computer system 172, can use policy selection policy 161 to select one or more potentially appropriate protection policies for use in protecting a resource.
Method 300 includes an act of accessing an indication that a specified resource of the organization is to be protected for use at a computer system (act 301). For example, computer system 172 can access an indication that resource 151 is to be protected. Resource 151 can be a resource of organization 102. The indication can be trigged by an event, for example, triggered through human interaction or automated by software. For example, the indication can be implied from receiving resource 151 or from some express (human or automated) indication that resource 151 is to be protected. Method 300 includes an act of accessing policy context data for the specified resource, the policy context data indicating the context for protecting the specified resource (act 302). For example, protection software 153 can formulate policy context data 152 for resource 151. Policy context data 152 indicates the context for protecting resource 151.
Method 300 includes an act of accessing a policy selection policy from a central policy database for the organization, the policy selection policy indicating protection polices within the central policy database that can be applied to a resource based on the policy context data for the resource so that protection polices are consistently applied to resources of the organization when the resources of the organization are utilized (act 303). For example, computer system 172 can send protection request 162 to central policy repository 104. In response to protection request 162, central policy repository 104 can return policy selection policy 161 to computer system 172. Policy selection policy 161 indicates policy handles for accessing protection policies stored in policy database 107. The protection policies stored in policy database 107 can be applied to resource 151 based on policy context data 152 so that protection polices are consistently applied to resource 151 when resource 151 is utilized.
Method 300 includes an act of identifying one or more appropriate protection policies to apply to the specified resource based on the indications in the policy selection policy and based on the accessed policy context data (act 304). For example, protection software 153 can identify one or more appropriate protection policies to apply to resource 151 based on the indications in policy selection policy 161 and policy context data 152. As depicted, protection software 153 identifies handle 143A (to protection policy 139A).
Protection software 153 can compare policy context data 152 to policy context data 141A, 141B, etc. Identifying a protection policy as appropriate can include determining that there is some requisite similarity between received policy context data and policy context data contained in the corresponding item. Thus, protection software 153 can identify a plurality of protection policies that are potentially appropriate. For example, protection software 153 can determine that there is some requisite similarity between policy context data 152 and policy context data 139A. Accordingly, protection software 153 can identify policy handle 143A (to protection policy 139A) as potentially appropriate for protecting resource 151. Other protection policies can be similarly identified.
Method 300 includes an act of receiving a selection of at least one of the one or more appropriate protection polices to apply to the specified resource (act 305). For example, protection software 153 can send policy handles for any potentially appropriate protection policies to central policy repository 104. As depicted, protection software 153 sends policy handle 143A to central policy repository 104. In response, central policy repository 104 can return corresponding protection policies (and friendly names) to protection software 153. As depicted, central policy repository 104 returns protection policy 139A along with friendly names 142B to protection software 153.
Protection software 153 can present a list of any potentially appropriate protection policies (e.g., by friendly names) at a user-interface of computer system 172. The user-interface can receive user selections of one or more protection policies that are to be used to protect resource 151. Alternately, protection software 153 can automatically select one or more protection policies that are to be used to protect resource 151.
Any selected protection policies can be applied to the resource 151 to protect resource 151. The protected version of resource 151 is depicted as protected resource 151P. Policy handles for protection policies used to protect protected resource 151P can be attached to protected resource 151P. The attachment of policy handles permits other computer systems utilizing protected resource 151P to more easily access appropriate protection policies and utilize protected resource 151P in accordance with the appropriate protection policies.
In some embodiments, policy identification module 106 uses policy selection policy 161 to identify potentially appropriate protection policies for protecting a resource based on received policy context data. Thus, policy selection policy 161 can be utilized at a computer system where protected content is to be processed or at central policy repository 104.
Embodiments of the present invention facilitate central storage of an organization's policies. Thus, an administrator can centrally create, maintain, and manage resource protection polices for all of the organizational units within an organization. Accordingly, resources consumed when performing these protection policy related operations is significantly reduced. Additionally, since protection policies are centrally located, there is increased likelihood of being able to consistently apply an organization's protection policies within different organizational units, even when protection policies change.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
