What are some of the best practices for securing database connections and network protocols?

Data should be encrypted in transit and at rest. Restrict connection, allow connection for trusted networks only Encryp backup and use immutable storage

In transit encryption is an essential security measure. This is also a requirement of many compliance programs. However, the databases themselves should be encrypted as well. Another area of security that is often overlooked is the backups, which also need to be encrypted. This will protect them in the event of a breach. A strong password should be used, no less than 16 digits alphanumeric. If an attacker exfiltrates a backup, they have an unlimited amount of time to try to crack it. A strong encryption protocol and long complex password helps defend against brute force decryption of protected databases.

For oracle use native network encryption(NNE) is simple and easy to configure. Few entries in sqlnet.ora file, reload the listener and it's done.

Use TDE transparent data encryption feature of oracle database to achieve the data encryption at rest in oracle database. For achieving data encryption in transit can make use of oracle native network encryption or TLS.

Unencrypted data could be easily sniffed, collected, or modified on the fly, so it is crucial to use network protocols with encryption enabled and properly configured. Build an infrastructure with a trusted certificates authority, which will issue and validate all the certificates in your network automatically. Don't use manually generated and/or self-signed certificates - this is the place for misconfiguration and human factor mistakes. When configuring certificate generation, use non-standard strongest encryption algorithms with long enough keys. Use a secret manager to store private keys, API keys, application credentials, and other secrets, used by different parts of the infrastructure to integrate and work together.

Use the company standard password manager to store, generate, share, and manage passwords. Generate long, cryptographically strong, and not memorable credentials - users won't even try to remember them and use the password manager. Configure automatic password rotation where technically possible - even if a password will leak, it will be replaced quickly. Use MFA (multi-factor authentication) with hardware keys and biometrics to secure the password manager, physical access, and all human auth channels. Clearly define (and constantly audit) the complete set of authorization roles in your company with expiration time and "only required" rule followed.

In my experience Role Based Access Control (RBAC) is great way to enforce the principle of least privilege. RBAC is a great way to segregate access and permissions based on roles. When it comes on Authentication Multi Factor Authentication can act as additional layer of security.

strong password policies, MFA, smart card maybe. MFA reduces the risk of unauthorized access even if passwords are compromised. The least-privilege principle should be applied, and role-based access control as well.

Vault can be used to store username and password against secrets . Clients can use this secrets to get username and password to authenticate . Vault is most widely used, popular and feature rich open source secrets manager . Vault is cloud agnostic, secure, highly used and battle tested. Vault works perfectly with EKS, GKE, and anywhere where we can run Kubernetes. Further , Encrypt your Secret into a SealedSecret, which is safe to store. The SealedSecret can be decrypted only by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.

If your database technologies support zero trust or at minimum JIT Just In Time access leverage it. Ensure logging and auditing enabled to ensure access is removed.

The firewall that protects the application core sub-network (the internal sub-network, where only application modules exist), should be configured in white list mode: it should block everything except intentionally allowed traffic, carefully described in the rules. 1st of all you need to decide whether you ever need direct access to the DB from outside the application core sub-network. If not, then just don't expose the DB to an outside network. But if yes, then decide, do you need it permanently or only from time to time for debugging and investigations (in this way you could open the communication channel to the DB for a short time only). Use non-standard ports and block ICMP traffic to make malicious service discovery a bit harder.

If your databases running in a cloud service, leverage private endpoint as much as possible. Private endpoints ensure traffic doesn’t leave your private VPC.

The implementation of a VLAN segmentation could be an additional security layer by dividing the network into isolated segments.

Install a DB monitoring agent from your global monitoring solution (I hope, you have it, but if not, you definitely need to deploy it). Configure it to collect and report all available DB activity data, including activity and security logs, performance metrics, errors, failures, and other exceptions. Configure notifications and automatic (preventing and/or recovering) actions in case of reaching a threshold of each collected metric, unusual/suspicious activity, or exception detected. Regularly audit the set of monitoring rules and corrective actions, collected logs, and metrics to make sure that you don't miss anything and that there are no false positive/negative detections.

You need database auditing for several reasons. You need auditing for risky users in your databases, and at the same time, you can create audit policies for sensitive data, security-relevant events, and activities recommended by compliance regulations such as GDPR and CIS. All you need is a good database activity monitoring (DAM) solution that can help you monitor and protect your sensitive data while generating real-time alerts on any suspicious activity initiated by hackers. Oracle Audit Vault and Database Firewall (AVDF) is one of the most popular DAM solutions. You can get real-time alerts on your e-mail for any unusual activity in your database, and you can leverage several in-built reports (e.g., the before-after value report).

Something important is the principle of "Least Privilege" that mandates that users, applications, or processes be granted only the minimum permissions necessary to complete their designated tasks. Within the context of database security, this means assigning limited access rights based on specific needs. For instance, an application that merely reads data shouldn't possess write privileges. By restricting access in this manner, the potential damage from security breaches is minimized, as intruders or compromised applications are constrained by the limited permissions they inherit.

IDS systems will assist in real-time monitoring to detect suspicious patterns or behaviours. this will in turn trigger alerts accordingly.

One of the biggest causes of vulnerabilities (in addition to misconfiguration, caused by human-factor) is the existence of unpatched components in the company ecosystem. Talking about DB, I think that minor patches must be installed automatically during daily maintenance timeslots, as DB vendors pay extra attention to the compatibility and stability of minor patches and it is usually safe to rely on them. You need to track the release roadmap, schedule, and end-of-life of your DB on the vendor's site to plan in advance and follow the major release plan. According to that test and migrate to the new major version of the DB, once it is released and stable enough.

Talking about security, the most important part is related to the administrator being fierce guardians of the best practices for access and security policies. Also, a good internal communication related to these "rules" created by experts can increase user awareness and improve participation in the security culture inside the organization by showing the importance of keeping safe the information.

This is one of the most important steps - best practices, as you want to make sure that in future, your team would help to contribute to a cleaner dataset.

The human factor is the one of main causes of vulnerabilities, so for sure you have to regularly train all users (including admins) according to their roles. Periodically you need to safely (but realistically) simulate some malicious activity to test how your users will react and behave. Then you need to run a lesson-learned session or retrain them according to the results. But the most important mitigation would be to minimize the impact of human factor by automating a routine, auditing logs and configs, and periodic system testing.

Always ensure to review and follow the best security practices based on the database. For example when working with Postgres avoid using trust authentication method in the pg_hba.conf file. Prior PostgreSQL 15, users can create tables or write data to Postgres public schema by default which should be revoked. If working with SQL Server ensure to set a hard password for sa, rename, disable sa and ensure no other accounts exists with sa name. When working with MongoDB enable Role-Based Access Control. Change default passwords when working with Oracle databases. These are just some examples but it always recommended to leverage the related database security documentation.

Something else to consider is access trends and behavior. Are your users accessing the database only through the approved client or is someone finding a work-around to access the data using a non-standard client? Is the approved client properly patched at the appropriate level? Lastly, are your users accessing the database outside of their normal work hours? Answers to these questions can uncover potential in-progress attacks that may otherwise be easily overlooked.

Do periodic backups to the offline storage. Using a DB without periodic backups would be the biggest mistake. Use offline storage, which is connected to the DB only at the backup/restore time - this will ensure that it is safe in case of some system failure or malicious activity going on. Test your backups for integrity periodically.

Incident Response Plan: What is that? To have and keep a well-defined procedure for how to respond in the event of a security breach. This includes identifying the breach, containing the damage, notifying stakeholders, and restoring services at least.

In my experience, it's a good idea to use SQL grant and revoke to restrict user and connection access to be able to only access the specific data (rows and columns) that's relevant. (Database roles can be used to grant or revoke access to more than one user at a time.) Normally application programs that connect to the database through the RDBMSs API only bring back the data that they need, but sometimes their underlying access is left at default meaning that the userid used may be able to access more data than the program need and more that is strictly necessary. If the userid becomes compromised having a tighter grant/revoke for each database user/connection/program may help reduce the risk of exposure of sensitive data.