One of the most basic implementations is securing a column of data with a symmetric key. SQL Server has built-in security measures that are robust, configurable, and offer multiple layers of security. Sometimes that level of security is warranted and sometimes it is not. Adding highly secure encryption to every aspect and byte of data in a database can be done, but it results in a correspondingly high amount of time and resources (CPU processing, etc.) to interface with the database with authorized credentials. Of course, the balance is the cost and, in the case of databases, the performance overhead. Bottom line: no security system is without weakness, but the more measures you have in place the more it deters and prevents would-be attackers, hence the more secure it is. However, even with all of that in place, all it takes is someone with two keys, the security system code, and enough force to overpower your armed guard and then your house is compromised. Think of securing your house: first you install doors, then you add a lock and key, then you might add a second lock with a second key, then a security system, then a guard, then an armed guard, and so on until you are satisfied with the security measures. The goal is simply to make it sufficiently difficult to extract sensitive information so as to deter intrusion or delay it long enough to detect and actively counter it. Database security is like security in general: every step you take offers a degree of protection, but no single step nor combination of steps can ever offer “complete” or “guaranteed” security.
0 Comments
Leave a Reply. |