Database Security: Part 1
Did you know that security breaches involving the cloud now surpass breaches involving on-premises infrastructure? According to the Verizon 2021 Data Breach Investigation Report, 73% of cybersecurity incidents involved external cloud assets—compared with 27% only one year ago. Having just joined Actian from a cloud security provider, even I was surprised by this tremendous surge.
This new insight has motivated me to review the security requirements for a modern cloud data warehouse. The topic turns out to be broad, so I’m writing this blog in two parts: part 1 focuses on database security; part 2 will focus on cloud service security. They’re related but separate issues, and you won’t have truly robust security in the cloud unless you address both.
Let’s start with a series of key questions that will help determine how secure the data in your cloud data warehouse really is. The critical database security features described below and summarized in the diagram on the right are all standard features of the Actian Avalanche™ hybrid-cloud data warehouse platform.
Database Security Questions:
Who can connect to the data warehouse?
At a minimum, a cloud data warehouse should require users to authenticate their identity using a unique login ID and password. Single sign-on (SSO) using Oauth allows a user to log into multiple independent software systems with one ID and password. Data warehouse support for SSO helps eliminate password fatigue for users and, more importantly, it can help you ensure that your organization’s identity policies are extended to protect your data warehouse. For added authentication protection, you can leverage your identity provider (IdP) to use multifactor authentication (MFA). This adds an extra level of security by requiring multiple methods of authentication (such as a password and a one-time numeric code sent via SMS to a known mobile phone number) before allowing a user to access the data warehouse.
What can users see and do?
The answer better not be “everything”. Your data warehouse should have access control features that limit who can read, write to, and update different data in the warehouse.
One discretionary approach to securing direct access to the data warehouse involves the use of an “IP Allow” list. This list limits access to those users with approved device IP addresses. When used in conjunction with the user authentication methods discussed above, an IP Allow list provides a valuable layer of additional security by precluding access to the data warehouse when a user’s credentials are correct, but the device being used is not recognized. An unscrupulous individual may have stolen a legitimate user’s credentials but won’t be able to use them to access the data warehouse unless the individual also has stolen a computer whose IP address appears on the IP Allow list.
A non-discretionary approach to access control is exemplified by Role-Based Access Control (RBAC). RBAC is a technique that grants access to specified resources based on an individual’s role in an organization. RBAC does more than just simplify user administration; it can also help enforce the principle of least privilege where users have only the privileges they need for their job function. This helps comply with privacy and confidentiality regulations. A grant statement can narrow down exactly what user or role is granted a privilege.
How can I ensure that users see only the data they should?
This kind of data access control can be enabled by dynamic data masking. This is a process by which original data is dynamically occluded by modified content. Dynamic masking is often used to protect fields containing personally identifiable information, sensitive personal data, or commercially sensitive data. Because sensitive data masking is a mandatory requirement for achieving PCI DSS, GDPR, and HIPAA compliance, it is a must for data warehouse security in industries governed by these regulations.
Who owns/has control over what?
Just as no individual should have access to everything in a data warehouse, no individual should be able to control everything in a data warehouse. What an organization needs is a database server option ensuring role separation. The idea is based on the principle of separation of duties where more than one person should be involved when completing critical or sensitive tasks. For example, role separation in the data warehouse could require that the person who determines what to audit (DBSSO) must be different from the person who monitors the audit trail (AAO), and both must be different from the person who is responsible for the operations of the database server (the DBSA).
By requiring individuals with distinct roles to work together to complete critical or sensitive tasks, you create a checks-and-balances mechanism that can reduce security risks and facilitate compliance with regulatory mandates such as SOX, HIPAA, PCI DSS, and GDPR—as well as with industry regulations such as ISO 17799.
How would I know if my warehouse experiences a database security event?
Two data warehouse features can help here. Start with audit logs. These form a critical part of data protection and compliance because they record all or specified classes of security events for the entire data warehouse installation. Selected classes of events, such as use of database procedures or access to tables, can be recorded in the security audit log file for later analysis. Criteria can be selected that apply to a single object or across an entire class of installation objects.
The second key feature is a security alarm capability, which enables you to specify the events to be recorded in the security audit log for individual tables and databases. Using security alarms, you can place triggers on important databases and tables. If any user attempts to perform an access operation that is not normally expected, the security alarm will raise an alert.
How can I protect my data at rest and in motion?
Data encryption scrambles data into “ciphertext” that makes it unreadable to anyone who doesn’t have a decryption key or password. Encryption of data at rest (that is, stored in a database) and in motion (in transit on a network) is needed to protect data everywhere.
Data at rest in the cloud provider’s filesystem should generally be protected by AES 256-bit encryption. Additionally, some data may warrant different privacy or security measures. To meet these needs, your data warehouse should offer the flexibility for both full database encryption and individual column encryption. The data warehouse should also support the rekeying of encryption keys where the entire data warehouse is decrypted and then re-encrypted with a new encryption key as recommended by NIST guidelines. This is a valuable way to limit the amount of time a bad actor can use a stolen key to access your data warehouse.
Because data in motion (data transported from one location to another) is vulnerable to man-in-the-middle (MiTM) attacks, it should be encrypted while in motion to prevent interception.
Is data being handled responsibly?
I’ll be discussing this in more detail in my next blog, but here are a few details: A data warehouse that operates in compliance with the System and Organization Controls 2 (SOC 2) framework demonstrates that your data warehouse maintains a high level of information security. A data warehouse vendor that has passed on-site audits shows that it has taken all steps necessary to keep the data warehouse, and the valuable information contained therein, safe from breaches.
As noted earlier, there’s much more to say on this topic, and I will continue this thread in my next blog post on cloud service security. Meanwhile, you can learn more about Actian Avalanche here.