| Description of Requirements (continued)
Security Topics
Unlike the previous sections, which
attempt to describe what will be required in a device, especially a disc drive, to support
an object abstraction, this section merely introduces some issues for consideration. As
the security requirements, we feel, are not yet sufficiently understood or described; it
is premature to suggest what will be needed in a device to satisfy the security needs of a
full NAS implementation. It is hoped
that this section will lead to more definition of what is needed, which will in turn
stimulate progress in this area.
As system configurations grow more
dispersed, the threat to security increases. NAS makes it easier to configure the
equivalent of a server with elements spread over a campus or city – or the Internet.
The Interconnect becomes correspondingly more susceptible to compromise. NAS should do its
part to prevent this increased exposure with more sophisticated security capabilities.
Permissions
The File Server can gate access to
storage by controlling to which Requesters it gives the credentials needed to get a
response from an OOD. The File Server also dictates to the OODs that they must only honor
I/O requests that adhere to the installation security policy.
For the storage interface, this entails
protocols that protect against corruption or snooping of traffic. The functions described
above provide for the ability to include sufficient protection to insure that the OOD can
validate the request as a legitimate one.
The keys underlying the permissions
security capability can be communicated to the OOD by the SET OBJECT ATTRIBUTES function.
If the appropriate level of security is set for an OOD, the OOD will check every I/O
command for security compliance. It is conceivable that some applications will use
security and some will not.
There is a great interest in remote
redundancy. If a server cluster had some devices located in another facility, it may be
desirable to define a higher level of security for communication with them, but not for
local traffic – to avoid the performance loss that would accompany the more complex
commands.
Cryptographic Support
If a device must perform secondary
operations on an object – such as compression, encryption or decryption – there
could be a huge performance penalty. There would also be some unavoidable cost for this.
The device might have to write the original object to the media, then reread it, pass it
through the appropriate encryption logic, and rewrite it. Managing several of these
concurrently, while also servicing a queue of I/O requests, puts quite a burden on that
logic and on the overall performance of a device that today's architectures would be hard
pressed to carry.
The added cost could be a problem. I
suspect the market will have to decide if it is willing to bear that across the board. It
is almost impossible to offer it as an optional feature on a drive. Either the industry
will buy into the concept or it will not.
Audit Trails
The necessity of logging an audit trail
of NASD activity to itself could also
pose a problem. It could be ameliorated by having the option to log the audit trail on
another network device dedicated to that function. Even so, the bandwidth consumed by a
sizable number of devices logging records would obviously reduce the application
bandwidth.
It might seem that a single extra
message for each I/O is not a big deal, but in a transaction environment, it is a BIG
deal! All I/O is essentially a message, and the I/O subsystem is typically message bound.
We already have some experience with this kind of thing on a drive where the SMART feature
causes logging of environmental data. It can have a significant impact on performance. And
the SMART data is only summary information.
Clocks
Each device will have a readable,
monotonically-incrementing clock to be used for timestamping secure messages and objects.
Either this clock must be synchronized system wide or the server will have to accommodate
the discrepancies in values from device to device.
|
