-2

I have an application (in a pure windows environment) that needs to store sensitive data so that other workstations with the same applications can access that data. At the moment that's done using a central server with a SMB network share and encrypted files. All (windows) users that use our application have to have read/write access to one central shared folder and this way data is stored and exchanged.

This configuration has one big drawback: Not only the application but also all users of our application have full access to that shared folder.

Ok, they can't read the sensitive data, as it is encrypted, but - given some criminal energy or stupidity - they can simply open a windows explorer, navigate to that shared folder and delete files there.

I tried but didn't manage to open the SMB-share only for my application - as soon as my application authenticates there, also the current windows user has access.

(I tried using WNetAddConnection2, but as soon as the authentication happened, the connection is opened also for all other programs. And if I don't map the SMB folder to a drive letter, I can not even disconnect the drive again)

Are there possibilities to authenticate only a process or a thread and not the current user for access to a network share?

Or are there performant alternatives to SMB shares? One data record is something between 100 and 900 MB in size. Therefore I need support for random access reading/writing to the files.

Using SFTP and pumping the entire data to the workstation when opening and sending everything back when closing is not an option. That would stress the network and if the application crashes, all changes are lost where when using "normal" access only the data in the network cache is lost.

Any recommendations?

ralfiii
  • 584
  • 4
  • 13
  • if AD is a possibility you can off load data access to a service (running as network service) which would require a machine account for the share and some interprocess communication for the main app. – Sertac Akyuz Apr 18 '19 at 16:50
  • 2
    Have you considered using a database to store your records in? This is the usual tool for this purpose. – J... Apr 18 '19 at 18:20
  • 1
    This is poor design. Put the data in a database, and let the server handle the security using its built in features to do so. Kludging around with a shared folder to work with secure data is simply not going to work. – Ken White Apr 18 '19 at 20:44
  • J..., Ken White: A database is not an option, Similar to using SFTP I would have to transfer the entire data block. The data is similar to a video stream. If a user wants to review a portion of that video somewhere in the middle of the recording I can access this easily using TFileStream.Seek and TFileStream. I can't do that using a database. I think the design is quite good so far. – ralfiii Apr 19 '19 at 11:01
  • @ralfiii I don't see how what you've described is incompatible with a suitable database model. – J... Apr 19 '19 at 12:52
  • The databases I know are not performant in storing big blobs. What do you suggest, what would be a proper database structure to store a multi-day video stream and have fast random access to every second of the stream? So you can quickly load data from day2 12:34:45 - 60 seconds long. And that without bloating the required disk space. – ralfiii Apr 21 '19 at 18:41
  • @ralfiii Segment it into 10-min pieces, store in DB. If you really like the filesystem approach, stow it behind a service application - keep the files on a restricted filesystem and write a service to provide the data on request. The service can manage independent authentication however you want and the files don't have to live anywhere where humans can go digging to find them. – J... Apr 22 '19 at 20:56

1 Answers1

2

Are there possibilities to authenticate only a process or a thread and not the current user for access to a network share?

No. Windows' security model is based on users, not applications. To apply rights on a per-process basis, you would have to run the application as a given user. To apply rights on a per-thread basis, you would have to impersonate a given user before doing the work, and then revert the impersonation when finished.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • 1
    The closest to per-program security is a service. Since Vista, services can be configured to use virtual service accounts, where the name is of the form "NT Service\" and the associated SID name is automatically derived from the service name. This virtual account can be used to secure objects. – Eryk Sun Apr 18 '19 at 22:56
  • @eryksun Thanks! I didn't know about that. Though, [according to MSDN](https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts#bkmk-virtualserviceaccounts), "*Virtual accounts were introduced in Windows Server 2008 R2 and Windows 7*" – Remy Lebeau Apr 18 '19 at 23:46
  • OK, that sounds promising. For communication between the service and the application I'd use a normal TCP/IP connection, or are there other means like named pipes or so you'd recommend? – ralfiii Apr 19 '19 at 11:20