We had an issue yesterday that we are trying to figure out. Out of nowhere everything on the database changed,
We know it was an update without a where clause, but we are just a few developers. So if any of us would have done it we would know it.
It was at a strange time of the day, very late at night and only a few ip addresses are allowed into the server.
Is there any way to get the full log with ips of all the transactions on azure?
Did anyone had a similar problem? can it be a break through?
Are there any software protections, scripts that we can add to limit this?
Is there any way to get the full log with ips of all the transactions on azure?
Few options i could think off,Even this is not possible in onpremises..if you don't have correct measures to detect this...else contact support for a request to read TLOG of the database(Azure support won't read the log,unless you have a business justification,as this involves involving many teams due to safety reasons)
1.) You could use activity log to know more details..
2.) There is an sys.event_log (Azure SQL Database) DMV ,which shows connections successfull or not .you can correlate to know the users based on your office set up..this won't show success or failures
To avoid this happening again,Audit data and Azure offers many features to know more on whats happening like
1..Get started with SQL database auditing
2. Enable rules to get alerted when some thing happens..
Enable Auditing and Threat Detection on the server if you hadn't
For more information, please read this page.
Related
I've got a writing and reading database application holding a local cache. In case of an application server fault a backup server shall start working.
The primary and backup application can only run exclusively because of its local cache and some low isolation level on the database.
As far as my communication knowledge goes it is impossible to let both servers always figure out who is allowed to run exclusively.
Can I somehow solve this communication conflict through using the database as a third entity? I think this is a quite typical problem and there might not be a 100% safe method, but I would be happy to know how other people recommend to solve such issues? Or if there is some best practice to this.
It's okay if both application are not working for 30 minutes or so, but there is not enough time to get people out of bed and let them figure out what the problem is.
Can you set up a third server which is monitoring both application servers for health? This server could then decide appropriately in case one of the servers appears to be gone: Instruct the hot standby to start processing.
if i get the picture right, your backup server constantly polls the primary server for data updates, it wouldn't be hard to check if the poll fails, schedule it again for 30s later 3 times and in the third failure dynamically update the DNS entry to the database server to reflect the change in active server. Both Windows DNS and Bind accept dynamic updates signed and unsigned.
In our college, we are conducting a contest, which is in the form of Multiple choice questions.
For that we are using VB as a front-end , MS Access as a back-end.
Ref:
The Application VB 6 runs with no problem and the participant entry is added into the database along with their scores, when 1 or 2 clients access the database simultaneously.
Problem:
But when more than 2 clients access the database simultaneously, the Application crashes.
1.In some clients, we are getting runtimeerror printing some large negative value with a
message "Operations query cannot modify the database".
2.In some clients, the VB 6.0 crashes and closes suddenly.
These errors occurs when we are tried to access the database using
OK,SUBMIT buttons.
Could you tell me why this error occurs and how can I correct it.
My Questions are..
1.Is giving the burden of all clients to a single laptop is the problem here?If there is some other problem please explain it.
2.Why I am getting the error as "Operation query cannot modify database", If so then how it works when 1 or 2 clients access the database simultaneously.
Access databases (and other directly file-based DBs) are not really built for multi-access. There are some facilities in place to help it work, but in my experience, it is quite unreliable.
You need a database server running, which can allow multiple clients to the same database simultaneously. A free option is MySQL. There is also a free version of Microsoft SQL Server available.
"Operation query cannot modify database"
Badly designed Access databases can have issues with users trying to modify records if they don't have defined Primary keys. This is especially true when multiple people are accessing because it literally can't tell which record to modify if two people try to do the same thing. Sometimes it will let you insert but not update.
Further if you are looking for performance, Access is just the wrong tool. It has very little in the way of performance tuning options or abilities. SQl Server Express or mySQl would have more things available to diagnose and fix a performance issue.
I have a very strange and complicated situation. I have data being erased from one of my SQL Server tables, and I am not sure by what application. I would like to be able to track this.
As I am sure you are wondering how I could find myself in this situation, here is some background. We have 2 servers, Web and Database running IIS6 and SQL Server 2005 respectively. They were setup by the previous developer who left the company without giving me any sort of introduction to the system so I am left "hunting" for everything.. I have been able to figure out most of the system on my own except for this, which remains a mystery. All I know for sure is this:
Data is being erased at a set time every day (I have setup a TRIGGER to capture this)
It is not a SQL Server Agent Job
It is not a Windows Scheduled Task
It is not a Windows Service
All database logins are done with the sa user so login history cannot help me... (again, I didn't set this up)
How the heck do I debug something like this? If anything, I want to know if this is coming from something running on the database server, or from a request from an outside source. Please help :-)
As you know the time it happens you should set up a SQL Profiler trace at that time to catch the statements being sent.
This will show you the SQL being sent, the spid of the connection, user name, application name sent by the connection and other useful info to track down the culprit.
In case the time that it happens is not convenient for you to do this you can script SQL traces (which is more lightweight than running the full GUI anyway)
Edit: Be careful when using it not to record so much information that you bog down the server. You can filter for activity on the database of interest for example.
We have a requirement from a client to protect the database our application uses, even from their local administrators (Auditors just gave them that requirement).
In their requirement, protecting the data means that the Sql Server admin cannot read, nor modify sensitive data stored in tables.
We could do that with Encryption in Sql Server 2005, but that would interfere with our third party ORM, and it has other cons, like indexing, etc.
In Sql Server 2008 we could use TDE, but I understand that this solution doesn't protect against a user with Sql Server admin rights to query the database.
Is there any best practice or known solution to this problem?
This problem could be similar to the one of having an application hosted by a host provider, and you want to protect the data from the host admins.
We can use Sql Server 2005 or 2008.
This has been asked a lot in the last few weeks. The answers usually boil down to:
(
a) If you don't control the application you are doomed to trust the DBA
or
b) If you do control the application you can encrypt everything with a key only known to the application, and decrypt on the way out. It'll hurt performance a bit (or a lot) though, that's why TDE exists. A variant of this to prevent tampering is to use a cryptographic hash of the values in the column, checking them upon application access.
)
and
c) Do extensive auditing, so you can control what are your admins doing.
I might have salary information in my tables, and I don't want my trusted dba's to see.
Faced with the same problem we have narrowed are options to:
1- Encrypt outside SQLServer, before inserts and updates and decrypt after selects. ie: Using .net encryption.
Downside: You loose some indexing and searching capabilities, cannot use like and betweens.
2- Use third party tools (at io level) that block crud to the database unless a password is provided. ie: www.Blockkk.com
Downside: You will need to trust a third party tool installed in your server. It might not keep up with SQL Server patches, etc...
3- Use an Auditing Solution that will keep track of selects, inserts, deletes, etc... And will notify (by email or event log)if violations occurred. A sample violation could be a dba running a select on your Salaries table. then fire the dba and change everyone salaries.
Auditors always ask for this, like they ask for other things that can never be done.
What you need to do is put it into risk-mitigation terms and show what controls you do have (tracking when users are elevated to administrators, what they did and that they were de-elevated afterwards) instead of in absolutes.
I once had a boss ask for total system redundancy without defining what he meant or how much he was willing to pay and sacrifice.
I think the right solution would be to only allow trusted people be DBA's.
It is implicit in being DBA, that you have full access, so in my opinion, your auditor should demand that you have procedures for restricting who has DBA access.
That way you work with the system through processes in stead of working aginst the system (ie. sql server).
To have person you don't trust be DBA would be nuts...
If you don't want any people in the admin group on the server to be able to access the database, then remove the "BUILTIN\Administrators" user on the server.
However, make sure you have another user that is a sysadmin on the server!
another way i heard that a company has implemented but i haven't seen it is:
there's a government body which issues kind of timestamped certificate.
each db change is sent to async queue and is timestamped with this certificate and is stored off site. this way noone can delete anything without breaking the timestamp chain.
i don't know how exactly this works on a deeper level.
I need a quick "no" for DELETE/UPDATE/INSERT, since 3p reporting tool allows users to write their own SQL.
I know that I should probably add a new user and set permissions on tables/sp/views/etc..., and then create a new connection as restricted user.
Is there a quicker way to force a transaction or connection in SQL Server to read only mode?
I don't know. If the 3P tool is that crazy, I would be completely paranoid about what I exposed to it. I think that setting up a new user is the best thing. Maybe even just giving them certian views and/or stored procs and calling it a day.
Why are you worried about your users' ability to put arbitrary SQL in their reporting queries? If they have the rights to change data in your database, surely they can just connect to it with any ODBC client and execute the SQL directly.
I'm not sure it's 3P that's the issue here, it sounds more like you need to restrict your users but haven't.
If you have a class of users who shouldn't be allowed to change your data, then set their accounts up that way. Relying on the fact that they'll only use a reporting tool that doesn't let them change data is a security hole I could drive a truck through.
If they are allowed to change the data, restricting sessions from 3P won't help secure your system.
Unless I've misunderstood your set-up. I've been wrong before, just ask my wife. In which case, feel free to educate me.
Does it have to be with named users ? I have a "report" user and a "browser" user that just has select rights on most tables. Anyone that needs data uses those accounts and since they are select only I don't have to worry about them.
See Kern's link.
Change the permissions for the user (the one used in the connection string) on the SQL Server.
If you have control when the connection is created and closed the you could perform a BEGIN TRAN and then do a ROLLBACK at the end. That way anything this reporting tool does will be rolled back at the end. However, if it has the ability to manage these transactions or new connections, or if the user base is unknown and potentially malicious then it is not foolproof. In addition, any large transaction may result in your database being locked by your users actions
I have to say though, the real answer is security is allocated to users. The "quicker" way you're after is a new user with just read only permissions.