AcuXDBC offers a variety of ways to secure your database. If you don't adopt any of these methods, your database is open to everyone.
- You can hide individual data fields from within your COBOL application by using the HIDDEN directive. This directive instructs
the compiler to flag a specified COBOL field as hidden when the XFD file is generated. When the XFD is subsequently loaded
into the database, this field will not appear as a column in any description of the table. This is useful for hiding data
like passwords, telephone numbers, and financial information — whatever information you do not want users to see.
- You can tag fields or columns of data as read-only using the READ-ONLY directive. Users can then view the data but not update
it.
- You can use the READ_ONLY configuration variable to establish the read and write permissions for all the files belonging to
the database.
- You can grant database-level and table/file-level privileges to individual users or to PUBLIC using the SQL statement GRANT.
This updates the system tables known as GENESIS_USERS and GENESIS_AUTH. When
AcuXDBC receives the connection string, it compares the username and password supplied through the data source name (or user-entered)
with the GENESIS_USERS table. If the GENESIS_USERS table doesn't exist,
AcuXDBC allows the connection. If the table does exist,
AcuXDBC checks to make sure the user and password match a record.
For general information on granting permissions, see Granting Database Privileges and Setting Permissions on Your Database Tables.
- You can create views of your data using the SQL statement CREATE VIEW to show certain fields and columns of data in your database,
but not others. A potential situation in which this could be useful is the following:
An application has a customer record containing all of the information on a customer. The application developer would like
to enable clerical workers to update some of the customer information, while masking any private information. A good way to
do this is making one user the owner of the full table. The application developer could then create a VIEW of the table that
contained only the non-private information. If the view were created as owned by PUBLIC, all users would be able to access
this information while maintaining the confidentiality of the remainder of the information.