Apparently, my post on Distributed Data Security is getting some attention from Ian Griffiths and John Lam, two people I very much respect. I asked for feedback, and now I am getting some.
I feel it is time for further clarification. When I wrote that piece I had in mind some of the questions others had asked about the use of Enterprise Services, the lack of good material on distributed .Net computing, and what security has to do (if at all) with distributed computing. I also had in mind work with distributed computing which uses Oracle, Enterprise Services, and ASP.NET for a high transactional, distributed database application. Of course, I also had in mind other thoughts regarding what was (in the unmanaged world) versus what is (in the managed world) as I am working between the two as well.
Ian mentioned use of integrated security with SQL Server, and that is a good strategy. But, if not done correctly, you could kill your connection pooling. Also, I work with Oracle, and can not use integrated security, so I do have to store credentials somewhere. Oracle also forces you to install most of the client tools by default (like SQLPlus) and keep database instance names in open files like tnsnames.ora. For me, that's unacceptable from a security viewpoint. There are ways around these issues, of course, but there are business requirements and restrictions that can come into play as well. Not all is black and white.
A point I would like to make regarding my own article is that I mentioned the importance of evaluating your own architecture and business requirements:
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.
This is key. The aim of my article, originally, was to point to various data security options, and for the reader to make some choices based on what is available, what was previously required (in some cases, there is still a lot of legacy code out there that won't go away for some time), and what is available. All of these options, of course, work with other options and choices, as I mentioned:
When dealing with distributed computing, there are many design considerations for your architecture regarding scalability, throughput, performance, physical deployment, security and technologies to choose.
Nothing should be done in isolation. And, realistically, it never is.
Both Ian and John point to my statements that you “should” use separate boxes for increased security (in particular, “security in depth”). Again, I would like to clarify that my intention was to offer alternatives IF the requirements force you to have that kind of environment (as Ian mentioned in his post regarding a possible need for two boxes when you have distributed databases involved). I would like to restate again, and make it clearer, that my intention was to point to the security options available if you do have the architecture with two or more boxes.
A bigger question, I believe, in regards to security in depth using layers, is do you make those layers logical or physical? Of course, you code logical layers (in most cases) as that is a good design. John correctly points to simplicity in security, and I agree. Separating layers physically does bring a lot more complexity, as seen by my article. I apologize for implying security by physical separation is an “end-all“ solution. You always have to weigh all your options and determine what works best for your situation.
Think about your options, try to keep it simple, but alway keep security in mind when working with your architecture designs.
