Net.Data Programming Guide

Keeping Your Assets Secure

Although Net.Data does not provide any type of security measures directly, you can keep your assets secure with existing measures you probably already use to protect your system and data. You must decide what level of security is appropriate for your assets.

• Authentication

  Net.Data supports two types of authentication: one protecting certain directories on your server and one protecting your database.

  • Most Web servers allow you to specify directories on the server to protect. You can also have your system require a user ID and password for people accessing files in directories you specify. See the Administrator's Guide for your Web server to determine your system's capabilities.

  • DB2 has an authentication system for database access that can restrict access to tables and columns to certain users. You can use Net.Data's special variables, LOGIN and PASSWORD, to link to the DB2 authentication routine. OS/390 and OS/400 use a different security scheme, as explained in Net.Data Reference Guide.

• Encryption

  You can encrypt all data sent between a client system and your Web server when you use a Web server with Secured Sockets Layer (SSL) or Secured Hypertext Transfer Protocol (SHTTP). These security measures encrypt login IDs, passwords, and all data input through HTML forms from the client and all data sent from the Web server.

• Firewall

  Net.Data can be used with IBM Firewall and most other firewall products, which protect both the Net.Data server and the network from external probes or attacks. Carefully consider these configurations with your organization's security policies:

  • Configuration A

    In this configuration, a subnetwork is created that contains only Net.Data and the Web server. This is the most secure configuration, placing both Net.Data and DB2 inside the firewall. This configuration requires these security measures:

    • In the packet filtering configuration file, let incoming TCP packets from any host on port 80, the standard http port, to access the Web server. Also let outgoing TCP ack packets go to any host from the Web server.

    • Install a socks server on the firewall. In the socks server configuration file, add an entry to allow ftp and telnet access to the Web server from the intranet. People using the intranet who want to ftp or telnet the subnetwork usually need to edit the /etc/socks.conf file to direct their requests through the socks server.

    • To let Net.Data access DB2 inside the intranet, install Client Application Enabler (CAE) on the Web server (not needed for OS/390 and OS/400) and add a packet filtering rule to allow DB2 client requests from Net.Data and ack packets from DB2 to Net.Data. OS/390 and OS/400 do not need CAE.

  • Configuration B

    An alternative configuration is to place Net.Data outside the firewall on a workstation platform with DB2 inside the firewall, and using DDCS to communicate between them. This configuration is simpler than Configuration A, yet still offers database protection.

    This configuration shows DB2 inside the firewall. The Web server must have CAE installed. Also, the firewall must have a packet filtering rule allowing DB2 client requests from Net.Data and ack packets from DB2 to Net.Data.

  • Configuration C

    The firewall needs no packet filtering rules for this configuration, but Net.Data and DB2 are left unprotected from external attacks.

Yet another method to protect your assets is to create your own protection scheme using Net.Data. For example, you can request validation information from a user through and HTML form and validate it using data in a database or through an external program called from a Net.Data macro.

You also protect your assets by the SQL statements you allow people to send to the database. For example, limiting SELECT statements to two tables. For more information on protecting your assets, see the Internet security list of frequently asked questions (FAQ) at this Web site:

http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html

For additional security, consider using hidden variables to conceal your database's internal structure from people who choose to view your HTML source with their Web browser. See "Hidden Variables" for more information.