How to revoke all permissions of a user and grant only one table to that user in SQL Server?

If you are SQL DBA and planning for an interview, you should prepare for database security related interview questions.

I already published, please check the below link.

The Ultimate Page of the SQL Server Interview Questions & Answers for Database Administrators and Developers

As a SQL DBA, operating with database permissions is a routine work like giving permission to ad-hoc users and modifying whenever it is required.

Last year, I asked this question to a DBA, and I got an answer like “Remove the user and Create a new user with specific table permission.”
What do you think? Is this correct answer? – Partially Yes…

Before removing a user, you should verify the created objects by that user and create a new user with the same old name.

But without doing this all, the answer can be the below script:

Stop access to all tables for a user:

EXEC sp_msforeachtable "DENY ALL ON '?' TO [User_Name];"
GO

Grant specific table permission:

GRANT ALL ON [Schema_Name].[Table_Name] TO [User_Name]
GO

As a Database Administrator, we are following common practice by creating Database User or Role and assign only require permission to it.

When we are assigning different object level permission to particular Database Role, It is also important check total assigned object to particular Database Role or Which object assigned to which Role/User?

Most of the Database Administrators do not have practice to audit the list of assigned permissions of particular Database User/Role.

It is fine that we are securing database access using specific role, but that is also similarly important to check information about the assigned object and Database Role.
Periodically, Database Administrator should review the list of permissions which assigned to a Database Role/User.

PostgreSQL provides list of system functions for auditing User, Role, and its permissions.

In PostgreSQL, these functions called as Access Privilege Inquiry Functions.
You can find list of functions in this official document.

I have also prepared a small demonstration of this.

First, Create a sample restricted database ROLE:

CREATE ROLE Test_User WITH LOGIN PASSWORD 'Test1234' 
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION VALID UNTIL 'infinity';

Assign SELECT, INSERT permission on one sample tbl_employees table:

GRANT SELECT,INSERT ON tbl_employees TO Test_User;

Using has_table_privilege(), Script to find list of Users or Roles, who have a INSERT permission on tbl_employees.

SELECT rolname 
FROM pg_roles 
WHERE has_table_privilege(rolname, 'tbl_employees', 'INSERT');

Using pg_has_role(), Script to find list of objects, on which particular User or Role have INSERT permission.

SELECT 
	DISTINCT relname
FROM pg_roles CROSS JOIN pg_class
WHERE pg_has_role('test_user', rolname, 'MEMBER')
	AND has_table_privilege(rolname, pg_class.oid, 'INSERT');

The Database security is always one of the major tasks for all the Database Administrators.
I have also prepared one article to create Read only User in PostgreSQL.

PostgreSQL: Script to Create a Read-Only Database User

In this post, I am sharing small note about REVOKE privileges for newly created Database Users of PostgreSQL.

Before a few days ago, one of the PostgreSQL Junior DBA asked this question on my FB Page. He created one new DB User in PostgreSQL and without giving a any permission that USER can CONNECT to all Databases.

Yes: When you create any new DB User in PostgreSQL, It has a default CONNECT privileges.
But It cannot access any Table or data of Databases, yes It can create new Table in any Database.

To prevent a new User for connecting any existing Database, we should run REVOKE command on particular User or Role.

REVOKE CONNECT privileges from Database:

REVOKE CONNECT ON DATABASE Database_Name FROM User_Name;

REVOKE all privileges from Database:

REVOKE ALL PRIVILEGES ON DATABASE Database_Name FROM User_Name;

You should GRANT only required Databases:

GRANT CONNECT ON DATABASE Database_Name TO User_Name;

What do you know about the SQL Server Audit?

SQL Server Audit is used to track and log events (not data change) occurring on the SQL Server. SQL Server uses extended events to help create an audit. The audit can be server level or database level.

If you create an audit on a database table, SQL Server will only track the events that trigger the certain operations (SELECT/INSERT/UPDATE/DELETE) defined in the database audit specification.

What options are available to audit login activity?

• Custom solution with your application to log all logins into a centralized table
• Enable login auditing at the instance level in Management Studio
• Execute Profiler to capture logins into the instance
• Leverage a third party product

What is Audit in SQL Server?

Auditing an instance of the SQL Server Database Engine or an individual database involves tracking and logging events that occur on the Database Engine.

What is Server level Audit specification?

You can create one server audit specification per audit.

The server audit specification collects many server-level action groups raised by the Extended Events feature. You can include audit action groups in a server audit specification. Audit action groups are predefined groups of actions, which are atomic events occurring in the Database Engine.

What is Database level Audit specification?

You can create one database audit specification per SQL Server database per audit.

The database audit specification collects database-level audit actions raised by the Extended Events feature. You can add either audit action groups or audit events to a database audit specification.

Is it good to enable Audit only for SQL Server Login fails?

Yes:

Database administrators should enable login auditing feature of SQL Server on all instances which they manage. Once this feature is enabled SQL Server will write all the failed and successful login information in SQL Server Error Logs. It is always a best practice to auditing failed SQL Server logins.

Does SQL Server Audit require any additional permission?

Yes:

Each feature and command for SQL Server Audit has individual permission requirements.

Should we encrypt the SQL Server datatabase backups?

Yes:

We need to make sure the database backups are encrypted to avoid the misuse.

Why we should not use tha SA login for all the different SQL Server access?

Because, the sa login and password to all of your SQL Servers because auditing the sa login with a shared password is difficult without capturing the host name or some other personally identifiable data. We should migrate all SQL Server authentication to Windows based authentication.

Can I stop a System Admin from enabling SQL Server xp_cmdshell?

No:

T-SQL script to disable the SA login

ALTER LOGIN sa DISABLE;

T-SQL script to rename the SQ login.

ALTER LOGIN sa WITH NAME = [dbrnd_user];

Please do auto reset the SA password and disable it.

SQL Server has an undocumented system stored procedure named sp_SetAutoSAPasswordAndDisable. This procedure will do exactly as the name suggests: it will reset the password and then disable the ‘sa’ login.

EXEC sp_SetAutoSAPasswordAndDisable
GO

SELECT name,type_desc,create_date,modify_date,password_hash 
FROM sys.sql_logins 
WHERE PWDCOMPARE('mssqltips',password_hash)=1;

SELECT name,type_desc,create_date,modify_date,password_hash 
FROM sys.sql_logins 
WHERE PWDCOMPARE('',password_hash)=1;

SELECT name,type_desc,create_date,modify_date,password_hash 
FROM sys.sql_logins 
WHERE PWDCOMPARE(name,password_hash)=1;

GRANT:gives a user permission to perform certain tasks on database objects.
DENY:denies any access to a user to perform certain tasks on database objects.
REVOKE:removes a grant or deny permission from a user on certain database objects.

Sample T-SQL scripts for GRANT, DENY and REVOKE.

GRANT INSERT, UPDATE, SELECT ON Customers TO Joe, Mary;
DENY DELETE ON Customers to Joe, Mary;
REVOKE UPDATE ON Customers to Joe;

Sharing one of the important articles for the PostgreSQL Professionals.

In PostgreSQL, when you create a new user without specifying any grant or rule, by default it the user can access all databases.

Postgres internally provides a PUBLIC grant to the newly created user.

So here, Database security is one of primary concern for us.

You can refer this article to create, read only user in PostgreSQL.

If you want to prevent the user from accessing all the databases, use below REVOKE script.

REVOKE CONNECT ON DATABASE database_name FROM PUBLIC;

My advice is to always create the customized database role for application and read-only user.

After executing revoke command, you can grant CONNECT to your Database Role.

GRANT CONNECT ON DATABASE database_name TO role_name;