602SQL Documentation Index  

Locked Applications

Requirements upon Application Security

When distributing applications to users, it is necessary to meet several security targets:

  1. to provide for protection of application author's know-how and to prohibit free reading of component definitions;
  2. to preclude changes in application internal logic (e.g. checking of intra-application licenses) by application modifications;
  3. to protect data within given application by means of access permissions, not only against illegal users, but also against - eventually - application administrator.

These targets are met in locked applications. The issue whether an application will be locked is decided during its export: An application that was exported as a locked one will be locked after the import as well.

Protection of Sensitive Application Components against Divulgence

Most database application components are - under normal circumstances - stored in the database in text format and, therefore, they are readable to any user that has a permission to use them. 602SQL offers a possibility to store components in encrypted format, to preclude the risk of malfeasance of the source texts from the completed applications that are distributed to users.

An author who intends to distribute his/her application in encrypted format would proceed like follows:

After the locked application has been imported:

The encryption utilizes the robust cryptographic pseudorandom number generator. Each object is encrypted using a different key; therefore eventual knowledge of the source form of some encrypted object would not assist in decryption of others. Roles cannot be encrypted.

Protection of Invariability and Operating Efficiency of the Application

A permission to modify the components of the imported application is assigned solely to the user that is appointed to the role of Author. That holds both for encrypted and unencrypted components.

If the locked application is imported, then no user is - and cannot be - appointed to the role of Author; therefore its components cannot be modified. New components can be created and later also modified.

If the author intends to permit user modifications of some components during operation, then permissions to modifications must be assigned to some other role.

Protection of Data in the Application

No role within an application need to have full permission to all the data. It depends upon application authorīs intentions, how he would assign permissions to data to individual roles that are defined within given application. Due to that, application users can have private data in some tables that cannot be read or modified even by the application administrator.

Triggers within an application have an unlimited access to data; the same holds for queries and procedures stored at the server, provided that they are marked for execution in the administrator mode.

If the application is locked, then following four paths to unauthorized data access are blocked:

All permissions mentioned above are owned solely by the user appointed to the Author role and in the locked application, nobody of this nature exists. Administrator of the locked application cannot appoint somebody to the Author role.

Upgrade of the Locked Application

Transition to the mew version is usually realized by means of import of new and modified components into the older application version.

During the upgrade import, the importing client is temporarily appointed to the Author role; therefore he is able to create and also to modify components beyond the scope of application user permissions.