Securing Open Source Databases

47
LAMySQL/LAPHP Talk: Securing Open-Source Databases in the Cloud Mike Frank, Director of Products

description

Discusses cyber-security fears and the risks to your data in the cloud, an overview of cloud and virtualized infrastructures, open-source products, and security application, and lastly, methods for protecting databases.

Transcript of Securing Open Source Databases

Page 1: Securing Open Source Databases

LAMySQL/LAPHP Talk:Securing Open-Source Databases in the CloudMike Frank, Director of Products

Page 2: Securing Open Source Databases

04/13/2023

2

Session Agenda

• Cyber-security fears and the risks to your data in the cloud

• Overview of cloud and virtualized infrastructures, open-source products, and security applications

• Methods for protecting databases

Page 3: Securing Open Source Databases

04/13/2023

3

Like everything The cloud has both

Rewards

And

Concerns

Page 4: Securing Open Source Databases

04/13/2023

4

The Cloud Rewards

• Scalable (Up or down)• Agile – Quick to Market• Service Oriented• Pay as you go – like a “utility”• Cost sharing / benefits• SLA driven – HA• Provides built in “automation” – APIs, tools, etc.• Maintenance

Page 5: Securing Open Source Databases

04/13/2023

5

The Cloud Concerns

• Information Security• Privacy• Data Location• Data Migration• Legal

Page 6: Securing Open Source Databases

04/13/2023

6

The Cloud is the

Same• Components are like any other IT assets.

– computing resources – used to do a job – must be monitored and managed

Different• Controlled and monitored through the APIs / Tools

– available from the cloud provider. • Can’t get “under the hood”

Page 7: Securing Open Source Databases

04/13/2023

7

Enterprise Cybersecurity Fears and the Risks to Data in Clouds

Page 8: Securing Open Source Databases

04/13/2023

8

What is DATA is vulnerable?

• Its all about DATA– DIRECT - Real actual data

• Via various services – web, database,…• In the end it resides in files and utimately on storage

– INDIRECT - Data that points to or protects data• Usernames and Passwords• Keys• Configuration files or code for services and applications

– Hypervisor Images – Firewalls– Web Servers– Middleware servers– Data Caching Servers/Services– Database Servers– Applications

Page 9: Securing Open Source Databases

04/13/2023

9

Threat Agents

• Internal– Company executives, Employees, Independent contractors,

Interns– Former Employees

• External– Lone hackers, Organized crime, and Government entities

• Partners – Third party sharing a business relationship – Suppliers, Vendors, Hosting Providers, Outsourced IT

support, etc. – Business partners

Page 10: Securing Open Source Databases

04/13/2023

10

Added Risks - In the Cloud

• These risks are accentuated– Data is more distributed

• Its in “Cloud Storage”• Its in server “images”

– More “elastic”• It moves around• Its transient

– Servers going up and down

– Its on the Cloud Server • Public, Hybrid, Private, Private Managed, etc etc etc• APIs to “control”

– Or within a Hosted Service

Page 11: Securing Open Source Databases

04/13/2023

11

Added Threat Agents - In the Cloud

• There are more– And they hit your public cloud server immediately

• Just launch a new cloud server with monitoring on• Attacks occur immediately

• They might be “closer”– In the same cloud– On the same hardware, network, hypervisor– On the same storage systems

• You have less control– More “managed”

• Some Cloud utilities have OS Server User Access– More unknown resources

Page 12: Securing Open Source Databases

04/13/2023

12

User Privileges

• Users typically have plenty to get the data– Just taking advantage of privileges granted to them– Don’t even need to be root

• Suspect in the cloud this is more so the case– More with powerful privileges– Not as well managed in many cases

Page 13: Securing Open Source Databases

04/13/2023

13

Main Attack Methods for Breaches

• Remote Access Services• Backdoor or control channel• Web Application• Network File Sharing

• Majority of data is from Servers• Followed by user devices

Page 14: Securing Open Source Databases

04/13/2023

14

Attack Vectors and Data Protection

• Get OS login access • Get access to files on storage• Network• Injection

– Not as important as it once was• Buffer Overflows

– Not as important as it once was• Social Engineering• Code• Malware, viruses, trojans, etc.

Page 15: Securing Open Source Databases

04/13/2023

15

Overview of cloud infrastructure, open-source products, and security applications

Page 16: Securing Open Source Databases

04/13/2023

16

Open-Source and the Cloud

• Currently majority of cloud is Open Source– Linux Based– Apache Based– Databases

• MySQL – 90% of databases• PostgreSQL - surging

– NoSQL / Big Data coming on strong• MongoDB• Cassandra• Hadoop• And more

– Other components• Solr, Sphinx

Page 17: Securing Open Source Databases

04/13/2023

17

Open Source Security Opinions

• Thinking is different from commercial• Fewer requests from community of end users• Less effort put into installers / configuration tools

– And more need to have users get started easily• Less time spent on security (or has been)

– Preference is for functional things – like performance– Expectation for OS or Applications to provide security

• Delineated boundaries– Adding security features breaks things– Security takes time – products are typically younger

• Or security features may be “add ons”

• Defaults are less secure

Page 18: Securing Open Source Databases

04/13/2023

18

This discussion focuses “below the yellow line”

Browser/Client

Public Network

Firewall

Web Server / Services

Database

OS

Cloud Servers - Hypervisor / VMs

Data inFile System

-----------------Local

OrNetwork/Cloud

File Storage

Page 19: Securing Open Source Databases

04/13/2023

19

Insecure direct object reference

The problem - attackers: • Manipulate direct object references

– Use to gain unauthorized access to other objects. – URLs or form parameters contain references to objects

such as files, directories, database records or keys.

Page 20: Securing Open Source Databases

04/13/2023

20

Insecure cryptographic storage

But: All to often Web devs don’t encrypt sensitive data

OR Encryption is present but poorly designed

• Leads to disclosure of sensitive data

How to protect : • Use good technology / design patterns

– AES, RSA public key cryptography, and SHA-256

• Generate keys offline • Only transmit keys over secured communications

Page 21: Securing Open Source Databases

04/13/2023

21

Data in File System

How, Where, Why is this “Vulnerable”?• Filesystem within the OS – from an “OS user”

– Whether from a shell or other method• Communications network

– Electronic eavesdropping – files and keys• Storage communications

– Electronic eavesdropping• Virtual Images

– Active or inactive• Other access to the storage• Physical storage device

Page 22: Securing Open Source Databases

04/13/2023

22

Per OSS DB Product – What to “Protect”

Page 23: Securing Open Source Databases

04/13/2023

23

MySQL

• The files for InnoDB tables (tablespace) or MyISAM– User schemas but also things like my.user

• Logs – Query Files - log=/var/log/mysql-queries.log– Bin Log

• Configuration Files – may contain user/pass– my.cnf– master.info– Other “client” configs (ie used by mysqldump etc)

• Backup Files/Exports– Whether hot, cold, warm, or logical (mysqldump)

Page 24: Securing Open Source Databases

04/13/2023

24

Postgres

• Tablespace– Protect the directory and all the files for a tablespace

• Logs – Is log_statement TRUE– Encrypt the log file then

• And more important = See where its going

• Configuration Files – may contain user/pass– Pg_hba.conf, pg_Ident.con, postgresql.conf, – “client” configs - pgpass.conf

• Backup Files– Whether hot, cold, warm, or some Logical or CDP

Page 25: Securing Open Source Databases

04/13/2023

25

MongoDB

• The data dir– The dbpath e.g. /var/lib/mongodb/

• Configuration Files – specify auth etc.– --config

• Log Files– Depending on what level is set

• Backup/Exports– Where ever you direct your mongodump/bsondump– Fsynv+lock – then copy– Other – LVM etc

Page 26: Securing Open Source Databases

04/13/2023

26

Cassandra

• Data Files– /var/lib/cassandra/data/<keyspace>/…

• Configuration Files– cassandra.yaml– -Dpasswd.properties=conf/passwd.properties – -Daccess.properties=conf/access.properties

• Logs– conf/log4j-server.properties

• Backup Files– /var/lib/cassandra/data/mykeyspace/backups/– /var/lib/cassandra/data/mykeyspace/snapshots/

Page 27: Securing Open Source Databases

04/13/2023

27

Hadoop

• From CDH3 docHadoop's current threat model assumes that users cannot:• Have root access to cluster or shared client machines.But someone will have root access or other accessNote: Various “flavors” and variance at this levelBut still need to protect • Data Files• Config files • hdfs-site.xml

Page 28: Securing Open Source Databases

04/13/2023

28

Overview of cloud infrastructure, open-source products, and security applications

Page 29: Securing Open Source Databases

04/13/2023

29

Linux Tools

IP Tables / Netfilter• Linux Kernel Firewall• Host based

AppAmor / SELinux• Restrict the actions that installed software can take• Add Roles and Policy Concept• Seldom enabled

Page 30: Securing Open Source Databases

04/13/2023

30

Encryption tools

• Network - OpenSSL• File – mcrypt, OpenSSL• Filesystem based encryption – ecrypfts• Dm-crypt – block based device encryption

Note: Each represents just one component in a comprehensive set of mechanisms to protect the confidentiality of your data.

Page 31: Securing Open Source Databases

04/13/2023

31

Clouds Security Tools

Can provide not just servers but also• Firewalls• Load Balancers• Dedicated Firewalls• Dedicated servers and storage• Firewalls with options like

– Stateful inspection, IDS, AV, SSL, IPsec VPN, and more• Encrypted Cloud Storage

– Block storage – at the FS mount level– Or API level– Still need to protect and manage the Keys

Page 32: Securing Open Source Databases

04/13/2023

32

Methods for protecting data: considering the pros and cons

Page 33: Securing Open Source Databases

AS-IS for LinuxOS Users And especially ROOT Can Read and Copy Data Files

Page 34: Securing Open Source Databases

Open Source Databases Don’t Protect FilesWith encryption - MySQL doesn’t

Copy a file and you have the data

The thief Has your data

Page 35: Securing Open Source Databases

Hypervisor Image

On the cloud the data is eitherIn the Hypervisor Image

Page 36: Securing Open Source Databases

Hypervisor Image

Or a mounted data store

Cloud Storage

Storage volumes that can be attached to a running instance and mounted as a device within the instance. Examples – Amazon EC2, vCloud VMFS or NFS

Page 37: Securing Open Source Databases

Partial 1 – Solve with encryption

Encryption - block or other filesystem

• Protects from disk theft, pulling data from io protocol taps, access physical volume (like a san), …

• Doesn’t protect from OS user access. Doesn’t protect keys or passwords

OS with OS Filesystem Mounts

Page 38: Securing Open Source Databases

Partial 2 – Access ControlProcess / User only have access

• Protects from OS user access. • Doesn’t protect data at rest etc.• Doesn’t protect keys or passwords

OS with OS Filesystem Mounts

Page 39: Securing Open Source Databases

Partial 3 –Key Management

• Protects key from open access. Stored in protect kernel.• Not stored on in the local or mounted filesystem• Control access to keys and key store

OS Kernel Memory The key is safely stored

Key Ring

Page 40: Securing Open Source Databases

Types of Database Encryption

• Encrypt data as it moves across the network– SSL certificates

• Encrypt data as it sits at rest within the database storage system– Database functions

• Keys are stored within the database• Keys stored outside of database

– Usually from an application– Can be other “key store”

– Application Encryption

Page 41: Securing Open Source Databases

How ezNcrypt is Different

• Provides on-disk encryption architecture • Application and process transparency• Key is kept outside of the database schema• Database or table-level encryption available

Also its not just for databases • Rules based – ACLs from Process to File for TDE

• Towards “Zero Trust”

Page 42: Securing Open Source Databases

Use Cases for Database Encryption

• Export of virtualized database machines• Lost or stolen hardware • Compliance Requirements

– PCI compliance with customer data– HIPAA compliance with protection of medical records – Other government agency compliance– Safeguard personnel records

• Protect data from privileged access users

Page 43: Securing Open Source Databases

Gazzangs ezNcrypt

If root copies a file and then all they have is an encrypted file

Its AES Encrypted The file is worthless

to the Thief

Page 44: Securing Open Source Databases

Linux Exe

ezNcrypt Flex Edition Work Flow Is this Linux Exe Trusted?• Name• Owner• Location• Process

Identifiers/Fingerprints

OK – then Provide Key – • Gets Transparent R/W access

Where is this Linux Exe Allowed or Denied Access to files/dir?• Limited Files or Directories

OK?• Transparently uses key for

R/W etc.

Not OK• Access is Denied

Access Control

Page 45: Securing Open Source Databases

KSSKey Storage System

1. Each individual file is encrypted with a

unique and random key

2. The passphrase and salt or RSA key is used to protect the server and all the file keys

3. ezNcrypt calls KSS to store the master key

4. The key is encrypted with a one time use secret and sent over SSL

5. The authenticity of ezNcrypt is verified *provisional patent

6. The key is safely stored

Store

Page 46: Securing Open Source Databases

KSSKey Storage System

6. Each individual file is unlocked with the

master key

5. The Master Key is loaded into the keyring

1. ezNcrypt calls KSS to retrieve the master key

4. The key is encrypted with a one time use secret and sent over SSL

2. The authenticity of ezNcrypt is verified *provisional patent

3. The key is extracted

Retrieve

Page 47: Securing Open Source Databases

47

Summary

• There are risks and rewards in the cloud

• By using a secure platform additional cloud security risks are greatly reduced and rewards recognized

Thank you for your time

Mike Frank – [email protected]

04/13/2023