IE960687A1 - A data processing system - Google Patents

Abstract

A data processing system (1) has a general interface (3) which accesses a database (2) by a path (A) including a database driver (10) and a database engine (11) using a data dictionary (12). The general interface (3) operates according to at least two modules, each comprising a suite of programs. Shared data for access by two or more modules is stored within a table (M.1/C), being the module which most frequently accesses the shared data. There is a separate auxiliary interface (20) which provides direct access to the engine (11) for fast security operations both initially and in-line. The auxiliary interface (20) decodes security tables (26) with code which is embedded within it.<Fig.1>

Description

The invention relates to a data processing system, and more particularly to such a system having a substantial database, in excess of 10MB of code. The invention is particularly directed towards data processing systems in which confidentiality of data is of importance and in which there are at least two processing modules, each having a suite of programs. An example is a data processing system for performing both payroll and personnel functions, confidentiality of such data being very important and there being a processing module for each of the payroll and personnel functions.

It is desirable in such a system to provide both extensive security to control access to data because of the required confidentiality, and secondly to integrate the processing modules together for consistency and simplified update operations. Because of the large number of blocks of code in a system of the size indicated above, levels of security which ensure correct access conditions for each operation and operand divert significant system processing resources. Even more resources are required to ensure that no temporary access limitations are in force, such resources providing various security monitors for constant supervision.

These problems are often addressed by providing very extensive hardware resources, possible including parallelprocessing workstations and many tens of MB of memory.

WO 95/22792 (British Telecom) describes a system in which row and user tags are correlated in a table to define security. This appears to be effective for many situations, however, for the situation set out above such - 2 security procedures would cause an excessive processor overhead.

The invention is therefore directed towards providing a set of technical features to ensure both good data access security and processing integration between modules without a consequent disimprovement in response time.

According to the invention, there is provided a data processing system comprising:user input and output interfaces; a general interface comprising a CPU operating according to at least two program modules, each module comprising a suite of programs; a database comprising a set of tables associated exclusively with each program module, and additionally a set of tables all of which have cells which are specific to a single program module and also cells which are for shared access by that module and at least one other module, the configuration of the tables being indicated by a data dictionary; a database drive and a database engine connected between the general interface and the database and providing a general data access path for the system; a set of stored security tables, each table indicating security for a plurality of security levels, wherein for each security level there is a cell indicating allowed access conditions for each of a of screen display programs, each cell comprising a series of indicators, the physical location of each indicator in the series determining the data for which an access condition is indicated, and wherein a security table provides security access conditions for options associated with screen display programs, each cell being associated with a screen display program and each indicator providing an access condition for a screen option of the associated program; and an auxiliary interface comprising the CPU operatively connected to a memory storing a hard-coded program for which there is no user editing interface, the program comprising code providing direct access to the database engine, by-passing the database driver, and comprising code for directly accessing the security tables to determine security access conditions for data, and in which correlations between the physical location of indicators in the security table cells and the associated data are embedded within the code of the auxiliary interface.

In one embodiment, a security table provides security access conditions for individual data items, each indicator in a cell providing an access condition for a particular data item on a one-to-one correlation and the auxiliary interface comprises means for automatically accessing said table to set access conditions in-line during operation of the general interface.

Preferably, characters describing rows and columns in a security table are encoded by comprising ANSI values which are off-set from the standard values in a manner which is decoded by code embedded within the auxiliary interface.

In another embodiment the auxiliary interface comprises means for automatically performing table analysis operations before retrieval of data by the general interface, said analysis operations comprising counting - 4 of data items in a relevant database table, providing a statistical analysis, and activating the database engine to perform maintenance operations.

In a further embodiment, the auxiliary interface comprises means for automatically activating operating system screen control operations before data retrieval by the general interface.

Preferably, the general interface comprises means for automatically writing information relating to data updates to both an audit trial file and a transaction file.

In another embodiment, the general interface comprises a means for automatically prompting a user to input a comment relating to a data update and for writing said comments to the audit trial file.

Preferably, the general interface comprises means for automatically prompting input of comments both before and after an update is made and for writing said comments to the audit trial file.

The invention will be more clearly understood from the following description of some embodiments thereof given by way of example only with reference to the following drawings, in which: Fig. 1 is a schematic representation of a data processing system of the invention; Fig. 2 is a flow diagram showing access control and retrieval of data in the system; and Fig. 3 is a representation of a stored security table. - 5 Referring to the drawings, and initially to Fig. 1 their is shown a data processing system 1 of the invention. The system 1 comprises a database 2 comprising in the region of 100 tables ranging in size from 5KB to 6GB. The total capacity os 10GB.

The system 1 comprises a general interface 3 which in this embodiment is a microcomputer CPU of the Pentium™ - based type operating according to (Graphical User Interface) G.U.I. front-end programs generated from software developed in the Visual Basic™ language.

The system 1 has an input interface 4 including a mouse and a keyboard. There is an output driver 5 which interfaces with both a display screen and a printer.

The general interface 3 communicates with a database driver 10 of the ODBC™ or Jet™ type. The database driver 10 converts signals between the general interface 3 and a database engine 11 of the Microsoft BTrieve™ type. The database engine 11 uses a data dictionary 12 having three disk files, namely index, field, and table files. It provides a comprehensive dictionary for all of the tables within the database 2. The general interface 3 is of the type which may be easily re-programmed by a user by use of high-level graphical interface user tools. This allows a large degree of versatility in user configuration of the system 1 for optimum performance and ease of modification to customise the system 1 to a given application. The general interface 3 accesses the database 2 on a Path A via the driver 10, the engine 11, and the data dictionary 12.

In addition, the system 1 comprises a hard-coded auxiliary interface 20. In this implementation, the - 6 interface 20 is the CPU of the system 1 operating according to low-level hard-coded programs for which there are no user editing tools. These direct access to the engine 11 for specific tasks for data access control. The code of the interface 20 provides for direct access to the database engine 11 via a path B, which by-passes the route of the general interface 3 via the database driver 10. Path B does not include two of the interfaces of Path A, namely those on both sides of the driver 10. The interface 20 may alternatively comprise a memory storing non-editable encrypted machine code, or fusible link EPROM devices with security lockout to prevent reverse engineering.

The database engine 11 is configured to access a set 25 of security tables 26 which are not represented in the data dictionary 12. The manner in which the security tables 26 are stored helps to ensure security. This is described in more detail below.

The general interface 3 and the auxiliary interface 20 are both programmed to provide a high level of data access security with little impact on response time. Further, the general interface 3 is programmed to operate according to programs of different modules using shared data in an efficient manner.

The manner in which the interfaces are programmed is describe by reference to the diagrams of Figs. 2 and 3.

Referring in particular to Fig. 2, a data access process 30 is illustrated. A step 31 is automatically performed by the auxiliary interface 20 to retrieve a security table in response to recipe of a login request by a use at the general interface 3. The auxiliary interface 20 repeatedly retrieves security tables to perform a sequence - 7 of security operations. These operations are performed independently of the general interface 3 and because the interface 20 is hard-coded for direct access to the database engine 11, the security files 26 are retrieved in a very fast manner. Further, the general ongoing development in software drivers involving modifications to the interface 3 and the driver 10 do not affect operation of the auxiliary interface 20. Such modifications may include replacement of a driver due to errors requiring patches.

The initial security tables 26 which are retrieved relate to the user name and password, and subsequent tables provide a detailed configuration setting out data which may and may not be accessed by that particular user. One of these security tables is described in Fig. 3. It comprises a set of rows, one for each of a number of predefined security levels. Previously using other security tables, the auxiliary interface 20 has determined that the user is authorised, and has determined the security level. Then, by reference to the table 26(a) shown in Fig. 3, the auxiliary interface 20 determines the set of menu options which may be presented to that user. Each column of the table in Fig. 3 relates to a particular display program, indicated alpha-numerically by Ml.a, Ml.b to Ml.n. Each of these display programs has a one-to-one correlation with a display screen.

Therefore, each cell of the table 26(a) sets out the menu options which are allowed for a particular security level, for a particular display program in the general interface 3. The manner in which these settings are indicated is pre-defined. Each cell comprises a set of thirty-two binary bit indicators, each having a value of either 0 (off) or 1 (on). The correlation between the physical location of the binary bit in each cell and the associated - 8 menu option is pre-defined in the auxiliary interface 20. The definition is embedded in the program code - which has been found to be much more secure than separately storing them. Because of the pre-defined bit sequence, each cell stores a very large amount of data, while only requiring thirty two bits of storage space. This provides for very fast security control operations. The time savings are in the order of tens of microseconds per display, of which there may be many hundreds. This is particularly important during Initial Program Load (IPL) where the database 2 is on a remote file server. In this case, each delay would be compounded by conventional network traffic delays .

Another feature providing security is offset-encoding of the row and column characters, the standard ANSI value being added to or deleted from according to a control process embedded in the code of the interface 20.

In summary, as indicated by the steps 31 and 32, a series of security tables 26 is retrieved until a code from a cell in the table 26(a) has been retrieved. This sets a comprehensive plan for the data which may be accessed and covers the menu options which the general interface 3 may present to the user.

In step 33, the general interface 3 receives a data access request and in step 34 auxiliary interface 20 automatically detects such a request and performs fieldlevel security using security tables configured in the same manner as the table 26(a) shown in Fig. 3 to determine which fields within the screens may be displayed. Again, because the auxiliary interface 20 is hard-coded and by-passes the conversion operations of the database driver 10, this in-line field-level security - 9 process is carried out very quickly with very little impact on response time.

Upon completion of the step 34 the general interface 3 may then access the allowed data fields using the driver 10 and the database engine 11 in conventional manner. The general interface 3 then proceeds to retrieve the data items from the allowed fields for display and output, as requested. However, at the initial stage of accessing the relevant data files the auxiliary interface 20 performs additional functions in a very fast manner and which assist the data retrieval and display process. These include in step 35 performing data storage analysis which is a low-level analysis of the table which contains the retrieved data items, and display of the output. At its most basic level, such operations involve counting the current number of records in the file and other statistical analysis operations. The interface 20 also prompts the engine 11 to perform maintenance operations such as compaction of the database fields and tables, automatic repairs, and reindexing requests to ensure optimum performance of the system as a whole.

In addition, in step 36 the auxiliary interface 20 directs the operating system to perform various screen control operations including screen colouring, setting screen coordinates, performing screen synchronisation, and status bar initialisation. These generally constitute up to 30% of the delays in loading a screen.

In step 38, the general interface 3 performs any necessary data updating. Referring again to Fig. 1 the database 2 has data tables which fall into three main categories. The first category includes tables which are specific to a first processing module, namely Module 1. These are indicated by Ml. The second category includes tables - 10 which are specific to the second processing module and are indicated by M2. the third category is a set of tables which are specific to the first module, but also include common fields for shared data accessible by all modules. These are indicated by Ml/C, C indicating common.

In performing a data update, the general interface 3 refers to a link between the relevant field and the table cell, this link being provided within the field structure.

An important aspect of the data updating is the fact that the shared fields are in files for the module which will use those fields most often, and the fact that the shared data is stored only once. This allows the system to be relatively easily upgraded by addition of further modules. Conventional file locking techniques can be used for controlling concurrent access, if required in a networked implementation of the invention.

The general interface 3 writes data indicating all updates to both an audit trial file and to a transaction file in step 39. An audit trial or transaction file data update entry includes :- DATA TYPE SIZE tBYTES1 NAME Date 4 EFFECTIVE DATE Date 4 POST DATE Time 4 POST TIME String 4 DATABASE TABLE IDENTIFIER String 1 AUDIT TYPE String 10 INTERFACE LOCATION String 12 USER IDENTIFIER String 60 COMMENT String 250 BEFORE 1 String 250 BEFORE 2 String 250 AFTER 1 String 250 AFTER 2 To make a data update, the interface 3 automatically prompts the user to enter tow text string comments beforehand, and then two again after the update. These are the COMMENT, BEFORE 1, BEFORE 2, AFTER 1 and AFTER 2 entries. The transaction file record may not include the comment fields.

The EFFECTIVE DATE field indicates how the interface 3 can handle updates being made which have a later effective date. The updates are automatically activated in response to a real time clock.

The invention is not limited to the embodiments described, but may be varied within the scope of the claims in construction and detail.

Claims (9)

1. A data processing system comprising:user input and output interfaces; a general interface comprising a CPU operating according to at least two program modules, each module comprising a suite of programs; a database comprising a set of tables associated exclusively with each program module, and additionally a set of tables all of which have cells which are specific to a single program module and also cells which are for shared access by that module and at least one other module, the configuration of the tables being indicated by a data dictionary; a database drive and a database engine connected between the general interface and the database and providing a general data access path for the system; a set of stored security tables, each table indicating security for of a plurality of security levels, wherein for each security level there is a cell indicating allowed access conditions for each of a plurality of screen display programs, each cell comprising a series of indicators, the physical location of each indicator in the series determining the data for which an access condition is indicated, and wherein a security table provides security access conditions for options associated with screendisplay programs, each cell being associated with a screen display program and each indicator providing an access condition for a screen option of the associated program; and - 13 an auxiliary interface comprising the CPU operatively connected to a memory storing a hard-coded program for which there is no user editing interface, the program comprising code providing direct access to the database engine, by-passing the database driver, and comprising code for directly accessing the security tables to determine security access conditions for data, and in which correlations between the physical location of indicators in the security table cells and the associated data are embedded within the code of the auxiliary interface.

2. A system as claimed in claim 1, wherein a security table provides security access conditions for individual data items, each indicator in a cell providing an access condition for a particular data item on a one-to-one correlation, and the auxiliary interface comprises means for automatically accessing said table to set access conditions in-line during operation of the general interface.

3. A system as claimed in any preceding claim, wherein characters describing rows and columns in a security table are encoded by comprising ANSI values which are off-set from the standard values in a manner which is decoded by code embedded within the auxiliary interface.

4. A system as claimed in any preceding claim, wherein the auxiliary interface comprises means for automatically performing table analysis operations before retrieval of data by the general interface, said analysis operation comprising counting data items in a relevant database table, providing a statistical analysis, and activating the database engine to perform maintenance operations. - 14 5. A system as claimed in any preceding claim, wherein the auxiliary interface comprises means for automatically activating operating system screen control operations before data retrieval by the general interface.

5

6. A system as claimed in any preceding claim, wherein the general interface comprises means for automatically writing information relating to data updates to both an audit trial file and a transaction file.

7. A system as claimed in claim 6, wherein the general 10 interface comprises means for automatically prompting a user to input a comment relating to a data update and for writing said comments to the audit trail file.

8. A system as claimed in claim 7, wherein the general interface comprises means for automatically prompting 15 input of comments both before and after an update is made and for writing said comments to the audit trial file.

9. A data processing system substantially as hereinbefore described with reference to and as illustrated in the accompanying drawings.