|
Putting each client into his own subsystem alone is not an adequate
solution. While you may not be able to steal the system resources (e.g.,
CPU) allocated to another client, there are no controls within subsystem
configuration that allow you to control access to objects. For example,
just because Client A is running in subsystem 1 does not mean that Client A
couldn't write a program to access the objects that belong to Client B whose
application runs in subsystem 2. Each client needs to be separated into
its own library and/or directory structure, and the object authority for
this structure needs to be configured so that only that client can access
the objects -- all other clients are excluded. I've seen this implemented
successfully, but it does take some careful architecture and design so that
clients are prohibited (via object level authorities) from accessing other
clients' applications and data files. ==================================
MORE INFORMATION ON THIS TOPIC
==================================
The Best Web Links: tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Check out this Search400.com Featured Topic: Top ten security tips
|
