Innovation from the developer side
So, I’ve already fielded a half-dozen phone calls this morning configuring an IPSec VPN for one remote user.
One.
5 years ago, VPN was the greatest thing in the world, and I was happy to hammer on IKE configuration parameters all day, gleefully knowing I was providing a solution for my clients that no one else could.
Well, it’s 2008 now. IPSec is a drag. Even SSL VPN isn’t all that sexy anymore. Let’s face it: web technology has allowed secure, authenticated and encrypted communications since the late ’90s. Why I have to beat my h.a.t.w. (head against the wall) over IPSec at all seems draconian.
While there is still a need for site-to-site IPSec (namely, the ability to avoid telco low-monthly-extortion-fees for their “managed” VPN services) to interconnect physical site networks, VPN is a real bother for the teleworker. Not only do I now have to ensure that the remote endpoint is secure (it never is) but that I keep the VPN client software updated (it never is) across *all* the teleworkers. Oh, and I can no longer willy-nilly update my VPN concentrator firmware on schedule because some new “feature” will break half the old software VPN clients that are still reporting their version numbers in Roman numerals.
So, I aim this squarely at the development community: c’mon guys - learn just a little about TCP/IP, SSL, and code your application to not require 100MB chunks of data to traverse between client and server when someone resizes the client window.
Getting a remote client software to connect to the server “back end” should involve me pointing 443 on the firewall at HQ to the application server, and giving all the teleworkers the URL to the application, like “appserver1.company.com.”
Of course, that would mean optimizing transactions between client and server (which you should be doing anyway) and it means you’ll HAVE to learn something about infrastructure.
A few software companies get it. Some coders actually realize that eventually someone will buy their software and use it in the real world - absent from the original development laboratory where it was hastily complied on a machine running the database engine on which the entire application depends.
If you’re a coder - get with it. Learn what a TCP port is, dig into the SSL stack (or just buy a plugin that provides SSL integration for your IDE) and make the rest of the world a better place. Your client software should only need a URL (or IP address, give me that option). After that, give me an application/database server with an integrated CA (look it up) and the ability to publish client certificates. Now I can rest assured that only my clients will be able to establish communications with my server - and that all data transmissions are authenticated and encrypted. No VPN, no IPSec, no VPN client, just pure administrative bliss.
Oh, and in the name of everything that’s good and holy, stop being lazy and figure out how to use integrated OS security and authentication. Make the Herculean effort required to resist the temptation to build a username/password database into your application, thinking that your security somehow rivals that developed over millions-of-man-hours by a company with more money than most developing countries. You think Microsoft is insecure? Give me 30 seconds with your application and I’ll not only have your data tables, but I’ll have your personal SSN and credit card information.
Build me a set of Windows security groups that represent different parts of your application. All I’ll have to do is link other groups I already have, or just populate the ones you give me. That way, if I create a new account for our new accountant, Bob, I only do that ONCE, and he has network, email, wireless, AND rights to your application. Also, make your data files easy to move and your database engine easy to install. If you’re going to modify the schema in SQL, give me the script or build an installer that works - every - time. Then, let it be as easy as moving an MDF file, reattaching to a new instance or new server, and starting the service. Since your client is coded to only need a URL (Riiiiiiiiiiiiight?!) I can name my server whatever I want and give it what IP address I want. I can even put it behind a DMZ (where it belongs) because your application only needs that ONE, SSL-protected port to get data. Riiiiiiiiiiiiight?!