I am not a security expert and there was a discussion in my project about if we should use Entity Framework. Even though it seems we will use it the project leader is instill insisting that we should still do all our operations (that includes simple CRUDs) with store procedures because of security. He says that if we use stored procedures the users will only need permission for executing a stored procedure instead of needing permissions for create/read/update/delete.
As I said before I am not a security expert, so I was curious to know how true is this.
What this does is give rights and privileges to the individual store procedures, which then have access to the tables, rather than to the tables themselves.
This way you can restrict the users from all the tables, and allow the SPs to allow semantic access based on other logic (both DB permissions at the SP level, as well as code within the SP).
This is gives the overall security framework finer granularity in terms of roles and privileges.
For example, using normal DB permissions, it's easy to limit what tables a user can see, but not what rows they can see within a table.
Two ways to fix that is to limit access to the underlying table, and then create a limited view on that table and grant permission to that, or you can limit access via the SP which has logic capable of restricting what rows a user can see.
Its true.
Stored procedures gives ability to perform better security than standard table permission (for example by giving possibility to update only few columns of table)
But..
For developers its a nightmare. Even simplest query needs to be implemented as stored proc or view.
So its not agile, rapid or sexy :)
Related
Is there a good reason to start a new project in a fresh Snowflake schema vs. a fresh Snowflake database?
I know this sounds like an opinion based question, but I'm trying to get to the technical limitations of one vs. the other.
As far as I can tell, databases & schemas are just like folders and sub-folders. They seem to have no bearing on cost or capability.
I can do:
SELECT *
FROM database1.schemaA.tableX x
JOIN database2.schemaB.tableY y ON y.row_id = x.row_id
So is it all purely syntax and table organization? Or am I missing something?
For simple use cases, you can treat databases and schemas as folders and subfolders. How you set them up is determined on how you want to organise your data and how you want to manage access control.
Access control: the more granular you want to make your access control the more complicated it is to implement and maintain. It's relatively simple to give users access to everything in a database, it's more complicated to give users access to specific schemas within a database and it can get very complicated to give users access to a subset of tables within a schema. Therefore if you have sets of tables that should be accessible to different set of users it is easier if you keep them in different schemas (or databases).
Replication: if you are going to need to replicate data to another Snowflake account (presumably in another region or otherwise you would probably use Sharing not Replication) then bear in mind that replication happens at the database level i.e. you can't replicate specific schemas (or tables or views), the whole database gets replicated. This may influence how you segregate your data between databases
All,
In SQL Server, can a stored procedure (beeing ran from a user) write to table where the user doesn't have access to write directly to the table?
Rgds,
MK
The correct answer is NO, a stored procedure does not have access to write into a table. However most users perceive it, incorrectly, as YES because of Ownership Chains:
When multiple database objects access
each other sequentially, the sequence
is known as a chain. Although such
chains do not independently exist,
when SQL Server traverses the links in
a chain, SQL Server evaluates
permissions on the constituent objects
differently than it would if it were
accessing the objects separately.
These differences have important
implications for managing security.
Ownership chaining enables managing
access to multiple objects, such as
multiple tables, by setting
permissions on one object, such as a
view.
So a procedure will be able to write into a table that the user has no permissions to write into if they form an ownership chain. This means that if the owner of the schema that contains the table is the same as the owner of the schema that contains the procedure, an ownership chain is formed and the procedure is allowed to write into the table. Since the vast majority of objects deployed in practice belong to the dbo schema, an ownership chain is almost always formed.
It is important to comprehend these details, so you can troubleshoot problems and understand why is the procedure allowed to write into the table. Erland Sommarskog has an excellent comprehensive write up on this topic: Giving Permissions through Stored Procedures. This article goes into great detail explaining all the options available. Your best option, far better than ownership chaining, is code signing.
Understanding how this works also helps understanding why dynamic SQL seems to 'break': running dynamic SQL is an automatic break in the ownership chain, which causes all 'magic' to disappear. And it also helps understand why this 'magic' appears not to work outside the database: cross db ownership chaining Option default value is 0.
In short, yes.
The main restriction in play in this scenario is whether the user can execute the stored procedure.
When creating the stored procedure, it needs to be done with a login/user that has the necessary write access to the table in question.
Yes, if the user is GRANTed EXEC permissions on the SP, any actions it takes (within that database) are allowed.
Going over to another database will require permissions on the underlying user to be examined.
Also, dynamic SQL built within the SP will require the underlying user to have permissions.
I've always wondered why the list of database roles (db_datareader, db_datawriter, db_ddladmin, etc) never included a db_storedprocedureexecutor. The others make sense, but it seems like being able to grant the ability to execute all stored procs to a particular user (without granting them db_owner, which is the only other way to accomplish the same thing) would be a handy thing.
For example, say I want to give all of my developers the rights to run stored procedures, while not let them execute any DDL - without explicitly granting EXECUTE on every stored procedure (and then remembering to add the new ones when additional SPs are deployed), there's not way to do this (I know that SPs can contain DDL, so they may still be indirectly allowed access to DDL this way).
If I have an application service account and a number of stored procedures that go along with my application, I have to grant rights explicitly to every SP (since I don't want to grant my application service account DBO), whereas I can use a role to allow them to update/delete anything they want.
While it initially seemed obvious, I'm now not sure why this role is missing from the database server - can anybody offer an explanation of why this is a terrible idea (as I assume it is, or it would already exist)?
EDIT:
Seems I'm not the only one with this expectation - and it's worked around with a handful of T-SQL (it seems you can grant a blanket EXECUTE right, which I wasn't aware you could do), which just leaves me wondering why it's not standard!
If you use schemas, then you only have to GRANT EXECUTE ON SCHEMA::storedprocschema
eg CREATE PROC storedprocschema.DoStuff ...
As to why, no idea...
Because if you can execute all stored procedures, you can execute sp_addrolemember, and you can do everything that a database_owner can.
I'm working with a database (let's call it DB_data) that contains all of the tables for a series of applications. In an attempt to minimize downtime during upgrades, a facade database (let's call it DB_facade) has been created which has a view for each of the tables in DB_data. It also contains all of the functions and stored procedures, which work against these views.
In trying to lock down security in DB_data we've done a DENY on all of the tables for all of the users in DB_data. All of these users have also been created in DB_facade with permissions to the views.
The problem here, is that because of cross-database ownership chaining the DENYs in DB_data are overriding the GRANTs in DB_facade.
I'd like to avoid turning on ownership chaining for both of these databases because of the potential security issues (although in my original tests, that did seem to correct the access problem). Also, we're trying to minimize impact to the applications, so requiring all access to be through stored procedures and using certificates (for example) wouldn't work.
Does anyone have any other suggestions on how to handle this?
Thanks!
Do you have this problem if you exclude the DENY on the tables in DB_data? If you don't explicitly GRANT permissions on these tables, you may be able to get the security you need and get the access rights through the views.
from what i've seen and done, sql server doesn't let you have any permissions unless explicitly told so. You should be able to grant select (or use the role datareader) in DB_Data to the users, and as long as it's the same account and it's mapped to both databases (you'll have to grant select and exec on db_facade) that should work just fine.
You can create a view in the DB_data database for each view in the DB_facade database. The new views would have rights to select from the tables. GRANT SELECT on the views in DB_data. Change the views on DB_facade to SELECT from the views on DB_data. And, the tables would have DENY set.
I recognize one disadvantage to this; the users can still interact with the DB_data database. They wouldn't be able to access the tables, but they could access the new views.
What is the importance of schema in sql server?
Where this schema help me?
Is it important for security reasons?
Yes, the primary purpose of SQL schema was -is- to facilitate security management: define who [which principals] can access what [which database objects]. This was made particularly easier starting with SQL 2005 when the schema stopped being directly tied to the owner.
Another use of schema is to serve as a namespace, that is preventing name clashes between objects from different schemas.
The original use of this was to allow multiple [interactive, i.e. ad-hoc like] users of a given database to create their own tables or stored procedures (or other objects), without having to worry about the existence of similarly named objects possibly introduced by other users.
The Namespace-like nature of schema can also be put to use in a planned database setting, i.e. one when a single architect designs the database structure in a way which provides distinct type of access, and indeed different behaviors, for distinct user groups.
They partition your database to make management easier.
This is from MSDN:
A schema is now a distinct namespace
that exists independently of the
database user who created it. In other
words, a schema is simply a container
of objects. A schema can be owned by
any user, and its ownership is
transferable.
Here's the page that came from: http://msdn.microsoft.com/en-us/library/ms190387.aspx
In relation to security it makes it simpler to assign permissions as you can grant someone access to a schema without exposing your entire database to them.
What a schema is changed with the release of SQL Server 2005 and later - I think of it as an additional security layer as well as a container of objects.
This is quite a good resource:
http://msdn.microsoft.com/en-us/library/ms190387(SQL.90).aspx
Schema is mainly used to Manage several logical entities in one physical database.
Schemas offer a convenient way to separate database users from database object owners. They give DBA’s the ability to protect sensitive objects in the database, and also to group logical entities together.
This is especially advantageous in situations where those objects are often utilized as a unit by applications. For example, a hotel-management system may be broken down into the following logical entities or modules: Rooms, Bar/Restaurant, and Kitchen Supplies.
These entities can be stored as three separate physical databases. Using schemas however, they can be combined as three logical entities in one physical database. This reduces the administrative complexity of managing three separate databases.
Source