Everyone knows how important it is to save the never-ending Big data. But the degree of troubles is only experienced by the DBA who handles this and his/her other subordinates who are actually given the task to take care. There are several layers of authorization to different employees who work in an organization. This makes sure that all kinds of information is never exposed to everybody, but limited to an individual’s designation and role. Yet again, there are still a number of factors to be considered before one proceeds. The Database Administrator is totally aware of the importance of database security which is why he or she takes even the minutest things into account while planning to safeguard.
The thing is, the trial-and-error methods could be beneficial as well as proved to be a huge disaster, and the DBA has to take responsibility for what comes next after his/her decision-making. Even after taking perfect measures, there is no guarantee that the information will never be exposed to vulnerability. It might still be possible, but the chances could be minimized to a great extent. Following are the database security requirements that a Database Administrator should take note of before executing anything practically.
Database Security Requirements
When it comes to safeguarding the data, one must ensure that both kinds of information are considered – at rest, and in motion. As their names clearly imply, the details that are in store AND the details that are being transmitted, both ought to be encapsulated against any possible external threat(s). If a firm acts irresponsibly, the importance of database security will only be felt after it has already gone through a huge loss; others simply learn from one’s own or their competitors’ mistakes (using case studies).
The possible targets of hackers are user accounts of any kind (social networking sites, banks, etc.), emails, sensitive business data, healthcare data, and so on. The most effective method to get the notification regarding the breach is to create triggers in the database that could be fired right before/after the events like UPDATE, INSERT, DELETE, etc. are executed. Therefore, if someone even tries to retrieve the row(s) or make edits, the trigger will alert the DBA. Following is an example of the same:
Example of using triggers in the database for security
CREATE TABLE stud (utyp VARCHAR2(10), rowcnt INTEGER); CREATE OR REPLACE PACKAGE stat IS rowcnt INTEGER; END; / CREATE TRIGGER btrig BEFORE UPDATE OR DELETE OR INSERT ON sal BEGIN stat.rowcnt := 0; END; / CREATE TRIGGER rtrig BEFORE UPDATE OR DELETE OR INSERT ON sal FOR EACH ROW BEGIN stat.rowcnt := stat.rowcnt + 1; END; /
CREATE TRIGGER atrig AFTER UPDATE OR DELETE OR INSERT ON sal DECLARE typ VARCHAR2(10); BEGIN IF updating THEN typ := 'update'; END IF; IF deleting THEN typ := 'delete'; END IF; IF inserting THEN typ := 'insert'; END IF; IF SQL%ROWCOUNT = 0 THEN INSERT INTO stud VALUES (typ, stat.rowcnt); END IF; END; /
The above code will count the number of rows that are either updated, deleted or inserted, and then will write respective actions along with the count. This not only prevents from intentional gain but also from accidental changes. In order to minimize the human-generated errors, there should be some effective controls and procedures in place.
SQL injection is the most common form of illegally retrieving the database information. Although, most experienced DBAs have now learned how to counter it. Other common mediums are spearheading and malicious software. In general, we only suspect the hackers to be at fault, but there can also be other culprits behind. For instance, customer support staff, OS admins, or even DBAs themselves.
An employee who wants to gain control over the full server belonging to an organization might keep a secret agenda to torment the image and security, OR may do it out of vengeance. Since the Database Administrator practically knows everything, it is indeed possible that (s)he breaches into the security system.
Also, the customer support staff of respective banks should not know the whole information, but only part of it. If only last three digits of a bank account number are exposed, rather than the whole of it, would save millions of individuals from being looted. This is just one example of precautionary measures. There could be lots of it to take into consideration.
In large organizations, the DBA is not just one person, but a group of persons who are collectively determined to safeguard the Big data. They ought to create a policy to follow and review it every year so as to ensure that everything followed is up to the mark and the latest threats won’t affect. The database should also be scanned for misconfiguration and rectified if something is detected. The Team Leader of the DBA team should have full knowledge about those who have full access to the database. Checking for a number of factors on an yearly basis does not mean that one should not pay attention before that at all. The Administrator ought to know the importance of database security before the real misfortune and stay alert all the time.
It is also a good practice to change the username and password after a certain interval, and also while moving the data from the test environment to the production environment. Make sure that the password is not too obvious to be guessed and should only be given to those who hold the equal designation. The owner(s) of the organization deserve(s) the right to know all usernames and passwords each time these are changed. If the Administrator forgets to communicate properly and loses the document that keeps the passwords OR intentionally does not reveal the new security measures then that individual is not reliable and the firm is going to get shattered, sooner or later.
Moreover, extra precautions need to be taken while taking the backup. The procedure should follow encryption format. If possible, encrypt all crucial data by default and have a proper encryption key management system. This will not compromise the data security. Furthermore, if the firewall is in use, it will disallow the unnecessary SQL traffic that is unauthorized. This will also protect the database from buffer overflow attack. Now refrain yourself from assuming that firewall guarantees the protection. It simply minimizes it to a large extent.
Other than the row and column level security in which a number of individuals are confined to access just a part of the whole database, there is also another kind of accessing – cell-level access. It is the duty of the DBA to provide cell-level access to particular candidates and the related security in those particular cases.
Last but not the least, have an audit plan to effectively review the system logs, failed log-on attempts, integrity control checks, authorization protocols, use of system privileges, user-defined procedures, encryption, and other security threats. Although, everyone knows the importance of database security which is why deep research is necessary; nevertheless, the server admins should also discover new ideas other than just following the existing norms. Obviously, the protocols being discussed here were also once discovered by someone.