I have one snowflake instance and I want to use it for 2 different environments.
To segregate the cost, I will create 2 warehouse for dev and qa.
Also, I will create two databases. Is it possible that dev warehouse can be restricted to be used by one dev db and qa database can only be used by qa warehouse.
I know we can restrict it be roles. But it is possible on database level in snowflake?
Or if not, what is the best way - is it creating two roles and then granting the access of db and warehouse by roles?
The issue with roles is that- I can impose restrictions with application level roles but not with individual user roles
It's not possible to assign warehouses to databases. You need to set up (at least) 2 roles and grant required permissions to use the specific warehouse and the database.
I couldn't understand the issue with the users. You will assign these roles to users, so the users will have access to only the specific warehouse and the database.
As Gokhan notes.
WAREHOUSES and DATABASES are just resources. They are only acted on by USER, users do stuff via ROLES.
So you have to have your QA users, have QA_x roles, and those ROLES have access to the WAREHOUSES and the DATABASES. And thus the DEV roles have access to the DEV DB & WAREHOUSE.
The only problem with this is if a USER has access to both ROLES, but then they will have to select between ROLES to access the resources, which they can use both ROLES at the same time via USE SECONDARY ROLES unless you have that blocked.
Related
We are using different Microsoft SQL Servers (SQL Server 2008 R2) within a Windows LAN network physically seperated each of them. Is there a good strategy how to control incoming connections to the central server?
I mean, how can I prevent/protocol significant changes like ALTER to a table structures from "other" users?
Thank you,
Move
Create different users for different purposes
Most SQL Server databases have a number of users viewing and accessing data, which makes security a major concern for the administrator. The smart administrator will take full advantage of SQL Server security roles, which grant and deny permissions to groups of users, greatly reducing the security workload.
The first step in protecting your client’s data is determining which users need to view which data and then allowing access to only those users. For example, a payroll clerk probably views salary figures for everyone in your company while team managers have access to salaries for team members. Individual employees have no need to view salaries at all.
The benefits of using roles
Roles are a part of the tiered security model:
Login security—Connecting to the server
Database security—Getting access to the database
Database objects—Getting access to individual database objects and data
For better understanding read below link guide line you will get answer
https://www.techrepublic.com/article/understanding-roles-in-sql-server-security/
https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/server-and-database-roles-in-sql-server
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/database-level-roles?view=sql-server-2017
The Problem
Good Morning! I work on an application team that supports a few applications which utilize SQL Server for data storage. Recently, our Database Support team decided that SQL Authentication was no longer permissible (for security and logging reasons) and so my team was forced to convert all connections to Windows Authentication including several dedicated Service IDs that our applications had been utilizing for data retrieval.
First, let me say there most certainly are advantages to moving to Windows Authentication, I am not trying to dispute that. But this change has raised a huge problem for us... by switching our Service IDs to Windows Authentication we have now opened up our back-end databases to every internal business user with front-end application access.
MS Access is pushed out to every user desktop and a few superusers even have access to SSMS. At this point we are relying entirely on user ignorance to prevent internal users from accessing the back-end database directly. And given that certain roles have elevated DML rights, this presents a possibility for some nasty data consequences.
This new enterprise standard has left my team stuck between a rock and a hard place at this point so we looking for any database, account or architecture solution that would allow us to restrict user access to front-end only.
Questions
Has anyone else run into this problem? Is there an architectural solution we are missing that would allow us to eliminate SQL Authentication without exposing our databases?
Does anyone know of a way to restrict access to a SQL Server database to only certain connection methods? I'm wondering if there is a way to designate a specific ID (or role) as only allowing a connection through a front end (and eliminate ODBC connections entirely).
Does anyone have any clever workarounds?
-------------EDIT---------------
A couple people brought up a good point about role access so I wanted to clarify our former and current solution... Previously, all role access was managed on the front-end and data retrieval was handled entirely by private system SQL Authenticated IDs to which end users had no visibility.
When we were forced to eliminate these SQL Auth IDs, we created a similar role-based setup on the back-end database as existed on the front end. Active Directory Groups were created to house different groups of users and these groups were assigned specific role privileges in the database. So currently access is limited by role as much as feasible.
The problem is that even the lowest privileged roles have INSERT, UPDATE and DELETE access to some tables (access which is normally controlled through code). So while we were able to mitigate risk somewhat by utilizing database roles, we still have areas where a user can bypass front end protections by logging directly into the database.
EDIT: Question clarification makes this answer obsolete, but leaving it for reference since some comments discuss it.
Assuming you mean that you have to (based on your architecture) allow access to the DB to each windows user account, one options is to use database roles.
You disable public access to your database, then define a set of database roles, depending on your use cases. Each role is granted permissions such that members of that role are able to manipulate the data they need and or work with the objects they need. Users are then mapped into the roles they require. When connecting to your database, the user will be granted permissions according to the roles they are members of.
For example, we have a role in one of our databases named MyAppUser (our name is actually related to the app which uses the db), which is designed for end users to read and insert data only. These can be created simply as follows:
CREATE ROLE [MyAppUser]
The role is granted just the permissions it to the relevant schemas or tables (assume all our "public" tables are in dbo schema for now).
GRANT SELECT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT INSERT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT DELETE ON SCHEMA::[dbo] TO [MyAppUser]
Each user who should have this public read-write access is then mapped into the relevant role.
ALTER ROLE [MyAppUser] ADD MEMBER [UserName]
This separates users and roles / permissions within your database and allows you to have a single point of entry to control who has access to what in your databases.
By having the "View Definition" permission denied by default (to end users), they won't be able to "explore" the database / view table definitions etc using access, or even SSMS.
NB: SSMS provides wizards for managing and viewing permissions and memberships which are very handy for getting things initially setup / tested / fiddled around with.
I having trouble understanding some core concepts in SQL Server 2008. Until recently I haven't had to care much about security, users, schemas etc.
What is the difference between a Login and a User?
How do these relate to roles
What is a schema? (Until I started reading about security I thought a schema was just a database design?!)
I'd like to be able to create a script to create my Users, Logins, especially as IIS attempts to connect to SQL Server as it's app pool. Can anyone point me in the direction of some examples of scripting this kind of thing?
Thanks in advance!
P.S:
I've been trying to read some MSDN articles about this stuff and getting a bit lost for example this seemed out of my depth:
http://msdn.microsoft.com/en-us/library/ms190387.aspx
A login is the principal that is used to connect to the server. A user is the principal that is used to connect to a database. The security context on the instance itself is dictated by the login, it's roles and the permissions granted/denied. The security context on the database is dictated by the user, it's roles and the permissions granted/denied.
Like all other role based systems, the roles are logical groupings of permissions. Roles can be applied to users and logins. There are fixed server roles and fixed database roles for frequently used sets of permissions.
A schema is a database object that is used for two things: logical separation of database objects (tables, stored procs, functions, views), and security separation. A schema contains these objects. And users can be granted/denied rights on schemas, implicitly granting/denying rights on the objects contained within.
4 doesn't really seem like a question. Can you reword??
Let's say I want to create simple database, for a simple book store application. I think i should have minimum two users: admin, which has privileges to create, modify and drop objects and user, having just select and insert privileges.
I am a little confused here. Should I create a user account with normal schema or with empty schema? Should the user has privileges to select and query from admin schema which contains tables or it is a user schema that should contain these tables?
There are many different ways to approach this sort of problem. So a great deal depends on your application architecture.
You would generally create one database account that owns the database objects-- tables, packages, views, etc. Let's call this account BOOKSTORE_OWNER. This account would generally be locked so that no one could log in as BOOKSTORE_OWNER other during periodic builds.
Beyond that starting point, however, there are a host of reasonable ways to deal with authentication and authorization. If you wanted to let the database handle both, you would create two roles-- BOOKSTORE_USER and BOOKSTORE_ADMIN. Those roles would be given appropriate privileges on the objects owned by BOOKSTORE_OWNER. You would then create a database user for every person that can use the application and grant the appropriate role to each new user. So if you're an admin and I'm a user, the database account dygi would be created and granted the BOOKSTORE_ADMIN role while the database account Justin would be created and granted the BOOKSTORE_USER role.
This approach worked quite well when people were building client-server applications. If you are using a three-tier application, on the other hand, you want the middle tier connection pool to use the same credentials to connect to the database rather than having each user have their own database connections. The simplest way to accomplish this is to create a single BOOKSTORE_APP database account, grant that account all the privileges of the BOOKSTORE_ADMIN and BOOKSTORE_USER role, and then let the application implement the logic to figure out which front end user has what privileges. This would generally entail a USER, PRIVILEGE, and USER_PRIVILEGE table in the BOOKSTORE_OWNER schema. This approach can work quite well. The downside, though, is that every application has to build its own logic for managing privileges which can get quite complex over time. It also can make it somewhat difficult to report on what privileges users have or to ensure that a user's privileges are kept up to date when users leave the organization or move to a new role.
Oracle in particular addresses many of these challenges by allowing proxy authentication. This allows you to mix the benefits of the client-server approach where every user has their own database account that leverages Oracle's existing privilege management infrastructure with the connection pooling benefits of using a shared database account. This works very well but only works with Oracle and then only with certain protocols (OCI and JDBC) so it is not terribly popular.
Of course, beyond these basics, you can get into quite a bit of complexity. You may want to have enterprise users where Oracle doesn't maintain the password but instead allows the user to authenticate against an external LDAP directory. You may want to manage privileges with LDAP roles rather than with rows in application-specific tables. You may want to integrate with various middle-tier single sign-on (SSO) solutions.
I've done a piece of work using Entity Framework. However, my manager asked me to use Stored Procedures instead. He said at the moment, the database security structure in the company is built on database roles.
For example, we have a roleA which includes the AD users that will access the database, and roleA has only been given Execution rights to relavent Stored Procedures. If I use Entity Framework, queries will be run as the actual users instead of the database role, and therefore those users could potentially connect to the database directly and do something with it.
I'm not too familiar with the database security. Can anyone please explain whether what my manager said is valid?
If so, is there any workaround so that I can still use Entity Framework while not breaking the company's database security structure?(i.e. use role to execute the queries instead of actual AD users)
Database role is database level object. User account used to run your application must first log in to the server. Then the permissions for this account are evaluated based on database users or database roles. If your application account will be member of roleA it should have permissions "to access the database" but if the access means only that members of roleA can execute SP you can forget about any linq or ESQL queries because database security will simply not allow you calling them (it will throw security exception).
The only advantage of EF in such case is automatic mapping of SP's result set to entity / complex type / custom type. No linq-to-entities can be used and entities can be modified only through mapped stored procedures.