We have a couple of Azure Elastic database pool with hundreds of databases. Now we want to enable the Transparent Data Encryption feature. It is not a server or a pool setting, but a database setting.
It would cost me a day clicking in the portal to enable the TDE for all individual databases. Is there a smarter way of doing this? Scripting or multi selecting, or something like that?
Thank you for any help!
All newly created SQL databases are encrypted by default using service-managed TDE. Existing databases before May 2017 and databases created through restore, geo-replication, and database copy are not encrypted by default. For more information, please read this documentation.
You can create an elastic job to perform an ALTER DATABASE SET ENCRYPTION OFF for all databases on a pool. Read more about it here.
i want to encrypt the database file before deattach it to move it to another sql server and decrypt the database file on the other sql server
Try protecting your archive instead of DB cypher mechanics. File-protectors are much more mature today. Usually, simple 7z-archive with a password on it is a quite fine precaution to sleep well in the middle of your DB migration.
You can encapsulate 7zip LZMA into your code like here for C#.
I advice you a highly available solution concerning that we discuss a small businees solution. For Enterprise business, it's all different completely.
The other option is using native SQL Server Encryption. Then you should follow the genuine manual here
CREATE MASTER KEY ENCRYPTION and etc...
I m bit new to this field of DBA i wanted to know is there any codes available to encrypt the entire database as we have a huge database maintained in sqlserver 2005 .
I know that it is not safe to encrypt the entire database but we ha such kind of requirement moreover the in the application end they don't want to encrypt it.
i want the process to be as the data comes through the application end into the database it should be encrypted and stored and while retrieving the data it must be decrypted with a certificate/key as provided and shown. I don't want to use any 3rd party tools as it has been instructed.
i searched through the net and found that we can encrypt columns and stored procedure through asymmetric/symmetric key but i need to encrypt the entire database(selected tables is also ok) can you all help me in that.
I don't think there is an easy way to do it in 2005, you would need to redefine all (or most) of your tables to take encrypted data (varbinary) and then you'd lose the ability to do searches and comparisions and a whole heap of other stuff.
For 2008 there is Transparent Data(base) Encryption, which encrypts at the file level (when SQL server writes data) no changes required to your applications.
Search for SQL Server TDE and have a look around.
We've started using SQL Server 2005 Express for a project and I noticed that every database has it's own MDF/LDF files. Whenever we need to duplicate our database (to another SQL Server) we simply copy these files and then attach them to the database.
However, this has me wondering about the security of these files. If somebody from the outside gets a copy of them are they encrypted or can they simply attach to them like I'm doing? I'm not prompted for any passwords when I copy/attach them myself so I'm a bit nervous.
Thanks,
John
They are not encrypted and can be loaded/attached by any person with read access to the MDF/LDF files.
There are a couple of approaches you can take if the actual MDF files need to be protected. (This assumes that merely using file permissions to lock down access isn't feasible, for example if you need to protect against users with Administrative rights to the machine or direct HDD access.)
Use EFS or BitLocker or similar to encrypt the files themselves. This won't protect against other applications in the same session/context accessing the files, but it will protect against other accounts accessing the files (EFS) or someone stealing a laptop/hard drive (EFS/BitLocker).
Encrypt the sensitive data within the database itself. You will obviously want to store the encryption key separately (possibly using DPAPI to protect it, for example). SQL Server 2008 Enterprise Edition introduces a feature called Transparent Database Encryption (TDE) to make this process easier, which obviously doesn't help much for 2005 or Express Edition, unfortunately. Your best option in this case might be to do custom encryption of sensitive data in your app. (Unfortunately in 2005 this will require either using varbinary fields or Base64-encoding encrypted values etc.)
Don't store the data locally in the first place (i.e. use a remote SQL Server rather than a local Express instance). That doesn't truly solve the problem, but it reduces it (you only need to protect the remote instance rather than N local/express copies).
We have a common problem of moving our development SQL 2005 database onto shared web servers at website hosting companies.
Ideally we would like a system that transfers the database structure and data as an exact replica.
This would be commonly achieved by restoring a backup. But because they are shared SQL servers, we cannot restore backups – we are not given access to the actual machine.
We could generate a script to create the database structure, but then we could not do a data transfer through the menu item Tasks/Import Data because we might violate foreign key constraints as tables are imported in an order the conflicts with the database schema. Also, indexes might not be replicated if they are set to auto generate.
Thus we are left with a messy operation:
Create a script in SQL 2005 that generates the database in SQL 2000 format.
Run the script to create a SQL 2000 database in SQL 2000.
Create a script in SQL 2000 that generates the database structure WITHOUT indexes and foreign keys.
Run this script on the production server. You now have a database structure to upload data to.
Use SQL 2005 to transfer the data to the production server with Tasks/Import data.
Use SQL 2000 to generate a script that creates the database with indexes and keys.
Copy the commands that generate the indexes and foreign keys only. These are located after the table creation commands. Note: In SQL 2005, the indexes and foreign keys are generated as one and cannot be easily separated.
Run this script on the production database.
Voila! The database is uploaded with all data and keys/constraints in place. What a messy and error prone system.
Is there something better?
Scott Gu had written few posts on this topic :
SQL Server Database Publishing Toolkit for Web Hosting
Generation scripts are fine for creating the database objects, but not for transporting database information. For example, client-specific databases where the developer is required to pre-populate some data.
One of the issues I've run into with this is the new MAX types in SQL Server 2005+. (nvarchar(max), varchar(max), etc.) Of course, this is worse when you are actually using Sql Server Express, which doesn't allow for exporting other than creating your own scripts to create the data.
I would recommend switching to a hosting company that allows you to have the ability to FTP backup files and does NOT require you to use your own scripts. That's the whole point of SQL Server, right? To provide more tools that are friendlier to use. If the hosting company takes that away, you may as well move to MySql for its ease in dumping information.
WebHost4Life is a life saver in this category. They offer FTP to the database server to upload your backup file or MDF and LDF files for attachment! I was so upset when I saw GoDaddy had the similar restriction you mentioned. Their tool didn't tell me it was a bad import, and I couldn't figure out why my site was coming back with 500 errors.
One other note: I'm not sure which is considered more secure. I enabled external connections in GoDaddy and connected with Management Studio, and I was able to see every database on that server! I couldn't access them, but I now have that info. A double whammy is that GoDaddy requires that the user name for the DB be the same as the DB! now all you need to do is spam passwords against those hundreds of DBs!
Webhost4life, on the other hand, has only your specific database shown in Management Studio. And they let you pick your own DB name and user name, independent of each other. They only append the same unique id on the end of the user & db names in order to keep them from conflicting with others.
You should not rely on restoring backups for copying / transferring databases. You need to use scripts - trust me you will get better at it.
I have used the RedGate Compare tools with shared hosting and it works well.
Database-generation scripts are messy, but they also have several advantages that ... well, make the pain more tolerable.
First, if you treat the DB scripts as real programming tasks in and of themselves, you can encapsulate the messiness. If you generate a script once (using a database tool), you can split the table structure aspects from the constraint aspects (keys, indices, etc.). Similarly, you can export the data once, but split it it into "system" data that's not frequently changed but is necessary for correct operation (stuff like tax or shipping rates, etc.), 'test' data that's easily identifiable, and 'operational' data that needs to be moved from DB version Old to DB version New (last week's Orders).
The first 3 minutes after you've accomplished that, things are wonderful: you can regenerate a new database with or without test data in a few minutes. Unfortunately, after 3 minutes, the databases are out of synch, at least in terms of data, if not quite as frequently in terms of structure.
I personally like to have each table's structure as a separate SQL file (and it's constraints as a separate file in a separate directory, and it's test data in one file, it's system data in another, etc.). On the one hand, this means that several different files have to be touched when making a change, but on the other hand, it makes it much easier to see the granularity of what's been changed: it's all right there in the version control logs. (I could probably be convinced that many-files is a mistaken strategy...)
All of this is predicated on the assumption that you have some facility for actually running a complex script involving many files and are not just constrained to some Web-based control panel, which may be what you're describing when you say "we are not given access to the actual machine." I feel that you can't do custom software development and not have some kind of shell access on the server; the hosting business is competitive enough that you can certainly find a script-friendly host easily enough.
Check whether the webhsoting company provides myLittleBackup
This is definitively the easiest solution to "install" a db from the development server to the shared sql server
Answer for SQL Server 2008 users.
I had the same exact issue as OP but I was using SQL Server 2008 and my shared hosting company is GoDaddy. Here's the solution to copy DB + the data to GoDaddy database...
In Visual Studio 2010, go to Server Explorer (in VS Express, I think it's called database explorer). Right click on database and select Publish to Provider ... this opens the Database Publishing Wizard ... go thru the wizard and it'll create a xxx.sql file on your local computer ...
Open SQL Server Management Studio and connect to the GoDaddy database (you should have already created this via the GoDaddy control panel within their website) ...
Open windows explorer and find the xxx.sql file and double click it. The script should open up in SSMS. Execute the script "within the proper database" ... voila, done.