In response to comments from Adrian Bateman, Tiago Pascoal, and others I would like to continue and elaborate on “Enterprise Distributed Computing in .NET”. Feedback is welcome.
--------
When dealing with distributed computing, there are many design considerations for your architecture regarding scalability, throughput, performance, physical deployment, security and technologies to choose. Of these, I am offering some ideas regarding data security, and in particular, distributed data security as it relates to current (and future) .Net technologies.
Local Data Storage and Security
If you develop an ASP.NET or Windows Forms application, typically, you use some kind of data store. That data store could be an XML file, a small MSDE database, or a full-blown database like SQL Server or Oracle. Depending on the nature of how sensitive the data is (i.e. if this data was obtained by someone else, would they be able to compromise your business?), you must make decisions regarding how to secure access to that data. You could decide to keep everything open because the data is read-only and doesn't contain information like passwords, credit card numbers, etc. But, read-only data should still be secured so the right people read it. And, of course, if the data DOES contain important “not for prying eyes” information, you definitely want some kind of secure access.
If you store your data with your application (on the same box), you must take precautions to make sure the data is both accessible to the application as well as secured from tampering. This may involve using ACLs to secure access to a file (i.e. XML or other file data) or running database services like SQL Server and Oracle with low-privileged users and well-defined access control to only needed stored procedures, tables, and views. You may also use encryption, one-way hashed passwords, and salt values to further secure internal data to make sure it’s not easily read by outside observers. Also, you should encrypt your connection string information as well in order to make it difficult for an outside observer to break into the database.
Remote Data Storage and Security
If you require further security for your data, you should host the data store away from the application and onto another box. Most applications have the ability to access remote data stores (i.e. SQL Server, Oracle, etc.) across the wire using standard network protocols. In .Net, you can use System.Data.SqlClient, System.Data.OracleClient, etc. to make your remote calls and things work nicely. Depending on your security requirements, this may be enough, and it is quite common.
One important issue with hosting databases locally or remotely and connecting to them from the local application is database connection information must be stored somewhere near the application, either in the registry, an XML configuration file, or (ugh) inside the code itself. As mentioned above, you should encrypt the information, but then you have to figure out the best way to store the encryption keys on the same box (I know with DPAPI you can go one step further and take advantage of user authentication so you remove the need to manage encryption keys, but this has some considerations as well).
Another step in further securing your data and what I advocate is to move the actual data access layer for the application onto another box in order to promote security in depth. By security in depth, I mean you introduce more secure layers that someone would have to “break through” in order to get at your data. By moving your data access to another box, you remove the need to store database configuration information on the local application box. Of course, when you host remote components on another box, you have to figure out how to access those components from the application. In .Net, there are (at the moment) a few well known methods: Remoting, Enterprise Services, and Web Services (you could also use sockets, but that is another topic).
.Net Remote Data Components and Security
Hosting remote components brings up another important issue. You have to make sure the communication between the two boxes is secure, because otherwise your data could be seen through a network listener. This is true if you access your remote database directly through the application – anything sent over the wire in clear text is available for prying eyes. In the rest of this article, I will detail some of the options available through the three .Net methods mentioned above for secure remote communications.
.Net Remoting
.Net Remoting is a good replacement for DCOM (from the unmanaged days, DCOM (Distributed COM) is a way to call remotely hosted COM components) as it provides a way to cross .Net AppDomains, whether on the same box or remotely to another box. Remoting is also extensible, unlike DCOM. The nice thing about DCOM, though, is security was built in using RPC encryption. Out of the box, Remoting doesn’t come with security built in, and you must either use SSL/ASP.NET security if you use an HttpChannel or IPSec if you use a TcpChannel. Though a TcpChannel provides better performance, you should only use this in a guaranteed secure network environment. Other alternatives are rolling your own authentication and authorization scheme, and there are examples on the internet for how to do this (like this one).
Enterprise Services is essentially a managed wrapper around the COMPlus services. If you need them,
For Server Applications, Enterprise Services combines and extends Remoting (as mentioned above) and uses COM Interop to make use of the DCOM services. For its raw performance and security (because of COMPlus/DCOM), it’s actually a good choice for secure remote communication. But, it has its drawbacks. As a result of COM Interop, you can have problems marshaling certain .Net types. Also, as a by-product of DCOM, you may have to open certain ports in your firewall to allow standard RPC/DCOM calls to go through (though, you can lock down the port range). Like Remoting, Enterprise Services should be used with local application (same box) or middle-tier components only, and not hosted across the internet. Again, consider Enterprise Services if you need some of the other services mentioned above and not only for secure remote communication.
Web Services
Web Services provides the ability to communicate remotely to another box that is sitting within your network or across the internet. For interoperability with other systems, it is the ideal choice as it has become (becoming?) the industry standard way of remote communication across different platforms. Using XML/SOAP as the message medium, you can make remote calls from your application. As far as security, you do have to make sure your message has some measure of encryption (in particular, the most sensitive parts). Typically, your Web Services calls are open text, but you can secure your calls using SSL (like Remoting when using an HttpChannel). Also, some extensions to Web Services like WSE (Web Services Extensions) and other initiatives (WS-Security) are providing ways to further secure communication using Web Services (WS-Security has already been implemented in WSE 2.0).
For the best ways to secure any of these methods, please look at these checklists (and related articles):
Checklist: Security Enterprise Services
Checklist: Security Web Services
Future: Indigo
I can’t do justice to my coverage of distributed data security without also mentioning the future of .Net called Indigo which takes the best of all three methods (Remoting, Enterprise Services, and Web Services) to provide remote communication services that include performance, security, transaction support, and a host of other service oriented architecture (SOA) benefits. This is the future, and one that is anticipated to help take us into the next phase of distributed computing.
Summary
In conclusion, you must decide how you want to secure your data. Consider all the options and requirements for your particular business and/or architecture, and weigh the advantages and disadvantages. Hopefully, though, I have presented a strong case to consider distributed data security when establishing the physical architecture and deployment of your project.
