The Gramm – Leach – Bliley Act (GLBA) was enacted in 1999. Its purpose is to protect consumer financial privacy. In order to meet GLBA compliance requirements, the financial organizations must inform their customers about the company’s information sharing and privacy practices. Customers must be given and explained their right to opt out (to say “no”) – if they don’t want their financial information shared with certain third parties
The Sarbanes–Oxley Act of 2002, Sarbanes–Oxley, Sarbox, or SOX is a regulation created to improve the quality and integrity of financial reporting. It addresses audits, financial reporting and disclosure, conflicts of interest, and corporate governance, so financial and business information is factual and accurate. Its purpose is to avoid accounting scandals like the ones in 1990s stock market.
Configuring a safe and secure environment for your SQL Server instance is a complex task. SQL Server security must be set on the SQL Server instance, operating system, firewall, antivirus program, etc. But failing to set up security properly can bring a lot of headaches and even irreversible damage
The saying “An ounce of prevention is worth a pound of cure” is ever so true when it comes to SQL Server security. Even if everything seems fine with your SQL Server environment from a security standpoint (i.e. no unexpected slowdowns or increased network traffic; none of the data or the objects are damaged corrupted or missing), as we’ve outlined in several articles before, having an auditing system up and running can be literally a life savior when it comes to any suspicious activities, such as unauthorized permission changes or compromised SQL logins. So, how can one set up SQL Server auditing?
One of the most important tasks for a DBA aiming to keep database and the data in it secure and away from unauthorized access or, heaven forbid, malicious changes is to always stay on top of the effective SQL Server permissions his users have over the SQL instances as well as the databases, database objects and data stored in them. Although this might seem like a pretty straightforward task, as the number of database users grows on one hand, and the number of databases and objects on the other things can get really complicated. Add to that the ever changing business requirements, and soon, unless you have some kind of documenting system in place, you can end up with users not having sufficient permissions or even worse – users having more permissions that they actually require
Although SQL Server’s stored procedures help out with code security by hiding the implementation of the business logic and even protecting against some kinds of SQL injection attacks — primarily those that use an operator such as AND or OR to append commands onto a valid input parameter value, simply wrapping the code into a stored procedure doesn’t mean that applications, database and SQL Server are safe from all types of SQL injection attacks. So, how to make stored procedures bulletproofed against SQL injections?
It seems something went awry with the SQL Server. It’s sluggish, behaves erratically, produces heavy network traffic, there is a significant increase in the server processor or memory utilization, and to top it all there are reports of or database objects and data being damaged or missing.