I need to set up a training database on Azure that will allow all users to run Select statements (nothing else, it will be read-only).
Multiple users would all be logging in as the same read-only login, and creating/running select statements via SSMS or some other tool.
Any caveats to doing this? I'm planning on opening up the firewall and allowing all IP addresses to access it.
You can use the AdventureWorkLT database that you can install from Azure portal as shown here.
Take in consideration that Basic tier only allows 300 sessions and 30 concurrent logins. You may have to use Standard tiers depending on the number of sessions expected. Please visit this documentation for more information about limits of Azure SQL tiers.
Related
I am developing a Winforms application (in VS2017 - VB.net) which connects to a Microsoft Azure SQL database by SQL authentication (connection string builder). The plan is to set up a new SQL database for each new customer as it is easier to manage (backups, deleting DB should the customer leave etc). The customer would be set up as a contained user on their database and would be the only one logging onto that database. I will be the only one managing the overview SQL server.
Should the customer be set up in Active Directory instead of sales authentication? I read it is more secure, but not sure if this option is best for my application. There could be many different operating systems, locations, customer domain settings etc. that I would not know in advance. Ideally, my application is generic and each customer would enter in their credentials to connect to their database.
Stay using SQL Authentication, because Azure SQL Authentication is intended for single tenant applications (applications intended to use for a single organization) or for software-as-a-service applications.
In your scenario you can make use of Elastic Pools where you can apply schema changes and upgrade your database with just one elastic job, if all your customer will use the same database schema. This should reduce time and effort of having to deal with many versions of databases for your customers, and having more personnel providing support to the many versions of databases and applications to your customers. Elastic pools only support SQL Authentication.
I understand there is a Domino ini setting for turning off all FT-indexing for an entire server. But is there any way to do this for only some databases on the sever, possibly on a per folder basis?
A fulltext can only be created by a user with manager access to the database.
In a well configured environment NO USER needs manager access to ANY database.
Even administrators don't need that (as there is Full Administration Mode).
So: Give users editor to the databases, manage access to databases with groups (user managed groups if you want), and then decide which databases to index.
In the end give the rules about which databases should have an index to the admins...
I have to execute some queries in Firebird, but I need to hide "query source" from viewing in mon$statements or any other log in database.
That's because the query has some business rules that I can't expose to other people.
Is there any way to do it? Or some "trick" that I can use?
There is no way to do this. However MON$STATEMENT only shows your own queries, unless you are SYSDBA, the owner of the database, or a user with the RDB$ADMIN role (then you can see all queries). Other then MON$STATEMENT, there is also the trace facility which allows people with sufficient access to see queries (either on the server or through the service api). People with insufficient access to the database can still see queries if they can see the network traffic between the application and the database server.
The only way is to not give any form of access to the database server to people who should not be able to see the queries. This can be done by hosting the application as a webapplication, or putting a webservice or other form of middleware between the database and the real application.
I'm trying to get some advice on how to approach a security architecture on Azure.
Background:
We are looking at building a multi-tenant app on Azure that needs to be extremely secure (personally sensitive data). The app will be accessed by standard browsers and mobile devices.
Security access types:
We have three types of users / access types...
1 - plain old user/password over https is fine, accessing both general, non private SQL plus hosted files
2 - user/pass over https, but need authentication of users via certificates that will be installed on user machines/devices. This level of user will need access to sensitive data which should be encrypted at rest both in database, and also any uploaded files.
3 - same as (2) but with the addition of some two factor authentication (we have used YubiKey for other things - might look towards a phone OTP offering as well)
Most users will only have access to their own tenant databases, however we have "account manager" type users that need access to selected tenant data, therefore we expect that they will need either a copy of one certificate per tenant they serve, or we will have to use some kind of master certificate.
Database type:
From a multi-tenant point of view it seems Azure Federated SQL is a good way to go because (a) we simply write one app with "TenentID" key in each table, and after login, set a global filter that handles the isolate for us (b) we understand that Azure federated SQL actually in the background maintains separate SQL database instances per tenant.(Ref: http://msmvps.com/blogs/nunogodinho/archive/2012/08/11/tips-amp-tricks-to-build-multi-tenant-databases-with-sql-databases.aspx)
Can anyone point to any links or give advice in relation to the approach needed to setup and manage file shares, encryption of SQL and file data at rest, authentication of users etc. (automated management on new user signup pref).
I can't really help on the certificates, but you will indeed need some "master certificate". If you are planning on using Azure website, you can't use your own certificates currently.
Concerning the database setup. SAAS applications build on trust, so you NEVER (EVER) want to be showing or editing the data of using to other users.
Therefore I strongly suggest that you don't use the TenantID for each table. This would leave still the possiblity of an attack by a malicious user or an error by some developer.
The only way to get around these risks are
extensive testing
physical different tables to store each tenant data.
Personally I believe that even with very extensive+automated testing you can't have 100% code coverage against malicious users. I guess I am not alone.
The only way out IMHO is physical different tables. Let's look at the options:
different server: valid, but pretty expensive in azure
different database: valid, less management overhead but same objection as the previous option - expensive if you have a lot of tenants
different schema's: the solution. Think about it...
you only have to manage users and there default schema's
you can back-up schema's using powershell
you can move schema's to other databases with some work
You can still digg into SQL federation if you need to.
the major drawback is that you will need to support database upgrades for each tenant.
Have you read on azure.com any articles about multi-tenancy? http://msdn.microsoft.com/en-us/library/windowsazure/hh689716.aspx
I want to install an application (ASP.Net + SQL server 2005 express) in local network of some small company for demoing it for a period of time, but I also want nobody even sysadmin have no permission on this database and any permission granting wants a secure pass that I have .
I just want my tables structure and relations and functions be hidden and encrypting the data have no advantage
I need to spend more time on this article Database Encryption in SQL Server 2008 Enterprise Edition that i found from this answer is-it-possible-to-password-protect-an-sql-server-database
but
1.I like to be sure and more clear on this because the other answer in this page says :
Yes. you can protect it from everyone
except the administrators of the
server.
2.if this is possible, the db have to be enterprise edition ?
3.is there any other possible solutions and workaround for this?
4.if I install a new instance with my own sa password , can i restrict other instances admins from attaching the mdf to their own ?
thanks in advance
These people can access your server or the SQL Server instance no matter what you do
anyone with physical access to the server
domain admins of the network
anyone with the sa password
a windows group with local admin and/or sa rights (which implies group policy etc)
You have to host your server offsite if you want no-one to get to log onto it.
It is that simple
In SQL Server, you cannot "password-protect" a database - what you can do is limit the permissions a given user or role has in your database.
You can DENY anyone access to your database - but that's a bit odd, since no one will be able to use it....
You can do all sorts of stuff to your database tables and logins - but a sysadmin will always be able to get around those things and get access to the database. As long as the sysadmin can get his hands physically on the server, I don't think there's any way to totally shut them out.
If you don't trust even your sysadmins, you have bigger problems.....
There's several different ways you could solve this problem.
Host it offsite - I think the easiest solution would just be to host it offsite. There's loads of cheap shared hosting out there which you could use.
Lock out the sysadmins from that server. Assuming you have root access and only you use/need that server you could change the root password and any other passwords on the server.
Do what you're currently doing and try to make something secure even when someone who shouldn't have access has root access to the server. This way sounds tricky and insecure even at best.
I have a contribution for (3):
I'm guessing (I might be wrong) you don't actually have sensitive information in your database, you just want to make it unfeasible for someone in the local network to use any of your stuff.
If that's the case, you could just make it harder for them to read your data by encrypting the data in the database and having your (compiled) code decrypt it before using it.
This way, any sysadmin who is just curious about the data or wants to change his hiscore to 13371337 will not want to go through the trouble of decompiling your code and/or cracking your encryption (for the duration of your demo) and your (assumed) problem will be solved.
I have no idea if this helps you at all, I guess I just want to say you might want to take a look at your problem again. Since you can't keep the sysadmins away from your stuff, you may want to take a different approach like making it less useful to them.
As discussed by the various other posters, you can't password protect a database - deny permissions - to the sysadmin. One alternative that hasn't been discussed is hosting it on a Laptop. Since this is a demo, you can host the Database and ASP.Net site on a laptop and hook that up to their Network - after Sysadmin permission of course - and have the clients test the application from your laptop.
This will allow you to protect the database from Sysadmins and provide the added benefit that if you want to allow them to see the database you can let them use your laptop and you will be there watching their actions on your database. This last benefit is something that you can't do easily with a hosted solution.
The above answers point 3. As for point 2, you will need the Enterprise Edition of SQL Server to take advantage of Transparent Data Encryption (TDE) as per the comparison link on MSDN. If you click on the Enterprise Security link at the top it will show a table explaining the different security capabilities of the different SQL Server versions and it shows that TDE is only for the Enterprise Edition.