Sicherer PostgreSQL Betrieb
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 49 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/51782 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Point cloudPostgreSQLPostgreSQLArmComputer animationMeeting/Interview
00:54
PostgreSQLOpen sourceIntegrität <Informatik>SQLEnterprise architectureDevice driverIBMOracle <Marke>SQL Server 7.0RankingInformation securityInformation and communications technologyHTMLProcess capability indexVersion <Informatik>Data conversionParticle detectorMobile appKommunikationPatch (Unix)Computer data loggingServer (computing)LINUXUNIXVirtualizationData conversionDebian GNU/LINUXPostgreSQLEnterprise architectureDatabaseDevice driverUbuntu <Programm>WordServer (computing)DistanceInformation and communications technologyIntegrität <Informatik>Field extensionSimilarity (geometry)Plane (geometry)Set (mathematics)MySQLService (economics)dBASECONSULTANT <Datenbank>Focus (optics)Function (mathematics)DatabaseDistribution (mathematics)ORACLSPhysical quantityProgramming languageVersion <Informatik>Open sourceINVESTOR <Programm>Smart cardSystem administratorMilitary rankBASICSTYLE <Programmierumgebung>Multitier architectureLinieMonster groupComputer animation
10:00
DatabaseSQLConfiguration spaceHigh availabilityData conversionPriorityManual of StyleServer (computing)Set (mathematics)TuningSystem administratorPostgreSQLParameter (computer programming)DatabaseService (economics)DatabasePoint clouddBASERoute of administrationData conversionPostgreSQLZugriffSystem administratorHigh availabilitySet (mathematics)InternetComponent-based software engineeringPoint (geometry)Instanz <Informatik>Google BloggerQuantum statePlane (geometry)LinieMultitier architectureFeld <Mathematik>Time zoneSun <Marke>Form (programming)BackupDebian GNU/LINUXHand fanServer (computing)Web serviceComputer animation
19:06
System administratorServer (computing)DatabaseSet (mathematics)TuningPostgreSQLInstanz <Informatik>RollbewegungMainframe computerHydraulic jumpPasswordLebensdauerComputer hardwareEigenvalues and eigenvectorsRollbewegungInstanz <Informatik>DatabaseServer (computing)PostgreSQLData recoveryInformationMainframe computerPasswordNoten <Programm>Hydraulic jumpZugriffComplete metric spaceChecklistdBASEPatch (Unix)Scheduling (computing)Core dumpObject (grammar)Scripting languageCalculationIP addressLebensdauerBackupDatabaseTestdatenPAPDegrees of freedom (physics and chemistry)Chain ruleGraph coloringProcess (computing)Plane (geometry)Multitier architectureField extensionHydraulic motorWeb serviceComputer animation
28:12
DatabaseUpdateVersion <Informatik>PostgreSQLDistribution (mathematics)Patch (Unix)Instanz <Informatik>Debian GNU/LINUXUbuntu <Programm>Limit (category theory)ChecklistDatenbankverwaltungSSHMainframe computerHydraulic jumpVirtuelles privates NetzwerkLoginConstraint (mathematics)Gastropod shellZugriffDatabaseZugriffDistribution (mathematics)LINUXPostgreSQLEnterprise architectureInternetUbuntu <Programm>Instanz <Informatik>Mainframe computerData dictionaryPatch (Unix)Query languagedBASESet (mathematics)Virtuelles privates NetzwerkDatabaseVersion <Informatik>Continuous trackPlane (geometry)Firewall (computing)Git <Software>Software bugSystems <München>PDF <Dateiformat>RALLY <Programm>Standard deviationSurfacePerturbation theoryCountingLattice (order)Operating systemData storage deviceSoftware testingComputer animation
37:17
Instanz <Informatik>PostgreSQLGastropod shellConstraint (mathematics)ZugriffRollbewegungPasswordAuthenticationLDAPClient (computing)Server (computing)DatabaseTimestampComputer data loggingPerimeterSSHMainframe computerBackupField extensionService (economics)Data recoveryData conversionPostgreSQLBackupZugriffGastropod shellPasswordDatabaseWordTap (transformer)Outline of industrial organizationLDAPIP addressdBASECore dumpPoint (geometry)Instanz <Informatik>Eigenvalues and eigenvectorsDatabaseActive DirectoryComputer data loggingHand fanServer (computing)Service (economics)Computer data loggingMetric systemTable (information)LoginStack (abstract data type)Grand Unified TheoryLarge eddy simulationComputer filePlug-in (computing)Route of administrationSystem administratorNoten <Programm>Local ringDebian GNU/LINUXAdditionEnterprise architectureSet (mathematics)Bindung <Stochastik>Computer animation
46:23
BlogPoint cloudComputer animationJSONXMLUML
Transcript: German(auto-generated)
00:07
Hallo allerseits, herzlich willkommen zu meinem diesjährigen Vortrag bei der Froskon. Mein Name ist Michael Bank. Ich arbeite für die Kreativ GmbH. Wir sind ein herstellerunabhängiges Open-Source-Consulting-Unternehmen.
00:21
Wir machen Trainings, wir machen Support, wir machen Betrieb, 24-7, alles Mögliche. Mit einem gewissen Schwerpunkt auf sowohl Cloud-Themen als auch insbesondere PostgreSQL. Da haben wir ein PostgreSQL Competence Center, wo ich auch Teil davon bin. Und wir suchen auch immer neue Mitarbeiter, die uns da verstärken können.
00:45
Mein Vortrag heute ist sicherer PostgreSQL-Betrieb nach BSI-Grundschutz. Ich habe die Vortragsfolien hier hochgeladen. Wer sich die vielleicht herunterladen will, um sie gleichzeitig anzuschauen, während ich den Vortrag halte.
01:03
Aber ich hoffe, man kann es auch so einigermaßen gut erkennen. Ich würde zuerst ein paar Worte zu PostgreSQL sagen. Die meisten werden es hoffentlich kennen, wenn sie sich hier den Vortrag anhören. PostgreSQL selber sagt, es wäre die world's most advanced open-source relational database.
01:23
Es ist entstanden in Berkeley als ein Forschungsprojekt. Aber inzwischen wird es von sehr vielen Leuten produktiv und im unternehmenskritischen Einsatz eingesetzt. Es ist herstellerunabhängig aufgrund der BSD-Lizenz. Es gibt keine Copyright Assignments, es gibt keine Open Core, keine Enterprise Version, keine Dual-Lizenzierung.
01:43
Es gibt natürlich aufgrund der BSD-Lizenz jede Menge Forks. Aber PostgreSQL selber ist herstellerunabhängig. Und der kommerzielle Support ist von mehreren Firmen unter anderem eben kreativ erhältlich. Es hat einen hohen Fokus auf Datenintegrität. Es ist kompromisslos, stabil und zuverlässig.
02:01
Es hat eigentlich alle, auch von SQL-Seite, alle Sachen, die man sich so vorstellen kann, ein paar gute Erweiterungen. Es hat insbesondere jede Menge Enterprise Features, die man benötigt für den unternehmenskritischen Einsatz. Von Replikation über analytische Sachen, über gute Möglichkeiten, die Sache zu administrieren.
02:26
Jede Menge Open Source-Projekte außenrum wie Postages für Spatial und so weiter. Das geht auch dazu über, dass es sehr viele Erweiterungen gibt, die auch zum Beispiel alle in den Debian oder Ubuntu oder auch Red Hat Distributionen erhältlich sind.
02:44
Man kann Funktionen in vielen verschiedenen prozeduralen Sprachen schreiben, nicht nur in SQL. Und es gibt auch Treiber für ganz viele Programmiersprachen. Es gibt ja insgesamt drei große Open Source-Datenbanken, wobei MySQL weiterhin die mit Abstand beliebteste ist.
03:03
MariaDB ist da sicherlich auch im Kommen. Und wenn man sich das DB-Engines-Ranking anschaut, MariaDB ist dann ungefähr da auf der blauen Linie, wo DB2 ist. Oben die drei sind Oracle, MySQL und SQL Server. Und diese vier sind alle so ein bisschen seit den letzten fünf Jahren stagniert, während Postgres kontinuierlich an Popularität hinzugewonnen hat.
03:27
Man muss dazu sagen, die Eskalierung ist logarithmisch. Also es ist nicht ganz bei der Hälfte, aber es nimmt potenziell immer weiter zu. Gut, das so weit dazu. Was ich eigentlich heute besprechen will oder vortragen will, ist eben BSI Grundschutz.
03:45
Das ist natürlich erstmal für viele in der Open Source-IT-Szene so ein bisschen wie zum Zahnarzt gehen oder SAP-Migration vor sich haben. Da hat man vielleicht nicht unbedingt die besten Vorstellungen von.
04:01
IT Grundschutz ist generell vom Bundesamt für die Sicherheit in der Informationstechnik herausgebrachter Leitfaden, wie man IT sicher umsetzen kann im unternehmenseigenen Informationstechnik. Das ist die Wikipedia-Definition davon.
04:20
Es gibt auch einige internationale Konzepte in der ähnlichen Sache, PCI Compliance für zum Beispiel Kreditkartenhersteller. Dann gibt es noch HIPAAA oder wie das heißt, für Versicherungen. Es gibt die Common Criteria und da ist der STIG Secure Technical Implementation Guide von dem amerikanischen Verzeihungsministerium. Wie man hier sieht, gibt es da auch für Postgres eine Umsetzung.
04:45
Das heißt, man kann Postgres auf diesem Ebene sehen und eben auch auf dieser Ebene betreiben. Gut, was oder wie kommt IT Grundschutz an? Üblicherweise wird das konzernweit oder behördenweit eingeführt.
05:06
Es gibt dann Projektteam, es gibt dann externe wahrscheinlich, irgendwelche Dienstleisterleute, die das eben hauptberuflich oder spezialisiert machen. Da würde ich jetzt relativ nicht dazuzählen. Was wir sicherlich gemacht haben in den letzten Jahren, ist Kunden oder auch aus privat oder aus dem behördlichen Umfeld
05:25
bei der Umsetzung und auch der Konzipierung von IT Grundschutz im Bereich Postgres konkret zu helfen. Das heißt, wir sind jetzt kein Spezialist für den kompletten Umstieg eines Betriebs oder einer Behörde auf IT Grundschutz.
05:40
Aber wir haben da im Bereich Datenbank und insbesondere Postgres durchaus Kunden geholfen. Generell ist es so, dass man verschiedene Phasen hat, die auch oft jedes Jahr wiederkommen. Dass man zunächst eine Planungsphase hat, eine sogenannte Schutzbedarfsfeststellung. Dann muss man gewisse Konzepte erstellen, falls sie noch nicht vorhanden sind oder vielleicht anpassen auf Grundschutz.
06:05
Man muss dann diese Konzepte umsetzen bzw. dokumentieren, wieso man Sachen jetzt nicht umgesetzt hat. Und bekommt dann oder hat dann normalerweise irgendwie Test-Audits und bekommt dann auch eine Zertifizierung.
06:20
Oft ist es dann so, dass vielleicht nur ein Teil auditiert oder zertifiziert wird zunächst bzw. auditiert erst mal. Und dann geht der Kerl vielleicht in den Datenbanken in einem Jahr vorüber, aber im nächsten Jahr ist es dann der Fall. Genau, die Datenbankadministratoren sind oft eben mit eingebunden. Datenbanken sind üblicherweise oder sind oft unternehmens- oder behördenskritische Infrastruktur.
06:45
Haben eben die schützenswerten Daten, die es eben durch IT Grundschutz zu schützen gibt. Und da sind die DBAs immer oft Teil bei diesem Unterprojekt dabei. Es ist dann auch oft so, wenn irgendein Kunde oder so, vielleicht man ist ein Dienstleister für Kunden,
07:06
wenn da ein Kunde eben diese besonderen Umsetzungen oder Zertifizierungen nach IT Grundschutz wünscht, dass man auch eben mit denen dann zusammenarbeitet und da auch dann eine gewisse Mitwirkungspflicht des Kunden besteht. Es ist auch auf jeden Fall so, dass wenn sich ein Konzern oder eine Behörde dazu entschließt, das umzusetzen,
07:26
dann muss das von oben passieren. Die Leitung muss da auch vorangehen und nicht einfach sagen, macht mal. Sondern das muss gewünscht werden und eben auch dann der Umsetzungswelle da sein, dass die Leute, die das machen müssen, eben dann auch die Möglichkeiten und die Ressourcen bekommen, das zu machen.
07:44
Und nicht einfach nur sozusagen als Überstunden hinten dran noch zum zusätzlichen Betrieb reingehauen wird. Als Überblick über die generelle IT Grundschutz Sache. Man hat sogenannte elementare Gefährdungen, die man sich anschauen sollte.
08:04
Es gibt dann verschiedene Bausteine, komme ich gleich dazu, und jeder Baustein hat dann eine eigene Gefährdungslage und insbesondere Anforderungen, früher hieß das eher Maßnahmen, die dann eben umgesetzt werden müssen oder sollten. Es gibt sogenannte Basisanforderungen, die müssen auf jeden Fall umgesetzt werden.
08:22
Das ist dann diese IETF must, also muss groß geschrieben in dem Fall. Und es gibt dann Standardanforderungen, die sollten umgesetzt werden, wobei man das eben im IETF Kontext sehen sollte. Man muss das normalerweise umsetzen. Man kann es aber eventuell argumentieren, wenn man das sorgfältig abwägt, dass vielleicht ist das zu teuer
08:45
oder vielleicht ist das zu kompliziert oder vielleicht ist das tatsächlich nicht nötig, dann kann man das weg argumentieren bei diesen Standardanforderungen. Und dann gibt es zusätzlich eben noch Anforderungen bei dem Schutzbedarf, da gehe ich jetzt aber nicht so genau drauf ein. Zum Thema Schutzbedarf würde ich dann nachher noch was zu sagen.
09:03
Zusätzlich gibt es auch Umsetzungshinweise zu bestimmten Bausteinen oder Unterbausteinen, wobei es da jetzt bei Datenbanken für Oracle Umsetzungshinweise gibt, aber meines Wissens für Postgres bisher nicht. Welche Bausteine gibt es? Das sind die Bausteine.
09:22
Da sind sicherlich, wenn man das komplett ganz einheitlich sieht, ist da alles mehr oder weniger wichtig. Aber wenn man es vielleicht aus der Sicht eines Datenbankadministrators, was jetzt hier so in diesem Vortrag der Punkt wäre, man ist Datenbankadministrator oder man ist vielleicht Freiberufler der Leute als Datenbankadmin oder Consultant berät oder unterstützt,
09:44
dann sind vielleicht eher diese Unterbausteine relevant und da dann insbesondere der Unterbaustein APP43 Relationale Datenbanksysteme. Der Rest mag dann, je nachdem wie auch die Organisationsstruktur ist, wichtig sein oder eben auch nicht.
10:02
Dieser Baustein 4.3 hat diese Gefährdungslage. Das ist jetzt nicht so besonders überraschend. Das sind alles Sachen, die man eigentlich mit gesunden Menschenverstand einigermaßen generell sehen würde. Was ich jetzt nochmal ein bisschen ausführlicher auch kurz besprechen will, ist der Schutzbedarf.
10:23
Man hat die sogenannten Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit. Der Schutzbedarf ist eben dann die Auswirkung, was passiert, wenn diese Grundwerte verletzt sind. Und dann hat man drei Stufen. Man hat den Schutzbedarf normal. Das heißt, wenn das eben die Verfügbarkeit oder die Integrität oder die Vertraulichkeit wechselt,
10:46
dann ist das begrenzt und überschaubar. Vielleicht weil man Backups hat, wenn jetzt zum Beispiel die Sache nicht mehr da ist oder weil vielleicht die Daten jetzt nicht so furchtbar wichtig sind, unternehmenskritisch, dass man sie nicht wieder ersetzen könnte
11:01
oder dass das Unternehmen hinunterzieht, wenn sie öffentlich werden. Aber wenn der Schutzbedarf hoch ist oder sehr hoch, dann kann es schon sein, dass die zentralen Daten sind, vielleicht einer Versicherung oder so, die, wenn sie dann wechseln oder im Internet auftauchen, das Unternehmen existenziell bedrohen können.
11:24
Im Allgemeinen würde ich davon ausgehen, dass man einen normalen Schutzbedarf hat, was allerdings trotzdem bedeutet, dass man nicht die meisten dieser Anforderungen umsetzen muss und aber nicht jetzt paranoid komplett alles mit protokollieren, loggen und so weiter oder jeden Mitarbeiter da sogenannte irgendwelche Fußfestung oder so ansetzen müsste im Übertragensinn.
11:46
Im Prinzip, was man auf jeden Fall hat, man macht eine sogenannte Schutzbedarffeststellung. Da kann man hier vielleicht direkt übergehen. Das ist so eine ganze Modellierung aller Komponenten. Da gibt es dann auch bestimmte Tools. Da gibt es dann Leute, die sich darauf spezialisiert haben.
12:04
Man macht das nach dem Maximalprinzip. Das ist natürlich dann auch, wenn man jetzt zum Beispiel Kunden hat, muss man den Schutzbedarf für den Kunden dann neu bestimmen. Aber wie gesagt, im üblichen Fall ist das ein normaler Schutzbedarf.
12:21
Man muss dann im Rahmen der Umsetzung von BOSI konkrete Sicherheitsmaßnahmen entwickeln. Man muss die dokumentieren, wieso jetzt irgendwelche Anforderungen oder Maßnahmen ausreichend sind jetzt oder warum sie nicht gemacht werden müssen. Man sollte sie dann auf jeden Fall auch priorisieren. Was sollte auf jeden Fall als erstes passieren? Was ist am wichtigsten?
12:43
Damit man dann einen Umsetzungsplan erstellen kann. Und da vor allem ist es wichtig, dass man Verantwortliche definiert, wer dann was macht. Und wie ich auch vorhin schon gesagt habe, es gibt auch eine gewisse angemessene Wirtschaftlichkeitsbetrachtung. Also lohnt es sich jetzt da hundertetausend Euro für irgendein Spezialprodukt auszugeben,
13:07
um jetzt da bis aufs Komma diese eine Anforderung umzusetzen. Oder kann man vielleicht mit geringerem Aufwand 95 oder 90 Prozent der Anforderungen umsetzen und den Rest dann eben weg argumentieren, weil der finanzielle Aufwand zum Beispiel dann zu hoch wäre.
13:25
Genau, man hat dann oft den Fall, dass man jede Menge Konzepte erst mal erstellen oder überarbeiten oder zusammenbringen muss. Es gibt dann ein übergeordnetes Sicherheitskonzept, wo dann aus Sicht der Datenbankadministration auch gewisse Einzelheiten reingeschrieben werden müssen.
13:45
Also entweder gibt es dann ein gesamtheitliches Sicherheitskonzept oder man muss eben für den Bereich Datenbanken dann eins im Rahmen oder in dem Kontext konzipieren. Was man auf jeden Fall auch machen sollte oder muss, sind dann ein Benutzernberechtigungskonzept zu schreiben
14:00
und dann zu erklären, welche wie Benutzer angelegt werden oder welche Berechtigungen sie bekommen sollten. Und auch ein Datensicherungskonzept und ein Protokollierungskonzept kommt man eigentlich nicht drum rum, wenn man BSI sich zertifizieren lassen will. Was hilfreich und sinnvoll ist, aber vielleicht nicht unbedingt nötig, ist ein Log-Auswertungskonzept
14:22
und auch ein Monitoring-Konzept, wenn es da ein bisschen... Ja, man kann natürlich ein sehr kurzes Monitoring-Konzept schreiben und sagen, man macht das und das war's. Aber hilfreich ist dann natürlich, wenn man das mit Monitoring ein bisschen ausführlicher machen will, dass man das auch besser konzipiert. Aber zu Monitoring bzw. zu den meisten von diesen Punkten kommen wir dann später nochmal.
14:44
Generell vielleicht zu dem Punkt jetzt hier die Erwartungshaltung. Also ich würde jetzt mal in den nächsten Folien generell die Best Practices oder Möglichkeiten, die wir so dann in der Umsetzung, aber auch im laufenden Betrieb von BSI mit Kunden gesehen haben, vorstellen,
15:04
was wir halt für sinnvoll halten. Und man muss da auch generell auf jeden Fall sagen, wenn man jetzt in einem Start-up-Unternehmen ist, das dann vielleicht hoch wächst, das dann jetzt schon mehrere Dutzend, hundert Mitarbeiter hat.
15:20
Aber am Anfang hatte man vielleicht halt nur ein paar und da gab es halt eine Datenbank und das war halt dann diese typische PET-Geschichte, PET statt Kettel. Man weiß dann genau, der Kollege X hat am Tag Y den Parameter Z in der Datenbank auf so und so geändert und die Kollegin A hat das dann so und so einen anderen Parameter gemacht.
15:43
Das kann man sich alles noch merken, wenn man nur eine Datenbank hat. Aber wenn man eben ein Dienstleister ist und da viele Kunden hat, und die halt vielleicht nicht alles per Self-Service oder per Cloud oder automatisiert machen, sondern da dann immer einen auch ein bisschen nerven müssen, wenn sie eine neue Datenbank haben wollen oder eine neue Erweiterung, dann ist es eben sinnvoll, solche Konzepte zu haben,
16:06
solche Umsetzungen zu haben und dann auch eben diese Sachen zu leben, um den Betrieb dann zu verbessern. Das heißt, wenn man erstmal diese Skalierung hat von ein paar Datenbanken zu hunderten Datenbanken und sich keinerlei Gedanken macht, dann fällt man irgendwann wahrscheinlich sehr stark
16:25
auf die Schnauze und da ist eben dann BSI Grundschutz, ein mit Augenmaß umgesetzter BSI Grundschutz, unserer Meinung nach ein sinnvoller Weg, das zu machen. Gut, als erstes, was man sehen sollte, ist die Trennung der Arbeitsbereiche.
16:43
Es gibt dann auch technische DBAs und fachliche DBAs und Systemadministratoren. Wie gesagt, bei einem Startup-Umfeld ist es dann oft so, dass das eine Person ist oder das ist einfach DevOps oder weiß ich nicht irgendwas, aber im größeren Umfeld und gerade auch bei Behörden hat man dann oft Teams und ein Team ist eben für die Einrichtung
17:01
der Serverinstanzen und auch der Backups zuständig und das andere Team ist dann eben für Anwendungen zuständig, betreut die und sorgt dafür, dass die Anwendung das Schema erstellt oder erstellt eben das Schema und die Datenbankänderung und da gibt es diese Abtrennung. Und da sollte man vor allem, wenn man im Bereich technische DBAs zuständig ist,
17:26
auf jeden Fall darauf drängen, dass es Auftragsberechtigte gibt und nicht einfach jeder Entwickler einem sagen kann, ich brauche heute kurzfristig Zugriff auf die Port, mach mal, sondern dass man da dann eben jemanden hat, der klarer Ansprechpartner ist und der das erlaubt. Das ist insbesondere dann wichtig, wenn man zum Beispiel
17:44
ein externer Dienstleister ist oder Freelancer und dann nicht Teil des Unternehmens ist und dann auch nicht so den Überblick hat, wer eigentlich da was zu sagen hat, da kann man sich dann sehr gut darauf berufen, ja, Auftragsberechtigter soll ein Ticket erstellen zum Beispiel, das ist eigentlich hilfreich.
18:02
Genau, es ist dann oft so, dass die fachlichen DBAs vielleicht entweder nur zu einer Person ist, die dann hier so ist zu einem externen Dienstleister oder einem Hersteller von einem Nischenprodukt und die Entwickler des Herstellers, die sagen dann, sie brauchen dies und das und der macht eben dann den Auftrag.
18:23
Manchmal sind es aber auch Inhouse-Entwickler oder eben tatsächlich dann, das ist eher seltener der Fall, würde ich sagen, aber tatsächlich dann auch wirklich fachliche DBAs, die das dann sich auf Postgres spezialisiert haben und da auch sehr gut z.B. Performance-Tuning usw. machen können.
18:41
Genau, oft ist es weiterhin so, dass die Systemadministration dann noch in einem anderen Team ist, d.h. die technischen DBAs haben keinen Systemzugriff, also SSH-Zugriff hat man normalerweise, aber vielleicht keinen UD-Zugriff. Man muss dann eher die technischen DBAs bitten, Pakete einzuspielen und so. Oft ist es dann vielleicht auch so, dass man gar nicht per Sudo sich einloggen kann
19:04
als Postgres-Nutzer, sondern halt nur Stopp von Postgres macht. Das muss man dann halt sehen, aber diese Trennung der Arbeitsbereiche und die Abgrenzung und die Dokumentation der Abgrenzung, das ist schon mal ein erster wichtiger Schritt. Dann auch sehr wichtig, was überraschend oft eigentlich
19:22
nicht eingehalten wird, ist die Separierung von Test- und Produktivdaten. Generell ist es so, ich habe dann versucht, wenn ich jetzt hier spontan den richtigen BSI-Baustein habe, da auch eine Zitat einzufügen. Hier habe ich es jetzt auf Anhieb nicht gefunden, aber das ist auf jeden Fall
19:41
sozusagen im Kontext von BSI wichtig und nötig, dass man Produktiv- und Testdaten nicht in der gleichen Datenmark hat oder im gleichen Instanz. Ich habe das schon durchaus auch von Kunden, von uns erfahren, dass man dann Anruf kriegt und sagt, ja, Entwickler hat sich aus Versehen auf die falsche Datenbank verbunden und hat dann seinen Test-
20:03
Skript ausgeführt und jetzt ist alles weg, bitte helft mir, wir haben aber leider auch keinen Backup. Und sowas kann leider nicht passieren, wenn man Produktiv- und Testdaten trennt und die Entwickler dann eben zum Beispiel keinen Zugriff auf die Produktivdaten haben. Die mögliche Separierung im Postgres, da gibt es verschiedene Abstufungen, auf jeden Fall kann man oder dann generell mal, um Datenbanken abzutrenzen,
20:24
hat man auf die Host oder Virtual Machine oder Container Ebene, dann ist es da sozusagen eine logische oder physikalische Separierung und es ist ganz klar, dass man da eben nicht draufkommt. Zusätzlich kann man auf einem Host oder in einer Virtual Machine
20:40
mehrere Instanzen von Postgres gleichzeitig laufen lassen. Die sind dann auch vollkommen voneinander unabhängig, wenn die fachlichen DBAs oder Entwickler keinen Shell-Zugriff haben, was üblicherweise auch nicht nötig ist, dann können die auch wirklich nicht sagen, was da sonst auf der Maschine läuft, also nur wenn man sich mit einer Datenbank in einer Instanz verbindet, kann man überhaupt nicht sagen, was in den anderen Instanzen los ist.
21:03
Etwas weniger dann wäre die Datenbank, das heißt, man hat in einer Instanz mehrere Datenbanken und Entwickler A ist erlaubt, sich zur Datenbank A zu verbinden und Entwickler B zu in Datenbank B. Dann würde aber Entwickler B zum Beispiel sehen, dass es Entwickler A gibt, weil Rollen in Postgres globale Objekte sind und man die auf jeden Fall sehen kann.
21:24
Insofern ist es da eigentlich sinnvoll, dass verschiedene Kunden, wenn möglich, eigene Instanzen bekommen. Wenn sie auch jetzt zum Beispiel, man hat jetzt einen großen Rechner für alle Testinstanzen, dass man da halt jedem Kunden einzelne Instanzen gibt.
21:41
Noch schlimmer oder weniger sinnvoll ist auf Schemaebene das Separieren, weil man dann auch die Datenbankobjekte sieht, das ist eigentlich jetzt nur der Vollständigkeit halber, das wäre per RSI nicht möglich. Auf jeden Fall erstmal der oberste Punkt. Produktive Instanzen sollten auf dem eigenen Server laufen, entweder Wirtelmaschine oder eigener physikalischer Host,
22:02
dass man da die Abgrenzung hat und die auch dann zum Beispiel besser physikalisch schützen kann in einer besseren Schutzzone oder wie auch immer dann sehen kann, vielleicht dann auch redundanter auslegen kann, ob jetzt die Hardware besser ist oder nicht. Das ist dann eher eine taktische Entscheidung, wie man da die Testumgebung
22:23
einrichtet, ob man da die gleiche Daten haben will oder nicht. Ansonsten muss man dazu sagen, das Ressourcenmanagement von mehreren Instanzen auf einem Host ist ohne Wirtelmaschinen und Container schwierig. Es gibt eine C Group Erweiterung, die ist aber nicht sehr mainstream, würde ich sagen. Da muss man eben aufpassen, dass die einzelnen Instanzen
22:42
dann nicht den anderen Instanzen die Ressourcen wegnehmen. Genau, das soweit zur Separierung von Test- und Produktivdaten. Das ist auf jeden Fall ein erster Punkt, der wichtig ist und der beherzt werden sollte. Dann die andere Sache, die eigentlich hilfreich ist,
23:01
die wir empfehlen umzusetzen, ist Notfall, Nutzer, Host, Plan, Übung zu haben, also einen Plan zu haben, wenn was passiert, irgendwie einen Disaster Recovery Plan oder auf jeden Fall schon mal einen Notfall Nutzer zu haben, der vielleicht auf jeden Fall irgendwie auf die Datenbank kommt von überall her.
23:22
Das Passwort sollte halt sicher sein, aber dann eben in einem Tresor hinterlegt oder dem Keystore, sodass Leute im Notfall darauf zugreifen können und das dann eben halt auch additierbar ist, wer das gemacht hat. Wichtig auch, wenn man sich mit einem über einen Jump Host verbindet, dass man da einen Notfall-Jump-Host hat, falls der übliche Down ist und man dann halt dann
23:44
zur Not was machen kann und auch ein Notfallplan, also was passiert im Notfall, wie ist die Eskalationskette, wer wird alarmiert und das sollte man eben auch üben, vielleicht einmal im Jahr, dass man den Notfallplan übt. Dann der nächste Punkt wäre Datenbank-Lebenszyklus
24:01
und hier jetzt wieder ein Zitat aus dem BSI-Grundschutz, die Datenbanken müssen eben nach einem definierten Prozess angelegt werden und die Informationen müssen dokumentiert werden und es muss auch ein Prozess etabliert werden, wie man eben Benutzer oder Berechtigungen anlegt, genehmigt, eingerichtet, modifiziert und wieder entzogen werden, dass man
24:21
diesen Lebenszyklus lebt und da auch einen gewissen Paper Trail hat. Also das fängt an mit der Beantragung, man kann das machen per Formular oder per Ticket. Was wir hier empfehlen würden, wäre möglichst wenig Auswahl den Leuten zu geben, weil natürlich hat man manchmal auch mit
24:41
Leuten zu tun, die sich da genau auskennen oder man hat vielleicht irgendwelche Hersteller, die dann sehr genau die Vorgaben haben, aber auch wissen die Leute auch nicht so genau, was sie brauchen und wenn man ihnen dann von 1 bis 99 Terabyte erlaubt, irgendwas auszuwählen an Storage oder weiß ich nicht, die V-Cores beliebig
25:01
einzusetzen, dann hat man dann x-beliebig verschiedene Instanzen überall rumlaufen, also es ist da auch eigentlich hilfreich, sowas wie S, M, L, X, XL oder sowas zu haben, wie es man von Cloud Betreibern üblicherweise gewohnt ist und dann auch eben entsprechend dann den Speicher oder
25:23
gut den Storage, das ist dann nochmal eine andere Sache, ein anderer Freiheitsgrad, aber zumindestens die Cores und den Speicher da schon mal so zu skalieren und auch sonst möglichst wenig den Kunden jetzt zum Beispiel nicht irgendwelche Details des Backups zu überlassen, wenn das nicht
25:41
nötig ist, man kann natürlich alles dann noch individuell absprechen, wenn es nötig ist, aber wenn man eine gewisse Größe hat, Pat not cattle, sollte man dann möglichst einheitliche Instanzen haben. Die Inbetriebnahme ist dann immer gut eine Checkliste zu haben, oft ist dann so, man muss irgendwie Storage bestellen beim Storage Management oder man muss eventuell virtuelle IP
26:01
Adressen bestellen bei irgendeinem Netzwerk Infrastruktur Management, man muss die Pakete einspielen lassen, man muss dies oder man muss das machen und da ist es gut, wenn man eine Checkliste hat oder eben auch ein Playbook, Finanzable oder Terraform, dass das die bestimmten Schritte dann macht, man kann
26:21
diese Schritte dann auch vielleicht in irgendwelche Skripte noch vervollständigen, aber wichtig auch ist, dass man den Kunden das am Ende dann abnehmen lässt, dass man dann die Sicherheit hat, dass der Kunde zufrieden ist mit dem, was man da abgeliefert hat und dann sozusagen dann auch die Dokumentation hat, dass es das ist, was der Kunde wollte. Man hat in der
26:42
Vergangenheit immer wieder gehabt, dass man dann nach Monaten kam, ja, ne, das muss ja ganz anders sein, machen sie das mal so und so, das wollten wir nicht und wenn der Kunde das halt unterschrieben hat, dann kann da nicht mehr so viel passieren, dann kann man das verargumentieren. Genauso bei Änderungen, neue Datenmarken, neue Nutzer, Änderungen der Nutzer, zusätzliche Erweiterungen, Konfigurationsänderungen, wenn das
27:01
eben auch nicht Self-Service irgendwie geht, dass man diese Sachen dann dokumentiert, einen Plan hat, wie das passiert, einen Ablaufplan und das auch verschriftlicht hat. Das Gleiche gilt dann, dass man sich überlegt, wie man Patching und Major Upgrades macht. Major Upgrades würde ich jetzt nicht groß hier diskutieren, aber
27:21
das Patching kommt dann gleich auch noch in einer eigenen Folie und ansonsten auch sehr wichtig, weil man da vielleicht nicht unbedingt jedes Mal dran denkt, dass auch die Aussonderung oder die Entfernung von Datenmarken oder Instanzen eben bedacht werden sollte, dass es da eben auch wieder eine Checkliste gibt oder ein Playbook, was passiert, was man da macht, muss man zum Beispiel
27:41
den letzten Stand noch archivieren und so weiter und so fort. Diese ganzen Sachen sollte man in einem Betriebshandbuch auch zusammenschreiben, die Checklisten kann man dann da drin haben, kann man ausgliedern, man kann auch generell die ganzen Arbeitsabläufe da reinschreiben, man sollte das jetzt nicht zu fein granular machen, also nicht
28:01
jeden Copy-Buffet oder so was oder nicht jedes Fehler, den man irgendwann mal gefunden hat und was man da gemacht hat, irgendwie da unbedingt reinschreiben, das sollte auch nicht zu unübersichtlich werden, aber die üblichen Arbeitsabläufe sollten da drin sein, das ist dann auch wichtig für Onboarding von neuen Kollegen oder wenn jemand mal im Notfall drauf schauen muss, dass er sich da nicht erst hunderte Seiten anschauen
28:20
muss. Da auch wieder wichtig, weil diese ganzen Konzepte und das Betriebshandbuch und so, das muss oft dann irgendwie freigegeben werden vor einer Zertifizierung oder einem Audit, dass man da halt dann oder das muss auch versioniert werden und so, dass man da keine dynamischen Daten drin hat wie irgendwie die Liste der Hosts, sondern dass man das alles auch in
28:42
externe Dokumente auslagern kann, vielleicht auch wie das Monitoring zum Beispiel aufgebaut ist und so, dass es da alles auf externe Dokumente auch verwiesen werden kann, damit das Betriebshandbuch selber dann auch nicht so groß ist. Genau, die waren wir eben gerade auch schon so ein bisschen dabei gewesen. Wichtig ist eben auch die
29:00
Dokumentation von Änderungen und Störungen, gerade Letzteres sollte man nicht unterschätzen, wenn was passiert, dass man das dann eben auch dokumentiert, was ist passiert, wann ist es passiert, wie hat man es behoben und dann vielleicht auch ein Post-Mortem macht mit den entsprechenden Gruppen, aber generell die Änderungen, es ist relativ egal wie, es ist halt wichtig, dass sie dokumentiert sind,
29:22
dass man das auch noch in zwei, drei Jahren nachvollziehen kann, vor allem wenn man eben nicht nur eine Datenbank hat, sondern Dutzende oder Hunderte, da ist es dann egal, ob man das in einem Sharepoint macht oder in ausgefüllte PDR- Formulare für Beantragungen oder Änderungen, dass man die dann irgendwo ablegt auf irgendwelchen Shares, dass man vielleicht Text-Dateien nur hat, was hat man geändert,
29:41
dass das auf jeden Fall auch in irgendwelchen Tickets ist oder eben auch kann sein im Git nachvollziehbar ist, wenn man GitOps zum Beispiel ja lebt. Genau, das dazu. Dann der nächste Punkt wäre die verwendete Version und Patchplan. Da ist auch vom BSI relativ stark
30:00
vorgeschrieben, dass man das machen muss, dass man patchen muss, dass das zeitnah passiert und eben auch, dass man das in einem Testsystem macht und dass man eben schaut, was die Abdeckzyklen sind. Hier ist man mit Postgres eigentlich auf einer sehr guten Ebene. Also die Major Releases werden fünf Jahre lang unterstützt von Postgres selber. Man muss da kein Enterprise Support einkaufen
30:21
oder so. Man bekommt einfach die für jedes Major Release Patches fünf Jahre lang. Diese Patches sind planbar. Sie sind vier Mal im Jahr, jeweils am zweiten Donnerstag des zweiten Monats eines Quartals. Man kann sich da also einen Termin erstellen im Kalender und ansonsten gibt es
30:41
halt auch ein Security Team für außergewöhnliche Sicherheitsvorfälle, aber in den letzten fünf Jahren ist es nur einmal vorgekommen, dass es dann Out of Bank nochmal ein Point Release gab. Üblicherweise werden die Sicherheitsvorfälle halt einfach dann am Ende noch mit reingenommen und announced mit dem vierteljährlichen Patch Releases. Als genereller Tipp,
31:01
neue Major Versionen sind nach ungefähr zwei bis drei oder zwei bis vier Point Releases bereit für den Produktiv-Einsatz. Also so ungefähr ein Jahr nach Produktiv-Gehrung. Man sollte das natürlich dann auch entsprechend testen, ob das im eigenen Umfeld dann sinnvoll ist und dann auch spezif frei geben für die Kunden zur Benutzung. Generell, wenn man
31:20
das auf Linux betreibt, Distribution Pakete sind verfügbar über Postgres, also vom Postgres Projekt, sowohl für Debian Ubuntu mit Postgres Quail Org, also für Red Hat Centos Suse Linux Enterprise bei Postgres Quail Org. Und da bekommt man für alle aktuell, also fünf Jahre, also meistens hat man
31:41
fünf Major Releases, die vom Postgres unterstützt werden und dann hat man auch jede Menge Major Releases der Red Hat, also Red Hat 7, Red Hat 8, Red Hat 6 oder Ubuntu 16.04, 18.04, 20.04. Für diese alle unterstützten Stable- oder Long-Term-Support-Versionen
32:00
bzw. Major Versionen gibt es die Pakete, die kann man sich darunter laden und das sind die offiziellen Pakete. Das ist unabhängig von denen, was die jeweilige Distribution als Standard Postgres Paket hat. Wenn man dann erst zum Patchen kommt, ist es so, man muss die Pakete halt einspielen, einspielen lassen und die
32:21
Instanzen dann neu starten. Das bedeutet, laufende Abfragen und Sessions werden beendet. Deswegen ist es sinnvoll, da ein Wartungsfester zu haben oder eben dann organisatorischen Vorlauf. Man braucht dann auch wieder Ansprechpartner oder Verantwortliche. Das heißt, auch da ist es wieder gut dann eben zu wissen, wer ist da
32:40
Auftragsbefreumichtiger oder Beziehungsweise Ansprechpartner für sowas, dass man die dann automatisch anschreiben kann oder was vielleicht noch besser ist, vor allem, wenn man dann viele verschiedene Instanzen im Host hat, dass man einfach festlegt, dass es ein Wartungsfenster gibt und der der Kunde dann damit rechnen muss, dass es eben mal
33:00
Neustart gibt. Das ist bei den meisten Sachen dann vielleicht auch okay, insbesondere bei Test- und Entwicklungsinstanzen. Wenn das nicht okay ist, dann sollte der Kunde vielleicht hochverfügbare Datenbanken haben, wo man dann schwenken kann, ob das dann im laufenden Betrieb so einfach ist oder ob das dann auch wieder die laufenden Abfragen beendet, das sei dahingestellt. Da kann man
33:20
dann vielleicht mit den Kunden das auch besser planen, aber im Prinzip sollte man da dann schauen, dass man das automatisiert, möglichst automatisiert handhabt und insbesondere eben auch die Test- Instanzen zuerst machen, vielleicht eine Woche vorher, um dann den Kunden die Möglichkeit zu geben, da eventuell noch zu reagieren. Man muss aber auch dazu sagen, dass Postgres da einen sehr guten
33:42
Track Record hat, was Sicherheitsupdates oder generell Patch-Releases angeht. Es werden dann nur klare Bugs behoben. Es gibt keine neuen Features und insbesondere gibt es keine Kompatibilitätsprobleme, außer für den sehr unwahrscheinlichen Fall, dass ein Sicherheitsupdate dann eben irgendwelche Änderungen benötigt oder ein katastrophaler
34:02
Fehler. Das passiert eigentlich nicht und ist dann meistens auch eher lokal. Im Allgemeinen hat man da keine Probleme, wenn man die einspielt, aber es ist trotzdem sinnvoll und per BSI vorgegeben, dass man da eine Woche wartet. Genau. Dann der nächste Punkt wäre Härtung der Standardberechtigung. Hier wieder das schreibt BSI soweit
34:21
vor, was man dabei Postgres machen sollte. Aus unserer Sicht sind die Standardberechtigungen soweit zu härten, dass man das eben nicht mehr macht. Also Postgres erlaubt standardmäßig sich im Prinzip an seinen Datenbanken anzumelden. Deswegen sollte man das erstmal vielleicht revoken. Es gibt die
34:42
sogenannte Rolle Public, in der dieser Nutzer drin ist und die relativ viel darf. Also wenn man sich erstmal verbunden hat an der Postgres Datenbank erfolgreich, dann darf man relativ viel. Postgres erlaubt standardmäßig nicht, dass man sich per RTCP IP zum Beispiel auf einen Postgres Datenbank verbindet. Also wenn man es installiert, ist es nicht
35:00
sofort im Internet, abgesehen davon, dass man vielleicht eh eine Firewall hat oder einen VPN. Aber wenn sich jemand verbinden darf, dann darf er erstmal relativ viel. Er darf sich an alle Datenbanken anmelden und insbesondere darf er im Public- Schema Sachen anlegen, so viele will. Und das ist in der Tat schon ein größeres Problem. Deswegen sollte man das auch unterbinden und dann
35:22
im Zweifelsfall halt mit den Kunden dann einzelne Maßnahmen treffen, falls sie das irgendwie benötigen, beziehungsweise halt mit ihnen reden, was da jetzt nötig ist. Genau. Das dazu. Dann generell der System- und Datenbankzugriff, also wie man da überhaupt draufkommt. Der Systemzugriff dazu ist zu sagen,
35:42
ein wichtiges Postgres Nutzer sollte sich nicht via SSR einloggen dürfen. Braucht er eigentlich auch nicht. Man sollte immer eine persönliche Kennung haben, die über einen Jump-Post geht, die sich auf dem Datemann-Serva einloggt, wenn man das überhaupt muss. Und diese Jump-Post sollte dann auch nur im VPN stehen und nicht im gesamten Internet verfügbar sein. Und dann
36:02
natürlich einloggen, wenn es geht, nur mit SSR-Schlüssel und auf das VPN nur mit zwei Fakta-Autodetizierungen und so weiter und so fort. Das sind eigentlich generelle Sicherheitsmaßnahmen. Aber genau, man sollte sich als technischer DBA mit seiner personalisierten Kennung einloggen und dann, wenn nötig, auf den
36:21
Postgres Nutzer per Sudo aufschalten. Generell sollte man natürlich auch keinen direkten Hutzugriff erlauben, wobei das wie gesagt den größeren Firmen und Behörden dann oft den technischen DBAs gar nicht erlaubt ist, gut zu werden und diese Art der Betriebssystemsachen dann nicht im Bereich des DBAs liegen. Der
36:42
System-Benutzer ist halt der Instanz-Benutzer. Man kann das natürlich umbenennen. Das sehe ich jetzt aber ehrlich gesagt nicht unbedingt einen riesen Vorteil. Der wird benötigt, um die Instanz zu starten oder zu stoppen. Und wenn man ins Datenverzeichnis schauen will, bis zu inklusive Version 10 hat sich Postgres
37:02
geweigert, wenn das Datenverzeichnis nicht, also Gruppen lesbar war mit irgendeiner Gruppe. Ab Version 11 kann man einer Gruppe Zugriff gewähren. Das heißt, vorher konnte man überhaupt nur als Postgres Nutzer darauf zugreifen, wenn man zum Beispiel wissen will, wie groß der Datenmarkt ist oder irgendwelche forensischen Sachen braucht oder so oder sonstige
37:22
Sachen da auskopieren will oder vielleicht auch ein Backup macht natürlich, wenn man das irgendwie selber macht. Sinnvoll wäre da, dass der Postgres Nutzer nur eine bestimmte Sudobefehle macht, keine eigene Shell bekommt, ist aber in der Praxis oft schlecht umsetzbar und muss dann zu sagen, dass man oft dann eben noch diesen
37:40
Zugriff dann als technische DBA bekommt. Generell was Kennungen und Passwörter angeht, da gibt es auch jede Menge, was BSI dann fordert. Auf jeden Fall ist es so, dass man als TDBA oder generell DBA einen Password Manager verwenden sollte für alle sonstigen Passwörter, wie ich keine Ahnung, Nextcloud
38:00
Zugang oder sowas oder sonstige Sachen, die jetzt nicht, also die mit der Arbeit zu tun haben, aber nicht direkt eine Datenbankrolle sind. Der andere Punkt, der hier jetzt wichtig ist, Postgres selber, ist in dem Fall leider nicht ganz so enterprise, dass es nicht
38:20
Änderungen oder es setzt keine Passwortrichtlinien um, wie jetzt Komplexität von Passwörtern oder regelmäßige Änderungen. Man kann noch nicht mehr sehen, wann sich eine Rolle an seinem Passwort geändert hat, leider sogar als Superuser nicht. Das heißt, da muss man dann schauen, dass man das anders umsetzt. Und unser
38:41
Vorschlag wäre hier, als technischer Nutzer für Anwendungs-Server Scram-Odd Defentification zu verwenden. Das ist eigentlich heutzutage State of the Art. Und dann den Anwendungsbetreuern oder wer halt immer das dann da fachverantwortlich ist für die Passwörter, um sie zu verpflichten,
39:01
dass sie dann eben die Passwörter ändern, wenn man das selber eben nicht kann. Und für sonstige Entwickler oder sonstige personalisierte Nutzer sollte man erstmal personalisierte Accounts verwenden, sodass man das auch dann eindeutig zuordnen kann. Und das kann man dann üblicherweise über LDAP oder Active Directory umsetzen. Da muss man allerdings
39:21
aufpassen, dass die Verbindung, also das läuft dann so ab, dass Postgres sich, man teilt dann Postgres sein AD-Passwort mit bei dem Verbindungsaufbau und Postgres versucht sich dann mit diesem AD-Passwort auf dem LDAP- Server oder AD-Server zu verbinden oder zu binden. Und wenn das funktioniert, dann erlaubt
39:41
Postgres eben auch, sich mit dieser Rolle auf der Datenbank anzuwählen. Generell kann man alternativ noch GSS API verwenden, ist aber leider sehr kompliziert und man braucht dann auch irgendwie Hilfe bei dem AD-Server, die man vielleicht dann nicht hat in größerem Umfeld. Verbindungsfreischaltung, das ist der Punkt, wenn es darum
40:01
geht, jetzt zum Beispiel TCP IP Verbindungen zu machen. Wichtig ist, dass für TDBAs, man sollte es nur über personalisierte Kennungen über TCP IP machen oder eben lokal über die sogenannte Peer-Authentifizierung. Wenn man sich schon lokal angemeldet hat mit SSH und dann eben Sude Rechte hat für Postgres zum Beispiel,
40:21
dann kann man sich auch als Postgres-Rolle an der Datenbank lokal über ein Socket anmelden. Das ist dann okay. Ansonsten muss man halt bestimmte Quell-IP-Adressen freischalten lassen für TCP IP Verbindungen in der sogenannten PGHBA-Conf. Da hat man ein Minimalprinzip zu befolgen und generell sollten die verschlüsselt
40:40
sein, sogenannte Host-SSL und es sollte feingranular möglich sein, die einzelnen Datenbanken da zu machen. Man kann zum Beispiel eine Scrum-Gruppe und Held-Up-Gruppe machen, um die einzelnen, also zum einen die technischen Benutzer abzugrenzen und die sonstigen Benutzer, sodass man zum Beispiel in Produktionen nur den technischen Benutzern Zugriff gibt, aber eben nicht den
41:00
älteren Benutzern. Das ist dann möglich oder auf jeden Fall nur den Applikationsservern die IP-Adressen gibt. Das wäre jetzt hier mal so ein Beispiel einer PGHBA-Conf. Jetzt vielleicht noch ein paar kurze Worte zu sonstigen Punkten im laufenden Betrieb.
41:21
Protokollierung ist im Prinzip wichtig, ist im Prinzip auch ein gewisser Eigenschutz für DBAs. Man hat selber natürlich Super-User- Rechte und man will ja dann auch gegenüber dem Chef oder dem Chef-Chef oder dem Behördenleiter oder dem, was er sich war, Geschäftsführer nachweisen können, dass man da keine Sachen gemacht
41:41
hat, wenn es mal ein Problem gibt. Deswegen wichtig oder sinnvoll ein Protokollierungskonzept zu haben und aus unserer Sicht auch vielleicht sinnvoll revisionssichere Die DBAs können das dann oft schreibend auch ändern, wenn sie Zugriff auf die Postgresrolle haben, weil der muss es ja schreiben können. Eine
42:01
Möglichkeit ist da rsyslog oder syslog-ng zu benutzen, um das an ein Log-Server zu verschicken, wo dann die DBAs noch Leserechte haben. Das ist auch dann hilfreich, wenn fache DBAs Zugriff auf die Serverlogs brauchen. Man kann das vielleicht dann auch rausfiltern irgendwelche personalisierten Daten noch auf der
42:21
Syslog-Seite und dann müssen sie da keinen SSH-Zugriff auf dem Produktiv-Server haben, sondern nur auf den Log-Server oder eben kriegen das sonst wieder zu und man muss aber auch die Aufbauungsfristen beachten. Man kann das dann zusätzlich Auditierungen nennen. Leider Logging von Verbindungen des Verbindungsaufbau ist leider
42:40
unflexibel, kann man nur ganz oder gar nicht machen. Was man machen sollte, ist DDL- Konfigurationsänderungen zu loggen. Das verlangt BSI und sinnvollerweise aus Eigenschutz eben dann Datenänderungen der TDBAs zu loggen, dass man dann nachweisen kann, dass man das eben nicht gemacht hat oder eben nur nach Ticket sowas macht. Die
43:01
PG-Audit-Erweiterung ist da sehr hilfreich, wenn man gezielt irgendwas loggen will. Also zum Beispiel nur Änderungen auf eine bestimmte Tabelle oder so. Das hilft dann da weiter. Dann Backup und Restore ist ein weiter wichtiger Punkt. Auf jeden Fall braucht man da ein Produkt, man sollte vermutlich
43:22
ab einer gewissen Größe von Datenbanken physikalische Backups haben, kann man vielleicht dann auch ein bisschen automatisiert einstellen. Da auch sinnvoll ein fertiges Produkt wie zum Beispiel PG Backrest oder Barman zu verwenden und nicht sich das selber zu basteln, weil man da gesehen hat, dass es da durchaus auch zu subtilen Problemen kommen kann. Man kann
43:41
natürlich auch Dumps machen, gerade wenn die kleiner sind. Das kann man dann auch per lokalen Skript durchführen. Man muss die Retention-Time beachten. Oft wird das halt dann auf Tapes oder so ausgelagert, aber dass man da vielleicht genug Platz hat auf der lokalen Instanz oder eben einen zentralen Backup-Server hat. Was auf jeden Fall wichtig ist, sind automatisierte Restore-Tests.
44:00
Das kann nicht nur jedem ans Herz legen, dass man da zum Beispiel einmal die Woche für produktive Instanzen macht und bei Point-in-Time-Recovery auch danach noch einen Dump macht, weil man da nicht sicher gehen kann, sonst, dass tatsächlich die Daten konsistent sind, wenn sie nur hochgefahren wird post-cris nach dem Einspielen, aber vielleicht nicht alle Daten lesen kann. Dann noch ein kurzer Punkt
44:21
zum Monitoring. Es reicht oft E-Zinger-Monitoring mit ein bisschen Alerting. Das deckt das, was ich will, ab, aber natürlich ist es hilfreich, ein sinnvolleres Monitoring zu haben, um zum Beispiel Performance-Probleme zu finden. Das ist aber eigentlich ein Vortrag für sich. Hier jetzt nur üblicherweise die
44:41
beiden Stacks sind dann Check-Post-Cris als E-Zinger-Plugin und dann Flux-DB-Krafana für Graphen oder eben Prometheus-Alert-Manager und Node- oder Post-Cris oder SQL-Exporter für Metriken und dann auch wieder Krafana-Dashboards. Das dazu will ich jetzt nicht mehr
45:01
dazu verlieren, sondern vielleicht noch ein paar Schlussbemerkungen zu machen. Was ich schon versucht habe, soweit zu sagen, ist, dass klar, das ist alles sehr bürokratisch, aber ab einer gewissen Größe sind viele von diesen Anforderungen einfach sinnvoll und helfen auch. Es ist vor allem auch Selbstschutz für Datenbank-Administratoren oder insbesondere für externe
45:20
Dienstleister oder Freelancer, dass man eben einen Auftragsberechtigten oder Ansprechpartner hat, die einem dann halt eben sagen, ja geht, geht nicht, man nicht das selber entscheiden muss, dass man ein Paper-Trail hat bei solchen Sachen, dass man durch Protokollierung, Auditierung nachweisen kann, dass man selber eben nichts gemacht hat. Man sollte auf der anderen
45:41
Seite auch nicht zu sehr die BSI-Kolde schwingen und bei jeder Kleinigkeit sagen, ne, ne, geht nicht, BSI, BSI, also das ist eigentlich auch nicht wirklich hilfreich. Man kann das schon mit Augenmaß umsetzen oder verargumentieren und begründen und oft kann man dann auch mit den Leuten reden. Und generell auf der anderen Seite ist es
46:00
aber dann auch wieder eine ganz gute Argumentationsgrundlage, wenn sich zum Beispiel jemand weigert, von Postgres 8.4 oder so wegzugehen, weil sie keine Lust haben oder die Anwendung angeblich das nicht unterstützt, dann kann man durchaus mal sagen, na gut, das kannst du schon so machen, aber dann brauche ich eine Risikoübernahme. Genau, und damit wäre ich
46:20
eigentlich auch schon am Ende von meinem Vortrag und würde jetzt für Fragen noch zur Verfügung stehen. Vielen Dank für die Aufmerksamkeit.