Hot answers tagged

6

First and foremost this is an issue of access control. Eliminate all redundant logins, and reduce permissions on the required logins to the strictly necessary minimum. Do not use 'well known' logins shared by every person with DB access, make sure every user uses its own login (eg. use Integrated Auth). It is not clear from your post whether this server is ...


4

DB_NAME does not work as advertised before SQL Server 2016 (where the behaviour of DB_ID is also changed). For details, see: Information disclosure with the db_name and db_id function (Connect bug report) There is a similar situation with other metadata functions, including: suser_name suser_sname suser_sid user_id database_principal_id is_rolemember ...


4

The security concern with SMTP from a database server is the potential for disclosure of sensitive information. For example, a user that has (or gains) permissions to execute sp_send_dbmail could send an email with sensitive information. Disallowing outbound access to the default SMTP port is a security measure security folks sometimes insist upon to limit ...


4

Yes. What you have will do what you want. I do question the need for UserA to have db_owner access even on database A though. Do they have a need to be able to drop the database? Run backups that could interrupt your backup chain? Change recovery model (same problem)? Generally even if a developer has complete control over a given database I would ...


4

I'd talk to your hosting provider's technical support people about this and get them to explain to you the security configuration they have on the msdb database, which is where those details are stored. By itself, the list of database names likely does not indicate a security risk. I'd ensure I wasn't giving away any details in my database names. If I had ...


3

In and of itself, no, you are probably not adding a security risk. As long as no one but a sysadmin can alter the procedure and as long as the ONLY thing the procedure can do is start a job I don't see a problem. The risks come in with the fact that MSDB is (and is supposed to be) marked as TRUSTWORTHY. That means that by using EXECUTE AS OWNER you are ...


2

Create the procedures with AUTHID DEFINER option (this is the default if you skip this clause) in a schema who has the ALTER USER privilege. Them simply grant execute on these procedures to NOC. NOC does not need any other privileges, as the procedures will run as if their owner would have called them.


2

Certs from trusted CAs (like VeriSign) are used when you need a certificate that must be able to prove its issuer, purpose, validity, etc... Certs for data encryption like Always Encrypted typically do not require such proof since your certs typically don't float beyond your org. I don't know of any use case where you would benefit from using a 3rd party CA ...


2

The servers I was looking at had only few credentials. While they had several jobs only a handful were using “Run As” Proxy credentials. This is the solution I used. First query shows the account (credential identity) linked to the proxy Second Query shows what Job and Step is using a Proxy -- Search Credentials (shows account for Name) use msdb ...


2

You need to investigate "Logon Triggers" (from memory they are available from SQL 2008 upwards). In the trigger you should be able to restrict logon attempts to specific hosts/applications only. Note: this is not a bullet proof solution but it will make it a little bit harder for your hacker. CREATE TRIGGER [tr_logonLogger] ON ALL SERVER WITH EXECUTE AS ...


2

The main issue here for me is how a web user was able to truncate the table. I would have a serious look at the permissions assigned to the tables and limit what can be done. If users only need to be able to read data then only allow them select access, if they need edit, give them select, insert and update etc... Work on giving them the least amount of ...


1

You can also use the GUI to do a quick check on all jobs using a single proxy. In object explorer navigate to the proxy Right click on the proxy and select properties. Then go to the references tab. That will list all jobs/job steps that use a given proxy. Obviously a query is better for mass checks but this works for spot checks.


1

Streaming replication in PostgreSQL uses the same security mechanisms as a normal frontend-backend connection. So in order to encrypt the traffic, SSL should be used, and access control should be set up. Alternatively, or additionally, consider a VPN of some kind. PostgreSQL instances aren't really meant to be run facing the open internet.


1

Answer to 2) question - Most probably you had some minor version upgrade for your master 5.5 MySQL server. There is a bug for 5.0 - Bug #50876 and according to my experience, the same bug exists in 5.5



Only top voted, non community-wiki answers of a minimum length are eligible