Get started Bring yourself up to speed with our introductory content.

Encrypt communication between iSeries and desktops

What do you do when you need to encrypt information flowing between iSeries servers and desktops? Here are a couple ideas.

The scenario: A company has users connecting to multiple iSeries and AS/400 servers using TCP/IP. The operating...

systems vary from V4R5 to V5R3. Several products are used to communicate through the network from the desktops to the different servers. The company wants a tool that will encrypt the information being passed between the PC desktop to the servers.

The company has several servers in multiple locations on its WAN. It already has both a firewall and VPN set up for external access to its network. iSeries access is only one of the emulation software packages in use; there are at least two others -- Reflections and e-Vantage.

Solutions:

"LOVESOPENSYSTEMS" WROTE:
One alternative is to use VPN (virtual private network) technology products such as IPsec from Nortel or VSClient from InfoExpress. They can be used over a company's internal network or across a public network. We use it to support all employee communication when people are traveling and dialing in or attaching to a high-speed cable network or DSL line from an external network. We also use it whenever a communicating node is attached to a wireless LAN -- whether they connect to our intranet or the Internet -- as an interim approach until 802.11 wireless security becomes more robust.

These security mechanisms function at the IP layer and are transparent to the applications. See AS/400 Internet Security: Implementing AS/400 Virtual Private Networks for information about the AS/400 implementation.

IPSec is an IETF standard. I'm afraid I don't have any information about the cost, but once you start looking for specific information on the technology, you should be able to pin that down.

itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke

"SOLUTIONS1" WROTE:
You can implement SSL by installing certificates on your servers. (You can also install client certificates on Express clients.) Doing so is probably the best option long-term.

In the literal sense of your question, full end-to-end encryption and server-based SSL is the best way, even if installing and updating the certificates is an annoying exercise. Putting in intermediate servers creates an added layer of cost and complexity. Note that having SSL on your AS/400s also simplifies the security setup for publishing Web services natively on the AS/400.

You have ample options for securing your traffic into your AS/400 environment. In picking among them (and others not mentioned), I suggest you keep in mind three architectural principles:

  1. Given that roughly 70% of the typical company's security risk is internal and 30% external (with the proportions varying based on the type of risk -- e.g., risk of vandalism is probably much more external; risk of peeking at personnel records regarding succession planning is probably more internal), originating the node to end-user level security is important. In your case, the AS/400s seem to be your bedrock "nodes."
  2. Thin client vs. fat client (or, at least, fatter client) is a key consideration. I tend to favor the very thin side of the spectrum, and "pure" SSL is about as thin as you can get while still attaining end-to-end encryption. Consumer "home banking" and self-service securities trading are secured based on SSL (and not much else) and address major security concerns regarding money. Indeed, the reason "phishing" is becoming commonplace is because SSL works well enough to divert prospective intruders to an automated form of "social engineering."
  3. Thin middleware vs. fat middleware is a related consideration, and again I tend to the thin school of thought. The more you add intermediate servers, complex middleware and so on, the more you run up against cost and manageability problems. There may be very good reasons for implementing complex middleware, but in my view the assumption going in would be that simple is better and then escalate only if gaps become apparent.

Obviously, you know your own circumstances, objectives and constraints better than any outsider, so my opinions are just my opinions.



This was last published in March 2005

Dig Deeper on Security Tools

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

Close