I have a couple of scenarios I would like to play with and was wondering if anyone can help me.
I have a flutter app that relies on external data. It's not very sensitive data but if my project goes forward, it will have some company privileged info.
For testing purposes, I have a Google sheet as a database. I could have all people sign up for a Gmail account and then grant permissions to access that sheet.
What happens if my boss likes the idea though? We have a sql database that requires you to be attached to the local network or VPNed to it.
How can I securely pull data from that database without needlessly exposing us or revoke permissions if a user gets fired? Would everyone need their own login to the dB?
Related
I need to grant access to Big Query to 30 Phd Students in a University on Google Cloud Platform.
Can I give them standalone access to each of them? i.e. One student cannot see other's work unless it is granted.
Creating projects = number of students is not too cost effective.
so can I give 30 access controls to a single project ?
The students need to have full access to Big query (Create, edit, join, download, run) to their respective databases.
The document is indeed confusing. Don't grant any project-level permissions. Just as Katie Sinatra said, go to the dataset Web UI, in the arrow drop's "Share dataset", add email and grant "Can edit". At the time of this writing, after you do the above, the user won't be able to see the dataset in the Web UI, but s/he can still do query in the Web UI just fine if s/he specifies the table correctly, i.e. `project.dataset.table`. (i tested it.) The user can also manually add the dataset to be displayed in the web UI. Here is how to do it, https://cloud.google.com/bigquery/bigquery-web-ui#displayprojects.
What i am still confusing is: after you do the above, when the user do a query, who is paying. My guess is the user is paying. If you want the dataset's original owner (the project under which the dataset is created) to be billed, then my guess is that you need to grant project-level BigQuery Job User permission to the user/email in addition to the above. Then, the user will be able to select the project in the GCP console and hit "BigQuery" to go to the big query Web UI, and be billed under the project. (by the way, if you do this, the dataset can be seen by the user in the Web UI.)
As JL-HN said, it is documented but it is a bit confusing. To give access to an specific dataset, you only need to go the dataset, in the arrow drop it down and click on "Share dataset". Then you only need to add the email of the student that will handle that dataset.
Background:
Our team is building an inhouse Intranet web application. We are using a standard three layer approach. Presentation layer (mvc web app), Business layer and data access layer.
Sql database is used for persistence.
Web app / iis handles user authentication (windows authentication). Logging is done in business and data access layer.
Question service account vs user specific Sql accounts:
Use service / app account:
Dev team is proposing to set up service account (set up for application only). This service account needs write & read access to db.
Vs
Pass on user credentials to SQL
IT ops is saying that using a service account (specifically created for app only) for db access is not deemed best practice. Set up Kerberos delegation configured from the web server to the SQL server so that you can pass on the Windows credentials of the end users & create a database role that grants the appropriate data access levels for end users
What is the best practice for setting up accounts in sql where all request to db will come through the front end client (ie via bus layer and then data layer)
The Best Practice here is to let the person/team responsible for the database make the decision. It sounds like the dev team wants to forward (or impersonate) some credentials to the DB which I know that some small teams like doing, but yes that can leave things a bit too open. The app can do whatever it likes to the database, which is not much of a separation if you're into that kind of thing.
Personally, if I understand what you're saying above, I do more of what the IT team is thinking about (I use Postgres). In other words my app deploys over SSH using a given account (let's say it's the AppName account). That means I need to have my SSH keys lined up for secure deployment (using a PEM or known_keys or whatever).
In the home root for AppName I have a file called .pgpass which has pretty specific security on it (0600). This means that my AppName account will use local security to get in rather than a username/password.
I do this because otherwise I'd need to store that information in a file somewhere - and those things get treated poorly pushed to github, for instance.
Ultimately, think 5 years from now and what your project and team will look like. Be optimistic - maybe it will be a smashing success! What will maintenance look like? What kinds of mistakes will your team make? Flexibility now is nice, but make sure that whomever will get in trouble if your database has a security problem is the one who gets to make the decision.
The best practice is to have individual accounts. This allows you to use database facilities for identifying who is accessing the database.
This is particularly important if the data is being modified. You can log who is modifying what data -- generally a hard-core requirement in any system where users have this ability.
You may find that, for some reason, you do not want to use your database's built-in authentication mechanisms. In that case, you are probably going to build a layer on top of the database, replicating much of the built-in functionality. There are situations where this might be necessary. In general, this would be a dangerous approach (the database security mechanisms probably undergo much more testing than bespoke code).
Finally, if you are building an in-house application with just a handful of users who have read-only access to the database, it might be simpler to have only a single login account. Normally, you would still like to know who is doing what, but for simplicity, you might forego that functionality. However, knowing who is doing what is usually very useful knowledge for maintaining and enhancing the application.
We have a Power User who knows the database very well and has become a great asset since we gave him access with SQL Server Management Studio. Unfortunately, we also gave him a user/pwd used by all Development which carries ability to change data.
Without going into all the wrongs behind having such a privileged db-user and giving such access an end user, is there a tool that would give the user ability to query without any ability to update/insert/drop/ or anything else?
My guess is that the user probably does not want to change the database -- for his/her protection as well as yours.
Just enable this user's login using Window to have read-only access. Or, set up another read-only user and give it to the power user. At the extreme, you may need to change the password of your super user account.
I would recommend in the mean time that you set up a development group, give the group privileges, and assign the developers to the group. They can then login through that id. Perhaps one day, you'll be able to disable your super user account. For now, you should think about ways to work around it.
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 have read a lot, but still i can't find the point that i want which is the following:
If i can connect to sql via windows authentication mode, then that mean after i install my software with it's database the user can easily look and manipulate my database, and if i want to revoke any role i will be limiting my program when it's going to access the database.
Is there a way to limit the user access on the database while my program can have a full access without any problems.
The application doesn't have to login to sql using the account that it's being run from. So create a seperate user account for the application that has all the rights it needs and login using that account from the application.
Alternatively, you can just setup a seperate login using sql server authentication and then you won't need another user account.
If this isn't your application and you can't modify it to use a different account to login with, then you could run the application itself under another account. When you hold shift and right click an icon you'll see it gives you an option to do so. However, I don't know how you would set the application up to automatically run that way without the user having to know the password to type in. I think it's possible though.
Also, I think when you set the account up you can set it as a special type that users can't actually login with. So they could know the password to it to run the application, but they wouldn't be able to actually login under that account to do anything with it. This wouldn't prevent someone smart enough from gaining access, but it's a good safeguard.