1 Sun Microsystems Methoden zur Absicherung und Datensicherung eines MySQL- Servers Lenz Grimmer MySQL Community Relations Manager.

Präsentation zum Thema: "1 Sun Microsystems Methoden zur Absicherung und Datensicherung eines MySQL- Servers Lenz Grimmer MySQL Community Relations Manager."—  Präsentation transkript:

1 1 Sun Microsystems Methoden zur Absicherung und Datensicherung eines MySQL- Servers Lenz Grimmer MySQL Community Relations Manager

2 2 Übersicht Verbesserung der Server-Sicherheit > Integrierte Funktionalität > Auf Betriebssystem-Ebene MySQL Datensicherung > physikalisch vs. logisch > Methoden und Werkzeuge

3 3 MySQL-Absicherung Wichtige Arbeitsschritte nach Erstinstallation Sicherheit der Standardinstallation bereits relativ hoch Zusätzliche Sicherungsmaßnahmen des Betriebssystems flankieren die im Server enthaltenen Funktionen http://dev.mysql.com/doc/refman/5.0/en/security.html http://dev.mysql.com/doc/refman/5.0/en/security.html

4 4 Benutzerkonten Kennwort für den root-User $ mysql ­u root mysql mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password'); Entfernen des anonymen Benutzers Entfernen der test -Datenbank Script: mysql_secure_installation Konten: nur die erforderlichen Privilegien: nur die notwendigen

5 5 Prüfung der Zugriffsrechte Verbindungsaufbau > Server überprüft anhand der user -Tabelle, ob ein passender Eintrag für username, host und passwort existiert SQL-Abfrage > Server überprüft Privilegien anhand der user, db, tables_priv and column_privs Tabellen http://dev.mysql.com/doc/refman/5.0/en/privilege-system.html

6 6 MySQL-Zugangskontrolle Query true false db true Query executed Permission denied false columns_priv false tables_priv false user true

7 7 Sicherheitsfunktionen Nützliche Optionen in my.cfg: > bind-address – lauscht nur am einem TCP-Interface (z.B. 127.0.0.1) > skip-networking – Kommunikation nur lokal (via socket-Datei) Wichtige SQL-Anweisungen: SHOW GRANTS, SET PASSWORD, GRANT/REVOKE PROCESS/SUPER/FILE Privilegien minimieren

8 8 Weitere Hinweise Keine Benutzerkennwörter im Klartext in Tabellen speichern MD5() oder SHA1(), nicht PASSWORD() Verschlüsselung (SSL, SSH, VPN) LOAD DATA LOCAL deaktivieren: --local-infile=0 Nie mysqld als root-Benutzer ausführen History-Datei ~/.mysql_history absichern oder löschen MySQL root -User umbenennen

9 9 Views & Stored Procedures VIEW s können Zugriff auf bestimmte Spalten regeln > http://dev.mysql.com/doc/refman/5.0/en/views.html http://dev.mysql.com/doc/refman/5.0/en/views.html Stored Procedures schirmen die realen Tabellen vor direkten Zugriffen durch Anwender und Applikationen ab > http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html Seit MySQL 5.0 enthalten

10 10 Absicherung auf OS-Ebene Zugriff auf das Datenverzeichnis beschränken ( chown/chmod ) > Tabellen und Log-Dateien schützen Keine Shell-Konten auf dem DB-Server Kein direkter Zugriff auf Port 3306 aus dem Internet! Firewall/DMZ/iptables SELinux, AppArmor, RBAC chroot(), Zones/Container, VMs

11 11 Security Auditing Regelmäßige, automatische Überprüfung oak-security-audit (openark kit) http://code.openark.org/forge/openark-kit/ http://code.openark.org/forge/openark-kit/

12 12 Datensicherung Notwendigkeit > Hardware-Ausfall > Anwender- oder Applikationsfehler Zu sichernde Daten > Datenbankinhalte > Log-Dateien Weitere Aspekte > Sicherungszeitpunkt > Ort der Sicherung und Aufbewahrung

13 13 Wann werden Sicherungen benötigt? Datenverlust durch Hardwarefehler > Absturz wg. Hardwareschaden > Festplattenausfall > Defekte Hardware Anwender- und Applikationsfehler > DROP TABLE oder DELETE FROM ohne WHERE - Klausel > Development vs. Production DB > Öffnen der Tabellendateien mit der falschen Anwendung

14 14 Was sollte gesichert werden? Datenbankinhalte > Für komplette Sicherungen > Logisch oder phyikalisch Log-Dateien > Für inkrementelle Sicherungen > Wiederherstellungszeitpunkte (Point in time recovery) Konfigurationsdateien > /etc/my.cnf > Cron-Jobs

15 15 Zeitpunkt der Datensicherung Regelmäßig Außerhalb der Lastspitzen Wenig veränderliche Daten weniger häufig

16 16 Speicherung der Sicherungskopien Auf dem DB-Server > Besser nicht! > Zumindest auf einem separaten Dateisystem/Volume oder Laufwerk Kopiert auf einen anderen Server > Onsite oder offsite Sicherung/Archivierung auf Band/Wechselplatte An verteilten Orten

17 17 Modulare Speicher-Engine-Architektur

18 18 MySQL Datenverzeichnis Alle Datenbanken und Logfiles werden standardmäßig hier gespeichert Ort abhängig von der MySQL distribution (einkompilierter Wert): > /usr/local/mysql/data (tarball) > /var/lib/mysql (RPM) Mit --datadir=/pfad/zum/datadir anpaßbar SHOW VARIABLES LIKE 'datadir'; InnoDB: innodb_data_home_dir

19 19 Das Binärlog Speichert alle datenverändernden SQL-Anweisungen (DML) z.B. CREATE, INSERT, DELETE, DROP, UPDATE Zweck: > Erleichtert Datenwiederherstellung > Replikation Enthält zusätzliche Informationen (Zeitstempel, Laufzeit) Binär codiert, mysqlbinlog zum decodieren Aktiviert mit -- log-bin[=datei]

20 20 Log-Management Server rotiert die Logs Log-Indexdatei verzeichnet alle Logs SHOW MASTER LOGS – listet alle auf dem Server vorhandenen logs FLUSH LOGS – rotiert logs RESET MASTER – löscht alle binärlogs PURGE MASTER – löscht alle binärlogs bis zu einem best. Zeitpunkt

21 21 Sicherungsmethoden logisch: SQL-Anweisungen physikalisch: Tabellendateien vollständig vs. inkrementell > Aktivieren des Binärlogs > Zeitpunktbezogene Wiederherstellung

22 22 Gängige MySQL-Sicherungspraktiken mysqldump > Vollständige Sicherung $ mysqldump mydb > mydb.20050925.sql > Struktur und/oder Daten als SQL-Anweisungen: CREATE TABLE, INSERT > Einzelne Tabellen oder Datenbanken möglich > portabel, aber unhandlich bei großen Datenmengen Mit anderen Unix-Werkzeugen kombinierbar (Piping) $ mysqldump ­­opt world | mysql ­h remote.host.com world

23 23 mysqldump - Tipps --lock-all-tables – nützlich für konsistente MyISAM-Backups > Aber sperrt alle DML-Anweisungen --flush-logs – synchronisiert das Binärlog (Checkpointing)

24 24 Sicherung von InnoDB-Tabellen mysqldump --single-transaction erstellt konsistente Sicherungskopie ohne Locking Physikalische Sicherung > MySQL-Server herunterfahren! > Datenfiles, InnoDB log-Dateien,.frm-Dateien sichern > Server wieder starten

25 25 XtraBackup / Maatkit https://launchpad.net/percona-xtrabackup Online-Backup für InnoDB In my.cnf: > [xtrabackup] target_dir = /home/backups Backup-Kommando: > xtrabackup –backup http://maatkit.org/ Multi-threaded Perl wrapper scripts > mk-parallel-dump / mk-parallel-restore

26 26 Weitere Sicherungsmöglichkeiten Replikation > Sicherung erfolgt auf Slave > Bonus: erhöhte Verfügbarkeit Dateisystem-Snapshots > „semi-hot“ > Linux: LVM (mylvmbackup) > Solaris: ZFS (mysql-snapback) MySQL 6.0: Online Backup API http://forge.mysql.com/wiki/OnlineBackup http://forge.mysql.com/wiki/OnlineBackup

27 27 Backups über Dateisystem-Snapshots Bequeme und schnelle Lösung zur unterbrechungsfreien Sicherung vollständiger Datenbanken Geringer Platzbedarf des LVM-Snapshots (10-15% reichen üblicherweise aus) Backup der Dateien auf dem Snapshot Volumen mit beliebigen Tools Beeinträchtigung der I/O Performance (Linux LVM)

28 28 Linux LVM Snapshot-Erzeugung Funktionsprinzip: mysql> FLUSH TABLES WITH READ LOCK $ lvcreate -s –-size= --name=backup mysql> UNLOCK TABLES $ mount /dev/ /backup /mnt $ tar czvf backup.tar.gz /mnt/* $ umount /mnt $ lvremove /dev/ /backup

29 29 Das mylvmbackup-Script Script zur schnellen Erzeugung von MySQL-Backups mit LVM-Snapshots Snapshots werden in ein temporäres Verzeichnis eingehängt, die Daten werden mit tar,rsync oder rsnap gesichert Archivnames mit Zeitstempeln ermöglichen wiederholte Backup-Läufe ohne Überschreiben Kann vor dem Backup InnoDB-Wiederherstellung auf dem Snapshot durchführen Benötigt Perl, DBI and DBD::mysql http://www.lenzg.net/mylvmbackup/

30 30 Werkzeuge Shell: cp, tar, cpio, gzip, zip, cron rsync, unison, rsnapshot, rdiff afbackup, Amanda/Zmanda, Bacula Nicht auf live-Daten anwenden! (ma.gnolia.com anyone?)

31 31 Wiederherstellung Letzte vollständige Sicherungskopie (+ binäre Logdatei) Einspielen des SQL-Dumps oder Kopieren der gesicherten Tabellendateien Wiederherstellung eines bestimmten Zeitpunkts (point-in-time recovery) durch Zeitstempel im Binärlog möglich

32 32 Beispiel Wiederherstellung Letzte vollständige Sicherung einspielen: $ mysql < backup.sql Einspielen der inkrementellen Änderungen seit der letzten vollständigen Sicherung: $ mysqlbinlog hostname-bin.000001 | mysql

33 33 Vergleich der Sicherungsmethoden Portabilität (SQL Dumps vs. Tabellendateien) Geschwindigkeit, Speicherbedarf Overhead und Beeinträchtigung des Betriebs

34 34 Sicherungsstrategien Regelmäßige Durchführung Binärlog aktivieren Log-Dateien synchronisieren (FLUSH LOGS) SQL-Dumps konsistent und verständlich benennen (z.B. mit Zeitstempel im Dateinamen) Aufbewahrung der Sicherungen auf anderen Dateisystemen

35 35 Generelle Backup-Hinweise Binärlogs auf einem anderen Laufwerk/Dateisystem ablegen > Verbesserte Performance > Vermeidet vollständigen Datenverlust Backups auf Vollständigkeit/Korrektheit überprüfen Prozeduren und Zeitpläne für Backups und Wiederherstellung festlegen Testen, ob sie auch wirklich funktionieren!

36 36 Vielen Dank! Fragen, Kommentare, Anregungen? Lenz Grimmer lenz@sun.com