Big question: How to rotate passwords in an Oracle database in a zero downtime (ZDT) way?
My current thought is to rotate the users. Originally, I had MY_USER that had all the tables and such. Now, I have:
CREATE USER MY_USER NO AUTHENTICATION;
GRANT CREATE SESSION TO MY_USER;
CREATE USER MY_USER_PROXY_1 IDENTIFIED BY "abc123";
GRANT CREATE SESSION TO MY_USER_PROXY_1;
ALTER USER MY_USER GRANT CONNECT THROUGH MY_USER_PROXY_1;
When I want to rotate the password, I simply create MY_USER_PROXY_2 and give the 'connect through' grant to MY_USER. This way, the app can continue to create new connections until I deploy it using the new user. Because of the 'connect through', the new user is essentially the same as the old user so everything should continue to work without much fanfare. Afterwards, I can decommission MY_USER_PROXY_1 or let the password normally expire
This seems like a reasonable approach if there is 1 'physical' user (MY_USER)
However, I am already using proxy users for multi-tenancy. Same as before, but instead of 1 user, there could be hundreds of users going through the same proxy user:
CREATE USER TENANT_PROXY_1 IDENTIFIED BY "abc123";
GRANT CREATE SESSION TO TENANT_PROXY_1;
-- During tenant onboard
CREATE USER TENANT_1234 NO AUTHENTICATION;
GRANT CREATE SESSION TO TENANT_1234;
ALTER USER TENANT_1234 GRANT CONNECT THROUGH TENANT_PROXY_1;
The issue with creating TENANT_PROXY_2 is recreating all the connect through grants. I could iterate through all the users like 'TENANT_%' and apply the grant that way but will always be a window of opportunity after TENANT_PROXY_2 is created and updated with the grants BUT BEFORE the app is restarted to use the new proxy user. So it would add the grant to TENANT_PROXY_1 and thus fail when the proxy user is rotated to TENANT_PROXY_2
I tried using roles (both as the connector and the connectee) but looks like only users are supported:
ALTER USER TENANT_1234 GRANT CONNECT THROUGH TENANT_PROXY_ROLE;
GRANT ROLE TENANT_PROXY_ROLE TO TENANT_PROXY_1;
-- or
ALTER ROLE TENANT_PROXY_ROLE GRANT CONNECT THROUGH TENANT_PROXY_1;
GRANT ROLE TENANT_PROXY_ROLE TO TENANT_1234;
My only thought is to pre-create TENANT_PROXY_1 through TENANT_PROXY_N and apply the grant to all N proxy users during onboarding and manually round-robin through the N users. Not quite as graceful, but still seems reasonable
Any thoughts on either solution? Databases have been around for decades, is there any official solution or pattern to ZDT password rotation problem?
Related
At first there is no authentication in mongodb, so I created one for one database with readWrite role.
Now I want to create more users for other databases but as this user doesn't have the privileges to create other users I'm stuck.
The documentation clearly says:
With access control enabled, ensure you have a user with userAdmin or userAdminAnyDatabase role in the admin database. This user can administrate user and roles such as: create users, grant or revoke roles from users, and create or modify customs roles.
If you haven't created such user, you cannot create it now with authentication and access rights enabled. I gues you need to restart the MongoDB server without authentication enabled, create that admin user, and restart the MongoDB server again with authentication enabled.
I highly recommend you read to complete documentation how to enable authentication first to understand the complete concept, before you follow it step by step. Otherwise it might be confusing and creating such state you are currently locked in and cannot continue with all actions.
I am using Azure SQL database with sharding (single tenant approach). So, when the application connects to DB it goes into Shard and creates a proper connection to the tenant's DB (tenant is identified by login name).
However, we've been using a server admin credentials for that on a development stage.
Now, I'd like to create a separate application user with much more limited permissions compared to server admin.
In a very general case, what I want is to have a user that can connect to the Shard Map and figure out a connection string to any of the Shards, but have different permissions for each of the shards. For example, some application user may need to be able to connect to DB_1 with full read-write permissions, to DB_2 with read-only permissions and no permissions to connect to DB_3.
In a simpler case I just need a user that doesn't have any update permissions to ShardMap and other internal databases, but has a normal read/write/execute access to all tenant databases(shards).
I was googling around and din't find any good recipe how to do that, what are the best practices, etc.
I'd appreciate if someone could answer me or point to a docs.
Thank yuo!
In each database create a role for the Application Users, and grant the minimal permissions needed for the application to run. Granting permissions on the Schema level is a good choice here, as you don't have to manage object-level permissions.
create role ApplicationUsers;
grant select, insert, update, delete, execute on schema::dbo to ApplicationUsers;
Then if you want a single identity to access all the databases, create a login with a password. Then in each Tenant database create a user mapped to that login.
--create a server-level Login
create login AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
--add a user mapped to that login in each database
create user AppUser for login AppUser;
alter role ApplicationUsres add member AppUser;
Or create a user in each database with a different password or a database user mapped to an Azure Active Directory identity.
create user AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
alter role ApplicationUsers add member AppUser;
or
create user [tenant123user#mydomain.onmicrosoft.com] from external provider;
alter role ApplicationUsers add member [tenant123user#mydomain.onmicrosoft.com];
For my application I decided that every user that is created via application and that is added to the database table Users is automatically added as a server login and database User. I figured out that it would help me keep track of logs allow me to and use Sql password policies (like password expiration).
I can insert a row into Users table with no problem and login, user and schema is added to the server/database via trigger. When I log in as a created user, I can then select, modify, delete data and create additional logins/users.
I decided to use Application role to allow all the users to have the same permissions. It works okay, but using Application role I cannot add new logins/users, I cannot reset or change their passwords either. Sql displays
User does not have permission to perform this action.
When I create new connection and not set application role, all users can create new users/logins etc.
As I'm new to Sql security, how do I grant those permissions not to users, but to the application role?
I would be very grateful for your help.
What is the best-practice to create a read-only user for a specific database?
I created a new user and granted the db_datareader role, however, this user still has access to the master db and other system databases. is that ok? or should i deny access on some system tables/databases as well to make it more secure?
Thanks.
Ok, so if i create a new user, will he have any more default permissions i have to deny?
if i do
~create login
~create user for login..
~grant EXECUTE for user
will the user only have EXECUTE permissions or will he have additional permissions as well for the active database?
Hi I believe the user can view other database in the object explorer too.
CREATE LOGIN me with password = 'me', check_policy = off
sp_changedbowner 'me'
GO
USE MASTER
GO
DENY VIEW ANY DATABASE TO me
GO
Well you can use denywrite as an role option. The user has to "see" the master, because the master contains the list of databases that he will enventually connect to, but he will only have guest privalages there. You can then deny access to other specific databases. AFAIK he does not need to see tempdb or msdb as its the SQL engine that accesses these
I am trying to create a SQL server login and database user from within my application, along with a custom application user row. I want these users to be able to create other users - i.e. the application will control who can/can't create users but I need all users to have permissions for creating SQL server logins and database users.
I have got the server login permissions working - i.e. an existing user/login can create a new login - by adding the logins to the 'securityadmin' server role - which grants the 'ALTER ANY LOGIN' privilege.
I tried to do the same with the database users - adding them to the 'db_accessadmin' database role - which supposedly grants the ALTER ANY USER privilege, which is required for CREATE USER.
However any time I try to create a new database user using a user with the above privileges I get a permissions exception.
I have tried manually granting the ALTER ANY USER permission to a particular user (GRANT ALTER ANY USER TO demouser) but this doesn't work either.
Technically, yes. Whether it's right or wrong... no comment.
Anyway, database security is split into 2 functions:
db_accessadmin to manage users (or "ALTER ANY USER" permission as you mentioned)
db_securityadmin allows you to manage roles memberships and object permissions (or "ALTER ANY ROLE permission)
This is mentioned for sp_addrolemember.
You are actually changing the role, not the user, by running sp_addrolemember so "ALTER ANY ROLE" is enough without having full db_owner rights.
My bad - I have found the issue - it was not the CREATE USER that was failing, but a subsequent call to 'sp_addrolemember'. This requires further permissions that I wasn't assigning.
In particular I needed to add my users to the db_owner database role in order to allow them to assign other/new users to fixed database roles.
Is there a cleaner way to allow me to achieve what I am trying to do here - i.e. create users that are allowed to create other users?
This seems very dangerous, easily becoming a security nightmare. Not knowing anything about why you think this is the best solution to accomplish your objective I can't really tell you not to do it this way, but wow!! - I would think long and hard about whether this really is necessary. The spider-webbing of users just seems like it could quickly be impossible to manage from a DBA perspective.
Would you not be able to just have one SQL account that has the permissions to add users, and the application uses that every time to add new users? Those users then would not need the ability to add other users. Maybe this won't work for your specific objective, but surely there is some other way.
But having said all that ... no, there is not really a cleaner way. The user would have to be assigned to the correct roles in order to have the ability to later add other users.
/*
TOPIC: create a login ,who can add other logins to databases (securityadmin server role)
*/
USE MASTER
GO
Create login securityTestLogin with password = '##somepassword123'
-----add this to server , this is server level security role -------
EXEC master..sp_addsrvrolemember #loginame = N'securityTestLogin', #rolename = N'securityadmin'
--- first this login should be a user in database where we want to give other users access
USE HTDBA
GO
Create user securityTestLogin for login securityTestLogin
EXEC sp_addrolemember N'db_accessadmin', N'securityTestLogin'
-- depends on your requriemtnt you might also want this permission too
--EXEC sp_addrolemember N'db_securityadmin', N'securityTestLogin'
GO
------ Now we think about adding other users to different database roles -------------
/*
There is one gottcha , db_securityadmin role cannot add users to the fixed database roles ,only
db_owner can perform this action , but for security we don't want to give this permission .
so we need a work around
Create a role with required permission and then add users to that role.
*/
--Create user defined database role Readers
EXEC sp_addrole DBUser
-- Add this role to fixeddbroles to get database level permission
EXEC sp_addrolemember db_datareader, DBUser
EXEC sp_addrolemember db_datawriter, DBUser
GO
--------READY TO TEST --------
------ we are using this sample login for test
use master
Go
Create login testlogin1 with password='##somepassword123'
use HTDBA
go
Create user testlogin1 for login testlogin1
--- now add this user to user created DBUser role .
EXEC sp_addrolemember DBUser, testlogin1
A very good article on SQL permissions:
http://www.sqlservercentral.com/articles/Security/sqlserversecurityfixeddatabaseroles/1231/