We're considering to enable our >10 suppliers (mainly from China) to input/edit/view data via an unified interface. The preferred way is to use the same windows-based .NET/MSSQL application as used internally.
As the application needs a direct database connection, my idea is to grant all suppliers access to a server at our site via terminal services. But there are concerns about the security of this approach, so that the current plan is to develop a web interface to the application (costly) or continue to use excel/txt/word/pdf for data submission (well...).
In deep detail, my approach would consist of:
external server
Windows Server 2003, SQL Server 2005, the application
windows update set on auto
Terminals Services, granted to individual users
directly start application (group policy), auto log-off after termination
adjust file system ACLs to prevent:
- any file writes (except e.g. profile files)
- execution of taskmgr, cmd, ftp, telnet, (explorer.exe?)
registry ACLs should be ok
change RDP port
firewalled appropriately
auditing enabled (group policy), report events via e-mail to admins:
- execution of cmd, taskmgr, etc. (all users, including system/admin/...)
- change of security permissions
internal server
- connected via crossover ethernet
completely firewalled (inbound)
synchronize every 5 minutes:
- open LAN interface
- synchronize files via network share
- synchronize database via SQL Server replication (some tables inbound, many outbound)
- close LAN interface
backup and history backups (as the external server has the master copy of the applications database)
As I use a similar approach in my department (web- instead of terminal services), I have no objections to the setup. The only practicable attack I'm concerned with, is a breach of in the application itself, which could lead to a compromise of application specific data (over all suppliers).
Nevertheless, as I have to convince a bunch of people favouring the excel approach, I'd like to hear your thoughts.
Many thanks.
It's unfortunate that you're on Server 2003, as Server 2008's RemoteApp features would serve you brilliantly in this scenario. However, what you've got there should pretty much cover it from a security standpoint.
We used to have a TS with un-trusted users on it and the setup was similar. Using GPO we locked down the accounts to remove everything - their start menu only had "log off", everything in the Windows Security screen was disabled (except Change Password and Log Off), if they were able to wrangle up a browse screen, access to every local disk was disabled, and they were members of a restricted group that actually had deny access on network resources. Hell we even disabled the ability to right-click on their desktop. We disabled the ability to map client devices over terminal services as well, along with the command prompt, everything.
Basically we went through a GPO and disabled every single feature of the UI we could discover. We did have trouble disabling explorer though, but if you can enforce a single program launch on startup, feel free to disable that too.
A couple of things you may not have thought of:
Actually, if you can, I would strongly suggest moving to 2008 R2 if at all possible, as it's got even more security features for terminal services (or RDS as it's now called)