Setting System Wide Variables in Snowflake - snowflake-cloud-data-platform

I'm interested in finding a method where a system wide variable can be written onto the Snowflake Account, and used in a view so that users can see the underlying DDL, but not know the value used in a particular function.
At the moment this is done by making these a "Secure" View, but that limits almost everyone from seeing the underlying DDL (which would be helpful to our users and admins).
I'm wondering if there is a way to set a System Wide Variable, and use that in the DDL.
Example:
SET SYSTEM VARIABLE variable_name = 'some_value';
CREATE VIEW catalog.schema.tablename AS
SELECT TRANSLATE(COLUMN_NAME, '0123456789', variable_name) AS NEW_COLUMN_NAME
FROM <FULL SOURCE TABLE NAME>
WHERE <WHATEVER CONDITIONS APPLY>;
I have found setting variables on a session, and I know I can see / change Account Parameters. But can I create something like Account Variables?

Function has two privileges on it - OWNERSHIP and USAGE. If you don't give either of these function privileges to the viewer of the view, but you give the viewer SELECT privileges on the view, they will be able to see the DDL of the view, but won't be able to see the details of the UDF. Then you can store values in your UDF that you don't want other people seeing. I'll post code for this in just a second.
--Something like this to test it out from scratch. You must have accountadmin for this to work:
--use role accountadmin:
--create a database called demo_db;
--create a role called owner_demo_db and grant it usage, monitor, and create schema; also give it usage on a warehouse;
--create a user called demo_db_user. give them ownership on demo_db;
--create a role called reader_demo_db;
--assign the "reader" and the "owner" role to demo_db_user;
--as the owner_demo_db role, create the following:
use role owner_demo_db;
--The role owner_demo_db will own this function
create function pi_udf()
returns float
as '3.141592654::FLOAT'
;
--The role owner_demo_db will own this view
create view MyView as
select 'some_value' AS someval
, pi_udf() pi_val;
--Because owner_demo_db owns the view, they can grant select to the reader role to the view
grant select on view demo_db.demo_schema.MyView to reader_demo_db;
--Show functions and views and you'll be able to see both.
show functions;
show views;
--Show functions and views as reader_demo_db, and you'll only be able to see DDL for the view b/c you don't have a privilege on the function
use role reader_demo_db;
show functions;
show views;

Related

Block access to column without changing query

I have a Microsoft SQL Server with data that needs to be protected (certain sensitive columns of some tables) and an application that queries that database like this:
SELECT BoringColumn, SensitiveColumn FROM Table
I have the following restrictions:
I have multiple users (3-4) each with different columns visible or not.
In this example SensitiveColumn should not be accessible.
I can not directly update the queries that the application sends
What did I try already:
I tried to use SQL Servers Dynamic Data Masking feature. However it's not granular enough, you can just turn it on or off per user but not just for some columns. And its can leak data in queries, the link above explains that as well.
I know I can just deny the user SELECT on Table.SensitiveColumn.
However then any existing query asking for the table just breaks with permission errors.
What other options do I have left?
Ideally I would like something that replaces the query on the serverside and executes something like this:
SELECT BoringColumn, 'N/A' as SensitiveColumn FROM Table
I think I found a possible solution:
Change the table structure - Rename the SensitiveColumn to a different name, and add a computed column with the old name of the SensitiveColumn, that will show results based on current_user.
CREATE TABLE tblTest
(
boringColumn int,
SensitiveBase varchar(10), -- no user should have direct access to this column!
SensitiveColumn as
case current_user
when 'Trusted login' then SensitiveBase
else 'N/A'
end
)
The one thing I'm not sure about is if you can deny access to the SensitiveBase column but grant it to the SensitiveColumn.
I'll leave you to test it yourself.
If that can't be done, you can simply grant select permissions on the SensitiveBase column only to trusted login and deny them for everyone else.

What permissions to I need to use User Defined Table Types

Background:
I have two accounts for the same database one "master" account and another (sub) account which I use for my website to use to connect to the server so I can manage what the user can and cannot do. A lot of the permissions on this account were already on there before I got access to it so I don't know what exactly all the permissions are, except the ones I have managed.
There is a user defined table type that some one else created, dont ask me why they did,
CREATE TYPE [dbo].[AffectedServiceList] AS TABLE(
[AffSerName] [nvarchar](200) NULL
)
GO
This type is used in a stored procedure like so
ALTER PROCEDURE [dbo].[Contractsetup] #OtherParams, --Easier than typing them all
#list dbo.AFFECTEDSERVICELIST READONLY
The master account can execute and modify this procedure perfectly but the sub account cannot run or modify this stored procedure while the affectedservicelist type is used as it gets the error
Cannot find the type 'AffectedServiceList', because it does not exist
or you do not have permission.
I have tried doing this grant execute on type::dbo.AFFECTEDSERVICELIST to subaccount
But it still returns the same error that about the permissions. I have eliminated it to the the permissions as when I try and modify on the master account I just get
Command(s) completed successfully.
To use User Defined Table Type you need EXECUTE or CONTROL permission on it.
Your code
grant execute on type::dbo.AFFECTEDSERVICELIST to subaccount
is correct.
What is missing here is REFERENCES permission:
grant references on type::dbo.AFFECTEDSERVICELIST to subaccount
this is need to be able to reference this type in the code.
To only be able o create a proc using UDT, you only need REFERENCES permission. EXECUTE or CONTROL is needed to be able to execute the code(proc)
After doing a bit more digging the permission I needed to add was not execute it was control.
So instead of doing this;
grant execute on type::dbo.AFFECTEDSERVICELIST to subaccount
I actually needed to do this;
grant control on type::dbo.AFFECTEDSERVICELIST to subaccount

Azure DB - How to give 1 user read-only permission for 1 table

I've been reading many answers but I am too weak at TSQL to filter out what I need.
I created a contained user for 1 DB...
CREATE USER appuser WITH PASSWORD = 'strongpwd';
So I need to allow a user in to read only the contents of 1 table - tableA (there are others in the DB) and do absolutely nothing else in the DB.
I do not want to affect any other users. I just want the user to be able to access the DB via say SSMS, see only tableA (well this is not that important), read it.
There are two ways one is to directly grant explicit SELECT only on Table 1 and the second one is to create a role, grant SELECT to role and addd the user to the role. Typically second way is the preferred way and can be done as below
CREATE ROLE [role_name]
GRANT SELECT ON [Table] to [role_name]
EXEC sp_addrolemember '[role_name]', 'appuser'

Dynamic Row Level Security In a SQL Server Database Using Extended Properties

We have a requirement to provide customer access to a staging database so that they can extract their data into their own servers, but every table contains all customers data. All of the tables have a 'CustomerID' column. Customers should only see rows where the customerID is the same as theirs.
I am not looking for suggestions to create separate databases or views for each customer as both suggestions are high maintenance and low efficiency.
My solution has to work with:
100GB database
400 Tables
Updates every 30 minutes from the core transaction database
Quarterly schema changes (Application is in continuous Development).
Can anyone give me a definitive answer as to why the following method is not secure or will not work?:
I've set up a database user for each customer, with their customerID as an extended property.
I've created a view of every table that dynamically selects * from the table where the customerID column is the same as the extended property CustomerID of the logged in user. The code looks like this and appears to work well:
CREATE VIEW [CustomerAccessDatabase].[vw_Sales]
AS SELECT * FROM [CustomerAccessDatabase].[Sales]
WHERE [Sales].[CustomerID]=
(SELECT CONVERT(INT,p.value) AS [Value]
FROM sys.extended_properties
JOIN sys.sysusers ON extended_properties.major_id=sysusers.[uid]
AND extended_properties.name = 'CustomerID'
AND sysusers.[SID]=(SELECT suser_sid())
);
GO
To provide access to the views I've created a generic database role 'Customer_Access_Role'. This role has access granted to all of the table views, but access to the database tables themselves is denied.
To prevent users from changing their own customerID I've denied access to the extended properties like so:
USE [master];
GO
DENY EXEC ON sys.sp_addextendedproperty to [public];
GO
DENY EXEC ON sys.sp_dropextendedproperty to [public];
GO
DENY EXEC ON sys.sp_updateextendedproperty to [public];
GO
The end result is that I only need one database, and one set of permissions.
To add a new customer all I would need to do is create a new user with their customerID as an extended attribute and add them to the Customer_Access_Role. Thats it!
I am going to reiterate what everyone is stating already and sum it up.
You are making your job harder than it has to be.
Create a View, that is just their data and then give them Security access to that View.
Alternatively, extract all their data out of the "Core" database and into their own and give them the necessary access to that data.

prevent some user from seeing db2 tables structure

How can I restrict some users in DB2, not to see the table structure. I set the user privilege and restrict user from table access. so that user can not select data or change table but still can see the table structure or describe it.
This problem refers to row access in tables which is added in db2 version 10.
I had this problem too.
you can use this version - if applicable- and restrict user access from specific table structures.
You need to remove the select grant on catalog tables. For example, the following query should return 0 rows when executing with q restricted user.
db2 "select tabschema, tabname from syscat.tables"
All tables and views in the following schemas should not have select on public, nor in any group the restrictive user is in.
sysibm
syscat
db2 revoke select on SYSIBM.SYSTABLES from username

Resources