I have an MVC3 + EF 4.1 application, against a SQL Server 2008 database, with a requirement that the 'entire table is encrypted' for sensitive data. What are my options for implementing this?
NOTE: I am using the Repository Pattern, with DI swappable concrete repositories, so EF data access is not an absolute requirement here.
You might want to consider using Transparent Data Encryption. This encrypts the entire database and it much easier to use than cell level encryption.
MS SQL does not provide a table based encryption.
See http://msdn.microsoft.com/en-us/library/bb934049.aspx for more detail.
Related
I have a .NET Core 3.0 MVC website with Identity. The database is a Postgresql database (mainly because of better performance with geographic data). But since the only other person that can work with postgresql has quit, i have to migrate to SQL Server (because of internal policy).
But there isn't much information on the big web on this specific migration.
I got a few ideas but since setting up a test takes quite some time, I wanted to check here first.
Is it just a matter of copying all tables between the databases (Copy/export data - change connectionstring - people won't even notice the change)?
write a small script using entity framework, copying all users to the new database with a default password - users have to change password on first login
people have to re-register
a combination of the above
EDIT: the problem is not the tables and data types but my concern is the passwords and the hashes. Can I just copy all the values to the SQL database and can people just log in?
There is a password hash in the table and I was thinking it maybe used other variables like the database engine to create the hash.
If the application is build on the same stack, lets say in your case Dot net core with Aspnet Identity, then the hashes can be migrated with no issue at all. Everything is handled by dotnet and it is not bound to the underlying datastore.
Create the schema and populate it and you will be good to go. No need to rehash or make your users change their passwords. Just move the data
You will need to figure out which data types you are using in Postgresql and what their equivalents are on MSSQL. Most data types are same/similar while there might be a few where there is no direct equivalent.
There are lots of ways to move data between databases. One possible simple way in this case is to dump your postgres db using pg_dump. This will get you a text file with sql statements to recreate the database. Then you can modify the sql statements as necessary to work on your MSSQL database.
I have a SQL Server database in Azure that is accessed by a .NET app and by a NodeJS app. I just applied AlwaysEncrypted to a table column that contains sensitive information. I used Azure Key Vault to store the encryption key.
I was wondering if it is possible to display the (decrypted) data in my NodeJS app?
A workaround to this would be to expose the data that I want to query through an API endpoint in my .NET app, and then call that endpoint from my NodeJS app, but I'm looking for a more elegant way of doing it.
Based on my understanding, I think the more elegant way you said is that directly using JavaScript to decrypte data for column applied Always Encrypted.
I can't find any code for doing it directly. However, I think there are two ways which you can try.
According the offical document Using Always Encrypted with the JDBC Driver, you can try to use the node package node-java to bridge an API that using Java to query encrypted column data. Please node the content below.
Always Encrypted is supported only by Microsoft JDBC Driver 6.0 (Preview) or higher for SQL Server with SQL Server 2016 (Preview).
There is a document Always Encrypted Cryptography describes encryption algorithms and mechanisms to derive cryptographic material used in the Always Encrypted feature in SQL Server and Azure SQL Database. It seems that you can try to decrypt the encrypted data via perform the reverse process of data encryption algorithm with some node packages like crypto-js, bcrypt, etc.
Hope it helps.
My requirement is that we have an Application "FinApp" which handles all Finance Related data of the Company.Current Audit Team has asked us to Encrypt data on production to enhance security.
I already have knowledge about standard SQL encryption with keys and all. Also we created a CLR Based Function so that the enc. keys are in application server and passed while calling, so that the DB Team cannot access data as well.
The thing is when we will run this on Production with close to 10-12 crores records will this kind of SQL work? Already using function calls in select query is working slow if a CLR Based Function or for that matter SQL Encryption is used. Has anyone done it?
"select encrypt(columna), encrypt(columnb), encrypt(columnc), encrypt(columnd) from mytableofhughnumbers"
We are of the view that performance would be severely hit. What alternative do we have if the data is huge and encryption is required? Database is sql server 2005.
There is an article for this
http://www.kodyaz.com/articles/sql-server-2005-database-encryption-step-by-step.aspx
Our IT manager is asking my help on deciding on which would be the best to save the data. Is it in sharepoint or sql server.
On my side I don't know much about saving data on sharepoint server, how does it work, how fast, how secured, etc. I even have a doubt if sharepoint is capable of complex database design. As far as I know, sharepoint is not a database server that's why I have this doubts.
So obviously I would say Sql Server would be my prefered storage and also because Sql server is known to me for a long time already. Considering my 3 weeks exposure on sharepoint vs. 7 years on Sql Server. I don't have the enough experience to witness the strength of Sharepoint for me to decide on what to do. So to be fair on sharepoint I would like to ask you guys out there who are more experienced on this.
My questions:
1.) Does sharepoint have the ability to store data?
2.) If sharepoint can store data, what are the pros and cons?
3.) Can it cover a complex design such as relational database design like sql server does?
4.) If you where to develop a sharepoint project, would you choose sql server as the backend?
Thanks in advance!
It obviously depends on the application, and complexity of it, who the client or audience is, and how you want to deploy it.
Here are my answers to your questions:
1. Yes
2. Pros:
It provides a UI for updating data.
Cons:
Creating relational structures will be complicated.
Think custom lookup lists, associated with other custom lists.
3. Yes, but I wouldn't try it.
4. SQL Server, but this depends on the project and
isn't an entirely technical decision.
Personally, I think given your skillset, you should use SQL Server, if your manager has said it's up to you.
SharePoint itself is built on top SQL Server and ASP.NET.
Yes. You can create a custom list (basically similar to table structure), you can store document along with its metadata. You can store web pages if you are using it as your publishing (CMS) platform.
It's not supposed be a relational engine like SQL Server. Pro: versioning, workflow, for most cases, UI is there to support data input / editing. Con: Limitation of the UI w/ large amount of data.
To some degree you can relate one list to another field in a different list / document metadata.
See what I said before point 1.
SharePoint offers its own database layer built on top of SQL Server.
A complex object model is provided, and the SQL language API not available.
Acsess is by API, REST, and UI List Webparts with views; NOT SQL and the database is not accessible except through interfaces.
Deep inside data stored in Entity-Attribute-Value triples (specifically: site, web, list, item, state, field, value) such that each value goes into its own record. This is strickly non-tablular.
Maintains a dynamic end-user populated Metadata dictionary.
As a non-relational layer above a DB is offers inheritance, multi-type list, hierarchies, taxonomies, versioning, check in/out and other advanced features missing from a relational model.
Documents may be attached to a list.
Extensive use of GUIDS for identifiers, but this causes problems when moving partial related data between systems.
No referential integrity.
No joining of database tables or lists.
Filtering is more limited than in SQL.
No concept of a schema.
Parts of SharePoint break when restoring from a backup or when published to a separate site.
Rolling new features and data from development to production is problematic and sometimes breaks.
Hope this helps.
Sharepoint is obviously not a Database Server but somehow it works on some ways.
1.)Yes
2.)You can but not as complicated as Sql Server does.
Pros: It's the interfaces the gives sharepoint the edge, UI grants the user a friendlier way of inputting data.
Cons:Just like what I've said complicated database design is not easy to do.
3.) 100% Yes
4.) I would prefer Sharepoint if the application doesn't need complex design on data. Definitely Sql Server for enterprise type of application.
I don't want customers to be able to make backups of my sql server database and access the tables data etc.
I know there are some products that will encrypt the data in the tables, and their product will decrypt it when displaying in my application.
What products do you guys know of? What options do I have?
(This is a business requirement, however silly it might seem to some hehe).
Update
This is for sql server 2008 express
The problem with encrypting data inside the database is that as long as the database lives on the client's machine (as you indicated, they're running SQL 2008 Express, so I'm betting it lives on the client's desktops or laptops) then they can get into the data. They can set up security on the instance so that they have SA privileges, and from there, they can get the data, period. There's no way around that.
What you have to do is encrypt the data before it hits the database: encrypt it in your application. Inside the app, encrypt the data that you want to store in each sensitive field. As another poster indicated, you don't want to encrypt ID fields because those are used for indexing.
There is the 3rd party xp_crypt. It's been around for years.
It's an extended stored proc (that is, DLL)
SQL Server 2008 supports database encryption natively. Check the documentation for Transparent Data Encryption (TDE).
You can encrypt stored procedures, which can protect your logic.
TDE is available only Enterprise edition.
I can't find if it supports native sql encryption - but you could find this out with a little searching. But if it did you could probably set the database master key with your application and keep all of the decryption/encryption code in your application.
If it doesn't support native encryption, you might want to creat/find your own encryption functions in your application language and lock away the keys in your code.
Transparent Data Encryption will encrypt the database on disk, but is unencrypted in memory, so appropriate security would also be necessary to ensure unauthorised users cannot access the table. As it's an Enterprise-only feature, you can safely move away from it.
SQL Server 2005 and above have built-in encryption features - have a look at Books Online, and especially Chapter 5 - Encryption of Adam Machanic's Expert SQL Server 2005 Development book (technically, Lara Rubbelke wrote chapter 5 though).
Note that you'll only want to encrypt some columns - those that you'll never try to look up, as encrypted columns are pretty much useless for indexing. Adam Machanic's book suggests ways to solve this problem.
Another solution for transparent SQL Server encryption is DbDefence
Free for databases less than 77 MBs.