|
> > > > I think it would be beneficial to the list to reflect on what you > > _really_ just said. > > Or at least your perception of it. > > > You said (and I'm paraphrasing heavily here), "Rather than > > properly securing your OS/400 applications, you're better off > > pulling data off of the /400 and dropping it on a Linux or > > Windows machine that you don't have to bother securing." > > I said nothing of the sort. If you read the thread, I carefully separated > data into two categories: secured and unsecured. This is a real and vital > differentiation. Secure data should be on a secure server, and for me, > that's OS/400. Unsecured data, on the other hand, is more problematic. I typed "said" and perhaps should have typed "heavily implied". While I agree on the task of separating data into "secured and unsecured", I disagree that this distance requires the physical space afforded by two different hardware platforms. If you've got the robust security features of OS/400 available to you, you can separate the data on the same box. For you Separation seems to be at the hardware level, I maintain that library level would be adequate. But I suspect you and I will have to agree to disagree on this point. > It depends on the currency requirement in relation to secure data - that is, > how closely does the unsecured data have to reflect secured data. Static > web pages by definition have no such requirement, while account status in an > online trading system requires pretty much direct access to secured data. > The less current the data needs to be, the better the argument for > offloading it for two reasons: security and system load. I think that this paragraph's reference to system load can be a convincing argument for offloading static web pages to a less expensive (to purchase) platform. However, the arguement that "static" information has no need for security just doesn't make sense. There is lot's of static information that is well deserving of the best protection money can buy. My Social Security number, the Coca Cola formula, Sate Farm's actuarial algorithms, etc. etc. Just because data does not normally change doen't mean it should be left unsecured. Remember that disclosure is the most common security breach. This is true whether you are serving the data via web pages or not. jte
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.