HK1180797B - Managing policies - Google Patents

Description

Managing policies

Technical Field

The invention relates to managing policies.

Background

The person deciding on the policy of a computer system may not be the same person creating the object implementing the computer system. Further, the person who creates, manages, or decides an object may not be the same person who is permitted to configure the computer system to apply the policy enforced by the object. Authorizing a policy decider or policy object creator to configure a computer system to execute a policy may weaken the security of the computer system, increase the direction of performance issues caused by poor configuration options, violate regulations or corporate policies, or have other possible negative consequences.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided merely to illustrate one exemplary technology area in which some embodiments described herein may be practiced.

Disclosure of Invention

Briefly, aspects of the subject matter described herein relate to managing policies. In various aspects, a staging store is used to store policies that are not applied to a computer system unless or until they are copied or otherwise imported to a production store. The configuration entity is allowed read/write access to the staged storage but is not allowed write access to the production storage. The policy manager is authorized to read access to the staging storage and to write access to the production storage. The policy manager may approve or reject a strategy in the project. If the policy manager approves the strategy in the project, the policy manager may derive a production strategy from the strategy in the project and store the production strategy in the production storage. Once the policy is in production storage, the policy may be applied to one or more entities as appropriate.

Drawings

FIG. 1 is a block diagram representing an exemplary general-purpose computing environment in which aspects of the subject matter described herein may be incorporated;

FIG. 2 is a block diagram that generally represents an environment in accordance with aspects of the subject matter described herein; and

3-6 are flow diagrams that generally represent exemplary actions that may occur in accordance with aspects of the subject matter described herein.

Detailed Description

Definition of

As used herein, the term "include" and its variants are intended as open-ended terms, meaning "including, but not limited to. The term "or" is considered "and/or" unless the context clearly indicates otherwise. The term "based on" is considered to be "based, at least in part, on". The terms "one embodiment" and "an embodiment" are used as "at least one embodiment". The term "another embodiment" is taken as "at least one other embodiment".

As used herein, terms such as "a," "an," and "the" include one or more of the indicated items or actions. In particular, in the claims, a reference to an item generally indicates that there is at least one such item, and a reference to an action indicates that at least one instance of the action is performed. The phrase "one or more" as used in the claims or elsewhere herein does not imply a different definition of the above terms, even though it may appear in a claim, sentence, or paragraph that employs one or more of the above terms.

The terms "first," "second," "third," and the like may sometimes be used herein. Without further context, the use of these terms in the claims is not intended to imply an ordering but rather for identification purposes. For example, the phrases "first version" and "second version" do not necessarily mean that the first version is the actual first version or was created before the second version, or even that the first version was requested or operated on before the second version. Rather, these phrases are used to identify different versions.

Headings are for convenience only; information about a given topic may be found outside of the section whose heading indicates that topic.

Other explicit or implicit definitions may be included below.

Exemplary operating Environment

FIG. 1 illustrates an example of a suitable computing system environment 100 on which aspects of the subject matter described herein may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of aspects of the subject matter described herein. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.

Aspects of the subject matter described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, or configurations that may be suitable for use with aspects of the subject matter described herein include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, Personal Digital Assistants (PDAs), gaming devices, printers, appliance devices including set top boxes, media centers, or other appliances, automobile-embedded or attached computing devices, other mobile devices, distributed computing environments that include any of the above systems or devices, and the like.

Aspects of the subject matter described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Aspects of the subject matter described herein 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 computer storage media including memory storage devices.

With reference to FIG. 1, an exemplary system for implementing aspects of the subject matter described herein includes a general purpose computing device in the form of a computer 110. A computer may include any electronic device capable of executing instructions. Components of computer 110 may include a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus, peripheral component interconnect extended (PCI-X) bus, Advanced Graphics Port (AGP), and PCI express (PCIe).

Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes 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. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110.

Communication media typically embodies 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 includes any information delivery media. The term "modulated data signal" means 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 includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as Read Only Memory (ROM) 131 and Random Access Memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CDROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include magnetic tape cassettes, flash memory cards, digital versatile disks, other optical disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 may be connected to the system bus 121 by an interface 140, and magnetic disk drive 151 and optical disk drive 155 may be connected to the system bus 121 by a removable nonvolatile memory interface, such as interface 150.

The drives and their associated computer storage media discussed above and illustrated in FIG. 1, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies.

A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, touch-sensitive screen, tablet, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a Universal Serial Bus (USB).

A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.

The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a Local Area Network (LAN) 171 and a Wide Area Network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 may include a modem 172 or other means for establishing communications over the WAN173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Managing policies

As mentioned above, a policy of a computer system may involve multiple people. It may be undesirable to authorize everyone to configure a computer system to apply policies.

FIG. 2 is a block diagram that generally represents an environment in accordance with aspects of the subject matter described herein. The entities shown in fig. 2 are exemplary and are not meant to be inclusive of all entities that may be required or included. In other embodiments, the entities described in connection with FIG. 2 may be included in other entities (shown or not shown) or placed in sub-entities without departing from the spirit or scope of aspects of the subject matter described herein. In some embodiments, the entities and/or functions described in connection with fig. 2 may be distributed across multiple devices.

The computers 210 and 211 used to access the production storage 213 and the staging storage 212 shown in figure 2, as well as any other computers (if any), may be implemented using one or more computing devices. These devices may include, for example, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, cellular telephones, Personal Digital Assistants (PDAs), gaming devices, printers, appliances including set top boxes, media centers, or other appliances, automotive embedded or attached computing devices, other mobile devices, distributed computing environments that include any of the above systems or devices, and the like.

An exemplary device that may be configured to implement the computer 210 and 211 of FIG. 2 includes the computer 110 of FIG. 1.

Using the user interface of the configuration computer 211, a user 205 (e.g., a configuration administrator or the like) may define objects that implement the policies in the project. Defining an object may include performing various actions that result in the creation of the object. For example, the user 205 may configure settings that are then translated into policy objects. In one example, a project policy object may be created or initially defined by the policy manager 206, and the user 205 may be permitted to modify policies enforced by the policy object in the project. Hereinafter, the term policy is often used to refer to objects or other data that implement the policy, unless the context dictates otherwise.

A policy may include one or more settings to be applied to one or more users, machines, or other entities. The policy may indicate preferences to be used to optionally configure the computer. For example, a policy may include preferences that may be used for configuration when the configuration is missing or incomplete on the computer. A policy may indicate what an entity can do and what it cannot do. For example, the policy may indicate that the user is not allowed to download the executable file. As another example, a policy may indicate restricted access to a particular folder. As another example, the policy may indicate what operating system components the user may execute, what icons will be displayed on the desktop, what programs the user is allowed to execute, and so on. As another example, the policy may indicate configuration data and rules to be used to enforce the secure network connection.

The above examples are not intended to be exhaustive or exhaustive of what the policy may indicate. Indeed, policies may include other types of data to be applied to one or more users or other entities without departing from the spirit or scope of aspects of the subject matter described herein.

In one embodiment, the user 205 may have rights to read and write objects in the staging storage 215. In another embodiment, user 205 may have additional rights to read objects from production store 216. The policy manager 206 may have the above-described rights (or at least read capabilities to the staging storage 215) and additional write capabilities to the production storage 216. With the above rights, in one embodiment, the user 205 may read and change the strategy 212 in the project but may not read or change the production strategy 213. In one embodiment, the user 205 may also be able to read the production policy 213 to obtain the location of the strategy 212 in the project.

In embodiments where the user 205 has the right to read and write objects in the staging store 215 but does not have the right to read or write to the production store 216, the communication line from the production policy 213 to the configuration computer 211 may be ignored. In this embodiment, the configuration computer 211 may obtain the location of the policy 212 in the staging from data stored in the configuration computer 211, the runtime computer 210, or another data store (not shown).

The policy manager 206 may include a computing device (e.g., as one of the computers 210 and 211) that approves or rejects the policies in the project based on a program executing on the computing device, a domain administrator or other person that may approve or reject the policies, a combination of the computing device and the domain administrator or other person, and so forth. The policy manager 206 may also derive production policies from the policies in the staging as will be described in more detail below.

Storage 215 and 216 may comprise any storage medium capable of storing data. Storage 215 and 216 may include volatile memory (e.g., cache), non-volatile memory (e.g., persistent storage), storage media as described in connection with FIG. 1, and so forth. In one embodiment, the storage 215 and 216 may be accessible via the internet (e.g., such as cloud storage).

The term "data" is to be broadly construed to include anything that can be represented by one or more computer storage elements. Logically, data can be represented as a series of 1's and 0's in volatile or non-volatile memory. In a computer having a non-binary storage medium, data may be represented according to the capabilities of the storage medium. Data may be organized into different types of data structures, including simple data types such as numbers, letters, and the like, hierarchical, linked, or other related data types, data structures including multiple other data structures or simple data types, and so forth. Some examples of data include information, program code, program state, program data, other data, and the like.

In one embodiment, production store 216 and staging store 215 may be part of the same store. In this embodiment, production policies may be distinguished from staging policies by their names, locations (e.g., folders, database tables or other database objects, etc.), metadata, or other data about or included in the policies.

The staging store 215 may be used to provide access to the staging policy 212 according to rights associated with the staging store 215. These rights may allow a configuration entity (e.g., the user 205, the configuration computer 211, or other entity) to read policies in the scratch from the scratch store 215 and write policies in the scratch store 215. The policies contained on staging storage 215 are not allowed to be applied until a copy of the policy is stored on production storage 216.

Production store 216 can be used to provide access to production policies 213 according to access rights associated with production policies 213. Production store 216 is associated with a right to not allow the aforementioned configuration entities to write to production store 216.

Policy manager 206 may be used to derive production policies from the staged policies and store the production policies in production storage. Policy manager 206 has at least write access to production storage 216.

As used herein, a database may include a relational database, an object-oriented database, a hierarchical database, a network database, a binary file of a group policy of a folder service, other types of databases, some combination or extension of the above, and the like. The data stored in the database may be organized as tables, records, objects, other data structures, and the like. The data stored in the database may be stored in a dedicated database file, a dedicated hard disk partition, an HTML file, an XML file, a spreadsheet, a flat file, a document file, a configuration file, other files, and the like. A database may reference a set of data that is read-only to the database, or may have the ability to read and write to the set of data.

Data in a database may be accessed via a database management system (DBMS). The DBMS may include one or more programs that control the organization, storage, management, and retrieval of data for the database. The DBMS may receive a request to access data in the database and may perform the operations needed to provide the access. As used herein, access may include reading data, writing data, deleting data, updating data, combinations comprising two or more of the foregoing, and the like.

In describing aspects of the subject matter described herein, terminology associated with relational databases is sometimes used herein for the sake of brevity. Although relational database terminology is sometimes used herein, the techniques herein may also be applied to other types of databases, including those already mentioned previously.

In another embodiment, production store 216 and staging store are two different stores.

The staging policy 212 is not applied on a computer (e.g., a running computer 210) of a domain or other organizational unit. However, the production policy 213 derived from the in-stage policy 212 may be applied to one or more computers of a domain or other organizational unit. In one embodiment, production policy 213 may be created, updated, or deleted only by an administrator or other entity that is permitted to write to production storage 216. In one example, the policy manager 206 has such permission and may create/update the production policy 213 according to the in-stage policy 212. The term "export" and variations thereof are sometimes used herein to indicate that a production strategy is created or updated according to a strategy under staging.

In one example, policy manager 206 may export production policies 213 from the in-stage policies 212 by exporting the in-stage policies 212 into a file and importing the exported file into production store 216. In another example, policy manager 206 may derive production policy 213 from the in-stage policy 212 by copying the in-stage policy 212 into a catalog of production store 216. In another embodiment, the policy manager may derive the production policy 213 from the in-stage policy 212 by updating a database containing the production policy 213.

The above examples are not intended to be exhaustive or exhaustive of the ways in which the production strategies 213 are derived from the in-stage strategies 212. Based on the teachings herein, one of ordinary skill in the art may recognize other methods of deriving production strategies 213 from the in-stage strategies 212 without departing from the spirit or scope of aspects of the subject matter described herein.

Prior to deriving the production policy 213 from the in-stage policy 212, the policy manager 206 may verify the in-stage policy 212 to ensure that it is safe to apply the production policy that will be derived from the in-stage policy 212. This verification may include checking rules for policies 212 in the project, checking rules for other policies, checking other data for policies 212 in the project, and so forth.

The policies contained in production store 216 are applied to computers, users, or other entities of the computing environment as appropriate. For example, the production policy 213 derived from the staging policy 212 may be applied to the running computer 210. Additionally, the production policies stored in production store 216 may be read by configuration computer 211 and used to obtain an indication of where in-stage policies 212 are stored, as shown below.

In one embodiment, the production policies 213 may include an indication of where the in-stage policies 212 are stored. For example, the production policy 213 may include a pointer to the policy 212 in the project. As another example, the production policy 213 may include a path to the staging store 215. Such a path may indicate where the strategy 212 under staging is stored. As another example, the production policy 213 may include the name of the policy 212 in the project. As another example, the production policy 213 may include an identifier of the database object for use in reading and writing policies in the project.

In another embodiment, the configuration computer 211 may store (e.g., in a cache or other memory) a pointer to the policy 212 under staging or retrieve the pointer from the running computer 210. In this embodiment, the configuration computer 211 may obtain the location of the staging policy 212 without reading from the production storage 216.

In the following, the term "pointer" is used to refer to any data that may be used to locate a policy 212 in a project, it being understood that a pointer may include any data that may be used to identify where a policy 212 in a project is stored.

A user seeking to modify the production policy 213 may retrieve the production policy 213. If there is a non-aerial staging policy (e.g., in-staging policy 212) associated with the production policy 213, the configuration computer 211 may display a user interface corresponding to the in-staging policy to allow a user to modify the in-staging policy. Otherwise, the configuration computer 211 may display a user interface corresponding to the copy of the production policy 213, the user may make modifications to the copy of the production policy 213, and when the copy is saved, it is saved as a strategy in staging (e.g., strategy in staging 212) corresponding to the production policy 213.

In another embodiment, the location of the policy 212 in the project may be stored in a database accessible by the configuration computer (e.g., a data store located on the runtime computer 210). In this embodiment, to modify the strategy 212 in the project, the configuration computer 211 may access the database and retrieve the location of the strategy 212 in the project. Using this location, the configuration computer 211 may retrieve the in-stage policy 212 from the staging store 215 and allow the user to modify the in-stage policy 212 via a user interface.

After changing the strategy in the project, the user 205 may notify the strategy manager 206 that the strategy in the project is ready to be applied. In response, the policy manager 206 may verify the in-stage policy and derive a production policy 213 from the in-stage policy 212 as described above.

In one embodiment, the policy manager 206 may create a strategy in a project and indicate to the user 205 where the strategy in the project is stored. The user 205 may then modify the in-stage policies as needed and notify the policy manager 206 when the in-stage policies are ready to be used to create production policies.

In one embodiment, there are multiple objects associated with one policy. For example, the in-stage policies 212 may be implemented as objects that store server configuration data, objects that store client configuration data, objects that store other device configuration data, other objects, and so forth. From each of these objects, a respective object may be derived to enforce the production policy 213. For example, policy manager 206 may validate each of these objects and copy them from staging storage 215 to production storage 216. The program used by the policy manager 206 to copy objects may ensure that: either all objects associated with the strategy in staging are copied from staging storage 215 to production storage 216 or none of the objects associated with the strategy in staging are copied. This may be implemented, for example, to ensure consistency in applying production policies across different domains, single domains, or different entities of other organizational units.

In enforcing a policy, the appropriate objects of the production policy may be used depending on the target on which the policy is to be enforced.

In another embodiment, there is a single object associated with one policy. For example, an extensible language markup (XML) document may encode policies and indicate which rules or other configuration data may be applied to what type of object. The target of the received document may then apply the appropriate rules and/or other configuration data.

3-6 are flow diagrams that generally represent example actions that may occur in accordance with aspects of the subject matter described herein. For simplicity of explanation, the methodologies described in conjunction with fig. 3-6 are depicted and described as a series of acts. It is to be understood and appreciated that aspects of the subject matter described herein are not limited by the acts illustrated and/or by the order of acts. In one embodiment, the actions occur in the order described below. However, in other embodiments, the acts may occur in parallel, in another order, and/or with other acts not presented and described herein. Moreover, not all illustrated acts may be required to implement a methodology in accordance with aspects of the subject matter described herein. In addition, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states via a state diagram or as events.

Turning to fig. 3, at block 305, actions begin. At block 310, an indication is received identifying a staging store for storing policies in a staging. The staging storage is associated with rights that allow the configuration entity to read and write policies in the staging from and to the staging storage. The staging storage may be used to store one or more policies that are not allowed to be applied until the one or more policies are stored on the production storage.

For example, referring to fig. 2, the configuration computer 211 may receive a pointer identifying the name of the policy in the project. This name may then be used to locate a staging store for the strategy in staging.

As another example, receiving an indication of a staging storage may include receiving a path identifying a policy for use in reading and writing the staging. For example, referring to FIG. 2, configuration computer 211 may receive a file path, resource name, or other path that identifies a location for reading and Hill-staging policy 212.

As another example, receiving an indication of a staging store may include receiving an identifier of a database object (e.g., a key of a row of tables, a pointer to a database object, or the like) for reading and writing policies 212 in the staging. In this example, the database may include a staging store. The database may be local to the configuration computer 211 (e.g., on a storage device hosted by the computer), such as a registry or other local database of the configuration computer, or may be remote from the configuration computer 211 (e.g., in a registry or other database of a running computer) but accessible via a network, other communication link, or the like.

As another example, receiving an indication of a staging store may include receiving an indication from a production strategy. For example, referring to fig. 2, the configuration computer 211 may receive an indication of a staging store 215 of staging policies 212 from a production policy 213.

Returning to FIG. 3, at block 315, the strategy under staging is saved to staging storage. For example, referring to fig. 2, the configuration computer 211 may present a user interface that allows the user 205 to create/change policies in a project. After making any desired modifications, the user 205 can instruct the configuration computer 211 to save the policy. In response, the configuration computer 211 may save the in-stage policy 212 to the staging store 215.

At block 320, the strategy in the project is provided to a strategy manager. For example, referring to fig. 2, after the configuration computer has saved the in-stage policy 212 in the staging store 215, the policy manager 206 may receive a notification that the in-stage policy 212 is ready for review. The in-stage policy 212 may be provided to, for example, an administrator via a user interface of the configuration tool that allows the administrator to review the in-stage policy 212 and determine whether to approve or reject the in-stage policy 212.

At block 325, a production strategy may be derived from the strategy in the project. For example, referring to FIG. 2, policy manager 206 may prepare to copy in-stage policy 212 from staging storage 215 to production storage 216 to form production policy 213. As another example, policy manager 206 may export a policy 212 in a project to a file.

At block 330, the production policy may be stored on production storage. For example, referring to FIG. 2, if production manager 206 approves a strategy 212 under staging, strategy manager 206 may cause a copy of strategy 212 under staging to be stored on production storage 216 as production strategy 213. As previously mentioned, production store 216 may be associated with access rights that deny user 205 writing to production store 216.

At block 335, the production strategy is enabled for enforcement. Enabling the production policy may include setting a flag, notifying an enforcement mechanism that the production policy has been changed or created, releasing a lock or other operating system or database resource, completing copying of the policy in the project to production storage, indicating that storage storing the production policy in production storage is complete, and so forth.

At block 340, other actions (if any) may be performed. For example, referring to fig. 2, the policy manager 206 may determine that the in-stage policy 212 is not approved and may send a notification of the rejection to the user 205. In response, the user may alter the in-stage policy 212 to cause the altered in-stage policy 212 of the configuration computer 211 to be stored to the stage store 215.

Turning to fig. 4, at block 405, actions begin. At block 410, the rights are granted to the configuration entity. These rights include rights to allow the configuration entity to read the strategy in the project from the project storage, rights to allow the configuration entity to write the strategy in the project to the project storage. In one embodiment, the rights may also include rights to allow the configuration entity to read the production policy from the production store. These rights do not include rights that allow the configuration entity to write the production policy to the production storage. For example, referring to fig. 2, a system administrator or the like may assign the aforementioned rights to a user 205, a configuration computer 211, or some other entity that is allowed to create a strategy in a project on project storage 215.

At block 415, rights are granted to the policy manager. These rights include rights to allow the policy manager to read a strategy in the staging from the staging storage and rights to allow the policy manager to write a production strategy to the production storage. For example, referring to FIG. 2, a system administrator or the like may assign the aforementioned rights to policy manager 206.

At block 420, the in-stage policies are presented to a policy manager. For example, referring to fig. 2, the in-stage policies 212 may be presented to the policy manager 206 for review.

At block 425, a request for policy is received and responded to as appropriate. Two example request sets and their responses are described in connection with fig. 5 and 6.

At block 430, other actions (if any) may be performed.

FIG. 5 is a flow diagram that generally represents exemplary actions that may be taken in creating or updating a production policy on a production store in accordance with aspects of the subject matter described herein. At block 505, the actions begin.

At block 510, a request to store a production policy on production storage is received from a production manager. For example, referring to FIG. 2, store 216 may receive a request to store production policy 213 on production store 216.

At block 515, in response to receiving the request, the production policy may be stored on production storage after checking the requestor's rights. For example, referring to FIG. 2, in response to receiving a request, and after checking the requestor's rights, production policy 213 may be stored on production store 216.

At block 520, a production strategy may be implemented. For example, referring to fig. 5, the production policy 213 may be implemented on the computer 210 at runtime. Such implementation may include configuring the runtime computer 210 to implement the production policy 213.

At block 525, other actions (if any) may be performed.

FIG. 6 is a flow diagram that generally represents exemplary actions that may be taken in creating or following a policy in a new project in accordance with aspects of the subject matter described herein. At block 605, the actions begin.

At block 610, a request to read a production policy is received from a configuration entity. For example, referring to FIG. 2, configuration computer 211 may request that production policy 213 be stored on production store 216.

In block 615, in response to the request, read access may be provided to the requesting entity. For example, referring to FIG. 2, read access to the production policy may be granted to the configuration computer 211.

In another embodiment, the actions of blocks 610 and 615 may be omitted. In this embodiment, the pointer may be read from a data store (e.g., cache, storage, or other memory or registry or other database) of the configuration computer 211 or database of the runtime computer 210 and cached in the cache of the configuration computer 211 by the configuration computer 211.

At block 620, a request to read a policy in the project is received from a configuration entity. For example, referring to fig. 2, after obtaining the production policies 213, the configuration computer 211 may determine that the corresponding in-stage policy is in-stage policy 212 of the staging store 215. The configuration computer 211 may then request to read the strategy 212 in the project.

At block 625, access to read the policy in the project is provided to the configuration entity in response to the request. For example, referring to fig. 2, the configuration computer 211 is given access to read the policy 212 in the staging of the staging storage 215.

At block 630, a request to write the updated strategy in the staging to the staging store is received. For example, referring to fig. 2, after receiving the strategy 212 in the project, the user 205 may update the strategy 212 in the project using the configuration computer 211 (e.g., via a user or other interface).

At block 635, access rights are provided to the configuration entity to write the updated policies in the staging to the staging store in response to the request. For example, referring to fig. 2, the configuration computer 211 is allowed to write updated in-stage policies 212 to the staging storage 215.

At block 640, other actions (if any) may be performed.

While aspects of the subject matter described herein are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit aspects of the claimed subject matter to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of aspects of the subject matter described herein.

Claims (10)

1. A policy management method implemented at least in part by a computer, the method comprising:

a policy manager to read a policy in a stored staging from a staging store, the staging store being associated with rights that allow a configuration entity to read and write the policy in the staging to the staging store, the staging store being usable to store one or more policies that are not allowed to be applied until the one or more policies are stored on a production store;

the policy manager verifying the in-stage policy to ensure that the application is secure a production policy that will be derived from the in-stage policy;

a policy manager derives the production policy from the planned policy;

a policy manager storing the production policy on the production storage, the production storage associated with access rights that deny the configuration entity writing to the production storage; and

enabling the production policy to be applied to a running computer to configure the running computer to implement the production policy.

2. The method of claim 1, wherein reading the stored policies in the staging store from the staging store comprises: a path is received that identifies a location for reading and writing a staging policy.

3. The method of claim 1, wherein reading the stored policies in the staging store from the staging store comprises: an identifier of a database object for reading and writing a staging policy is received.

4. The method of claim 1, wherein reading the stored policies in the staging store from the staging store comprises: receiving, from a database local to the running computer, an indication that the configuration entity is attempting to configure.

5. The method of claim 1, further comprising providing the in-stage policy to a user having rights to write a policy to the production storage.

6. The method of claim 1, further comprising receiving an indication that a policy in the staging is not approved, loading a policy in the staging from the staging store, receiving an alteration to the policy in the staging, and storing the altered policy in the staging to the staging store.

7. A policy management system comprising:

a staging store operable to provide access to policies in staging, the staging store being associated with rights that allow a configuration entity to read and write policies in staging to the staging store, the staging store operable to provide access to one or more policies that are not allowed to be applied until the one or more policies are stored on a production store;

a production store operable to provide access to a production policy, the production store associated with a right to disallow writing of the configuration entity to the production store; and

a policy manager operable to derive the production policy from the in-stage policy and store the production policy to the production storage, the policy manager having at least write access rights to the production storage, the production policy configured to be applied to a running computer to configure the running computer to implement the production policy.

8. The system of claim 7, wherein the configuration entity comprises a configuration computer operable to provide a user interface through which a user is allowed to define the policy in the staging.

9. The system of claim 8, wherein the configuration computer is further operable to access a database local to the runtime computer to determine the location of the staging store.

10. A policy management method implemented at least in part by a computer, the method comprising:

granting a first set of rights to a configuration entity, the first set of rights including rights to allow the configuration entity to read a strategy in staging from a staging store and rights to allow the configuration entity to write the strategy in staging from a production store to the staging store, the first set of rights not including rights to allow the configuration entity to write a production strategy to the production store, the staging store being usable to store one or more strategies that are not allowed to be applied until the one or more strategies are stored on the production store;

granting a second set of rights to a policy manager, the second set of rights including rights to allow the policy manager to read a policy in the staging from the staging store and rights to allow the policy manager to write the production policy to the production store;

receiving a request from the policy manager to store the production policy on the production storage; and

in response to receiving the request, storing the production policy on the production storage, the production policy stored to be applied to a running computer to configure the running computer to implement the production policy.