Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Data File Encryption

Status
Not open for further replies.

sschlicher

IS-IT--Management
Aug 21, 2001
18
US
We have netware 6 sp2 server that houses our in house visual foxpro accounting package. Is there anyway to encrypt the data files so that someone could not open my computer to the map drive and be able to open the data files but still maintain there novell rights to the drive for the program to work properly?

Thanks in advance
 
Your computer should not be left open so anyone can access it. You should ensure that you "lock" your workstation when you leave your desk (Ctrl-Alt-Delete and Lock Workstation). By doing this, someone can only try to access your computer by rebooting as it would need your own password to re-access the computer. If someone was to reboot your computer, they would be returned to the normal login screen.

Only someone with a valid login name and password will be able to access your server and only you should be able to access your own login account.

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
FYI.... Encryption requires NW6.5 SP2. Also, I haven't used encryption in production environments, just some basic testing.. It appears that the encryption is transparent to the end user. So if you have rights to the file system, you will be able to see the files. As Thelad pointed out, you need to take precautions to secure your workstations.

Here are some details from novell documentation:

On the first activation after a system reboot, you must enter a valid password. When the volume is activated, NSS loads the volume's persistent data from the Volume Data Block. If the Encrypted attribute is enabled for a volume, NSS searches in memory for a known key in the list of volume names and keys. If the key is present, it is used. If no key is present, NSS consults the list of volumes and passwords. If a password is available, it is used to unwrap the key from the persistent data and the new key is placed in the list of volumes and keys. The password is eliminated from memory.

Note this portion: >>> After the encrypted volume is activated, all encryption operations on user data are transparent to file system applications that use normal file I/O functions.<<<

Data written to files is held in cache until such time as it would be normally written. At physical write time, the data is encrypted to a temporary write buffer and written to the volume in encrypted format.

During reads, the cache is consulted, as it would normally be, to determine if a requested block is already in memory. If the requested data block is in cache, the clear-text data is transferred. If it is not, a physical read request is made, with the read directed to a temporary buffer. After read completion, but before control is returned to the calling program, the encrypted data in the temporary buffer is decrypted into a cache buffer. The read proceeds normally, with clear-text data being made available to all future requestors.

Marvin Huffaker, MCNE
 
The computer aren't left open for access. You are totally misunderstanding what I need to do. I'll be a little more specific on the issue. Say we have accountant A who runs our accouting package to do the books. The accounting program security only allows him to do the funtions he has rights for (we'll say AR functions for the example) and the accounting group on netware gives him the initial rights to the data directory. Now lets say the accountant is crooked and has a little computer background. Because of his Netware rights he could go to the data directory and with the help of tools he could modify or change the GL file without even going through the accounting program. Now because of SOX auditing this is unsecure. This package was totally written inhouse over a period of about 10 years. There is over 1000 programs intertined that make up this program, so just a simple change of separating the data files to different folders is almost imposible because of all the code.

Any help would be appreciated. We don't have security issues, its just more of an audit hole that needs to be closed.
 
That's a dilemma you have regardless of the application.. How do you give file permissions to the application but make it so that the users are restricted from doing anything destructive. I see that scenario a lot, and usually what happens is the file permissions have to be wide open, and the application security is supposed to control access to areas in the program. Not good at all, but sometimes the only option. If you limit access to the actual files, the program doesn't work correctly.

A couple ideas...

Can you have the control files in different locations that are restricted.

You could probably figure out a way to restrict access with ZENworks, but that would require a lot of testing and goes way beyond what I can go into here..







Marvin Huffaker, MCNE
 
NSS has the Encryption and Shredder features.
You could also use something like BestCrypt containers
stored on Netware.


George Walkey
Senior Geek in charge
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top