Database Security: The Fundamentals and the Future of Database Security in the Cloud

Most businesses today are using cloud-based services to house their data without realizing that operating in the Cloud fundamentally changes the rules of database security.

Let’s dig into the basics of traditional database security to understand what works, where there are gaps, and what you can do to protect your company and your users.

What is Database Security:

Database security refers to all the techniques a company uses to protect and secure its databases. In the accelerated arms race of cyber defense, database security professionals are continuously evolving their tactics in response to new threats and changing environments. The scope of database security has evolved, as well. Once focused on access controls and perimeter defense for the database itself, database security now covers management and data classification systems and all the tools and 3rd party applications that have access to the database. Database security today means making effective use of a powerful toolkit of practices and technologies to defend your company’s entire data estate against intentional or accidental breaches as well as internal and external threats.

Why do organizations need to worry about database security?

The basic requirements of database security are determined by regulations like GDPR and CPRA. So at a ground level, all companies that store personal data are required by law to secure their databases. But data compliance with these regulations is only a starting point; the laws are new, and their limits and interpretations are still being  determined in courts.  GDPR compliance doesn’t guarantee protection against data breaches. Checking off boxes to meet the bare minimum of regulatory data compliance won’t protect your company in the face of a cyberattack holding your database at ransom or a disgruntled employee publishing internal documents, selling client lists, or exposing your intellectual property. In order to protect your company’s reputation and bottom line, database security needs a comprehensive approach because data breaches are happening  every day. The global average  cost of a data breach is $4.24 million, and it’s not just big businesses that suffer: more than half of small businesses that experience a cyber attack  never recover.

Traditional Database Security

Historically, companies stored amounts of data that were orders of magnitude smaller than the data estates organizations now generate. That data was typically stored and protected in-house and accessed by a limited number of users. The rules of the game for database security were developed in this context, and they still guide how most database security plays out today.

Traditional database security operates on three levels.

1. Database Level

At the database level, data security has revolved around four main practices:

Database encryption relies on an algorithm to convert plain text data into a cipher, protecting against misuse if a bad actor were to gain access. Encryption is an important requirement of regulations like the Payment Card Industry Data Security Standard (PCI-DSS), which requires that cardholder data be encrypted using industry-accepted algorithms, truncated, tokenized, or hashed and also outlines rules for encryption key management.

Encryption needs to be a consideration for data at rest — that’s all persistent data, as well as data backups — and data in transit. Data in transit — for example, between a server and client webpage — can be particularly vulnerable to theft or alteration, and so encryption before transfer, and decryption upon arrival, is considered best practice for all private and protected classes of data.

Data Masking refers to a range of practices which can include encryption, as well as scrambling, substitution, nulling out, and other techniques for replacing real data with a fake-but-useable version that can be shared across departments for testing, development, and training without putting the real data at risk. Data Masking techniques are specifically oriented toward protecting private data from insider threats, and it’s mainly applied to database backups and during data mining.

Data tokenization is a technique that comes from the credit card industry, though it’s more broadly used today. Tokenization replaces personally identifiable data such as credit card or social security numbers with a surrogate value. The key to reversing that process is stored in a separate database.

Physical database security has involved a range of best practices to protect the physical servers where private data is held: locking rooms, monitoring access, etc. With the industry shift to cloud-based data storage, these practices have become largely obsolete.

2. Access Level

Database security has traditionally aimed to control access to private data by organizing users according to different authorization models, allowing for different privileges.

Access Control Lists such as DAC and MAC provided a starting point for authentication and authorization. Discretionary Access Control or DAC allows the data-owner to determine access, providing a distributed and flexible model of access control but with low security. In a system of Mandatory Access Control or MAC, access roles are determined by security clearance, set in place by an administrator, and executed by the operating system. MAC offers a high level of security, but it’s difficult to maintain and to scale.

Role Based Access Control (RBAC) organizes users by role, and access is granted based on those roles or categories of users. In this methodology, the key security principles of "least privilege" and "separation of privilege" come into play. ABAC or Attribute Based Access Control adds a finer-grain level of security by assigning attributes to both users and resources and then assessing whether access should be granted dynamically based on attributes, including time of day and location.

Access Privileges determine what a user can actually do to the data they have access to. System privileges allow the user to CREATE, ALTER, or DROP database objects. Object privileges allow the user to EXECUTE, SELECT, INSERT, UPDATE, or DELETE data from database objects to which the privileges apply.

3. Perimeter Level

Database security at the perimeter level involves three main methods of building a wall around your data:

Firewalls and Web-Application Firewalls: Traditionally, a network firewall protects a secure local-area network from unauthorized access. A web application firewall (WAF) protects web applications by acting as a barrier between external and internal network traffic, analyzing all HTTP communication to detect and block malicious requests before they reach users or web applications.

VPNs: A Virtual Private Network or VPN makes use of technologies such as Internet Protocol Security (IPsec), Transport Layer Security (SSL/TLS), or Datagram Transport Layer Security (DTLS) to keep devices secure while using public networks, by forming a private network for company data.

User Authentication: Otherwise referred to as an “Identity firewall,” systems such as SSO or Single Sign On tailor authorization-based factors, including user identity, role, location, device, and more.

The Cloud has fundamentally changed Database Security

As companies radically expand their data estates across data warehouses, databases, and other data stores in the Cloud, the challenges to data security grow exponentially.

Companies have more data to protect, more employees and stakeholders wanting access to data, and more kinds of tools to get that access (from BI tools to SQL command line, APIs, and  data pipelines). In addition, the very environment itself has changed, and with it, the rules of the game.

Data Loss Prevention solutions all try to detect data crossing through a perimeter. But cloud database storage dissolves the perimeter, and with no perimeter, DLP becomes impractical, if not obsolete.

Manually managed systems like MAC are left in the dust by the speed data moves in the Cloud. New database instances can be spun up (and down) with a few clicks of a button. Security teams can’t keep up with the speed of DevOps. The result is a rapidly multiplying, unmapped universe of insecure database instances.

To keep up with the Cloud, a new, automated approach to database security is needed

In order to adapt to the paradigm shift of storing data in the Cloud, and to future-proof database security in this new fast-changing context, security systems must:

• Automatically discover new databases in the Cloud
• Automatically find and fix database misconfigurations
• Automatically detect when new fields are added to databases
• Automatically classify the data contained in those fields
• Automatically keep track of data lineage to archive and delete data sets

The approach that’s required will promote seamless collaboration with the Data Team, notifying the Data Team when a new field is found and classified and allowing the Data Team to quickly and easily confirm or change the data classification. It will automatically detect over-permission to sensitive data and monitor data-in-use.

Much of Database Security has historically been about access control. The industry needs to assume that database credentials can and will be compromised, and zero trust needs to be applied within the database. The only way to take a zero-trust approach within a database is to monitor actual data in use with sophisticated tools for automating that analysis and empowering collaboration within data and security teams.

Dasera is the only coherent solution to the complexity of database security in the Cloud. Find out more.