One of the hardest thing to do is prevent something from happening when you don’t know when it might happen or who will try to make it happen. As a Database Administrator, you have to be aware that a data breach might happen and you must take reasonable precautions to prevent them. According to the 2016 study by IBM, 60% of database attacks are insiders (people using approved network credentials) looking to access or steal corporate data.
There are some basic steps you should execute to help prevent unauthorized access to your database environment.
- Enforce Privileges – As an employee starts their tenure at a company, they are usually given the exact correct privileges for their position. The longer the employee is with a company, the correct privileges start to vary from the effective privileges, until eventually the employee has the wrong access privileges. You need to make sure those initial access rights are correct from day one, and that you periodically review the access rights for every employee. If there is any question about the correct privileges, you should contact their supervisor and document the correct level of access.
- Database Discovery – People are busy, and don’t always pay attention when new database instances are created. The people who manage the databases are often times not the people who install the software, so this can lead to an environment where there are unauthorized or poorly configured database instances. Database discovery is a crucial first step for avoiding security issues, so you should scan your environment for new database instances as often as possible. The amount of change in your environment will dictate how often you should search for new database instances, but the minimum is annually.
- Connection Encryption – Encrypting the connection between the user and the database can help prevent man-in-the-middle attacks.
- Strong Password – You should expect the same password strength for your databases as you expect on the network. If possible, use Windows Authentication instead of SQL Server Authentication. This will help enforce the same password strength as your network password, and you must verify that the network settings are using best practice strength requirements.
- Detect Compromised Credentials – It is estimated that 60% of companies cannot detect compromised credentials, based on a study by solution vendor Rapid7. Since authorized individuals use databases in a predictable way, abnormal or unauthorized access will be detected and you can be alerted. There are security appliances that can catch unusual or unwanted user access based solely on algorithm analysis, preventing a possible data breach.
Some people believe that their computer systems are more secure if the person attacking their systems don’t know some facts, like what port their SQL Server instance is using or by not disclosing the written specifications for critical software functions. Those people believe that if malicious attackers don’t know how the system is secured, security will be better. Although this might seem logical, it’s actually easy to see how it is untrue if you think about if for a few minutes. Insider attacks by employees, one of the most common forms of an attack, will already know the port used or how your software works.
The problem with security through ignorance is it just leads to a false sense of security, which is usually much more dangerous than not doing anything at all. Assume you are working with an intelligent attacker, and that your weak half-attempts to secure your systems will delay the attacker all of about 2 minutes. Spend your time and effort for implementing true security measures and you will sleep better each night.
To understand SQL Server index fragmentation, you have to first understand how SQL Server stores data. You may already know that SQL Server stores data on 8KB data pages, and that eight contiguous data pages form an extent. Each data page in both in clustered or non-clustered indexes contains data and pointers to the next and previous pages.
As data is added to a table, the index data must be saved to a data page. If there isn’t enough room on an existing page, the SQL Server engine will create a new data page to store the data, but it must also adjust the pointers on the existing data pages to reflect the new sequence of the impacted data pages. This also means that a new extent might have to be created. These new objects may be stored in a completely different part of the storage drive. This causes both database and disk fragmentation, which can make performance an issue over time.
Continue reading “Understanding SQL Server Index Fragmentation”
The “sa” account is a critical account on all versions of SQL Server. If you forget your “sa” password, it can cause problems. This article will help you identify the steps required if you have forgotten the password of your “sa” account of your SQL Server instance on Linux.
The mssql-conf utility is a configuration tool that installs with SQL Server on Linux (Red Hat Enterprise Linux, SUSE Linux Enterprise server, and Ubuntu). This handy tool as a replacement for SQL Server Configuration Manager which exists when you install SQL Server on Windows.
Reset the “sa” account password
- Connect SQL Server using command-line tool with the existing password to make sure that your current password is working. You will skip this step if you don’t know the password.
sqlcmd -S <SQLInstanceName>-U <UserName> -P <Password>
- To change the “sa” password, first stop SQL Server service on Linux:
sudo systemctl stop mssql-server
sudo systemctl status mssql-server
- Reset the “sa” password by creating a new strong password :
Note: When you are resetting/changing “sa” password using sqlcmd in a bash terminal, you must not use the special character “$”.
- Start and verify the status of SQL Server Service:
sudo systemctl start mssql-server
sudo systemctl status mssql-server
- Connect SQL Server with the new password:
sqlcmd -S <SQLInstanceName>-U <UserName> -P <Password>
- Once you are successfully connected, you know the new password is correctly altered.
Change password using sp_password
- Login with any User account that has sysadmin access on the server.
- syntax: sp_password NULL, ‘<insert_new_password_here>’, ’sa’
- command :-
sp_password NULL, 'Admin@1433', 'sa'
- Log into the SQL Server instance using the “sa” account and the new password to verify it has been successfully changed.
When creating a new database instance, people will often make mistakes. While I can’t list all the mistakes that people can or will make, I hope this brief list will help you know what mistakes are possible, and help guide you to not making as many mistakes. Sometimes we attack a design problem with the idea that we will just get the work done, but most times it is better to take the extra time to do it right.
I’m not perfect, and I have made these (any many other) mistakes in database design. I’m not trying to tell you what to do or even how to do it. I’m just trying to take my lessons learned and provide a simple list so that you might not make the same mistakes. I also want to point out that no list will ever be the only way to do anything. With database design questions, the best answer is usually “it depends”. When considering the many variables that make up your environment, you will need to make many decisions that help your database instance work best in your unique environment. You have to take into account the personnel you are working with, limits of your hardware, company policies, etc.
Continue reading “Common Database Design Mistakes”
The Master database is important to your SQL Server instance. This database records all the system-level information for your SQL Server system. This includes instance-wide metadata like logon accounts, endpoints, linked servers, system configuration settings, and records for the existence of all other databases and their file locations.
SQL Server cannot start if the Master database is unavailable. The core information of master database is recorded in a physical file called master.MDF files, and the transaction logs are stored on to the masterlog.LDF file. This means the all user and login details for the instance and the information about all the other databases on that instance are stored on the master database.
If anything happens to the master database you can’t start or use your SQL Server instance. As a Database or System Administrator, it is essential that you to know the symptoms that may indicate the corruption or damage in your Master database so you can troubleshoot those types of issues correctly.
Continue reading “Rebuild and Restore Master Database in SQL Server”
You may want to log the event each time a user logs into your database. This can be easily done by starting SQL Server Managements Studio (SSMS) and running the following code in Transact-SQL: Continue reading “How to Create a SQL Server Logon Trigger”