The Access Control Privileges documentation in Snowflake only says :
Grants ability to see details within an object (e.g. queries and usage
within a warehouse).
So what details specifically (regarding schemas) is referrering to?
Is it just the ability of performing DESCRIBE SCHEMA xxx?
Yes, it's exactly the ability to perform DESCRIBE SCHEMA command.
So to be able to use this ability, you also need to have usage rights on the target database and the schema.
Related
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 have an ASP.net (.net 4, c#) web application (Backend: SQL Server 2012). The permission concept (what data is each user allowed to see) is processed within the web application.
The permissions come from different sources:
-AD group memberships:
AD group name is linked to properties of the records
-Underlying database:
-Users are assigned to different criteria
Organizational structure
Location structure
Direct assignment
Currently all this is processed within the web application. So I collect all the users permission and then I query the database for the data he is allowed to see.
Now I need to bring the permission concept to database level.
The target is that the users can query the database (pre defined views) almost directly (Reporting Services, Excel and so on)
Any idea how to solve such an issue?
Thought about joining the user’s permission on the foreign keys. But that’s not possible for the AD permissions.
Or maybe creating a dll and calling this dll from a stored procedure. Then the view joins the stored procedure.
You should look at defining roles in the database http://msdn.microsoft.com/en-us/library/ms188659.aspx .
Then grant permissions on different tables or views depending upon your requirement. I have seen data being exclusively read from views. So, that could also be an option.
EDIT:
So, it looks like you need row level security. Please read this guidance from Microsoft.
http://technet.microsoft.com/en-us/library/cc966395.aspx
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.
I need to know if somebody can read and save to oneself packages from my database, Oracle specifically. Can I prevent it?
I mostly worry about tools like "Export schema" of Toad. How can I know somebody didn't something like exporting my database structure?
You want to obfuscate your code? Oracle calls it wrapping: http://www.comp.dit.ie/btierney/oracle11gdoc/appdev.111/b28370/wrap.htm
Oracle can log many things like who accesses the system, who executes certain packages and procedures, who accesses data etc. The facility is called Auditing or Fine Grained Auditing. Just have a look at the documentation for the AUDIT command.
Having said that, it needs to be turned on explicitly. So if it hasn't been turned on yet, then you won't find any audit information for the past.
For the future, it's probably easier to restrict the access rights of your users to prevent them from doing it than to identify all the functions and places that would require auditing.
Your question is slightly vague... are you the owner (DBA) of the Database? What version of Oracle is it? Are there other DBA's?
Anyway.
Since most users can only export their own schema by default and only DBA's and users specifically granted the EXP_FULL_DATABASE role will be allowed to export your schema. (Try to export somebody elses schema to see if you have privaleges to do this)
If you are the DBA you can make sure all other users don't have the EXP_FULL_DATABSE role. However, if there are other DBA's they will be able to export your schema.
See below for an explanation of how Import / Export works?
To use Export and Import, you must
have the CREATE SESSION privilege on
an Oracle database. This privilege
belongs to the CONNECT role
established during database creation.
To export tables owned by another
user, you must have the
EXP_FULL_DATABASE role enabled. This
role is granted to all database
administrators (DBAs).
If you do not have the system
privileges contained in the
EXP_FULL_DATABASE role, you cannot
export objects contained in another
user's schema. For example, you cannot
export a table in another user's
schema, even if you created a synonym
for it.
Sorry it's a little vague but I hope it helps.
We have some corporate intranet users using a WinForms app to work on a system with SQL server behind. Integrated Security is setup, allowing all users update and delete permissions, where application security limits how and where table updates take place.
However, some users are power users with SQL query tools at their disposal, and access the DB directly for building reports. However, with integrated security, they have default update rights on tables where they should not have, as the application apply rules to the updates.
Is this an example of where it's more appropriate providing the app with a central SQL authenticated login, whilst users get read only rights for integrated security?
As Jon mentioned stored procedures would give you the protection over direct table modifications. There are other options too. You can use SQL Server's "Application Role" (via sp_setapprole proc). This enables you to continue to use a separate ID for everyone but only at application connection time (through the front-end) are the user's rights elevated.
A major downside to using a shared ID is you lose track of who is submitting SQL to the server though if they're all internal you can get to the machine name.
Something else is concerning though. It sounds as if your users can connect to the database and run queries at will. You run a major risk of downtime in the application due to user behavior in the directly connected SQL sessions. If you can pull it off you may want to try to have a reporting database created that is updated at intervals that your business can tolerate, i.e., daily. HTH
I presume from the way that you've worded your question that your app executes sql statements directly. If you could refactor it so that it executes stored procedures, you could grant exec rights on the procedures and deny direct updating of the tables. This might not be possible though, depending on what your app does.
sql authentication is one option. Stored procedures are another. However, building more granular roles for assigning just the appropriate permissions to just the appropriate user types is where you should really be looking.
Additionally, I would really avoid giving these users direct access to the DB at all. Security reasons aside, it doesn't take much for a user who isn't proficient in SQL to accidentally execute a query that will swamp your database server and create an effective denial of service. Even pros can do this accidentally from time to time.
Instead, give them access to a reporting services or analysis services type solution, or use replication to give them access to a clone of the data. This way your production system is protected.
Personally I would do all application data access through stored procedures. I would set Integrated security to only allow users to run the SP's and not manipulate the data directly.
Advanced access can be given to DB admins to manipulate the data directly when needed.
Group based permissions will provide you with much more flexibility for access rights, and less administrative burden when controlling these with integrated security.