Is SQL Server safe?
I have been using SQL Server ever since I learned how databases work. Transferring an Access database to MS SQL was my first big project in EnGraph . Over the years I have learned not so much and was taken by surprise by a client's question - is SQL Server safe or not? Specifically, customers were interested in our ParaPlan Cloud product, which we placed using Amazon EC2, and were concerned about the opening of port 1433.
I was partially taken by surprise, because my thought process was something like this: “Of course, SQL Server is safe! How silly it is to ask about it! ”But after working with SQL Server for more than a dozen years, I could not satisfactorily answer their question. We have built a whole company on the use of this product and therefore, perhaps, we should understand how its security works. So I told them that I would do additional research and return with the results.
Here is what I found after several hours of research:
')
Login / password transfer transactions are always encrypted ( MSDN ):
The credentials (in the login package) that are sent when the client application connects to SQL Server are always encrypted. SQL Server will use the certificate of the trusted root certification authority, if it has one. If a trusted certificate is not installed, SQL Server will generate a self-signed certificate when the instance is started and will encrypt the credentials with it.
(Further added by me - a comment of the translator )
This self-signed certificate improves security, but does not provide protection against server imitation of identity. If a self-signed certificate is used, and the ForceEncryption parameter is set to Yes, then using this self-signed certificate all data transmitted over the network between SQL Server and the client application will be encrypted.
You can perform additional encryption of the database / tables / columns, but at the expense of performance ( Pinal Dave ):
Encryption is a very important security feature in SQL Server 2005. Long and asymmetric keys create impenetrable, strong encryption, which, in turn, heavily loads the processor to encrypt data. The more secure the encryption, the slower the process. If you need to encrypt a large amount of data, a symmetric key is assumed. The same symmetric key itself can be encrypted with an asymmetric key in order to provide additional protection, which will lead to the benefits of more reliable encryption. It is also recommended to compress data before encrypting, because encrypted data cannot be compressed.
If you want to continue to control access to SQL, you can block all outgoing traffic on port 1433, restricting access to it to specified servers. This is how it can be done with Cisco .
Now I know much more about SQL Server security and I feel more confident in offering this information to clients. It will help them decide whether to continue working with the product hosted in our storage or with the product hosted by EnGraph.
Translator's epilogue
It is not my business to evaluate, but how such a level notes get on the Code Project newsletter is astonished. On the other hand, having started to translate something, I don’t like to throw halfway through. Maybe someone will come in handy.
I was partially taken by surprise, because my thought process was something like this: “Of course, SQL Server is safe! How silly it is to ask about it! ”But after working with SQL Server for more than a dozen years, I could not satisfactorily answer their question. We have built a whole company on the use of this product and therefore, perhaps, we should understand how its security works. So I told them that I would do additional research and return with the results.
Here is what I found after several hours of research:
')
Login / password transfer transactions are always encrypted ( MSDN ):
The credentials (in the login package) that are sent when the client application connects to SQL Server are always encrypted. SQL Server will use the certificate of the trusted root certification authority, if it has one. If a trusted certificate is not installed, SQL Server will generate a self-signed certificate when the instance is started and will encrypt the credentials with it.
(Further added by me - a comment of the translator )
This self-signed certificate improves security, but does not provide protection against server imitation of identity. If a self-signed certificate is used, and the ForceEncryption parameter is set to Yes, then using this self-signed certificate all data transmitted over the network between SQL Server and the client application will be encrypted.
You can perform additional encryption of the database / tables / columns, but at the expense of performance ( Pinal Dave ):
Encryption is a very important security feature in SQL Server 2005. Long and asymmetric keys create impenetrable, strong encryption, which, in turn, heavily loads the processor to encrypt data. The more secure the encryption, the slower the process. If you need to encrypt a large amount of data, a symmetric key is assumed. The same symmetric key itself can be encrypted with an asymmetric key in order to provide additional protection, which will lead to the benefits of more reliable encryption. It is also recommended to compress data before encrypting, because encrypted data cannot be compressed.
If you want to continue to control access to SQL, you can block all outgoing traffic on port 1433, restricting access to it to specified servers. This is how it can be done with Cisco .
Now I know much more about SQL Server security and I feel more confident in offering this information to clients. It will help them decide whether to continue working with the product hosted in our storage or with the product hosted by EnGraph.
Translator's epilogue
It is not my business to evaluate, but how such a level notes get on the Code Project newsletter is astonished. On the other hand, having started to translate something, I don’t like to throw halfway through. Maybe someone will come in handy.
Source: https://habr.com/ru/post/141392/
All Articles