BACKGROUND OF THE INVENTION
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.
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 securityrequirements
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 andconfidentiality.
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 andmanaging an enterprise access control policy may be both
difficult andinefficient. 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.
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, andglobal 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 distributedcomputing,
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 haveanumber of solutions to choose
from for authenticating users (determining andverifying 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 anddatabases.
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 adistributed computer netwo
rk.
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 ah 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 acentrally managed policy database with distributed authorization (access
control) services that enforce the policy for all applications across the organization.
Therefore, the present invention more efficiently and effectively
manages andprotects 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;
IG. 2 is a block diagram of one embodiment of the non-volatile memory located
/ithin the server in FIG. 1, according to the present invention;
:IG. 3 is a block diagram of one embodiment of the non-volatile memory located
vithin the client in FIG. 1, according to the present invention;
:IG. 4 is a block diagram of one embodiment of the policy manager located within the
ion-volatile memory in FIG. 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 in FIG. 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, inaccordance
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 computensystems against unauthorized access. The following description is
presented to enable one of ordinary skill in the art to make anduse 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.
Referring now to FIG. 1, a block diagram of one embodiment
of a distributedcomputer network system 110 is shown, including a server 112
connected via anetwork 114 to a client 116, in accordance with the present invention.
One client 116 is shown, but server 112 is typically connected to many clients
116. In the FIG. 1 embodiment, server 112 may preferably include a central processing
unit (CPU) 118, a read-only memory (ROM) 120, a random-access memory (RAM)
122, a non-volatile memory 124, an input device 126, and a display 128 all connected
via a bus 130.
Referring now to FIG. 2, a block diagram of one embodiment for non-volatile memory
124, located within server 112 of FIG. 1, is shown. In the FIG. 2 embodiment, nonvolatile
memory 124 includes a policy manager 210 -that
manages and distributes a policy. A policy is intended to specify
the securityrequirements 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 forindividual users. This
would greatly improve manageability and lead to more comprehensible, business-level
policies.
Now referring to the FIG. 2 embodiment, policy manager 210 preferably
includes a management station program 212 to operate policy manager
210, a distributor program 214 to distribute local client policies to clients, a logger
program 216 to track authorization requests, and a database
management system (DBMS) 218 to maintain policy data files. Policy manager 210 also
includes an audit log data file 220 to record authorization requests, an optimized policy
data file 222, an enterprise policy data file 224, an administrative policy data file
226, and a local administrative policy data file 228. The contents and operation of
policy manager 210 are further discussed below in conjunction with FIGS. 4, 8, 9, 10,
l l , a n d l 2.
Referring now to FIG. 3, a block diagram of one embodiment for non-volatile memory
138, located within client 116 of FIG. 1, is shown. In the FIG. 3 embodiment, nonvolatile
memory 138 preferably includes an application guard 310 that grants or denies
access to various components of client 116, as specified by a pre-determined
policy. For example, various components of client 116 can include applications,
data, and/or objects. In the FIG. 3 embodiment, application guard 310 preferably
includes at least one application 312, an authorization library program 314, an
authorization . engine program 316, and a local client policy 318. The
contents and operation of application guard 310 are further discussed
below inconjunction with FIGS. 5,13, and 14.
Referring now to FIG. 4, a block diagram of one embodiment for policy manager 210,
located within non-volatile memory 124 in FIG. 2, is shown. In the preferred
embodiment, policy manager 210 allows system users to implement, analyze,
edit and update a centrally-managed security policy or enterprise policy 224. In the
FIG. 4 embodiment, policy manager 210 preferably includes a management console or
management station 212, a database management system 218, an audit facility or
logger 216, and a distributor 214.
Referring now to FIG. 5, a block diagram of one embodiment of application guard 310,
located within non-volatile memory 138 in FIG. 3, is shown. Application guard 310 may
be distributed on clients 116 throughout an enterprise, and is designed to reside along
with each of the protected applications having an associated application guard 310.
Application guard 310 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 of application guard 310 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.
Referring back to FIG. 4, logger 216 may then advantageously receive a client audit log
450 through a communication interface 452 and an ODBC 454 from authorization
engine 316 (FIG. 5). Client audit log 450 is then formatted by message processing 456
before being stored in audit log 220. Audit log 220 may then be monitored via log
viewer 424 inmanagement station 212.
Referring now to FIG. 6, a block diagram of one embodiment of a policy loader 610 is
shown. In the FIG. 6 embodiment, policy rules may be entered one at a time into
enterprise policy database 224 via management station 212 (FIG. 4), or the policy rules
may alternatively be loaded as a batch process via policy loader 610. Policy loader 610
is an additional utility that bulk loads an existing set of policy rules into enterprise
policy database 224. An existing set of policy rules may be entered into policy loader
610 via input 612. A parser/type checker 614 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 a DB layer 616 and an ODBC 618 before being stored in enterprise policy
database 224.
Referring now to FIG. 7, a flowchart of method steps to
configure a system in accordance with one embodiment of the present invention is
shown. Initially, in step 710, a system administrator installs policy manager 210
on a server 112. The installation may include management station 212, distributor 214,
logger 216, and DBMS 218. After all the components of policy manager 210 have been
installed, the system administrator then enters a set of policy rules. Instep 712, the
administrator can decide whether to use policy loader 610, or to use management
station 212 to enter policy rules. If the system administrator decides to use
management station 212, then at step 714, policy rules are entered using edit function
420. However, if policy loader 610 is used, then at step 716, policy rules are entered
into a file, and at step 718, the file of policy rules passes to policy loader 610.
Referring now to FIG. 8, a flowchart of one embodiment to manage policy under
management services 412 inmanagement station 212 is shown. In order to
allow for a complex set of policy rules, a number of different functionality features are
incorporated into system 110 to facilitate implementation and management.
In the FIG. 8 embodiment, at step 810, an authorized administrator logs i n to policy
manager 210. Next, in step 812, the authorized administrator chooses between
administrative mode or enterprise mode. The administrative mode allows
the system administrator to manage administrative policy 226, and the enterprise
mode allows the system administrator to manage enterprise policy 224.
The system administrator is then presented with six menu options including navigate
tree 814, analyze policy 816, edit policy 818, distribute policy 820, view audit log
822, and exit 824. The features of navigate tree 814, analyze policy 816, edit policy
818, and distribute policy 820 are described in more detail through FIGS. 9, 10,
11, and 12, respectively. View audit log 822 is a security feature that allows an
administrator to view and track all authorization requests that have occurred at any
application guards 310 connected to system 110. The systemadministrator can choose
any of the menu options, or at step 824 the system administrator may then exit
the system.
Referring now to FIG. 9, a flowchart of one embodiment of menu option navigate tree
814 in management station 212 is shown. Navigate tree 814 provides a set of
options for an administrator to add, delete, and/or modify features on server 112 or
client 116. The features that an administrator may add, delete, and/or modify include
global users 910, global roles 912, directories 914, local roles 916, local users 918,
applications 920, application guards 922, and declarations 924. At step 926,
the system administrator may then exit from navigate tree 814.
Referring now to FIG. 10, a flowchart of one embodiment of menu option analyze
policy 816 in management station 212 is shown. Analyze policy 816 preferably allows
an authorized user to analyze and view rules and policies within enterprise policy 224.
At step 1010, the user has an option to search rules, or at step 1012 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, at step 1014 the system administrator
may exit from analyze policy 816.
Referring now to FIG. 11, a flowchart of one embodiment of menu "option edit policy
818 in management station 212 is shown. Edit policy 818 allows an authorized user to
add, delete, and/or modify enterprise policy 224 features. The features that may be
edited include rule sets 1110, access 1112, privilege 1114, objects 1116, user/role
1118, and attributes 1120. At step 1122, the system administrator may then exit edit
policy 818.
Referring now to FIG. 12, a flowchart of one embodiment of method steps of menu
option distribute policy 820 is shown. After enterprise policy 224 has been initially
entered or modified in any way, the modified features of enterprise policy 224 may
then be distributed to appropriate application guards 310. At step 1210, upon selecting
the distribute policy option, distributor 214 optimizes enterprise policy 224. Then at
step 1212, differ 438 preferably computes any difference between the newly
optimized policy and optimized policy 222. At step 1214, the newly optimized policy is
then published as optimized policy 222 in DBMS 218. Next, at step 1216, only the
changed portions of optimized policy 222 are committed to appropriate application
guards 310. At step 1218, application guards 310 receive the changed policy, and then
at step 1220, application guards 310 merge the changed policy into local client policy
318. Next at step 1222, new local client policy 318 is activated to work with application
guard 310.
Referring now to FIG. 13, a flowchart of one embodiment of method steps for client
access authorization is shown. The FIG. 13 example for using a standard application
guard 310 by a user begins with a user requesting access to a securable component
protected by an application guard 310. Instep 1310, application guard 310
constructs and issues an authorization request. At step 1312, the authorization request
is evaluated by application guard 310 according to its local client policy 318 to
determine whether to allow or deny the authorization request. At step 1314, audit 518
then records the authorization request in audit log 450. Next, at step 1316, if there is
an error in the authorization request, or if the request is not valid, then at step 1318
the user is denied access. However, if the authorization request is valid, then at step
1320 it is determined whether access shouldbe granted. If the evaluated authorization
request does not deny access for the user, then at step 1322 access is allowed. If the
evaluated authorization request denies access for the user, then at step 1324 access is
denied.
Referring now to FIG. 14, a flowchart of one embodiment of method steps to evaluate
an authorization request from an application guard 310 is shown. In order to evaluate
an authorization request at application guard 310, in step 1420, evaluator 516 first
searches any deny rules in local policy 318. At step 1412, if evaluator 516 finds any
deny rules, then at step 1414, an evaluation is performed on any constraints on the
deny rules. If, at step 1416, the evaluation finds presently valid constraints on the deny
rules, then at step 1418 access is denied. However, if at step 1416, the evaluation finds
that the constraints on the deny rules are not presently valid, or if no deny rules are
found in foregoing step 1412, then at step 1420, a search of grant rules is performed. If
no grant rules are found at step 1422 that would allow access for the user, then at step
1418, access is denied. If instep 1422 grant rules are found, then at step 1424 an
evaluation is performed on any constraints in the grant rules. If the evaluated
constraint is presently valid, then at step 1426, a true value is passed, and at step 1428
access is allowed. However, if the evaluated constraint is not presently valid, then at
step 1426, a false value is passed, and at step 1418 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.

We Claim:
1. A system for maintaining security in a distributed computing environment,
comprising:
a policy manager for managing a security policy; and
an application guard for managing access to securable components as specified by
the security policy, said securable components being selected from the group
consisting of at least one application, a function within an application, a procedure
within an application, a data structure within an application, a database object
referenced by an application, or a file systemobject referenced by an application.
2. The system of claim 1, wherein said policy manager comprises amanagement
station for constructing and editing the security policy.
3. The system of claim 2, wherein said policy manager further
comprises a distributor for distributing the security policy to a client.
4. The system of claim 2, wherein said policy manager further
comprises a distributor for distributing a customized local policy based on
the security policy to a client.
5. The system of claim 4, wherein said policy manager further
comprises a logger for recording and tracking authorization events that occur through
the application guard.
6. The system of claim 4, wherein the policy manager further comprises a database
management system for maintaining the security policy.
7. The system of claim 4, wherein the customized local policy is optimized.
8. The system of claim 1, wherein said system is scalable by further
comprising a plurality of . clients, said policy manager further
managing and distributing a customized local policy to each client, and at least one
additional application guard located on each client for managing access to the
securable components as specified by each customized local policy.
9. The system of claim 1, wherein said application guard includes an application guard
interface coupled to an application for requesting access to the securable
components, and at least one authorization engine for evaluating requests from the
application guard interface as specified by a customized local policy based on
the security policy.
10. The system of claim 9, wherein said application guard interface is located
on a client, and said at least one authorization engine and said customized local policy
are located on a client server.