If you're offering your app via an RDP-based technology then you're pretty well protected. The EXE is never copied to or executed on the remote endpoints (unlike a conventional LAN-based app). Authorized users should be locked down and have only the minimum privileges needed to access your app, and no direct rights to the file system on your server(s).

Still, it's possible your cloud server(s) could be compromised via a vulnerability in a standard account, or if the credentials you use to manage your server(s) get compromised. Or maybe via unauthorized access to backups of your server(s). In that case it might be handy to have some sort of key. I don't know if a hardware key would even be possible, cloud servers are heavily virtualized and individual VMs can get migrated from one physical server to another. I think the only way you could use a hardware key would be with a dedicated hardware server of your own, which would likely be more expensive and less reliable than a full cloud offering.

It might be worth asking cloud providers what they can do about this. You may find you'd have to do something like make a call to a web service on a separate web server that you control, and only let the program run if you get an "authorized" response.

>Thanks Dmitri, Brandon, Al and Jos for the friendly questioning and comments.
>
>I guess I'm most afraid of someone somehow getting hold of the exe and running it freely. But there are other ways to prevent it that, of course, like in that case requiring a hardware key.
>
>Have a good weekend,
>
>Alex
>
>>>We are preparing to offer access to our vfp desktop app as a remote app hosted in a server in the cloud.
>>>
>>>With the desktop app we use a hardware key to defend against piracy, which would not work in the cloud.
>>>
>>>The first line of defense in the cloud is that we create users on the server, but we would like to be able to limit access to the application to authorized PCs only. Is there a way that our program, while running in a terminal server session, can find out information about the PC that connected to that session? Things such as CPU number, motherboard number, etc.?
>>
>>I agree with Brandon, in general you wouldn't want to limit access to particular machines.
>>
>>That said, it's a good idea to be more security-conscious if you're cloud-based. One major concern is remote endpoints getting compromised with malware. These often include keyloggers, so logon credentials for your app could end up in the wrong hands. And since your app is cloud-based it could theoretically then be accessed from wherever the miscreant happens to be. The greater the number of endpoints that can access your app, the greater the chance of compromise.
>>
>>One way to mitigate that is to use two-factor authentication. In addition to user name/password, the user also needs something like a fingerprint (reader), smartcard etc.
>>
>>In any case you may want a clause in your service agreement such that the customer is responsible for ensuring that machines that access your service are free of malware, and that you are not responsible for any losses due to infection of a user endpoint.
>>
>>Using a Virtual Private Network (VPN) for access to your app can also be helpful. Users would first have to connect to your cloud server via VPN (with a different user name/password) before accessing your app via RemoteApp, RDP etc. This means that only authorized users can even connect to your service, rather than any hacker world-wide. Some VPN clients let you store user names and passwords and connect just with a click or double-click, so the user doesn't have to type those in, and they don't get harvested by keyloggers. In a way this is a sort of two-factor authentication.
>>
>>If you want to limit access to certain remote sites (e.g. for those companies that tend to work from fixed offices) then a VPN may help you there as well. Some VPN servers let you define a list of remote IP addresses that are allowed to connect. Computers at other IP addresses can't get in, even if they happen to have a valid VPN user name and password.
>>
>>If there are many users at a fixed office site (say, more than 3 or 4) you could also consider setting up a dedicated site-to-site VPN connection. That way, anyone at the office could connect to your app without having to go through the initial VPN connection step. This would also reduce the proliferation of separate VPN connections at your server side (some VPN servers are licensed by the number of simultaneous connections they will support).
>>
>>For added security you could consider limiting time-of-day access to VPN and/or your app itself. You could define "normal business hours" and allow access only during those times. This could apply to all users, or you could set certain users to be exempt from those restrictions.
>>
>>These days users like to be mobile, working from many locations and at all hours of the day or night. If your customers have salespeople traveling worldwide then you may not be able to apply many of these measures, but I'd still give serious thought to using VPN as an added layer of protection, and maybe some other two-factor authentication measure as well.
>>
>>On the other hand, if your customers tend to work from fixed office locations then you can use some of the measures above to help lock things down.