Securly transferring data from server to external database - sql

Reason: We have a new client that wishes for the database containing all their info to be stored on their own personal database server. However the web server will be located at another location.
Question How can you secure the data from the time it is inputed until the time an external database saves it?
Through some reading it seems that SSL will only cover so much and that some sort of a secure connection must be set up between the two. Or does the SSL cover this connection as well? It somewhat seems that it should.

SSL provides a reasonable solution to transport security (keeping the data safe from prying eyes as it goes over the wire).
Lock down the endpoints between the two systems as far as practical. For example, in addition to encryption, our firewall blocks physical access to the database except from well-known IP addresses.
You still need to ensure that your web server is secure (since the data is available unencrypted there), and that their database server is secure (including encryption of sensitive data when stored in database tables).

Related

Password protect sql database backups in maintenance plan

I have a microsoft sql server database (2012) and its currently being backed up using maintenance plans. I have a full back up, differential back up and transaction logs backup in my plan. For security reason i would like to add password protection on these files. Is there any way to achieve this within my maintenance plan? Thanks in advance.
I found this link and it will work for me (for now at least).
https://msdn.microsoft.com/en-us/library/bb934049.aspx
The following is from Microsoft Website
Transparent Data Encryption (TDE)
Transparent Data Encryption (TDE) encrypts SQL Server and Azure SQL
Database data files, known as encrypting data at rest. You can take
several precautions to help secure the database such as designing a
secure system, encrypting confidential assets, and building a firewall
around the database servers. However, in a scenario where the physical
media (such as drives or backup tapes) are stolen, a malicious party
can just restore or attach the database and browse the data. One
solution is to encrypt the sensitive data in the database and protect
the keys that are used to encrypt the data with a certificate. This
prevents anyone without the keys from using the data, but this kind of
protection must be planned in advance.
TDE performs real-time I/O encryption and decryption of the data and
log files. The encryption uses a database encryption key (DEK), which
is stored in the database boot record for availability during
recovery. The DEK is a symmetric key secured by using a certificate
stored in the master database of the server or an asymmetric key
protected by an EKM module. TDE protects data "at rest", meaning the
data and log files. It provides the ability to comply with many laws,
regulations, and guidelines established in various industries. This
enables software developers to encrypt data by using AES and 3DES
encryption algorithms without changing existing applications.

Storing an X509 Certificate in a MySQL Database

We're working on a TCP server that secures its communication with its clients using TLS/SSL.
Currently we are storing our public (.cer file) and private (password protected, private key included .p12) certificates in the Windows certificate store. We are going to increase the number of TCP servers soon and depending on the traffic we'll be adding more and more in time.
To facilitate the deployment process and periodic certificate change (or in case we detect some sort of intrusion) we plan to store both (private and public) certificates in the system's common MySQL database that is accessible by the TCP servers.
Is storing the .cer and password protected .p12 files in BLOB columns a bad idea from a security point of view?
P.S: I don't think it is very relevant but the TCP server is being developed in c#.
Skipping the security concerns, your language is PKE with native support for the windows store, you are going to have to roll your own (increase complexity) with this change. It would be better as part of the server start to update the Windows Store.
From a security point of view, you now have additional points where the encrypted key are accessible. Is you password secure enough? This is not a best practice and should be managed by the systems admin doing the install and updates. Lastly, this increase of complexity also increase the attack surface.

WCF SSL secure transfer or large payloads without changing firewall

I need to transfer small amounts of data intermittently from clients to our server in a secure fashion and pull down large binary files from the server ocassionally. It's important for all this to be reliable. I'm anticipating 100,000 clients. I control both ends, but I want to deliver a solution that doesn't require changing the firewall for the majority of customers. A lag of one or two minutes before the information migrates to the server or comes down seems to be acceptable at this time.
We need to make the connection secure, so was thinking about SSL, but open to suggestions. Basically, what is the best binding to use in this situation so that we have a secure transmission and the system handles the stress and load in a way that works for 95% of clients out of the box (firewalls will not block in majority of firewall configurations).
Firewall: you can port sharing to some well known port, or add yourself to exception list if client is using windows firewall
Using self signed certificate on net.tcp binding using transport security would be ideal.

Hosting SQL at remote location?

My OSCommerce site includes a separately programmed feature for which I use SQL tables. I've decided to host its tables on a remote site offering free SQL accounts. I'd like to know if there could be any disadvantages to this approach.
Thanks
Syd
Disadvantages might include the longer time it will take to run the script since it has to make a connection over the network and the need to make sure that the database connection is made securely -- that the password for the database login isn't passed in clear text & that the permissions on the receiving end of the connection are set to allow connections from only that IP. Of course you'll also want to make sure that the free hosting company provides adequate security for the database itself -- "free" doesn't alway pay for the best set up or the most knowledgeable technicians...
You should connect to your MySQL database using MySQL's built-in SSL ability. This insures that all data transfered is highly protected. You should create self-signed x509 certificates and hard code them. This is free, and you don't need a CA like Verisign for this. If there is a certificate exception then there is a MITM and thus this stops you from spilling the password.
Another option is a VPN, and this is better suited if you have multiple daemons that require secure point to point connections.
I am assuming you are hosting the OSCommerce database on the same server as the webserver and your solution only allocates one database per customer. You can use the add-on tables in the same database as the regular OSCommerce tables as long as you prefix them with some prefix so that they won't have a namespace conflicts. If the code to the third party solution is any good, it won't be too hard to configure a table prefix so that the code will know what the new names for the tables are. This solves any potential latency problem and keeps the control in your hands. I use this trick to host multiple wordpress blogs in the same database.

Best Practices for storing passwords in Windows Azure

For those in the know, what recommendations do you have for storing passwords in Windows Azure configuration file (which is accessed via RoleManager)? It's important that:
1) Developers should be able to connect to all production databases while testing on their own local box, which means using the same configuration file,
2) Being Developers need the same configuration file (or very similar) as what is deployed, passwords should not be legible.
I understand that even if passwords in the configuration were not legible Developers can still debug/watch to grab the connection strings, and while this is not desirable it is at least acceptable. What is not acceptable is people being able to read these files and grab connection strings (or other locations that require passwords).
Best recommendations?
Thanks,
Aaron
Hum, devs are not supposed to have access to production databases in the first place. That's inherently non-secure, no matter if it's on Azure or somewhere else. Performing live debugging against a production database is a risky business, as a simple mistake is likely to trash your whole production. Instead I would suggest to duplicate the production data (eventually as an overnight process), and let the devs work against a non-prod copy.
I think it may be solved partially by a kind of credentials storage service.
I mean a kind of service that do not need a passwords, but allows access only for machines and SSPI-authenticated users which are white-listed.
This service can be a simple WebAPI hosted under SSLed server, with simple principles like so:
0) secured pieces have a kind of ACL with IP whitelist, or machine name-based, or certificate-based whitelist per named resource, or mixed.
1) all changes to stored data are made only via RDP access or SSH to the server hosting the service.
2) the secured pieces of information are accessed only via SSL and this API is read-only.
3) client must pre-confirm own permissons and obtain a temporary token with a call to api like
https://s.product.com/
3) client must provide a certificate and machine identity must match with the logical whitelist data for resource on each call.
4) requesting of data looks like so:
Url: https://s.product.com/resource-name
Header: X-Ticket: value obtained at step 3, until it expire,
Certificate: same certificate as it used for step 3.
So, instead of username and password, it is possible it store alias for such secured resource in connection string, and in code this alias is replaced by real username-password, obtained from step 4, in a Sql connection factory. Alias can be specified as username in special format like obscured#s.product.com/product1/dev/resource-name
Dev and prod instances can have different credentials aliases, like product1.dev/resource1 and product1/staging/resource1 and so on.
So, only by debugging prod server, sniffing its traffic, or by embedding a logging - emailing code at compilation time it is possible to know production credentials for actual secured resource.