US20090178111A1 - System and method for maintaining security in a distributed computer network - Google Patents

Abstract

A system for maintaining security in a distributed computing environment comprises a policy manager located on a server to maintain policy data files and distribute local security policies to a plurality of clients, and a plurality of application guards, wherein each application guard is located at one of the plurality of clients to manage access by individual transactions to at least one application associated with the application guard, wherein the application guard controls access to the application based on a local security policy received from the policy manager.

Description

CLAIM OF PRIORITY
• This application is a continuation of U.S. patent application Ser. No. 09/721,557, filed Nov. 22, 2000, entitled SYSTEM AND METHOD FOR MAINTAINING SECURITY IN A DISTRIBUTED COMPUTER NETWORK, which is a continuation of U.S. patent application Ser. No. 09/248,788, filed Feb. 21, 1999, now U.S. Pat. No. 6,158,010, issued Dec. 5, 2000, entitled SYSTEM AND METHOD FOR MAINTAINING SECURITY IN A DISTRIBUTED COMPUTER NETWORK which claims the benefit of priority to U.S. Provisional Patent Application No. 60/105,963, filed Oct. 28, 1998, entitled SYSTEM AND METHOD FOR MAINTAINING SECURITY IN A DISTRIBUTED COMPUTER NETWORK, each of which applications are herein incorporated by reference.
COPYRIGHT NOTICE
• A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• This invention relates generally to computer security systems, and relates more particularly to a system and method for managing and enforcing complex security requirements in a distributed computer network.
• 2. Description of the Background Art
• Computer security issues have become more complex with the continual evolution of contemporary computer systems. As corporations utilize increasingly distributed and open computing environments, the security requirements of an enterprise typically grow accordingly. The complexity of employee, customer and partner access to critical information assets, while assuring proper security, has proven to be a major hurdle. For example, many organizations deploy applications that allow their external business partners, as well as their own internal employees, to access sensitive information resources within the enterprise. In the absence of adequate security measures, an enterprise may thus be subject to the risk of decreased security and confidentiality.
• While most organizations focus their security concerns on protecting the internal network from the outside world, it is estimated that 80-90% of all corporate security breaches come from within an organization (source: Aberdeen Group, September 1997). This further underscores the need to specify and enforce an access control security policy within the enterprise network.
• In today's complex business environment, specifying, stating, implementing and managing an enterprise access control policy may be both difficult and inefficient. When corporate data and applications revolved around a mainframe model, the problem of defining and managing access to corporate applications was relatively straightforward. Today, the complexity of business methods, as well as the complexity of distributed application architectures, may force companies to resort to manual, ineffective or highly custom approaches to access control in their attempts to implement the business process.
• To secure a complex and distributed computer system, the system may typically employ a combination of encryption, authentication, and authorization technologies. Encryption is a means of sending information between participants in a manner that prevents other parties from reading the information. Authentication is a process of verifying a party's identity. Authorization is a technique for determining what actions a participant is allowed to perform.
• Encryption and authentication are well-understood and have led to effective network security products, whereas authorization technology is not as well developed, and is often inadequate for many enterprises. The security approach of most companies today is to focus on the authentication of users to ensure that those users are part of the organization or a member of a select group. Authentication can be accomplished with a number of different approaches, from simple password or challenge response mechanisms to smart cards and biometric devices such as a fingerprint reader. Once users are authenticated, however, there is still a significant problem in managing and enforcing their set of privileges, which may be unique and vary widely between users. The same authentication mechanism can be used for every user, but different authorization mechanisms must be developed for most applications. Therefore, reliable and efficient access control is a much more difficult problem facing enterprises today.
• Authentication mechanisms often work together with some sort of access control facility that can protect information resources from unauthorized users. Examples of network security products include firewalls, digital certificates, virtual private networks, and single sign-on systems. Some of these products provide limited support for resource-level authorization. For example, a firewall can screen access requests to an application or a database, but does not provide object-level authorization within an application or database. Single Sign-On (SSO) products, for example, maintain a list of resources an authenticated user can access by managing the login process to many different applications. However, firewalls, SSO and other related products are very limited in their ability to implement a sophisticated security policy characteristic of many of today's enterprises. They are limited to attempting to manage access at a login, or “launch level”, which is an all or nothing approach that inherently cannot implement a business-level policy.
• A real-world security policy within a large enterprise is a detailed and dynamic knowledge base specific to that organization. The authorization privileges are specific to the constantly evolving set of users, applications, partners, and global policies that the enterprise puts in place to protect its key information resources. A security policy within a large enterprise can consist of tens or hundreds of thousands of individual rules that cover which users are authorized to access particular applications, perform various operations, or manage the delegation and transfer of tasks. Many of these policy rules that implement the business practice of the organization have to be hard coded within custom-built applications or stored in the database.
• The key problem is that these policy rules are localized, scattered throughout the organization, and embedded in applications and databases. Such embedding is expensive and error-prone, and mitigates against efficient policy updates. An organization cannot effectively implement and manage the resulting policy. Inconsistencies arise and updates can quickly become unmanageable. Policy queries and analysis from a global perspective are nearly impossible. The resulting policy begins to diverge from the intended business practices of the organization. Compromises are made in the policy implementation at the department level, and auditors can quickly become frustrated.
• The increasing security risks associated with the proliferation of distributed computing, including Intranet and Extranet applications, are prompting many organizations to explore a broad range of security solutions for controlling access to their important information assets. Although organizations have a number of solutions to choose from for authenticating users (determining and verifying who is attempting to gain access to the network or individual applications), there is little choice when it comes to controlling what users can do and when they can do it to the extent necessary to implement the kinds of complex security policies required by modern organizations. Organizations have been forced to choose between custom authorization solutions that are costly, error-prone, and difficult to manage, or third-party solutions that are very limited in their ability to control access to information across applications and databases.
• A real-world security policy within a large organization is a detailed and dynamic knowledge base that determines which users are authorized to access particular applications, perform various operations or manage the delegation and transfer of tasks, as well as when and under what circumstances they are permitted to do so. Authorization privileges depend upon a constantly evolving set of users, applications, partners, and business polices that comprise the enterprise security policy. A typical enterprise environment consists of several thousand users, hundreds of applications, and a myriad of network resources, resulting in a security policy that can consist of tens or hundreds of thousands of interrelated policy rules.
• Typically, organizations attempt to control access to the internals of in-house applications through policy rules that are hard-coded in the application or through stored procedure statements in the database. But as the number of applications and databases grows, this patchwork approach to authorization quickly gets out of hand. First, organizations must incur the costly and time-consuming overhead of developing customized security code for each application. But more importantly, once the code is developed and embedded in an application, the embedded policy rules become impossible to track, difficult to update, and nearly impossible to manage because they are scattered throughout the organization.
• With an estimated 80 percent of all security breaches coming from authorized users (source: Forrester Research), advanced policy features and enforcement mechanisms are needed to control access to sensitive information assets. To implement an enterprise policy, organizations need a centralized policy and a powerful way to specify policy rules to give them adequate access control security. At the same time, they need a distributed authorization infrastructure to provide authorization services to all applications with performance and scalability for modern distributed network environments.
• Therefore, for the foregoing reasons, an improved system and method are needed to protect the distributed networks of enterprises against unauthorized access to their valuable information assets by managing and enforcing the complex security policy requirements of the organization.
SUMMARY OF THE INVENTION
• In accordance with the present invention, a system and method are disclosed to manage and enforce complex security requirements for a computer system in a distributed computer network.
• It is therefore an object of the present invention to provide an access control system that can manage individual transactions by users around well-defined, detailed objects within an application. It is also an object of the present invention to provide a policy manager that enables the creation, modification, querying, and analysis of an enterprise access-control policy, as well as the configuration and monitoring of integrated audit logs, while delivering the performance and scalability required to meet the demands of any enterprise. It is a further object of the present invention to provide a system that combines a centrally managed policy database with distributed authorization (access control) services that enforce the policy for all applications across the organization.
• It is also an object of this invention to provide a system that works in conjunction with any authentication system, including digital certificates and smartcards, and obviates the need for single sign-on systems by letting organizations set detailed, dynamic rules for exactly who can access which applications, databases, and other network objects. It is a still further object of this invention to provide a robust security policy and authorization service that can be implemented in very heterogeneous environments, across all applications and databases within the organization, thereby completely eliminating the need for embedded, custom security code within applications, and making it possible to centrally manage and administer a consistent, robust security policy for all applications, databases, and network resources. Furthermore, organizations would no longer have to rely on authorization mechanisms provided by packaged or web application vendors that do not integrate with in-house or other third-party products.
• In the preferred embodiment, the system comprises a policy manager located on a server for managing and distributing a local client policy based on a global security policy, and an application guard located on a client or server associated with one or more clients for managing access to securable components as specified by the local client policy. The global policy specifies access privileges of the user to securable components. The policy manager may then distribute a local client policy based on the global policy to the client or server. An application guard located on the client or server then manages authorization requests to the securable components as specified by the local client policy. Each authorization request may be recorded in an audit log to keep track of the authorization requests, whether they were granted or denied, and other useful information.
• The system and method of the present invention supports centralized management and distributed authorization. A central policy server stores and manages the policy rules in a centrally administered database. A powerful graphical user interface is used to create, manage, and customize the elements of a policy. Security rules can be specified by both novice and expert users. A dedicated authorization service is associated with one or more applications. The central policy server automatically distributes (over the network) only the relevant portion of the enterprise policy to each remote service. This distributed architecture ensures that authorization requests are not bottlenecked at a central service point and provides unlimited scalability and maximum performance, regardless of the number of applications or policy rules involved.
• A more sophisticated security policy is possible because the application has the ability to evaluate access privileges upon every access to the information, during every transaction, and at every data request.
• Therefore, the present invention more efficiently and effectively manages and protects computer applications, databases, and network resources against unauthorized access in a distributed computer network.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram of one embodiment for one system, in accordance with the present invention;
• FIG. 2 is a block diagram of one embodiment of the non-volatile memory located within the server inFIG. 1, according to the present invention;
• FIG. 3 is a block diagram of one embodiment of the non-volatile memory located within the client inFIG. 1, according to the present invention;
• FIG. 4 is a block diagram of one embodiment of the policy manager located within the non-volatile memory inFIG. 2, in accordance with the present invention;
• FIG. 5 is a block diagram of one embodiment of the application guard located within the non-volatile memory inFIG. 3, according to the present invention;
• FIG. 6 is a block diagram of one embodiment of a policy loader, in accordance with the present invention;
• FIG. 7 is a flowchart of one embodiment of method steps to configure a system, in accordance with the present invention;
• FIG. 8 is a flowchart of one embodiment to manage policy in the management station, according to the present invention;
• FIG. 9 is a flowchart of one embodiment to navigate tree in the management station, according to the present invention;
• FIG. 10 is a flowchart of one embodiment to analyze policy in the management station, in accordance with the present invention;
• FIG. 11 is a flowchart of one embodiment to edit policy in the management station, in accordance with the present invention;
• FIG. 12 is a flowchart of method steps to distribute policy, according to one embodiment of the present invention;
• FIG. 13 is a flowchart of method steps for client access authorization, in accordance with one embodiment of the present invention; and
• FIG. 14 is a flowchart of method steps to evaluate authorization request, according to one embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
• The present invention relates to an improvement in security techniques to protect computer systems against unauthorized access. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
• The present invention includes a system and method for managing and enforcing complex security requirements in a distributed computer network, and comprises a policy manager located on a server for managing and distributing a policy to a client, and an application guard located on the client, the application guard acting to grant or deny access to various components of the client, as specified by the policy.
• Referring now toFIG. 1, a block diagram of one embodiment of a distributedcomputer network system110 is shown, including aserver112 connected via anetwork114 to aclient116, in accordance with the present invention. Oneclient116 is shown, butserver112 is typically connected tomany clients116. In theFIG. 1 embodiment,server112 may preferably include a central processing unit (CPU)118, a read-only memory (ROM)120, a random-access memory (RAM)122, anon-volatile memory124, aninput device126, and adisplay128 all connected via abus130.
• Similarlyclient116 may preferably include a central processing unit (CPU)132, a read-only memory (ROM)134, a random-access memory (RAM)136, anon-volatile memory138, aninput device140, and adisplay142 all connected via abus144.
• Server112 preferably contains a program stored innon-volatile memory124 for managing a policy or a set of rules and then distributing the policy toclient116 vialink114.Client116 preferably contains a program stored innon-volatile memory138 for granting or denying access to various components or resources ofclient116, as specified by the policy distributed fromserver112. For example, various components or resources ofclient116 can include applications, functions or procedures within an application, data structures within an application, and database or file system objects referenced by an application.
• Referring now toFIG. 2, a block diagram of one embodiment fornon-volatile memory124, located withinserver112 ofFIG. 1, is shown. In theFIG. 2 embodiment,non-volatile memory124 includes apolicy manager210 that manages and distributes a policy. A policy is intended to specify the security requirements for applications and database objects. A policy may contain thousands of “security rules” that describe several constraints, including what applications a particular user can access, what objects (operations) within an application a user can access, and how those privileges are constrained by time, geography, or external events. In general, a policy or authorization policy should constrain access to both applications and the operations within them. The policy may be generalized to groups and hierarchies, not just specified for individual users. This would greatly improve manageability and lead to more comprehensible, business-level policies.
• An authorization policy preferably consists of four components, including objects, subjects, privileges, and conditions. Objects may be applications, or the operations within an application. Examples of objects include applications or methods, web pages, database tables or files, and menu items in a graphical user interface. The granularity of objects has a direct impact on the level of security achieved. The less information an object contains, it is less likely that a user has access to information not needed to perform his job function. On the other hand, the granularity of objects should be balanced against the ease of security management. The more information an object contains, the fewer objects that have to be protected, and the smaller the policy is.
• Objects are preferably organized into an object hierarchy. If an object represents an application, then its children objects might represent the methods with the application. Similarly, if an object represents a database, then its children objects might represent the tables and views within the database.
• If a user is granted a certain privilege on a parent object, then he is automatically granted the privilege on all the children objects. Similarly, if a user is denied a certain privilege on a parent object, then he is automatically denied the privilege on all the children objects. In other words, privileges are inherited from parent to children objects. Privilege inheritance through the object hierarchy eases security management because rather than granting the same privilege to every child object, the privilege is granted once to the parent object, and if the privileges of an object change, the policy on all the children objects automatically reflect the changes made to the object.
• Subjects may be users, or roles containing users, who access protected objects. Subjects correspond to users that have access to information in a system. Users can either be internal or external to a system. Users are authorized to access information in order to perform their job functions. Such access may be controlled so that a user gets access only to the information needed to perform his job function.
• An object, such as an application or a database, typically has its own list of users. These are users who can log on to the object and be authenticated by the objects, sometimes through an external authentication server. In a large system, users are preferably maintained separately by one or more directory servers. Users are preferably extracted from objects or directory servers, and are maintained up-to-date by synchronizing with these objects and directory servers.
• Alias users may also be supported. An alias of a user is another user who inherits all the privileges of the user under certain conditions. Alias facilitates authorization management by providing fine granularity of control on the propagation of privileges. For example, an alias of a user can be created to perform his job function while he is absent. The inheritance of privileges takes effect only when the user is absent. An alias implements the business requirements of delegation, where the privileges of a user can be delegated to another user under certain conditions. Conditional inheritance of privileges through an alias reduces the burden of security management, because it restricts privilege propagation to situations when certain conditions are satisfied.
• Users of an object may be defined as being local to that object. In a typical system, the same user is often represented by different login identifications in different objects. This system may support the notion of a “global” user to capture this situation. Every global user is mapped to a set of local users, one per object. Global users facilitate the centralized management of users throughout the system, even if they are identified by different names in different objects.
• A privilege defines the kinds of access that may be allowed on objects. In the preferred embodiment, a privilege is the right to perform a particular action on a specific object. The kinds of privileges that apply to an object depend on the type of the object. Examples of privileges include the right to execute an application, the right to download a web page, the right to query a database table, or the right to view a menu item.
• Privileges are granted to users so they can accomplish tasks required for their job. A privilege should be granted to a user only when it is absolutely required for the user to accomplish a task. Excessive granting of unnecessary privileges may lead to compromised security. A user may receive a privilege in two different ways, privileges can be granted to users explicitly (for example, user SMITH can be granted the privilege to execute the payroll application), or privileges can be granted to a role (a named group of privileges), which is then granted to one or more users (for example, a role named “clerk” can be granted the privilege to execute the payroll application, and user SMITH can be granted the clerk role).
• Roles are named groups of privileges that are granted to users or other roles. Users granted to a role are the members of that role. A role is often used to represent the set of privileges needed to perform a job function.
• The members of a role automatically inherit all the privileges granted or denied to the role. In addition, roles may be organized into a role hierarchy, where parent roles are granted to children roles. If a parent role is granted a privilege, then the children roles are automatically granted the privilege. Similarly, if a role is denied a privilege, then the children roles are automatically denied the privilege.
• Roles of an object may be defined as being local to that object. In a typical system, the same role is often represented by different names in different objects. This system may support the notion of a “global” role to capture this situation. Every global role is mapped to a set of local roles, one per object. Global roles facilitate the centralized management of roles throughout the system, even if they are identified by different names in different objects.
• Role membership may be further constrained by the notion of mutual exclusion. Two roles are mutually exclusive if no single user can be granted to both roles simultaneously. Role mutual exclusion implements a business requirement of separation of duty. For example, a submit.sub.—budget role and an approve.sub.—budget role should be mutually exclusive, because no user should be simultaneously authorized to perform both actions.
• In a typical policy, there are preferably two types of access rules, a grant rule, and a deny rule. A grant rule states that a privilege on an object is granted to a subject under an optional constraint. A deny rule states that a privilege on an object is denied to a subject under an optional constraint. Additionally, a wild card “any” may be used as a privilege, object, or subject, meaning that any legitimate value could be substituted in its place.
• An access request preferably consists of a privilege, an object, and a subject, representing the fact that the subject request authorization of the privilege on the object. An access request matches a grant rule if the privilege, object, and subject math those in the rule, and the constraint in the rule evaluates to “true.” An access request matches a deny rule if the privilege, object, and subject match those in the rule, and the constraint in the rule does not evaluate to “false.”
• An access request is denied if there is a deny rule matching the request, or there are no access rules matching the request. An access request is granted if there are no deny rules matching the request, and there is a grant rule matching the request.
• Conditions define the constraints on when objects and subjects can be accessed. The constraints in an access rule specifies further requirements on when the access rule is applicable. These requirements could be conditioned on properties of the object or the subject.
• Constraints are preferably expressions formed from conditions and Boolean operators NOT, AND, and OR. Three kinds of built-in conditions may be used: 1) relational operations =, < >, <, <=, >, >= on integers; 2) relational operations =, < >, LIKE, NOTLIKE on strings (the operator LIKE takes a string and a pattern and evaluates to true if the string matches the pattern, the operator NOTLIKE is the negation of LIKE); and 3) set operations IN, NOTIN (the operator IN on integers takes an integer and a set of integers and evaluates to “true” if the integer is in the set, the operator IN on strings is similarly defined, and the operator NOTIN is the negation of IN).
• In addition to built-in conditions, users ofsystem110 may declare custom evaluation functions, which are customer-defined conditions.System110 may provide an Application Programming Interface (API) for invoking customer-supplied code to evaluate custom evaluation functions. For example, an evaluation function could access a remote database to validate certain properties of the object. Another evaluation function could invoke an external server to authenticate the subject.
• Now referring to theFIG. 2 embodiment,policy manager210 preferably includes amanagement station program212 to operatepolicy manager210, adistributor program214 to distribute local client policies to clients, alogger program216 to track authorization requests, and a database management system (DBMS)218 to maintain policy data files.Policy manager210 also includes an audit log data file220 to record authorization requests, an optimized policy data file222, an enterprise policy data file224, an administrative policy data file226, and a local administrative policy data file228. The contents and operation ofpolicy manager210 are further discussed below in conjunction withFIGS. 4,8,9,10,11, and12.
• Referring now toFIG. 3, a block diagram of one embodiment fornon-volatile memory138, located withinclient116 ofFIG. 1, is shown. In theFIG. 3 embodiment,non-volatile memory138 preferably includes anapplication guard310 that grants or denies access to various components ofclient116, as specified by a pre-determined policy. For example, various components ofclient116 can include applications, data, and/or objects. In theFIG. 3 embodiment,application guard310 preferably includes at least oneapplication312, anauthorization library program314, anauthorization engine program316, and alocal client policy318. The contents and operation ofapplication guard310 are further discussed below in conjunction withFIGS. 5,13, and14.
• Referring now toFIG. 4, a block diagram of one embodiment forpolicy manager210, located withinnon-volatile memory124 inFIG. 2, is shown. In the preferred embodiment,policy manager210 allows system users to implement, analyze, edit and update a centrally-managed security policy orenterprise policy224. In theFIG. 4 embodiment,policy manager210 preferably includes a management console ormanagement station212, adatabase management system218, an audit facility orlogger216, and adistributor214.
• In theFIG. 4 embodiment,management station212 preferably includes a graphical user interface (GUI)410 for creating or customizing rules by system users.Management station212 supports concurrent rule development by multiple users. Each policy rule preferably includes four basic components: 1) an object that is to be protected; 2) an access right or privilege; 3) a global or local user to which the privilege applies; and 4) conditions under which the privilege is granted or denied, including built-in access criteria such as time of day or location, as well as custom-defined access criteria.
• Graphical user interface (GUI)410 provides a user-friendly set of menu options ormanagement services412 to fully operate the policy manager. Programs controlled by the menu options may includenavigation414,search416,distribution418, edit420,query422, andlog viewer424. The operation of these programs are further discussed below in conjunction withFIGS. 8,9,10,11, and12. As an alternative to the GUI, the management services can be operated from an application through an API that allows programs to perform the same functions as a human operator. In the preferred embodiment, management station also includes anapplication guard426 to allow only authorized administrators to operatemanagement station212. Localadministrative policy228 provides a set of policy rules specifying which users are authorized to accessmanagement station212.
• After the policy rules are created or modified usingmanagement station212, they may then be distributed toappropriate clients116.Management station212 includes acommunication interface434 in order to pass information between various other components insystem110.
• Prior to when the policy rules are distributed, a parser/type checker428 preferably reviews and reconstructs the policy rules to make sure that they are syntactically and semantically correct according to a predefined policy language. The policy rules pass through a database layer (DB layer)430 and an open database connectivity layer (ODBC)432 before being stored asenterprise policy224.DB layer430 formats the policy rules into standard database storage tables, andODBC432 provides a common interface to various vendor-specific databases.
• Enterprise policy224 is then passed todistributor214. Anoptimizer program436 withindistributor214 determines whichapplication guard310 needs to receive which policy rules. A differprogram438 determines what type of changes were made to optimizedpolicy222, and then distributes only the changed policy rules orlocal client policy318 to the appropriate application guards310 through anODBC layer440 and acommunication interface442, which enforce access control to local applications and data.
• Since the application guards310 can be distributed amongvarious clients116, and eachapplication guard310 has its own specificlocal client policy318, the system provides scalability.
• Distributor214 may also be used to optimizeadministrative policy226 into an optimized administrative policy or localadministrative policy228 for use withapplication guard426 inmanagement station212.
• Referring now toFIG. 5, a block diagram of one embodiment ofapplication guard310, located withinnon-volatile memory138 inFIG. 3, is shown.Application guard310 may be distributed onclients116 throughout an enterprise, and is designed to reside along with each of the protected applications having an associatedapplication guard310.
• Application guard310 supports transactional access control by allowing an application to be aware of the authorization service and to make authorization requests at each and every user interaction, data request, or business-level transaction. In addition, the design and integration ofapplication guard310 is fundamental to providing access control to business-level objects within an application since the authorization services have visibility to those named policy objects within the application.
• In theFIG. 5 embodiment,application guard310 is preferably integrated intoapplication312 through a high-level application programming interface (API) orauthorization library314 that allowsapplication312 to request authorization services as needed through anapplication guard interface512. Typically, this can be done very quickly by including authorization requests at key points inapplication312 for control user interaction or database access so that each interaction is protected with a minimum of development.
• In theFIG. 5 embodiment, an authorization request is processed byauthorization engine316. A parser/type checker514 parseslocal client policy318 and stores the parsed local client policy inRAM136. Anevaluator516 then determines whether the authorization request should be granted or denied by evaluating the authorization request with the parsed local client policy inRAM136. Plug-ins522 inauthorization engine316 allow for additional capabilities to process and evaluate authorization requests based on customized code. Each authorization request is then recorded in anaudit log518 and transmitted tologger216 via acommunication interface520.
• Users have the option of implementingapplication guard310 locally toapplication312, as a service running on the same system asapplication312, or as a remote authorization service through a remote procedure call to another server. The advantage of the latter design would be to offload the application server from handling authorization services or allowing a single authorization server to handle a multiple number of applications. A local implementation would provide maximum performance and minimize any network traffic overhead.
• As seen inFIG. 5,application guard310 includes anapplication guard interface512 coupled to anapplication312 for requesting access to securable components.Application guard310 also includes at least oneauthorization engine316 for evaluating requests fromapplication guard interface512 as specified bylocal client policy318.Multiple authorization engines316 can be used for added performance and reliability. Furthermore,application guard interface512 can be located on a client computer, whileauthorization engine316 andlocal client policy318 can be located on a client server.
• The application guard authorization service of the present invention introduces virtually no performance overhead to an existingapplication312. The policy rules developed atpolicy manager210 are compiled into an optimized form before being distributed to the target application guards310. This optimized form only distributes attributes relevant to thatapplication guard310, so that access requests may be evaluated by reviewing only a few rules rather than frequently analyzing the potentially large policy rule base.
• Referring back toFIG. 4,logger216 may then advantageously receive a client audit log450 through acommunication interface452 and anODBC454 from authorization engine316 (FIG. 5).Client audit log450 is then formatted by message processing456 before being stored inaudit log220.Audit log220 may then be monitored vialog viewer424 inmanagement station212.
• Referring now toFIG. 6, a block diagram of one embodiment of apolicy loader610 is shown. In theFIG. 6 embodiment, policy rules may be entered one at a time intoenterprise policy database224 via management station212 (FIG. 4), or the policy rules may alternatively be loaded as a batch process viapolicy loader610.Policy loader610 is an additional utility that bulk loads an existing set of policy rules intoenterprise policy database224. An existing set of policy rules may be entered intopolicy loader610 viainput612. A parser/type checker614 then preferably reviews and reconstructs the policy rules to make sure that they are syntactically and semantically correct according to a predefined policy language. The policy rules may then be passed through aDB layer616 and an ODBC618 before being stored inenterprise policy database224.
• Referring now toFIG. 7, a flowchart of method steps to configure a system in accordance with one embodiment of the present invention is shown. Initially, instep710, a system administrator installspolicy manager210 on aserver112. The installation may includemanagement station212,distributor214,logger216, andDBMS218. After all the components ofpolicy manager210 have been installed, the system administrator then enters a set of policy rules. Instep712, the administrator can decide whether to usepolicy loader610, or to usemanagement station212 to enter policy rules. If the system administrator decides to usemanagement station212, then atstep714, policy rules are entered usingedit function420. However, ifpolicy loader610 is used, then atstep716, policy rules are entered into a file, and atstep718, the file of policy rules passes topolicy loader610.
• Next, instep720, the system administrator installs application guards310 ontoclient systems116, as well as installinglocal client policies318 ontoclient systems116. Then atstep722, the system administrator registers plug-ins522 intoapplication guards318 to allow for additional capabilities in order to process authorization requests based on customized code.
• Referring now toFIG. 8, a flowchart of one embodiment to manage policy undermanagement services412 inmanagement station212 is shown. In order to allow for a complex set of policy rules, a number of different functionality features are incorporated intosystem110 to facilitate implementation and management.
• In theFIG. 8 embodiment, atstep810, an authorized administrator logs in topolicy manager210. Next, instep812, the authorized administrator chooses between administrative mode or enterprise mode. The administrative mode allows the system administrator to manageadministrative policy226, and the enterprise mode allows the system administrator to manageenterprise policy224. The system administrator is then presented with six menu options including navigatetree814, analyzepolicy816,edit policy818, distributepolicy820,view audit log822, andexit824. The features of navigatetree814, analyzepolicy816,edit policy818, and distributepolicy820 are described in more detail throughFIGS. 9,10,11, and12, respectively.View audit log822 is a security feature that allows an administrator to view and track all authorization requests that have occurred at anyapplication guards310 connected tosystem110. The system administrator can choose any of the menu options, or atstep824 the system administrator may then exit the system.
• Referring now toFIG. 9, a flowchart of one embodiment of menu option navigatetree814 inmanagement station212 is shown. Navigatetree814 provides a set of options for an administrator to add, delete, and/or modify features onserver112 orclient116. The features that an administrator may add, delete, and/or modify include global users910,global roles912,directories914,local roles916, local users918,applications920, application guards922, anddeclarations924. Atstep926, the system administrator may then exit from navigatetree814.
• Referring now toFIG. 10, a flowchart of one embodiment of menu option analyzepolicy816 inmanagement station212 is shown. Analyzepolicy816 preferably allows an authorized user to analyze and view rules and policies withinenterprise policy224. Atstep1010, the user has an option to search rules, or atstep1012 to query policy. When search rules is selected, a search can be made for all the grant rules or all the deny rules pertaining to a particular user. When query policy is selected, a search can be made on who is granted or denied what privilege on which objects under what conditions.
• After analyzing and viewing rules or policies, atstep1014 the system administrator may exit from analyzepolicy816.
• Referring now toFIG. 11, a flowchart of one embodiment of menuoption edit policy818 inmanagement station212 is shown.Edit policy818 allows an authorized user to add, delete, and/or modifyenterprise policy224 features. The features that may be edited include rule sets1110,access1112,privilege1114, objects1116, user/role1118, and attributes1120. Atstep1122, the system administrator may then exitedit policy818.
• Referring now toFIG. 12, a flowchart of one embodiment of method steps of menu option distributepolicy820 is shown. Afterenterprise policy224 has been initially entered or modified in any way, the modified features ofenterprise policy224 may then be distributed to appropriate application guards310. Atstep1210, upon selecting the distribute policy option,distributor214 optimizesenterprise policy224. Then atstep1212, differ438 preferably computes any difference between the newly optimized policy and optimizedpolicy222. Atstep1214, the newly optimized policy is then published as optimizedpolicy222 inDBMS218. Next, atstep1216, only the changed portions of optimizedpolicy222 are committed to appropriate application guards310. Atstep1218, application guards310 receive the changed policy, and then atstep1220, application guards310 merge the changed policy intolocal client policy318. Next atstep1222, newlocal client policy318 is activated to work withapplication guard310.
• Referring now toFIG. 13, a flowchart of one embodiment of method steps for client access authorization is shown. TheFIG. 13 example for using astandard application guard310 by a user begins with a user requesting access to a securable component protected by anapplication guard310. Instep1310,application guard310 constructs and issues an authorization request. Atstep1312, the authorization request is evaluated byapplication guard310 according to itslocal client policy318 to determine whether to allow or deny the authorization request. Atstep1314,audit518 then records the authorization request inaudit log450. Next, atstep1316, if there is an error in the authorization request, or if the request is not valid, then atstep1318 the user is denied access. However, if the authorization request is valid, then atstep1320 it is determined whether access should be granted. If the evaluated authorization request does not deny access for the user, then atstep1322 access is allowed. If the evaluated authorization request denies access for the user, then atstep1324 access is denied.
• Referring now toFIG. 14, a flowchart of one embodiment of method steps to evaluate an authorization request from anapplication guard310 is shown. In order to evaluate an authorization request atapplication guard310, instep1420,evaluator516 first searches any deny rules inlocal policy318. Atstep1412, ifevaluator516 finds any deny rules, then atstep1414, an evaluation is performed on any constraints on the deny rules. If, atstep1416, the evaluation finds presently valid constraints on the deny rules, then atstep1418 access is denied. However, if atstep1416, the evaluation finds that the constraints on the deny rules are not presently valid, or if no deny rules are found in foregoingstep1412, then atstep1420, a search of grant rules is performed. If no grant rules are found atstep1422 that would allow access for the user, then atstep1418, access is denied. If instep1422 grant rules are found, then atstep1424 an evaluation is performed on any constraints in the grant rules. If the evaluated constraint is presently valid, then atstep1426, a true value is passed, and atstep1428 access is allowed. However, if the evaluated constraint is not presently valid, then atstep1426, a false value is passed, and atstep1418 access is denied.
• The invention has been explained above with reference to a preferred embodiment. Other embodiments will be apparent to those skilled in the art in light of this disclosure. For example, the present invention may readily be implemented using configurations other than those described in the preferred embodiment above. Additionally, the present invention may effectively be used in conjunction with systems other than the one described above as the preferred embodiment. Therefore, these and other variations upon the preferred embodiments are intended to be covered by the present invention, which is limited only by the appended claims.

Claims (18)

1. A system for maintaining security in a distributed computing environment, comprising:

a policy manager located on a server to maintain policy data files and distribute local security policies to a plurality of clients; and

a plurality of application guards, wherein each application guard is located at one of the plurality of clients to manage access by individual transactions to at least one application associated with the application guard, wherein the application guard controls access to the application based on a local security policy received from the policy manager,

wherein the application guard receives an authorization request including a subject, an object and a privilege and evaluates said request by matching the rules received from the policy manager to said subject, said object and said privilege in order to control access to said application associated with the application guard.

2. The system ofclaim 1 wherein:

the policy manager derives local security policies from a global security policy, the global security policy includes a plurality of rules applicable to all application guards in the system.

3. The system ofclaim 2 wherein:

the policy manager optimizes the global security policy into an optimized form, wherein the optimized form only distributes attributes relevant to a specific application guard.

4. The system ofclaim 1 wherein:

the policy manager computes any differences caused by a modification on the security policy and commit only the changed portion of the security policy to an appropriate application guards.

5. The system ofclaim 1 wherein:

the policy manager supports concurrent rule development by multiple users.

6. The system ofclaim 1 wherein:

the policy manager tracks and record authorization requests.

7. The system ofclaim 1 wherein:

the policy manager is associated with an application guard to allow only authorized administrator to access and operate the policy manager.

8. The system ofclaim 1 wherein:

the policy manager reviews and reconstructs policy rules to make sure the policy rules are syntactically and semantically correct to a predefined policy language.

9. The system ofclaim 1 wherein:

the policy manager determines which application guard needs to receive which policy rules.

10. The system ofclaim 1 wherein:

the application guard is integrated into the application associated with the application guard.

11. The system ofclaim 1 wherein:

the application guard evaluates the authorization request against a stored local security policy.

12. The system ofclaim 1 wherein:

the application guard is associated with plug-ins to allow for additional capabilities to process and evaluate the authorization request based on customized code.

13. The system ofclaim 1 wherein:

the application guard is implemented as a remote authorization service through a remote procedure call to another server.

14. The system ofclaim 1 wherein:

the application guard uses multiple authorization engines to add performance and reliability.

15. The system ofclaim 1, further comprising:

an enterprise policy database that allows a user to enter policy rules one at a time.

16. The system ofclaim 16, further comprising:

a policy loader to bulk load a existing set of policy rules into the enterprise policy database.

17. A system for maintaining security in a distributed computing environment, comprising:

a policy manager located on a server to maintain policy data files and distribute local security policies to a plurality of clients, wherein the policy manager operates to

derive local security policies from a global security policy, the global security policy includes a plurality of rules applicable to one or more of the plurality of clients;

organize the global security policy into an optimized form, wherein the optimized form only distributes attributes relevant to a specific client;

compute any differences caused by a modification on the global security policy and commit only the changed portion of the global security policy to a specific client;

18. A system for maintaining security in a distributed computing environment, comprising:

a plurality of application guards, wherein each application guard is located at one of a plurality of clients to manage access by individual transactions to at least one application associated with the application guard, wherein the application guard controls access to the application based on a local security policy received from a policy manager,

wherein the application guard receives an authorization request including a subject, an object and a privilege and evaluates said request by matching the rules received from the policy manager to said subject, said object and said privilege in order to control access to said application associated with the application guard.

Images