shai hess wrote:
Question, how are you going to handle security, especially if its RACF?
Two options:
1. Query MVS RACF from PC before accessing the data.
2. Using MFNetDisk security which allow only specific IP to access the data
(IPOK in my documentation).
Security, Security and more Security.
MFNetDisk mirrors and data is not going to be a site which everyone in the
world can access, put virus and surf the Internet.
I want to hear from all of you (please do not mention RACF again because
this will force me to access MF) what you think about security in MFNetDisk
data and mirrors. What is the best way to handle security better then
allowed only specific PC to access the data.
Shai,
Frankly, it seems that you do not understand the security issue, which
is driven by specific laws in the USA, including most famously
1) HIPPA - Health Insurance Privacy Protection Act
2) The Sarbanes-Oxley corporate financial accountability law
These laws require that in certain types of companies, certain types
of databases are required to be protected by a security system that
allows an auditor to determine
- who (which person) has modified a data record, and what exactly did
they change (i.e. a logfile must collect before-and-after snapshots)
- who has looked at a data record
The regulators are quite serious about these laws. My wife is a
hospital nurse, so I have gotten a glimpse of how these systems
work, and how they are integrated in the company workflow.
Because any employee in these companies can be fired or even subjected
to criminal prosecution for looking at data they may have technical
but not legal access to (for example, if a friend or neighbor is
a patient in the hospital where my wife works, she is allowed to
look at the person's record only if that patient is on her floor)
the protection system must be extremely trustworthy.
z/OS and with one of the leading database systems and one of the
leading security systems CAN provide such assurance.
Data that is under this kind of protection can not leave the mainframe
unless it is encrypted in a way that cannot be decoded outside of
the "security envelope".
Even in this type of company, most of the data is not that critical.
The printfile from an accounts payable check run may not contain
anything that is legally protected. (A snapshot of the corporate
balance sheet for a publicly traded company probably does.)
But in order to prevent "leaks", auditors generally like to see
a system that enforces fundamental separations, such as "data can
only move from this area to that area under these rules". Where
there is not a data path, a leak cannot occur.
A product such as yours is thus unlikely to be allowed into the
data center of a large (publicly traded) company or a company in
the Health Care industry.
At the same time, it seems it can be VERY valuable to the most
cost-conscious segments of the mainframe market:
- small independent software developers
- smallish privately owned companies that are not in a regulated
industry.
It seems to me that a product like yours can provide a path to
geographic dispersion of physical data storage for a significantly
lower cost than the state-of-the-art storage arrays from the
major vendors, who may not a have an affordably priced system at
a low enough performance point for these classes of customers.
Both of these groups would be even better served (and would not need
a product like yours) if a lower-priced product line were available
from IBM, such as a developer-only license for a Hercules-class
product. But that is another thread (that scares people here).
/ Lars Poulsen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
