How to grant select on entire schema to a role or user in ASE 16
Without more details I'm going to assume you're referring to the (new in Sybase/SAP ASE 16) on schema clause for the grant command; I hadn't actually noticed this new addition until I came across this question.
After spending 10 minutes trying several different combinations I've been unable to come up with a working version of the clause; and as you've likely noticed the documentation for the grant command has no examples.
At this point I'd suggest a) open a case with tech support and/or b) post a question on the SAP Q&A site (make sure to tag your question with SAP Adaptive Server Enterprise) to see if someone from the SAP/ASE group can chime in with an answer.
Related
Im new to working with databases and Im trying to do the following
Copy all databaseA schemas (which has several tables each and permissions attached) without any data to my
existing databaseB table as record fields (which now contains only one schema and
also a few tables and permissions attached)
databaseA is an Amazon redshift database & databaseB is an Amazon RDS database. Im connecting to both using DBeaver, databaseA I'm using a redshift driver & databaseB I'm using a PostgreSQL driver
After the inital copy I want to run a daily cron job that checks for the following
a. Compare databaseA to databaseB table
b. If databaseA does not match databaseB (in terms of schema & table permissions)
c. Then switch all perms to match databaseB table
Any feedback on how to approach this would be appreciated!
You could create a python script that connects to both of the databases. You could set up a cron job to spot the differences daily and to update the database.
You can have a query like this for PG:
SELECT table_schema,table_name
FROM information_schema.tables
ORDER BY table_schema,table_name;
And something like this for Redshift:
SELECT schemaname, tablename
FROM PG_TABLE_DEF;
From there it`s just a matter of comparing the two and deciding if you want to update certain tables. Good luck.
I don't have experience with AWS. Im translating the little knowledge I have from OCS which is a younger solution than AWS.
First, Amazon Redshift is tailored for Data warehousing. RDS is a cloud relational database. Im not sure what your aim is to copy from Redshift to RDS. It would be more natural to have the DB or multiple DB copy/clone to the data warehouse unless this was some form of backup. You might need to look into the architecture of your solution.
Oracle Cloud which is fairly new provides a service for copying. Amazon should have a similar solution as they have been in the cloud business longer.
I have had a look at the Amazon documentation. Your challenge has a solution "backwards" here.
After copying the two dbs my assumption is they would be similar structurally. What is affecting the changes on dbA ? It feels like you don't want to use the permissions on dbA maybe its compromised.
My suggestion is to use permissions to prevent changes to dbA. Look at the IAM documentation and check the logs for dbA. If you really need to develop a solution use the API or CLI to interface with the db
I'm developing a security product for databases in java. One feature in this product is creating security recommendations based on db-privileges and activity.
In order to do that I need to extract privilege data from db2.
So far I'v read a lot of documentation on db2 security but I haven't found a solution yet for the following problem:
The Db2 udb security, part 4 article explains how to extract privileges only but here it says:
Instance level authority levels (SYSADM, SYSCTRL, SYSMAINT, and SYSMON) and group membership are defined outside of DB2 UDB, and are therefore not reflected in system catalog tables.
To my understanding authorities have effect on a user's privileges and therefore are crucial to get the full picture of entitlements of the db.
Further in this article it explains how to get the authorities of the connected user but doesn't explain how to get all authorities of all users\groups. similarly to this answer: How to check DB2 SYSADM or SYSCTRL authorization for a user
So my question is how to extract authorities of all entities in a single query?
In DB2 for LUW there is a table function AUTH_LIST_AUTHORITIES_FOR_AUTHID():
select * from table (AUTH_LIST_AUTHORITIES_FOR_AUTHID('JOHN','U'))
It is available since DB2 9.7.
You would still need to access the operating system to enumerate users and groups though.
I am using MSSQL 2014 and I am having troubles fulfilling one request from DB admin regarding the security.
Our solution contains several databases (on the same server) with stored procedures in them that have joins between the tables of two or more databases. We have one user that has same rights on all databases.
Very simplified example: one database contains Articles while the other one contains Prices, queries need to get Articles with their Prices. Queries have INNER JOIN-s between tables in those two databases.
After deployment of the solution on our client's test environment, I talked to client's DB admin and he asked me to modify the databases and users to match some of their standards. Those standards include different database names on different environments as well as one separate user per database.
If I did changed database names and users in my current solution, stored procedures would return errors due to invalid database names or invalid credentials. I asked that admin how they solved such problem in their environment and his answer was that they create database links. After googling for the solution, I found out that Oracle has CREATE DATABASE LINK option, but there is nothing similar in MSSQL (except maybe linked servers feature, but that does not solve my problem).
What I am looking for is something similar to Oracle's CREATE DATABASE LINK in MSSQL 2014, some solution that would allow execution of stored procedures without need to change the queries, but rather to create 'alias' of the databases that need to be renamed.
Does anyone have an idea how I could do this?
I just searched msdn
CREATE SYNONYM (Transact-SQL)
I know link only answers are frowned upon but that is the answer and msdn is not going away
not sure if this can be an answer but it is too long to fit a comment...
there is no tech detail in your question so i'm making a huge wild guess but maybe the problem could be avoided using many schema instead of many databases.
that way all your objects would belong to the same database and there will be no need to make cross-database calls.
obviously this solution may not fit your situation, be not applicable because of [your long list of reason here] and would also require changes whose impact cannot be estimated reading a post on SO... ^^
as a side note the customer is not always right; if they have a policy that relies upon a specific oracle feature they cannot expect to enforce that very same policy on a different rdbms that lack the feature.
actually they may expect to do so but is your job to 'educate' them (or at least try to!).
anyway if the policy is mandatory then they will be happy to pay for the extra effort required to comply, isn't it?
Starting with the obvious I think you should explain the client that although there is more than one physical database it is in fact the very same database split apart and used by the very same product. Make it clear that this shouldn't be considered like a breach in their standard.
If you can not convince them then you have to deal with two problems : different user/login and different database name.
Different user/login : You can solve this with a linked server. Linked servers aren't only for different servers or different instances, you can create a "local" linked server that will use a different login.
EXEC sp_addlinkedserver
#server='yourAlias',
#srvproduct='SQL_SERVER',
#provider='yourServer\yourInstance',
#dataSrc = 'yourDatabaseXYZ'
GO
You can easily modify the credentials used by the linked server you've just created :
In SQL Server Management Studio, open Object Explorer, expand Server Objects and ight-click the new linked servers you just created;
On the Security page specify the login you want to use.
Different database name : The only solution I can came up with is to create a SYNONYM for every object in the database. This is something others people seems to have done before and although it is not something funny it seems very doable. You can have a look here for a complete solution.
Of course you can use a SYNONYM on a linked server resource. Something like :
CREATE SYNONYM yourTable FOR [yourAlias].yourDatabaseXYZ.schemaABC.yourTable
And then you will be able to do :
-- Transparent usage of a table from another database with different credentials
SELECT * FROM yourTable;
By the way, there is a feature request to Microsoft to Allow CREATE SYNONYM for database. Maybe you'd like to upvote it
Final note :
To avoid problem like this, and like Blam also mentionned, you should consider not hardcoding the database name in your application.
I'm writing an application to manage AD permissions groups.
However, some fields which are needed like "Primary Owner", "Secondary Owner, "Date Reviewed" and historical logs are not in AD.
I'm planning on having a separate SQL Server database to hold this data and using the Group's System ID to join the data.
My question is: Can I have the SQL Server database be synchronized with what is in AD upon changes in AD? Perhaps some listening tool exists? Can LDAP be used to solve this?
A problem which can arise if the database is updated nightly is if a new group is created in AD, primary and secondary owners need to be assigned to it, but the
SID of the new group will not be immediately in the SQL Server Database.
I'm not familiar with SQL Server, so I cannot tell whether it has some special capability to synchronize with AD.
What I know is that there are a few different solutions if you want to track changes in AD using LDAP. You can find an overview of the available techniques in this MSDN article.
I've recently open-sourced ADSync4J, a small Java library that can help you implementing the third technique mentioned in that article (Polling for Changes Using USNChanged). However it won't be of much help if your target platform is not the JVM.
We use a console application written in C# which is run on a batch to read the AD information and insert it into a SQL table. This could be done in almost any language with LDAP bindings but depending on the size of your AD catalog could be performance prohivative.
There does seem to be a way to query directly with SQL (although with some caveats, namely maximum result set size and no support for multi-value parameters). Many articles exist on this from a quick google search such as; https://www.mssqltips.com/sqlservertip/2580/querying-active-directory-data-from-sql-server/
Is there any way to obscure the schema of a database on SQL Server?
If I have SQL Server Express installed on a client site, is there a way to obscure the schema and data so that someone else cannot come along and learn the schema in order to extract data out of it and into another product?
The best way to obscure your database schema is to not let it leave your servers.
Even if you encrypt the schema you still will have to provide the key somewhere, and if the client is determined to get it, they'll spend time and money to do so.
So you're better off either offering your product as service or making your client loyal by doing good job.
AFAIK, "no".
The best way to "lock down" your database is:
1) Install with appropriate roles and users (ideally, SQL roles and SQL users you create)
2) Explicitly restrict object permissions in SQL Server
3) Code your application to use SQL Server stored procedures (instead of raw T-SQL) as much as possible
4) Encrypt your stored procedures
Here's a good link on "SQL Server Best Practices" that might be of interest. It discusses security issues and a (relatively) new feature, "User Schema Separation":
http://msdn.microsoft.com/en-us/library/dd283095%28v=sql.100%29.aspx
This is a tricky one and may not even be 100% possible. However, there are a few tricks to setting it up:
Install a new named instance of SQL server with a custom SA account (both name and password). There is an installation method for SQL server call "Unattended Installation" which allows you to specify all the installation parameters for SQL server in an ini file and then run the install silently. Check out the documentation here: Unattended Installation of SQL Server 2008 r2
Create your database, tables, procedures, etc. with your magic SQL install script (use encrypted stored procs if you want, but they too are crackable)
Add/Verify the schema permissions for the custom SA account and Drop all schema permissions for all Administrator roles. The goal here is that no roles have any schema permissions to your database and only your custom SA user has permission (not assigned by role, but directly to the user).
There are several commercial applications that I know of that don't even tell you they are installing an instance of MS SQL express. They too will create their own named instance with a named SA account. I can't say I like that as a customer (as SQL takes a hit on the CPU and I don't want "secret" instances running on my workstation). But so long as you disclose this to your customers upfront, they may understand.
**Keep in mind a skilled DBA may have the knowledge to mess with system tables and what not to manually grant access to your database. These techniques really are just "obfuscation" and won't be 100% bullet proof.
As a side note: With the plethora of available 3rd party datalayers and webservice technologies, I think many companies are finding their database schema alone isn't so proprietary or valuable anymore. There was a time when the database schema alone could have represented hundreds of hours of coding. But today tools like EntityFramework, NHibernate, Linq-to-SQL, XPO, etc all create your database schema for you based on your software class definitions and in code attributes. So just seeing a DB table isn't really very valuable. Plus you might write a bunch of business logic, statistical analysis or other helper methods in your software that aren't in your database schema. In my opinion, this is where today's "value add" is found, in the business logic, analysis and reporting functionality of your software - not in the raw datatables.
This is also why another poster recommended obfuscating stored procedures, because these could be many times the work of the database schema itself if you have some nice analysis and reporting procedures written up. Its also what customer's would most likely want to customize for their own reporting needs. You may be inclined to have a policy that custom reporting can only be done by your company (hey, even the big guys like SAP are sticky with who can modify what).
There is a way, it's convoluted and ugly but it works.
You have a master table that acts as a lookup table for your other tables. This master table would look sort of like this:
id, guid, entityname, parent_id
then all of your table names and column names get renamed to be guids. after that you put an entry in the lookup table for each of them. When you want to select data you have to do so by pulling the guid's out of the lookup table by their entitynames which then give you the obscured table and column names.
There is a major software vendor out there that does something very similar to this, so it has been done before.