There are a number of things you can do with permissions before you get into encryption.
You can create a folder which the application has write permission, but only grant read to certain user accounts. You can also remove the Take Ownership permissions from Administrator to prevent a local admin stealing the file. If you want to use a database then you should create a user which only has permission to run 1 custom stored procedure which inserts the logging record into the database. The user would not have permission to read the records back. Then you need to have a separate controlled user to access the data. Note that the DBO would still be able to access the data so that user would need to be controlled for that database. If you use encryption it is most important to consider security of the keys. If using symmetric encryption (DES, etc.. including Windows NTFS encryption) the key used to write the encrypted data can also be used to decrypt it. To encrypt the data the application needs access to the encryption key (or, for windows NTFS encryption, the user account), but you don't want unauthorised personnel to have access to the decrypt key. You may want to consider using a public key system to encrypt the data as they encryption key can be widely known, e.g. stored in the application's config file, or in the Windows certificate store, but it cannot be used to decrypt the data. The decryption key is separate and can be held safe by authorised personnel. Public key (asymmetric) encryption is generally much slower than private key (symmetric) encryption, most public key systems just use the public key to encrypt a symmetric key which is then used to encrypt the data. This may cause extra problems if you want to keep re-opening and writing to the same file each time as you won't be able to find out which symmetric key you used before. The encryption APIs don't really help you with this very much, they let you do the basic stuff. To decrypt the data you will need to write your own tools as well. As far as which is the way to go; writing to an encrypted folder or writing to an encrypted database would depend very much on your infrastructure and whether or not you can control access sufficiently. If you want to write an EncryptedFileAppender then you need to override the OpenFile method to wrap the FileStream in a System.Security.Cryptography.CryptoStream. Note that this can only be used with a symmetric encryption algorithm, so you would need to decide that side of things first. Alternatively you could wrap the TextWriter used for output by overriding the SetQWForFiles method. Overriding SetQWForFiles is simpler because you don't have to open the file, but it depends how you decide to implement the encryption. You probably need to use a combination of strictly controlled permissions and data encryption. Nicko > -----Original Message----- > From: Hart, Leo [mailto:[EMAIL PROTECTED] > Sent: 04 March 2005 20:20 > To: [email protected] > Subject: Secure Logging > > OK, here's a problem I'm sure many of you have come across: > > We're planning on integrating Log4Net into our web > application. We'll be using it for the normal purposes: > logging user activity and creating debugging statements in > case of exceptions, both of which will include information > considered to be highly confidential. I would prefer to > output our logging information to a rolling file appender, > however, our ISO will not be happy with the fact that > potentially sensitive information like account numbers, SSNs, > etc will be stored in clear text on our application's server. > Basically, on one hand we want to log this information > because it's necessary to debug any problems, but on the > other hand we don't want to log this information because not > even the system administrators are permitted to view the data > (our database is highly secured, so only a small few can > view the data that way). > > So I was wondering if any of you have been presented with > this problem and was wondering what steps you have taken to > get around it. Three potential solutions came up on our side: > > 1. Somehow make Log4Net encrypt all of its logging output > prior to writing it to the log (maybe creating a new appender > that extends the rolling file appender). > 2. Creating an encrypted folder on the server and writing > the file to that location. > 3. Logging to the database. > > OK, so #1 sounds good, but I'm not sure where to start. > > #2 should be fairly straight-forward, but I guess you have to > link up a user account to a SID and if someone removes the > user account, there's no way to access the folder. > > #3 won't work as of now because we need to encrypt the > username/password in the Log4Net config file, which I don't > believe is currently supported. Also, I don't really dig the > idea of logging to a database because it just adds one more > point of failure to process. > > So what do you guys think? Any suggestions on what I should > do? If you think #1 is the way to go, how would I go about > doing this? > > > Thanks, > Leo Hart >
